draft-ietf-xcon-event-package-01.txt   rfc6502.txt 
XCON G. Camarillo Internet Engineering Task Force (IETF) G. Camarillo
Internet-Draft Ericsson Request for Comments: 6502 Ericsson
Intended status: Standards Track S. Srinivasan Category: Standards Track S. Srinivasan
Expires: March 8, 2009 Microsoft Corporation ISSN: 2070-1721
R. Even R. Even
Polycom Gesher Erove Ltd
J. Urpalainen J. Urpalainen
Nokia Nokia
September 4, 2008 March 2012
Conference Event Package Data Format Extension for Centralized
Conferencing (XCON)
draft-ietf-xcon-event-package-01.txt
Status of this Memo Conference Event Package Data Format Extension
for Centralized Conferencing (XCON)
By submitting this Internet-Draft, each author represents that any Abstract
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 This document specifies the notification mechanism for XCON
Task Force (IETF), its areas, and its working groups. Note that (centralized conferencing). This mechanism reuses the SIP (Session
other groups may also distribute working documents as Internet- Initiation Protocol) event package for conference state.
Drafts. Additionally, the notification mechanism includes support for the
XCON data model and for partial notifications.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
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 This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (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.
This Internet-Draft will expire on March 8, 2009. 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.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Abstract 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 specifies the notification mechanism for XCON This document may contain material from IETF Documents or IETF
(centralized conferencing). This mechanism reuses the SIP (Session Contributions published or made publicly available before November
Initiation Protocol) event package for conference state. 10, 2008. The person(s) controlling the copyright in some of this
Additionally, the notification mechanism includes support for the material may not have granted the IETF Trust the right to allow
XCON data model and for partial notifications. 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology .....................................................4
3. Notification Formats . . . . . . . . . . . . . . . . . . . . . 4 3. Notification Formats ............................................5
4. Full Notifications . . . . . . . . . . . . . . . . . . . . . . 4 4. Full Notifications ..............................................5
4.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 5 4.1. Backwards Compatibility ....................................5
5. Partial Notifications . . . . . . . . . . . . . . . . . . . . 5 5. Partial Notifications ...........................................6
5.1. Generation of Partial Notifications . . . . . . . . . . . 5 5.1. Generation of Partial Notifications ........................6
5.2. Processing of Partial Notifications . . . . . . . . . . . 6 5.2. Processing of Partial Notifications ........................7
5.3. Partial Notification Format . . . . . . . . . . . . . . . 7 5.3. Partial Notification Format ................................8
5.4. XML Schema for Partial Notifications . . . . . . . . . . . 7 5.4. XML Schema for Partial Notifications .......................8
5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.5. Examples ...................................................9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations ............................................10
6.1. MIME type Registration: 6.1. MIME type Registration:
application/xcon-conference-info+xml . . . . . . . . . . . 9 application/xcon-conference-info+xml ......................10
6.2. MIME type Registration: 6.2. MIME type Registration:
application/xcon-conference-info-diff+xml . . . . . . . . 10 application/xcon-conference-info-diff+xml .................11
6.3. URN Sub-Namespace Registration: consent-status . . . . . . 11 6.3. URN Sub-Namespace Registration:
6.4. XML Schema Registration . . . . . . . . . . . . . . . . . 11 xcon-conference-info-diff .................................12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6.4. XML Schema Registration ...................................12
8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations ........................................12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References .....................................................13
Intellectual Property and Copyright Statements . . . . . . . . . . 14 8.1. Normative References ......................................13
8.2. Informative References ....................................13
1. Introduction 1. Introduction
The XCON (centralized Conferencing) framework The XCON (Centralized Conferencing) framework [RFC5239] defines a
[I-D.ietf-xcon-framework] defines a notification service that notification service that provides updates about a conference
provides updates about a conference instance's state to authorized instance's state to authorized parties using a notification protocol,
parties using a notification protocol, as shown in Figure 1. This as shown in Figure 1. This document specifies how to use the SIP
document specifies how to use the SIP (Session Initiation Protocol (Session Initiation Protocol [RFC3261]) event package for conference
[RFC3261]) event package for conference state defined in [RFC4575] as state defined in [RFC4575] as a notification protocol between a
a notification protocol between a client and a conference's client and a conference's notification server.
notification server.
........................... ...........................
. Conferencing System . . Conferencing System .
. . . .
. +--------------+ . . +--------------+ .
. | Conf. object | . . | Conf. object | .
. | | . . | | .
. +--------------+ . . +--------------+ .
. | . . | .
. v . . v .
skipping to change at page 3, line 51 skipping to change at page 4, line 40
. | Client | . . | Client | .
. +------------+ . . +------------+ .
. . . .
. Conferencing Client . . Conferencing Client .
....................... .......................
Figure 1: Notification service and protocol in the XCON architecture Figure 1: Notification service and protocol in the XCON architecture
In addition to specifying the SIP event package for conference state, In addition to specifying the SIP event package for conference state,
[RFC4575] specifies a data format to be used with the event package. [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 The XCON data model [RFC6501] extends that format with new elements
format with new elements and attributes so that the extended format and attributes so that the extended format supports more
supports more functionality (e.g., floor control). The notification functionality (e.g., floor control). The notification protocol
protocol specified in this document supports all the data defined in specified in this document supports all the data defined in the XCON
the XCON data model (i.e., the data originally defined in [RFC4575] data model (i.e., the data originally defined in [RFC4575] plus all
plus all the extensions defined in [I-D.ietf-xcon-common-data-model]) the extensions defined in [RFC6501]) plus a partial notification
plus a partial notification mechanism based on XML patch operations mechanism based on XML patch operations [RFC5261].
[I-D.ietf-simple-xml-patch-ops].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Notification Formats 3. Notification Formats
In order to obtain notifications from a conference server's In order to obtain notifications from a conference server's
skipping to change at page 4, line 32 skipping to change at page 5, line 20
NOTIFY requests within this event package can carry an XML document NOTIFY requests within this event package can carry an XML document
in the "application/conference-info+xml" format. Additionally, per in the "application/conference-info+xml" format. Additionally, per
this specification, NOTIFY requests can also carry XML documents in this specification, NOTIFY requests can also carry XML documents in
the "application/xcon-conference-info+xml" and the "application/ the "application/xcon-conference-info+xml" and the "application/
xcon-conference-info-diff+xml" formats. xcon-conference-info-diff+xml" formats.
A document in the "application/xcon-conference-info+xml" format A document in the "application/xcon-conference-info+xml" format
provides the user agent with the whole state of a conference provides the user agent with the whole state of a conference
instance. A document in the "application/ instance. A document in the "application/
xcon-conference-info-diff+xml" format provides the user agent with xcon-conference-info-diff+xml" format provides the user agent with
the changes the state of the conference instance has experimented the changes the state of the conference instance has experienced
since the last notification sent to the user agent. since the last notification sent to the user agent.
4. Full Notifications 4. Full Notifications
Subscribers signal support for full notifications by including the Subscribers signal support for full notifications by including the
"application/xcon-conference-info+xml" format in the Accept header "application/xcon-conference-info+xml" format in the Accept header
field of the SUBSCRIBE requests they generate. If a client field of the SUBSCRIBE requests they generate. If a client
subscribing to the 'conference' event package generates an Accept subscribing to the 'conference' event package generates an Accept
header field that includes the MIME type "application/ header field that includes the MIME type "application/
xcon-conference-info+xml", the server has the option of returning xcon-conference-info+xml", the server has the option of returning
documents that follow the XML format specified in documents that follow the XML format specified in [RFC6501] and are
[I-D.ietf-xcon-common-data-model] and are carried in "application/ carried in "application/xcon-conference-info+xml" message bodies.
xcon-conference-info+xml" message bodies.
4.1. Backwards Compatibility 4.1. Backwards Compatibility
Conference servers that implement the SIP event package for Conference servers that implement the SIP event package for
conference state and support the "application/ conference state and support the "application/
xcon-conference-info+xml" MIME type MUST also support the xcon-conference-info+xml" MIME type MUST also support the
"application/conference-info+xml" MIME type. This way, legacy "application/conference-info+xml" MIME type. This way, legacy
clients, which only support "application/conference-info+xml", are clients, which only support "application/conference-info+xml", are
able to receive notifications in a format they understand. able to receive notifications in a format they understand.
skipping to change at page 6, line 5 skipping to change at page 6, line 37
xcon-conference-info-diff+xml", the server has the option of xcon-conference-info-diff+xml", the server has the option of
returning documents that follow the XML format specified in returning documents that follow the XML format specified in
Section 5.4 and are carried in "application/ Section 5.4 and are carried in "application/
xcon-conference-diff-info+xml" message bodies. xcon-conference-diff-info+xml" message bodies.
5.1. Generation of Partial Notifications 5.1. Generation of Partial Notifications
Once a subscription is accepted and installed, the server MUST Once a subscription is accepted and installed, the server MUST
deliver full state in its first notification. To report full state, deliver full state in its first notification. To report full state,
the server MUST set the Content-Type header field to the value the server MUST set the Content-Type header field to the value
'application/xcon-conference-info+xml'. "application/xcon-conference-info+xml".
In order to deliver a partial notification, the server MUST set the In order to deliver a partial notification, the server MUST set the
Content-Type header field to the value 'application/ Content-Type header field to the value "application/
xcon-conference-info-diff+xml'. When the server generates a partial xcon-conference-info-diff+xml". When the server generates a partial
notification, the server SHOULD only include the information that has notification, the server SHOULD only include the information that has
changed compared to the previous notification. It is up to the changed compared to the previous notification. It is up to the
server's local policy to determine what is considered as a change to server's local policy to determine what is considered as a change to
the previous state. the previous state.
The server MUST construct partial notifications according to the The server MUST construct partial notifications according to the
following logic: all the information that has been added to the following logic: all the information that has been added to the
document is listed inside <add> elements. All information that has document is listed inside <add> elements. All information that has
been removed from the document is listed inside <remove> elements and been removed from the document is listed inside <remove> elements,
all information that has been changed is listed under <replace> and all information that has been changed is listed under <replace>
elements. elements.
The server MUST NOT send a new NOTIFY request with a partial The server MUST NOT send a new NOTIFY request with a partial
notification until it has received a final response from the notification until it has received a final response from the
subscriber for the previous one or the previous NOTIFY request has subscriber for the previous one or the previous NOTIFY request has
timed out. timed out.
When the server receives a SUBSCRIBE request (refresh or termination) When the server receives a SUBSCRIBE request (refresh or termination)
within the associated subscription, it SHOULD send a NOTIFY request within the associated subscription, it SHOULD send a NOTIFY request
containing the full document using the 'application/ containing the full document using the 'application/
skipping to change at page 6, line 46 skipping to change at page 7, line 29
xcon-conference-info+xml' content type before generating its first xcon-conference-info+xml' content type before generating its first
partial notification. partial notification.
5.2. Processing of Partial Notifications 5.2. Processing of Partial Notifications
When a subscriber receives the first notification containing full When a subscriber receives the first notification containing full
state in a 'application/xcon-conference-info+xml' MIME body, the state in a 'application/xcon-conference-info+xml' MIME body, the
subscriber MUST store the received full document as its local copy. subscriber MUST store the received full document as its local copy.
When the subscriber receives a subsequent notification, the When the subscriber receives a subsequent notification, the
subscriber MUST modify its locally-stored information according to subscriber MUST modify its locally stored information according to
the following logic: the following logic:
o If the notification carries an 'application/ o If the notification carries an 'application/
xcon-conference-info+xml' document, the subscriber MUST replace xcon-conference-info+xml' document, the subscriber MUST replace
its local copy of the document with the document received in its local copy of the document with the document received in the
notification. notification.
o If the notification carries an 'application/ o If the notification carries an 'application/
xcon-conference-info-diff+xml' document, the subscriber MUST apply xcon-conference-info-diff+xml' document, the subscriber MUST apply
the changes indicated in the received 'application/ the changes indicated in the received 'application/
xcon-conference-info-diff+xml' document to its local copy of the xcon-conference-info-diff+xml' document to its local copy of the
full document. full document.
If subscriber encounters a processing error while processing an If the subscriber encounters a processing error while processing an
'application/xcon-conference-info-diff+xml' encoded document, the 'application/xcon-conference-info-diff+xml' encoded document, the
subscriber SHOULD renew its subscription. A subscriber can fall back subscriber SHOULD renew its subscription. A subscriber can fall back
to normal operations by not including the "application/ to normal operations by not including the "application/
xcon-conference-info-diff+xml' format in a new SUBSCRIBE request. xcon-conference-info-diff+xml" format in a new SUBSCRIBE request.
If the server changes the content type used in notifications within If the server changes the content type used in notifications within
the existing subscription, the subscriber MUST discard all the the existing subscription, the subscriber MUST discard all the
previously received information and process the new content as previously received information and process the new content as
specified for that content type. specified for that content type.
5.3. Partial Notification Format 5.3. Partial Notification Format
A xcon-conference-info-diff diff document is an XML An xcon-conference-info-diff document is an XML
[W3C.REC-xml-20060816] document that MUST be well-formed and SHOULD [W3C.REC-xml-20081126] document that MUST be well-formed and SHOULD
be valid. The namespace URI for the <conference-info-diff> root be valid. The namespace URI for the <conference-info-diff> root
document element is defined in [I-D.ietf-xcon-common-data-model] : document element is defined in [RFC6501]:
urn:ietf:params:xml:ns:xcon-conference-info urn:ietf:params:xml:ns:xcon-conference-info
The root document element <conference-info-diff> has a single The root document element <conference-info-diff> has a single
mandatory attribute, "entity". The value of this attribute is the mandatory attribute, "entity". The value of this attribute is the
conference object identifier (XCON-URI) that identifies the conference object identifier (XCON-URI) that identifies the
conference being described in the document. conference being described in the document.
The content of the <conference-info-diff> element is an unordered The content of the <conference-info-diff> element is an unordered
sequence of <add>, <replace> and <remove> elements followed by sequence of <add>, <replace>, and <remove> elements followed by
elements from other namespaces for the purposes of extensibility. elements from other namespaces for the purposes of extensibility.
Any such unknown elements MUST be ignored by the client. The <add>, Any such unknown elements MUST be ignored by the client. The <add>,
<replace> and <remove> elements can contain other extension <replace>, and <remove> elements can contain other extension
attributes than what are defined in the corresponding base types of attributes than what are defined in the corresponding base types of
[I-D.ietf-simple-xml-patch-ops]. [RFC5261].
5.4. XML Schema for Partial Notifications 5.4. XML Schema for Partial Notifications
This is the XML schema for the "application/ This is the XML schema for the "application/
xcon-conference-info-diff+xml" data format. The xcon-conference-info-diff+xml" data format. The
"urn:ietf:params:xml:schema:xml-patch-ops" schema is defined in "urn:ietf:params:xml:schema:xml-patch-ops" schema is defined in
[I-D.ietf-simple-xml-patch-ops]. [RFC5261].
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:xcon-conference-info" targetNamespace="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns="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" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"> elementFormDefault="qualified">
<!-- include patch-ops type definitions --> <!-- include patch-ops type definitions -->
<xs:include <xs:include
skipping to change at page 9, line 43 skipping to change at page 10, line 24
There are four IANA considerations associated with this There are four IANA considerations associated with this
specification. specification.
6.1. MIME type Registration: application/xcon-conference-info+xml 6.1. MIME type Registration: application/xcon-conference-info+xml
This section registers the 'application/xcon-conference-info+xml' This section registers the 'application/xcon-conference-info+xml'
MIME type. MIME type.
MIME media type name: application MIME media type name: application
MIME subtype name: xcon-conference-info+xml MIME subtype name: xcon-conference-info+xml
Mandatory parameters: none Mandatory parameters: none
Optional Parameters: Same as charset parameter application/xml as Optional Parameters: Same as charset parameter application/xml as
specified in [RFC3023]. specified in [RFC3023].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in [RFC3023]. application/xml as specified in [RFC3023].
Security considerations: Security considerations: See Section 10 of Security considerations: Security considerations: See Section 10 of
[RFC3023]. [RFC3023].
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC xxxx (Note to the RFC Editor: Please
replace XXXX with the RFC Number of this specification.) Published specification: RFC 6502
Applications that use this media type: This document type has been Applications that use this media type: This document type has been
defined to support centralized conferencing applications. defined to support centralized conferencing applications.
Additional Information: Additional Information:
Magic Number: none Magic Number: none
File extension: .xml File extension: .xml
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: IETF XCON Personal and email address for further information: IETF XCON
Working Group <xcon@ietf.org> Working Group <xcon@ietf.org>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF.
6.2. MIME type Registration: application/xcon-conference-info-diff+xml 6.2. MIME type Registration: application/xcon-conference-info-diff+xml
This section registers the 'application/ This section registers the 'application/
xcon-conference-info-diff+xml' MIME type. xcon-conference-info-diff+xml' MIME type.
MIME media type name: application MIME media type name: application
MIME subtype name: xcon-conference-info-diff+xml MIME subtype name: xcon-conference-info-diff+xml
Mandatory parameters: none Mandatory parameters: none
Optional Parameters: Same as charset parameter application/xml as Optional Parameters: Same as charset parameter application/xml as
specified in [RFC3023]. specified in [RFC3023].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in [RFC3023]. application/xml as specified in [RFC3023].
Security considerations: Security considerations: See Section 10 of Security considerations: Security considerations: See Section 10 of
[RFC3023]. [RFC3023].
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC xxxx (Note to the RFC Editor: Please
replace XXXX with the RFC Number of this specification.) Published specification: RFC 6502
Applications that use this media type: This document type has been Applications that use this media type: This document type has been
defined to support partial notifications in centralized defined to support partial notifications in centralized
conferencing applications. conferencing applications.
Additional Information: Additional Information:
Magic Number: none Magic Number: none
File extension: .xml File extension: .xml
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: IETF XCON Personal and email address for further information: IETF XCON
Working Group <xcon@ietf.org> Working Group <xcon@ietf.org>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF.
6.3. URN Sub-Namespace Registration: consent-status 6.3. URN Sub-Namespace Registration: xcon-conference-info-diff
This section registers a new XML namespace per the procedures in This section registers a new XML namespace per the procedures in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:xcon-conference-info-diff URI: urn:ietf:params:xml:ns:xcon-conference-info-diff
Registrant Contact: IETF SIPPING working group, <sipping@ietf.org>, Registrant Contact: IETF SIPPING working group <sipping@ietf.org>,
Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
XML: XML:
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>Partial Notifications in Centralized Conferencing</title> <title>Partial Notifications in Centralized Conferencing</title>
</head> </head>
<body> <body>
<h1>Namespace for Partial Notifications in</h1> <h1>Namespace for Partial Notifications in</h1>
<h1>Centralized Conferencing</h1> <h1>Centralized Conferencing</h1>
<h2>urn:ietf:params:xml:ns:xcon-conference-info-diff</h2> <h2>urn:ietf:params:xml:ns:xcon-conference-info-diff</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX [[NOTE TO <p>See <a href="http://www.rfc-editor.org/rfc/rfc6502.txt">
RFC-EDITOR/IANA: Please replace XXXX with the RFC Number of RFC 6502</a>.</p>
this specification]]</a>.</p>
</body> </body>
</html> </html>
6.4. XML Schema Registration 6.4. XML Schema Registration
This section registers an XML schema per the procedures in [RFC3688]. This section registers an XML schema per the procedures in [RFC3688].
URI: urn:ietf:params:xml:schema:xcon-conference-info-diff URI: urn:ietf:params:xml:schema:xcon-conference-info-diff
Registrant Contact: IETF XCON working group, <xcon@ietf.org>, Gonzalo Registrant Contact: IETF XCON working group, <xcon@ietf.org>, Gonzalo
skipping to change at page 12, line 16 skipping to change at page 13, line 9
7. Security Considerations 7. Security Considerations
This document specifies how to deliver notifications using the SIP This document specifies how to deliver notifications using the SIP
event package for conference state in two new formats. The fact that event package for conference state in two new formats. The fact that
notifications are encoded in a different format does not have notifications are encoded in a different format does not have
security implications. Section 8 of [RFC4575] contains security security implications. Section 8 of [RFC4575] contains security
considerations related to the use of the event package. Implementers considerations related to the use of the event package. Implementers
of the event package need to follow those considerations regardless of the event package need to follow those considerations regardless
of the format used to encode their notifications. of the format used to encode their notifications.
8. Normative References 8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. 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 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006. State", RFC 4575, August 2006.
[W3C.REC-xml-20060816] [RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch
Paoli, J., Yergeau, F., Bray, T., Sperberg-McQueen, C., Operations Framework Utilizing XML Path Language (XPath)
and E. Maler, "Extensible Markup Language (XML) 1.0 Selectors", RFC 5261, September 2008.
(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] [RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
Urpalainen, J., "An Extensible Markup Language (XML) Patch "Conference Information Data Model for Centralized
Operations Framework Utilizing XML Path Language (XPath) Conferencing (XCON)", RFC 6501, March 2012.
Selectors", draft-ietf-simple-xml-patch-ops-04 (work in
progress), November 2007.
[I-D.ietf-xcon-framework] [W3C.REC-xml-20081126]
Barnes, M., Boulton, C., and O. Levin, "A Framework for Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
Centralized Conferencing", draft-ietf-xcon-framework-10 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
(work in progress), November 2007. Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>.
[I-D.ietf-xcon-common-data-model] 8.2. Informative References
Novo, O., Camarillo, G., Morgan, D., and R. Even,
"Conference Information Data Model for Centralized [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
Conferencing (XCON)", draft-ietf-xcon-common-data-model-08 January 2004.
(work in progress), December 2007.
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, June 2008.
Authors' Addresses Authors' Addresses
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com EMail: Gonzalo.Camarillo@ericsson.com
Srivatsa Srinivasan Srivatsa Srinivasan
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Email: srivats@microsoft.com EMail: srivatsa.srinivasan@gmail.com
Roni Even Roni Even
Polycom Gesher Erove Ltd
94 Derech Em Hamoshavot 14 David Hamelech
Petach Tikva 49130 Tel Aviv 64953
Israel Israel
Email: roni.even@polycom.co.il EMail: ron.even.tlv@gmail.com
Jari Urpalainen Jari Urpalainen
Nokia Nokia
Itamerenkatu 11-13 Itamerenkatu 11-13
Helsinki 00180 Helsinki 00180
Finland Finland
Email: jari.urpalainen@nokia.com EMail: jari.urpalainen@nokia.com
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).
 End of changes. 67 change blocks. 
136 lines changed or deleted 160 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/