SIMPLE Interim Meeting

Afternoon Session Minutes

Monday 24^th May 2004

XCAP Open Issues

Jonathan Rosenberg

Slides presented

Issue 1: Schema Extensibility

Proposed on-list that schema be appleid only to validation, and that

insertion location be determined by client. No disagreement noted on

list or in meeting.

Issue2 : Positional Insertion

Operator and predicate suggestions made on-list.

Discussion in the meeting explored the complexity level of XCAP with

the suggested mechanism versus possible simpler approaches. No

conclusion on this point.

Also proposed that we consider the "simplifying assumptions" that are

applied, for example flat structures.

Three options proposed:

1) Flat structures -- contain the schemas to prevent failures.

2) Servers that support specific address/location model or

top-level replacement only.

3) Servers that support full xpath-like specificity.

It was suggested that the servers should be able to negotiate the

granularity of their policy.

Comment: If this xcap stuff can't be done as a reasonable student

project, it isn't happening.

Decision making process. Rohan proposes that anyone suggesting "moving

the bar" here should provide detailed examples that illustrate what

they are doing and why the existing approach is inefficient.

Discussion: How many customers for XCAP do we see? Does this justify a

full-on, all possible capabilities design, or something optimized for

the specific customers?

No decision reached in meeting and analysis will continue.

Issue 3: PUT v POST

Modifications proposed on list to preserve idempotence and get(put(x))=x.

Debate point: Is there any point to having clients submit request with

"blank" required parameters? Wouldn't it be more efficient to have the

client make something up, which the server could reject if needed?

Poll for consensus on PUT v POST: None opposed to PUT.

Issue 4: Element Separator

Conclusion - two tildes, as in "~~"

Issue 5: Multiple Insertions

Issue is in preserving idempotence on multiple insertion operations.

Two algorithms presented for consideration.

Mentioned that there are numerous efforts to define XML database

operations. We shouldn't try and reinvent them here.

Discussed that most operations that seem to require transactional

multiple-element operations can be avoided by careful design of the

schema. This leaves the question of where to document this

approach. The author proposes that the XCAP document provided a basis

of discussion here.

Noted that schema design can allow overlapping (pipelined) PUT

operations.

Proposed: We do not pursue multiple insertions at this time, but add

discussion on schema design issues into the specification. Rough

consensus for this appraoch was recorded in the meeting.

Issue 6: Selecting Elements by Text Content

Currently selectable by position and attribute value, but not text

value.

Several proposals for content matching have been considered.

Proposed: We wish to exclude selection by text content from the

specification at this time. Rough consensus for this approach was

recorded in the meeting.

Issue 7: Unique Hops in Schema

Proposed that we mandate unique element "key" tags for elements with

max-occurs > 1.

Poll: Do people agree that each level of an XCAP reference must be

unique? Consensus recorded. Note: We need to check to see that we can

enforce this constraint without checking each instance document.

Issue 8: Finding out scope of change.

Four solutions proposed for consideration.

No conclusion on approach recorded at this meeting. Noted that we have

to stay as semantically close as possible to the basic etag

model.

Presence Authorization Rules

Jonathan Rosenberg

Slides Presented

Slides reviewed current authorization document format.

Open Issue #1 Default provide-contact

Proposed: Provide Unknown Status. No conclusion noted.

What is a Tuple?

Jonathan Rosenberg

Slides Presented

Proposes several ideas, all of which appear to be controversial.

Event Filtering

Hisham Khartabil

Slides Presented

Issue 1: Allowing multiple filters per target. Consenus to disallow.

Issue 2: List-expansion of elements in a filter yields elements that

do not exist in the list. What do we do with these elements of the

filter? ZCurrently, these are passed on to any list subscription, in

case the filter actually appleis to a list within the list. Proposed

that this pass-through effect be limited to filters that are targeted

to domains outside of the scope of the RLS. This raises questions

about handling of lists that recurse back to the domain of origin. No

consensus recorded in this meeting.

Issue 3: Should lters of higher specificity override filters of lower

specificity? Proposed "yes". No objections reported. Cullen has a

funny feeling he may be able to come up with examples where this

doesn't work, but doesn't have anything now.

Issue 4: How to remove a filter. Consensus on Proposal 2, remove or

replace using the same filter ID.

Partial Publication

Aki Niemi

Slides Presented

Background presented.

Poll: Is there a need for this? No clear consensus either way recorded.