XCON Minutes IETF-71 Minute Taker: Dave Morgan Comments from the Chairs: Agenda Bash - none * The XCON framework document is in to the RFC editor, but encountered a "speed bump" with new reviewer assigned * Who thinks the data model is ready for WGLC? One person abstained. Preference is to have it go to WGLC and then park it there. Intention is to "freeze it" unless there's a strong and compelling reason to reopen. - Oscar Novo (ON): Wants a relax NG expert to review it. - Adam Roach (AR): During WGLC we will have someone from XML directorate check it * Our primary goal for today is make a call to the group to see if the conference control protocol is ready for adoption as working group item =========================== Conference Control Protocol - Mary Barnes presenting Draft-barnes-Xcon-ccmp-04 Summary: Mary opened the discussion by reviewing the changes from -03 and noting that the document has been expanded. She then asked the group to comment on an open issue regarding what approach to use for partial updates of the schema. Option 1 is to use a model that would allow discrete operations (commonly called the semantic approach). Option 1 has the advantage of deploying a small subset of operations which would keep this simple. Option 2 would use an existing protocol for XML schema updates (the syntactic approach). Option 2 has the advantage that we may be able to reuse a protocol stack, but we may inherit a lot of functionality we may not need. Several people approached the mic to make comments including Adam Roach, Dave Morgan, Lisa Dusseault, Henning Schulzrinne and Gonzalo Camarillo. The working group's previous foray into this area came up and Gonzalo reminded us that we had evaluated XCAP in an XCON CCCP draft but that didn't gain consensus in the group although XCAP is being used elsewhere. Dave and Lisa brought up some of the advantages of option 1 and purpose-built operations. Henning argued that some of the problems with option 2 are that when something goes wrong the error messages that some XML parsers spit back are "XML invalid on line 42." He wants to avoid this. Adam asked if there was any support for option 2. There was none. He noted for the record that he strongly supports option 1. ** Resolution: We move forward with option 1 in the CCMP draft. Mary then asked to add this as a working group item. Adam asked for a show of hands and there were only a few. Mary made the point that adopting the document gives people the opportunity to provide more input. Henning noted that we aren't considering any other conference control protocols now and that adopting this would probably preclude us from adopting others. Adam asked for a show of hands on who was opposed to adopting. There were none. ** Resolution: This was agreed to be adopted as a working group item =========================== Event Package - Gonzalo Camarillo presenting Draft-ietf-Xcon-event-package-00 Summary: Gonzalo started by summarizing the last meeting where this was adopted as a working group item. He noted he had picked up this draft from Sre Srinivasan. In the last meeting there was a lot of discussion on how this would be reconciled with the notification package of RFC 4745. Gonzalo reviewed the proposed mime type xcon-conference-info-diff+xml Which is based on relax NG. This allows diffs to be done using XML patch notifications. Consequently we won't be using the state elements for partial notifications that are employed in 4575. This means that an XCON conference would have to support two mine times, one for the elements defined in 4575 and one for xcon-conference-info-diff. This started a discussion at the mic with Adam, Sre, Mary, Roni Evan, and Lorenzo Miniero. Sre was concerned about backward compatibility to 4575. Gonzalo reiterated that there wouldn't be backwards compatibility because we are introducing a new mime type. You'll have to implement both notification methods. This will be new code that will work against the XCON data model. Sre asked if these patch operations for differences have been used in other areas. Gonzalo same they have been used in the Presence WG and other areas. He was aware that Nokia had an implementation and mentioned that it can be applied to any XML schema. Sre confirmed this is the right way forward but it makes it harder to implement. Roni stated he was under the impression that the server needs to respond to both this and 4575. Gonzalo confirmed that's the case because of the separate mime type. Adam chimed in that you're required to support 4575 in conferencing and if you want to support the XCON model you need to support this event package. As far as our working group's charter, we are not chartered to maintain functionality but to add functionality. Sre wanted to know if this means we can't define extensions to 4575. Gonzalo countered that we would have to extend 4575. Lorenzo then brought up the point that the patch operation recreates the conference object and the client has to parse a large XML each time there is an update. Gonzalo said the trade-off is that you either get the whole conference object or in the case of patch you know which parts have changed, such as just the user part, so you only parse that. It is an optimization. This seemed to satisfy the people who came to the mic. ** Resolution: Event notification draft will continue to use XML patch notifications. Dan York then brought up the point that this draft and the previous control protocol draft needs more expository text on when and why you would use this protocol and examples of the different conference notification states. Gonzalo said that was a fair comment. He asked Dan to provide three bullets - examples of things that should be expanded. Miguel Garcia then stated that this applies to the data model as well, not just these two drafts. Adam chimed in saying that would be useful, but these examples are in the framework document. Adam then stated that this draft is tied tightly to the data model and they should be submitted together. ** Action Item: Gonzalo to update the document with use cases. ================== Chat in Centralized Conferencing - Mary Barnes presenting IM Draft-boulton-Xcon-session-chat-01 Summary: Mary started by saying that text chat is a good use case for XCON. The intent is for the chat in centralized conferencing to be agnostic to the chat client. The current use cases in the framework document were voice and video. The framework didn't mention chat, although it did talk about media in sidebars. She said this draft is related to the efforts in Simple and related to MSRP. There was a lot of discussion at the mic with Miguel Garcia, Simon Romano, Adam and Mary. Miguel noted there was significant overlap with a draft in Simple and the documents need to be synchronized. Mary responded that this draft better addresses things like logging mechanisms and anonymous users and nicknames and that she's careful about clarifying why this is different. Miguel responded that this is only going to confuse implementers. Adam clarified that this work is not on the XCON charter. We will evaluate it after we are done with our deliverables. However, it is on the Simple charter. But Simple provides a point solution with less complexity. Mary's doc is showing how this is performed with the tools defined in XCON. Miguel then countered that Simple is discussing the connection between the nickname and media. Mary then clarified that this is not intended to be a standards track document. Adam added that this document is saying the mechanism exists in XCON to meet multi-user chat requirements. Mary added that we didn't develop the detailed call flows because the XCON protocols were not completed. This document will show how it will work when we have the protocols. It's basically another use case. We have finished the framework document and we didn't include this use case. Miguel was still concerned that there are two documents addressing the same problem with slightly different functionality. Miguel suggested that the delta in functionality should just be put in the framework document. Mary objected because that document is completed. Simon then weighed in with Miguel saying his team implemented XCON moderated chat very easily. He didn't see a need to justify writing a separate draft for this. Mary responded that she was happy to park this until the protocols are done. Adam interjected that the intent of this document was to organize thoughts on this topic. Dan York then brought up that the document doesn't talk about reusing existing protocol mechanisms for chat conferencing. For example XMPP has some of these elements specified. Mary responded that XCON can use XMPP because it's protocol agnostic. Adam then mentioned that this is how you would manipulate media in an XCON conference from both XMPP and SIP protocols. He expects that clients that use XCON for other media would have a consistent experience as compared with someone using a protocol-specific solution. Dan asked if people were developing XCON systems. Adam said yes. Mary then addressed the issue of nicknames. She suggested we follow the model for XCON user ID and follow the same model for persistence. She said we can implement a default user name - perhaps the XCON user ID. This is defined as a URI in the data model. Maybe we can put some text in data model to explicitly call out nicknames. ** Action Item: Mary will put some call flows into the document as the protocols are developed (she's looking for someone to help her). ** Resolution: This will be picked up again at the next meeting. Adam wrapped up the meeting by saying we're close to the end. He's looking forward to shutting down the group and declaring success. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ VERBATIMS: XCON Agenda bash - Adam XCON framework into RFC editor, at a speed bump with new reviewer Data model who thinks it's ready for WGLC, one person abstained, may go to WGLC and then park it, freeze it unless strong and compelling reason to reopen Oscar Novo (ON): wants a relax NG expert to check it Adam Roach (AR): During last call will have someone from XML group check it Goal for today is Conference control protocol, make a call to the group to see if it's ready for adoption as working group item Mary Barnes (MB) CCMP, conference control protocol Version -04 From -03 made a number of changes (slides) Significantly more complete doc Partial updates, two approaches, Option 1, use a model with more discrete changes Option 2 Use an existing XML protocol - may not be ideal fit - may inherit functions you may not use AR: strongly suggest option 1 Dave Morgan (DM): - be consistent with Gonzalo's event notification syntax which uses XML patch MB: has to be request/ response protocol that only sends model changes Lisa Dusseault (LD): - along with XCAP, another approach is to send an HTTP patch and put a diff in the body, purpose built doc with syntax to change. Need special purpose instructions for making changes/patches AR: what is Lisa arguing for? MB: (to Henning) sounds like people in favor of option 1 Gonzalo Camarillo GC: group had XCAP approach - CCCP, OMA made changes and are using. They have XCAP-like changes, Henning Schulzrinne (HS): problem with Option 2 is when something is wrong it spits back an error message with some XML - XML invalid on line 42. Wants to avoid this. AR: - that matches his recollection, any support for option 2 - No - let's go forward CONSENSUS - Adopt option 1. MB: wants to add as work group item AR: should we adopt, show of hands (only a few) MB: adoption gives people more input HS: wouldn't be considering another Conf control protocol if we adopt this AR: who supports adopting doc - a few, no one against CONSENSUS adopt as WG item =========================== Gonzalo Event Package Adopted as WG item in last meeting Concluded we want a new mime time based on relax NG Second issue, how we wanted to do partial notifications, 4575 uses a state element to keep full state or partial Defines two mime times Relax NG allows patch notifications, allows for changes Allan - typo on slides needs XCON-conference Gonzalo has a few nits. AR: thoughts using patch ops for diff ops (XML patch operation) Sree Srinivasan (SS): what about backward compatible GC: no, it's not going to be compatible, we have a new mime time SS: will it support 4575 and this GC: this is an optional mechanism, you'll have to implement both notifications, you will need new code to fill the XCON data model SS: the right way forward, but if you have 4575, it's harder to implement this GC: SS: the XML patch - have they been used GC: yes in presence and other WG SS: who has implemented them GC: I know Nokia has an implementation. You can apply to any XML schema Roni Evan (RE): under impression server needs to respond to this and 4575. GC: yes that's the case. RE: does it have to support it MB: trying to clear up confusion GC: we're using a different mime type you have to support it AR: you're required to support 4575, this is optional but if you want to support the XCON data model you need to support this event package SS: question of backwards compatibility AR: not part of our charter to maintain, part of charter to add functionality SS: - does this mean you can't define extensions to 4575 GC: you would have to extend 4575 Lorenzo Miniero (LR): The creates updated version on the client side - would this force client to parse large XML each time (updates) because patch recreates conf object GC: option 1 get the whole conference or option 2 you get a patch and you have to do the operation, you know which parts have changed, user part hasn't changed so you don't have to parse it, so this is an optimization Dan York (DY): editorial content - with this and Mary's draft concern is needs more expository text on why this would be used, explain why you would use this protocol. What are diff conf notification states. GC: that's a fair comment, give me three bullets, I'd like you to expand on a b c Miguel Garcia (MG): I think that comment goes to the data model, not just these 2 AR: this would be useful - it's in the framework, Action - GC to update with use cases GC: small draft "says nothing" next steps? AR: tightly tied to data model we should put them in at same time. ================== Mary IM session in XCON MB: Related to simple, related to MSRP, took MSRP out of title Use cases were voice and video. Text based chat a good use case for XCON, Intent is to have no impact on IM clients, not specify a chat protocol, be agnostic Framework supports sidebars MG: don't understand this doc, significant overlap with the one in simple, need to synchronize docs MB: yes, not a lot to add to support this. We don't have the problem of anonymous and nicknames, doc is careful about clarifying why this is different MG: If I'm an implementer I'm confused AR: we were going to do in XCON or simple or just XCON. This is not on charter. We will do after done with other things. On the simple charter. Simple has a point solution with less complexity. Mary's docs are showing how to do it with tools we defined MB: this spans conferencing system, more functionality in XCON, Mary, this is MG: we discussed in Simple about nickname being applicable to media MB: this is not standards track doc, but we don't have MSRP AR: this doc says the mechanism exists, meets multi-user chat reqs MB: don't have detail call flows because we didn't have protocols. This doc shows how it will work when we have protocols - this is another use case, your doc won't supply to XCON. We finished XCON framework and didn't include it MG: in my opinion this is not resolved. We have two docs. I read earlier version MB: we have to put out a doc to discuss how to resolve it. We don't have a nickname. MB: Logging mechanism - your solution doesn't have this. Where should we put it? MG: in the framework MB: but the framework is done. This is just taking XCON framework and elaboration on how this should work Simon Pietro Romano (SR): Miguel's comment was the right one. Chat is just conferencing. They implemented XCON moderated chat in their system very easily. Don't see anything to justify writing a draft. MB: where to put the nicknames SR: that is why XCON was conceived as an agnostic protocol, don't need a separate doc AR: you're brighter than the average implementer MB: can't do anything until the protocols are done. Happy to park this until then. AR: intent of doc was to organize thoughts on this topic DY: intent is to reuse existing mechanisms. No mention of XMPP, some elements are in there MB: can use XMPP because it's protocol agnostic DY: so various parts of this are implemented already AR: true, this is how you would manipulate media in an XCON conference, can use this mechanism to manipulate both (XMPP and SIP). Expect clients that use XCON for other media would have a consistent experience than a protocol specific fashion DY: are people developing XCON systems AR: yes MB: make sure we are clear on text for nicknames. Can follow model for XCON user ID. Follow same model for persistence. Do we want a default user name - perhaps XCON user ID. It's defined as a URI in the data model. Put some text in data model on nicknames MB: will start a call flow doc with description. Will populate as protocols develop. Looking for someone to help her RESOLUTION - will be picked up again Adam - close to the end and would like to shut it down and declare success.