Approval announcement
Draft of message to be sent after approval:
Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)' to Informational RFC (draft-ivov-xmpp-cusax-09.txt)
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/
Ballot Text
(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.