idnits 2.17.1 

draft-ietf-sipping-conference-package-10.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** It looks like you're using RFC 3978 boilerplate.  You should update this
     to the boilerplate described in the IETF Trust License Policy document
     (see https://trustee.ietf.org/license-info), which is required now.

  -- Found old boilerplate from RFC 3978, Section 5.1.a on line 20.

  -- Found old boilerplate from RFC 3978, Section 5.5 on line 1908.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1885.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1892.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1898.

  ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
     Acknowledgement. 

  ** This document has an original RFC 3978 Section 5.4 Copyright Line,
     instead of the newer IETF Trust Copyright according to RFC 4748.

  ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
     of the newer disclaimer which includes the IETF Trust according to RFC
     4748.

  ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
     instead of verbatim RFC 3978 boilerplate.  After 6 May 2005, submission
     of drafts without verbatim RFC 3978 boilerplate is not accepted.

     The following non-3978 patterns matched text found in the document. 
     That text should be removed or replaced:

        This document is an Internet-Draft and is subject to all provisions of
        Section 3 of RFC 3667.

        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.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard

  == It seems as if not all pages are separated by form feeds - found 0 form
     feeds but 43 pages


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 60 instances of too long lines in the document, the longest
     one being 207 characters in excess of 72.

  ** There are 311 instances of lines with control characters in the document.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
     it appears to use RFC 2119 keywords. 

     (The document does seem to have the reference to RFC 2119 which the
     ID-Checklist requires).
  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (March 25, 2005) is 6971 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: 'RFC XXXX' on line 1746

  == Unused Reference: '16' is defined on line 1818, but no explicit
     reference was found in the text

  == Unused Reference: '21' is defined on line 1838, but no explicit
     reference was found in the text

  ** Obsolete normative reference: RFC 2141 (ref. '2') (Obsoleted by RFC 8141)

  ** Obsolete normative reference: RFC 2327 (ref. '3') (Obsoleted by RFC 4566)

  ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226)

  ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '6')

  ** Obsolete normative reference: RFC 3023 (ref. '7') (Obsoleted by RFC 7303)

  ** Obsolete normative reference: RFC 3265 (ref. '9') (Obsoleted by RFC 6665)

  -- Obsolete informational reference (is this intentional?): RFC 2326 (ref.
     '14') (Obsoleted by RFC 7826)

  -- Obsolete informational reference (is this intentional?): RFC 3388 (ref.
     '16') (Obsoleted by RFC 5888)

  == Outdated reference: A later version (-05) exists of
     draft-ietf-sipping-conferencing-framework-04

  == Outdated reference: A later version (-06) exists of
     draft-ietf-sipping-dialog-package-05

  == Outdated reference: A later version (-15) exists of
     draft-ietf-sip-gruu-03


     Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------

1	SIPPING                                                     J. Rosenberg
2	Internet-Draft                                             Cisco Systems
3	Expires: September 26, 2005                               H. Schulzrinne
4	                                                     Columbia University
5	                                                           O. Levin, Ed.
6	                                                   Microsoft Corporation
7	                                                          March 25, 2005

9	    A Session Initiation Protocol (SIP) Event Package for Conference
10	                                 State
11	                draft-ietf-sipping-conference-package-10

13	Status of this Memo

15	   This document is an Internet-Draft and is subject to all provisions
16	   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
17	   author represents that any applicable patent or other IPR claims of
18	   which he or she is aware have been or will be disclosed, and any of
19	   which he or she become aware will be disclosed, in accordance with
20	   RFC 3668.

22	   Internet-Drafts are working documents of the Internet Engineering
23	   Task Force (IETF), its areas, and its working groups.  Note that
24	   other groups may also distribute working documents as
25	   Internet-Drafts.

27	   Internet-Drafts are draft documents valid for a maximum of six months
28	   and may be updated, replaced, or obsoleted by other documents at any
29	   time.  It is inappropriate to use Internet-Drafts as reference
30	   material or to cite them other than as "work in progress."

32	   The list of current Internet-Drafts can be accessed at
33	   http://www.ietf.org/ietf/1id-abstracts.txt.

35	   The list of Internet-Draft Shadow Directories can be accessed at
36	   http://www.ietf.org/shadow.html.

38	   This Internet-Draft will expire on September 26, 2005.

40	Copyright Notice

42	   Copyright (C) The Internet Society (2005).

44	Abstract

46	   This document defines a conference event package for the Session
47	   Initiation Protocol (SIP) Events framework, along with a data format
48	   used in notifications for this package.  The conference package
49	   allows users to subscribe to a conference URI.  Notifications are
50	   sent about changes in the membership of this conference and
51	   optionally about changes in the state of additional conference
52	   components.

54	Table of Contents

56	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
57	   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
58	   3.  Conference Event Package . . . . . . . . . . . . . . . . . . .  4
59	     3.1   Event Package Name . . . . . . . . . . . . . . . . . . . .  4
60	     3.2   SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . .  5
61	     3.3   Subscription Duration  . . . . . . . . . . . . . . . . . .  5
62	     3.4   NOTIFY Bodies  . . . . . . . . . . . . . . . . . . . . . .  5
63	     3.5   Notifier Processing of SUBSCRIBE Requests  . . . . . . . .  6
64	     3.6   Notifier Generation of NOTIFY Requests . . . . . . . . . .  6
65	     3.7   Subscriber Processing of NOTIFY Requests . . . . . . . . .  6
66	     3.8   Handling of Forked Requests  . . . . . . . . . . . . . . .  7
67	     3.9   Rate of Notifications  . . . . . . . . . . . . . . . . . .  7
68	     3.10  State Agents . . . . . . . . . . . . . . . . . . . . . . .  7
69	   4.  Conference Document  . . . . . . . . . . . . . . . . . . . . .  7
70	     4.1   Format . . . . . . . . . . . . . . . . . . . . . . . . . .  7
71	     4.2   Namespace  . . . . . . . . . . . . . . . . . . . . . . . .  7
72	     4.3   Versioning . . . . . . . . . . . . . . . . . . . . . . . .  7
73	     4.4   Partial Notifications Mechanism  . . . . . . . . . . . . .  8
74	     4.5   Element Keys . . . . . . . . . . . . . . . . . . . . . . .  9
75	     4.6   Constructing Coherent State Procedure  . . . . . . . . . .  9
76	   5.  Conference Data  . . . . . . . . . . . . . . . . . . . . . . . 10
77	     5.1   <conference-info>  . . . . . . . . . . . . . . . . . . . . 11
78	     5.2   <conference-description> . . . . . . . . . . . . . . . . . 11
79	       5.2.1   <conf-uris>  . . . . . . . . . . . . . . . . . . . . . 12
80	       5.2.2   <service-uris> . . . . . . . . . . . . . . . . . . . . 13
81	       5.2.3   <maximum-user-count> . . . . . . . . . . . . . . . . . 13
82	       5.2.4   <available-media>  . . . . . . . . . . . . . . . . . . 13
83	     5.3   <host-info>  . . . . . . . . . . . . . . . . . . . . . . . 14
84	       5.3.1   <display-text> . . . . . . . . . . . . . . . . . . . . 14
85	       5.3.2   <web-page> . . . . . . . . . . . . . . . . . . . . . . 14
86	       5.3.3   <uris> . . . . . . . . . . . . . . . . . . . . . . . . 14
87	     5.4   <conference-state> . . . . . . . . . . . . . . . . . . . . 14
88	       5.4.1   <user-count> . . . . . . . . . . . . . . . . . . . . . 14
89	       5.4.2   <active> . . . . . . . . . . . . . . . . . . . . . . . 15
90	       5.4.3   <locked> . . . . . . . . . . . . . . . . . . . . . . . 15
91	     5.5   <users> of <user>  . . . . . . . . . . . . . . . . . . . . 15
92	       5.5.1   <display-text> . . . . . . . . . . . . . . . . . . . . 16
93	       5.5.2   <associated-aors>  . . . . . . . . . . . . . . . . . . 16
94	       5.5.3   <roles>  . . . . . . . . . . . . . . . . . . . . . . . 16
95	       5.5.4   <language> . . . . . . . . . . . . . . . . . . . . . . 16
96	       5.5.5   <cascaded-focus> . . . . . . . . . . . . . . . . . . . 16
97	       5.5.6   <endpoint> . . . . . . . . . . . . . . . . . . . . . . 16
98	     5.6   <endpoint> . . . . . . . . . . . . . . . . . . . . . . . . 17
99	       5.6.1   <display-text> . . . . . . . . . . . . . . . . . . . . 17
100	       5.6.2   <referred> . . . . . . . . . . . . . . . . . . . . . . 17
101	       5.6.3   <status> . . . . . . . . . . . . . . . . . . . . . . . 18
102	       5.6.4   <joining-method> . . . . . . . . . . . . . . . . . . . 19
103	       5.6.5   <joining-info> . . . . . . . . . . . . . . . . . . . . 19
104	       5.6.6   <disconnection-method> . . . . . . . . . . . . . . . . 19
105	       5.6.7   <disconnection-info> . . . . . . . . . . . . . . . . . 20
106	       5.6.8   <media>  . . . . . . . . . . . . . . . . . . . . . . . 20
107	       5.6.9   <call-info>  . . . . . . . . . . . . . . . . . . . . . 20
108	     5.7   <media>  . . . . . . . . . . . . . . . . . . . . . . . . . 21
109	       5.7.1   <display-text> . . . . . . . . . . . . . . . . . . . . 21
110	       5.7.2   <type> . . . . . . . . . . . . . . . . . . . . . . . . 21
111	       5.7.3   <label>  . . . . . . . . . . . . . . . . . . . . . . . 21
112	       5.7.4   <src-id> . . . . . . . . . . . . . . . . . . . . . . . 21
113	       5.7.5   <status> . . . . . . . . . . . . . . . . . . . . . . . 22
114	     5.8   <sidebars-by-ref>  . . . . . . . . . . . . . . . . . . . . 22
115	     5.9   <sidebar-by-val> . . . . . . . . . . . . . . . . . . . . . 22
116	   6.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 22
117	   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
118	     7.1   Basic Example  . . . . . . . . . . . . . . . . . . . . . . 30
119	     7.2   Rich Example . . . . . . . . . . . . . . . . . . . . . . . 32
120	   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 35
121	   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 36
122	     9.1   conference Event Package Registration  . . . . . . . . . . 36
123	     9.2   application/conference-info+xml MIME Registration  . . . . 36
124	     9.3   URN Sub-Namespace Registration for
125	           urn:ietf:params:xml:ns:conference-info . . . . . . . . . . 37
126	     9.4   XML Schema Registration  . . . . . . . . . . . . . . . . . 38
127	     9.5   URI Purposes Sub-registry Establishment  . . . . . . . . . 38
128	   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
129	   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 39
130	     11.1  Normative References . . . . . . . . . . . . . . . . . . . 39
131	     11.2  Informative References . . . . . . . . . . . . . . . . . . 40
132	       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41
133	       Intellectual Property and Copyright Statements . . . . . . . . 43

135	1.  Introduction

137	   The Session Initiation Protocol (SIP) Events Framework [9] defines
138	   general mechanisms for subscribing to, and receiving notifications
139	   of, events within SIP networks.  It introduces the notion of a
140	   package, which is a specific "instantiation" of the events framework
141	   for a well-defined set of events.  Here, we define an event package
142	   for SIP conferences.  This package provides the conference
143	   notification service as outlined in the SIP conferencing framework
144	   [19].  As described there, subscriptions to a conference URI are
145	   routed to the focus that is handling the conference.  It acts as the
146	   notifier, and provides clients with updates on conference state.

148	   The information provided by this package is comprised of conference
149	   identifier(s), conference participants (optionally with their
150	   statuses and media description), conference sidebars, conference
151	   service URIs, etc.

153	2.  Terminology

155	   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
156	   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
157	   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
158	   indicate requirement levels for compliant implementations.

160	3.  Conference Event Package

162	   The conference event package allows a user to subscribe to a
163	   conference.  In SIP, conferences are represented by URIs.  These URIs
164	   route to a SIP user agent, called a focus, that is responsible for
165	   ensuring that all users in the conference can communicate with each
166	   other, as described in Conferencing Framework [19].  The focus has
167	   sufficient information about the state of the conference to inform
168	   subscribers about it.

170	   It is possible that a participant in the conference may in fact be
171	   another focus.  In order to provide a more complete participant list,
172	   the focus MAY subscribe to the conference package of the other focus
173	   to discover the participant list in the cascaded conference.  This
174	   information can then be included in notifications by use of the
175	   <cascaded-focus> element as specified by this package.

177	   This section provides the details for defining a SIP-specific event
178	   notification package, as specified by RFC 3265 [9].

180	3.1  Event Package Name

182	   The name of this event package is "conference".  This package name is
183	   carried in the Event and Allow-Events header, as defined in RFC 3265
184	   [9].

186	3.2  SUBSCRIBE Bodies

188	   A SUBSCRIBE for a conference package MAY contain a body.  This body
189	   defines a filter to apply to the subscription.  Filter documents are
190	   not specified in this document, and at the time of writing, are
191	   expected to be the subject of future standardization activity.

193	   A SUBSCRIBE for a conference package MAY be sent without a body.
194	   This implies the default subscription filtering policy.  The default
195	   policy is:
196	   o  Notifications are generated every time there is any change in the
197	      state of the conference.
198	   o  Notifications do not normally contain full state; rather, they
199	      only indicate the state that has changed.  The exception is a
200	      NOTIFY sent in response to a SUBSCRIBE.  These NOTIFYs contain the
201	      full state of the information requested by the subscriber.

203	3.3  Subscription Duration

205	   The default expiration time for a subscription to a conference is one
206	   hour.  Once the conference ends, all subscriptions to that particular
207	   conference are terminated, with a reason of "noresource" as defined
208	   in RFC 3265 [9].

210	3.4  NOTIFY Bodies

212	   As described in RFC 3265 [9], the NOTIFY message will contain bodies
213	   that describe the state of the subscribed resource.  This body is in
214	   a format listed in the Accept header field of the SUBSCRIBE, or a
215	   package-specific default if the Accept header field was omitted from
216	   the SUBSCRIBE.

218	   In this event package, the body of the notification contains a
219	   conference information document.  This document describes the state
220	   of a conference.  All subscribers and notifiers MUST support the
221	   "application/conference-info+xml" data format described in Section 5.
222	   The subscribe request MAY contain an Accept header field.  If no such
223	   header field is present, it has a default value of
224	   "application/conference-info+xml".  If the header field is present,
225	   it MUST include "application/conference-info+xml", and MAY include
226	   any other types.

228	   Of course, the notifications generated by the server MUST be in one
229	   of the formats specified in the Accept header field in the SUBSCRIBE
230	   request.

232	3.5  Notifier Processing of SUBSCRIBE Requests

234	   The conference information contains very sensitive information.
235	   Therefore, all subscriptions SHOULD be authenticated and then
236	   authorized before approval.  Authorization policy is at the
237	   discretion of the administrator, as always.  However, a few
238	   recommendations can be made.

240	   It is RECOMMENDED that all users in the conference be allowed to
241	   subscribe to the conference event package.

243	3.6  Notifier Generation of NOTIFY Requests

245	   Notifications SHOULD be generated for the conference state when a new
246	   participant joins (i.e.  gets "connected" to) or a participant leaves
247	   (i.e.  gets "disconnected" from) the conference.

249	   Subject to a local focus policy, additional changes in participants'
250	   status, changes in their media types, and other optional information
251	   MAY be reported by the focus.

253	   Changes in sidebar rosters SHOULD be reported by the focus to their
254	   participants and MAY be reported to others, subject to local policy.

256	   Changes in conference identifiers and service URIs SHOULD be reported
257	   by the focus to the Conference package subscribers.

259	   Changes in other conference state information MAY be reported by the
260	   focus to the Conference package subscribers.

262	3.7  Subscriber Processing of NOTIFY Requests

264	   The SIP Events framework expects packages to specify how a subscriber
265	   processes NOTIFY requests in any package specific ways, and in
266	   particular, how it uses the NOTIFY requests to construct a coherent
267	   view of the state of the subscribed resource.

269	   Typically, the NOTIFY for the conference package will only contain
270	   information about those users whose state in the conference has
271	   changed.  To construct a coherent view of the total state of all
272	   users, a subscriber to the conference package will need to combine
273	   NOTIFYs received over time.

275	   Notifications within this package can convey partial information;
276	   that is, they can indicate information about a subset of the state
277	   associated with the subscription.  This means that an explicit
278	   algorithm needs to be defined in order to construct coherent and
279	   consistent state.  The details of this mechanism are specific to the
280	   particular document type.  See Section 4.6 for information on
281	   constructing coherent information from an
282	   application/conference-info+xml document.

284	3.8  Handling of Forked Requests

286	   By their nature, the conferences supported by this package are
287	   centralized.  Therefore, SUBSCRIBE requests for a conference should
288	   not generally fork.  Users of this package MUST NOT install more than
289	   a single subscription as a result of a single SUBSCRIBE request.

291	3.9  Rate of Notifications

293	   For reasons of congestion control, it is important that the rate of
294	   notifications not become excessive.  As a result, it is RECOMMENDED
295	   that the server doesn't generate notifications for a single
296	   subscriber at a rate faster than once every 5 seconds.

298	3.10  State Agents

300	   Conference state is ideally maintained in the element in which the
301	   conference resides.  Therefore, the elements that maintain the
302	   conference are the ones best suited to handle subscriptions to it.
303	   Therefore, the usage of state agents is NOT RECOMMENDED for this
304	   package.

306	4.  Conference Document

308	4.1  Format

310	   Conference information is an XML document that MUST be well-formed
311	   and valid.  It MUST be based on Extensible Markup Language (XML) 1.0
312	   and MUST be encoded using UTF-8 [12].

314	4.2  Namespace

316	   This specification makes use of XML namespaces for identifying
317	   conference information documents and document fragments.  The
318	   namespace URI for elements defined by this specification is a URN
319	   [2], using the namespace identifier 'ietf' defined by [6] and
320	   extended by RFC 3688 [13].  This URN is:

322	   urn:ietf:params:xml:ns:conference-info

324	4.3  Versioning

326	   The conference information is described by a hierarchal XML structure
327	   with the root element <conference-info>.  The root element is the
328	   only element in the schema that carries meaningful version number for
329	   all the elements in the document.  The whole conference information
330	   is associated with this version number.

332	   The 'version' attribute MUST be included in the root
333	   <conference-info> element.

335	4.4  Partial Notifications Mechanism

337	   This specification defines a basic partial notifications mechanism by
338	   using a 'state' attribute as described below.  This mechanism MUST be
339	   supported by all subscribing clients.  Additional general partial
340	   notifications mechanisms can be defined and applied to this package
341	   in the future.

343	   All sub-elements in the <conference-info> hierarchal XML structure
344	   can be classified in two groups: permissible for partial
345	   notifications or not.  Elements that carry a substantial amount of
346	   data that is subject to frequent changes are permissible for partial
347	   notifications and have a 'state' attribute attached to them.  All
348	   future extensions to this schema MUST define which extension elements
349	   can also use this mechanism.  All other elements can be updated as
350	   atomic pieces of data only.

352	   Below is the complete list of elements permissible to use the partial
353	   notifications mechanism defined in this specification.  (Note that
354	   future partial notifications mechanisms can potentially be applicable
355	   to additional elements.)

357	   o  Element <conference-info>
358	   o  Element <users>
359	   o  Element <user>
360	   o  Element <endpoint>
361	   o  Element <sidebars-by-val>
362	   o  Element <sidebars-by-ref>

364	   The 'state' attribute value indicates whether the reported
365	   information about the element is "full", "partial" or the element is
366	   "deleted" from the conference state document.  The default value of
367	   any 'state' attribute is "full".

369	   A 'state' attribute of a child element in the document MUST adhere to
370	   its parent 'state'.  It means that if the parent's 'state' is "full",
371	   the state of its children MUST be "full".  If the parent's 'state' is
372	   "partial", the state of its children MAY be either "partial", "full",
373	   or "deleted".

375	4.5  Element Keys

377	   The defined XML schema has a property of unique identification among
378	   sub-elements of a common parent, which makes it possible to use the
379	   partial notifications mechanism defined in this document.  This
380	   property is achieved by defining a key to each sub-element that can
381	   appear multiple times under the common parent.

383	   In the context of this specification, the element key is the set of
384	   mandatory attributes or sub-elements of an element.  The key value
385	   MUST be unique for the element among its siblings of the same type.

387	   In the context of this specification, the comparison rules for keys
388	   of type xs:anyURI are byte-by-byte (including all URI parameters that
389	   can be included with the URI).

391	   Below is the list of elements (subject to partial notifications of
392	   their parent elements) with their keys as defined by this
393	   specification:

395	   o  Element <user> uses as the key 'entity'
396	   o  Element <endpoint> uses as the key 'entity'
397	   o  Element <media> uses as the key 'id'
398	   o  Element <entry> (child to <sidebars-by-val>) uses as the key
399	      'entity'
400	   o  Element <sidebars-by-ref> uses as the key <uri>

402	4.6  Constructing Coherent State Procedure

404	   A conference package subscriber maintains a local version number, a
405	   local element for each element in the schema, and a table for each
406	   element with its key as defined above.

408	   The first time a NOTIFY with a "full" document is received (as
409	   indicated by the value of the 'state' attribute in the
410	   <conference-info> element), the conference package subscriber MUST
411	   set the local 'version' number to the value of the 'version'
412	   attribute from the received <conference-info> and populate local data
413	   with the received information.

415	   Each time a new NOTIFY is received, the value of the local version
416	   number and the value of the 'version' attribute in the new received
417	   document are compared.  If the value in the document is equal or less
418	   than the local version, the document is discarded without processing.

420	   Otherwise, if the received NOTIFY contains a "full" or "deleted"
421	   state, the conference package subscriber MUST set the local 'version'
422	   number to the value of the 'version' attribute from the received
423	   <conference-info> and replace the local information with the received
424	   document.  Receiving "deleted" state means that the conference ceased
425	   to exist and the subscriber SHOULD terminate the subscription by
426	   sending the SUBSCRIBE with Expires = 0.

428	   Otherwise (i.e.  if the received NOTIFY contains "partial" state), if
429	   the 'version' number in the received document is more than one number
430	   higher than the previous local version number, the subscriber MUST
431	   generate a subscription refresh request to trigger a full state
432	   notification.  If the 'version' number in the document is one higher
433	   than the local version number, the local version number is updated
434	   accordingly and the document is used to update the local content as
435	   described below.

437	   For each sub-element of the <conference-info> element in the received
438	   document,

440	   1.  If the element contains "full" state, the whole local element
441	   content is flushed and repopulated from the document.

443	   2.  Otherwise, if the element contains "deleted" state, the whole
444	   element MUST be removed from the local content.

446	   3.  Otherwise, if the element contains "partial" state:

448	   3.1 For elements with keys, the subscriber compares the keys received
449	   in the update with the keys in the local tables.

451	   3.1.1 If a key does not exist in the local table, a row is added, and
452	   its content is set to the element information from the update.

454	   3.1.2 Otherwise, if a key of the same value does exist, for each
455	   sub-element in the row the algorithm is applied from step 3.2.

457	   3.2 For each atomic element received in the schema, the element is
458	   replaced with the new information as a whole.  Also, for each
459	   non-atomic element received in the schema with either no 'state'
460	   attribute included or the state attribute is set to "full", the
461	   element is replaced with the new information as a whole.

463	   3.3 For each non-atomic element with the state attribute set to
464	   "partial", the algorithm is applied recursively starting from step
465	   3.1.

467	5.  Conference Data
468	5.1  <conference-info>

470	   A conference information document begins with the root element tag
471	   <conference-info> of conference-type.

473	   The following attributes are defined for <conference-info>:

475	   entity: This attribute contains the conference URI that identifies
476	      the conference being described in the document.

478	   state: This attribute indicates whether the document contains the
479	      whole conference information ("full"), only the information that
480	      has changed since the previous document ("partial"), or the
481	      conference ceased to exist ("deleted").  For more detail see
482	      Section 4.

484	   version: This attribute allows the recipient of conference
485	      information documents to properly order them and it MUST be
486	      included when used in the root <conference-info> element.  Version
487	      number is a 32 bit monotonically increasing integer scoped within
488	      a subscription.  A server MUST increment the version number by one
489	      for each new partial notification being sent to a subscriber.

491	   The <conference-info> element is comprised of
492	   <conference-description>, <host-info>, <conference-state>, <users>,
493	   <sidebar-by-ref> and <sidebars-by-val> child elements.  A "full"
494	   conference document MUST at least include the
495	   <conference-description> and <users> child elements.

497	   Following sections describe these elements in detail.  The full XML
498	   schema is provided in Section 6.

500	5.2  <conference-description>

502	   The <conference-description> element describes the conference as a
503	   whole.

505	   The child elements <display-text>, <subject>, <free-text>, and
506	   <keywords> are used to describe the conference content:

508	   <display-text>: Contains a text suitable for human consumption and
509	      directory listing

511	   <subject>: Contains the subject of the conference
512	   <free-text>: Contains an additional longer description of the
513	      conference

515	   <keywords>: Contains a list of comma-separated keywords that can be
516	      used by search engines to better classify the conference

518	   Additional child elements <conf-uris> and <service-uris> are used to
519	   describe the conference-related URIs; <maximum-user-count> and
520	   <available-media> are used to describe the overall characteristics.

522	   This information is typically derived from the system conference
523	   policies, is set before the conference activation, and is rarely
524	   changed during the conference lifetime.

526	   The following sections describe the remaining elements in more
527	   detail.  Other sub-elements can extend <conference-description> in
528	   the future.

530	5.2.1  <conf-uris>

532	   This element is a set of <entry> child elements - each containing the
533	   URI to be used in order to access the conference by different
534	   signaling means.  The value of the URI MUST be unique in the
535	   conference context and is included in the <uri> sub-element.

537	   Each <entry> can contain additional optional information useful to
538	   the participant when accessing the conference.

540	   An <entry> element MAY contain the <display-text> sub-element that
541	   provides a textual description meant for human consumption.

543	   Each <entry> element SHOULD contain a <purpose> sub-element that
544	   describes what happens when accessing the URI.  The currently defined
545	   <purpose> values to be used with the <conf-uris> are:

547	   participation: Accessing a URI with this <purpose> will bring the
548	      party into the conference
549	   streaming: Accessing a URI with this <purpose> will commence
550	      streaming the conference, but not allow active participation

552	   Examples of suitable URI schemes include sip: and sips: [8], h323:
553	   [18], and tel: [17] URIs.  The rtsp [14] URI is suitable for
554	   streaming.

556	   Future extensions to this schema may define new values and register
557	   them with IANA under the registry established by this specification.

559	5.2.2  <service-uris>

561	   This element describes auxiliary services available for the
562	   conference.  Like <conference-uris>, this element contains a set of
563	   <entry> child elements - each containing the URI to be used in order
564	   to access different services available for the particular conference.
565	   The value of the URI MUST be unique in the conference context and is
566	   included in the <uri> sub-element.

568	   An <entry> element MAY contain the <display-text> sub-element that
569	   provides a textual description meant for user consumption.

571	   Each <entry> element SHOULD contain a <purpose> sub-element.  The
572	   currently defined <purpose> values to be used with the <service-uris>
573	   are:

575	   web-page: Indicates the web page containing the additional
576	      information about the conference
577	   recording: Indicates the link at which the recorded conference
578	      context can be retrieved
579	   event: Indicates the URI to which the subscription to the conference
580	      event package needs to be performed.  This would typically be the
581	      conference URI of the main conference

583	   Future extensions to this schema may define new values and register
584	   them with IANA under the registry established by this specification.

586	5.2.3  <maximum-user-count>

588	   This element, if used, specifies the maximum number of users
589	   permitted in the conference.

591	5.2.4  <available-media>

593	   This element contains a sequence of <entry> child elements of
594	   conference-medium-type, each being indexed by the attribute 'label'.

596	   The 'label' attribute is the media stream identifier being assigned
597	   by the conferencing server such as its value is unique in the
598	   <conference-info> context.  The value of this attribute MAY
599	   correspond to the SDP "label" media attribute defined in [22].

601	   Each <entry> describes a single media stream available to the
602	   participants in the conference and contains the following
603	   information:

605	   <display-text> This element contains the display text for the media
606	      stream.

608	   <type> This element contains the media type of the media stream.  The
609	      value of this element MUST be one of the values registered for
610	      "media" of SDP [3] and its later revision(s).

612	   <status> This element indicates the status in both directions of the
613	      media stream and has the values "sendrecv", "sendonly",
614	      "recvonly", or "inactive" as defined in SDP [3] and its later
615	      revision(s).  Note that value specifies the direction from the
616	      participant's point of view.

618	5.3  <host-info>

620	   This element contains information about the entity hosting the
621	   conference.  This information is set before the conference
622	   activation, and is rarely changed during the conference lifetime,
623	   unless the whole conference is moved to be hosted by another entity.
624	   The host information is comprised of the following elements:

626	5.3.1  <display-text>

628	   This element contains display text describing the entity hosting the
629	   conference.

631	5.3.2  <web-page>

633	   This element contains a URI of a web page describing either the
634	   conference service or the user hosting the conference.

636	5.3.3  <uris>

638	   This element can contain additional (to the conference URI) URIs
639	   pointing to the conference host.

641	5.4  <conference-state>

643	   By including this element in the conference document, the server can
644	   inform the subscribers about the changes in the overall conference
645	   information.  The <conference-state> child elements are described
646	   below.

648	5.4.1  <user-count>

650	   This element contains the current number of users in the conference.

652	5.4.2  <active>

654	   This Boolean element says whether the conference is currently active
655	   or not.  A conference is active if dialing into one of the
656	   <conf-uris> results in successful establishment of a call signaling
657	   session between the dialed user and the conference focus.

659	5.4.3  <locked>

661	   This Boolean element says whether the conference is currently locked
662	   or not.  In this context, "locked" means that the conference roster
663	   can not be added to (although participants may leave or be removed
664	   from the conference).

666	5.5  <users> of <user>

668	   The <users> element is a container of <user> child elements, each
669	   describing a single participant in the conference.

671	   The following attributes are defined for <user> element:

673	   entity: This attribute contains the URI for the user in the
674	      conference.  This is a logical identifier, which corresponds to
675	      the call signaling authenticated identity of the participant.  The
676	      'entity' value MUST be unique among all participants in the
677	      conference.  If for some participants, the focus decides to not
678	      revealing this information (due to local policies or security
679	      reasons, for example), the host portion of the user URI MUST use
680	      the .invalid top level domain (TLD) according to definitions of
681	      RFC 2606 [5].  The focus also MUST construct the user portion of
682	      the URI such as the URI is unique among all participants of the
683	      same domain.  For example,

685	          "Anonymous1" <sip:anonymous1@anonymous.invalid>

687	       could be used for a participant requesting privacy in accordance
688	      with the guidelines for generating anonymous URIs of RFC 3323
689	      [15].

691	   state: This attribute indicates whether the document contains the
692	      whole user information ("full"), only the information that has
693	      changed since the previous document ("partial"), or the user was
694	      removed from the conference ("deleted").

696	   The following child elements are defined for <user> element:

698	5.5.1  <display-text>

700	   This element is used to display the user friendly name in the
701	   conference.

703	5.5.2  <associated-aors>

705	   This element contains associated URIs of the user.  Usually this
706	   information will be manually provided by a system administrator
707	   showing the logical association between signaling entities otherwise
708	   independent.

710	5.5.3  <roles>

712	   This element is used to display the roles of the user in the
713	   conference.

715	5.5.4  <language>

717	   This element contains the language preference of the user.  This
718	   information can be automatically learned via call signaling or be
719	   manually set per participant.

721	5.5.5  <cascaded-focus>

723	   This element contains a conference URI (different from the main
724	   conference URI) for users that are connected to the main conference
725	   as a result of focus cascading.  In accordance with the SIP
726	   conferencing framework [19], this package allows for representation
727	   of peer-to-peer (i.e.  "flat") focus cascading only.  The actual
728	   cascading graph can not be deduced from the information provided in
729	   the package alone.  Advanced applications can construct the graph by
730	   subscribing to both this package and the Dialog Package [20] of each
731	   cascaded focus and correlating the relevant information.

733	5.5.6  <endpoint>

735	   By including one or more <endpoint> elements under a parent <user>
736	   element, the server can provide the desired level of details
737	   (including the state, media streams, and access information) about
738	   the user's devices and signaling sessions taking part in the
739	   conference.

741	   In a conferencing system where authentication is performed per
742	   endpoint (rather than per user), the focus can be unaware of the
743	   logical association of multiple endpoints under a common user.  In
744	   this case, each endpoint will appear as a separate <user> with its
745	   own <endpoint> sub-element(s) in the conference document.

747	   In a different case, the focus may choose to shield the information
748	   about the participant's multiple endpoints and signaling sessions
749	   from other subscribers altogether (due to privacy policies, for
750	   example).  To do so, the focus MAY aggregate the multiple signaling
751	   sessions' information under a single <endpoint> element.  Note that
752	   in this case, the detailed call signaling information (represented by
753	   <call-info> sub-element) will not be included.

755	5.6  <endpoint>

757	   This section describes the <endpoint> element in more detail.

759	   The following attributes are defined for <endpoint> element:

761	   entity: The server MUST generate the 'entity' key for each <endpoint>
762	      element included under the parent <user>, such as its value is
763	      unique in the user context.  In SIP terms, this can be the Contact
764	      URI, GRUU, etc.

766	   state: This attribute indicates whether the element contains the
767	      whole endpoint information ("full"), only the information that has
768	      changed since the previous document ("partial"), or the endpoint
769	      has been removed from the conference ("deleted").

771	   The following child elements are defined for <endpoint> element:

773	5.6.1  <display-text>

775	   This element contains the display text for the endpoint.

777	5.6.2  <referred>

779	   This element contains information about the user who's action
780	   resulted in this endpoint being brought into the conference (e.g.
781	   the SIP user identified by this URI sent a REFER to the focus).  It
782	   can contain the following sub-elements:

784	   when: This element contains the date and time that the endpoint was
785	      referred to the conference and SHOULD be expressed in Coordinated
786	      Universal Time (UTC) format.

788	   reason: This element contains the reason the endpoint was referred to
789	      the conference.

791	   by: This element contains the URI of the entity who caused the
792	      endpoint to be referred to the conference.

794	5.6.3  <status>

796	   This element contains the status of the endpoint, and can assume the
797	   following values:

799	   connected: The endpoint is a participant in the conference.
800	      Depending on the media policies, he/she can send and receive media
801	      to and from other participants.

803	   disconnected: The endpoint is not a participant in the conference and
804	      no active dialog exists between the endpoint and the focus.

806	   on-hold: Active signaling dialog exists between an endpoint and a
807	      focus, but endpoint is "on-hold" for this conference, i.e.
808	      neither he/she is "hearing" the conference mix, nor is his/her
809	      media being mixed in the conference.  As an example, the endpoint
810	      has asked to join the conference using SIP, but his/her
811	      participation is pending based on moderator approval.  In the
812	      meantime he/she is hearing music-on-hold or some other kind of
813	      related content.

815	   muted-via-focus: Active signaling dialog exists between an endpoint
816	      and a focus and the endpoint can "listen" to the conference, but
817	      endpoint's media is not being mixed into the conference.  Note
818	      that sometimes a subset of endpoint media streams can be muted by
819	      focus (such as poor quality video) while others (such as voice or
820	      IM) can still be active.  In this case, it is RECOMMENDED that the
821	      "aggregated" endpoint connectivity <status> reflects the status of
822	      the most active media.

824	   pending: Endpoint is not yet in the session, but it is anticipated
825	      that he/she will join in the near future.

827	   alerting: A PSTN ALERTING or SIP 180 Ringing was returned for the
828	      outbound call, endpoint is being alerted.

830	   dialing-in: Endpoint is dialing into the conference, not yet in the
831	      roster (probably being authenticated).

833	   dialing-out: Focus has dialed out to connect the endpoint to the
834	      conference, but the endpoint is not yet in the roster (probably
835	      being authenticated).

837	   disconnecting: Focus is in the process of disconnecting the endpoint
838	      (e.g., in SIP a DISCONNECT or BYE was sent to the endpoint).

840	   Note that the defined transient statuses (e.g., disconnecting,
841	   alerting, etc.) could generate a lot of notifications.

843	   Implementations MAY choose not to generate notifications on these to
844	   all participants if it will generate too much traffic.

846	5.6.4  <joining-method>

848	   This element contains method by which the endpoint joined the
849	   conference, and can assume the following values:

851	   dialed-in: The endpoint dialed into the conference (e.g., in SIP sent
852	      INVITE to the focus), which resulted in successful dialog
853	      establishment.

855	   dialed-out: The focus has brought the endpoint into the conference
856	      (e.g., in SIP by sending a successful INVITE to the endpoint).

858	   focus-owner: The endpoint is the focus for this conference.  This
859	      status is used only when a participant's UA acts as a conference
860	      focus.

862	5.6.5  <joining-info>

864	   This element contains information about how the endpoint joined and
865	   can contain the following sub-elements:

867	   when: This element contains the date and time that the endpoint
868	      joined the conference and SHOULD be expressed in Coordinated
869	      Universal Time (UTC).

871	   reason: This element contains the reason the endpoint joined the
872	      conference.

874	   by: This element contains the URI of the entity who caused the
875	      endpoint to join the conference.

877	5.6.6  <disconnection-method>

879	   This element contains method by which the endpoint departed the
880	   conference, and can assume the following values:

882	   departed: In SIP, the endpoint sent a BYE, thus leaving the
883	      conference.

885	   booted: In SIP, the endpoint was sent a BYE by the focus, booting
886	      him/her out of the conference.  Alternatively, the endpoint tried
887	      to dial into to conference but was rejected by the focus due to
888	      local policy.

890	   failed: In SIP, the server tried to bring the endpoint into the
891	      conference, but its attempt to contact the specific endpoint
892	      resulted in a non-200 class final response.  Alternatively, the
893	      endpoint tried to dial into the conference without success due to
894	      technical reasons.

896	5.6.7  <disconnection-info>

898	   This element contains information about the endpoint's departure from
899	   the conference and can contain the following sub-elements:

901	   when: This element contains the date and time that the endpoint
902	      departed the conference and SHOULD be expressed in Coordinated
903	      Universal Time (UTC).

905	   reason: This element contains the reason the endpoint departed the
906	      conference.  When known and meaningful, it is RECOMMENDED to
907	      include the information as conveyed/reported by the call signaling
908	      in the format defined by RFC 3326 [10].  For example,

910	   <reason>Reason: SIP ;cause=415 ;text="Unsupported Media Type"</reason>

912	   by: This element contains the URI of the entity who caused the
913	      endpoint to depart the conference.

915	5.6.8  <media>

917	   This element contains information about a single media stream and is
918	   included for each media stream being established between the focus
919	   and the <endpoint>.

921	   Note that if the <call-info> sub-element of the endpoint is not
922	   included in the document by the server, it is possible that the media
923	   streams listed under the common <endpoint> were established by
924	   separate signaling sessions.

926	5.6.9  <call-info>

928	   The <call-info> element provides detailed call signaling information
929	   for a call being maintained between the participant and the focus.
930	   Privacy policies MUST be consulted before revealing this information
931	   to other participants.

933	   The <sip> sub-element contains the SIP dialog identifier of the
934	   endpoint's dialog with the focus.  The element includes sub-elements
935	   <display-text>, <call-id>, <to-tag>, <from-tag>.

937	   In future, the <call-info> element can be expanded to include call
938	   signaling protocol information for other protocols besides SIP.

940	5.7  <media>

942	   This section describes the <media> element in more detail.

944	   A single 'id' attribute is defined for this element.  This is the
945	   media stream identifier being generated by the server such as its
946	   value is unique in the endpoint context.  This attribute is the key
947	   to refer to a particular media stream in the conference document.

949	   The following child elements are defined for <media>:

951	5.7.1  <display-text>

953	   This element contains the display text for the media stream.

955	5.7.2  <type>

957	   This element contains the media type for the media stream.  The value
958	   of this element MUST be one of the values registered for "media" of
959	   SDP [3] and its later revision(s).

961	5.7.3  <label>

963	   The <label> element carries a unique identifier for this stream among
964	   all streams in the conference and is assigned by the focus.  The
965	   value of this element corresponds to the SDP "label" media attribute
966	   defined in [22].

968	5.7.4  <src-id>

970	   The <src-id> element, if applicable, carries the information about
971	   the actual source of the media.  For example, for RTP/RTCP [11] media
972	   streams, the value MUST contain the SSRC value generated by the
973	   endpoint for the stream it sends.

975	   When an RTP mixer generates a CSRC list according to RTP/RTCP [11],
976	   it inserts a list of the SSRC identifiers of the sources that
977	   contributed to the generation of a particular packet into the RTP
978	   header of that packet.  A quote from RFC 3550: "An example
979	   application is audio conferencing where a mixer indicates all the
980	   talkers whose speech was combined to produce the outgoing packet,
981	   allowing the receiver to indicate the current talker, even though all
982	   the audio packets contain the same SSRC identifier (that of the
983	   mixer)."
984	   If an RTP mixer compliant to the above is used, participants can
985	   perform an SSRC to user mapping and identify "a current speaker".

987	5.7.5  <status>

989	   The element <status> indicates the status in both directions of the
990	   media stream and has the values "sendrecv", "sendonly", "recvonly",
991	   or "inactive" as defined in SDP [3] and its later revision(s).  Note
992	   that value specifies the direction from the participant's point of
993	   view.  For example, a muted participant's stream will have the value
994	   of "recvonly".

996	5.8  <sidebars-by-ref>

998	   This element contains a set of <entry> child elements each containing
999	   a sidebar conference URI.  The recipient of the information can then
1000	   subscribe to sidebar information independently from the main
1001	   conference package subscription.

1003	5.9  <sidebar-by-val>

1005	   This element contains a set of <entry> child elements each containing
1006	   information about a single sidebar.  By using this element of
1007	   conference-type, the server can include a full or a partial
1008	   description of each sidebar (as a sub-conference) in the body of the
1009	   main conference document.

1011	6.  XML Schema

1013	   <?xml version="1.0" encoding="UTF-8" ?>
1014	   <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">
1015	      <!--
1016	             This import brings in the XML language attribute xml:lang
1017	      -->
1018	        <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/03/xml.xsd" />
1019	      <!--
1020	         CONFERENCE ELEMENT
1021	      -->
1022	      <xs:element name="conference-info" type="conference-type"/>
1023	      <!--
1024	         CONFERENCE TYPE
1025	      -->
1026	      <xs:complexType name="conference-type">
1027	         <xs:sequence>
1028	               <xs:element name="conference-description" type="conference-description-type" minOccurs="0"/>
1029	      	   <xs:element name="host-info" type="host-type" minOccurs="0"/>
1030	      	   <xs:element name="conference-state" type="conference-state-type" minOccurs="0"/>
1031	      	   <xs:element name="users" type="users-type" minOccurs="0"/>
1032	      	   <xs:element name="sidebars-by-ref" type="uris-type" minOccurs="0"/>
1033	      	   <xs:element name="sidebars-by-val" type="sidebars-by-val-type" minOccurs="0"/>
1034	      	   <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
1035	         </xs:sequence>
1036	         <xs:attribute name="entity" type="xs:anyURI" use="required"/>
1037	         <xs:attribute name="state" type="state-type" use="optional" default="full"/>
1038	         <xs:attribute name="version" type="xs:unsignedInt" use="optional"/>
1039	         <xs:anyAttribute namespace="##other"/>
1040	      </xs:complexType>
1041	      <!--
1042	         STATE TYPE
1043	      -->
1044	      <xs:simpleType name="state-type">
1045	      	<xs:restriction base="xs:string">
1046	      		<xs:enumeration value="full"/>
1047	      		<xs:enumeration value="partial"/>
1048	      		<xs:enumeration value="deleted"/>
1049	      	</xs:restriction>
1050	      </xs:simpleType>
1051	      <!--
1052	         CONFERENCE DESCRIPTION TYPE
1053	      -->
1054	      <xs:complexType name="conference-description-type">
1055	         <xs:sequence>
1056	      	   <xs:element name="display-text" type="xs:string" minOccurs="0"/>
1057	      	   <xs:element name="subject" type="xs:string" minOccurs="0"/>
1058	      	   <xs:element name="free-text" type="xs:string" minOccurs="0"/>
1059	      	   <xs:element name="keywords" type="keywords-type" minOccurs="0"/>
1060	      	   <xs:element name="conf-uris" type="uris-type" minOccurs="0"/>
1061	      	   <xs:element name="service-uris" type="uris-type" minOccurs="0"/>
1062	      	   <xs:element name="maximum-user-count" type="xs:unsignedInt" minOccurs="0"/>
1063	      	   <xs:element name="available-media" type="conference-media-type" minOccurs="0"/>
1064	    	   <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
1065	         </xs:sequence>
1066	         <xs:anyAttribute namespace="##other"/>
1067	      </xs:complexType>
1068	      <!--
1069	         HOST TYPE
1070	      -->
1071	      <xs:complexType name="host-type">
1072	         <xs:sequence>
1073	      	   <xs:element name="display-text" type="xs:string" minOccurs="0"/>
1074	      	   <xs:element name="web-page" type="xs:anyURI" minOccurs="0"/>
1075	      	   <xs:element name="uris" type="uris-type" minOccurs="0"/>
1076	      	   <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
1077	         </xs:sequence>
1078	         <xs:anyAttribute namespace="##other"/>
1079	      </xs:complexType>
1080	      <!--
1081	         CONFERENCE STATE TYPE
1082	      -->
1083	      <xs:complexType name="conference-state-type">
1084	         <xs:sequence>
1085	               <xs:element name="user-count" type="xs:unsignedInt" minOccurs="0"/>
1086	      	   <xs:element name="active" type="xs:boolean" minOccurs="0"/>
1087	      	   <xs:element name="locked" type="xs:boolean" minOccurs="0"/>
1088	      	   <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
1089	         </xs:sequence>
1090	         <xs:anyAttribute namespace="##other"/>
1091	      </xs:complexType>
1092	      <!--
1093	         CONFERENCE MEDIA TYPE
1094	      -->
1095	      <xs:complexType name="conference-media-type">
1096	         <xs:sequence>
1097	      	   <xs:element name="entry" type="conference-medium-type" maxOccurs="unbounded"/>
1098	         </xs:sequence>
1099	      <xs:anyAttribute namespace="##other"/>
1100	      </xs:complexType>
1101	      <!--
1102	         CONFERENCE MEDIUM TYPE
1103	      -->
1104	      <xs:complexType name="conference-medium-type">
1105	         <xs:sequence>
1106	       	   <xs:element name="display-text" type="xs:string"/>
1107	      	   <xs:element name="type" type="xs:string" minOccurs="0"/>
1108	      	   <xs:element name="status" type="media-status-type" minOccurs="0"/>
1109	      	   <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
1110	         </xs:sequence>
1111	         <xs:attribute name="label" type="xs:string" use="required"/>
1112	         <xs:anyAttribute namespace="##other"/>
1113	      </xs:complexType>

1115	      <!--
1116	         URIs TYPE
1117	      -->
1118	      <xs:complexType name="uris-type">
1119	         <xs:sequence>
1120	      	   <xs:element name="entry" type="uri-type" maxOccurs="unbounded"/>
1121	         </xs:sequence>
1122	         <xs:attribute name="state" type="state-type" use="optional" default="full"/>
1123	         <xs:anyAttribute namespace="##other"/>
1124	      </xs:complexType>

1126	      <!--
1127	         URI TYPE
1128	      -->
1129	      <xs:complexType name="uri-type">
1130	         <xs:sequence>
1131	      	   <xs:element name="uri" type="xs:anyURI"/>
1132	      	   <xs:element name="display-text" type="xs:string" minOccurs="0"/>
1133	      	   <xs:element name="purpose" type="xs:string" minOccurs="0"/>
1134	      	   <xs:element name="modified" type="execution-type" minOccurs="0"/>
1135	      	   <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
1136	         </xs:sequence>

1138	         <xs:anyAttribute namespace="##other"/>
1139	      </xs:complexType>

1141	      <!--
1142	         KEWORDS TYPE
1143	      -->
1144	      <xs:simpleType name="keywords-type">
1145	             <xs:list itemType="xs:string"/>
1146	      </xs:simpleType>

1148	      <!--
1149	         USERS TYPE
1150	      -->
1151	      <xs:complexType name="users-type">
1152	         <xs:sequence>
1153	             <xs:element name="user" type="user-type" minOccurs="0" maxOccurs="unbounded"/>
1154	      	   <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

1156	         </xs:sequence>
1157	         <xs:attribute name="state" type="state-type" use="optional" default="full"/>
1158	         <xs:anyAttribute namespace="##other"/>
1159	      </xs:complexType>
1160	      <!--
1161	         USER TYPE
1162	      -->
1163	      <xs:complexType name="user-type">
1164	         <xs:sequence>
1165	      	   <xs:element name="display-text" type="xs:string" minOccurs="0"/>
1166	      	   <xs:element name="associated-aors" type="uris-type" minOccurs="0"/>
1167	      	   <xs:element name="roles" type="user-roles-type" minOccurs="0"/>
1168	      	   <xs:element name="language" type="xs:language" minOccurs="0"/>
1169	      	   <xs:element name="cascaded-focus" type="xs:anyURI" minOccurs="0"/>
1170	      	   <xs:element name="endpoint" type="endpoint-type" minOccurs="0" maxOccurs="unbounded"/>
1171	      	   <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
1172	         </xs:sequence>
1173	         <xs:attribute name="entity" type="xs:anyURI"/>
1174	         <xs:attribute name="state" type="state-type" use="optional" default="full"/>
1175	         <xs:anyAttribute namespace="##other"/>
1176	      </xs:complexType>

1178	      <!--
1179	         USER ROLES TYPE
1180	      -->
1181	      <xs:complexType name="user-roles-type">
1182	         <xs:sequence>
1183	      	   <xs:element name="entry" type="xs:string" maxOccurs="unbounded"/>
1184	         </xs:sequence>
1185	         <xs:anyAttribute namespace="##other"/>
1186	      </xs:complexType>

1188	      <!--
1189	         ENDPOINT TYPE
1190	      -->
1191	      <xs:complexType name="endpoint-type">
1192	         <xs:sequence>
1193	      	   <xs:element name="display-text" type="xs:string" minOccurs="0"/>
1194	      	   <xs:element name="referred" type="execution-type" minOccurs="0"/>
1195	      	   <xs:element name="status" type="endpoint-status-type" minOccurs="0"/>
1196	      	   <xs:element name="joining-method" type="joining-type" minOccurs="0"/>
1197	      	   <xs:element name="joining-info" type="execution-type" minOccurs="0"/>
1198	      	   <xs:element name="disconnection-method" type="disconnection-type" minOccurs="0"/>
1199	      	   <xs:element name="disconnection-info" type="execution-type" minOccurs="0"/>
1200	      	   <xs:element name="media" type="media-type" minOccurs="0" maxOccurs="unbounded"/>
1201	      	   <xs:element name="call-info" type="call-type" minOccurs="0"/>
1202	      	   <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
1203	         </xs:sequence>
1204	         <xs:attribute name="entity" type="xs:string"/>
1205	         <xs:attribute name="state" type="state-type" use="optional" default="full"/>
1206	         <xs:anyAttribute namespace="##other"/>
1207	      </xs:complexType>

1209	      <!--
1210	         ENDPOINT STATUS TYPE
1211	      -->
1212	      <xs:simpleType name="endpoint-status-type">
1213	      	<xs:restriction base="xs:string">
1214	      		<xs:enumeration value="pending"/>
1215	      		<xs:enumeration value="dialing-out"/>
1216	      		<xs:enumeration value="dialing-in"/>
1217	      		<xs:enumeration value="alerting"/>
1218	      		<xs:enumeration value="on-hold"/>
1219	      		<xs:enumeration value="connected"/>
1220	      		<xs:enumeration value="muted-via-focus"/>
1221	      		<xs:enumeration value="disconnecting"/>
1222	      		<xs:enumeration value="disconnected"/>
1223	      	</xs:restriction>
1224	      </xs:simpleType>
1225	      <!--
1226	         JOINING TYPE
1227	      -->
1228	      <xs:simpleType name="joining-type">
1229	      	<xs:restriction base="xs:string">
1230	      		<xs:enumeration value="dialed-in"/>
1231	      		<xs:enumeration value="dialed-out"/>
1232	      		<xs:enumeration value="focus-owner"/>
1233	      	</xs:restriction>
1234	      </xs:simpleType>
1235	      <!--
1236	         DISCONNECTION TYPE
1237	      -->
1238	      <xs:simpleType name="disconnection-type">
1239	             <xs:restriction base="xs:string">
1240	      		<xs:enumeration value="departed"/>
1241	      		<xs:enumeration value="booted"/>
1242	      		<xs:enumeration value="failed"/>
1243	      	</xs:restriction>

1245	      </xs:simpleType>

1247	      <!--
1248	         EXECUTION TYPE
1249	      -->
1250	      <xs:complexType name="execution-type">
1251	         <xs:sequence>
1252	      	   <xs:element name="when" type="xs:dateTime" minOccurs="0"/>
1253	      	   <xs:element name="reason" type="xs:string" minOccurs="0"/>
1254	      	   <xs:element name="by" type="xs:anyURI" minOccurs="0"/>
1255	         </xs:sequence>
1256	         <xs:anyAttribute namespace="##other"/>
1257	      </xs:complexType>

1259	     <!--
1260	         CALL TYPE
1261	      -->
1262	      <xs:complexType name="call-type">
1263	         <xs:choice>
1264	      	   <xs:element name="sip" type="sip-dialog-id-type"/>
1265	      	   <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
1266	         </xs:choice>
1267	         <xs:anyAttribute namespace="##other"/>
1268	      </xs:complexType>

1270	      <!--
1271	         SIP DIALOG ID TYPE
1272	      -->
1273	      <xs:complexType name="sip-dialog-id-type">
1274	         <xs:sequence>
1275	      	   <xs:element name="display-text" type="xs:string" minOccurs="0"/>
1276	      	   <xs:element name="call-id" type="xs:string"/>
1277	      	   <xs:element name="from-tag" type="xs:string"/>
1278	      	   <xs:element name="to-tag" type="xs:string"/>
1279	      	   <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
1280	         </xs:sequence>
1281	         <xs:anyAttribute namespace="##other"/>
1282	      </xs:complexType>

1284	      <!--
1285	         MEDIA TYPE
1286	      -->
1287	      <xs:complexType name="media-type">
1288	         <xs:sequence>
1289	   	   <xs:element name="display-text" type="xs:string" minOccurs="0"/>
1290	      	   <xs:element name="type" type="xs:string" minOccurs="0"/>
1291	      	   <xs:element name="label" type="xs:string" minOccurs="0"/>
1292	     	         <xs:element name="src-id" type="xs:string" minOccurs="0"/>
1293	      	   <xs:element name="status" type="media-status-type" minOccurs="0"/>
1294	      	   <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
1295	         </xs:sequence>
1296	         <xs:attribute name="id" type="xs:string" use="required"/>
1297	         <xs:anyAttribute namespace="##other"/>
1298	      </xs:complexType>

1300	      <!--
1301	         MEDIA STATUS TYPE
1302	      -->
1303	      <xs:simpleType name="media-status-type">
1304	      	<xs:restriction base="xs:string">
1305	      		<xs:enumeration value="recvonly"/>
1306	      		<xs:enumeration value="sendonly"/>
1307	      		<xs:enumeration value="sendrecv"/>
1308	      		<xs:enumeration value="inactive"/>
1309	      	</xs:restriction>
1310	      </xs:simpleType>

1312	       <!--
1313	         SIDEBARS BY VAL TYPE
1314	       -->
1315	      <xs:complexType name="sidebars-by-val-type">
1316	         <xs:sequence>
1317	      	   <xs:element name="entry" type="conference-type" minOccurs="0" maxOccurs="unbounded"/>
1318	         </xs:sequence>
1319	         <xs:attribute name="state" type="state-type" use="optional" default="full"/>
1320	         <xs:anyAttribute namespace="##other"/>
1321	      </xs:complexType>
1322	      </xs:schema>

1324	7.  Examples

1326	7.1  Basic Example

1328	   The following is an example conference information document:

1330	   <conference-info entity="sips:conf233@example.com" state="partial" version="5" >
1331	   <!--
1332	      CONFERENCE INFO
1333	   -->
1334	      <conference-description>
1335	   	<subject>Agenda: This month's goals</subject>
1336	   	<service-uris>
1337	   		<entry>
1338	   			<uri> http://sharepoint/salesgroup/</uri>
1339	   			<purpose>web-page</purpose>
1340	   		</entry>
1341	   	</service-uris>
1342	      </conference-description>

1344	   <!--
1345	      CONFERENCE STATE
1346	   -->
1347	      <conference-state>
1348	   	<user-count>33</user-count>
1349	      </conference-state>

1351	      <users>
1352	      <!--

1354	          USER
1355	      -->
1356	   	<user entity="sip:bob@example.com" state="full">
1357	   		<display-text>Bob Hoskins</display-text>
1358	   		<!--
1359	   	  		ENDPOINTS
1360	   		-->
1361	   		<endpoint entity="sip:bob@pc33.example.com">
1362	   			<display-text>Bob's Laptop</display-text>
1363	   			<status>disconnected</status>
1364	   			<disconnection-method>departed</disconnection-method>
1365	   			<disconnection-info>
1366	   				<when>2005-03-04T20:00:00Z</when>
1367	   				<reason>bad voice quality</reason>
1368	   				<by>sip:mike@example.com</by>
1369	   			</disconnection-info>
1370	   			<!--
1371	   	  			MEDIA
1372	   			-->
1373	   			<media id="1">
1374	   				<display-text>main audio</display-text>
1375	   				<type>audio</type>
1376	   				<label>34567</label>
1377	   				<src-id>432424</src-id>

1379	   				<status>sendrecv</status>
1380	   			</media>
1381	   		</endpoint>
1382	   	</user>

1384	      <!--

1386	   	USER
1387	      -->
1388	          <user entity="sip:alice@example.net" state="full">
1389	          		<display-text>Alice</display-text>
1390	          		<!--
1391	   			ENDPOINTS
1392	   		-->
1393	   	 	<endpoint entity="sip:4kfk4j392jsu@example.net;grid=433kj4j3u" call="1">

1395	   	 		<status>connected</status>
1396	   	 		<joining-method>dialed-out</joining-method>
1397	   	 		<joining-info>
1398	   				<when>2005-03-04T20:00:00Z</when>
1399	   				<by>sip:mike@example.com</by>
1400	   	 		</joining-info>
1401	   			<!--
1402	   	  			MEDIA
1403	    			-->
1404	    			<media id="1">
1405	   				<display-text>main audio</display-text>
1406	   				<type>audio</type>
1407	     				<label>34567</label>
1408	    				<src-id>534232</src-id>
1409	    				<status>sendrecv</status>
1410	    			</media>
1411	          		</endpoint>

1413	          </user>
1414	      </users>

1416	   </conference-info>

1418	7.2  Rich Example

1420	   The following is an example conference information document.  In this
1421	   example of a partial state notification, there are 32 participants in
1422	   a voice conference.  The user Bob has been booted from the conference
1423	   by Mike due to bad voice quality.  Note that there are three sidebars
1424	   in the conference, two are referenced just by their sidebar URIs and
1425	   information about the third sidebar is included in this notification.
1426	   Also note that while this conference offers both audio and video
1427	   capabilities, only audio is currently in use.

1429	   <conference-info entity="sips:conf233@example.com" state="partial" version="5" >
1430	      <!--
1431	   	CONFERENCE INFO
1432	      -->
1433	   	<conference-description>
1434	   		<display-text>Weekly Sales Meeting</display-text>
1435	   		<subject>Agenda: This month's goals</subject>
1436	   		<free-text>We will start strict on time</free-text>

1438	   		<keywords>sales, meeting, weekly</keywords>
1439	   		<conf-uris>
1440	   			<entry>
1441	   				<uri>tel:+18005671234</uri>
1442	   				<display-text>TTI Bridge</display-text>
1443	   				<purpose>participation</purpose>

1445	   			</entry>

1447	   			<entry>
1448	   				<uri>h323:conf545@h323.example.com</uri>
1449	   				<purpose>participation</purpose>
1450	   			</entry>
1451	   			<entry>
1452	      	<uri>http://real.streaming.com/54634/live.ram</uri>
1453	   				<purpose>streaming</purpose>
1454	   			</entry>

1456	   		</conf-uris>
1457	   		<service-uris>
1458	   			<entry>
1459	   				<uri>http://sharepoint/salesgroup/</uri>
1460	   				<purpose>web-page</purpose>
1461	   			</entry>
1462	   			<entry>
1463	   	<uri>http://quicktime.com/54634/recording.mov</uri>
1464	   				<display-text>Quicktime</display-text>

1466	   				<purpose>recording</purpose>
1467	   			</entry>
1468	   		</service-uris>
1469	   		<maximum-user-count>100</maximum-user-count>
1470	   		<available-media>
1471	   			<entry label="34567">
1472	   				<display-text>main audio</display-text>
1473	   				<type>audio</type>
1474	   				<status>sendrecv</status>
1475	   			</entry>
1476	   			<entry label="34569">
1477	   				<display-text>main video</display-text>
1478	   				<type>video</type>
1479	   				<status>inactive</status>
1480	   			</entry>
1481	   		</available-media>
1482	   	</conference-description>
1483	   	<!--

1485	   	  HOST INFO
1486	   	-->
1487	   	<host-info>
1488	   		<display-text>Sales Host</display-text>
1489	   		<web-page>http://sharepoint/salesgroup/hosts/</web-page>
1490	   		<uris>
1491	   			<entry>
1492	   				<uri>sip:sales@example.com</uri>
1493	   			</entry>
1494	   		</uris>
1495	   	</host-info>
1496	   	<!--
1497	   	  CONFERENCE STATE
1498	   	-->
1499	   	<conference-state>
1500	   		<user-count>32</user-count>
1501	   		<active>true</active>
1502	   		<locked>false</locked>

1504	   	</conference-state>

1506	   	<!--
1507	   	USERS
1508	   	-->
1509	   	<users>
1510	   		<user entity="sip:bob@example.com">
1511	   			<display-text>Bob Hoskins</display-text>
1512	   			<associated-aors>
1513	   				<entry>
1514	   					<uri>mailto:bob@example.com</uri>
1515	   					<display-text>email</display-text>
1516	   				</entry>
1517	   			</associated-aors>
1518	   			<roles>
1519	   				<entry>participant</entry>
1520	   			</roles>
1521	   			<language>en</language>

1523	   		<!--
1524	   	  	ENDPOINTS
1525	   		-->
1526	   			<endpoint entity="sip:bob@pc33.example.com">
1527	   				<display-text>Bob's Laptop</display-text>
1528	   				<referred>
1529	   					<when>2005-03-04T20:00:00Z</when>
1530	   					<reason>expert required</reason>
1531	   					<by>sip:mike@example.com</by>
1532	   				</referred>
1533	   				<status>disconnecting</status>
1534	   				<joining-method>dialed-out</joining-method>
1535	   				<joining-info>

1537	   					<when>2005-03-04T20:00:00Z</when>
1538	   					<reason>invitation</reason>
1539	   					<by>sip:mike@example.com</by>

1541	   				</joining-info>
1542	   				<disconnection-method>booted</disconnection-method>
1543	   				<disconnection-info>
1544	   					<when>2005-03-04T20:00:00Z</when>
1545	   					<reason>bad voice quality</reason>
1546	   					<by>sip:mike@example.com</by>
1547	   				</disconnection-info>
1548	   			<!--
1549	   	  		CALL INFO
1550	   			-->
1551	   				<call-info>
1552	   					<sip>
1553	   					   <display-text>full info</display-text>
1554	   					   <call-id>hsjh8980vhsb78</call-id>
1555	   					   <from-tag>vav738dvbs</from-tag>
1556	   					   <to-tag>8954jgjg8432</to-tag>
1557	   					</sip>
1558	   				</call-info>
1559	   			<!--
1560	   	  		MEDIA
1561	   			-->
1562	   				<media id="1">
1563	   					<display-text>main audio</display-text>
1564	   					<type>audio</type>
1565	   					<label>34567</label>
1566	   					<src-id>432424</src-id>
1567	   					<status>sendrecv</status>
1568	   				</media>
1569	   			</endpoint>
1570	   		</user>
1571	   	</users>

1573	   	<!--
1574	   	SIDEBARS BY REFERENCE
1575	   	-->
1576	   	<sidebars-by-ref state="partial">
1577	   		<entry>
1578	   			<uri>sips:conf233@example.com; grid=45</uri>
1579	   			<display-text>sidebar with Carol</display-text>
1580	   		</entry>
1581	   		<entry>
1582	   			<uri>sips:conf233@example.com; grid=21</uri>
1583	   			<display-text>private sidebar with Peter</display-text>
1584	   		</entry>
1585	   	</sidebars-by-ref>

1587	   	<!--
1588	   	SIDEBARS BY VALUE
1589	   	-->
1590	   	<sidebars-by-val state="partial">
1591	   		<entry entity="sips:conf233@example.com; grid=77" state="partial">

1593	   			<users>
1594	   				<user entity="sip:bob@example.com"></user>
1595	   				<user entity="sip:mark@example.com"></user>
1596	   				<user entity="sip:dan@example.com"></user>
1597	   			</users>
1598	   		</entry>
1599	   	</sidebars-by-val>

1601	   </conference-info>

1603	8.  Security Considerations

1605	   Subscriptions to conference state can reveal very sensitive
1606	   information.  For this reason, the document recommends authentication
1607	   and authorization, and provides guidelines on sensible authorization
1608	   policies.

1610	   Since the data in notifications is sensitive as well, end-to-end SIP
1611	   encryption mechanisms using S/MIME SHOULD be used to protect it.

1613	   Since a focus provides participant identity information using this
1614	   event package, participant privacy needs to be taken into account.  A
1615	   focus MUST support requests by participants for privacy.  Privacy can
1616	   be indicated by the conference policy - for every participant or
1617	   select participants.  It can also be indicated in the session
1618	   signaling.  In SIP this can be done using the Privacy header field
1619	   described in RFC 3323 [15].  For a participant requesting privacy, no
1620	   identity information SHOULD be revealed by the focus such as a URI
1621	   (e.g.  the Address of Record, Contact, or GRUU).  For these cases,
1622	   the anonymous URI generation method outlined in section Section 5.5
1623	   of this document MUST be followed.

1625	9.  IANA Considerations

1627	   This document registers a SIP event package, a new MIME type,
1628	   application/conference-info+xml, a new XML namespace, a new XML
1629	   schema, and creates a  sub-registry "URI purposes" under the
1630	   existing registry: http://www.iana.org/assignments/sip-parameters.

1632	9.1  conference Event Package Registration

1634	   This specification registers an event package, based on the
1635	   registration procedures defined in RFC 3265 [9].  The following is
1636	   the information required for such a registration:
1637	   Package Name: conference
1638	   Package or Template-Package: This is a package.
1639	   Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX
1640	      with the RFC number of this specification).
1641	   Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.

1643	9.2  application/conference-info+xml MIME Registration
1644	   MIME media type name: application
1645	   MIME subtype name: conference-info+xml
1646	   Mandatory parameters: none
1647	   Optional parameters: Same as charset parameter application/xml as
1648	      specified in RFC 3023 [7]
1649	   Encoding considerations: Same as encoding considerations of
1650	      application/xml as specified in RFC 3023 [7]
1651	   Security considerations: See Section 10 of RFC 3023 [7] and Section 8
1652	      of this specification

1654	   Interoperability considerations: none
1655	   Published specification: This document
1656	   Applications which use this media type: This document type has been
1657	      used to support SIP conferencing applications
1658	   Additional Information:
1659	      Magic Number: None
1660	      File Extension: .cif or .xml
1661	      Macintosh file type code: "TEXT"
1662	   Personal and email address for further information: Jonathan
1663	      Rosenberg, <jdrosen@jdrosen.net>
1664	   Intended usage: COMMON
1665	   Author/Change controller: The IETF

1667	9.3  URN Sub-Namespace Registration for
1668	    urn:ietf:params:xml:ns:conference-info

1670	   This section registers a new XML namespace, as per the guidelines in
1671	   RFC 3688 [13].

1673	   URI: The URI for this namespace is
1674	      urn:ietf:params:xml:ns:conference-info
1675	   Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>,
1676	      Jonathan Rosenberg <jdrosen@jdrosen.net>
1677	   XML:

1679	   BEGIN
1680	   <?xml version="1.0"?>
1681	   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
1682	             "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
1683	   <html xmlns="http://www.w3.org/1999/xhtml">
1684	   <head>
1685	     <meta http-equiv="content-type"
1686	        content="text/html;charset=iso-8859-1"/>
1687	     <title>Conference Information Namespace</title>

1689	   </head
1690	   <body>
1691	     <h1>Namespace for Conference Information</h1>
1692	     <h2>urn:ietf:params:xml:ns:conference-info</h2>
1693	     <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
1694	   </body>
1695	   </html>
1696	   END

1698	9.4  XML Schema Registration

1700	   This specification registers a schema, as per the guidelines in RFC
1701	   3688 [13].
1702	      URI: please assign
1703	      Registrant Contact: IETF, SIPPING Working Group
1704	      (sipping@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net)
1705	      XML: The XML can be found as the sole content of Section 6

1707	9.5  URI Purposes Sub-registry Establishment

1709	   This document instructs the IANA to create a new sub-registry "URI
1710	   purposes" under the already existing registry:
1711	   http://www.iana.org/assignments/sip-parameters.

1713	   The purpose of a URI is an XML element, encoded in the conference
1714	   event package [RFC XXXX - substitute with the number assigned to this
1715	   draft].  The value of the <purpose> element indicates the intended
1716	   usage of the URI in the context of the conference event package and
1717	   is defined in sections Section 5.2.1 and Section 5.2.2 of this
1718	   specification.

1720	   This sub-registry is defined as a table that contains the following
1721	   three columns:

1723	   Value: The token under registration
1724	   Description: A descriptive text defining the intended usage of the
1725	      URI
1726	   Document: A reference to the document defining the registration

1728	   This specification instructs IANA to create the table with the
1729	   initial content as defined below:

1731	   Value         Description                         Document
1732	   -------       ----------------------------------  ----------

1734	   participation The URI can be used to join the     [RFC XXXX]
1735	                 conference

1737	   streaming     The URI can be used to access the   [RFC XXXX]
1738	                 streamed conference data

1740	   event         The URI can be used to subscribe    [RFC XXXX]
1741	                 to the conference event package

1743	   recording     The URI can be used to access the   [RFC XXXX]
1744	                 recorded conference data

1746	   web-page      The URI can be used to access a     [RFC XXXX]
1747	                 web page that contains additional
1748	                 information of the conference

1750	   New values of the "URI purposes" are registered by the IANA when a
1751	   specification becomes available and according to the definition of
1752	   RFC 2434 [4].  The IANA Considerations section of the specification
1753	   MUST include the following information:

1755	   Value: The value of the <purpose> element to be registered
1756	   Description: A short description of the intended usage of the URI

1758	10.  Acknowledgements

1760	   The authors would like to thank Dan Petrie, Sean Olson, Alan
1761	   Johnston, Rohan Mahy, Cullen Jennings, Brian Rosen, Roni Even, and
1762	   Miguel Garcia for their comments and inputs.

1764	11.  References

1766	11.1  Normative References

1768	   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
1769	         Levels", BCP 14, RFC 2119, March 1997.

1771	   [2]   Moats, R., "URN Syntax", RFC 2141, May 1997.

1773	   [3]   Handley, M. and V. Jacobson, "SDP: Session Description
1774	         Protocol", RFC 2327, April 1998.

1776	   [4]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
1777	         Considerations Section in RFCs", BCP 26, RFC 2434, October
1778	         1998.

1780	   [5]   Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names",
1781	         BCP 32, RFC 2606, June 1999.

1783	   [6]   Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
1784	         August 1999.

1786	   [7]   Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types",
1787	         RFC 3023, January 2001.

1789	   [8]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
1790	         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
1791	         Session Initiation Protocol", RFC 3261, June 2002.

1793	   [9]   Roach, A., "Session Initiation Protocol (SIP)-Specific Event
1794	         Notification", RFC 3265, June 2002.

1796	   [10]  Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason Header
1797	         Field for the Session Initiation Protocol (SIP)", RFC 3326,
1798	         December 2002.

1800	   [11]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
1801	         "RTP: A Transport Protocol for Real-Time Applications", STD 64,
1802	         RFC 3550, July 2003.

1804	   [12]  Yergeau, F., "UTF-8, a transformation format of ISO 10646",
1805	         STD 63, RFC 3629, November 2003.

1807	   [13]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1808	         January 2004.

1810	11.2  Informative References

1812	   [14]  Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
1813	         Protocol (RTSP)", RFC 2326, April 1998.

1815	   [15]  Peterson, J., "A Privacy Mechanism for the Session Initiation
1816	         Protocol (SIP)", RFC 3323, November 2002.

1818	   [16]  Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne,
1819	         "Grouping of Media Lines in the Session Description Protocol
1820	         (SDP)", RFC 3388, December 2002.

1822	   [17]  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
1823	         December 2004.

1825	   [18]  Levin, O., "H.323 Uniform Resource Locator (URL) Scheme
1826	         Registration", RFC 3508, April 2003.

1828	   [19]  Rosenberg, J., "A Framework for Conferencing with the Session
1829	         Initiation Protocol",
1830	         Internet-Draft draft-ietf-sipping-conferencing-framework-04,
1831	         February 2005.

1833	   [20]  Rosenberg, J., "An INVITE Inititiated Dialog Event Package for
1834	         the Session Initiation  Protocol (SIP)",
1835	         Internet-Draft draft-ietf-sipping-dialog-package-05, November
1836	         2004.

1838	   [21]  Rosenberg, J., "Obtaining and Using Globally Routable User
1839	         Agent (UA) URIs (GRUU) in the  Session Initiation Protocol
1840	         (SIP)", Internet-Draft draft-ietf-sip-gruu-03, February 2005.

1842	   [22]  Levin, O. and G. Camarillo, "The SDP (Session Description
1843	         Protocol) Label Attribute",
1844	         Internet-Draft draft-ietf-mmusic-sdp-media-label-01, January
1845	         2005.

1847	Authors' Addresses

1849	   Jonathan Rosenberg
1850	   Cisco Systems
1851	   600 Lanidex Plaza
1852	   Parsippany, NJ  07054
1853	   US

1855	   Phone: +1 973 952-5000
1856	   Email: jdrosen@cisco.com
1857	   URI:   http://www.jdrosen.net

1859	   Henning Schulzrinne
1860	   Columbia University
1861	   M/S 0401
1862	   1214 Amsterdam Ave.
1863	   New York, NY  10027
1864	   US

1866	   Email: schulzrinne@cs.columbia.edu
1867	   URI:   http://www.cs.columbia.edu/~hgs
1868	   Orit Levin (editor)
1869	   Microsoft Corporation
1870	   One Microsoft Way
1871	   Redmond, WA  98052
1872	   US

1874	   Email: oritl@microsoft.com

1876	Intellectual Property Statement

1878	   The IETF takes no position regarding the validity or scope of any
1879	   Intellectual Property Rights or other rights that might be claimed to
1880	   pertain to the implementation or use of the technology described in
1881	   this document or the extent to which any license under such rights
1882	   might or might not be available; nor does it represent that it has
1883	   made any independent effort to identify any such rights.  Information
1884	   on the procedures with respect to rights in RFC documents can be
1885	   found in BCP 78 and BCP 79.

1887	   Copies of IPR disclosures made to the IETF Secretariat and any
1888	   assurances of licenses to be made available, or the result of an
1889	   attempt made to obtain a general license or permission for the use of
1890	   such proprietary rights by implementers or users of this
1891	   specification can be obtained from the IETF on-line IPR repository at
1892	   http://www.ietf.org/ipr.

1894	   The IETF invites any interested party to bring to its attention any
1895	   copyrights, patents or patent applications, or other proprietary
1896	   rights that may cover technology that may be required to implement
1897	   this standard.  Please address the information to the IETF at
1898	   ietf-ipr@ietf.org.

1900	Disclaimer of Validity

1902	   This document and the information contained herein are provided on an
1903	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1904	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1905	   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1906	   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1907	   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1908	   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

1910	Copyright Statement

1912	   Copyright (C) The Internet Society (2005).  This document is subject
1913	   to the rights, licenses and restrictions contained in BCP 78, and
1914	   except as set forth therein, the authors retain all their rights.

1916	Acknowledgment

1918	   Funding for the RFC Editor function is currently provided by the
1919	   Internet Society.