Internet DRAFT - draft-ietf-xcon-event-package
draft-ietf-xcon-event-package
XCON G. Camarillo
Internet-Draft Ericsson
Intended status: Standards Track S. Srinivasan
Expires: March 8, 2009 Microsoft Corporation
R. Even
Polycom
J. Urpalainen
Nokia
September 4, 2008
Conference Event Package Data Format Extension for Centralized
Conferencing (XCON)
draft-ietf-xcon-event-package-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 8, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document specifies the notification mechanism for XCON
(centralized conferencing). This mechanism reuses the SIP (Session
Camarillo, et al. Expires March 8, 2009 [Page 1]
Internet-Draft XCON Event Package September 2008
Initiation Protocol) event package for conference state.
Additionally, the notification mechanism includes support for the
XCON data model and for partial notifications.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Notification Formats . . . . . . . . . . . . . . . . . . . . . 4
4. Full Notifications . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 5
5. Partial Notifications . . . . . . . . . . . . . . . . . . . . 5
5.1. Generation of Partial Notifications . . . . . . . . . . . 5
5.2. Processing of Partial Notifications . . . . . . . . . . . 6
5.3. Partial Notification Format . . . . . . . . . . . . . . . 7
5.4. XML Schema for Partial Notifications . . . . . . . . . . . 7
5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. MIME type Registration:
application/xcon-conference-info+xml . . . . . . . . . . . 9
6.2. MIME type Registration:
application/xcon-conference-info-diff+xml . . . . . . . . 10
6.3. URN Sub-Namespace Registration: consent-status . . . . . . 11
6.4. XML Schema Registration . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Camarillo, et al. Expires March 8, 2009 [Page 2]
Internet-Draft XCON Event Package September 2008
1. Introduction
The XCON (centralized Conferencing) framework
[I-D.ietf-xcon-framework] 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.
...........................
. 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 [I-D.ietf-xcon-common-data-model] extends that
format with new elements and attributes so that the extended format
Camarillo, et al. Expires March 8, 2009 [Page 3]
Internet-Draft XCON Event Package September 2008
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 [I-D.ietf-xcon-common-data-model])
plus a partial notification mechanism based on XML patch operations
[I-D.ietf-simple-xml-patch-ops].
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].
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 experimented
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
[I-D.ietf-xcon-common-data-model] and are carried in "application/
xcon-conference-info+xml" message bodies.
Camarillo, et al. Expires March 8, 2009 [Page 4]
Internet-Draft XCON Event Package September 2008
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.
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,
Camarillo, et al. Expires March 8, 2009 [Page 5]
Internet-Draft XCON Event Package September 2008
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.
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
Camarillo, et al. Expires March 8, 2009 [Page 6]
Internet-Draft XCON Event Package September 2008
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 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.
5.3. Partial Notification Format
A xcon-conference-info-diff diff document is an XML
[W3C.REC-xml-20060816] document that MUST be well-formed and SHOULD
be valid. The namespace URI for the <conference-info-diff> root
document element is defined in [I-D.ietf-xcon-common-data-model] :
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
[I-D.ietf-simple-xml-patch-ops].
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
[I-D.ietf-simple-xml-patch-ops].
Camarillo, et al. Expires March 8, 2009 [Page 7]
Internet-Draft XCON Event Package September 2008
<?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>
<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"/>
Camarillo, et al. Expires March 8, 2009 [Page 8]
Internet-Draft XCON Event Package September 2008
</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">
<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].
Camarillo, et al. Expires March 8, 2009 [Page 9]
Internet-Draft XCON Event Package September 2008
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 xxxx (Note to the RFC Editor: Please
replace XXXX with the RFC Number of this specification.)
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"
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 xxxx (Note to the RFC Editor: Please
replace XXXX with the RFC Number of this specification.)
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
Camarillo, et al. Expires March 8, 2009 [Page 10]
Internet-Draft XCON Event Package September 2008
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
Author/Change controller: The IETF.
6.3. URN Sub-Namespace Registration: consent-status
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="[URL of published RFC]">RFCXXXX [[NOTE TO
RFC-EDITOR/IANA: Please replace XXXX with the RFC Number of
this specification]]</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>
Camarillo, et al. Expires March 8, 2009 [Page 11]
Internet-Draft XCON Event Package September 2008
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
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. 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.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006.
[W3C.REC-xml-20060816]
Paoli, J., Yergeau, F., Bray, T., Sperberg-McQueen, C.,
and E. Maler, "Extensible Markup Language (XML) 1.0
(Fourth Edition)", World Wide Web Consortium
Recommendation REC-xml-20060816, August 2006,
<http://www.w3.org/TR/2006/REC-xml-20060816>.
[I-D.ietf-simple-xml-patch-ops]
Urpalainen, J., "An Extensible Markup Language (XML) Patch
Operations Framework Utilizing XML Path Language (XPath)
Selectors", draft-ietf-simple-xml-patch-ops-04 (work in
progress), November 2007.
[I-D.ietf-xcon-framework]
Camarillo, et al. Expires March 8, 2009 [Page 12]
Internet-Draft XCON Event Package September 2008
Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", draft-ietf-xcon-framework-10
(work in progress), November 2007.
[I-D.ietf-xcon-common-data-model]
Novo, O., Camarillo, G., Morgan, D., and R. Even,
"Conference Information Data Model for Centralized
Conferencing (XCON)", draft-ietf-xcon-common-data-model-08
(work in progress), December 2007.
Authors' Addresses
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Gonzalo.Camarillo@ericsson.com
Srivatsa Srinivasan
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Email: srivats@microsoft.com
Roni Even
Polycom
94 Derech Em Hamoshavot
Petach Tikva 49130
Israel
Email: roni.even@polycom.co.il
Jari Urpalainen
Nokia
Itamerenkatu 11-13
Helsinki 00180
Finland
Email: jari.urpalainen@nokia.com
Camarillo, et al. Expires March 8, 2009 [Page 13]
Internet-Draft XCON Event Package September 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Camarillo, et al. Expires March 8, 2009 [Page 14]
