draft-ietf-sipping-conference-package-01.txt   draft-ietf-sipping-conference-package-02.txt 
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft dynamicsoft Internet-Draft dynamicsoft
Expires: December 29, 2003 H. Schulzrinne Expires: April 26, 2004 H. Schulzrinne
Columbia University Columbia University
June 30, 2003 O. Levin, Ed.
Microsoft Corporation
October 27, 2003
A Session Initiation Protocol (SIP) Event Package for Conference A Session Initiation Protocol (SIP) Event Package for Conference
State State
draft-ietf-sipping-conference-package-01 draft-ietf-sipping-conference-package-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 29, 2003. This Internet-Draft will expire on April 26, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document defines a conference event package for the Session This document defines a conference event package for the Session
Initiation Protocol (SIP) Events framework, along with a data format Initiation Protocol (SIP) Events framework, along with a data format
used in notifications for this package. The conference package allows used in notifications for this package. The conference package allows
users to subscribe to a conference URI. Notifications are sent about users to subscribe to a conference URI. Notifications are sent about
changes in the membership of this conference, the state of the changes in the membership of this conference, the status of users'
dialogs that compose the conference, and general information about participation in the conference, and the sidebars in the conference.
the conference.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conference Event Package . . . . . . . . . . . . . . . . . . 5 3. Conference Event Package . . . . . . . . . . . . . . . . . 5
3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . . 5 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 5
3.2 Event Package Parameters . . . . . . . . . . . . . . . . . . 5 3.2 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 5
3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Subscription Duration . . . . . . . . . . . . . . . . . . 5
3.4 Subscription Duration . . . . . . . . . . . . . . . . . . . 6 3.4 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 5
3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 6 3.5 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 6
3.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . . 7 3.6 Notifier Generation of NOTIFY Requests . . . . . . . . . . 6
3.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . . 7 3.7 Subscriber Processing of NOTIFY Requests . . . . . . . . . 6
3.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 7 3.8 Handling of Forked Requests . . . . . . . . . . . . . . . 7
3.9 Handling of Forked Requests . . . . . . . . . . . . . . . . 8 3.9 Rate of Notifications . . . . . . . . . . . . . . . . . . 7
3.10 Rate of Notifications . . . . . . . . . . . . . . . . . . . 8 3.10 State Agents . . . . . . . . . . . . . . . . . . . . . . . 7
3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Conference Data Format . . . . . . . . . . . . . . . . . . 8
4. Conference Data Format . . . . . . . . . . . . . . . . . . . 9 4.1 Conference Information . . . . . . . . . . . . . . . . . . 8
4.1 Structute of the Format . . . . . . . . . . . . . . . . . . 9 4.1.1 User Element . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1 Conferencing Service Element . . . . . . . . . . . . . . . . 9 4.1.1.1 User Statuses . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2 User Element . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.1.2 Media Stream Information . . . . . . . . . . . . . . . . . 9
4.1.3 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.2 Sidebar . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.4 Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2 Constructing Coherent State . . . . . . . . . . . . . . . 10
4.1.5 Media Streams . . . . . . . . . . . . . . . . . . . . . . . 11 4.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Constructing Coherent State . . . . . . . . . . . . . . . . 12 4.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . 15
4.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . 16 6.1 conference Event Package Registration . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 6.2 application/conference-info+xml MIME Registration . . . . 16
6.1 conference Event Package Registration . . . . . . . . . . . 17
6.2 application/conference-info+xml MIME Registration . . . . . 17
6.3 URN Sub-Namespace Registration for 6.3 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:conference-info . . . . . . . . . . . 18 urn:ietf:params:xml:ns:conference-info . . . . . . . . . . 17
6.4 XML Schema Registration . . . . . . . . . . . . . . . . . . 19 6.4 XML Schema Registration . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 19
Normative References . . . . . . . . . . . . . . . . . . . . 21 8. Changes since -01 . . . . . . . . . . . . . . . . . . . . 20
Informative References . . . . . . . . . . . . . . . . . . . 22 Normative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 Informative References . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . 23
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [3] Events framework [2] The Session Initiation Protocol (SIP) [3] Events framework [2]
defines general mechanisms for subscribing to, and receiving defines general mechanisms for subscribing to, and receiving
notifications of, events within SIP networks. It introduces the notifications of, events within SIP networks. It introduces the
notion of a package, which is a specific "instantiation" of the notion of a package, which is a specific "instantiation" of the
events framework for a well-defined set of events. Packages have been events framework for a well-defined set of events. Here, we define an
defined for user presence [11], watcher information [12], and message event package for SIP conferences. This package provides the
waiting indicators [14], amongst others. Here, we define an event conference notification service as outlined in the SIP conferencing
package for SIP conferences. This package provides the conference framework [9]. As described there, subscriptions to a conference URI
notification service as outlined in the SIP conferencing framework are routed to the focus that is handling the conference. It acts as
[15]. As described there, subscriptions to a conference URI are the notifer, and provides clients with updates on conference state.
routed to the focus that is handling the conference. It acts as the
notifer, and provides clients with updates on conference state.
The information provided by this package is broken into several
general categories:
General State: A small amount of general conference state is
provided, primarily for the purposes of bootstrapping access to
other conference services, such as media and conference policy
controls.
Membership State: The members of the conference, and their state
within the conference.
Dialog State: The state of the dialogs for users connected to the
conference.
Media State: Information about what media users in the conference are The information provided by this package is comprised of conference
receiving. identifier, conference participants (optionally with their statuses
and media types) and conference sidebars.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
3. Conference Event Package 3. Conference Event Package
The conference event package allows a user to subscribe to a The conference event package allows a user to subscribe to a
conference. In SIP, conferences are represented by URIs. These URIs conference. In SIP, conferences are represented by URIs. These URIs
route to a SIP user agent, called a focus, that is responsible for route to a SIP user agent, called a focus, that is responsible for
ensuring that all users in the conference can communicate with each ensuring that all users in the conference can communicate with each
other [15]. The focus has sufficient information about the state of other [9]. The focus has sufficient information about the state of
the conference to inform subscribers about it. the conference to inform subscribers about it.
This section provides the details for defining a SIP Events package, This section provides the details for defining a SIP Events package,
as specified by [2]. as specified by [2].
3.1 Event Package Name 3.1 Event Package Name
The name of this event package is "conference". This package name is The name of this event package is "conference". This package name is
carried in the Event and Allow-Events header, as defined in [2]. carried in the Event and Allow-Events header, as defined in [2].
3.2 Event Package Parameters 3.2 SUBSCRIBE Bodies
Two Event header field parameters are defined for this package. The
first is "recurse". The parameter has no values. When present, it
informs the server that it should check whether any participants in
the conference are themselves a focus, and if so, generate a
subscription to their conference state with the "recurse" attribute.
The focus can determine whether a participant is a focus based on the
presence of the "isfocus" capability indication in the Contact header
field provided by the participant [4]. The users reported in
notifications from this recursed subscription are reported to the
original subscriber. The result is that the list of users reported to
the subscriber represents the complete user list even when cascaded
conferences are used.
The second Event header field parameter is "type". Its value is a
comma separated list of the types of conference information that are
desired. This specification defines four values - "general",
"membership", "dialog", and "basic-media". When any one of these is
present, it means that the corresponding conference information is
desired. The specific components of a conference information document
corresponding to each of these values are described below. Additional
values for this parameter MAY be defined by extensions to this
package. Such extensions are anticipated to handle membership and
media policy state.
Both of these parameters MUST have the same value in a initial
SUBSCRIBE request and any refreshes of the resulting subscription. In
other words, their values are fixed for the duration of the
subscription. The default meaning of the "type" parameter, when not
present, is that the focus should send all information it has about
the conference. When present, the type parameter MUST have at least
one value.
The BNF for these parameters is:
recurse = "recurse"
type = "type" EQUAL SWS DQUOTE conf-info *("," conf-info)
DQUOTE
;; EQUAL, SWS, DQUOTE from RFC3261
conf-info = "general" | "membership" | "dialog" | "basic-media" |
token
Example:
Event: conference;recurse;type="membership,general"
3.3 SUBSCRIBE Bodies
A SUBSCRIBE for a dialog package MAY contain a body. This body A SUBSCRIBE for a dialog package MAY contain a body. This body
defines a filter to apply to the subscription. Filter documents are defines a filter to apply to the subscription. Filter documents are
not specified in this document, and at the time of writing, are not specified in this document, and at the time of writing, are
expected to be the subject of future standardization activity. expected to be the subject of future standardization activity.
A SUBSCRIBE for a dialog package MAY be sent without a body. This A SUBSCRIBE for a dialog package MAY be sent without a body. This
implies the default subscription filtering policy. The default policy implies the default subscription filtering policy. The default policy
is: is:
o Notifications are generated every time there is any change in the o Notifications are generated every time there is any change in the
state of the conference, where that change is in a piece of state of the conference.
information that the subscriber has indicated (using the "type"
Event header field parameter) an interest in receiving.
o Notifications do not normally contain full state; rather, they o Notifications do not normally contain full state; rather, they
only indicate the state that has changed. The exception is a only indicate the state that has changed. The exception is a
NOTIFY sent in response to a SUBSCRIBE. These NOTIFYs contain the NOTIFY sent in response to a SUBSCRIBE. These NOTIFYs contain the
full state of the information requested by the subscriber. full state of the information requested by the subscriber.
3.4 Subscription Duration 3.3 Subscription Duration
The default expiration time for a subscription to a conference is one The default expiration time for a subscription to a conference is one
hour. Once the conference ends, all subscriptions to that particular hour. Once the conference ends, all subscriptions to that particular
conference are terminated, with a reason of "noresource" [2]. conference are terminated, with a reason of "noresource" [2].
3.5 NOTIFY Bodies 3.4 NOTIFY Bodies
As described in RFC 3265 [2], the NOTIFY message will contain bodies As described in RFC 3265 [2], the NOTIFY message will contain bodies
that describe the state of the subscribed resource. This body is in a that describe the state of the subscribed resource. This body is in a
format listed in the Accept header field of the SUBSCRIBE, or a format listed in the Accept header field of the SUBSCRIBE, or a
package-specific default if the Accept header field was omitted from package-specific default if the Accept header field was omitted from
the SUBSCRIBE. the SUBSCRIBE.
In this event package, the body of the notification contains a In this event package, the body of the notification contains a
conference information document. This document describes the state of conference information document. This document describes the state of
a conference. All subscribers and notifiers MUST support the a conference. All subscribers and notifiers MUST support the
"application/conference-info+xml" data format described in Section 4. "application/conference-info+xml" data format described in Section 4.
The subscribe request MAY contain an Accept header field. If no such The subscribe request MAY contain an Accept header field. If no such
header field is present, it has a default value of "application/ header field is present, it has a default value of "application/
conference-info+xml". If the header field is present, it MUST include conference-info+xml". If the header field is present, it MUST include
"application/conference-info+xml", and MAY include any other types "application/conference-info+xml", and MAY include any other types
capable of representing dialog state. capable of representing dialog state.
Of course, the notifications generated by the server MUST be in one Of course, the notifications generated by the server MUST be in one
of the formats specified in the Accept header field in the SUBSCRIBE of the formats specified in the Accept header field in the SUBSCRIBE
request. request.
3.6 Notifier Processing of SUBSCRIBE Requests 3.5 Notifier Processing of SUBSCRIBE Requests
The conference information contains very sensitive information. The conference information contains very sensitive information.
Therefore, all subscriptions SHOULD be authenticated and then Therefore, all subscriptions SHOULD be authenticated and then
authorized before approval. Authorization policy is at the discretion authorized before approval. Authorization policy is at the discretion
of the administrator, as always. However, a few recommendations can of the administrator, as always. However, a few recommendations can
be made. be made.
It is RECOMMENDED that all users in the conference be allowed to It is RECOMMENDED that all users in the conference be allowed to
subscribe to the conference. subscribe to the conference.
3.7 Notifier Generation of NOTIFY Requests 3.6 Notifier Generation of NOTIFY Requests
Notifications SHOULD be generated for the conference whenever there Notifications SHOULD be generated for the conference whenever there
is a change in the state in any of the information types requested by is a change in the state in any of the information delivered to the
the subscriber. For "membership", these changes generally occur when subscriber.
a new participant joins, a participant leaves, and a dial-out attempt
succeeds or fails. For "dialog", these changes occur when a dialog is
created, terminated, or updated through a target refresh request. For
"basic-media", these changes occur when the media types receive by a
participant change. For "general", these changes occur when the
conference policy protocol URIs change.
3.8 Subscriber Processing of NOTIFY Requests The changes generally occur when a new participant joins, a
participant leaves, or a participant is put on-hold. Subject to a
local focus policy, changes in media types and other optional media
attributes MAY be reported by the focus. In addition, creation and
deletion of sidebars together with their rosters MAY be reported by
the focus, subject to its local policy.
3.7 Subscriber Processing of NOTIFY Requests
The SIP Events framework expects packages to specify how a subscriber The SIP Events framework expects packages to specify how a subscriber
processes NOTIFY requests in any package specific ways, and in processes NOTIFY requests in any package specific ways, and in
particular, how it uses the NOTIFY requests to contruct a coherent particular, how it uses the NOTIFY requests to contruct a coherent
view of the state of the subscribed resource. view of the state of the subscribed resource.
Typically, the NOTIFY for the conference package will only contain Typically, the NOTIFY for the conference package will only contain
information about those users whose state in the conference has information about those users whose state in the conference has
changed. To construct a coherent view of the total state of all changed. To construct a coherent view of the total state of all
users, a subscriber to the dialog package will need to combine users, a subscriber to the dialog package will need to combine
skipping to change at page 8, line 21 skipping to change at page 7, line 20
Notifications within this package can convey partial information; Notifications within this package can convey partial information;
that is, they can indicate information about a subset of the state that is, they can indicate information about a subset of the state
associated with the subscription. This means that an explicit associated with the subscription. This means that an explicit
algorithm needs to be defined in order to construct coherent and algorithm needs to be defined in order to construct coherent and
consistent state. The details of this mechanism are specific to the consistent state. The details of this mechanism are specific to the
particular document type. See Section 4.2 for information on particular document type. See Section 4.2 for information on
constructing coherent information from an application/ constructing coherent information from an application/
conference-info+xml document. conference-info+xml document.
3.9 Handling of Forked Requests 3.8 Handling of Forked Requests
By their nature, the conferences supported by this package are By their nature, the conferences supported by this package are
centralized. Therefore, SUBSCRIBE requests for a conference should centralized. Therefore, SUBSCRIBE requests for a conference should
not generally fork. Users of this package MUST NOT install more than not generally fork. Users of this package MUST NOT install more than
a single subscription as a result of a single SUBSCRIBE request. a single subscription as a result of a single SUBSCRIBE request.
3.10 Rate of Notifications 3.9 Rate of Notifications
For reasons of congestion control, it is important that the rate of For reasons of congestion control, it is important that the rate of
notifications not become excessive. As a result, it is RECOMMENDED notifications not become excessive. As a result, it is RECOMMENDED
that the server not generate notifications for a single subscriber at that the server not generate notifications for a single subscriber at
a rate faster than once every 5 seconds. a rate faster than once every 5 seconds.
3.11 State Agents 3.10 State Agents
Conference state is ideally maintained in the element in which the Conference state is ideally maintained in the element in which the
conference resides. Therefore, the elements that maintain the conference resides. Therefore, the elements that maintain the
conference are the ones best suited to handle subscriptions to it. conference are the ones best suited to handle subscriptions to it.
Therefore, the usage of state agents is NOT RECOMMENDED for this Therefore, the usage of state agents is NOT RECOMMENDED for this
package. package.
4. Conference Data Format 4. Conference Data Format
Conference information is an XML document [5] that MUST be Conference information is an XML document that MUST be well-formed
well-formed and SHOULD be valid. Dialog information documents MUST be and SHOULD be valid. Dialog information documents MUST be based on
based on XML 1.0 and MUST be encoded using UTF-8. This specification XML 1.0 and MUST be encoded using UTF-8. This specification makes use
makes use of XML namespaces for identifying dialog information of XML namespaces for identifying dialog information documents and
documents and document fragments. The namespace URI for elements document fragments. The namespace URI for elements defined by this
defined by this specification is a URN [6], using the namespace specification is a URN [4], using the namespace identifier 'ietf'
identifier 'ietf' defined by [7] and extended by [8]. This URN is: defined by [5] and extended by [6]. This URN is:
urn:ietf:params:xml:ns:conference-info urn:ietf:params:xml:ns:conference-info
A conference information document begins with the root element tag A conference information document begins with the root element tag
"conference-info". "conference-info".
4.1 Structute of the Format 4.1 Conference Information
Conference information begins with the top level element Conference information begins with the top level element
"conference-info". This element has three mandatory attributes: "conference-info". This element has three mandatory attributes:
version: This attribute allows the recipient of conference version: This attribute allows the recipient of conference
information documents to properly order them. Versions start at 0, information documents to properly order them. Versions start at 0
and increment by one for each new document sent to a subscriber. and increment by one for each new document sent to a subscriber.
Versions are scoped within a subscription. Versions MUST be Versions are scoped within a subscription. Versions MUST be
representable using a 32 bit integer. represented using a 32 bit integer.
state: This attribute indicates whether the document contains the state: This attribute indicates whether the document contains the
full conference information, or whether it contains only the full conference information, or whether it contains only the
information that has changed since the previous document information that has changed since the previous document
(partial). (partial).
entity: This attribute contains the conference URI that identifies entity: This attribute contains the conference URI that identifies
the conference being described in the document. the conference being described in the document.
The "conference-info" element has zero or more "conf-service" The "conference-info" element has zero or more "user" sub-elements
elements, which provide URIs for access conferencing services, such which contain information on the users in the conference. This is
as media policy and conference policy control. This is followed by followed by zero or more "sidebar" sub-elements which contain
zero or more "user" sub-elements which contain information on the information on the sidebars in the conference.
users in the conference.
4.1.1 Conferencing Service Element
The "conf-service" element contains a URI that can be used to access
some additional conferencing service. The element contains the
following attributes:
id: This attribute provides a unique identifier (unique within the 4.1.1 User Element
context of the subscription) for the service. The attribute is
mandatory.
type: This attribute contains a string which indicates the type of The user element has one mandatory attribute, "uri" that indicates
service. Defined values are "conf-policy", to indicate that the the URI for the user in the conference. This is a logical identifier,
URI is for manipulating the conference policy [17][18], not a machine specific one (i.e., it's taken from the authenticated
"media-policy", to indicate that the URI is for manipulating the identity of the participant). The optional attribute "display-name"
media policy [9], and "floor-control", to indicate that the URI is contains a display name for the user. The standard "xml:lang"
for access to floor control services [19]. The attribute is language attribute can also be present to indicate the language of
mandatory. the display-name.
There MUST only be one conf-service for each type of service. 4.1.1.1 User Statuses
Additional service types may be defined in the future.
OPEN ISSUE: Once a protocol becomes solidified, we will need to Two optional status elements are defined: activity-status and history
add some additional content here. For example, if XCAP [16] is status. "Activity-status" provides information about user's current
used, the AUID should be provided here. We may want to move to a level of participation in the conference. "History-status", if
model where each service type is a unique XML element; that would present, provides information about the way the user joined or left
allow for the schema to impose the contraint on a single URI for the conference. Additional optional indication "is-on-dial-out-list"
each service type. completes the information about the user membership in the
conference.
The "conf-service" element is only provided in notifications if the The following statuses are defined for the activity-status element:
subscriber included the value of "general" in its "type" Event header
field parameter.
4.1.2 User Element connected: The user is a participant in the conference. Depending on
the media policies, he/she can send and receive media to and from
other participants.
Each user element has zero or one "status" elements, indicating their disconnected: The user is not a participant in the conference and no
status in the conference, zero or one "dialog" elements, indicating active dialog exists between the user and the focus.
their dialog information, and zero or one "media-streams" elements,
indicating their media reception information.
The user element has one mandatory attribute, "uri" that indicates on-hold: Active SIP dialog exists between a user and a focus, but
the URI for the user in the conference. This is a logical identifier, user is "on-hold" for this conference. As an example, the user has
not a machine specific one (i.e., its taken from the authenticated asked to join the conference using SIP, but his/her participation
identity of the participant). The optional attribute "display-name" is pending based on moderator approval. In the meantime he/she is
contains a display name for the user. The standard "xml:lang" hearing music-on-hold or some other kind of related content.
language attribute can also be present to indicate the language of
the display name.
4.1.3 Status The following statuses are defined for the history-status element:
The status element contains the status of the user in the conference. dialed-in: The user dialed into the conference, i.e. sent INVITE to
The following statuses are defined: the focus, which resulted in successful dialog establishment.
active: The user is in an active dialog with the focus. dialed-out: The focus has brought the user into the conference by
sending a successful INVITE to the user.
departed: The user sent a BYE, thus leaving the conference. departed: The user sent a BYE, thus leaving the conference.
booted: The user was sent a BYE by the conference host, booting them booted: The user was sent a BYE by the focus, booting him/her out of
out of the conference. the conference.
failed: The server tried to bring the user into the conference, but failed: The server tried to bring the user into the conference, but
its attempt to contact the specific user resulted in a non-200 its attempt to contact the specific user resulted in a non-200
class final response. class final response.
The "status" element is only provided in notifications if the 4.1.1.2 Media Stream Information
subscriber included the value of "membership" in its "type" Event
header field parameter.
4.1.4 Dialog Each user has zero or more "media-stream" sub-elements.
The dialog element is defined in [13]. It is presented from the Each "media-stream" element indicates the media stream that the user
viewpoint of the focus. The "dialog" element is only provided in is currently connected to. Here, "connected to" implies that a user
notifications if the subscriber included the value of "dialog" in its has a media line in their SDP [10]. With this definition, a user is
"type" Event header field parameter. connected to a media stream even if they are not sending any media.
4.1.5 Media Streams The "media-stream" element has a mandatory "media-type" attribute
which identifies the media type (e.g. audio, video, message and
application) and MUST have one of the values registered for "media"
of SDP [10].
The "media-streams" element indicates the media streams that the user The "media-stream" element has also an optional "proto" sub-element,
is currently connected to. Here, "connected to" implies that a user which MUST has the value registered for "proto" of SDP [10]).
has a media line in their SDP [20] which is associated with a media
stream managed by the focus (see Section 2.1 of [9]). With this
definition, a user is connected to a media stream even if they are
not sending any media.
The "media-streams" element has zero or more "media-stream" An optional "ssrc" sub-element, if present, carries the value of SSRC
sub-elements. The value of the "media-stream" element is an (RTP/RTCP [8]) as generated by the user for the stream it sends.
identifier, unique within the conference, which identifies the media
stream that a user is connected to [9]. The "media-stream" element
also has a mandatory "media-type" attribute which identifies the
media type (audio, video, message and application) of the media
stream.
The "media-streams" element is only provided in notifications if the When an RTP mixer generates a CSRC list according to RTP/RTCP [8], it
subscriber included the value of "basic-media" in its "type" Event inserts a list of the SSRC identifiers of the sources that
header field parameter. contributed to the generation of a particular packet into the RTP
header of that packet. "An example application is audio conferencing
where a mixer indicates all the talkers whose speech was combined to
produce the outgoing packet, allowing the receiver to indicate the
current talker, even though all the audio packets contain the same
SSRC identifier (that of the mixer)."
OPEN ISSUE: This needs to be aligned with the final media policy 4.1.2 Sidebar
mechanisms done in xcon. If we wish this draft to proceed
independently, we should probably remove any notion of media The sidebar element has one attribute - "entity" that indicates the
information. URI which identifiers the sidebar. A sidebar has zero or more users
that are of type "user-type" as the users of the main conference are.
4.2 Constructing Coherent State 4.2 Constructing Coherent State
The conference information subscriber maintains a table for the list The conference information subscriber maintains a table for the list
of users in the conference. The table contains a row for each user. of users in the conference. The table contains a row for each user.
Each row is indexed by a URI, present in the "uri" attribute of the Each row is indexed by a URI, present in the "uri" attribute of the
"user" element. The contents of each row contain the state of that "user" element. The contents of each row contain the state of that
user as conveyed in the document. The subscriber also maintains a user as conveyed in the document.
table for the service URIs in the conference. This table contains a
row for each service type. Each row is indexed by a token, present in
the "id" attribute of the "conf-service" element. The contents of the
row contain the URI and type of that service.
Both tables are associated with a version number. The version number The table is associated with a version number. The version number
MUST be initialized with the value of the "version" attribute from MUST be initialized with the value of the "version" attribute from
the "conference-info" element in the first document received. Each the "conference-info" element in the first document received. Each
time a new document is received, the value of the local version time a new document is received, the value of the local version
number, and the "version" attribute in the new document, are number, and the "version" attribute in the new document, are
compared. If the value in the new document is one higher than the compared. If the value in the new document is one higher than the
local version number, the local version number is increased by one, local version number, the local version number is increased by one,
and the document is processed. If the value in the document is more and the document is processed. If the value in the document is more
than one higher than the local version number, the local version than one higher than the local version number, the local version
number is set to the value in the new document, the document is number is set to the value in the new document, the document is
processed, and the subscriber SHOULD generate a refresh request to processed, and the subscriber SHOULD generate a refresh request to
trigger a full state notification. If the value in the document is trigger a full state notification. If the value in the document is
less than the local version, the document is discarded without less than the local version, the document is discarded without
processing. processing.
The processing of the conference information document depends on The processing of the conference information document depends on
whether it contains full or partial state. If it contains full state, whether it contains full or partial state. If it contains full state,
indicated by the value of the "state" attribute in the indicated by the value of the "state" attribute in the
"conference-info" element, the contents of both tables are flushed. "conference-info" element, the contents of the table is flushed. It
They are repopulated from the document. A new row in the user table is repopulated from the document. A new row in the user table is
is created for each "user" element, and a new row in the conferencing created for each "user" element. If the document contains partial
services table is created for each "conf-service" element. If the state, as indicated by the value of the "state" attribute in the
document contains partial state, as indicated by the value of the "conference-info" element, the document is used to update the table.
"state" attribute in the "conference-info" element, the document is For each "user" element in the document, the subscriber checks to see
used to update the tables. For each "user" element in the document, whether a row exists for that user in the user table. This check is
the subscriber checks to see whether a row exists for that user in done by comparing the URI in the "uri" attribute of the "user"
the user table. This check is done by comparing the URI in the "uri" element with the URI associated with the row. If the user doesn't
attribute of the "user" element with the URI associated with the row. exist in the table, a row is added, and its state is set to the
If the user doesn't exist in the table, a row is added, and its state information from that "user" element. If the user does exist, its
is set to the information from that "user" element. If the user does state is updated to be the information from that "user" element. If a
exist, its state is updated to be the information from that "user" row is updated or created, such that its state is now disconnected,
element. If a row is updated or created, such that its state is now
booted, failed or departed, that entry MAY be removed from the table booted, failed or departed, that entry MAY be removed from the table
at any time. at any time.
Similarly, for each each "conf-service" element in the document, the
subscriber checks to see whether a row exists for that service in the
service table. This check is done by comparing the id in the "id"
attribute of the "conf-service" element with the id associated with
the row. If the service doesn't exist in the table, a row is added,
and its URI and type are set to be the information from the
"conf-service" element. Since it is not expected that this
information will change during the lifetime of the conference, there
is no way to indicate removal of a service.
OPEN ISSUE: Is this really the right way to bootstrap these URIs?
The information really is static, and placing it in an event
package will result in a waste of bandwidth during full-state
updates.
4.3 Schema 4.3 Schema
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema <xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-info" xmlns:tns="urn:ietf:params:xml:ns:conference-info" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:conference-info" elementFormDefault="qualified" attributeFormDefault="unqualified">
targetNamespace="urn:ietf:params:xml:ns:conference-info" <!--
xmlns:tns="urn:ietf:params:xml:ns:conference-info" This import brings in the XML language attribute xml:lang
xmlns:xs="http://www.w3.org/2001/XMLSchema" -->
xmlns:di="urn:ietf:params:xml:ns:dialog-info" <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/03/xml.xsd" />
xmlns="urn:ietf:params:xml:ns:conference-info"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<!-- This import brings in the dialog-info element dialog-->
<xs:import namespace="urn:ietf:params:xml:ns:dialog-info"
schemaLocation="dialog-info.xsd"/>
<xs:element name="conference-info"> <xs:element name="conference-info">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="conf-service" type="tns:conf-serviceType" <xs:element name="user" type="user-type" minOccurs="0" maxOccurs="unbounded" />
minOccurs="0" maxOccurs="unbounded"/> <xs:element name="sidebar" type="sidebar-type" minOccurs="0" maxOccurs="unbounded" />
<xs:element name="user" type="user-type" <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded" />
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="version" type="xs:nonNegativeInteger" <xs:attribute name="version" type="xs:nonNegativeInteger" use="required" />
use="required"/>
<xs:attribute name="state" use="required"> <xs:attribute name="state" use="required">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="full"/> <xs:enumeration value="full"/>
<xs:enumeration value="partial"/> <xs:enumeration value="partial"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
<xs:attribute name="entity" type="xs:anyURI" use="required"/> <xs:attribute name="entity" type="xs:anyURI" use="required"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:complexType name="user-type"> <xs:complexType name="user-type">
<xs:sequence> <xs:sequence>
<xs:element name="status" type="tns:status-type" minOccurs="0"/> <xs:element name="activity-status" type="tns:activity-status-type" minOccurs="0" />
<xs:element ref="di:dialog" minOccurs="0"/> <xs:element name="history-status" type="tns:history-status-type" minOccurs="0" />
<xs:element name="media-streams" minOccurs="0"> <xs:element name="is-on-dial-out-list" type="xs:boolean" minOccurs="0" />
<xs:complexType name="media-status-type"> <xs:element name="media-stream" type="tns:media-stream-type" minOccurs="0" maxOccurs="unbounded" />
<xs:sequence> <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded" />
<xs:element name="media-stream"
type="tns:media-stream-type"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence> </xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required"/> <xs:attribute name="uri" type="xs:anyURI" use="required"/>
<xs:attribute name="display-name" type="xs:string" use="optional"/> <xs:attribute name="display-name" type="xs:string" use="optional"/>
<xs:attribute ref="xml:lang" use="optional"/> <xs:attribute ref="xml:lang" use="optional"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="media-stream-type">
<xs:simpleContent> <xs:complexType name="sidebar-type">
<xs:extension base="xs:string"> <xs:sequence>
<xs:attribute name="media-type" type="tns:mimetypes" <xs:element name="user" type="user-type" minOccurs="0" maxOccurs="unbounded" />
use="required"/> <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded" />
</xs:extension> </xs:sequence>
</xs:simpleContent>
<xs:attribute name="entity" type="xs:anyURI" use="required" />
</xs:complexType> </xs:complexType>
<xs:simpleType name="mimetypes">
<xs:restriction base="xs:string"> <xs:complexType name="media-stream-type">
<xs:enumeration value="audio"/> <xs:sequence>
<xs:enumeration value="video"/> <xs:element name="proto" type="xs:string" minOccurs="0" />
<xs:enumeration value="message"/> <xs:element name="ssrc" type="xs:nonNegativeInteger" minOccurs="0" />
<xs:enumeration value="application"/> <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded" />
</xs:restriction> </xs:sequence>
</xs:simpleType> <xs:attribute name="media" type="xs:string" use="required" />
<xs:complexType name="conf-serviceType">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="type" type="tns:typeType" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:simpleType name="typeType">
<xs:simpleType name="activity-status-type">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="conf-policy"/> <xs:enumeration value="connected" />
<xs:enumeration value="media-policy"/> <xs:enumeration value="disconnected" />
<xs:enumeration value="floor-control"/> <xs:enumeration value="on-hold" />
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="status-type">
<xs:simpleType name="history-status-type">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="active"/> <xs:enumeration value="dialed-in" />
<xs:enumeration value="dialed-out" />
<xs:enumeration value="departed"/> <xs:enumeration value="departed"/>
<xs:enumeration value="booted"/> <xs:enumeration value="booted"/>
<xs:enumeration value="failed"/> <xs:enumeration value="failed"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
4.4 Example 4.4 Example
The following is an example conference information document: The following is an example conference information document:
<conference-info version="0" state="full" entity="sip:conf233@example.com"> <conference-info version="0" state="full" entity="sip:conf233@example.com">
<user uri="sip:jdrosen@example.com" display-name="Jonathan Rosenberg"> <user uri="sip:bob@example.com" display-name="Bob Jones">
<status>active</status> <activity-status>connected</activity-status>
<media-streams> <history-status>dialed-in</history-status>
<media-stream media-type="audio">8hha7</media-stream> <media-stream media-type="audio"
</media-streams> <proto> RTP/AVP <proto>
<ssrc> 583398 <ssrc>
</media-stream>
</user> </user>
<user uri="sip:hgs@example.com" display-name="Henning Schulzrinne">
<status>active</status> <user uri="sip:barbara@example.com" display-name="Barbara Jones">
<activity-status>on-hold</activity-status>
</user> </user>
<user uri="sip:bill@example.com" display-name="Bill Minelli">
<activity-status>on-hold</activity-status>
</user>
<sidebar entity="sip:conf233.1@example.com">
<user>uri="sip:barbara@example.com"</user>
<user>uri="sip:bill@example.com"</user>
</sidebar>
</conference-info> </conference-info>
This document describes a conference with two users, both of which This document describes a conference with three users, two of which
are active. are in a sidebar conversation.
5. Security Considerations 5. Security Considerations
Subscriptions to conference state can reveal very sensitive Subscriptions to conference state can reveal very sensitive
information. For this reason, the document recommends authentication information. For this reason, the document recommends authentication
and authorization, and provides guidelines on sensible authorization and authorization, and provides guidelines on sensible authorization
policies. policies.
Since the data in notifications is sensitive as well, end-to-end SIP Since the data in notifications is sensitive as well, end-to-end SIP
encryption mechanisms using S/MIME SHOULD be used to protect it. encryption mechanisms using S/MIME SHOULD be used to protect it.
skipping to change at page 17, line 35 skipping to change at page 16, line 35
6.2 application/conference-info+xml MIME Registration 6.2 application/conference-info+xml MIME Registration
MIME media type name: application MIME media type name: application
MIME subtype name: conference-info+xml MIME subtype name: 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 RFC 3023 [10]. specified in RFC 3023 [7].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [10]. application/xml as specified in RFC 3023 [7].
Security considerations: See Section 10 of RFC 3023 [10] and Section Security considerations: See Section 10 of RFC 3023 [7] and Section 5
5 of this specification. of this specification.
Interoperability considerations: none. Interoperability considerations: none.
Published specification: This document. Published specification: This document.
Applications which use this media type: This document type has been Applications which use this media type: This document type has been
used to support SIP conferencing applications. used to support SIP conferencing applications.
Additional Information: Additional Information:
skipping to change at page 18, line 24 skipping to change at page 17, line 24
Rosenberg, <jdrosen@jdrosen.net> Rosenberg, <jdrosen@jdrosen.net>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF.
6.3 URN Sub-Namespace Registration for 6.3 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:conference-info urn:ietf:params:xml:ns:conference-info
This section registers a new XML namespace, as per the guidelines in This section registers a new XML namespace, as per the guidelines in
[8]. [6].
URI: The URI for this namespace is URI: The URI for this namespace is
urn:ietf:params:xml:ns:conference-info. urn:ietf:params:xml:ns:conference-info.
Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>, Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>,
Jonathan Rosenberg <jdrosen@jdrosen.net>. Jonathan Rosenberg <jdrosen@jdrosen.net>.
XML: XML:
BEGIN BEGIN
<?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>Dialog Information Namespace</title> <title>Conference Information Namespace</title>
</head </head
<body> <body>
<h1>Namespace for Dialog Information</h1> <h1>Namespace for Conference Information</h1>
<h2>urn:ietf:params:xml:ns:conference-info</h2> <h2>urn:ietf:params:xml:ns:conference-info</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
6.4 XML Schema Registration 6.4 XML Schema Registration
This specification registers a schema, as per the guidelines in in This specification registers a schema, as per the guidelines in in
[8]. [6].
URI: please assign. URI: please assign.
Registrant Contact: IETF, SIPPING Working Group Registrant Contact: IETF, SIPPING Working Group
(sipping@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net). (sipping@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
XML: The XML can be found as the sole content of Section 4.3. XML: The XML can be found as the sole content of Section 4.3.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Dan Petrie and Sean Olson for their The authors would like to thank Dan Petrie and Sean Olson for their
comments. comments.
8. Changes since -01
o Package parameters are removed. Decision about performing
"recursive" membership algorithm is perceived as a focus local
policy.
o General information (i.e. pointers to additional available
services) is removed. The defined XML schema can be extended in
future to include those when XCON work matures.
o Dialog information is removed. It can be obtained by direct
subscription to a dialog package of a participant.
o Media stream information is aligned with SDP definitions (media
and proto) and SSRC attribute is added.
o Participant's status is expressed using two optional statuses:
"activity" and "history". Optional "is-on-a-dial-out-list"
indication is added.
o Normative references to XCON work are removed.
o Optional sidebar rosters are added.
Normative References Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[4] Rosenberg, J., "Indicating User Agent Capabilities in the [4] Moats, R., "URN Syntax", RFC 2141, May 1997.
Session Initiation Protocol (SIP)",
draft-ietf-sip-callee-caps-00 (work in progress), June 2003.
[5] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
REC REC-xml-20001006, October 2000.
[6] Moats, R., "URN Syntax", RFC 2141, May 1997.
[7] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, [5] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999. August 1999.
[8] Mealling, M., "The IETF XML Registry", [6] Mealling, M., "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-05 (work in progress), June draft-mealling-iana-xmlns-registry-05 (work in progress), June
2003. 2003.
[9] Mahy, R. and N. Ismail, "Media Policy Manipulation in the [7] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
Conference Policy Control Protocol",
draft-mahy-xcon-media-policy-control-00 (work in progress),
June 2003.
[10] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001. 3023, January 2001.
Informative References [8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
[11] Rosenberg, J., "A Presence Event Package for the Session 3550, July 2003.
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
in progress), January 2003.
[12] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)",
draft-ietf-simple-winfo-package-05 (work in progress), January
2003.
[13] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog
Event Package for the Session Initiation Protocol (SIP",
draft-ietf-sipping-dialog-package-01 (work in progress), March
2003.
[14] Mahy, R., "A Message Summary and Message Waiting Indication Informative References
Event Package for the Session Initiation Protocol (SIP)",
draft-ietf-sipping-mwi-03 (work in progress), July 2003.
[15] Rosenberg, J., "A Framework for Conferencing with the Session [9] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol", Initiation Protocol",
draft-ietf-sipping-conferencing-framework-00 (work in draft-ietf-sipping-conferencing-framework-00 (work in
progress), May 2003. progress), May 2003.
[16] Rosenberg, J., "The Extensible Markup Language (XML) [10] Handley, M. and V. Jacobson, "SDP: Session Description
Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-00 (work in progress), June 2003.
[17] Koskelainen, P. and H. Khartabil, "An Extensible Markup
Language (XML) Configuration Access Protocol (XCAP) Usage for
Conference Policy Manipulation",
draft-koskelainen-xcon-xcap-cpcp-usage-00 (work in progress),
June 2003.
[18] Levin, O., "Conference Policy Control Protocol for Centralized
Conferencing", draft-levin-xcon-cpcp-00 (work in progress),
June 2003.
[19] Wu, X., "Use of Session Initiation Protocol (SIP) and Simple
Object Access Protocol (SOAP) for Conference Floor Control
Protocol (SOAP) for Conference Floor Control",
draft-wu-sipping-floor-control-04 (work in progress), March
2003.
[20] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
Authors' Addresses Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
skipping to change at page 24, line 5 skipping to change at page 22, line 37
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
M/S 0401 M/S 0401
1214 Amsterdam Ave. 1214 Amsterdam Ave.
New York, NY 10027 New York, NY 10027
US US
EMail: schulzrinne@cs.columbia.edu EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs URI: http://www.cs.columbia.edu/~hgs
Orit Levin (editor)
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
EMail: oritl@microsoft.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
skipping to change at page 25, line 7 skipping to change at page 24, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/