One document matched: draft-srinivasan-xcon-eventpkg-extensions-02.txt
Differences from draft-srinivasan-xcon-eventpkg-extensions-01.txt
XCON Working Group S. Srinivasan
Internet-Draft Microsoft Corporation
Intended status: Standards Track R. Even
Expires: February 17, 2008 Polycom
August 16, 2007
Conference event package data format extension for centralized
conferencing
draft-srinivasan-xcon-eventpkg-extensions-02
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 February 17, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document augments the notification mechanism defined in RFC 4575
to suit the specific needs of the framework and the data model
defined for centralized conferencing. The document registers a new
media subtype for this purpose. Support for this new data format may
be negotiated using Accept header semantics as defined in the Session
Initiation Protocol (SIP).
Srinivasan & Even Expires February 17, 2008 [Page 1]
Internet-Draft xcon-eventpkg-extensions August 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Event package definition . . . . . . . . . . . . . . . . . . . 4
3.1. Event package name . . . . . . . . . . . . . . . . . . . . 4
3.2. SUSCRIBE and NOTIFY bodies . . . . . . . . . . . . . . . . 4
3.2.1. Reasons for a new media type . . . . . . . . . . . . . 5
3.2.2. Elements supporting partial updates . . . . . . . . . 6
3.3. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 7
3.4. Notifier Generation of NOTIFY Requests . . . . . . . . . . 7
3.5. Subscriber Processing of NOTIFY Requests . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.1. application/xcon-conference-info+xml media type
registration . . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informational References . . . . . . . . . . . . . . . . . 9
Appendix A. Examples of partial updates . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Srinivasan & Even Expires February 17, 2008 [Page 2]
Internet-Draft xcon-eventpkg-extensions August 2007
1. Introduction
The framework for centralized conferencing [1] specifies the need for
a notification mechanism to deliver conference state updates to
conference-aware clients. The purpose of this document is to fill
that requirement by building upon the event package defined in RFC
4575 [2] and uses the data model defined for centralized conferencing
[3] instead of the one defined in the Conference Event Package.
The diagram below shows the subscription and notification entities
present in the centralized conferencing framework.
...........................
. Conferencing System .
. .
. +--------------+ .
. | Conf. object | .
. | | .
. | | .
. | | .
. +--------------+ .
. | .
. | .
. v .
. +------------+ .
. |Notification| .
. |Service | .
. |(Notifier) | .
. +------------+ .
. ^ ^ .
.....|....|................
| |
| |
Subscribe| |Notification
| |(data model for centralized conferencing)
| |
| |
.....|....|............
. V v .
. +------------+ .
. |Notification| .
. | Client | .
. |(Subscriber)| .
. | | .
. +------------+ .
. .
. Conferencing Client .
.......................
Srinivasan & Even Expires February 17, 2008 [Page 3]
Internet-Draft xcon-eventpkg-extensions August 2007
As mentioned earlier, the conferencing client may use the
notification protocol defined in RFC 4575 [2] to subscribe and
receive notifications based on mechanisms defined here. Listed below
are some of the requirements for the event package.
o The event package should satisfy the notifications needs defined
in the conferencing framework [1] and the data model defined for
centralized conferencing [3].
o The event package should re-use the event package mechanisms
defined in RFC4575 [2] to the extent possible.
o The event package should support partial updates of changes in
elements defined in the data model for centralized conferencing
[3] such as controls and list elements. Clients receiving partial
notifications can determine the specific control that changed by
examining the notification received.
o The event package should describe how conference-aware clients
implementing the conference event package [2](and the data format
defined therein) will work against the centralized conferencing
defined data format defined in [3].
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations.
3. Event package definition
Implementations of this event package MUST follow all sections of RFC
4575 [2] Section 3 unless otherwise specified in this document.
3.1. Event package name
The name of this event package is "conference" as defined in Section
3.1 of RFC 4575 [2].
3.2. SUSCRIBE and NOTIFY bodies
This document defines a new media type 'application/
xcon-conference-info+xml' for supporting the data model for
centralized conferencing.
Implementations of this specification thus MUST support the data
model defined for centralized conferencing [3]. Furthermore,
Srinivasan & Even Expires February 17, 2008 [Page 4]
Internet-Draft xcon-eventpkg-extensions August 2007
implementations MUST also support the media type 'application/
conference-info+xml' defined in RFC 4575 [2] for backward
compatibility reasons.
Subscribers implementing this specification MUST include an Accept
header, as defined in RFC 3261 [4], in the SUBSCRIBE request
including BOTH 'application/xcon-conference-info+xml' as well as the
media type 'application/conference-info+xml' defined in [2].
Notifiers implementing this specification MUST handle SUBSCRIBE
requests with either media types as well. Therefore, subscribers
implementing this specification may receive NOTIFY's with either
media type depending on the format that the conferencing system
supports. Notifiers implementing this specification SHOULD prefer to
use 'application/xcon-conference-info+xml' wherever possible over the
media type 'application/conference-info+xml'.
Furthermore, the subscriber may a priori determine which formats the
conferencing system is capable of by using Accept header semantics.
3.2.1. Reasons for a new media type
This section describes some of the reasoning for defining a new media
type as opposed to simply using XML extensibility to achieve the
needs for notifications.
The media type 'application/conference-info+xml' is defined in the
conference event package [2]. Sections 4.4, 4.5 and 4.6 therein
specify a mechanism to send partial updates of conference state
information. The algorithm defined in those sections, however,
prevents the partial notifications for non-atomic sub-elements of
elements like 'available-media' (defined in Section 5.3.4 of [2]) and
'media' (defined in Section 5.7.8 of [2]) as these elements do not
contain a state attribute defined.
The data model for centralized conferencing introduces the concept of
controls for controlling media. This is defined under 'available-
media' for streams from the mixer and under 'media' for streams
received from and sent to the mixer from conference participant's
endpoints. A 'floor' element has also been defined under the 'media'
element. These elements may frequently change their state over the
course of a conference. The list of media could grow significantly
large for large conferences. Furthermore, clients receiving updates
of media often need to know which specific control changed when a
notification as such is received.
To overcome these limitations, a partial notification mechanism needs
to be defined for these elements. Thus, state attributes and element
Srinivasan & Even Expires February 17, 2008 [Page 5]
Internet-Draft xcon-eventpkg-extensions August 2007
keys (for the sub-elements) have been defined in the data model for
these elements. This, however, requires that a new media subtype be
defined and registered as these elements have been explicitly marked
as not having a state attribute in [2]. A conferencing system,
implementing only [2], may not expect to receive these XML elements
with a state attribute of partial and thus this may result in
inconsistent conferencing state. In-order to overcome this
limitation this specification defines a new media subtype which can
be used to enable partial notifications of elements previously
defined without a state attribute.
3.2.2. Elements supporting partial updates
As specified earlier, the following captures elements defined in RFC
4575 [2] not supporting partial updates that now need support for
partial updates.
1. Conference information 'available-media' XML element defined in
Section 5.3.4 of [2]
2. Endpoint 'media' XML element defined in Section 5.7.8 of [2]
3.2.2.1. Available-media
With the introduction of the state attribute to available-media in
[3], element keys are defined as follows for sub-elements.
The sub-element 'entry' is defined with the attribute key 'label'.
The non-atomic sub-elements under 'entry' are 'codecs' and
'controls'.
There are no requirements to have 'codecs' support partial updates as
these are expected to change rarely.
The 'controls' element is defined with a state attribute as well.
The sub-elements appearing under 'controls' do not require a key as
each sub-element (like 'mute' or 'gain') appears only once and is
atomic. That is, in a partial notification, the 'mute' element (and
all sub-elements) should be included.
3.2.2.2. Media
Similarly, the introduction of the state attribute to media requires
element keys to be defined for its sub-elements.
The 'endpoints' element (under which 'media' appears) has the state
attribute defined and so do all its parent elements.
Srinivasan & Even Expires February 17, 2008 [Page 6]
Internet-Draft xcon-eventpkg-extensions August 2007
The non-atomic sub-elements under 'media' are 'from-mixer' and 'to-
mixer'. Both of which have the state attribute defined.
The 'floor' element is an atomic sub-element of 'from-mixer' or 'to-
mixer' and thus does not require a state attribute. The non-atomic
sub-element appearing under both 'from-mixer' and 'to-mixer' is the
'controls' element which has a 'state' attribute defined. The sub-
elements appearing under 'controls', as defined previously
(Section 3.2.2.1), do not require a key as each sub-element appears
only once and is atomic.
3.3. Notifier Processing of SUBSCRIBE Requests
Notifiers implementing this specification MUST be capable of
accepting SUBSCRIBE requests with an Accept header field containing
'application/xcon-conference-info+xml' and/or 'application/
conference-info+xml'.
A SUBSCRIBE request sent without an Accept header field MUST be
supported. In this case, the notifier should default to the media
type 'application/conference-info+xml' and thus all NOTIFY's
generated for that subscription MUST follow RFC 4575 [2].
Furthermore, a SUBSCRIBE body sent without a body will apply default
subscription filtering policy as specified in Section 3.2 of [2].
3.4. Notifier Generation of NOTIFY Requests
Notifiers generating NOTIFY requests should take into account the
media type that the subscriber can accept when generating partial
notifications. As mentioned before, notifiers SHOULD prefer to use
'application/xcon-conference-info+xml' wherever possible over the
media type 'application/conference-info+xml'.
For example, a notification request generated to a subscriber only
accepting the media type 'application/conference-info+xml' may be
different from the one generated to a subscriber accepting
'application/xcon-conference-info+xml'. An example of such a case is
illustrated in Appendix A.
3.5. Subscriber Processing of NOTIFY Requests
Subscribers implementing this specification MUST be capable of
receiving NOTIFY Requests with media types of either 'application/
xcon-conference-info+xml' or 'application/conference-info+xml'. All
sections of Section 4.6 of [2] apply to enable subscribers to
construct coherent state when receiving partial updates based on the
new media type defined here.
Srinivasan & Even Expires February 17, 2008 [Page 7]
Internet-Draft xcon-eventpkg-extensions August 2007
4. Security Considerations
It is RECOMMENDED that a centralized conferencing system following
this specification use a strong means for authentication and
conference information protection and that it apply comprehensive
authorization rules as defined in RFC 4575 [2], Section 8.
5. IANA Considerations
5.1. application/xcon-conference-info+xml media type registration
[[TBD]]
To: ietf-types@iana.org
Subject: Registration of media type application/
xcon-conference-info+xml
Type name: application
Subtype name: xcon-conference-info+xml
Required parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [5]
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [5]
Security considerations: See Section 10 of RFC 3023 [5] and Section 4
of this specification
Interoperability considerations: none
Published specification: This document.
Applications which use this media type: This document type has been
used to support SIP conferencing applications that comply with the
data model for centralized conferencing [3]
Additional Information:
Magic Number(s): None
File Extension(s): .xml
Srinivasan & Even Expires February 17, 2008 [Page 8]
Internet-Draft xcon-eventpkg-extensions August 2007
Macintosh file type code(s): "TEXT"
Personal and email address for further information: TBD
Intended usage: COMMON
Author:
Change controller: TBD
6. References
6.1. Normative References
[1] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", draft-ietf-xcon-framework-09 ,
August 2007.
[2] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference State",
RFC 4575, August 2006.
[3] Novo, O., Camarillo, G., Morgan, D., and R. Even, "Conference
Information Data Model for Centralized Conferencing (XCON)",
draft-ietf-xcon-common-data-model-05 , April 2007.
[4] 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.
[5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
6.2. Informational References
[6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
Appendix A. Examples of partial updates
Consider an example, where the conferencing state changes. The main
audio stream with a label of '34569' changes mute state from false to
true.
A notifier implementing partial updates specified in RFC 4575 [2]
without the state attribute extensions defined in this document would
Srinivasan & Even Expires February 17, 2008 [Page 9]
Internet-Draft xcon-eventpkg-extensions August 2007
end up sending the entire available-media element as shown below.
Content-Type: application/conference-info+xml
...
<?xml version="1.0" encoding="UTF-8"?>
<conference-info xmlns="urn:ietf:params:xml:ns:conference-info"
entity="sips:conf233@example.com"
state="partial" version="1">
<!-- CONFERENCE INFO -->
<available-media>
<entry label="34569">
<display-text>main audio</display-text>
<type>audio</type>
<status>sendrecv</status>
<controls>
<mute>true</mute>
<gain>0</gain>
</controls>
</entry>
</available-media>
</conference-info>
However, a notifier implementing the centralized conferencing data
model and the extensions defined in this draft would notify clients
with relevant changes only wherever possible as shown below.
Content-Type: application/conference-info+xml
...
<?xml version="1.0" encoding="UTF-8"?>
<conference-info xmlns="urn:ietf:params:xml:ns:conference-info"
entity="sips:conf233@example.com"
state="partial" version="1">
<!-- CONFERENCE INFO -->
<available-media state="partial">
<entry label="34569" state="partial">
<controls state="partial">
<mute>true</mute>
</controls>
</entry>
</available-media>
</conference-info>
Srinivasan & Even Expires February 17, 2008 [Page 10]
Internet-Draft xcon-eventpkg-extensions August 2007
Authors' Addresses
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
Srinivasan & Even Expires February 17, 2008 [Page 11]
Internet-Draft xcon-eventpkg-extensions August 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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).
Srinivasan & Even Expires February 17, 2008 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 20:41:47 |