Subject: [Simple] Fwd: SIMPLE notes

From: Robert Sparks <[email-masked]>
Date: Fri, 19 Aug 2005 09:39:09 -0500

I just noticed that this didn't get forwarded to the list while we were
at IETF. Apologies. These raw notes will be massaged into minutes
this weekend.

RjS

Begin forwarded message:

> From: Dean Willis <[email-masked]>
> Date: August 4, 2005 9:35:03 AM CDTSubject: SIMPLE notes
>
> SIMPLE Notes
> IETF 63
> reported by Dean Willis
>
> Topic: RPID
> Jonathan Rosenberg
> Slides presented
>
> Note: the schema needs to be updated to match what's in the SIP 
> Foundry repository.
>
> Issue 1:
> Verified/Unverified. Solution accepted as proposed. The impact of 
> GI/GO should be noted in the text, at a SHOULD rather than MUST level.
>
> Suggested text add: When you create an originally new document, it 
> must be valid. Rohan promised to send appropriate text.
>
> Issue 2:
> Aliasing. Solution accepted as proposed.
>
> Issue 2; Schema.
>  fromUntil vs sinceUntilProposal to adjust RPID schema accepted.
>
> Issue 3: Schema.  deviceID:
> Proposed to define only as a global element. Proposal accepted. Note 
> that this will change the schema in RPID.
>
> Issue 4: PIDF-LO integration: Proposal to keep definition of PIDF-LO 
> encapsulation out of data model spec. Argued that this makes for a lot 
> of documents to read in order to get an implementation. General 
> consensus on proposal.
>
>
> Topic: Presence Processing Model
> Slides presented
>
> Changes since last rev reviewed
>
> Proposed that further work here be deferred until more critical 
> documents are done and more experience gained. There was general 
> consensus on this approach.
>
>
> Topic: Presence Authorization
> Jonathan Rosenberg
> Slides presented
>
> Changes since last rev reviewed.
>
> Issue; Sphere determination.
>
> To Do: Make the hook for sphere composition more explicit.
>
>
> Topic: XCAP Diff
> Jonathan Rosenberg
> Slides presented
>
> Changes since last rev presented
>
> No known open issues except disconnection with partial publication 
> (different patch format).  many documents blocked on this.
>
> Proposed that we have review and WGLC.
>
> Noted that the impact of different patch implementation might not have 
> a dramatic impact.
>
> Suggested that we use a multipart MIME approach to  Basically, we 
> would put the metadata in an initial text data. This would prevent the 
> CDATA escaping need to handle embedded markup in the current format.
>
> Proposed: Punt and say that the xml-diff format indicates only that 
> the document has changed (notification of change by reference rather 
> than by value).
>
> AD comment: Not worthing doing this just to advise people a document 
> has changed. But the CDATA problem probably bears closer examination. 
> And this task DOES need completion, even if only a piece is split off 
> to meet the near-term requirements.
>
> Next steps; Talk to the XML folks about solving the problem, and if 
> necessary, fall back to change-by-reference.
>
>
> Topic: Partial PIDF format 04
> Jarri
> Slides Presented
>
> Noted by chair that scope of this draft seems to have expanded since 
> last rev, possibly in disagreement with consensus of last meeting.  
> This may require some examination. The authors are cautioned to inform 
> the WG if they see a future need for this sort of scope change.
>
> Noted that this approach has been implemented and seems to work.
>
> Comment: One implementor believes that this spec will be much more 
> difficult to implement than core XCAP was.
>
> Proposed: People should look a drafts using this function and see if 
> this draft has enabled a better solution, then decide.
>
> Noted that the developer of partial notify and related material has 
> found this approach very useful.
>
> Poll: How many people are actively following: Few
>
> How many are actively implementing? Even less. . .
>
> Open question: Can we produce a general XML patch mechanism? AD 
> comment: Very concerned that this may not meet the XCAP design goals. 
> If it does, then it's OK if it's also generally usable. But we have no 
> need to prove that it is a general mechanism in order to proceed.
>
> Chair comment: We can present this as specific to partial 
> notification, even if the algorithms are more useful.
>
> Proposed that we have a con-call with the XML directorate to review 
> this. The ADs will assist with scheduling and selecting the right 
> people.
>
> Proposed by Chair: This seems to be a reasonable way to move forward 
> if it works, and after review with the XML people the WG will be 
> informed.
>
>
> Topic: Common Policy
> Henning Schulzrinne
> Slides presented
>
> Current solution reviewed.
>
>
> Issue: Authenticated vs Asserted
>
> The current draft has some discussion without use cases.  Suggested 
> that this text be deleted and a richer discussion elsewhere be 
> referenced. Debate followed with no clear conclusion.
>
>
> Issue: Processing Logic
>
> Question: Allow OR conditions within various  sections? Currently 
> defined only for <identity>.
>
> Question; Allow >=1 (groups) .
>
> Discussion followed.
>
> Question: Can this accept everybody BUT a specific individual? Yes, it 
> could.
>
> Seems to be general consensus to accept proposal.
>
>
> Issue: Tel URIs;
>
> Proposal to only allow domain identifiers in <many /> clauses., and 
> non-domain identifiers in <one/> clauses.
>
> Discussion followed.
>
> Noted that tel: is not the only class of non-domain identifiers.
>
> Noted that this proposal prevents exclusions on ranges of numbers
>
> Suggested that exclude clauses be restricted to members of the 
> surrounding group element.
>
> Suggested that each rule element apply to a single URI scheme type, 
> like sip: or xmpp:.
>
> Chair comment: How long do we think it would take to navigate our way 
> through this? Would it be reasonable to plan for EGLCZ on presence 
> rules at the end of September? The sense of the room is favorable to 
> this position.
>
> Proposed that we need to do a requirements document. This proposal was 
> met with general disdain.
>
> These general discussion questions need to be raised on the mailing 
> list.
>
>
> Topic: Presence Composition
> Henning Schulzrinne
> Slides presented
>
> Previous discussions summarized.
>
> Comment: It might be nice to be able to apply credibility factors to 
> the composition. This is complicated by the lack of a source 
> attribution in each element.
>
> Issue: Source Labeling
>
> Issue; Simple Composition Policy Language
>
> Comment: Composition of "lunch" and "meeting" is difficult -- is this 
> a lunch meeting, lunch, or a meeting?
>
> Comment: Presence extrapolation is an interesting problem.
>
> Comment: This problem is similar to the configuration merging problem.
>
> Comment Yes, but presence composition errors aren't going to result in 
> device crashes or interop failures.
>
> Comment: This is a very low priority topic.
>
> Comment: A recent exercise in client-side composition revealed that 
> there are 4 or 5 categories of data, with one type of merging 
> algorithm appropriate for that data type.
>
> Comment: Conflicting information can be presented to and analyzed by 
> humans.
>
> Comment; There DOES need to be a way for the user to influence the 
> composition policy in order to get useful information in/out of a 
> system.
>
> Comment: One the things that was in the presence processing model was 
> guidance about how a user sets things.
>
> Topic: Messaging and Delivery Notfication
> Hisham Khartabil
> Slides presented
>
>
> Topic: IMDN
> Eric Burger
> Slides presented
>
> Discussion of two preceding:
>
> Comment: Recent experience with customers indicates a need to solve 
> this problem. Both drafts look like a good start but would be better 
> combined.
>
> Comment: Delivery notification would be useful for calendar 
> notifications.
>
> Discussion of XML vs not-XML inconclusive.
>
>
> Topic: Translation of Schema to WebDAV
> Rohan Mahy
> Slides presented
>
> Comment: JDR sees no value in this approach.
>
> Comment: The functionality of locking mechanism could be very useful.

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple