The IESG has approved the following document: - 'CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)' (draft-ivov-xmpp-cusax-09.txt) as Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/ (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document is requested to be published as Informational. This is the proper type of RFC as it defines no new protocol elements nor does it require any IANA registrations. This RFC type is indicated on the title page. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes suggested practices for combined use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). Such practices aim to provide a single fully featured real-time communication service by using complementary subsets of features from each of the protocols. Typically such subsets would include telephony capabilities from SIP and instant messaging and presence capabilities from XMPP. This specification does not define any new protocols or syntax for either SIP or XMPP. However, implementing it may require modifying or at least reconfiguring existing client and server-side software. Also, it is not the purpose of this document to make recommendations as to whether or not such combined use should be preferred to the mechanisms provided natively by each protocol (for example, SIP's SIMPLE or XMPP's Jingle). It merely aims to provide guidance to those who are interested in such a combined use. Working Group Summary: Was the document considered in any WG, and if so, why was it not adopted as a work item there? Was there controversy about particular points that caused the WG to not adopt the document? Per the RAI area process for new work, this document has been reviewed in the DISPATCH WG. The DISPATCH WG does not progress any documents as WG documents. The DISPATCH WG selects one the following actions for contributions to the WG that have been adequately reviewed and discussed: - None in the case of work items for which there is inadequate interest or feedback indicates that the work should not be progressed (e.g., it's a bad idea or not within scope for RAI area or IETF) - New work item in currently chartered WG - New WG or mini-WG in the case where the deliverable is likely a single document - e.g. a new SIP header - IETF official BoF - typically for work items that are of broad interest and potential impact within the RAI area and across areas. - Individual/AD sponsored - for items limited in scope and applicability Individual/AD sponsored was the consensus of the DISPATCH WG for this document and the AD(s) agreed to progress the document. There was no controversy around this decision. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This document provides suggested practices for the combined usage of two existing protocols: SIP and XMPP. There are folks that support both SIP and XMPP in their products that plan to follow the practices as outlined in this document. Aaron Evans and Dan Christian Bogos both reviewed the -04 version of this document and deemed it a useful reference that they plan to follow for their implementations. Markus Isomaki reviewed the -02 version and his comments were incorporated in a subsequent revision. In addition, other experts/implementers have reviewed the document as described in the Acknowledgement section of the document. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Mary Barnes (DISPATCH WG co-chair) is the Document Shepherd. Gonzalo Camarillo is the Responsible AD.
