idnits 2.17.1 draft-ietf-xcon-cpcp-xcap-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 29 longer pages, the longest (page 26) being 74 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 32 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 181 instances of too long lines in the document, the longest one being 87 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 == Line 270 has weird spacing: '...o other name...' == Line 439 has weird spacing: '...owed to subs...' == Line 901 has weird spacing: '...gnaling pro...' == Line 917 has weird spacing: '... server can a...' == Line 919 has weird spacing: '...ent. It is a...' == (8 more instances...) -- 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 (April 19, 2004) is 7311 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) == Unused Reference: '1' is defined on line 1305, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1313, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1348, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (ref. '2') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 3023 (ref. '6') (Obsoleted by RFC 7303) -- No information found for draft-ietf-xcon-cpcp-req - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-02 == Outdated reference: A later version (-05) exists of draft-ietf-simple-xcap-list-usage-02 == Outdated reference: A later version (-03) exists of draft-ietf-simple-xcap-package-01 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-01 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-conferencing-framework (ref. '11') == Outdated reference: A later version (-12) exists of draft-ietf-sipping-conference-package-03 Summary: 6 errors (**), 0 flaws (~~), 18 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON H. Khartabil 3 Internet-Draft P. Koskelainen 4 Expires: October 18, 2004 Nokia 5 April 19, 2004 7 The Conference Policy Control Protocol (CPCP) 8 draft-ietf-xcon-cpcp-xcap-00 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on October 18, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This document describes the Conference Policy Control Protocol 39 (CPCP). It specifies an Extensible Markup Language (XML) Schema that 40 enumerates the conference policy data elements that enable a user to 41 define a conference policy. It also defines an XML Configuration 42 Access Protocol (XCAP) application usage that is needed to store and 43 manipulate a conference policy. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Conventions Used in This Document . . . . . . . . . . . . 3 49 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 50 4. Structure of a Conference Policy document . . . . . . . . 4 51 4.1 MIME Type for CPCP XML Document . . . . . . . . . . . . . 6 52 4.2 XML Document Description . . . . . . . . . . . . . . . . . 6 53 4.2.1 element . . . . . . . . . . . . . . 6 54 4.2.2 element . . . . . . . . . . . . . . . . 6 55 4.2.3 element . . . . . . . . . . . . . . . . 7 56 4.2.4 (Access Control List) element . . . . . . . . . . . 8 57 4.2.5 (Privilege Control List) element . . . . . . . . . . 9 58 4.2.6
(Dial-Out List) element . . . . . . . . . . . . . . . 10 59 4.2.7 (Security Control) element . . . . . . . . . . . . . 10 60 4.2.8 element . . . . . . . . . . . . 11 61 4.2.9 element . . . . . . . . . . . . 12 62 4.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 12 63 5. Floor Control Policy vs. Floor Control Protocol . . . . . 19 64 6. An XCAP Usage for Conference Policy Manipulation . . . . . 19 65 6.1 Application Unique ID . . . . . . . . . . . . . . . . . . 19 66 6.2 Resource Interdependencies . . . . . . . . . . . . . . . . 19 67 6.3 Additional Constraints . . . . . . . . . . . . . . . . . . 20 68 6.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . 20 69 6.5 Authorization Policies . . . . . . . . . . . . . . . . . . 20 70 6.6 MIME Type for CPCP XML Document . . . . . . . . . . . . . 20 71 6.7 Overview of Operation . . . . . . . . . . . . . . . . . . 20 72 6.8 Communication Between Conference Entities . . . . . . . . 21 73 6.9 Conference Creation and Termination . . . . . . . . . . . 21 74 6.10 Manipulating the Participant Lists . . . . . . . . . . . . 21 75 6.10.1 Expelling a Participant . . . . . . . . . . . . . . . . . 22 76 6.11 Privileges: Who can modify the conference policy . . . . . 22 77 6.12 Conference URI(s) . . . . . . . . . . . . . . . . . . . . 23 78 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 23 79 8. Security Considerations . . . . . . . . . . . . . . . . . 26 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . 26 81 9.1 XCAP Application Usage ID . . . . . . . . . . . . . . . . 26 82 9.2 application/conference-policy+xml mime TYPE . . . . . . . 26 83 9.3 URN Sub-Namespace Registration for 84 urn:ietf:params:xml:ns:conference-policy . . . . . . . . . 27 85 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . 28 86 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 28 87 Normative References . . . . . . . . . . . . . . . . . . . 28 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 29 89 Intellectual Property and Copyright Statements . . . . . . 31 91 1. Introduction 93 SIP conferencing framework [11] defines the mechanisms for 94 multi-party centralized conferencing in a SIP environment. Existing 95 SIP mechanisms allow users, for example, to join and leave a 96 conference. A centralized serve, called focus, can expel and invite 97 users, and may have proprietary access control lists and user 98 privilege definitions. However, in many cases it is useful to have a 99 standardised conference policy elements such as access control lists 100 and a standardised protocol means to manipulate them. The 101 requirements for such protocol are defined in [7]. This document 102 provides an XML Schema Section 4.3 that enumerates the conference 103 policy data elements that enable a user to define a conference 104 policy. It also defines an XML Configuration Access Protocol (XCAP) 105 [8] application usage that is needed to store and manipulate a 106 conference policy. 108 Other mechanisms, such as web page or voice response system can also 109 be used to manipulate conference policy data. 111 XCAP has many advantages in its use for conference policy control 112 protocol. It is a HTTP 1.1 based protocol that allows clients to 113 read, write, modify and delete application data stored in XML format 114 at a server. XCAP maps XML document elements and attributes to HTTP 115 URIs that can be directly accessed by HTTP. One application area 116 which has already adopted XCAP is the manipulation of event lists 117 [9]. 119 2. Conventions Used in This Document 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119. 125 3. Terminology 127 This document uses terminology from [11]. Some additional definitions 128 are introduced here. 130 ACL 132 Access control list (ACL) defines users who can join to a 133 conference. Users may have allowed, blocked, pending or 134 expelled status in the list. Each conference has its own ACL. 136 CPS 138 Conference Policy Server. See [11] 140 Conference participant 142 Conference participant is a user who has on-going session (e.g. 143 SIP dialog) with the conference focus. 145 Floor control 147 Floor control is a mechanism that enables applications or users 148 to gain safe and mutually exclusive or non-exclusive access to 149 the shared object or resource in a conference. 151 Dial-Out List (DL) 153 Dial-out list (DL) is a list of users who the focus needs to 154 invite to the conference. 156 PCL 158 Privilege control control (PCL) defines privileges for a user. 159 Each user in a conference may have different list of privileges 160 and each conference has its own PCL. 162 Privileged user 164 In this document, a privileged user is the creator. Defining 165 privileges to modify certain parts of a conference policy is 166 outside the scope of this document. 168 CPS XCAP URI 170 The URI of the XCAP server that is used to create the 171 conference. The URI contsruction is specified in [8]. It is 172 refered to in XCAP as the host part. 174 Conference Policy URI 176 The URI of conference policy. In XCAP, it is the CPS XCAP URI 177 along with the abs_path. It identifies the XML document. The 178 URI contsruction is specified in [8]. 180 4. Structure of a Conference Policy document 182 The conference policy document is an XML [5] document that MUST be 183 well-formed and MUST be valid. Conference policy documents MUST be 184 based on XML 1.0 and MUST be encoded using UTF-8. This specification 185 makes use of XML namespaces for identifying conference policy 186 documents and document fragments. The namespace URI for elements 187 defined by this specification is a URN [2], using the namespace 188 identifier 'ietf' defined by [3] and extended by [13]. This URN is: 190 urn:ietf:params:xml:ns:conference-policy 192 A conference policy document begins with the root element tag 193 "conference-policy". Other elements from different namespaces MAY be 194 present for the purposes of extensibility. Elements or attributes 195 from unknown namespaces MUST be ignored. The conference policy is 196 build up using multiple namespaces: 198 o "urn:ietf:params:xml:ns:conference-settings": This namespace 199 defines elements for conference setting. The inclusion of this 200 namespace is optional. It contains the mandatory element 201 . This element contains the conference URI(s) 202 and maximum number of participants. It can occur only once in the 203 document. 205 o "urn:ietf:params:xml:ns:conference-info": This namespace defines 206 elements to carry conference information. The inclusion of this 207 namespace is optional. It contains the mandatory element 208 . This element includes informational describing 209 the conference, e.g. for search purposes. This information can 210 also be used in the session description when the focus is sending 211 invitations. It can occur only once in the document. 213 o "urn:ietf:params:xml:ns:conference-time": This optional namespace 214 defines conference time information. It defines the mandatory 215 element that includes elements defining start 216 and stop times for a conference. 218 o "urn:ietf:params:xml:ns:conference-acl": This optional namespace 219 is for the access control list. It defines the mandatory 220 element that contains URIs for users who can dial into the 221 conference, users who are blocked from dialling in, and expelled 222 users. 224 o "urn:ietf:params:xml:ns:conference-pcl": This optional namespace 225 is for the privilege control list. It defines the mandatory 226 element that contains privileges and URIs for users who have those 227 privileges. 229 o "urn:ietf:params:xml:ns:conference-dl": This optional namespace is 230 for the dial-out list. It defines the mandatory
element that 231 contains URIs for users that the focus will invite to the 232 conference. 234 o "urn:ietf:params:xml:ns:conference-sc": This optional namespace is 235 for security control. It defines the element that contains 236 conference security level and passwords. 238 o "urn:ietf:params:xml:ns:conference-mp": This optional namespace is 239 for the media policy for a conference. It defines the 240 element that contains the media types to 241 be used in the conference. 243 o "urn:ietf:params:xml:ns:conference-fp": This optional namespace is 244 for the floor control policy. It defines the 245 element. 247 The elements are described in more detail in the forthcoming 248 sections. 250 4.1 MIME Type for CPCP XML Document 252 The MIME type for the CPCP XML document is "application/ 253 conference-policy+xml". 255 4.2 XML Document Description 257 4.2.1 element 259 The mandatory element contains 2 sub-elements; 260 the element and the element. 262 is an optional element. It can occur more than once 263 to accommodate multiple signaling protocols. Once a conference URI is 264 set, it MUST NOT be changed or removed for the duration of the 265 conference. Only one URI per protocol MUST be set. URIs can be added 266 at any time. 268 This is in its own XML namespace, so it is separated from other 269 elements and hence relevant modification rights (privileges) can be 270 given more easily to other namespaces. 272 is an optional. It carries the maximum number 273 of participants allowed in the conference. When the maximum number of 274 participants threshold is reached, no new users are not allowed to 275 join until the number of participants decreases again. If using SIP, 276 the server can reject a request to join (INVITE) with a "480 277 Temporarily Unavailable" response. Alternatively, the sever may 278 implement a waiting queue. 280 4.2.2 element 282 Mandatory element has its own namespace and it can 283 occur only once in a document. It includes informative conference 284 parameters which may be helpful describing the purpose of a 285 conference, e.g. for search purposes or for providing host contact 286 information. The element, which describes 291 the current topic in a conference. The optional 292 element is the display name of the conference, which usually does not 293 change over time. 295 and are optional elements. They provide 296 additional textual information about the conference. This information 297 can be made available to potential conference participants by means 298 outside the scope of this document. Examples of usage could be 299 searching for a conference based on some keywords. The optional 300 element points to a URI where additional information about 301 the conference can be found. 303 The optional element contains several elements. It gives 304 additional information about the user hosting the conference. This 305 information can, for example, be included into the SDP fields of the 306 SIP INVITEs sent by the focus. The element is optional and can 307 occur more than once. 309 4.2.3 element 311 The information related to conference time and lifetime is contained 312 in the element. The conference may occur for a 313 limited period of time (i.e. bounded), or the conference may be 314 unbounded (i.e. it does not have a specified end time). Bounded 315 conferences may occur multiple times(e.g. on weekly basis). 317 has its own XML namespace. It contains one or more 318 elements each defining the time information 319 of a single conference occurrence. Multiple 320 elements MAY be used if a conference is active at multiple 321 irregularly spaced times; each additional 322 element contains time information for a specific occurrence. 324 For each occurrence, the element specifies when a 325 conference starts. the element specifies the time a 326 conference stops. If the element is not present, it 327 indicates that the conference starts immediately. If the 328 is set to zero, then conference occurrence is not bounded, i.e. 329 permanent, though it will not become active until the . 330 If the element is not present, it indicates that the 331 conference terminates as soon as the last participant leaves the 332 conference. The focus might wait a small period of time before 333 terminating the conference, in case a participant joins straight 334 after the last participant leaves. 336 When saying that a conference starts, or becomes active (start-time), 337 it means that the mixing starts. A focus will most likely allow 338 participants to connect shortly before start time, but may put them 339 on hold until the start time. Participants on the Dial out list may 340 also be dialled to shortly before start time. 342 A conference terminates with stop-time. The creator is free to set 343 the stop-time to be the time s/he leaves (and therefore the 344 conference terminates when s/he leaves), terminate the conference as 345 s/he leaves (modifying stop-time), or leave before the stop-time and 346 therefore the conference continues. The stop-time can be changed by 347 the conference creator, during the conference, to allow the extension 348 of the conference based on best effort. A conference always 349 terminates when the conference policy is removed, regardless of the 350 stop time. 352 The absence of this conference time information indicates that a 353 conference starts immediately and terminates when the conference 354 policy is removed. See Section 6.9 for more details 356 4.2.4 (Access Control List) element 358 ACL has its own XML namespace. 360 The purpose of Access Control List (ACL) is to control who can join 361 the conference.A conference has one consisting of one or more 362 elements and the parameter for those 363 URIs. Access-Types are one of Allowed/Blocked/Pending/Expelled. 364 Allowed means that the target is allowed to join the conference. 365 Blocked means that the target is not allowed to join the conference. 366 This can be used in the where the allowed URIs are wild-carded and 367 the user wants to explicitly block one potential participant, whose 368 URI falls within the wildcarded URIs, from joining. The other way 369 around is also possible where the blocked URIs are wildcarded and 370 the user wants to explicitly allow one potential participant, whose 371 URI falls within the wildcarded URIs, to join. Pending means that 372 authorisation for the target is not granted and while further 373 processing is required - such as consulting the moderator. Expelled 374 means that user is expelled from current conference and is not 375 allowed to join or be dialled-out (even if dial-out list includes 376 user's URI). 378 Wildcards are allowed in ACL as follows. The domain part is allowed 379 to be wildcard only if the username is a wildcard. Wildcard in the 380 domain part MUST be immediately after the @-sign. A wildcard in the 381 domain is interpreted as multiple zones. For example: 382 sip:*@*.example.com includes sip:*@engineering.example.com as well as 383 sip:*@tester.engineering.example.com. The use of wildcarding has been 384 restricted to avoid ambiguous entries in the access control list. 386 Examples of allowed wildcards are - sip:*@example.com, *@*.com, *@*. 388 Examples are not allowed wildcards are - sip:bob@example.*, 389 sip:bob@*.com, sip:*@example.*.com. 391 "Most-specific expression wins" policy is used if overlapping rules 392 are found. Basically, this means that user specific rule is searched 393 first and if it is not found, then most specific wildcard rule is 394 utilized. 396 There is a need for the ACL to contain an entry that defines the 397 default access types for users not explicitly allowed nor blocked 398 from joining the conference, i.e. everybody else. For example: 399 "Pending" action for *@*. If that entry is missing, the focus local 400 policy dictates the behaviour. 402 Sip: and sips: schemes are treated as equivalent in the ACL since it 403 defines users and not the security used by users. 405 It is also possible to ask the focus to refer users to the 406 conference. An optional Boolean attribute "refer" exists in the 407 that indicates to the server that the creator of the 408 conference wishes for the focus to refer the identified potential 409 participants to the conference when a conference occurrence has 410 started. In SIP, this is achieved by the focus sending a REFER 411 request to those potential participants. The default value for the 412 "refer" attribute is "false". 414 4.2.5 (Privilege Control List) element 416 Advanced privilege models can be applied in conferencing context 417 (e.g. who is allowed to modify ACL, who is allowed to expel users 418 etc). This document defines only one privilege and leaves the 419 definition of additional privileges (e.g. who can modify ACL) as a 420 separate standardisation effort. 422 The element is mandatory and has its own XML namespace. It 423 defines which users has what privileges. The element may 424 contain one or more elements. The element 425 carries 2 pieces of information: the target URI, and 426 the privileges for that URI, . All mandatory elements. 428 The target URI can be wildcarded as described for the ACL in Section 429 4.2.4. 431 Example URIs are: 433 sip:bob@company.com 435 sip:*@example.com 437 The only privilege defined in this document is 438 RIGHT_TO_SUBSCRIBE_TO_CONF_EVENT_PACKAGE. It defines which users are 439 allowed to subscribe to the conference state event package [12]and 440 be notified. 442 4.2.6
(Dial-Out List) element 444 The dial-out list (DL) is a list of user URIs that the focus uses to 445 learn who to invite to join a conference. This list can be updated 446 during the conference lifetime so it can be used for mid-conference 447 invites (and mass-invites) as well. 449 DL has its own XML namespace. 451 The
element includes a mandatory element. The 452 element includes the mandatory element. 453 This elements carries the URI of the user to be invited. 455 4.2.7 (Security Control) element 457 The conference security encompasses three aspects: controlling the 458 visibility of a conference, securing the SIP messages, and performing 459 authentication for individual users. 461 This element has its own XML namespace. 463 The conference security settings start with the mandatory >SC> 464 element. It contains the mandatory element. This element 465 can hold one of two values: visible or invisible. The 466 element controls whether information in the , 467 and elements may be made 468 available publicly. For example, an application at a conference 469 server might list the ongoing conferences on web page, or it may 470 allow searching for conferences based on the keywords listed in the 471 element. Setting to "invisible" 472 instructs the application not to reveal any such information. 473 However, information in other elements, such as , should not be 474 seen by anyone else other than a privileged user, even with the 475 element set to "visible". 477 We define two mechanisms for securing the signaling between users and 478 the focus: TLS and S/MIME. TLS is used to provide transport layer 479 security on a hop-by-hop basis. According to SIP [6], using SIPS URI 480 scheme in a request signifies that TLS must be used to secure each 481 hop over which the request is forwarded until the request reaches the 482 SIP entity responsible for the domain portion of the Request-URI. 484 The element inside the element has 2 boolean 485 parameter: TLS and S/MIME. When in TLS parameter is set to "true" 486 (thus implying the use of SIPS URI scheme, if SIP is used as the 487 signaling protocol), it is required that TLS is used end-to-end. In 488 other words, TLS must be used also on the last hop between the entity 489 responsible for the domain portion of the Request-URI and the 490 conference policy server. 492 If end-to-end confidentiality of entire SIP messages is not required 493 by the conference policy, but it is required that the message bodies 494 within SIP are encrypted, the S/MIME attribute must have a value 495 "true". 497 TLS and S/MIME may be required independent of each other. In other 498 words, it may be required to use neither, one, or both depending on 499 the settings of these parameters. 501 The conference creator can define an authentication policy for the 502 participants. This is done with the optional element. 504 If the element is present, then at least one 505 inside the element must be present, each 506 identifies a user or a set of users for which the authentication 507 mechanism apply. The target URI can be wildcarded as described for 508 the ACL in Section 4.2.4. 510 The authentication policy defined in the optional 511 element defines how the participants should 512 be authenticated. Two authentication mechanisms are defined in this 513 document: Digest and Digest-AKA. The authentication policy can also 514 be set to none. The password associated with each user in the Digest 515 authentication is included in the optional attribute. This 516 attribute is ignored if authentication is set to "none". 518 4.2.8 element 520 This element has its own XML namespace. The absence of this namespace 521 and its elements from an XML document indicates that the conference 522 does not have a floor. 524 The is mandatory and contains the required 525 boolean attribute that indicates if the floor is moderator controlled 526 or not. One or more elements can appear in the 527 element. The number of those elements 528 indicates how many floors the conference can have. A floor can be 529 used for one or more media types; the mandatory element 530 can contain zero or more of the