Idea Transcript
Minutes : SIMPLE : IETF 68 March 22, 2007 - Thursday Afternoon I Chair: Robert Sparks Notetaker: Dean Willis Summary: * MSRP has been approved. * A technical error in the IANA registration section of the IMDN draft has been identified and corrected. The document will not be re-WGLCed. Reviewers should pay special attention to this correction during IETF last call. * There was interest in discussing IMDN for MSRP messages. Some concern was expressed over the notion of "read" vs "delivered". * The Presence SIGCOMP dictionary will progress as an AD-sponsored individual submission. Several attendees volunteered to review the document. * Some interest was expressed in exploring the use of SIP Events outside the realm of real-time communications. Henning has created a list on which to start those discussions. * The new mechanism suggestions in the Interdomain Optimization Analysis draft will be removed to a separate document. The group will focus on reviewing the model and analysis in the document with the expectation that we will last call and request publication of this draft achieving the associated milestone item before the Chicago meeting. * The attendees reconfirmed accepting neimi-chat as the basis for meeting our IM chat milestone. Conversation indicated we are making progress on providing an immediate solution that will be compatible with the long term XCON solution * There was significant pushback against optimizing MSRP by dropping To-path and From-path in Aki's MSRP-ice proposal. There was interest in continuing to discuss the remainder of the document. Raw Notes ---------------------------------Topic: Status lead: Robert Sparks Slides presented
Issue: Advanced Messaging Draft: Should we revive or let expire? Discussion indicated might depend on following conversation. Issue: OMA LS on XCAP DIFF: Meeting held yesterday. We understand issues and are working on it.
Issue: Remaining Milestones IMDN submission should occur soon. Adam Roach will edit SIMPLE Protocol Annotated Review for Chicago Question: If SIMPLE concludes this year, where would further work go? Answer: to RAI ADs or individuals as appropriate.
Issue: IMDN Bug found in extension of cpim namespace. Corrective changes made and under review. Will submit to IESG LC if review OK.
Topic: DMDN lead: Jerry Shih Slides presented OMA SIMPLE IM is based on IETF SIMPLE IM. Presentation overviewed messaging model. Questions on Read notification for Large Message Mode slide: Henry: If we don't get an error message, we presume it has been delivered, and if we did get a notification we would be aggravated. Also people often delete messages without reading them. How do you define "being read"? Answer: Delivery notification is optional and used only if desired, so won't annoy people who don't use it. Determining if a message has been read is implementation dependent. The implication is that the message has been rendered to a user interface and acted on by a user. Discussion followed broadly. Concerns about regulatory implications were raised. Noted that IMDN has a comparable capability. Further discussion deferred by order of the chair. Questions on slide Delivery Notification for Session based Deferred Messaging Ben Campbell noted that he resisted IMDN in MSRP, because we had no explored the use cases enough to understand how it needs to work. For example, the current slides talk about delivery after an MSRP session ends, which requires deliver on an alternate path and is forbidden explicitly in the current spec. It would be good to have a broader set of use cases to make sure we get this right. Miguel Garcia noted that there is value in delivery notification and/or read notification and it should be explored, but that the use case requires clarification on when it is needed. It needs to be more session based. Noted there is a spam harvesting risk that might need to be addressed (although 200 OK may have leaked that same information). Q: do we have delayed notification, and is declining a message a UI issue? ANs: Not yet, and yes. Proposed by Dean Willis that that the OMA messaging protocol provides a session layer mechanism that spans multiple IETF protocols, and it is probably required that the OMA delivery notification mechanism operate at that same level. IETF protocols might each require a delivery notification capability, but the aggregation of this into the OMA "read" condition has to happen at an OMA layer.
Topic: Presence Specific Dictionary for SIGCOMP lead: Miguel Angel Garcia-Martin Slides presented Document "mostly ready" to ship. Recently received input to remove small (less than 4 char) entries from dictionary. Help is needed in reviewing, specifically around "priorities" (probably of use) classification for strings. This might require analyzing a large body of messages in different languages and dialects for best fit, but analysis for distribution in things like PIDF might also be very useful. Poll: Who will give feedback on this draft: 5 hands presented. Question to AD: Can this progress without a WG or should it go through here? Ans: (JonP) If you can find reviewers, AD will take as AD-sponsored individual
Topic: Vehicle Event Package lead: Henning Schulzrinne Slides presented Noted that US government application CAP uses XMPP for somehing very similar, but needs to be broadened. Issue: Previously, asynchronous events outside of presence and MWI have been considered out of scope. Options: 1) Not at all in IETF, 2) Use XMPP, 3) make a per-case decision by expertise, size, etc. 4) build a general-purpose asynch event mechanism using SIMPLE as a basis Discussion: There are a lot of examples of information sources like this in Public Safety arena, where much work has been done on formatting the messages but not on transporting them. Brian Rosen expressed strong interest in the work. Question: Why here and not SIPPING? And: SIPPING was too busy this week. Question (Adam Roach) We originally had explicit instruction from IESG about not doing a general subscription notification message system like TIBCO. Will we be receiving guidance from the IESG that the language in 3265 no longer applies, or does the guidance stand. Noted that the same concerns would apply to XMPP and the rest of RAI. Noted by Miguel Garcia that there are concepts in the drafts he is scheduled to present in SIPPING tomorrow that relate to this work. Avshalom Houri expressed interest in the work. Not sure where it should be done. Henning noted that the whole set of things we've built, including partials, diffs, filtering, etc are perfectly applicable. Issue: Group Management. Miguel's work includes concept of "Communities" that are similar and should be coordinated. AD Guidance: Original guidance is that SIMPLE is in support of human real-time communications. Noted also that event packages are "informational required" and do not have to be done only in SIMPLE/SIPPING. Poll: Interest level in room is relatively high.
Topic: SIMPLE Problem Statement lead: Avshalom Houri Slides presented
Intro by chair: Not certain that current draft universally hits the main point for the analysis required in the charter. We will need to make some decisions about how to arrange this. Note: "Numbers" slide, 5th column is messages per 8 hour day Discussion from Brian Rosen: Agreed that this shows a problem, but it would be useful to get a better handle on the size of the problem. This isn't protocol specific, it's presence-specific. Discussion from HGS: There were some papers about AT&T's network that we might could extract useful data from. But it is hard to put an upper limit on a scary number. Guidance from chair: This draft is now at the point where its model could be usefully compared to real experience. Please do so. Request from Ben Campbell: Would like to see feedback on his analysis as posted. Question from Henry Sinnreich: If you think this is the usage scenario, is this an argument that these big-load applications (like presence) should be handled in the endpoints and not the servers? Ans: maybe . . .
Issue: Optimizations Comment from HGS: Google seems to be doing something like that already. The goal is reducing load, not shifting it around. Comment from Adam Roach: There are two sets of stuff here 1) existing mechanisms 2) new mechanisms for which we have not yet done an adequate requirements analysis. The document can be split along these lines. Adam would support the further optimization work. Comment from HGS: Could also have an informational on "lazy" approaches that can be implemented in today's protocols without change. Comment from Sriram: Young users often use their presence status to communicate like a broadcast message, perhaps 3-4 times per minute. This isn't true of enterprise users, the distribution could be very large.
Topic: SIMPLE Chat draft lead: Miguel Angel Garcia-Martin Slides presented
Issue: nicknames. Discussion: In other sessions, nicknames are a property of the use, not a property of the chat. Do we need to sove this or the general prolem? Adam noted that everything we do here will apply to xcon. Aki will look through xcon data model for a way to do it, and we'll have a system-wide capability. Ben noted that we have to be careful, because once the approach is in code, the feature requirement will be there forever. That will make it hard to change over. Mary asks that we make sure what we do here is NOT the general model for xcon. Adam confirms that these features will hag around, but that would not be as bad as not having the capabilities now. in his opinion the amount of work involved is relatively small. Question from Ben: Does the draft contain motivation for doing this in media stream instead of in SIP TO DO: Find this motivation and put it in draft. Comment from ben: Doing it this way will require ability to provision both focus and mixer with nickname. Comment from Brian Rosen: Ben's comment makes sense. Don't remember any discussion of this in the past. We should make this nicknaming SIP-wide. Comment from Adam: XCON does operations towards the focus, not the mixer, so may need to look at this. Comment from Aki: We previously said that if we put this stuff in the SDP then we're negotiating both session and nickname. This requires new response codes for "nickname taken". Also not pretty to have to use a reinvite to change nicknames mid-chat. Issue: Will you work on this? Comment from Brian Rosen: Yes. Comment from Ben: Yes, and we need to analyze impact on end-to-end encryption. Comment from Henry: We must do this to be able to use SIMPLE instead of XMPP. But we need to think about how this works in a serverless environment. Comment from Brian: End-system (multicast, broadcast, many-cast) mixing can meet the serverless. Poll from chair: Do we still have consensus to keep this as a basis for a WG item to meet our charter? Ans: We have consensus on doing this work.
Topic: XCON work on MSRP conferencing lead: Mary Barnes Slides presented No discussion from room.
Topic: MSRP ICE lead: Aki Niemi Slides presented Intended as a replacement for MSRP relays. Current draft is a strawman intended to get discussion going. Issue; Dropping To-Path, From-Path Comment from Ben campbell. Would be a chore to change MSRP just to do the discard of To-path and From-Path as suggested. Would also like to see case where one end uses relay, one end uses ICE. Comment from Adam. Dropping them is much like dropping tags in SIP and breaking forking. Comment from Robert Sparks Comment from Hadriel Kaplan: This is probably too much of a change This raises the question: if you keep them, what do you put there? Issue: RFC 4571 framing. Why are we doing this in ice-tcp? Comment from Adam Roach: We probably need to do something different from 4571 because it has a length header and this messes up arbitrary chunking. We probably need to come up with yet another mechanism. Comment from Henry: This draft is very useful because it moves more things to the endpoints. We should do it. From chair: If you want to work on this: DO SO! Meeting closed.