GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6502

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6502.txt · Last modified: 2012/03/24 17:40 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki