IETF-84 DISPATCH WG minutes (MONDAY, 15:40-17:10) =================================================== - Summary by chairs (Mary Barnes, Cullen Jennings) - Detailed notes by Ben Campbell and Keith Drage appended below. Summary: The WG discussed Client-side SIP+XMPP combination proposal.(draft-ivov-xmpp-cusax) Conclusions: ------------ There was positive support in the room for the this work to proceed in the IETF as an informational draft in the form of "An example deployment integrating XMPP and SIP". The scope should be limited and usage clearly specified. The document makes no changes to SIP or XMPP. The ADs will decide the best way to dispatch (e.g., RAI AD sponsored, APP AD sponsored). ===================== Notes by Ben Campbell ===================== --- Client-Side-SIP-and-XMPP Emil Ivov -- Discussion: Ben: looking through the draft, I get the impression that it's 90% about user experience. However, what we need to work on in the IETF is interoperability Presenter: Every time someone wants to build this, we end up having to explain and argue what the best behavior is. Having an advisory document is useful. Ben: But that's about user experience. Presenter: No, that's about behavior. For example, if you want XMPP clients to call your SIP address, you just put it in your vcard. Ben: So, to put my comment on it, what I see is advice on application design, which isnt' our strength. Mary: So where does this get done? Ben: It's not standards impacting. I can see it maybe as a BCP, but it doesn't really have that wide of applicability. Mary: So what venue? Ben: I'm not sure it has one. Cullen: Right now, it's informational, not BCP.  Does it make sense to say that clients with both capabilities that are configured in a certain way will have these properties? Ben: Perhaps. It's not clear whether we need to have it worked on in a working group. Paul K: Did I see INVITEs with two contacts? Paul: Doesn't think you can have multiple contacts in an INVITE. Can't find where it says that. People trying to find the language. Bernard: Already doing both, doesn't feel confused about this, not sure he needs this sort of advice. Doesn't want operational guidance that says you can't do something. What is the value that this draft can provide that doesn't limit implementation flexibility. Emil: Depends on the audience Bernard: Different clients do this very differently for different application. No one right way to do it. Emil: Closest thing we can find to standard Bernard: All the implementations he has seen are standardized, but different. Emil: Wonders how to address Bernards questions Bernard: Advice not needed for interoperability, the advice doesn't fit everyone's design points. Emil: Target audience is people using standard XMPP and SIP, here's advice on how to do it. Bernard: Lots of companies already do this, and may not agree with the device. Fluffy: MS, Google, and Apple already do this. None of them do it this way (or the same way). Chris Christou: What about presence mapping. Could be interop issue there. Marcus: This shows a way it can be done. Don't want give strict advice. Keith Drage: Everything I here says "individual submission" (clarify: AD sponsored) Gonzalo: Doesn't care how we do it if we decide to, just decide if it's a good idea. Hadriel: Doesn't a contact header go to sipcore? Mary: Not a new header. Hadriel: What does it mean in dialog packages? How does it affect routing? Paul K and room: Multiple contacts in INVITE won't work even if it's legal. Fluffy: Don't worry about the details of the contact header--worry about where there's interest in working on the problem. Fluffy: would anyone else be willing to author this if there was no draft? [Ben objects to question] Hum Request: Who's willing to work on this? [4-5, plus 3 authors) Gonzalo: Heard multiple people object. Fluffy: Would people object to an informational that skins the cat in a way they don't like? Bernard: If it's well scoped RjS: Would the authors be willing to scope this to an example of a working implementation? Chris: Can we work on presence mapping? Does that need to be a separate document? Emil: No presence mapping was part of their simplification. The only mapping they have is to allow the SIP system to send presence info over XMPP Consensus call: Who would support an document showing an example document, scope limited to example, does not extend or violate SIP or XMPP. Ben: We should ask people in XMPP to look at this. Hum canceled by AD (Gonzalo). We have information about scope, no opposition at this scope, known energy level. Dispatch to ADs. Meeting Adjourned. ====================== Notes by Keith Drage ====================== 15:40 start Chairs  Status and agenda bash ---------------------------------- http://www.ietf.org/proceedings/84/slides/slides-84-dispatch-0.ppt Note well No bashing CUSAX: Combined Use of SIP and XMPP ------------------------------------ draft-ivov-xmpp-cusax-01 Emil Ivov presenting (eventually) Slides: http://www.ietf.org/proceedings/84/slides/slides-84-dispatch-1.pdf Slide 1 Slide 2: CUSAX: Why? Slide 3: CUSAX: What? Slide 4: CUSAX Approach Slide 5: CUSAX: Matching JIDs to AORs Cullen: RFC 4770 tells you how to put these into a vcard. Slide 6: CUSAX: Matching JIDs to AORs Slide 7: CUSAX: Related Work Slide 8: CUSAX: Other Details Slide 9: CUSAX: Example Deployment Slide 10: CUSAX: Open Issues Slide 11: CUSAX: Open Issues Slide 12: CUSAX: Combined Use of SIP and XMPP draft-ivov-xmpp-cusax Ben Campbell: Reckons this is a draft that is 90% about user experience. Not very much about interoperability. What does the IETF need to solve? Why do we need a standard? Presenter: Find oneself having to explain the best behaviour. Having an advisory document is what we need. For example if want xmpp clients call sip address for contacts then put in vcard but there are other ways people may do this. Ben: So this is only advice on implementation design. Chair: Class of document that is operational advice. Informational not BCP. Ben: Possible individual rather than working group. Paul K.: Invite with two contacts? Can do for REGISTER but not others. Think is illegal but cannot find text. Bernard: Lot of provisioning related info, but otherwise should not limit implementation flexibility. Doesn't know that there is only one way of doing this. Cullen: Microsoft, Apple and Cisco all have products that do both SIP and XMPP and none of them do it this way Bernard: and if they are interoperating what is the problem. Chris: Identified potential interop issue. Marcus Isomaki: Maybe value is just to show that this can be done. Maybe not be too strict on the advice. Keith Drage: AD sponsored individual. Hadriel: If putting in Contact header then would that not be SIPCORE. Paul K: Can only put SIP or SIPS URIs as contacts when making dialog establishing request. Whether more than one is not definitive. Chairs: Asked who would be willing to put effort into writing a document. Review a document etc. 4/5 might be interested to review. Chairs do not believe we are chartering a working group. Bernard: No ojection providing it is clear who the audience is and that it is not generally applicable. Robert: If scope that said "example deployment for such and such"? Presenter: Yes. ????: Question about presence mapping. Back to reference slide 9. Chairs: consensus call: Who would support a document for example deployment with scope clearly identified as to what it is limited to. Informational. Defines no new protocol elements. Ben: As XMPP chair. Expertise of SIP and XMPP needed. Chairs: AD would want expert review and may well ask both camps. ADs think they have enough information to process. Gonzalo took action point. Conclusion: Dispatched to ADs. Meeting closed: 16:27.