summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6502.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6502.txt')
-rw-r--r--doc/rfc/rfc6502.txt787
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc6502.txt b/doc/rfc/rfc6502.txt
new file mode 100644
index 0000000..47fee1c
--- /dev/null
+++ b/doc/rfc/rfc6502.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) G. Camarillo
+Request for Comments: 6502 Ericsson
+Category: Standards Track S. Srinivasan
+ISSN: 2070-1721
+ R. Even
+ Gesher Erove Ltd
+ J. Urpalainen
+ Nokia
+ March 2012
+
+
+ Conference Event Package Data Format Extension
+ for Centralized Conferencing (XCON)
+
+Abstract
+
+ This document specifies the notification mechanism for XCON
+ (centralized conferencing). This mechanism reuses the SIP (Session
+ Initiation Protocol) event package for conference state.
+ Additionally, the notification mechanism includes support for the
+ XCON data model and for partial notifications.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6502.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 1]
+
+RFC 6502 XCON Event Package March 2012
+
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 2]
+
+RFC 6502 XCON Event Package March 2012
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................4
+ 3. Notification Formats ............................................5
+ 4. Full Notifications ..............................................5
+ 4.1. Backwards Compatibility ....................................5
+ 5. Partial Notifications ...........................................6
+ 5.1. Generation of Partial Notifications ........................6
+ 5.2. Processing of Partial Notifications ........................7
+ 5.3. Partial Notification Format ................................8
+ 5.4. XML Schema for Partial Notifications .......................8
+ 5.5. Examples ...................................................9
+ 6. IANA Considerations ............................................10
+ 6.1. MIME type Registration:
+ application/xcon-conference-info+xml ......................10
+ 6.2. MIME type Registration:
+ application/xcon-conference-info-diff+xml .................11
+ 6.3. URN Sub-Namespace Registration:
+ xcon-conference-info-diff .................................12
+ 6.4. XML Schema Registration ...................................12
+ 7. Security Considerations ........................................12
+ 8. References .....................................................13
+ 8.1. Normative References ......................................13
+ 8.2. Informative References ....................................13
+
+1. Introduction
+
+ The XCON (Centralized Conferencing) framework [RFC5239] defines a
+ notification service that provides updates about a conference
+ instance's state to authorized parties using a notification protocol,
+ as shown in Figure 1. This document specifies how to use the SIP
+ (Session Initiation Protocol [RFC3261]) event package for conference
+ state defined in [RFC4575] as a notification protocol between a
+ client and a conference's notification server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 3]
+
+RFC 6502 XCON Event Package March 2012
+
+
+ ...........................
+ . Conferencing System .
+ . .
+ . +--------------+ .
+ . | Conf. object | .
+ . | | .
+ . +--------------+ .
+ . | .
+ . v .
+ . +------------+ .
+ . |Notification| .
+ . |Service | .
+ . +------------+ .
+ . ^ .
+ ..........|................
+ |
+ | Notification
+ | Protocol
+ |(notifications following the
+ | XCON data model)
+ |
+ ..........|............
+ . v .
+ . +------------+ .
+ . |Notification| .
+ . | Client | .
+ . +------------+ .
+ . .
+ . Conferencing Client .
+ .......................
+
+ Figure 1: Notification service and protocol in the XCON architecture
+
+ In addition to specifying the SIP event package for conference state,
+ [RFC4575] specifies a data format to be used with the event package.
+ The XCON data model [RFC6501] extends that format with new elements
+ and attributes so that the extended format supports more
+ functionality (e.g., floor control). The notification protocol
+ specified in this document supports all the data defined in the XCON
+ data model (i.e., the data originally defined in [RFC4575] plus all
+ the extensions defined in [RFC6501]) plus a partial notification
+ mechanism based on XML patch operations [RFC5261].
+
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+
+
+Camarillo, et al. Standards Track [Page 4]
+
+RFC 6502 XCON Event Package March 2012
+
+
+3. Notification Formats
+
+ In order to obtain notifications from a conference server's
+ notification service, a client subscribes to the 'conference' event
+ package at the server as specified in [RFC4575]. Per [RFC4575],
+ NOTIFY requests within this event package can carry an XML document
+ in the "application/conference-info+xml" format. Additionally, per
+ this specification, NOTIFY requests can also carry XML documents in
+ the "application/xcon-conference-info+xml" and the "application/
+ xcon-conference-info-diff+xml" formats.
+
+ A document in the "application/xcon-conference-info+xml" format
+ provides the user agent with the whole state of a conference
+ instance. A document in the "application/
+ xcon-conference-info-diff+xml" format provides the user agent with
+ the changes the state of the conference instance has experienced
+ since the last notification sent to the user agent.
+
+4. Full Notifications
+
+ Subscribers signal support for full notifications by including the
+ "application/xcon-conference-info+xml" format in the Accept header
+ field of the SUBSCRIBE requests they generate. If a client
+ subscribing to the 'conference' event package generates an Accept
+ header field that includes the MIME type "application/
+ xcon-conference-info+xml", the server has the option of returning
+ documents that follow the XML format specified in [RFC6501] and are
+ carried in "application/xcon-conference-info+xml" message bodies.
+
+4.1. Backwards Compatibility
+
+ Conference servers that implement the SIP event package for
+ conference state and support the "application/
+ xcon-conference-info+xml" MIME type MUST also support the
+ "application/conference-info+xml" MIME type. This way, legacy
+ clients, which only support "application/conference-info+xml", are
+ able to receive notifications in a format they understand.
+
+ Clients that implement the SIP event package for conference state and
+ support the "application/xcon-conference-info+xml" MIME type SHOULD
+ also support the "application/conference-info+xml" MIME type. This
+ way, these clients are able to receive notifications from legacy
+ servers, which only support "application/conference-info+xml", in a
+ format they understand.
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 5]
+
+RFC 6502 XCON Event Package March 2012
+
+
+5. Partial Notifications
+
+ The conference state reported by this event package may contain many
+ elements. When the "xcon-conference-info+xml" format is used and
+ there is a change in the state of an element, the server generates a
+ notification with the whole conference state. Generating large
+ notifications to report small changes does not meet the efficiency
+ requirements of some bandwidth-constrained environments. The partial
+ notifications mechanism specified in this section is a more efficient
+ way to report changes in the conference state.
+
+ The SIP event package for conference state defined a partial
+ notification mechanism based on <state> elements. Servers compliant
+ with this specification MUST NOT use that partial notification
+ mechanism. Instead, they MUST use the mechanism specified in this
+ section.
+
+ Subscribers signal support for partial notifications by including the
+ "application/xcon-conference-info-diff+xml" format in the Accept
+ header field of the SUBSCRIBE requests they generate. If a client
+ subscribing to the 'conference' event package generates an Accept
+ header field that includes the MIME type "application/
+ xcon-conference-info-diff+xml", the server has the option of
+ returning documents that follow the XML format specified in
+ Section 5.4 and are carried in "application/
+ xcon-conference-diff-info+xml" message bodies.
+
+5.1. Generation of Partial Notifications
+
+ Once a subscription is accepted and installed, the server MUST
+ deliver full state in its first notification. To report full state,
+ the server MUST set the Content-Type header field to the value
+ "application/xcon-conference-info+xml".
+
+ In order to deliver a partial notification, the server MUST set the
+ Content-Type header field to the value "application/
+ xcon-conference-info-diff+xml". When the server generates a partial
+ notification, the server SHOULD only include the information that has
+ changed compared to the previous notification. It is up to the
+ server's local policy to determine what is considered as a change to
+ the previous state.
+
+ The server MUST construct partial notifications according to the
+ following logic: all the information that has been added to the
+ document is listed inside <add> elements. All information that has
+ been removed from the document is listed inside <remove> elements,
+ and all information that has been changed is listed under <replace>
+ elements.
+
+
+
+Camarillo, et al. Standards Track [Page 6]
+
+RFC 6502 XCON Event Package March 2012
+
+
+ The server MUST NOT send a new NOTIFY request with a partial
+ notification until it has received a final response from the
+ subscriber for the previous one or the previous NOTIFY request has
+ timed out.
+
+ When the server receives a SUBSCRIBE request (refresh or termination)
+ within the associated subscription, it SHOULD send a NOTIFY request
+ containing the full document using the 'application/
+ xcon-conference-info+xml' content type.
+
+ If the server has used a content type other than 'application/
+ xcon-conference-info+xml' in notifications within the existing
+ subscription and changes to deliver partial notifications, the server
+ MUST deliver full state using the 'application/
+ xcon-conference-info+xml' content type before generating its first
+ partial notification.
+
+5.2. Processing of Partial Notifications
+
+ When a subscriber receives the first notification containing full
+ state in a 'application/xcon-conference-info+xml' MIME body, the
+ subscriber MUST store the received full document as its local copy.
+
+ When the subscriber receives a subsequent notification, the
+ subscriber MUST modify its locally stored information according to
+ the following logic:
+
+ o If the notification carries an 'application/
+ xcon-conference-info+xml' document, the subscriber MUST replace
+ its local copy of the document with the document received in the
+ notification.
+
+ o If the notification carries an 'application/
+ xcon-conference-info-diff+xml' document, the subscriber MUST apply
+ the changes indicated in the received 'application/
+ xcon-conference-info-diff+xml' document to its local copy of the
+ full document.
+
+ If the subscriber encounters a processing error while processing an
+ 'application/xcon-conference-info-diff+xml' encoded document, the
+ subscriber SHOULD renew its subscription. A subscriber can fall back
+ to normal operations by not including the "application/
+ xcon-conference-info-diff+xml" format in a new SUBSCRIBE request.
+
+ If the server changes the content type used in notifications within
+ the existing subscription, the subscriber MUST discard all the
+ previously received information and process the new content as
+ specified for that content type.
+
+
+
+Camarillo, et al. Standards Track [Page 7]
+
+RFC 6502 XCON Event Package March 2012
+
+
+5.3. Partial Notification Format
+
+ An xcon-conference-info-diff document is an XML
+ [W3C.REC-xml-20081126] document that MUST be well-formed and SHOULD
+ be valid. The namespace URI for the <conference-info-diff> root
+ document element is defined in [RFC6501]:
+
+ urn:ietf:params:xml:ns:xcon-conference-info
+
+ The root document element <conference-info-diff> has a single
+ mandatory attribute, "entity". The value of this attribute is the
+ conference object identifier (XCON-URI) that identifies the
+ conference being described in the document.
+
+ The content of the <conference-info-diff> element is an unordered
+ sequence of <add>, <replace>, and <remove> elements followed by
+ elements from other namespaces for the purposes of extensibility.
+ Any such unknown elements MUST be ignored by the client. The <add>,
+ <replace>, and <remove> elements can contain other extension
+ attributes than what are defined in the corresponding base types of
+ [RFC5261].
+
+5.4. XML Schema for Partial Notifications
+
+ This is the XML schema for the "application/
+ xcon-conference-info-diff+xml" data format. The
+ "urn:ietf:params:xml:schema:xml-patch-ops" schema is defined in
+ [RFC5261].
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <xs:schema
+ targetNamespace="urn:ietf:params:xml:ns:xcon-conference-info"
+ xmlns="urn:ietf:params:xml:ns:xcon-conference-info"
+ xmlns:xs="http://www.w3.org/2001/XMLSchema"
+ elementFormDefault="qualified">
+
+ <!-- include patch-ops type definitions -->
+ <xs:include
+ schemaLocation="urn:ietf:params:xml:schema:patch-ops"/>
+ <!-- partial updates -->
+ <xs:element name="conference-info-diff">
+ <xs:complexType>
+ <xs:sequence minOccurs="0" maxOccurs="unbounded">
+ <xs:choice>
+ <!-- add some content -->
+ <xs:element name="add">
+ <xs:complexType mixed="true">
+ <xs:complexContent>
+
+
+
+Camarillo, et al. Standards Track [Page 8]
+
+RFC 6502 XCON Event Package March 2012
+
+
+ <xs:extension base="add">
+ <xs:anyAttribute processContents="lax"/>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+ </xs:element>
+ <!-- remove some content -->
+ <xs:element name="remove">
+ <xs:complexType>
+ <xs:complexContent>
+ <xs:extension base="remove">
+ <xs:anyAttribute processContents="lax"/>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+ </xs:element>
+ <!-- replace some content -->
+ <xs:element name="replace">
+ <xs:complexType mixed="true">
+ <xs:complexContent>
+ <xs:extension base="replace">
+ <xs:anyAttribute processContents="lax"/>
+ </xs:extension>
+ </xs:complexContent>
+ </xs:complexType>
+ </xs:element>
+ <!-- allow extension elements from other namespaces -->
+ <xs:any namespace="##other" processContents="lax"/>
+ </xs:choice>
+ </xs:sequence>
+ <xs:attribute name="entity" type="xs:anyURI" use="required"/>
+ <xs:anyAttribute processContents="lax"/>
+ </xs:complexType>
+ </xs:element>
+ </xs:schema>
+
+5.5. Examples
+
+ The following is an 'application/xcon-conference-info-diff+xml'
+ partial update document:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <conference-info-diff
+ xmlns="urn:ietf:params:xml:ns:xcon-conference-info"
+ entity="conference123@example.com">
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 9]
+
+RFC 6502 XCON Event Package March 2012
+
+
+ <add
+ sel="*/users/allowed-users-list"> <target
+ uri="sip:john@example.com" method="refer"/>
+ </add>
+
+ <replace sel="*/conference-state/user-count/text()">5</replace>
+
+ </conference-info-diff>
+
+6. IANA Considerations
+
+ There are four IANA considerations associated with this
+ specification.
+
+6.1. MIME type Registration: application/xcon-conference-info+xml
+
+ This section registers the 'application/xcon-conference-info+xml'
+ MIME type.
+
+ MIME media type name: application
+
+ MIME subtype name: xcon-conference-info+xml
+
+ Mandatory parameters: none
+
+ Optional Parameters: Same as charset parameter application/xml as
+ specified in [RFC3023].
+
+ Encoding considerations: Same as encoding considerations of
+ application/xml as specified in [RFC3023].
+
+ Security considerations: Security considerations: See Section 10 of
+ [RFC3023].
+
+ Interoperability considerations: none
+
+ Published specification: RFC 6502
+
+ Applications that use this media type: This document type has been
+ defined to support centralized conferencing applications.
+
+ Additional Information:
+
+ Magic Number: none
+
+ File extension: .xml
+
+ Macintosh file type code: "TEXT"
+
+
+
+Camarillo, et al. Standards Track [Page 10]
+
+RFC 6502 XCON Event Package March 2012
+
+
+ Personal and email address for further information: IETF XCON
+ Working Group <xcon@ietf.org>
+
+ Intended usage: COMMON
+
+ Author/Change controller: The IETF.
+
+6.2. MIME type Registration: application/xcon-conference-info-diff+xml
+
+ This section registers the 'application/
+ xcon-conference-info-diff+xml' MIME type.
+
+ MIME media type name: application
+
+ MIME subtype name: xcon-conference-info-diff+xml
+
+ Mandatory parameters: none
+
+ Optional Parameters: Same as charset parameter application/xml as
+ specified in [RFC3023].
+
+ Encoding considerations: Same as encoding considerations of
+ application/xml as specified in [RFC3023].
+
+ Security considerations: Security considerations: See Section 10 of
+ [RFC3023].
+
+ Interoperability considerations: none
+
+ Published specification: RFC 6502
+
+ Applications that use this media type: This document type has been
+ defined to support partial notifications in centralized
+ conferencing applications.
+
+ Additional Information:
+
+ Magic Number: none
+
+ File extension: .xml
+
+ Macintosh file type code: "TEXT"
+
+ Personal and email address for further information: IETF XCON
+ Working Group <xcon@ietf.org>
+
+ Intended usage: COMMON
+
+
+
+
+Camarillo, et al. Standards Track [Page 11]
+
+RFC 6502 XCON Event Package March 2012
+
+
+ Author/Change controller: The IETF.
+
+6.3. URN Sub-Namespace Registration: xcon-conference-info-diff
+
+ This section registers a new XML namespace per the procedures in
+ [RFC3688].
+
+ URI: urn:ietf:params:xml:ns:xcon-conference-info-diff
+
+ Registrant Contact: IETF SIPPING working group <sipping@ietf.org>,
+ Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
+
+ XML:
+
+ <?xml version="1.0"?>
+ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
+ "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
+ <html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="content-type"
+ content="text/html;charset=iso-8859-1"/>
+ <title>Partial Notifications in Centralized Conferencing</title>
+ </head>
+ <body>
+ <h1>Namespace for Partial Notifications in</h1>
+ <h1>Centralized Conferencing</h1>
+ <h2>urn:ietf:params:xml:ns:xcon-conference-info-diff</h2>
+ <p>See <a href="http://www.rfc-editor.org/rfc/rfc6502.txt">
+ RFC 6502</a>.</p>
+ </body>
+ </html>
+
+6.4. XML Schema Registration
+
+ This section registers an XML schema per the procedures in [RFC3688].
+
+ URI: urn:ietf:params:xml:schema:xcon-conference-info-diff
+
+ Registrant Contact: IETF XCON working group, <xcon@ietf.org>, Gonzalo
+ Camarillo <Gonzalo.Camarillo@ericsson.com>
+
+ The XML for this schema can be found in Section 5.4.
+
+7. Security Considerations
+
+ This document specifies how to deliver notifications using the SIP
+ event package for conference state in two new formats. The fact that
+ notifications are encoded in a different format does not have
+
+
+
+Camarillo, et al. Standards Track [Page 12]
+
+RFC 6502 XCON Event Package March 2012
+
+
+ security implications. Section 8 of [RFC4575] contains security
+ considerations related to the use of the event package. Implementers
+ of the event package need to follow those considerations regardless
+ of the format used to encode their notifications.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
+ Types", RFC 3023, January 2001.
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ June 2002.
+
+ [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
+ Initiation Protocol (SIP) Event Package for Conference
+ State", RFC 4575, August 2006.
+
+ [RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch
+ Operations Framework Utilizing XML Path Language (XPath)
+ Selectors", RFC 5261, September 2008.
+
+ [RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
+ "Conference Information Data Model for Centralized
+ Conferencing (XCON)", RFC 6501, March 2012.
+
+ [W3C.REC-xml-20081126]
+ Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
+ F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
+ Edition)", World Wide Web Consortium Recommendation REC-
+ xml-20081126, November 2008,
+ <http://www.w3.org/TR/2008/REC-xml-20081126>.
+
+8.2. Informative References
+
+ [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+ January 2004.
+
+ [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
+ Centralized Conferencing", RFC 5239, June 2008.
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 13]
+
+RFC 6502 XCON Event Package March 2012
+
+
+Authors' Addresses
+
+ Gonzalo Camarillo
+ Ericsson
+ Hirsalantie 11
+ Jorvas 02420
+ Finland
+
+ EMail: Gonzalo.Camarillo@ericsson.com
+
+
+ Srivatsa Srinivasan
+
+ EMail: srivatsa.srinivasan@gmail.com
+
+
+ Roni Even
+ Gesher Erove Ltd
+ 14 David Hamelech
+ Tel Aviv 64953
+ Israel
+
+ EMail: ron.even.tlv@gmail.com
+
+
+ Jari Urpalainen
+ Nokia
+ Itamerenkatu 11-13
+ Helsinki 00180
+ Finland
+
+ EMail: jari.urpalainen@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo, et al. Standards Track [Page 14]
+