idnits 2.17.1
draft-ietf-sipping-conference-package-01.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:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 5 instances of too long lines in the document, the longest one
being 6 characters in excess of 72.
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 (June 30, 2003) is 7599 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)
** Obsolete normative reference: RFC 3265 (ref. '2') (Obsoleted by RFC 6665)
== Outdated reference: A later version (-03) exists of
draft-ietf-sip-callee-caps-00
-- Possible downref: Non-RFC (?) normative reference: ref. '5'
** Obsolete normative reference: RFC 2141 (ref. '6') (Obsoleted by RFC 8141)
** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '7')
== Outdated reference: A later version (-01) exists of
draft-mahy-xcon-media-policy-control-00
-- Possible downref: Normative reference to a draft: ref. '9'
** Obsolete normative reference: RFC 3023 (ref. '10') (Obsoleted by RFC
7303)
== Outdated reference: A later version (-06) exists of
draft-ietf-sipping-dialog-package-01
== Outdated reference: A later version (-04) exists of
draft-ietf-sipping-mwi-03
== Outdated reference: A later version (-05) exists of
draft-ietf-sipping-conferencing-framework-00
== Outdated reference: A later version (-12) exists of
draft-ietf-simple-xcap-00
== Outdated reference: A later version (-02) exists of
draft-koskelainen-xcon-xcap-cpcp-usage-00
-- Obsolete informational reference (is this intentional?): RFC 2327 (ref.
'20') (Obsoleted by RFC 4566)
Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 SIPPING J. Rosenberg
3 Internet-Draft dynamicsoft
4 Expires: December 29, 2003 H. Schulzrinne
5 Columbia University
6 June 30, 2003
8 A Session Initiation Protocol (SIP) Event Package for Conference
9 State
10 draft-ietf-sipping-conference-package-01
12 Status of this Memo
14 This document is an Internet-Draft and is in full conformance with
15 all provisions of Section 10 of RFC2026.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that other
19 groups may also distribute working documents as Internet-Drafts.
21 Internet-Drafts are draft documents valid for a maximum of six months
22 and may be updated, replaced, or obsoleted by other documents at any
23 time. It is inappropriate to use Internet-Drafts as reference
24 material or to cite them other than as "work in progress."
26 The list of current Internet-Drafts can be accessed at http://
27 www.ietf.org/ietf/1id-abstracts.txt.
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html.
32 This Internet-Draft will expire on December 29, 2003.
34 Copyright Notice
36 Copyright (C) The Internet Society (2003). All Rights Reserved.
38 Abstract
40 This document defines a conference event package for the Session
41 Initiation Protocol (SIP) Events framework, along with a data format
42 used in notifications for this package. The conference package allows
43 users to subscribe to a conference URI. Notifications are sent about
44 changes in the membership of this conference, the state of the
45 dialogs that compose the conference, and general information about
46 the conference.
48 Table of Contents
50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
52 3. Conference Event Package . . . . . . . . . . . . . . . . . . 5
53 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . . 5
54 3.2 Event Package Parameters . . . . . . . . . . . . . . . . . . 5
55 3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . 6
56 3.4 Subscription Duration . . . . . . . . . . . . . . . . . . . 6
57 3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 6
58 3.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . . 7
59 3.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . . 7
60 3.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 7
61 3.9 Handling of Forked Requests . . . . . . . . . . . . . . . . 8
62 3.10 Rate of Notifications . . . . . . . . . . . . . . . . . . . 8
63 3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . . 8
64 4. Conference Data Format . . . . . . . . . . . . . . . . . . . 9
65 4.1 Structute of the Format . . . . . . . . . . . . . . . . . . 9
66 4.1.1 Conferencing Service Element . . . . . . . . . . . . . . . . 9
67 4.1.2 User Element . . . . . . . . . . . . . . . . . . . . . . . . 10
68 4.1.3 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
69 4.1.4 Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
70 4.1.5 Media Streams . . . . . . . . . . . . . . . . . . . . . . . 11
71 4.2 Constructing Coherent State . . . . . . . . . . . . . . . . 12
72 4.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
73 4.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 15
74 5. Security Considerations . . . . . . . . . . . . . . . . . . 16
75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17
76 6.1 conference Event Package Registration . . . . . . . . . . . 17
77 6.2 application/conference-info+xml MIME Registration . . . . . 17
78 6.3 URN Sub-Namespace Registration for
79 urn:ietf:params:xml:ns:conference-info . . . . . . . . . . . 18
80 6.4 XML Schema Registration . . . . . . . . . . . . . . . . . . 19
81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
82 Normative References . . . . . . . . . . . . . . . . . . . . 21
83 Informative References . . . . . . . . . . . . . . . . . . . 22
84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23
85 Intellectual Property and Copyright Statements . . . . . . . 24
87 1. Introduction
89 The Session Initiation Protocol (SIP) [3] Events framework [2]
90 defines general mechanisms for subscribing to, and receiving
91 notifications of, events within SIP networks. It introduces the
92 notion of a package, which is a specific "instantiation" of the
93 events framework for a well-defined set of events. Packages have been
94 defined for user presence [11], watcher information [12], and message
95 waiting indicators [14], amongst others. Here, we define an event
96 package for SIP conferences. This package provides the conference
97 notification service as outlined in the SIP conferencing framework
98 [15]. As described there, subscriptions to a conference URI are
99 routed to the focus that is handling the conference. It acts as the
100 notifer, and provides clients with updates on conference state.
102 The information provided by this package is broken into several
103 general categories:
105 General State: A small amount of general conference state is
106 provided, primarily for the purposes of bootstrapping access to
107 other conference services, such as media and conference policy
108 controls.
110 Membership State: The members of the conference, and their state
111 within the conference.
113 Dialog State: The state of the dialogs for users connected to the
114 conference.
116 Media State: Information about what media users in the conference are
117 receiving.
119 2. Terminology
121 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
122 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
123 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
124 indicate requirement levels for compliant implementations.
126 3. Conference Event Package
128 The conference event package allows a user to subscribe to a
129 conference. In SIP, conferences are represented by URIs. These URIs
130 route to a SIP user agent, called a focus, that is responsible for
131 ensuring that all users in the conference can communicate with each
132 other [15]. The focus has sufficient information about the state of
133 the conference to inform subscribers about it.
135 This section provides the details for defining a SIP Events package,
136 as specified by [2].
138 3.1 Event Package Name
140 The name of this event package is "conference". This package name is
141 carried in the Event and Allow-Events header, as defined in [2].
143 3.2 Event Package Parameters
145 Two Event header field parameters are defined for this package. The
146 first is "recurse". The parameter has no values. When present, it
147 informs the server that it should check whether any participants in
148 the conference are themselves a focus, and if so, generate a
149 subscription to their conference state with the "recurse" attribute.
150 The focus can determine whether a participant is a focus based on the
151 presence of the "isfocus" capability indication in the Contact header
152 field provided by the participant [4]. The users reported in
153 notifications from this recursed subscription are reported to the
154 original subscriber. The result is that the list of users reported to
155 the subscriber represents the complete user list even when cascaded
156 conferences are used.
158 The second Event header field parameter is "type". Its value is a
159 comma separated list of the types of conference information that are
160 desired. This specification defines four values - "general",
161 "membership", "dialog", and "basic-media". When any one of these is
162 present, it means that the corresponding conference information is
163 desired. The specific components of a conference information document
164 corresponding to each of these values are described below. Additional
165 values for this parameter MAY be defined by extensions to this
166 package. Such extensions are anticipated to handle membership and
167 media policy state.
169 Both of these parameters MUST have the same value in a initial
170 SUBSCRIBE request and any refreshes of the resulting subscription. In
171 other words, their values are fixed for the duration of the
172 subscription. The default meaning of the "type" parameter, when not
173 present, is that the focus should send all information it has about
174 the conference. When present, the type parameter MUST have at least
175 one value.
177 The BNF for these parameters is:
179 recurse = "recurse"
180 type = "type" EQUAL SWS DQUOTE conf-info *("," conf-info)
181 DQUOTE
182 ;; EQUAL, SWS, DQUOTE from RFC3261
183 conf-info = "general" | "membership" | "dialog" | "basic-media" |
184 token
186 Example:
188 Event: conference;recurse;type="membership,general"
190 3.3 SUBSCRIBE Bodies
192 A SUBSCRIBE for a dialog package MAY contain a body. This body
193 defines a filter to apply to the subscription. Filter documents are
194 not specified in this document, and at the time of writing, are
195 expected to be the subject of future standardization activity.
197 A SUBSCRIBE for a dialog package MAY be sent without a body. This
198 implies the default subscription filtering policy. The default policy
199 is:
201 o Notifications are generated every time there is any change in the
202 state of the conference, where that change is in a piece of
203 information that the subscriber has indicated (using the "type"
204 Event header field parameter) an interest in receiving.
206 o Notifications do not normally contain full state; rather, they
207 only indicate the state that has changed. The exception is a
208 NOTIFY sent in response to a SUBSCRIBE. These NOTIFYs contain the
209 full state of the information requested by the subscriber.
211 3.4 Subscription Duration
213 The default expiration time for a subscription to a conference is one
214 hour. Once the conference ends, all subscriptions to that particular
215 conference are terminated, with a reason of "noresource" [2].
217 3.5 NOTIFY Bodies
218 As described in RFC 3265 [2], the NOTIFY message will contain bodies
219 that describe the state of the subscribed resource. This body is in a
220 format listed in the Accept header field of the SUBSCRIBE, or a
221 package-specific default if the Accept header field was omitted from
222 the SUBSCRIBE.
224 In this event package, the body of the notification contains a
225 conference information document. This document describes the state of
226 a conference. All subscribers and notifiers MUST support the
227 "application/conference-info+xml" data format described in Section 4.
228 The subscribe request MAY contain an Accept header field. If no such
229 header field is present, it has a default value of "application/
230 conference-info+xml". If the header field is present, it MUST include
231 "application/conference-info+xml", and MAY include any other types
232 capable of representing dialog state.
234 Of course, the notifications generated by the server MUST be in one
235 of the formats specified in the Accept header field in the SUBSCRIBE
236 request.
238 3.6 Notifier Processing of SUBSCRIBE Requests
240 The conference information contains very sensitive information.
241 Therefore, all subscriptions SHOULD be authenticated and then
242 authorized before approval. Authorization policy is at the discretion
243 of the administrator, as always. However, a few recommendations can
244 be made.
246 It is RECOMMENDED that all users in the conference be allowed to
247 subscribe to the conference.
249 3.7 Notifier Generation of NOTIFY Requests
251 Notifications SHOULD be generated for the conference whenever there
252 is a change in the state in any of the information types requested by
253 the subscriber. For "membership", these changes generally occur when
254 a new participant joins, a participant leaves, and a dial-out attempt
255 succeeds or fails. For "dialog", these changes occur when a dialog is
256 created, terminated, or updated through a target refresh request. For
257 "basic-media", these changes occur when the media types receive by a
258 participant change. For "general", these changes occur when the
259 conference policy protocol URIs change.
261 3.8 Subscriber Processing of NOTIFY Requests
263 The SIP Events framework expects packages to specify how a subscriber
264 processes NOTIFY requests in any package specific ways, and in
265 particular, how it uses the NOTIFY requests to contruct a coherent
266 view of the state of the subscribed resource.
268 Typically, the NOTIFY for the conference package will only contain
269 information about those users whose state in the conference has
270 changed. To construct a coherent view of the total state of all
271 users, a subscriber to the dialog package will need to combine
272 NOTIFYs received over time.
274 Notifications within this package can convey partial information;
275 that is, they can indicate information about a subset of the state
276 associated with the subscription. This means that an explicit
277 algorithm needs to be defined in order to construct coherent and
278 consistent state. The details of this mechanism are specific to the
279 particular document type. See Section 4.2 for information on
280 constructing coherent information from an application/
281 conference-info+xml document.
283 3.9 Handling of Forked Requests
285 By their nature, the conferences supported by this package are
286 centralized. Therefore, SUBSCRIBE requests for a conference should
287 not generally fork. Users of this package MUST NOT install more than
288 a single subscription as a result of a single SUBSCRIBE request.
290 3.10 Rate of Notifications
292 For reasons of congestion control, it is important that the rate of
293 notifications not become excessive. As a result, it is RECOMMENDED
294 that the server not generate notifications for a single subscriber at
295 a rate faster than once every 5 seconds.
297 3.11 State Agents
299 Conference state is ideally maintained in the element in which the
300 conference resides. Therefore, the elements that maintain the
301 conference are the ones best suited to handle subscriptions to it.
302 Therefore, the usage of state agents is NOT RECOMMENDED for this
303 package.
305 4. Conference Data Format
307 Conference information is an XML document [5] that MUST be
308 well-formed and SHOULD be valid. Dialog information documents MUST be
309 based on XML 1.0 and MUST be encoded using UTF-8. This specification
310 makes use of XML namespaces for identifying dialog information
311 documents and document fragments. The namespace URI for elements
312 defined by this specification is a URN [6], using the namespace
313 identifier 'ietf' defined by [7] and extended by [8]. This URN is:
315 urn:ietf:params:xml:ns:conference-info
317 A conference information document begins with the root element tag
318 "conference-info".
320 4.1 Structute of the Format
322 Conference information begins with the top level element
323 "conference-info". This element has three mandatory attributes:
325 version: This attribute allows the recipient of conference
326 information documents to properly order them. Versions start at 0,
327 and increment by one for each new document sent to a subscriber.
328 Versions are scoped within a subscription. Versions MUST be
329 representable using a 32 bit integer.
331 state: This attribute indicates whether the document contains the
332 full conference information, or whether it contains only the
333 information that has changed since the previous document
334 (partial).
336 entity: This attribute contains the conference URI that identifies
337 the conference being described in the document.
339 The "conference-info" element has zero or more "conf-service"
340 elements, which provide URIs for access conferencing services, such
341 as media policy and conference policy control. This is followed by
342 zero or more "user" sub-elements which contain information on the
343 users in the conference.
345 4.1.1 Conferencing Service Element
347 The "conf-service" element contains a URI that can be used to access
348 some additional conferencing service. The element contains the
349 following attributes:
351 id: This attribute provides a unique identifier (unique within the
352 context of the subscription) for the service. The attribute is
353 mandatory.
355 type: This attribute contains a string which indicates the type of
356 service. Defined values are "conf-policy", to indicate that the
357 URI is for manipulating the conference policy [17][18],
358 "media-policy", to indicate that the URI is for manipulating the
359 media policy [9], and "floor-control", to indicate that the URI is
360 for access to floor control services [19]. The attribute is
361 mandatory.
363 There MUST only be one conf-service for each type of service.
364 Additional service types may be defined in the future.
366 OPEN ISSUE: Once a protocol becomes solidified, we will need to
367 add some additional content here. For example, if XCAP [16] is
368 used, the AUID should be provided here. We may want to move to a
369 model where each service type is a unique XML element; that would
370 allow for the schema to impose the contraint on a single URI for
371 each service type.
373 The "conf-service" element is only provided in notifications if the
374 subscriber included the value of "general" in its "type" Event header
375 field parameter.
377 4.1.2 User Element
379 Each user element has zero or one "status" elements, indicating their
380 status in the conference, zero or one "dialog" elements, indicating
381 their dialog information, and zero or one "media-streams" elements,
382 indicating their media reception information.
384 The user element has one mandatory attribute, "uri" that indicates
385 the URI for the user in the conference. This is a logical identifier,
386 not a machine specific one (i.e., its taken from the authenticated
387 identity of the participant). The optional attribute "display-name"
388 contains a display name for the user. The standard "xml:lang"
389 language attribute can also be present to indicate the language of
390 the display name.
392 4.1.3 Status
394 The status element contains the status of the user in the conference.
395 The following statuses are defined:
397 active: The user is in an active dialog with the focus.
399 departed: The user sent a BYE, thus leaving the conference.
401 booted: The user was sent a BYE by the conference host, booting them
402 out of the conference.
404 failed: The server tried to bring the user into the conference, but
405 its attempt to contact the specific user resulted in a non-200
406 class final response.
408 The "status" element is only provided in notifications if the
409 subscriber included the value of "membership" in its "type" Event
410 header field parameter.
412 4.1.4 Dialog
414 The dialog element is defined in [13]. It is presented from the
415 viewpoint of the focus. The "dialog" element is only provided in
416 notifications if the subscriber included the value of "dialog" in its
417 "type" Event header field parameter.
419 4.1.5 Media Streams
421 The "media-streams" element indicates the media streams that the user
422 is currently connected to. Here, "connected to" implies that a user
423 has a media line in their SDP [20] which is associated with a media
424 stream managed by the focus (see Section 2.1 of [9]). With this
425 definition, a user is connected to a media stream even if they are
426 not sending any media.
428 The "media-streams" element has zero or more "media-stream"
429 sub-elements. The value of the "media-stream" element is an
430 identifier, unique within the conference, which identifies the media
431 stream that a user is connected to [9]. The "media-stream" element
432 also has a mandatory "media-type" attribute which identifies the
433 media type (audio, video, message and application) of the media
434 stream.
436 The "media-streams" element is only provided in notifications if the
437 subscriber included the value of "basic-media" in its "type" Event
438 header field parameter.
440 OPEN ISSUE: This needs to be aligned with the final media policy
441 mechanisms done in xcon. If we wish this draft to proceed
442 independently, we should probably remove any notion of media
443 information.
445 4.2 Constructing Coherent State
447 The conference information subscriber maintains a table for the list
448 of users in the conference. The table contains a row for each user.
449 Each row is indexed by a URI, present in the "uri" attribute of the
450 "user" element. The contents of each row contain the state of that
451 user as conveyed in the document. The subscriber also maintains a
452 table for the service URIs in the conference. This table contains a
453 row for each service type. Each row is indexed by a token, present in
454 the "id" attribute of the "conf-service" element. The contents of the
455 row contain the URI and type of that service.
457 Both tables are associated with a version number. The version number
458 MUST be initialized with the value of the "version" attribute from
459 the "conference-info" element in the first document received. Each
460 time a new document is received, the value of the local version
461 number, and the "version" attribute in the new document, are
462 compared. If the value in the new document is one higher than the
463 local version number, the local version number is increased by one,
464 and the document is processed. If the value in the document is more
465 than one higher than the local version number, the local version
466 number is set to the value in the new document, the document is
467 processed, and the subscriber SHOULD generate a refresh request to
468 trigger a full state notification. If the value in the document is
469 less than the local version, the document is discarded without
470 processing.
472 The processing of the conference information document depends on
473 whether it contains full or partial state. If it contains full state,
474 indicated by the value of the "state" attribute in the
475 "conference-info" element, the contents of both tables are flushed.
476 They are repopulated from the document. A new row in the user table
477 is created for each "user" element, and a new row in the conferencing
478 services table is created for each "conf-service" element. If the
479 document contains partial state, as indicated by the value of the
480 "state" attribute in the "conference-info" element, the document is
481 used to update the tables. For each "user" element in the document,
482 the subscriber checks to see whether a row exists for that user in
483 the user table. This check is done by comparing the URI in the "uri"
484 attribute of the "user" element with the URI associated with the row.
485 If the user doesn't exist in the table, a row is added, and its state
486 is set to the information from that "user" element. If the user does
487 exist, its state is updated to be the information from that "user"
488 element. If a row is updated or created, such that its state is now
489 booted, failed or departed, that entry MAY be removed from the table
490 at any time.
492 Similarly, for each each "conf-service" element in the document, the
493 subscriber checks to see whether a row exists for that service in the
494 service table. This check is done by comparing the id in the "id"
495 attribute of the "conf-service" element with the id associated with
496 the row. If the service doesn't exist in the table, a row is added,
497 and its URI and type are set to be the information from the
498 "conf-service" element. Since it is not expected that this
499 information will change during the lifetime of the conference, there
500 is no way to indicate removal of a service.
502 OPEN ISSUE: Is this really the right way to bootstrap these URIs?
503 The information really is static, and placing it in an event
504 package will result in a waste of bandwidth during full-state
505 updates.
507 4.3 Schema
509
510
517
518
520
521
523
524
525
526
528
530
532
533
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
556
558
559
560
561
562
563
564
565
566
567
568
569
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
608 4.4 Example
610 The following is an example conference information document:
612
613
614 active
615
616 8hha7
617
618
619
620 active
621
622
624 This document describes a conference with two users, both of which
625 are active.
627 5. Security Considerations
629 Subscriptions to conference state can reveal very sensitive
630 information. For this reason, the document recommends authentication
631 and authorization, and provides guidelines on sensible authorization
632 policies.
634 Since the data in notifications is sensitive as well, end-to-end SIP
635 encryption mechanisms using S/MIME SHOULD be used to protect it.
637 6. IANA Considerations
639 This document registers a SIP event package, a new MIME type,
640 application/conference-info+xml, a new XML namespace, and a new XML
641 schema.
643 6.1 conference Event Package Registration
645 This specification registers an event package, based on the
646 registration procedures defined in RFC 3265 [2]. The following is the
647 information required for such a registration:
649 Package Name: conference
651 Package or Template-Package: This is a package.
653 Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX
654 with the RFC number of this specification).
656 Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.
658 6.2 application/conference-info+xml MIME Registration
660 MIME media type name: application
662 MIME subtype name: conference-info+xml
664 Mandatory parameters: none
666 Optional parameters: Same as charset parameter application/xml as
667 specified in RFC 3023 [10].
669 Encoding considerations: Same as encoding considerations of
670 application/xml as specified in RFC 3023 [10].
672 Security considerations: See Section 10 of RFC 3023 [10] and Section
673 5 of this specification.
675 Interoperability considerations: none.
677 Published specification: This document.
679 Applications which use this media type: This document type has been
680 used to support SIP conferencing applications.
682 Additional Information:
684 Magic Number: None
686 File Extension: .cif or .xml
688 Macintosh file type code: "TEXT"
690 Personal and email address for further information: Jonathan
691 Rosenberg,
693 Intended usage: COMMON
695 Author/Change controller: The IETF.
697 6.3 URN Sub-Namespace Registration for
698 urn:ietf:params:xml:ns:conference-info
700 This section registers a new XML namespace, as per the guidelines in
701 [8].
703 URI: The URI for this namespace is
704 urn:ietf:params:xml:ns:conference-info.
706 Registrant Contact: IETF, SIPPING working group, ,
707 Jonathan Rosenberg .
709 XML:
711 BEGIN
712
713
715
716
717
719 Dialog Information Namespace
720
722 Namespace for Dialog Information
723 urn:ietf:params:xml:ns:conference-info
724 See RFCXXXX.
725
726