idnits 2.17.1 draft-ietf-xcon-conference-policy-privileges-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 824. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 814. ** 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 are 21 instances of too long lines in the document, the longest one being 159 characters in excess of 72. ** There are 57 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 225 has weird spacing: '...ined in the c...' == Line 333 has weird spacing: '...allowed to mo...' == Line 343 has weird spacing: '...allowed to mo...' == Line 353 has weird spacing: '...allowed to mo...' == Line 363 has weird spacing: '...allowed to mo...' == (14 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 (October 12, 2004) is 7136 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: '9' is defined on line 745, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 749, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 754, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 758, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 768, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 771, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 3023 (ref. '5') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 2141 (ref. '6') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '7') -- No information found for draft-ietf-xcon-cpcp-req - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' == 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. '13') ** Obsolete normative reference: RFC 2617 (ref. '14') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (ref. '15') (Obsoleted by RFC 9110) Summary: 13 errors (**), 0 flaws (~~), 18 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 XCON H. Khartabil 2 Internet-Draft A. Niemi 3 Expires: April 12, 2005 Nokia 4 October 12, 2004 6 Privileges for Manipulating a Conference Policy 7 draft-ietf-xcon-conference-policy-privileges-01 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 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 21 Internet-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 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 12, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 The Conference Policy is defined as the complete set of rules for a 43 particular conference manipulated by the conference policy server. 44 The Conferece Policy Control Protocol (CPCP) is the protocol used by 45 client to manipulate the conference policy. This document specifies 46 an Extensible Markup Language (XML) Schema that enumerates the 47 conference policy meta data that enable a user to assign privileges 48 to users that enables them to read and/or manipulate parts of or the 49 entire conference policy. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Structure of a Conference Policy Privileges XML Document . . . 4 57 4.1 MIME Type for CPCP XML Document . . . . . . . . . . . . . 4 58 4.2 Privileges Root . . . . . . . . . . . . . . . . . . . . . 5 59 4.3 XML Document Description . . . . . . . . . . . . . . . . . 5 60 4.3.1 Conference Policy Privileges . . . . . . . . . . . . . 5 61 4.3.1.1 Conditions . . . . . . . . . . . . . . . . . . . . 6 62 4.3.1.1.1 Validity . . . . . . . . . . . . . . . . . . . 6 63 4.3.1.1.2 Identity . . . . . . . . . . . . . . . . . . . 7 64 4.3.1.1.2.1 Interpreting the Element . . . . . . 8 65 4.3.1.1.3 Conference Policy Identity . . . . . . . . . . 8 66 4.3.1.1.3.1 Matching Any Identity . . . . . . . . . . 8 67 4.3.1.1.3.2 Matching Identities in External Lists . . 8 68 4.3.1.1.4 Sphere . . . . . . . . . . . . . . . . . . . . 8 69 4.3.1.2 Actions . . . . . . . . . . . . . . . . . . . . . 8 70 4.3.1.2.1 Modifying Conference setting . . . . . . . . . 8 71 4.3.1.2.2 Modifying Conference Information . . . . . . . 9 72 4.3.1.2.3 Modifying Conference Time . . . . . . . . . . 9 73 4.3.1.2.4 Modifying Authorization rules . . . . . . . . 9 74 4.3.1.2.5 Modifying Conference Dial-out List . . . . . . 9 75 4.3.1.2.6 Modifying Conference Refer List . . . . . . . 9 76 4.3.1.2.7 Modifying Conference media streams . . . . . . 10 77 4.3.1.2.8 Creating Sidebars . . . . . . . . . . . . . . 10 78 4.3.1.2.9 Modifying Conference Dial-in List . . . . . . 10 79 4.3.1.2.10 Reading Conference setting . . . . . . . . . . 10 80 4.3.1.2.11 Reading Conference Information . . . . . . . . 11 81 4.3.1.2.12 Reading Conference Time . . . . . . . . . . . 11 82 4.3.1.2.13 Reading Authorization rules . . . . . . . . . 11 83 4.3.1.2.14 Reading Conference Dial-out List . . . . . . . 11 84 4.3.1.2.15 REading Conference Refer List . . . . . . . . 11 85 4.3.1.2.16 Reading Conference media streams 86 Information . . . . . . . . . . . . . . . . . 12 87 4.3.1.2.17 Reading Sidebar Information . . . . . . . . . 12 88 4.3.1.2.18 Reading Conference Dial-in List . . . . . . . 12 89 4.3.1.3 Transformations . . . . . . . . . . . . . . . . . 12 90 4.4 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 12 91 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 5.1 A Simple Conference Policy Privileges Document . . . . . . 14 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 95 7.1 application/privileges+xml MIME TYPE . . . . . . . . . . . 15 96 7.2 URN Sub-Namespace Registration for 97 urn:ietf:params:xml:ns:privileges . . . . . . . . . . . . 16 98 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 99 9. Normative References . . . . . . . . . . . . . . . . . . . . . 17 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 101 Intellectual Property and Copyright Statements . . . . . . . . 19 103 1. Introduction 105 The Conference Policy Control Protocol (CPCP) [1]specifies an 106 Extensible Markup Language (XML) Schema that enumerates the 107 conference policy data elements that enable a user to define a 108 conference policy. It, however, does not define user privileges (who 109 is allowed to read or modify certain parts or all of a conference 110 policy). 112 In many cases, the creator of the conference policy is the sole user 113 with access rights to the conference policy and other users do not 114 have any rights to view nor modify the document. However, there is a 115 need for different privileges to exist where users can modify certain 116 parts of the conference policy XML document. This document specifies 117 an Extensible Markup Language (XML) Schema that enumerates the 118 conference policy meta data that enable such privileges to exist. 120 2. Conventions Used in This Document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [3]. 126 3. Terminology 128 This document uses terminology from [13]. Some additional 129 definitions are introduced in [1], including the defintion of a 130 privileged user. 132 4. Structure of a Conference Policy Privileges XML Document 134 The conference policy privileges document is an XML [4] document that 135 MUST be well-formed and MUST be valid according to schemas, including 136 extension schemas, available to the validater and applicable to the 137 XML document. The Conference policy privelges documents MUST be 138 based on XML 1.0 and MUST be encoded using UTF-8. This specification 139 makes use of XML namespaces for identifying conference policy 140 privileges documents and document fragments. The namespace URI for 141 elements defined by this specification is a URN [6], using the 142 namespace identifier 'ietf' defined by [7] and extended by [8]. This 143 URN is: 145 urn:ietf:params:xml:ns:privileges 147 4.1 MIME Type for CPCP XML Document 149 The MIME type for the CPCP XML document is 150 "application/privileges+xml". 152 4.2 Privileges Root 154 A conference policy privileges document begins with the root element 155 tag . Other elements from different namespaces MAY be 156 present for the purposes of extensibility. Elements or attributes 157 from unknown namespaces MUST be ignored. 159 A user may create a new conference policy privieleges at the CPS by 160 placing a new conference policy document at the CPS. Depending on 161 server policy and user privileges, the CPS may accept the creation. 162 Only the creator of the conference can create a conference policy 163 privileges document for that conference policy. 165 A conference that exists without a conference policy privileges 166 document allows all privileges to the creator of the conference 167 policy only. A conference policy privielges document can be deleted 168 permanently by removing the conference policy document from the CPS. 169 When the user deletes a conference policy document, the user SHOULD 170 also delete the conference policy privielges document associated with 171 the deleted conference. A CPS may apply local policy in determining 172 when and if to delete the conference policy privielges document if it 173 has not been removed after a the conference policy document was 174 deleted. 176 4.3 XML Document Description 178 4.3.1 Conference Policy Privileges 180 One of the key components of the conference policy privileges 181 document is the set of authorization rules that specify who is 182 allowed to read and manipulate a conference policy. The unordered 183 list of authorization rules together define the conference policy 184 privileges in the form of an authorization policy. 186 The element appears after the root element and contains the URI 187 of the conference policy document that the privileges defines within 188 it apply to. This is followed by the element which carry 189 the rules defining the actual privileges. 191 The conference policy privileges are enclosed in the 192 element are formatted according to the XML schema defined in the 193 common policy framework [2]. In the element, there can be 194 multiple rules, each rule is represented by the element, each 195 of which consist of three parts: conditions, actions and 196 transformations. Conditions determine whether a particular rule 197 applies to a request. Each action or transformation in the applied 198 rule is a positive grant of permission to the conference policy user. 199 The details of each specific element and attribute is described in 200 [2]. 202 Asking the conference policy server to allow certain users to 203 manipulate the conference policy is achieved by modifying an existing 204 authorization rule or creating a new one. 206 If the conference is long-lasting, it is possible that new rules are 207 added all the time but old rules are almost never removed (some of 208 them are overwritten, though). This leads easily to the situation 209 that the conference policy meta data contains many unnecessary rules 210 which are not really needed anymore. Therefore, there is a need to 211 delete rules. This can be achieved by removing that portion of the 212 policy. 214 Conflicting rules may exist (for example, both allowed and blocked 215 action is defined for same target). The common policy directives [2] 216 dictate the behaviour in such situations. 218 This section outlines the new conditions, actions and transformations 219 for conference policy privileges. 221 4.3.1.1 Conditions 223 4.3.1.1.1 Validity 225 The element, as defined in the common policy framework 226 [2], expresses the rule validity period by two attributes, a starting 227 and a ending time. Times are expressed in XML dateTime format. 228 Expressing the lifetime of a rule implements a garbage collection 229 mechanism. A rule maker might not have always access to the 230 conference policy server to remove some rules which grant 231 permissions. Hence this mechanisms allows to remove or invalidate 232 granted permissions automatically without further interaction between 233 the rule maker and the conference policy server. 235 To give a real life example, there are often meetings where users can 236 have access to modify the dial-out list from 10 minutes before the 237 conference starts until 10 mintues after the conference starts. One 238 rules can be set in this scenario. The following example demostrates 239 this. The meeting starts at 9:30 and ends at 12:30. A manager with 240 identity "manager@example.com" can read and modify the dial-out list 241 betweem 8:50 and 9:40. After that time until the conference ends, 242 the manager can only read the dial-out-list 243 244 245 246 2004-12-17T08:50:00-05:00 247 2004-12-17T09:40:00-05:00 248 249 250 manager@example.com 251 252 253 254 allow 255 256 257 258 259 260 261 manager@example.com 262 263 264 265 allow 266 267 268 269 ... 270 279 4.3.1.1.2 Identity 281 The element is already defined in the common policy 282 framework [2]The presence of the element is a condition 283 requires any identity within it to be authenticated before a rule is 284 applied to it. This includes the element (Section 4.3.1.1.2.1), 285 the element (Section 4.3.1.1.3.1), the element 286 (Section 4.3.1.1.3.2), their exceptions, and any future extension 287 that carries an identity. The absence of the element with 288 in a condition indicated that the rule applies to all unauthenticated 289 identities. That is participants that have provided no authenticated 290 identity to the conference focus. 292 4.3.1.1.2.1 Interpreting the Element 294 As earlier indicated, the element is already defined in 295 the common policy framework [2]. However, the rules for interpreting 296 the identities in elements are left for each application to 297 define separately. This document, however, does not define the rules 298 for interpreting identities in elements in conferencing 299 applications since those interpretation rules are signalling protocol 300 specific. 302 OPEN ISSUE: Do we need to state more than this? How are identities 303 derived from users that join using POTS, H.323, etc.? 305 4.3.1.1.3 Conference Policy Identity 307 4.3.1.1.3.1 Matching Any Identity 309 The element is used to match any participant. This allows a 310 conference priveleges to be open to any authenticated user. Just as 311 for the element in element, The element 312 contains a list of elements and allows to implement a simple 313 blacklist mechanism. The element contains the identity. It 314 differs from the element in that the domain part is needed 315 in the identity since it has not domain to refer to. 317 4.3.1.1.3.2 Matching Identities in External Lists 319 The element can be used to match those participants 320 that are part of a resource list that is created externally. The use 321 of is similar to that defined in Section x of [1]. 323 4.3.1.1.4 Sphere 325 The element has no meaning in the context of conference 326 policy and MUST be ignored if present. 328 4.3.1.2 Actions 330 4.3.1.2.1 Modifying Conference setting 332 The element represents a boolean action. If 333 set to TRUE, the identity is allowed to modify the conference 334 settings in the conference policy. If set to FALSE, any 335 modifications to the conference settings are rejected. 337 If this element is undefined it has a value of FALSE, causing the 338 modifications to be rejected. 340 4.3.1.2.2 Modifying Conference Information 342 The element represents a boolean action. 343 If set to TRUE, the identity is allowed to modify the conference 344 information in the conference policy. If set to FALSE, any 345 modifications to the conference information are rejected. 347 If this element is undefined it has a value of FALSE, causing the 348 modifications to be rejected. 350 4.3.1.2.3 Modifying Conference Time 352 The element represents a boolean action. If set 353 to TRUE, the identity is allowed to modify the conference time in 354 the conference policy. If set to FALSE, any modifications to the 355 conference time are rejected. 357 If this element is undefined it has a value of FALSE, causing the 358 modifications to be rejected. 360 4.3.1.2.4 Modifying Authorization rules 362 The element represents a boolean 363 action. If set to TRUE, the identity is allowed to modify the 364 authorization rules of a conference in the conference policy. If set 365 to FALSE, any modifications to the rules are rejected. 367 If this element is undefined it has a value of FALSE, causing the 368 modifications to be rejected. 370 4.3.1.2.5 Modifying Conference Dial-out List 372 The element represents a boolean action. If set 373 to TRUE, the identity is allowed to modify the conference dial-out 374 list in the conference policy. If set to FALSE, any modifications to 375 the dial-out list are rejected. 377 If this element is undefined it has a value of FALSE, causing the 378 modifications to be rejected. 380 4.3.1.2.6 Modifying Conference Refer List 382 The element represents a boolean action. If set to 383 TRUE, the identity is allowed to modify the conference refer list in 384 the conference policy. If set to FALSE, any modifications to the 385 refer list are rejected. 387 If this element is undefined it has a value of FALSE, causing the 388 modifications to be rejected. 390 4.3.1.2.7 Modifying Conference media streams 392 The element represents a boolean action. If set to 393 TRUE, the identity is allowed to modify the conference media streams 394 in the conference policy. If set to FALSE, any modifications to the 395 media streams are rejected. 397 If this element is undefined it has a value of FALSE, causing the 398 modifications to be rejected. 400 4.3.1.2.8 Creating Sidebars 402 The element represents a boolean action. If 403 set to TRUE, the identity is allowed to create and manipulate a 404 sidebar by creating and modifying a element in a conference 405 policy. If set to FALSE, any sidebar creation and manipulation is 406 rejected. 408 If this element is undefined it has a value of FALSE, causing the 409 modifications to be rejected. 411 4.3.1.2.9 Modifying Conference Dial-in List 413 The conference dial-in list is virtual and is not represented by a 414 physical list in the conference policy. It is rather a collection of 415 authorization rules that allow users to join a conference. The 416 element represents a boolean action. If set to 417 TRUE, the identity is allowed to create an authorization rule in the 418 conference policy that give a user a join handling of "allow". If 419 set to FALSE, any modifications to authorization rules are rejected. 421 If this element is undefined it has a value of FALSE, causing the 422 modifications to be rejected. 424 4.3.1.2.10 Reading Conference setting 426 The element represents a boolean action. If 427 set to TRUE, the identity is allowed to read the conference settings 428 in the conference policy. If set to FALSE, any attempts to read the 429 conference settings are rejected. 431 If this element is undefined it has a value of FALSE, causing the 432 read requests to be rejected. 434 4.3.1.2.11 Reading Conference Information 436 The element represents a boolean action. If 437 set to TRUE, the identity is allowed to read the conference 438 information in the conference policy. If set to FALSE, any attempts 439 to read the conference information are rejected. 441 If this element is undefined it has a value of FALSE, causing the 442 read requests to be rejected. 444 4.3.1.2.12 Reading Conference Time 446 The element represents a boolean action. If set to 447 TRUE, the identity is allowed to read the conference time in the 448 conference policy. If set to FALSE, any attempts to read the 449 conference time are rejected. 451 If this element is undefined it has a value of FALSE, causing the 452 read requests to be rejected. 454 4.3.1.2.13 Reading Authorization rules 456 The element represents a boolean 457 action. If set to TRUE, the identity is allowed to read the 458 authorization rules of a conference in the conference policy. If set 459 to FALSE, any attempts to read the rules are rejected. 461 If this element is undefined it has a value of FALSE, causing the 462 read requests to be rejected. 464 4.3.1.2.14 Reading Conference Dial-out List 466 The element represents a boolean action. If set to 467 TRUE, the identity is allowed to read the conference dial-out list 468 in the conference policy. If set to FALSE, any attempts to read the 469 dial-out list are rejected. 471 If this element is undefined it has a value of FALSE, causing the 472 read requests to be rejected. 474 4.3.1.2.15 REading Conference Refer List 476 The element represents a boolean action. If set to 477 TRUE, the identity is allowed to read the conference refer list in 478 the conference policy. If set to FALSE, any attempts to read the 479 refer list are rejected. 481 If this element is undefined it has a value of FALSE, causing the 482 read requests to be rejected. 484 4.3.1.2.16 Reading Conference media streams Information 486 The element represents a boolean action. If set to 487 TRUE, the identity is allowed to read the conference media streams 488 information in the conference policy. If set to FALSE, any attempts 489 to read the media streams information are rejected. 491 If this element is undefined it has a value of FALSE, causing the 492 read requests to be rejected. 494 4.3.1.2.17 Reading Sidebar Information 496 The element represents a boolean action. If set 497 to TRUE, the identity is allowed to read side bar inforation in the 498 conference policy, indicating how many sidebars are currently in a 499 conference. If set to FALSE, any attempts to read sidebar 500 information is rejected. 502 If this element is undefined it has a value of FALSE, causing the 503 modifications to be rejected. 505 4.3.1.2.18 Reading Conference Dial-in List 507 The Dial-in List is defined in Section 4.3.1.2.9. If set to TRUE, 508 the identity is allowed to read authorizations rule in the 509 conference policy that give a user a join handling of "allow". If 510 set to FALSE, any attempts to read such rules are rejected. 512 If this element is undefined it has a value of FALSE, causing the 513 read requests to be rejected. 515 4.3.1.3 Transformations 517 No transformations are defined at this time. 519 4.4 XML Schema 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 543 544 545 546 547 548 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 574 5. Examples 575 5.1 A Simple Conference Policy Privileges Document 577 The following document dictates that Bob and Alice are allowed to 578 read and modify the conference settings at 579 "http://xcap.example.com/services/conferences/users/Alice/conference. 580 xml" why John can only read the dial-out list. 582 583 585 http://xcap.example.com/services/conferences/users/Alice/conference.xml" 586 587 588 589 590 bob@example.com 591 alice@example.com 592 593 594 595 true 596 true 597 598 599 600 601 602 603 john@example.com 604 605 606 607 true 608 609 610 611 612 614 6. Security Considerations 616 A conference policy privileges document may contain information that 617 is highly sensitive. Its delivery to the conference server needs to 618 happen strictly, paying special attention to integrity and 619 confidentiality. Reading the document is also a security concern 620 since the conference policy proviliges document contains sensitive 621 information like who is allowed to modify certain parts of a 622 conference policy document. 624 A milicious user can manipulate parts of the conference policy 625 privileges document giving themselves and others privileges to 626 manipulate the conference policy, including the dial-out list and the 627 ruleset. Those authorization rules carry the privileges that certain 628 identities have. If an unauthorized user gets access to this 629 document (pretending to be someone else), s/he can manipulate those 630 rules giving himself and other unauthorized users access to the 631 conference policy. Some of the things that a malicious user can do 632 include: denying users certain privileges, removing rules for certain 633 identities and giving privileges to other malicious users. 634 Therefore, it is very important that only authorized clients are able 635 to manipulate the conference policy privileges document. Any 636 conference policy privileges document transport protocol MUST provide 637 authentication, confidentiality and integrity. 639 7. IANA Considerations 641 7.1 application/privileges+xml MIME TYPE 643 MIME media type: application 645 MIME subtype name: privileges+xml 647 Mandatory parameters: none 649 Optional parameters: Same as charset parameter application/xml as 650 specified in RFC 3023 [5]. 652 Encoding considerations: Same as encoding considerations of 653 application/xml as specified in RFC 3023 [5]. 655 Security considerations: See section 10 of RFC 3023 [5] and section 656 Section 7 of this document. 658 Interoperability considerations: none. 660 Published specification: This document. 662 Applications which use this media type: This document type has been 663 used to support conference policy manipulation for SIP based 664 conferencing. 666 Additional information: 668 Magic number: None 670 File extension: .cl or .xml 672 Macintosh file type code: "TEXT" 674 Personal and email address for further information: Hisham Khartabil 675 (hisham.khartabil@nokia.com) 677 Intended Usage: COMMON 679 Author/change controller: The IETF 681 7.2 URN Sub-Namespace Registration for 682 urn:ietf:params:xml:ns:privileges 684 This section registers a new XML namespace, as per guidelines in URN 685 document [8]. 687 URI: The URI for this namespace is urn:ietf:params:xml:ns:privileges. 689 Registrant Contact: IETF, XCON working group, Hisham Khartabil 690 (hisham.khartabil@nokia.com) 692 XML: 694 BEGIN 695 696 698 699 700 702 Conference Policy Namespace 703 704 705

Namespace for Conference Policy

706

application/conference-policy+xml

707

See RFCXXXX.

708 709 710 END 712 8. Acknowledgements 714 The authors would like to thank Hannes Tschofenig, Aki Niemi, Alan 715 Johnston, and the IETF XCON working group for their feedback and 716 suggestions. 718 9 Normative References 720 [1] Khartabil, H., Koskelainen, P. and A. Niemi, "The Conference 721 Policy Control Protocol (CPCP)", Internet-Draft 722 I-D.draft-ietf-xcon-cpcp, September 2004. 724 [2] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J. and J. 725 Rosenberg, "Common Policy", Internet-Draft 726 I-D.ietf-geopriv-common-policy, February 2004. 728 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 729 Levels", RFC 2119, BCD 14, March 1997. 731 [4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 732 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 733 REC REC-xml-20001006, October 2000. 735 [5] Murata, M., Laurent, S. and D. Kohn, "XML Media Types", RFC 736 3023, January 2001. 738 [6] Moats, R., "URN Syntax", RFC 2141, May 1997. 740 [7] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 741 August 1999. 743 [8] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. 745 [9] Koskelainen, P. and H. Khartabil, "Requirements for conference 746 policy control protocol", draft-ietf-xcon-cpcp-req-01 (work in 747 progress), January 2004. 749 [10] Johnston, A. and O. Levin, "Session Initiation Protocol Call 750 Control - Conferencing for User Agents", 751 draft-ietf-sipping-cc-conferencing-03 (work in progress), 752 February 2004. 754 [11] Rosenberg, J., "The Extensible Markup Language (XML) 755 Configuration Access Protocol (XCAP)", 756 draft-ietf-simple-xcap-02 (work in progress), February 2004. 758 [12] Rosenberg, J., "An Extensible Markup Language (XML) 759 Configuration Access Protocol (XCAP) Usage for Presence Lists", 760 draft-ietf-simple-xcap-list-usage-02 (work in progress), 761 February 2004. 763 [13] Rosenberg, J., "A Framework for Conferencing with the Session 764 Initiation Protocol", 765 draft-ietf-sipping-conferencing-framework-01 (work in 766 progress), October 2003. 768 [14] Franks, J., "HTTP Authentication: Basic and Digest Access 769 Authentication", RFC 2617, June 1999. 771 [15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 773 Authors' Addresses 775 Hisham Khartabil 776 Nokia 777 P.O. Box 321 778 Helsinki FIN-00045 779 Finland 781 EMail: hisham.khartabil@nokia.com 783 Aki Niemi 784 Nokia 785 P.O. Box 100 786 NOKIA GROUP, FIN 00045 787 Finland 789 Phone: +358 50 389 1644 790 EMail: aki.niemi@nokia.com 792 Intellectual Property Statement 794 The IETF takes no position regarding the validity or scope of any 795 Intellectual Property Rights or other rights that might be claimed to 796 pertain to the implementation or use of the technology described in 797 this document or the extent to which any license under such rights 798 might or might not be available; nor does it represent that it has 799 made any independent effort to identify any such rights. Information 800 on the procedures with respect to rights in RFC documents can be 801 found in BCP 78 and BCP 79. 803 Copies of IPR disclosures made to the IETF Secretariat and any 804 assurances of licenses to be made available, or the result of an 805 attempt made to obtain a general license or permission for the use of 806 such proprietary rights by implementers or users of this 807 specification can be obtained from the IETF on-line IPR repository at 808 http://www.ietf.org/ipr. 810 The IETF invites any interested party to bring to its attention any 811 copyrights, patents or patent applications, or other proprietary 812 rights that may cover technology that may be required to implement 813 this standard. Please address the information to the IETF at 814 ietf-ipr@ietf.org. 816 Disclaimer of Validity 818 This document and the information contained herein are provided on an 819 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 820 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 821 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 822 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 823 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 824 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 826 Copyright Statement 828 Copyright (C) The Internet Society (2004). This document is subject 829 to the rights, licenses and restrictions contained in BCP 78, and 830 except as set forth therein, the authors retain all their rights. 832 Acknowledgment 834 Funding for the RFC Editor function is currently provided by the 835 Internet Society.