Cullen, Whilst neither agreeing nor disagreeing with the charter, I did not find anything in the charter that said the information had to be in the SIP header rather than in the body. On what basis do you make that deduction? John > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of Cullen Jennings > Sent: 28 June 2010 19:24 > To: iesg@xxxxxxxx > Cc: IETF Discussion Mailing List > Subject: Re: WG Review: Call Control UUI for SIP (cuss) > > > As far as I can tell, the WG says they wants to transfer some > information to achieve cross vendor interoperability. > However, what I believe the charter is actually going to do > is exactly the opposite of that. When you get your head > around what this charter is proposing, it is going to form a > more or less opaque container for transporting proprietary > information in a SIP header. It's hard to imagine how this > will help interoperability. > > If we wanted to have interoperability, the charter would say > what information needs to be transferred and have the WG > define a way to get it between systems in an operable way. > What the charter for this WG actually says they are going to > do is make a special container for transfer proprietary > information. There's not even willing to say what that > proprietary information is used for other than things ISDN > UUI which is a non interoperable and fairly proprietary > field in ISDN. Furthermore they have asserted that existing > containers such as SIP-T or SIP bodies can't be used for > reasons that are hard to describe. (I reject the idea that > because the call might not involved the PSTN, it can't use SIP-T). > > I think the folks that want to do this should get a much > clear explanation of how this results in interoperability and > why exist approach such as SIP-T will not work before this is > chartered. > > I do think there is a need to standardize some important call > control information used in call centers and related places. > However, the "we need a standard container to exchange secret > information WG" is a bad idea and violates the sprit of the > SIP change process not to mention the mission of the IETF. > > In summary, I'm in favor of figuring out what the problems > are people hope to solve with this WG and figuring out a way > to write interoperable standards to achieve that. However, I > think this charter should be rejected by the IESG and sent > back to the drawing board. The RAI area has things of higher > priority items to work on than a SIP header for transfer > proprietary data. > > > > On Jun 22, 2010, at 10:00 , IESG Secretary wrote: > > > A new IETF working group has been proposed in the Real-time > Applications > > and Infrastructure Area. The IESG has not made any > determination as yet. > > The following draft charter was submitted, and is provided for > > informational purposes only. Please send your comments to > the IESG mailing > > list (iesg@xxxxxxxx) by Tuesday, June 29, 2010. > > > > Call Control UUI for SIP (cuss) > > -------------------------------------------------- > > Current Status: Proposed Working Group > > > > Last modified: 2010-06-21 > > > > Chair(s): > > TBD > > > > Real-time Applications and Infrastructure Area Director(s): > > Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx> > > Robert Sparks <rjsparks@xxxxxxxxxxx> > > > > Real-time Applications and Infrastructure Area Advisor: > > Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx> > > > > Mailing Lists: TBD > > > > Description of Working Group: > > > > The Call Control UUI for SIP (CUSS) working group is chartered to > > define a Session Initiation Protocol (SIP) mechanism for > transporting > > call-control related user-to-user information (UUI) between User > > Agents. > > > > The mechanism developed in this working group is applicable in the > > following situations: > > > > 1. The information is generated and consumed by an application using > > SIP during session setup but the application is not necessarily > > even SIP aware. > > 2. The behavior of SIP entities that support it is not significantly > > changed (as discussed in Section 4 of RFC 5727). > > 3. Generally only the User Agent Client (UAC) and User Agent Server > > (UAS) are interested in the information. > > 4. The information is expected to survive retargeting, redirection, > > and transfers. > > 5. SIP elements may need to apply policy about passing and screening > > the information. > > 6. Multi-vendor interoperability is important. > > > > This mechanism is not applicable in the following situations: > > > > 1. The behavior of SIP entities that support it is significantly > > changed (as discussed in Section 4 of RFC 5727). > > 2. The information is generated and consumed at the SIP layer by SIP > > elements. > > 3. SIP elements besides the UAC and UAS might be interested in > > consuming (beyond applying policy) the information. > > 4. There are specific privacy issues involved with the information > > being transported (e.g., geolocation or emergency-related > > information). > > > > User data of the mechanism will be clearly marked with the > > application, encoding, semantics, and content type, > allowing policy to > > be applied by UAs. The working group will define the > information that > > each application must specify to utilize the mechanism. This type of > > application-specific information will be specified in > standards-track > > documents. > > > > One important application of this mechanism is interworking with the > > ISDN User to User Information Service. This application defined by > > ITU-T Q.931 is extensively deployed in the PSTN today > supporting such > > applications as contact centers, call centers, and automatic call > > distributors (ACDs). A major barrier to the movement of these > > applications to SIP is the lack of a standard mechanism to transport > > this information in SIP. For interworking with ISDN, minimal > > information about the content of the UUI is available to > the PSTN-SIP > > gateways. In this case only, the content will just > indicate ISDN UUI > > Service 1 interworking rather than the actual content. > > > > Call control UUI is user information conveyed between user agents > > during call control operations. As a result, the > information must be > > conveyed with the INVITE transaction, and must survive proxy > > retargeting, redirection, and transfers. The mechanism > must utilize a > > minimum of SIP extensions since it will need to be supported by many > > simple SIP user agents such as PSTN gateways. The mechanism must > > interwork with the existing ISDN service but should also be > extensible > > for use by other applications and non-ISDN protocols. > > > > Even though interworking with the PSTN is an important requirement, > > call control UUI can be exchanged between native SIP clients that do > > not have any ISUP support. Therefore, existing SIP-T > > encapsulation-based approaches defined in RFC3372 do not meet the > > requirements to transport this type of information. > > > > Mechanisms based on the SIP INFO method, RFC2976, will not be > > considered by the working group since the UUI contents carry > > information that must be conveyed during session setup at the user > > agent - the information must be conveyed with the INVITE > transaction. > > The information must be passed with the session setup request > > (INVITE), responses to that INVITE, or session termination requests. > > As a result, it is not possible to use INFO in these cases. > > > > The group will produce: > > > > - A problem statement and requirements document for > implementing a SIP > > call control UUI mechanism > > > > - A specification of the SIP extension to best meet those > requirements. > > > > Goals and Milestones > > ==================== > > > > Sep 10 - Problem statement and requirements document to IESG > > (Informational) > > Mar 11 - SIP call control UUI specification to IESG (PS) > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf-announce > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf