Notes, SIMPLE Second Session, IETF 61

Reported by Dean Willis

Topic: PIDF Partials

----------------------------------------------------

Discussion led by by Jari Urpalainen

Slides presented

Comment: There would be a benefit to having some sort of XML

compression and partial scheme that would work across

applications. Discussion followed on this approach vs xcap

diff. Author maintains this approach is shorter and should replace

xcap diff. Suggested that there should be comparisons made with real

messages.

Comment: It appears that the net effect is that we have different XML

element names.

The previous proposal worked on the element level, whereas this

approach is doing more of a syntactic patch.

Consensus: We should settle on one technique -- this or XCAP diff, or

whatever. Noted that XCAP diff is already a WG document, so we should

study this approach and see what, if any, makes it better, then add

that to xcap diff.

Chair commentary: This is the result of convergent evolution, and we

should take this to the list for convergence. We do still have a need

for partial notification. We should also check with people outside

SIMPLE who are doing XML diffs.

Topic: Partial Presence

------------------------------------------------------

Discussion led by Aki Niemi

Slides presented.

Goal: A small change in presence should produce a small NOTIFY.

Noted that this technique should work for any event package using XML

bodies.

Observed that sometimes, for a very small document, a partial update

might be larger than a full update due to the extra syntax. It was

discussed as to whether the draft has adequate guidance on "when" to

use the partial format.

Topic: XCAP Needed Diffs

-------------------------------------------------------

Discussion led by Jonathan Rosenberg

Slides presented.

Issue: Noted that draft needs to clarify usage of term "idempotency".

Discussion of this term and usage followed.

Issue: Namespace prefix definitions. Fix proposed in

slides. Discussion: Could this lead to a collision? Ans. No, the

prefix definition is at the service element itself.

Conclusion: Author will submit a revised draft.

Presence Data Model Open Issues

--------------------------------------------------------

Discussion led by Jonathan Rosenberg and Henning Schulzrinne

Slides presented.

Issue: One element vs. many. Current system does not allow conflicting

data. It has been proposed tha twe allow multiple service elements,

representing conflicting input to the compositor, allowing the watcher

to decide.

Proposal: Stay with existing system (argued by JDR). This generates

issues for automata as consumers of services. This may also lead to

multiple ways of interpreting conflicting data vs. simultaneous

capabilities, and could be problemactic. This also requires adding a

tuple/element identifier, and may need lots of additional metadata to

make the interpretation feasible. Alternate approach would be to add a

"<conflict>" wrapper later.

Proposal: Add support for many elements (Argued by HGS). Most existing

presence systems have only once source of presence data. They don't

need to do multiple elements. However, we are now building multisource

systems, and need multiple elements to meet additional requirements

listed in slides.

Noted that one could add a "<view>" or "<conflict>" wrapper now, to

accomplish something similar, but that if it is added "in the future",

we will have a major backward compatibility problem.

Disussion follows . . .

Observed that conflicting data will occur -- the Question is how to

deal with

this. Is there really a correct composition of this data, or is there

a consumer decision that is needed? We probably have a need to support

delivery of both "vest guess" composition AND full data to consumers.

Observed that we may not know how to do the "best" composition in all

cases, and therefore probably need to be able to expose uncertainty to

the watchers.

Observed that it may be important that the publisher understand what

the compositor is going to do with its data. This may lead to a need

for source-expressable composition preferences, which is hopefully a

"future" topic.

Proposed that we need to support both models.

Proposed that HGS' model would benefit watcher-specific composition.

Noted by chair: This means that an "original source" could publish

conflicting information.

Proposed that the presence document should be able to indicate the

"preferred" view among conflicting views, and that this would be

usable by "dumb" clients. Also noted that "outgoing" policy might

dictate which view is shown to any given watcher.

Proposed that there is no "one true answer" for composition.

Proposed that a timestamp is not enough to indicate the "preferred"

element out of a compositor.

Chair summary: Not acceptable for us to produce a lossy model. We want

the ability to pass through additional information. We understand that

this increases complexity. We will not explain everything, but will

provide a hint as to to which one of the conflicting elements is

recommended.

Issue: Sphere

If we have multiple elements, we may have conflicting sphere

information. This breaks the current model of using the default

composition policy to select which authorization policy applies.

Proposal: Allow separate algorithm (not same as default composition

policy) for determination of which conflicting variable is used for

authorization policy.

Much discussion followed.

Proposed that perhaps authorization policy should be driven by the

view that would be seen by the presentity as a watcher.

Issue: Mutiple Services with Same URI

Much discussion followed.

Noted that there are deployments that don't support GRUU and that some

are hestitant to make the solution GRUU dependent.

Noted that "Open" and "Closed" at a top-level are inadequate as soon

as there are multiple capabilities per device.

Discussion devolved into an apparent divide between model views.

Chair point: We keep talking about differentiating tuples based on

URI equivalency, and whether compositors group according to these same

comparisons. This necessitates that compositors be able to

ascertain the equivalency of two URIs, which might be difficult. We

appear to have no consensus on this at thsi time.

Summary: This is going to make a long list discussion, and we may not

have even stated the problem clearly.