idnits 2.17.1 draft-ietf-simple-xcap-auth-usage-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 6 instances of too long lines in the document, the longest one being 7 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 (October 27, 2003) is 7486 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: '4' is defined on line 705, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 710, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 744, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-00 -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2141 (ref. '5') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3023 (ref. '6') (Obsoleted by RFC 7303) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '7') ** Obsolete normative reference: RFC 2617 (ref. '8') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2633 (ref. '10') (Obsoleted by RFC 3851) == Outdated reference: A later version (-10) exists of draft-ietf-simple-rpid-00 == Outdated reference: A later version (-05) exists of draft-ietf-simple-xcap-list-usage-00 Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIMPLE J. Rosenberg 2 Internet-Draft dynamicsoft 3 Expires: April 26, 2004 October 27, 2003 5 Extensible Markup Language (XML) Configuration Access Protocol (XCAP) 6 Usages for Setting Presence Authorization 7 draft-ietf-simple-xcap-auth-usage-01 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on April 26, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document describes two usages of the Extensible Markup Language 38 (XML) Configuration Access Protocol (XCAP) that allow a client to 39 provide authorization decisions regarding watchers of their presence. 40 The first of these usages, called permission-statements, contains 41 statements about what permissions are to be granted to watchers of 42 presence. The second usage, called supported-permissions, allows a 43 client to determine what permissions are understood by the provider. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Structuring Presence Authorization . . . . . . . . . . . 4 49 3. Terminology . . . . . . . . . . . . . . . . . . . . . . 5 50 4. Permission Statements . . . . . . . . . . . . . . . . . 6 51 4.1 Application Unique ID . . . . . . . . . . . . . . . . . 6 52 4.2 Structure of Permission Statements . . . . . . . . . . . 6 53 4.2.1 Applying Statements to Watchers . . . . . . . . . . . . 6 54 4.2.2 Specifying Permissions . . . . . . . . . . . . . . . . . 8 55 4.2.2.1 Acceptance Permissions . . . . . . . . . . . . . . . . . 8 56 4.2.2.2 Content Permissions . . . . . . . . . . . . . . . . . . 10 57 4.2.2.2.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . 11 58 4.3 Additional Constraints . . . . . . . . . . . . . . . . . 12 59 4.4 Naming Conventions . . . . . . . . . . . . . . . . . . . 12 60 4.5 Authorization Policies . . . . . . . . . . . . . . . . . 12 61 4.6 XML Schema . . . . . . . . . . . . . . . . . . . . . . . 13 62 5. Supported Permissions . . . . . . . . . . . . . . . . . 14 63 5.1 Application Unique ID . . . . . . . . . . . . . . . . . 14 64 5.2 Structure of Supported Permissions . . . . . . . . . . . 14 65 5.3 Naming Conventions . . . . . . . . . . . . . . . . . . . 15 66 5.4 Authorization Policies . . . . . . . . . . . . . . . . . 15 67 5.5 XML Schema . . . . . . . . . . . . . . . . . . . . . . . 16 68 5.6 Example Document . . . . . . . . . . . . . . . . . . . . 16 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . 18 70 6.1 XCAP Application Usage IDs . . . . . . . . . . . . . . . 18 71 6.1.1 Permission Statements . . . . . . . . . . . . . . . . . 18 72 6.1.2 Supported Permissions . . . . . . . . . . . . . . . . . 18 73 6.2 URN Sub-Namespace Registrations . . . . . . . . . . . . 18 74 6.2.1 urn:ietf:params:xml:ns:permission-statements . . . . . . 18 75 6.2.2 urn:ietf:params:xml:ns:supported-permissions . . . . . . 19 76 6.3 XML Schema Registrations . . . . . . . . . . . . . . . . 20 77 6.3.1 Permissions Statements . . . . . . . . . . . . . . . . . 20 78 6.3.2 Supported Permissions . . . . . . . . . . . . . . . . . 20 79 Normative References . . . . . . . . . . . . . . . . . . 21 80 Informative References . . . . . . . . . . . . . . . . . 22 81 Author's Address . . . . . . . . . . . . . . . . . . . . 22 82 Intellectual Property and Copyright Statements . . . . . 23 84 1. Introduction 86 The Session Initiation Protocol (SIP) for Instant Messaging and 87 Presence (SIMPLE) specifications allow a user, called a watcher, to 88 subscribe to another user, called a presentity [13], in order to 89 learn their presence information [14]. This subscription is handed by 90 a presence agent. In order to process the subscription, the presence 91 agent must make a determination about whether the subscription is 92 authorized. This authorization decision includes whether or not to 93 accept the subscription, but also includes decisions about when the 94 watcher should receive notifications, and when it does receive them, 95 what the content of those notifications should be. 97 Typically, the authorization decision will be a combination of the 98 authorization policies of the provider, combined with the 99 authorization policices of the presentity. In order for the PA to 100 compute the final authorization decision, it needs access to the 101 presentity's authorization policies. 103 In order to provide this access, the XML Configuration Access 104 Protocol (XCAP) [2] is used. XCAP allows a client to manipulate XML 105 documents stored on a server. Those XML documents represent per-user 106 provisioning data on how an application should operate. XCAP has the 107 notion of an application usage, which is a definition of the XML 108 schema used by a particular application, along with other relevant 109 information. Each application usage is given a unique application 110 usage ID (AUID) which identifies it. This specification makes use of 111 three application usages. 113 2. Structuring Presence Authorization 115 This specification defines three application usages (each with their 116 own XML schema) that, put together, present a comprehensive solution 117 for allowing clients to specify authorization policies that a PA can 118 use when processing a subscription. The first of these application 119 usages has the AUID of permission-statements. This usage allows a 120 client to make statements about which permissions are granted to 121 which watchers. Each statement contains a definition of the watchers 122 to whom it applies, and then contains a list of permissions which are 123 granted to those watchers. The concept of a permission is central to 124 this specification. A permission is an atomic statement of consent. A 125 permission can indicate a condition under which a subscription is 126 accepted or rejected, a condition under which a notification is or is 127 not sent, or a piece of information which is revealed in a presence 128 document. The overall authorization for a watcher is represented by 129 the union of the permissions granted to that watcher. 131 This specification contains a basic set of primitive permissions. It 132 is anticipated that new ones will be standardized in the future. It 133 is also anticipated that vendors will define proprietary permissions. 134 In order for a client to connect to a server, and achieve 135 interoperability, it is neccesary for the client to know what 136 permissions are supported by the server. The second application 137 usage, supported-permissions, allows a client to read the list of 138 permissions understood by the server. 140 3. Terminology 142 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 143 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 144 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 145 indicate requirement levels for compliant implementations. 147 4. Permission Statements 149 4.1 Application Unique ID 151 XCAP requires application usages to define a unique application usage 152 ID (AUID) in either the IETF tree or a vendor tree. This 153 specification defines the "permission-statements" AUID within the 154 IETF tree, via the IANA registration in Section 6. 156 4.2 Structure of Permission Statements 158 A permission statement is an XML [3] document that MUST be 159 well-formed and SHOULD be valid. Permission statement documents MUST 160 be based on XML 1.0 and MUST be encoded using UTF-8. This 161 specification makes use of XML namespaces for identifying permission 162 statement documents and document fragments. The namespace URI for 163 elements defined for this purpose is a URN [5], using the namespace 164 identifier 'ietf' defined by [7] and extended by [11]. This URN is: 166 urn:ietf:params:xml:ns:permission-statements 168 A permission statement document begins with the root element tag 169 "permission-statements". It consists of any number of "statement" 170 elements. Each statement element defines a set of permissions and 171 identifies to whom they are granted. 173 Each "statement" element has a single attribute: 175 id: This is a string which serves as a way to uniquely identify 176 statements in the document. The attribute MUST be unique amongst 177 all statement elements in the document. This attribute is 178 mandatory. 180 Each statement is composed of a single "applies-to" element and a 181 single "permissions" element. The "permissions" element is composed 182 of one or more elements that grant permissions. 184 4.2.1 Applying Statements to Watchers 186 The "applies-to" element defines the set of watchers to whom the 187 statement applies. It contains one or more "uri" elements, "domain" 188 elements, "on-list" elements or a single "any" element, followed by 189 any number of "except" elements. The "uri" element identifies a 190 single watcher by specifying its URI. The "domain" element says that 191 the statement applies to all watchers from the specified domain. The 192 "on-list" element says that the statement applies to all users on the 193 specified presence list [17], identified with an HTTP URI that points 194 to the list. Finally, the "any" element says that the statement 195 applies to all watchers. Additional elements can be added that 196 express other ways of identifying the watchers to whom the statement 197 applies. When unioned together, the result of the "uri", "domain", 198 "on-list" and "any" elements define a set of users to whom the 199 permission statement applies. This list is reduced in size by the 200 "except" element, which removes a user or domain from the set. The 201 "except" element contains instances of the "uri", "domain" and 202 "on-list" elements, which specify the users, domains, lists to be 203 removed from the set. 205 The "uri", "domain", "on-list", and "any" elements all have the 206 following attributes: 208 id: This is a string which serves as a way to uniquely identify an 209 instance of this element within the enclosing "applies-to" 210 element. The attribute MUST be unique amongst all elements of the 211 same name within the enclosing "applies-to" element. This 212 attribute is mandatory. 214 display-name: This is a string that contains a display name, suitable 215 for rendering to a human user, the identity of the user or domain 216 implied by the element. This attribute is optional. 218 lang: This attribute identifies the language used to represent the 219 display name. It is imported from the XML namespace. This 220 attribute is optional. 222 When a subscription arrives at the PA, the PA performs an 223 authentication operation to determine the identity of the watcher. It 224 then uses the "applies-to" element in each statement within the 225 presentity's document, and determines the set of statements that 226 apply to the watcher. It is possible that multiple statements can 227 match a single subscription. In that case, the union of the 228 permissions across those statements is applied to the subscription. 229 It is also possible that none of the statements match, in which case 230 the subscription is considered "pending". 232 For example, the following XML fragment includes two statements, one 233 that applies to the user joe@example.com, and another that applies to 234 example.com. When Joe subscribes, both statements match. Therefore, 235 he is granted the union of the permissions across the two statements. 237 238 239 240 241 sip:joe@example.com 242 244 245 246 248 250 251 252 example.com 253 255 256 257 258 260 262 4.2.2 Specifying Permissions 264 The remainder of the content of the "statement" element contains 265 specific permissions that are granted to watchers to whom the 266 statement applies. Each permission is represented by a single XML 267 element. 269 Primitive permissions can be grouped into two categories: 271 1. Acceptance permissions allow the watcher to subscribe. Without an 272 acceptance permission, a subscription is rejected outright. 274 2. Content permissions indicate which information the watcher is 275 permitted to see, in the event a notification is sent in the 276 first place (based on the rule permissions). 278 4.2.2.1 Acceptance Permissions 280 Acceptance permissions grant the ability of the watcher to subscribe 281 to the presentity. Without an acceptance permission, none of the 282 other permissions make any sense. There are only two primitive 283 acceptance permissions, each of which is an XML element. These are 284 "accept" and "accept-if". The "accept" element has no content and no 285 attributes. It simply grants permission to the watcher to subscribe. 286 Only one such element can be present in any statement. The 287 "accept-if" element also grants permission to subscribe, but the 288 granting of this permissions is predicated on some condition. The 289 content of the "accept-if" element is a condition element. Condition 290 elements describe characteristics of the subscription, or of the 291 operating environment of the server, which are either true or false. 292 If the condition within the "accept-if" element is true, an 293 acceptance permission is granted. 295 The following represent the conditions which can be checked: 297 auth-mechanism: This element contains an enumerated type that 298 describes authentication mechanisms. The defined values are none, 299 digest (referring to the HTTP digest [8] mechanism used in RFC 300 3261 [9]), smime (referring to SIP's S/MIME authentication), tls 301 (meaning that the watcher authenticated themself using a client 302 certificate in a mutual TLS exchange with the server), and 303 p-asserted-id (as defined in RFC 3325 [16]). The condition 304 evaluates to true if the client was authenticated using the listed 305 algorithm. 307 anonymous: This element contains no values. The condition evaluates 308 to true if the watcher is anonymous. They are considered anonymous 309 if the From header field of the request is equal to "Anonymous". 310 Note that a user can be anonymous and also have authenticated 311 themselves with digest. This occurs when the "anonymous" username 312 and password, as defined in RFC 3261 [9], are used. 314 can-encrypt: This element contains no values. The condition evaluates 315 to true if it is possible to encrypt, using S/MIME, notifications 316 sent to this watcher. Generally, this can be determined when the 317 Accept header field in the subscription indicates support for the 318 application/pkcs7-mime [10] MIME type. 320 As an example, the following statement grants permission for watcher 321 sip:joe@example.com to subscribe if he authenticates with digest: 323 324 325 326 327 sip:joe@example.com 328 330 332 digest 333 334 335 336 338 4.2.2.2 Content Permissions 340 Content permissions specify the information that is to be sent to a 341 watcher. Each permission specifies a piece of information that is to 342 be sent, or to be used in general in the computation of the presence 343 document. The defined permissions are: 345 all-content: This permission specifies that all presence information 346 can be sent. The element has no attributes or value. 348 show-contact-element: This permission specifies that the contact 349 component of the tuple can be sent. The element has no attributes 350 or value. 352 show-note: This permission specifies that the note component of the 353 tuple can be sent. The element has no attributes or value. 355 show-tuple: This permission specifies that the identified tuples can 356 be sent to the watcher. The element has no attributes. Its content 357 is a string that matches the "class" element present within the 358 tuple [12]. 360 show-element: This permission specifies that the XML element 361 identified by "show-element" can be presented to the watcher. The 362 content of "show-element" is a qualified element name. When 363 present, it that the specified element, if present in any 364 published documents from publishers, can be used by the presence 365 server and then distributed to watchers. 367 show-namespace: This permission specifies that elements and 368 attributes in the presence document within the specified namespace 369 can be presented to the watcher. When present, it that content 370 from the specified element, if present in any published documents 371 from publishers, can be used by the presence server and then 372 distributed to watchers. 374 encrypt: This permission specifies that the presence document should 375 be sent to the watcher encrypted. It should never be present in a 376 statement without the presence of an "accept-if" element which 377 conditions acceptance of the subscription on the ability of the 378 watcher to receive encrypted presence documents. 380 4.2.2.2.1 Examples 382 The following example specifies that a watcher is only allowed to see 383 baseline pidf information: 385 386 388 389 390 sip:joe@example.com 391 393 394 395 urn:ietf:params:xml:ns:pidf 396 398 399 401 The following example shows that the watcher is allowed to see PIDF 402 information along with the placetype element from RPIDS: 404 405 408 409 410 sip:joe@example.com 411 413 414 415 urn:ietf:params:xml:ns:pidf 416 rpids:placetype 417 419 420 422 4.3 Additional Constraints 424 The following are additional constraints not described by the schema: 426 o The content of a "show-element" element indicates the name of an 427 XML element, and may be fully qualified (i.e., prefixed with a 428 namespace identifier followed by a colon). 430 o The value of the "domain" element MUST be compliant to the BNF for 431 "host" as defined in RFC 3261 [9]. 433 o The value of the "on-list" element MUST be a valid HTTP URI that 434 represents a presence list, as defined in [17]. 436 o TODO: Complete this list. 438 4.4 Naming Conventions 440 When a presence agent receives a subscription for some user foo 441 within a domain, it will look for all documents within http://[xcap 442 root services uri]/permission-statements/users/foo, and use all 443 documents found beneath that point to guide authorization policy. 445 4.5 Authorization Policies 447 This application usage does not modify the default XCAP authorization 448 policy, which is that only a user can read, write or modify their own 449 documents. A server can allow priveleged users to modify documents 450 that they don't own, but the establishment and indication of such 451 policies is outside the scope of this document. 453 4.6 XML Schema 455 ]]> 457 TODOS: need to add points of extensibility. 459 5. Supported Permissions 461 Supported permissions allow a presentity to determine what the 462 capabilities of the PA are, in terms of expressing authorization 463 policy. This capability is expressed as a list of primitive 464 permissions, primitive conditions, and compound permissions. When a 465 client starts up, it reads this set of permissions from a well known 466 URI (see Section 5.3). It then knows which permissions, both 467 primitive and compound, that it can include in its permission 468 statements. 470 5.1 Application Unique ID 472 XCAP requires application usages to define a unique application usage 473 ID (AUID) in either the IETF tree or a vendor tree. This 474 specification defines the "supported-permissions" AUID within the 475 IETF tree, via the IANA registration in Section 6. 477 5.2 Structure of Supported Permissions 479 A supported permission is an XML [3] document that MUST be 480 well-formed and SHOULD be valid. Supported permission documents MUST 481 be based on XML 1.0 and MUST be encoded using UTF-8. This 482 specification makes use of XML namespaces for identifying supported 483 permission documents and document fragments. The namespace URI for 484 elements defined for this purpose is a URN [5], using the namespace 485 identifier 'ietf' defined by [7] and extended by [11]. This URN is: 487 urn:ietf:params:xml:ns:supported-permissions 489 A supported permission document begins with the root element tag 490 "supported-permissions". It consists of one "primitive-permissions" 491 element, and zero or one "conditions" elements. 493 The "primitive-permissions" element has, for its content, a 494 "permissions" element. This element contains a valid permission 495 statement which purposefully includes all primitive permissions that 496 are supported by the server. All PA's which allow for xcap-based 497 configuration of authorization MUST support, at a minimum, the 498 "accept", and "all-content" primitive permissions. 500 The "conditions" element contains a sequence of conditions which can 501 be used within the "accept-if" element. Clearly, the "conditions" 502 element will not be present if "accept-if" is not listed as a 503 supported permission. There is no minimum requirement for a PA in 504 terms of the conditions that need to be supported. 506 5.3 Naming Conventions 508 When a client starts, it can fetch the permissions understood by the 509 server in one of two places. If the server capabilities differ on a 510 user by user basis, the supported permissions for user foo can be 511 found in http://[xcap root services uri]/supported-permissions/users/ 512 foo/sp.xml. A client SHOULD check this file first. If this document 513 doesn't exist, the client should next check for the system wide 514 permissions by checking http://[xcap root services uri]/ 515 supported-permissions/global/sp.xml. 517 5.4 Authorization Policies 519 This application usage does not modify the default XCAP authorization 520 policy, which is that only a user can read, write or modify their own 521 documents. A server can allow priveleged users to modify documents 522 that they don't own, but the establishment and indication of such 523 policies is outside the scope of this document. 525 5.5 XML Schema 527 528 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 550 551 552 553 554 555 556 558 5.6 Example Document 560 This example document describes a PA that allows very simple 561 primitive types. Instead, it defines several compound ones that are 562 the preferred way for clients to express permissions. 564 565 570 571 572 573 574 example 575 576 577 579 6. IANA Considerations 581 There are several IANA considerations associated with this 582 specification. 584 6.1 XCAP Application Usage IDs 586 This section registers three XCAP Application Usage IDs (AUID) 587 according to the IANA procedures defined in [2]. 589 6.1.1 Permission Statements 591 Name of the AUID: permission-statements 593 Description: Permission-statements are documents that describe the 594 permissions that a presentity [13] has granted to users that seek 595 to watch their presence. 597 6.1.2 Supported Permissions 599 Name of the AUID: supported-permissions 601 Description: Supported permissions are documents that describe the 602 types of permissions which are supported by a presence agent [14]. 603 These permissions specify the information that watchers [13] of 604 presence are allowed to see. 606 6.2 URN Sub-Namespace Registrations 608 This section registers several new XML namespaces, as per the 609 guidelines in [11] 611 6.2.1 urn:ietf:params:xml:ns:permission-statements 613 URI: The URI for this namespace is 614 urn:ietf:params:xml:ns:permission-statements. 616 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 617 Jonathan Rosenberg (jdrosen@jdrosen.net). 619 XML: 621 BEGIN 622 623 625 626 627 629 Permission Statements Namespace 630 631 632

Namespace for Permission Statements

633

urn:ietf:params:xml:ns:permission-statements

634

See RFCXXXX.

635 636 637 END 639 6.2.2 urn:ietf:params:xml:ns:supported-permissions 641 URI: The URI for this namespace is 642 urn:ietf:params:xml:ns:supported-permissions. 644 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 645 Jonathan Rosenberg (jdrosen@jdrosen.net). 647 XML: 649 BEGIN 650 651 653 654 655 657 Supported Permissions Namespace 658 659 660

Namespace for Supported Permissions

661

urn:ietf:params:xml:ns:supported-permissions

662

See RFCXXXX.

663 664 665 END 667 6.3 XML Schema Registrations 669 This section registers three XML schemas as per the procedures in 670 [11]. 672 6.3.1 Permissions Statements 674 URI: please assign. 676 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 677 Jonathan Rosenberg (jdrosen@jdrosen.net). 679 The XML for this schema can be found as the sole content of 680 Section 4.6. 682 6.3.2 Supported Permissions 684 URI: please assign. 686 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 687 Jonathan Rosenberg (jdrosen@jdrosen.net). 689 The XML for this schema can be found as the sole content of 690 Section 5.5. 692 Normative References 694 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 695 Levels", BCP 14, RFC 2119, March 1997. 697 [2] Rosenberg, J., "The Extensible Markup Language (XML) 698 Configuration Access Protocol (XCAP)", 699 draft-ietf-simple-xcap-00 (work in progress), June 2003. 701 [3] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 702 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 703 REC REC-xml-20001006, October 2000. 705 [4] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 706 1.0", W3C REC REC-xpath-19991116, November 1999. 708 [5] Moats, R., "URN Syntax", RFC 2141, May 1997. 710 [6] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 711 3023, January 2001. 713 [7] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 714 August 1999. 716 [8] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 717 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 718 Basic and Digest Access Authentication", RFC 2617, June 1999. 720 [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 721 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 722 Session Initiation Protocol", RFC 3261, June 2002. 724 [10] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 725 2633, June 1999. 727 [11] Mealling, M., "The IETF XML Registry", 728 draft-mealling-iana-xmlns-registry-05 (work in progress), June 729 2003. 731 [12] Schulzrinne, H., "RPID -- Rich Presence Information Data 732 Format", draft-ietf-simple-rpid-00 (work in progress), July 733 2003. 735 Informative References 737 [13] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 738 Instant Messaging", RFC 2778, February 2000. 740 [14] Rosenberg, J., "A Presence Event Package for the Session 741 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 742 in progress), January 2003. 744 [15] Sugano, H. and S. Fujimoto, "Presence Information Data Format 745 (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 746 2003. 748 [16] Jennings, C., Peterson, J. and M. Watson, "Private Extensions 749 to the Session Initiation Protocol (SIP) for Asserted Identity 750 within Trusted Networks", RFC 3325, November 2002. 752 [17] Rosenberg, J., "An Extensible Markup Language (XML) 753 Configuration Access Protocol (XCAP) Usage for Presence 754 Lists", draft-ietf-simple-xcap-list-usage-00 (work in 755 progress), June 2003. 757 Author's Address 759 Jonathan Rosenberg 760 dynamicsoft 761 600 Lanidex Plaza 762 Parsippany, NJ 07052 763 US 765 Phone: +1 973 952-5000 766 EMail: jdrosen@dynamicsoft.com 767 URI: http://www.jdrosen.net 769 Intellectual Property Statement 771 The IETF takes no position regarding the validity or scope of any 772 intellectual property or other rights that might be claimed to 773 pertain to the implementation or use of the technology described in 774 this document or the extent to which any license under such rights 775 might or might not be available; neither does it represent that it 776 has made any effort to identify any such rights. Information on the 777 IETF's procedures with respect to rights in standards-track and 778 standards-related documentation can be found in BCP-11. Copies of 779 claims of rights made available for publication and any assurances of 780 licenses to be made available, or the result of an attempt made to 781 obtain a general license or permission for the use of such 782 proprietary rights by implementors or users of this specification can 783 be obtained from the IETF Secretariat. 785 The IETF invites any interested party to bring to its attention any 786 copyrights, patents or patent applications, or other proprietary 787 rights which may cover technology that may be required to practice 788 this standard. Please address the information to the IETF Executive 789 Director. 791 Full Copyright Statement 793 Copyright (C) The Internet Society (2003). All Rights Reserved. 795 This document and translations of it may be copied and furnished to 796 others, and derivative works that comment on or otherwise explain it 797 or assist in its implementation may be prepared, copied, published 798 and distributed, in whole or in part, without restriction of any 799 kind, provided that the above copyright notice and this paragraph are 800 included on all such copies and derivative works. However, this 801 document itself may not be modified in any way, such as by removing 802 the copyright notice or references to the Internet Society or other 803 Internet organizations, except as needed for the purpose of 804 developing Internet standards in which case the procedures for 805 copyrights defined in the Internet Standards process must be 806 followed, or as required to translate it into languages other than 807 English. 809 The limited permissions granted above are perpetual and will not be 810 revoked by the Internet Society or its successors or assignees. 812 This document and the information contained herein is provided on an 813 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 814 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 815 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 816 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 817 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 819 Acknowledgement 821 Funding for the RFC Editor function is currently provided by the 822 Internet Society.