idnits 2.17.1
draft-ietf-sipping-conference-package-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 10 instances of too long lines in the document, the longest
one being 7 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The "Author's Address" (or "Authors' Addresses") section title is
misspelled.
== 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 (June 24, 2002) is 7976 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)
-- Possible downref: Non-RFC (?) normative reference: ref. '1'
-- Possible downref: Non-RFC (?) normative reference: ref. '3'
** Obsolete normative reference: RFC 2141 (ref. '4') (Obsoleted by RFC 8141)
** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '5')
-- Possible downref: Non-RFC (?) normative reference: ref. '6'
-- Possible downref: Non-RFC (?) normative reference: ref. '7'
** Obsolete normative reference: RFC 3023 (ref. '8') (Obsoleted by RFC 7303)
Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force SIPPING WG
3 Internet Draft J. Rosenberg
4 dynamicsoft
5 H. Schulzrinne
6 Columbia U.
7 draft-ietf-sipping-conference-package-00.txt
8 June 24, 2002
9 Expires: December 2002
11 A Session Initiation Protocol (SIP) Event Package for Conference State
13 STATUS OF THIS MEMO
15 This document is an Internet-Draft and is in full conformance with
16 all provisions of Section 10 of RFC2026.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
21 Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress".
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt
31 To view the list Internet-Draft Shadow Directories, see
32 http://www.ietf.org/shadow.html.
34 Abstract
36 This document defines a conference event package for the SIP Events
37 architecture, along with a data format used in notifications for this
38 package. The conference package allows users to subscribe to a SIP
39 URI that is associated with a conference. Notifications are sent
40 about changes in the membership of this conference, changes in active
41 speaker, and media mixing information.
43 Table of Contents
45 1 Introduction ........................................ 4
46 2 Terminology ......................................... 4
47 3 Conference Event Package ............................ 4
48 3.1 Event Package Name .................................. 5
49 3.2 Event Package Parameters ............................ 5
50 3.3 SUBSCRIBE Bodies .................................... 5
51 3.4 Subscription Duration ............................... 6
52 3.5 NOTIFY Bodies ....................................... 6
53 3.6 Notifier Processing of SUBSCRIBE Requests ........... 6
54 3.7 Notifier Generation of NOTIFY Requests .............. 6
55 3.8 Subscriber Processing of NOTIFY Requests ............ 6
56 3.9 Handling of Forked Requests ......................... 7
57 3.10 Rate of Notifications ............................... 7
58 3.11 State Agents ........................................ 7
59 4 Conference Data Format .............................. 7
60 4.1 Structute of the Format ............................. 8
61 4.1.1 User Element ........................................ 8
62 4.1.2 Status .............................................. 9
63 4.1.3 Dialog .............................................. 9
64 4.1.4 Media Status ........................................ 9
65 4.2 Constructing Coherent State ......................... 9
66 4.3 Schema .............................................. 10
67 4.4 Example ............................................. 13
68 5 Security Considerations ............................. 13
69 6 IANA Considerations ................................. 13
70 6.1 application/conference-info+xml MIME Registration
71 ................................................................ 13
72 6.2 URN Sub-Namespace Registration for
73 urn:ietf:params:xml:ns:conference-info ......................... 14
74 7 Acknowledgements .................................... 15
75 8 Authors Addresses ................................... 15
76 9 Normative References ................................ 15
77 10 Informative References .............................. 16
79 1 Introduction
81 The SIP Events framework [1] defines general mechanisms for
82 subscription to, and notification of, events within SIP networks. It
83 introduces the notion of a package, which is a specific
84 "instantiation" of the events mechanism for a well-defined set of
85 events. Packages have been defined for user presence [9], watcher
86 information [10], and message waiting indicators [11], amongst
87 others. Here, we define an event package for SIP conferences. This
88 package will work for any conference in which there is a central
89 signaling element [12].
91 The conferencing package allows a subscriber to learn about the
92 identities of participants and their status in the conference, the
93 dialogs that are used by each user, the media makeup of the
94 conference, and the mixing matrix (i.e., who is receiving whose
95 audio). This information is vital to building conferencing
96 applications using SIP.
98 2 Terminology
100 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
101 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
102 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
103 indicate requirement levels for compliant implementations.
105 3 Conference Event Package
107 The conference event package allows a user to subscribe to a
108 conference. In SIP, conferences are represented by URIs. These URIs
109 route to a SIP user agent that is responsible for ensuring that all
110 users in the conference can communicate with each other. Detailed
111 information on conferencing models can be found in [12]. This package
112 can work with any of the tightly-coupled models described in that
113 specification. However, the conference server may not have complete
114 information on the media makeup of the conference. This is the case
115 for multicast-based conferences, where the server cannot know the
116 mixing matrix for the conference. In this case, that information
117 would simply not be reported through this package.
119 The specific information conveyed in notifications in this package
120 is:
122 o The SIP URI identifying the user.
124 o The dialog state associated with that users attachment to the
125 conference.
127 o Their status in the conference (active, declined, departed).
129 o Their status in terms of receiving media in the conference.
131 This section provides the details for defining a SIP Events package,
132 as specified by [1].
134 3.1 Event Package Name
136 The name of this event package is "conference". This package name is
137 carried in the Event and Allow-Events header, as defined in [1].
139 3.2 Event Package Parameters
141 A single parameter, "recurse" is defined for this package. When
142 present, it informs the server that it should check whether any
143 participants in the conference are themselves conferences, and if so,
144 generate a subscription to their conference state with the "recurse"
145 attribute. The users reported in notifications from this recursed
146 subscription are reported to the original subscriber. The result is
147 that the list of users reported to the subscriber represents the
148 complete user list even when cascaded conferences are used.
150 Example:
152 Event: conference;recurse
154 3.3 SUBSCRIBE Bodies
156 A SUBSCRIBE for a dialog package MAY contain a body. This body
157 defines a filter to apply to the subscription.
159 A SUBSCRIBE for a conference package MAY be sent without a body. This
160 implies the default subscription filtering policy. The default policy
161 is:
163 o Notifications are generated every time there is any change in
164 the set of users participating in the conference, or a change
165 their state (dialog state, media mixing state, etc.)
167 o Notifications do not normally contain full state; rather, they
168 only indicate the state of the participant whose state has
169 changed. The exception is a NOTIFY sent in response to a
170 SUBSCRIBE. These NOTIFYs contain the complete view of
171 conference state.
173 o For a given user, the notifications contain the identity
174 information and status.
176 3.4 Subscription Duration
178 The default expiration time for a subscription to a conference is one
179 hour. Of course, once the conference ends, all subscriptions to that
180 particular conference are terminated, with a reason of "noresource"
181 [1].
183 3.5 NOTIFY Bodies
185 The body of the notification contains a conference information
186 document. All implementations MUST support the type
187 "application/conference-info+xml", defined in Section 4. Other
188 formats MAY be supported.
190 When a client generates a SUBSCRIBE request, and that request
191 contains an Accept header, the "application/conference-info+xml"
192 format MUST be included in the header. Other formats MAY be listed.
193 The default value for the Accept header when it is not present in a
194 request is "application/conference-info+xml".
196 Of course, the notifications generated by the server MUST be in one
197 of the formats specified in the Accept header in the SUBSCRIBE
198 request.
200 3.6 Notifier Processing of SUBSCRIBE Requests
202 The conference information contains very sensitive information.
203 Therefore, all subscriptions SHOULD be authenticated and then
204 authorized before approval. Authorization policy is at the discretion
205 of the administrator, as always. However, a few recommendations can
206 be made.
208 It is RECOMMENDED that all users in the conference be allowed to
209 subscribe to the conference.
211 3.7 Notifier Generation of NOTIFY Requests
213 Notifications SHOULD be generated for the conference whenever a new
214 participant joins, a participant leaves, and a dial-out attempt
215 succeeds or fails. Notifications MAY be generated for the conference
216 whenever the media mixing status of a user changes.
218 3.8 Subscriber Processing of NOTIFY Requests
220 The SIP Events framework expects packages to specify how a subscriber
221 processes NOTIFY requests in any package specific ways, and in
222 particular, how it uses the NOTIFY requests to contruct a coherent
223 view of the state of the subscribed resource.
225 Typically, the NOTIFY for the conference package will only contain
226 information about those users whose state in the conference has
227 changed. To construct a coherent view of the total state of all
228 users, a subscriber to the dialog package will need to combine
229 NOTIFYs received over time.
231 Notifications within this package can convey partial information;
232 that is, they can indicate information about a subset of the state
233 associated with the subscription. This means that an explicit
234 algorithm needs to be defined in order to construct coherent and
235 consistent state. The details of this mechanism are specific to the
236 particular document type. See Section 4.2 for information on
237 constructing coherent information from an application/conference-
238 info+xml document.
240 3.9 Handling of Forked Requests
242 By their nature, the conferences supported by this package are
243 centralized. Therefore, SUBSCRIBE requests for a conference should
244 not generally fork. Users of this package MUST NOT install more than
245 a single subscription as a result of a single SUBSCRIBE request.
247 3.10 Rate of Notifications
249 For reasons of congestion control, it is important that the rate of
250 notifications not become excessive. As a result, it is RECOMMENDED
251 that the server not generate notifications for a single subscriber at
252 a rate faster than once every 5 seconds.
254 3.11 State Agents
256 Conference state is ideally maintained in the element in which the
257 conference resides. Therefore, the elements that maintain the
258 conference are the ones best suited to handle subscriptions to it.
259 Therefore, the usage of state agents is NOT RECOMMENDED for this
260 package.
262 4 Conference Data Format
264 Conference information is an XML document [3] that MUST be well-
265 formed and SHOULD be valid. Dialog information documents MUST be
266 based on XML 1.0 and MUST be encoded using UTF-8. This specification
267 makes use of XML namespaces for identifying dialog information
268 documents and document fragments. The namespace URI for elements
269 defined by this specification is a URN [4], using the namespace
270 identifier 'ietf' defined by [5] and extended by [6]. This URN is:
272 urn:ietf:params:xml:ns:conference-info
274 A conference information document begins with the root element tag
275 "conference-info".
277 4.1 Structute of the Format
279 Conference information begins with the top level element
280 "conference-info". This element has three mandatory attributes:
282 version: This attribute allows the recipient of conference
283 information documents to properly order them. Versions
284 start at 0, and increment by one for each new document sent
285 to a subscriber. Versions are scoped within a subscription.
286 Versions MUST be representable using a 32 bit integer.
288 state: This attribute indicates whether the document contains
289 the full conference information, or whether it contains
290 only information on those users whose state have changed
291 since the previous document (partial).
293 entity: This attribute contains a URI that identifies the
294 conference whose information is reported in the remainder
295 of the document.
297 The "conference-info" element has zero or more "user" sub-elements
298 which contain information on the users in the conference.
300 4.1.1 User Element
302 Each user element has zero or one "status" elements, indicating their
303 status in the conference, zero or one "dialog" elements, indicating
304 their dialog information, and zero or one "media-state" elements,
305 indicating their media reception information.
307 The user element has one mandatory attribute, "uri" that indicates
308 the URI for the user in the conference. This is a logical identifier,
309 not a machine specific one (i.e., its taken from the To/From, not the
310 Contact). The optional attribute "display-name" contains a display
311 name for the user. The standard "xml:lang" language attribute can
312 also be present to indicate the language of the display name.
314 4.1.2 Status
316 The status element contains the status of the user in the conference.
317 The following statuses are defined:
319 active: The user is in an active dialog with the conference
320 host.
322 departed: The user sent a BYE, thus leaving the conference.
324 booted: The user was sent a BYE by the conference host, booting
325 them out of the conference.
327 failed: The server tried to bring the user into the conference,
328 but its attempt to contact the specific user resulted in a
329 non-200 class final response.
331 4.1.3 Dialog
333 The dialog element is defined in [7].
335 4.1.4 Media Status
337 The "media-status" element indicates the types of media that the user
338 is currently receiving in the conference. It consists of a series of
339 "media-stream" sub-elements, each of one describes a particular media
340 stream. Each "media-stream" element has a mandatory "media-type"
341 attribute that indicates the MIME media type for the stream. There is
342 also an optional "send-status" and "recv-status" attribute which
343 attribute which indicates the status of the media to/from that user.
345 If the "send-status" is "received-by-all", it means that the media
346 for that stream that is being generated by the user is being mixed by
347 the server and sent to all recipients. "muted" means that no one is
348 receiving their media. If it is "unknown", the server does not know
349 the status, perhaps because the media is being distributed via
350 multicast or multi-unicast.
352 If the "recv-status" is "receiving-all" it means that the user is
353 hearing all other participants. If it is "anchor-only", the user is
354 hearing media from just a single participant. If it is "unknown", the
355 server does not know the status, perhaps because the media is being
356 distributed via multicast or multi-unicast.
358 4.2 Constructing Coherent State
360 The conference information subscriber maintains a table for the list
361 of users in the conference. The table contains a row for each user.
363 Each row is indexed by a URI, present in the "uri" attribute of the
364 "user" element. The contents of each row contain the state of that
365 user as conveyed in the document. The table is also associated with a
366 version number. The version number MUST be initialized with the value
367 of the "version" attribute from the "conference-info" element in the
368 first document received. Each time a new document is received, the
369 value of the local version number, and the "version" attribute in the
370 new document, are compared. If the value in the new document is one
371 higher than the local version number, the local version number is
372 increased by one, and the document is processed. If the value in the
373 document is more than one higher than the local version number, the
374 local version number is set to the value in the new document, the
375 document is processed, and the subscriber SHOULD generate a refresh
376 request to trigger a full state notification. If the value in the
377 document is less than the local version, the document is discarded
378 without processing.
380 The processing of the conference information document depends on
381 whether it contains full or partial state. If it contains full state,
382 indicated by the value of the "state" attribute in the "conference-
383 info" element, the contents of the table are flushed. They are
384 repopulated from the document. A new row in the table is created for
385 each "user" element. If the document contains partial state, as
386 indicated by the value of the "state" attribute in the "conference-
387 info" element, the document is used to update the table. For each
388 "user" element in the document, the subscriber checks to see whether
389 a row exists for that user. This check is done by comparing the URI
390 in the "uri" attribute of the "user" element with the URI associated
391 with the row. If the user doesn't exist in the table, a row is added,
392 and its state is set to the information from that "user" element. If
393 the user does exist, its state is updated to be the information from
394 that "user" element. If a row is updated or created, such that its
395 state is now booted, failed or departed, that entry MAY be removed
396 from the table at any time.
398 4.3 Schema
400 The following is the schema for the application/conference-info+xml
401 type:
403
404
411
412
415
416
419
420
421
422
424
426
427
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
449
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
473
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
500 OPEN ISSUE: We need to register the schema for the dialog
501 info package in order to have a stable reference for it in
502 the conference info schema above.
504 4.4 Example
506 The following is an example conference information document:
508
509
510 active
511
512
513
514
515
516 active
517
518
520 This document describes a conference with two users, both of which
521 are active.
523 5 Security Considerations
525 Subscriptions to conference state can reveal very sensitive
526 information. For this reason, the document recommends authentication
527 and authorization, and provides guidelines on sensible authorization
528 policies.
530 Since the data in notifications is sensitive as well, end-to-end SIP
531 encryption mechanisms using S/MIME SHOULD be used to protect it.
533 6 IANA Considerations
535 This document registers a new MIME type, application/conference-
536 info+xml and registers a new XML namespace.
538 6.1 application/conference-info+xml MIME Registration
540 MIME media type name: application
542 MIME subtype name: conference-info+xml
544 Mandatory parameters: none
546 Optional parameters: Same as charset parameter application/xml
547 as specified in RFC 3023 [8].
549 Encoding considerations: Same as encoding considerations of
550 application/xml as specified in RFC 3023 [8].
552 Security considerations: See Section 10 of RFC 3023 [8] and
553 Section 5 of this specification.
555 Interoperability considerations: none.
557 Published specification: This document.
559 Applications which use this media type: This document type has
560 been used to support SIP conferencing applications.
562 Additional Information:
564 Magic Number: None
566 File Extension: .cif or .xml
568 Macintosh file type code: "TEXT"
570 Personal and email address for further information: Jonathan
571 Rosenberg,
573 Intended usage: COMMON
575 Author/Change controller: The IETF.
577 6.2 URN Sub-Namespace Registration for
578 urn:ietf:params:xml:ns:conference-info
580 This section registers a new XML namespace, as per the guidelines in
581 [6].
583 URI: The URI for this namespace is
584 urn:ietf:params:xml:ns:conference-info.
586 Registrant Contact: IETF, SIMPLE working group,
587 , Jonathan Rosenberg
588 .
590 XML:
592 BEGIN
593
594
596
597
598
600 Dialog Information Namespace
601
603 Namespace for Dialog Information
604 application/conference-info+xml
605 See RFCXXXX.
606
607