SIMPLE IETF 64

Notes reported by Dean Willis

Chaired by Robert Sparks, Hisham Khartabil

0900-1130 Friday November 11, 2005

Vancouver, BC, Canada

Topic: Revised agenda presented by chairs.

Slides presented.

Issue: Status reviewed by chairs.

Issue: MSRP update

Will increased fixed size. Will add section describing endpoints with mutual TLS and self-signed certs. Will then send to IESG. There may be a discussion on the sizes. This should happen in next few weeks.

Topic: IMDN

Led by Eric Burger

Slides Presented

draft-burger-sipping-imdn-02

6 open issues raised and discussed on list

Issue 1: Security of notification

Several proposals offered relating to encryption of message body (listed in slides).

Room polled for preference. Ted stated preference for "encrypt body if message was encrypted". Recommendation accepted unanimously by room but will be reviewed on list.

Issue 2: Sender Keeping State

Suggested that we not change from what the draft says. Noted that point "minimum info from IMDN" is critical, and we can do things like validate that a specific message arrived with current text. Noted also that clienst are likely to throw away IMDNs for which they don't have stored state. Suggested that we adjust wording in draft to not talk about state, but about the minimization of information in IMDN itself.

Issue 3: No Disposition time in IMDN

Question (Cullen): Is there another date around that would have to be reconciled? Suggested that the draft should say "Don't trust any dates but what you get from the transport protocol. Question: How does this affect record requirements for financial industries? Answer: draft says "don't do this with IMDN". Other workarounds exist.

Issue 4: Recipient of IMDN can appear to be different from sender.

draft suggests authenticated transport for IM transport. Question raised: There are use cases for sending IMDN via different transport than message. For example, MSRP answering machine that stores a message for later playback might use email for IMDN or other non-session thing. Ted suggest that we "minimize complexity". Poll: Anybody here need this feature? None in room. Resolved to double-check this on list.

Issue 5: Deleted State

Proposed that we drop deleted state altogether from design. Poll: Does anybody want to keep "deleted" as a reporting state? Cullen reports that he thinks somebody was using this, possibly reported in Paris and in the financial sector. Resolved to discuss on list.

Issue 6: Report Consolidation

Proposed to say no but retain placeholder for future extension. Suggested it is important that relays NOT explode IMDNs. Relaying through multiple B2BUAs was discussed. Chair declares consensus on behalf of proposal.

Issue: Does anyone care? Miguel reports that OMA MWG is looking at this. Adam reports that he has customer requirements for this and will be implementing it and would like it to be standardized. Keith clarifies 3GPP position as being in a feasibility study with no official dependencies. Ben also reports a need for standardization. Poll: Who in the room will work on this: Chair reports "enough". Poll: Adopt as WG item? Unanimous response in favor.

Topic: XML Patch Ops BoF

chairs report on discussion in this BoF. The BoF was not interested in building a general xml diff tool. Compromise agreed to move forward with our drafts and roughly what Jari has in his diff tools now.

Topic: XCAP

Led by Jonathan Rosenberg

Slides Presented

draft-ietf-simple-xcap-07 was in RFC Ed queue. Proposed that we yank from queue, revise to fix XCAP namespace issue and several reported bugs and extensibility problem and namespace problem.

The -08 version includes text to fix these things. Slides review the changes.

Changes not noted here received no counter-discussion in meeting.

Issue: Whitespace vs comment nodes. Proposal is questionable in use of mixed text and will be discussed on list.

Issue: Document Selector. Noted (Derek) that OMA does similar things but has their own names. Proposed that we coordinate with OMA on these conventions. Author, chairs, and liaison tasked to work this out.

Issue: Namespace proposal. Get and Namespaces. Proposed that we reject canonical XML approach. Use proposal 2 for blind insertions. Discussed possibility of requiring server to munge namespaces appropriately in some depth (it basically doesn't work). Several people spoke in favor of proposal from slides.

Issue; The Insertion Problem. Proposed to make non-extant resources extant but empty if the parent exists. Question: This would appear to break conditional tests "does this element exist?". Discussion revealed that that the logic for the test changes (test on element not resource but can still be implemented. Proposed that it is worth writing a draft about and discussing. Noted by Ted Hardie that a change of this magnitude would require a full recycle through the IETF publication review process. Further discussion on requirements and mechanism and implications followed. Joel noted that this breaks the ability to "Insert this buddy if I haven't used the name already", which might be important. Question: Is it possible to fix XCAP for OMA now, and leave the "insertion problem" for later as an extension? We can ask OMA if this would work for them, but it remains unclear as to whether this WG will accept the approach. Jonathan will write this up and communicate it with WG and O! MA.

Topic: Presence Authorization

led by Jonathan Rosenberg

slides presented

Relates to conclusions in geopriv on common policy.

Henning suggests "3897 and be done with it".

Issue: Anonymity. Can't currently differentiate "unauthenticated" and "anonymous". Poll: Do we agree to maintain text that does not differentiate anonymous for now? Response appears to be unanimous. The plan forward is that Hannes will revise common-policy soon, and then Jonathan will revise this draft to match.

Topic: XCAP Diff

led by Jonathan Rosenberg

Slides presented

draft-simple-change-log will be essentially abandoned unless we bog down with current mechanism completely.

Issue: Extending xcap-diff. Two approaches described. Discussion followed. There seems to be some kind of issue with Approach 1. The conclusion is dependent on the related change proposal discussed in the slide and cannot be determined at this time. Noted that HTTP responses require a Content-Length, which breaks one of the ideas discussed.

Topic: Partial PIDF

led by Jari Urpalaienen

Slides Presented

Changes from -03 reviewed

Poll: Does anyone believe that these drafts are not ready for WGLC? None opposed. Chairs plan to announce WGLC within next few weeks.

Topic: Simplified XCAP profile

led by Rohan Mahy

Slides presented

Lighweight profile discussed.

Henning is averse to the protocol fragmentation he sees resulting from this approach, and doens't want to have to build on a generic XML database.

Jonathan thinks it is useful to talk about client simplifications, but that simplifying the server will create interop problems and effectively multiple different protocols for different usages.

Jari believes that the additional server code needed to implement the full xcap to be minimal.

Robert suggests that this doesn't really break the XCAP model. Each profile is simply a declaration of policy.

Keith asks whether this approach actually increases the client complexity by requiring it to negotiate and understand profiles.

Jonathan noted that this would appear to require updates of the list usages and other documents in order to reference the profile document.

Derek worries that this might increase client complexity via a requirement to annotate the tree for the profile.

Dan suggests that this approach is a natural optimization towards launching and deploying XCAP services sooner rather than later.

Keith suggested that we're not talking about a profile, but a change to normative behavior and therefore not a profile.

Joel reports that previous attempts to build restricted implementations have often failed due to a mismatch between what the clients want to do and what the profile does.

Ted asks if this is something we could accomplish by declaring these as different "XCAP applications" (AUIDs) .

Henning suggests a compromise possibility. Perhaps these "profiles" constitute a recommended set of operations that clients should stick to that would be "efficient" on the server, and that if clients step back to the more complex operations, it might be reasonable to do the "full functions" via a slower, brute force manner.

Adam notes that the server functionality is not lost in absolute terms with these profiles, but might require the client to send a larger data set in order to meet the function.

Poll: is it worth exploring XCAP ideas relating to depth restriction on servers? The result was declared inconclusive by the chairs.

Topic: Resource Information List

led by Rocky Wang

Slides presented

General idea is on providing a mechanism for informing watchers about partial subscription satisfaction.

Chair encourages participants to read this draft.

Noted that there is a privacy consideration raised by revealing the information that a watcher is not allowed to see, and that any future revision will need to explore this issue

Topic: PIDF Connections

Led by Jussi Ala-Kurikka

Slides presented

Attempts to describe relative cost to correspondent of exercising a particular device tuple as described in PIDF.

Jonathan suggests that the draft provides useful assistance in tuple selection. He cautions that trying to express the absolute cost is likely to cause problems. he would like to add this as a WG item, but would prefer to defer it until more of the current work is finished.

Henry notes that there seems to be some overlap between this work and lower-layer efforts at layer 2, and that the draft is timely.

Robert (not as chair) thinks that the draft is interesting and that the authors should resist the temptation to over-extend the information expressed. However, he would prefer not to offer the draft for adoption by the WG at this time.

Henning notes that the access-network bandwidth is often not the limiting factor. he thinks the useful information can be presented as one bit for "costs this user" and a few more for order-of-magnitude ranges on bandwidth.