idnits 2.17.1 draft-ietf-xcon-cpcp-xcap-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 462. ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 18 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 == Line 364 has weird spacing: '...cuments and t...' -- 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 (October 12, 2004) is 7128 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: Normative reference to a draft: ref. '1' -- Possible downref: Normative reference to a draft: ref. '2' -- No information found for draft-ietf-xcon-cpcp-req - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-07) exists of draft-ietf-sipping-cc-conferencing-03 == 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 (-05) exists of draft-ietf-sipping-conferencing-framework-01 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-conferencing-framework (ref. '8') ** Obsolete normative reference: RFC 2617 (ref. '9') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (ref. '10') (Obsoleted by RFC 9110) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 XCON H. Khartabil 2 Internet-Draft Nokia 3 Expires: April 12, 2005 October 12, 2004 5 An Extensible Markup Language (XML) Configuration Access Protocol 6 (XCAP) Usages for Conference Policy Manipulation and Conference 7 Policy Privelges Manipulation 8 draft-ietf-xcon-cpcp-xcap-03 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 12, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 The Conference Policy is defined as the complete set of rules for a 44 particular conference manipulated by the conference policy server. 45 The Conferece Policy Control Protocol (CPCP) is the protocol used by 46 client to manipulate the conference policy. This document defines an 47 XML Configuration Access Protocol (XCAP) application usage that may 48 be used to store and manipulate a conference policy. 50 There also exists an Extensible Markup Language (XML) Schema that 51 enumerates the conference policy meta data that enable a user to 52 assign privileges to users that enables them to read and/or 53 manipulate parts of or the entirety of a conference policy. This 54 document defines an XML Configuration Access Protocol (XCAP) 55 application usage that may be used to store and manipulate a 56 conference policy priveleges XML document. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. An XCAP Usage for Conference Policy Manipulation . . . . . . . 4 64 4.1 Application Unique ID . . . . . . . . . . . . . . . . . . 4 65 4.2 Resource Interdependencies . . . . . . . . . . . . . . . . 4 66 4.3 Additional Constraints . . . . . . . . . . . . . . . . . . 4 67 4.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . 4 68 4.5 Authorization Policies . . . . . . . . . . . . . . . . . . 4 69 4.6 MIME Type for CPCP XML Document . . . . . . . . . . . . . 4 70 5. An XCAP Usage for Conference Policy Privileges Manipulation . 5 71 5.1 Application Unique ID . . . . . . . . . . . . . . . . . . 5 72 5.2 Resource Interdependencies . . . . . . . . . . . . . . . . 5 73 5.3 Additional Constraints . . . . . . . . . . . . . . . . . . 5 74 5.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . 5 75 5.5 Authorization Policies . . . . . . . . . . . . . . . . . . 5 76 5.6 MIME Type for CPCP XML Document . . . . . . . . . . . . . 5 77 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 6.1 Conference Policy Manipulation . . . . . . . . . . . . . . 5 79 6.1.1 Creating a Conference . . . . . . . . . . . . . . . . 5 80 6.1.2 Expelling a User . . . . . . . . . . . . . . . . . . . 6 81 6.1.3 Allowing An Expelled Participant To Join Again . . . . 6 82 6.1.4 Allowing Sarah to Refer Users . . . . . . . . . . . . 7 83 6.1.5 Removing A Conference . . . . . . . . . . . . . . . . 7 84 6.2 Conference Policy Privileges Manipulation . . . . . . . . 8 85 6.2.1 Creating Conference Policy Privilegtes . . . . . . . . 8 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 88 8.1 XCAP Application Usage IDs . . . . . . . . . . . . . . . . 9 89 8.1.1 conference-policies . . . . . . . . . . . . . . . . . 9 90 8.1.2 conference-policy-privielges . . . . . . . . . . . . . 9 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 92 10. Normative References . . . . . . . . . . . . . . . . . . . . 9 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 94 Intellectual Property and Copyright Statements . . . . . . . . 11 96 1. Introduction 98 The SIP conferencing framework [8] defines the mechanisms for 99 multi-party centralized conferencing in a SIP environment. 101 Existing SIP mechanisms allow users, for example, to join and leave a 102 conference, as described in [5]. A centralised server, called focus, 103 can expel and invite users, and may have proprietary access control 104 lists and user privilege definitions. The Conference Policy Control 105 Protocol [1] defines an XML Schema that enumerates the conference 106 policy data elements that enable a user to define a conference 107 policy. This policy document may be given to a focus using a number 108 of transports. Mechanisms such as a web page or a voice response 109 system can also be used to manipulate conference policy data. 111 Similarily, Privileges for Manipulating a Conference Policy [2] 112 defines an Extensible Markup Language (XML) Schema that enumerates 113 the conference policy meta data that enable a user to assign 114 privileges to users that enables them to read and/or manipulate a 115 conference policy. Mechanims are also needed to manipulate such 116 data. 118 In many cases it is useful to have standardised means to manipulate 119 conference policy elements and conference policy privileges elements. 120 Two XML Configuration Access Protocol (XCAP) [6] application usages 121 are defined that allow for the real-time manipulation of conference 122 policy and conference policy privileges and meets the requirements in 123 [4] to store and manipulate a conference policy object and a 124 conference policy privileges object. 126 XCAP has many advantages in its use for conference policy control 127 protocol. It is a HTTP 1.1 based protocol that allows clients to 128 read, write, modify and delete application data stored in XML format 129 at a server. XCAP maps XML document elements and attributes to HTTP 130 URIs that can be directly accessed by HTTP. One application area 131 which has already adopted XCAP is the manipulation of event lists 132 [7]. 134 For manipulation of the Conference Policy XML object, the system MAY 135 support the XCAP usage defined in Section 4. For manipulation of the 136 Conference Policy Privileges XML object, the system MAY support the 137 XCAP usage defined in Section 5. 139 2. Conventions Used in This Document 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [3]. 145 3. Terminology 147 This document uses terminology from [8]. Some additional definitions 148 are introduced in [1]. 150 4. An XCAP Usage for Conference Policy Manipulation 152 4.1 Application Unique ID 154 XCAP requires application usages to define a unique application usage 155 ID (AUID) in either the IETF tree or a vendor tree. This 156 specification defines the "conference-policies" AUID within the IETF 157 tree, via the IANA registration in Section 8. 159 4.2 Resource Interdependencies 161 The conference policy server MAY fill the conference URI(s), but the 162 client MUST propose a conference URI. If the CPS does not allow 163 assignments of URIs by the client, it rejects the request with a 164 "409" response and SHOULD include a body in the response detailing 165 the error. XCAP Base document [6] section 7.2.1 explains how such a 166 response body is constructed. The CPS MAY assign multiple conference 167 URIs to a conference, one for each call signaling protocol that it 168 supports. Section xx of [1] (Conference Settings) discusses this is 169 more detail. 171 Sidebar URIs are subject to the same behaviour. 173 4.3 Additional Constraints 175 These are defined within the XML structure definition in [1]. 177 4.4 Naming Conventions 179 There are no naming conventions that need to be defined for this 180 application usage. 182 4.5 Authorization Policies 184 A server can allow privileged users to modify documents that they 185 don't own. The establishment and indication of such policies is done 186 by setting the authorization rules as described in [2]. 188 4.6 MIME Type for CPCP XML Document 190 The MIME type for the CPCP XML document is defined in [1]. 192 5. An XCAP Usage for Conference Policy Privileges Manipulation 194 5.1 Application Unique ID 196 XCAP requires application usages to define a unique application usage 197 ID (AUID) in either the IETF tree or a vendor tree. This 198 specification defines the "conference-policy-privileges" AUID within 199 the IETF tree, via the IANA registration in Section 8. 201 5.2 Resource Interdependencies 203 There are no resource interdependencies that need to be defined fo 204 this application usage. 206 5.3 Additional Constraints 208 These are defined within the XML structure definition in [2]. 210 5.4 Naming Conventions 212 The "filename" as defined in XCAP Base document [6] is used to 213 describe the final path segment in the document selector. This XCAP 214 usage requires that the filename of the conference policy privileges 215 be exactly the same as the filename given to the conference policy 216 that it relates to. This will save processing time in that the focus 217 does not need to search all conference privileges documents looking 218 for the right one. This also eliminates any conflicts that may occur 219 by disallowing more than one conference policy privileges document to 220 exist for a single conference policy. 222 5.5 Authorization Policies 224 This application usage does not modify the default XCAP authorization 225 policy, which is that only a user can read, write or modify their own 226 documents. 228 5.6 MIME Type for CPCP XML Document 230 The MIME type for the Conference Policy Privileges XML document is 231 defined in [2] 233 6. Examples 235 6.1 Conference Policy Manipulation 237 6.1.1 Creating a Conference 239 Continuing with the example in Section xx of [1], Alice's client uses 240 XCAP to transport the conference policy to the conference policy 241 server 243 PUT 244 http://xcap.example.com/services/conference-policies/users/Alice/c 245 onference.xml HTTP/1.1 246 Content-Type: application/conference-policy+xml 248 [conference policy from [1] example goes here]. 250 At exactly 2004-12-17T09:30:00-05:00, the focus sends SIP INVITE 251 request to Alice and a SIP REFER request to Sarah. At 252 2004-12-17T09:25:00-05:00, SIP INVITE requests can be accepted from 253 anyone at domain example.com. Any attempts to join the conference by 254 users in other domains are rejected. 256 6.1.2 Expelling a User 258 After the conference has started, Alice decides to expel Bob who has 259 joined the conference. So she modifies the authorization rule that 260 allows everyone at example.com to join: 262 PUT 263 http://xcap.example.com/services/conference-policies/users/Alice/c 264 onference.xml/~~/conference/authorization-rules/rule[@id=""]/condi 265 tions/identity/ HTTP/1.1 266 Content-Type:text/plain 268 269 example.com 270 bob@example.com 271 273 At this point, the focus sends a SIP BYE request to Bob ending Bob's 274 participation in the conference. This also guarantees that Bob 275 cannot rejoin the conference since he is explicitly blocked. Any 276 attempt Bob makes in rejoining the conference will fail. 278 6.1.3 Allowing An Expelled Participant To Join Again 280 Continuing with the example above, Alice now decides to allow Bob to 281 join again after a period of time. She does so by rewriting parts of 282 the rule that blocks him from joining. 284 PUT 285 http://xcap.example.com/services/conference-policies/users/Alice/c 286 onference.xml/~~/conference/authorization-rules/rule[@id=""]/condi 287 tions/identity/ HTTP/1.1 288 Content-Type:text/plain 290 291 example.com 292 294 Bob can now rejoin the conference by sending a SIP INVITE request. 296 6.1.4 Allowing Sarah to Refer Users 298 Alice now decides that Sarah can ask the focus to refer users to the 299 conference: 301 PUT 302 http://xcap.example.com/services/conference-policies/users/Alice/c 303 onference.xml/~~/conference/authorization-rules/rule[@id="3"] 304 HTTP/1.1 305 Content-Type:text/plain 307 308 309 310 sarah@example.com 311 312 313 314 true 315 316 317 319 6.1.5 Removing A Conference 321 Alice now decides she no longer wants this conference to exist and 322 therefore deletes the conference: 324 DELETE 325 http://xcap.example.com/services/conference-policies/users/Alice/c 326 onference.xml 328 As a result of this action, the focus sends SIP BYE requests to all 329 current participants in the conference. The conference server 330 terminates the focus thereafter. 332 6.2 Conference Policy Privileges Manipulation 334 6.2.1 Creating Conference Policy Privilegtes 336 Continuing with the example in Section xx of [2], Alice's client uses 337 XCAP to transport the conference policy privileges to the conference 338 policy server 340 PUT 341 http://xcap.example.com/services/conference-policy-privileges/user 342 s/Alice/cp-privileges.xml HTTP/1.1 343 Content-Type: application/privileges+xml 345 [conference policy privileges from [2] example goes here]. 347 7. Security Considerations 349 The information contained in conference-policies and 350 conference-policy-privileges documents are particularly sensitive. 351 The former represents critical conference information like allowed 352 user and conference time while the latter represents the list of 353 privileged people with assigned privileges. As a result, clients 354 SHOULD use TLS when contacting servers in order to fetch this 355 information. Note that this does not represent a change in 356 requirement strength from XCAP. The XCAP base specification mandates 357 that all XCAP servers MUST implement HTTP Authentication: Basic and 358 Digest Access Authentication [9]. Furthermore, XCAP servers MUST 359 implement HTTP over TLS [10]. It is recommended that administrators 360 of XCAP servers use an HTTPS URI as the XCAP root services URI, so 361 that the digest client authentication occurs over TLS. By using 362 these means, XCAP client and server can ensure the confidentiality 363 and integrity of the XCAP created conference policy and conference 364 policy privileges documents and their manipulation operations, and 365 that only authorized clients are allowed to perform them. 367 8. IANA Considerations 369 8.1 XCAP Application Usage IDs 371 8.1.1 conference-policies 373 Name of the AUID: conference-policies 374 Description: Conference policy application manipulates conference 375 policy at a server. 377 8.1.2 conference-policy-privielges 379 Name of the AUID: conference-policy-privileges 380 Description: Conference policy privileges application manipulates 381 conference policy privielges at a server. 383 9. Acknowledgements 385 The authors would like to thank Alan Johnston and the IETF XCON 386 working group for their feedback and suggestions. 388 10 Normative References 390 [1] Khartabil, H., Koskelainen, P. and A. Niemi, "The Conference 391 Policy Control Protocol (CPCP)", Internet-Draft 392 I-D.draft-ietf-xcon-cpcp, September 2004. 394 [2] Khartabil, H. and A. Niemi, "Privileges for Manipulating a 395 Conference Policy", Internet-Draft 396 I-D.draft-ietf-xcon-conference-policy-privileges, September 397 2004. 399 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 400 Levels", RFC 2119, BCD 14, March 1997. 402 [4] Koskelainen, P. and H. Khartabil, "Requirements for conference 403 policy control protocol", draft-ietf-xcon-cpcp-req-01 (work in 404 progress), January 2004. 406 [5] Johnston, A. and O. Levin, "Session Initiation Protocol Call 407 Control - Conferencing for User Agents", 408 draft-ietf-sipping-cc-conferencing-03 (work in progress), 409 February 2004. 411 [6] Rosenberg, J., "The Extensible Markup Language (XML) 412 Configuration Access Protocol (XCAP)", 413 draft-ietf-simple-xcap-02 (work in progress), February 2004. 415 [7] Rosenberg, J., "An Extensible Markup Language (XML) 416 Configuration Access Protocol (XCAP) Usage for Presence Lists", 417 draft-ietf-simple-xcap-list-usage-02 (work in progress), 418 February 2004. 420 [8] Rosenberg, J., "A Framework for Conferencing with the Session 421 Initiation Protocol", 422 draft-ietf-sipping-conferencing-framework-01 (work in 423 progress), October 2003. 425 [9] Franks, J., "HTTP Authentication: Basic and Digest Access 426 Authentication", RFC 2617, June 1999. 428 [10] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 430 Author's Address 432 Hisham Khartabil 433 Nokia 434 P.O. Box 321 435 Helsinki FIN-00045 436 Finland 438 EMail: hisham.khartabil@nokia.com 440 Intellectual Property Statement 442 The IETF takes no position regarding the validity or scope of any 443 Intellectual Property Rights or other rights that might be claimed to 444 pertain to the implementation or use of the technology described in 445 this document or the extent to which any license under such rights 446 might or might not be available; nor does it represent that it has 447 made any independent effort to identify any such rights. Information 448 on the procedures with respect to rights in RFC documents can be 449 found in BCP 78 and BCP 79. 451 Copies of IPR disclosures made to the IETF Secretariat and any 452 assurances of licenses to be made available, or the result of an 453 attempt made to obtain a general license or permission for the use of 454 such proprietary rights by implementers or users of this 455 specification can be obtained from the IETF on-line IPR repository at 456 http://www.ietf.org/ipr. 458 The IETF invites any interested party to bring to its attention any 459 copyrights, patents or patent applications, or other proprietary 460 rights that may cover technology that may be required to implement 461 this standard. Please address the information to the IETF at 462 ietf-ipr@ietf.org. 464 Disclaimer of Validity 466 This document and the information contained herein are provided on an 467 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 468 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 469 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 470 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 471 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 472 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 474 Copyright Statement 476 Copyright (C) The Internet Society (2004). This document is subject 477 to the rights, licenses and restrictions contained in BCP 78, and 478 except as set forth therein, the authors retain all their rights. 480 Acknowledgment 482 Funding for the RFC Editor function is currently provided by the 483 Internet Society.