idnits 2.17.1 draft-ietf-simple-xcap-list-usage-05.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 1424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1401. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1414. ** 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 13 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 (February 7, 2005) is 7018 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: '11' is defined on line 1359, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2141 (ref. '3') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3023 (ref. '5') (Obsoleted by RFC 7303) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '6') ** Obsolete normative reference: RFC 2048 (ref. '9') (Obsoleted by RFC 4288, RFC 4289) == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-05 == Outdated reference: A later version (-10) exists of draft-ietf-simple-presence-rules-01 -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '14') (Obsoleted by RFC 6665) Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: August 8, 2005 February 7, 2005 6 Extensible Markup Language (XML) Formats for Representing Resource 7 Lists 8 draft-ietf-simple-xcap-list-usage-05 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 August 8, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 In multimedia communications, presence and instant messaging systems, 44 there is a need to define Uniform Resource Identifiers (URIs) that 45 represent services which are associated with a group of users. One 46 example is a resource list service. If a user sends a Session 47 Initiation Protocol (SIP) SUBSCRIBE message to the URI representing 48 the resource list service, the server will obtain the state of the 49 users in the associated group, and provide it to the sender. To 50 facilitate definition of these services, this specification defines 51 two Extensible Markup Language (XML) documents. One document 52 contains service URIs, along with their service definition and a 53 reference to the associated group of users. The second document 54 contains the user lists which are referenced from the first. This 55 list of users can be utilized by other applications and services. 56 Both documents can be created and managed with the XML Configuration 57 Access Protocol (XCAP). 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Resource Lists Documents . . . . . . . . . . . . . . . . . . . 5 64 3.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 3.3 Example Document . . . . . . . . . . . . . . . . . . . . . 10 67 3.4 Usage with XCAP . . . . . . . . . . . . . . . . . . . . . 11 68 3.4.1 Application Unique ID . . . . . . . . . . . . . . . . 11 69 3.4.2 MIME Type . . . . . . . . . . . . . . . . . . . . . . 11 70 3.4.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . 11 71 3.4.4 Default Namespace . . . . . . . . . . . . . . . . . . 12 72 3.4.5 Additional Constraints . . . . . . . . . . . . . . . . 12 73 3.4.6 Data Semantics . . . . . . . . . . . . . . . . . . . . 12 74 3.4.7 Naming Conventions . . . . . . . . . . . . . . . . . . 13 75 3.4.8 Resource Interdependencies . . . . . . . . . . . . . . 13 76 3.4.9 Authorization Policies . . . . . . . . . . . . . . . . 14 77 4. RLS Services Documents . . . . . . . . . . . . . . . . . . . . 14 78 4.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . 14 79 4.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 4.3 Example Document . . . . . . . . . . . . . . . . . . . . . 16 81 4.4 Usage with XCAP . . . . . . . . . . . . . . . . . . . . . 17 82 4.4.1 Application Unique ID . . . . . . . . . . . . . . . . 17 83 4.4.2 MIME Type . . . . . . . . . . . . . . . . . . . . . . 17 84 4.4.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . 17 85 4.4.4 Default Namespace . . . . . . . . . . . . . . . . . . 17 86 4.4.5 Additional Constraints . . . . . . . . . . . . . . . . 18 87 4.4.6 Data Semantics . . . . . . . . . . . . . . . . . . . . 19 88 4.4.7 Naming Conventions . . . . . . . . . . . . . . . . . . 19 89 4.4.8 Resource Interdependencies . . . . . . . . . . . . . . 19 90 4.4.9 Authorization Policies . . . . . . . . . . . . . . . . 21 91 4.5 Usage of an RLS Services Document by an RLS . . . . . . . 22 92 5. SIP URI Canonicalization . . . . . . . . . . . . . . . . . . . 23 93 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 24 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 96 8.1 XCAP Application Unique IDs . . . . . . . . . . . . . . . 25 97 8.1.1 resource-lists . . . . . . . . . . . . . . . . . . . . 25 98 8.1.2 rls-services . . . . . . . . . . . . . . . . . . . . . 26 99 8.2 MIME Type Registrations . . . . . . . . . . . . . . . . . 26 100 8.2.1 application/resource-lists+xml . . . . . . . . . . . . 26 101 8.2.2 application/rls-services+xml . . . . . . . . . . . . . 27 102 8.3 URN Sub-Namespace Registrations . . . . . . . . . . . . . 28 103 8.3.1 urn:ietf:params:xml:ns:resource-lists . . . . . . . . 28 104 8.3.2 urn:ietf:params:xml:ns:rls-services . . . . . . . . . 29 105 8.4 Schema Registrations . . . . . . . . . . . . . . . . . . . 29 106 8.4.1 urn:ietf:params:xml:schema:resource-lists . . . . . . 29 107 8.4.2 urn:ietf:params:xml:schema:rls-services . . . . . . . 30 108 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 110 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 30 111 10.2 Informative References . . . . . . . . . . . . . . . . . . . 31 112 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31 113 Intellectual Property and Copyright Statements . . . . . . . . 32 115 1. Introduction 117 The Session Initiation Protocol (SIP) [4] defines the SIP Uniform 118 Resource Identifier (URI) as any resource to which a SIP request can 119 be generated for the purposes of establishing some form of 120 communications operation. These URIs can represent users (for 121 example, sip:joe@example.com). The SIP URI can also represent a 122 service, such as voicemail, conferencing, or a presence list. A 123 common pattern across such SIP services is that the service is 124 defined, and associated with a URI. In order to operate, that 125 service needs to make use of a list of users (or, more generally, a 126 list of resources). When a SIP request is sent to the service URI, 127 the server providing the service reads that list, and then performs 128 some kind of operation against each resource on the list. This is 129 shown pictorially in Figure 1. 131 /---\ 132 | | 133 \---/ Resource 134 +----| | List 135 | | | 136 | \---/ 137 | 138 | 139 | 140 | 141 V 142 +-------------+ 143 | | --------> 144 | SIP | 145 ---------------> | Service | --------> 146 service | | 147 URI | | --------> 148 +-------------+ 150 Figure 1 152 One important example of such a service is a presence [12] list 153 service. A presence list service allows a client to generate a SIP 154 SUBSCRIBE request to ask for presence information for a list of 155 users. The presence list server obtains the presence for the users 156 on the list, and provides them back to the client. A presence list 157 server is a specific case of a resource list server (RLS) [15], which 158 allows a client to generate a SIP SUBSCRIBE request to ask for 159 notifications of SIP events for a list of resources. 161 Another example of such a service is an instant conference service. 162 If a client sends a SIP INVITE request to the URI representing the 163 instance conference service, the conference server will create a 164 conference call containing the client and the associated group of 165 users. 167 It is very useful for a user of these systems to define the groups of 168 users or resources (generally called a resource list) separately from 169 the services which access those resource lists. Indeed, there are 170 usages for resource lists even in the absence of any associated 171 network-based service. As an example, rather than using a presence 172 list service, a client might generate individual SUBSCRIBE requests 173 to obtain the presence of each user in a locally stored presence 174 list. In such a case, there is a need for a format for storing the 175 list locally on disk. Furthermore, the user might wish to share the 176 list with friends, and desire to email it to those friends. This 177 also requires a standardized format for the resource list. 179 As such, this document defines two Extensible Markup Language (XML) 180 document formats. The first is used to represent resource lists, 181 independent of any particular service. The second is used to define 182 service URIs for an RLS, and to associate a resource list with the 183 service URI. This document also defines an XML Configuration Access 184 Protocol (XCAP) [10] application usage for managing each of these two 185 documents. 187 2. Terminology 189 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 190 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 191 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 192 indicate requirement levels for compliant implementations. 194 3. Resource Lists Documents 196 3.1 Structure 198 A resource lists document is an XML [2] document that MUST be 199 well-formed and MUST be valid according to schemas, including 200 extension schemas, available to the validater and applicable to the 201 XML document. Resource lists documents MUST be based on XML 1.0 and 202 MUST be encoded using UTF-8. This specification makes use of XML 203 namespaces for identifying resource lists documents and document 204 fragments. The namespace URI for elements defined by this 205 specification is a URN [3], using the namespace identifier 'ietf' 206 defined by RFC 2648 [6] and extended by RFC 3688 [8]. This URN is: 208 urn:ietf:params:xml:ns:resource-lists 210 A resource lists document has the element as the 211 root element of the document. This element has no attributes. Its 212 content is a sequence of one or more elements, each of which 213 defines a single resource list. 215 Each element can contain an optional "name" attribute. This 216 attribute is a handle for the list. When present, it MUST be unique 217 amongst all other elements within the same parent element. 218 THe element may also contain attributes from other namespaces, 219 for the purposes of extensibility. 221 Each element is composed of an optional display name, a 222 sequence of zero or more elements, each of which may be an 223 element, a element, an element, or an 224 element, followed by any number of elements from other namespaces, 225 for the purposes of extensibility. The ability of a element 226 to contain other elements means that a resource list can be 227 hierarchically structured. The then allows for a 228 human-friendly name to be associated with each level in the 229 hierarchy. An element describes a single resource, defined 230 by a URI, that is part of the list. An element allows an 231 entry in a document within the same XCAP root to be included by 232 reference, rather than by value. An element contains a 233 reference to a list stored on this or another server. 235 The element describes a single resource. The element 236 has a single mandatory attribute, "uri". This attribute is equal to 237 the URI that is used to access the resource. The resource list 238 format itself does not constrain the type of URI that can be used. 239 However, the service making use of the resource list may require 240 specific URI schemes. For example, RLS services will require URIs 241 that represent subscribeable resources. This includes the SIP and 242 pres [16] URIs. The "uri" attribute MUST be unique amongst all other 243 "uri" attributes in elements within the same parent. 244 Uniqueness is determined by case sensitive string comparisons. As 245 such, it is possible that two "uri" attributes will have the same URI 246 when compared using the functional equality rules defined for that 247 URI scheme, but different ones when compared using case sensitive 248 string comparison. The element can also contain attributes 249 from other namespaces for the purposes of extensibility. 251 The element contains a sequence of elements that provide 252 information about the entry. Only one such element is defined at 253 this time, which is . This element provides a UTF-8 254 encoded string, meant for consumption by a human user, that describes 255 the resource. Unlike the "name" attribute of the element, 256 the has no uniqueness requirements. The 257 element can contain the "xml:lang" attribute, which 258 provides the language of the display name. The element can 259 contain other elements from other namespaces. This is meant to 260 support the inclusion of other information about the entry, such as a 261 phone number or postal address. 263 The element allows an entry to be included in the list by 264 reference, rather than by value. This element is only meaningful 265 when the document was obtained through XCAP. In such a case, the 266 referenced entry has to exist within the same XCAP root. The 267 element has a single mandatory attribute, "ref". The "ref" attribute 268 MUST be unique amongst all other "ref" attributes in 269 elements within the same parent. Uniqueness is determined by case 270 sensitive string comparisons. The element also allows 271 attributes from other namespaces, for the purposes of extensibility. 272 The content of an element is an optional display name, 273 followed by any number of elements from other namespaces, for the 274 purposes of extensibility. The display name is useful for providing 275 a localized nickname as an alternative to the name defined in the 276 to which the refers. 278 The content of the "ref" attribute is a relative HTTP URI [7]. 279 Specifically, it MUST be a relative path reference, where the base 280 URI is equal to the XCAP root URI of the document in which the 281 appears. This relative URI, if resolved into an absolute 282 URI according to the procedures in RFC 3986, MUST resolve to an 283 element within a resource-lists document. For example, if an 284 element within a specific XCAP root was identified by the 285 following HTTP URI: 287 http://xcap.example.com/root/resource-lists/users/bill/ 288 mylist/~~/resource-lists/list%5b@name=%22list1%22%5d/ 289 entry%5b@uri=%22sip:petri@example.com%22%5d 291 If http://xcap.example.com/root is the XCAP root URI, then an 292 element pointing to this entry would have the form: 294 298 Note that line folding within the HTTP URI and XML attribute above 299 are for the purposes of readability only. Also note that, as 300 described in RFC 3986, the relative path URI does not begin with the 301 "/". Since the relative URI used within the "ref" attribute must be 302 a relative path URI, the "/" will never be present as the first 303 character within the content of a "ref" attribute. Since the content 304 of the "ref" attribute is a valid HTTP URI, it must be escape encoded 305 within the XML document. 307 The element is similar to the element. Like 308 , it is only meaningful in documents obtained from an XCAP 309 server. It too is a reference to content stored elsewhere. However, 310 it refers to an entire list, and furthermore, allows that list to be 311 present on another server. The element has a single 312 mandatory attribute, "anchor", which specifies the external list by 313 means of an absolute HTTP URI. The "anchor" attribute MUST be unique 314 amongst all other "anchor" attributes in elements within 315 the same parent. Uniqueness is determined by case sensitive string 316 comparisons. The element can also contain attributes from 317 other namespaces, for the purposes of extensibility. The content of 318 an element is an optional followed by any 319 number of elements from another namespace, for the purposes of 320 extensibility. The value of the "anchor" attribute MUST be an 321 absolute HTTP URI. This URI MUST identify an XCAP resource, and in 322 particular, it MUST represent a element within a resource 323 lists document. The URI MUST be escape coded. 325 For both the and elements, the responsibility 326 of resolving their references falls upon the entity that is making 327 use of the document. When used in conjunction with XCAP, this means 328 that the burden falls on the XCAP client. If the XCAP client is a PC 329 based application using the resource-lists document as a presence 330 list, the references would likely be resolved upon explicit request 331 by the user. They can, of course, be resolved at any time. If the 332 XCAP client is an RLS itself, the references would be resolved when 333 the RLS receives a SUBSCRIBE request for an RLS service associated 334 with a resource list that contains one of these references (see 335 below). An XCAP server defined by this specification will not 336 attempt to resolve the references before returning the document to 337 the client. Similarly, if, due to network errors or some other 338 problem, the references cannot be resolved, the handling is specific 339 to the usage of the document. For resource lists being used by RLS 340 services, the handling is discussed below. 342 3.2 Schema 344 345 349 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 422 3.3 Example Document 424 The following is an example of a document compliant to the schema. 425 All line feeds within element content are for display purposes only. 427 428 430 431 432 Bill Doe 433 434 436 437 Close Friends 438 439 Joe Smith 440 441 442 Nancy Gross 443 444 446 Marketing 447 448 449 450 452 3.4 Usage with XCAP 454 Resource lists documents can be manipulated with XCAP. This section 455 provides the details necessary for such a usage. 457 3.4.1 Application Unique ID 459 XCAP requires application usages to define a unique application usage 460 ID (AUID) in either the IETF tree or a vendor tree. This 461 specification defines the "resource-lists" AUID within the IETF tree, 462 via the IANA registration in Section 8. 464 3.4.2 MIME Type 466 The MIME type for this document is "application/resource-lists+xml". 468 3.4.3 XML Schema 470 The XML Schema for this document is defined as the sole content of 471 Section 3.2. 473 3.4.4 Default Namespace 475 The default namespace used in expanding URIs is 476 urn:ietf:params:xml:ns:resource-lists. 478 3.4.5 Additional Constraints 480 In addition to the schema, there are constraints on the values 481 present in the the "name" attribute of the element, the "uri" 482 attribute of the element, the "ref" attribute of the 483 element and the "anchor" attribute of the 484 element. These constraints are defined in Section 3.1. Some of 485 these constraints are enforced by the XCAP server. Those constraints 486 are: 488 o The "name" attribute in a element MUST be unique amongst 489 all other "name" attributes of elements within the same 490 parent element. Uniqueness is determined by case sensitive string 491 comparison. 493 o The "uri" attribute in a element MUST be unique amongst 494 all other "uri" attributes of elements within the same 495 parent element. Uniqueness is determined by case sensitive string 496 comparison. 498 o The URI in the "ref" attribute of the element MUST be 499 unique amongst all other "ref" attributes of elements 500 within the same parent element. Uniqueness is determined by case 501 sensitive string comparison. The value of the attribute MUST be a 502 relative path reference. Note that the server is not responsible 503 for verifying that the reference resolves to an element in 504 a document within the same XCAP root. 506 o The URI in the "anchor" attribute of the element MUST 507 be unique amongst all other "anchor" attributes of 508 elements within the same parent element. Uniqueness is determined 509 by case sensitive string comparison. The value of the attribute 510 MUST be an absolute HTTP URI. Note that the server is not 511 responsible for verifying that the URI resolves to a 512 element in a document. Indeed, since the URI may reference a 513 server in another domain, referential integrity cannot be 514 guaranteed without adding substantial complexity to the system. 516 3.4.6 Data Semantics 518 Semantics for the document content are provided in Section 3.1. 520 3.4.7 Naming Conventions 522 Resource lists documents are usually identified as references from 523 other application usages. For example, an RLS services document 524 contains a reference to the resource list it uses. 526 Frequently, an XCAP client will wish to insert or remove an , 527 or element from a document without having a 528 cached copy of that document. In such a case, the "uri" attribute of 529 the element, the "ref" attribute of the element 530 or the "anchor" attribute of the element is used as an 531 index to select the element to operate upon. The XCAP server will 532 determine uniqueness by case sensitive string comparison. However, 533 each of these attributes contain URIs, and the URI equality rules for 534 their schemes may allow for two URI to be the same, even if they are 535 different by case sensitive string comparison. As such, it is 536 possible that a client will attempt a PUT or DELETE in an attempt to 537 modify or remove an existing element, but instead, the PUT ends up 538 inserting a new element, or the DELETE ends up returning an error 539 response. 541 To mitigate against this case, if the client knows that the user 542 intent is to explicitly modify an existing element, as opposed to 543 creating a new one, the client SHOULD make the request conditional, 544 using an If-Match header field with a value of *. This will cause 545 the request to fail if it is not a replacement. 547 If the XCAP client cannot determine whether the user intent is to 548 create or replace, the client SHOULD canonicalize the URI before 549 performing the operation. For a SIP URI (often present in the "uri" 550 attribute of the element), this canonicalization procedure is 551 defined in Section 5. We expect that the SIP URIs that will be 552 placed into resource lists documents will usually be of the form 553 sip:user@domain, and possibly include a user parameter. The 554 canonicalization rules work perfectly for these URIs. 556 For HTTP URIs, a basic canonicalization algorithm is as follows. If 557 the the port in the URI is equal to the default port (80 for http 558 URIs), the port is removed. The hostname is converted to all 559 lowercase. Any characters that are escape encoded are un-escaped, 560 and only re-escaped if they cannot be represented within their 561 component of the URI. In other words, if the grammar for a part of 562 the URI disallows a certain character, but that character needs to be 563 present, it is escape coded. 565 3.4.8 Resource Interdependencies 567 There are no resource interdependencies identified by this 568 application usage. 570 3.4.9 Authorization Policies 572 This application usage does not modify the default XCAP authorization 573 policy, which is that only a user can read, write or modify their own 574 documents. A server can allow privileged users to modify documents 575 that they don't own, but the establishment and indication of such 576 policies is outside the scope of this document. It is anticipated 577 that a future application usage will define which users are allowed 578 to modify a list resource. 580 4. RLS Services Documents 582 4.1 Structure 584 An RLS services document is used to define URIs that represent 585 services provided by a Resource List Server (RLS) as defined in [15]. 586 An RLS services document is an XML [2] document that MUST be 587 well-formed and MUST be valid according to schemas, including 588 extension schemas, available to the validater and applicable to the 589 XML document. RLS services documents MUST be based on XML 1.0 and 590 MUST be encoded using UTF-8. This specification makes use of XML 591 namespaces for identifying RLS services documents and document 592 fragments. The namespace URI for elements defined by this 593 specification is a URN [3], using the namespace identifier 'ietf' 594 defined by RFC 2648 [6] and extended by RFC 3688 [8]. This URN is: 596 urn:ietf:params:xml:ns:rls-services 598 The root element of an rls-services document is . It 599 contains a sequence of elements, each of which defines a 600 service available at an RLS. 602 Each element has a single mandatory attribute, "uri". This 603 URI defines the resource associated with the service. That is, if a 604 client subscribes to that URI, they will obtain the service defined 605 by the corresponding element. The element can 606 also contain attributes from other namespaces, for the purposes of 607 extensibility. The element contains child elements that 608 define the service. For an RLS service, very little service 609 definition is needed - just the resource list to which the server 610 will perform virtual subscriptions [15] and the set of event packages 611 that the service supports. The former can be conveyed in one of two 612 ways. There can be a element, which points to a 613 element in a resource-lists document, or there can be a 614 element, which includes the resource list directly. The supported 615 packages are contained in the element. The 616 element can also contain elements from other namespaces, for the 617 purposes of extensibility. 619 By including the contents of the resource list directly, a user can 620 create lists and add members to them with a single XCAP operation. 621 However, the resulting list becomes "hidden" within the RLS service 622 definition, and is not usable by other application usages. For this 623 reason, the element exists as an alternative. It can 624 reference a element in a resource-lists document. Since the 625 list is separated from the service definition, it can be easily 626 reused by other application usages. 628 The element is of the list type defined by the schema for 629 resource lists. It is discussed in Section 3.1. 631 The element contains a URI. This element is only 632 meaningful when the document was obtained through XCAP. The URI MUST 633 be an absolute HTTP URI representing an XCAP element resource. Its 634 XCAP root MUST be the same as the XCAP root of the RLS services 635 document. When the RLS services document is present in a user's home 636 directory, the HTTP URI MUST exist underneath that user's home 637 directory in the resource-lists application usage. When the RLS 638 services document is in the global directory, the HTTP URI MUST exist 639 underneath any user's home directory in the resource-lists 640 application usage. In either case, the element referenced by the URI 641 MUST be a element within a resource-lists document. All of 642 these constraints except for the latter one (which is a referential 643 integrity constraint) will be enforced by the XCAP server. 645 The element contains a sequence of elements. 646 The content of each element is the name of a SIP event 647 package [14]. The element may also contain elements from 648 additional namespaces, for the purposes of extensibility. The 649 element is optional. When not present, it means that the 650 RLS service will accept subscriptions for any event package. 652 4.2 Schema 653 654 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 675 676 677 678 679 680 681 682 684 685 686 687 688 689 691 4.3 Example Document 693 This document shows two services. One is sip:mybuddies@example.com, 694 and the other is sip:marketing@example.com. The former service 695 references a resource list in a resource-lists document, and the 696 latter one includes a list locally. Both services are for the 697 presence event package only. 699 700 703 704 http://xcap.example.com/resource-lists/users/joe/index/~~/ 705 resource-lists/list%5b@name=%22l1%22%5d 706 707 presence 708 709 710 711 712 713 714 715 716 presence 717 718 719 721 4.4 Usage with XCAP 723 RLS services documents can be manipulated with XCAP. This section 724 provides the details necessary for such a usage. 726 4.4.1 Application Unique ID 728 XCAP requires application usages to define a unique application usage 729 ID (AUID) in either the IETF tree or a vendor tree. This 730 specification defines the "rls-services" AUID within the IETF tree, 731 via the IANA registration in Section 8. 733 4.4.2 MIME Type 735 The MIME type for this document is "application/rls-services+xml". 737 4.4.3 XML Schema 739 The XML Schema for this document is defined as the sole content of 740 Section 4.2. 742 4.4.4 Default Namespace 744 The default namespace used in expanding URIs is 745 urn:ietf:params:xml:ns:rls-services. 747 4.4.5 Additional Constraints 749 In addition to the schema, there are constraints on the URIs present 750 in the and elements. These constraints are 751 defined in Section 3.1. Some of these constraints are enforced by 752 the XCAP server. Those constraints are: 754 o The URI in the "uri" attribute of the element MUST be 755 unique amongst all other URIs in "uri" elements in any 756 element in any document on a particular server. This uniqueness 757 constraint spans across XCAP roots. Furthermore, the URI MUST NOT 758 correspond to an existing resource within the domain of the URI. 759 If a server is asked to set the URI to something that already 760 exists, the server MUST reject the request with a 409, and use the 761 mechanisms defined in [10] to suggest alternate URIs that have not 762 yet been allocated. 764 o The URI in a element MUST be an absolute URI. The 765 server MUST verify that the URI path contains "resource-lists" in 766 the path segment corresponding to the AUID. If the RLS services 767 document is within the XCAP user tree (as opposed to the global 768 tree), the server MUST verify that the XUI in the path is the same 769 as the XUI in the URI of to the RLS services document. These 770 checks are made by examining the URI value, as opposed to 771 de-referencing the URI. The server is not responsible for 772 verifying that the URI actually points to a element within 773 a valid resource lists document. 775 o In addition, an RLS services document can contain a 776 element, which in turn can contain , and 777 elements. The constraints defined for these elements 778 in Section 3.4.7 MUST be enforced. 780 o In some cases, an XCAP client will wish to create a new RLS 781 service, and wish to assign it a "vanity URI", such as 782 sip:friends@example.com. However, the client does not know 783 whether this URI meets the uniqueness constraints defined above. 784 In that case, it can simply attempt the creation operation, and if 785 the result is a 409 that contains a detailed conflict report with 786 the element, the client knows that the URI 787 could not be assigned. It can then retry with a different vanity 788 URI, or use one of the suggestions in the detailed conflict 789 report. 791 o If the client wishes to create a new RLS service, and it doesnt 792 care what the URI is, the client creates a random one, and 793 attempts the creation operation. As discussed in [10], if this 794 should fail with a uniqueness conflict, the client can retry with 795 different URIs with increasing randomness. 797 4.4.6 Data Semantics 799 Semantics for the document content are provided in Section 4.1. 801 4.4.7 Naming Conventions 803 Typically, there are two distinct XCAP clients that access RLS 804 services documents. The first is a client acting on behalf of the 805 end user in the system. This client edits and writes both resource 806 lists and RLS services documents as they are created or modified by 807 the end user. The other XCAP client is the RLS itself, which reads 808 the RLS services documents in order to process SUBSCRIBE requests. 810 To make it easier for an RLS to find the element for a 811 particular URI, the XCAP server maintains, within the global tree, a 812 single RLS services document representing the union of all of the 813 elements across all documents created by all users within 814 the same XCAP root. There is a single instance of this document, and 815 its name is "index". Thus, if the root services URI is 816 http://xcap.example.com/root, the following is the URI that an RLS 817 would use to fetch this index: 819 http://xcap.example.com/root/rls-services/global/index 821 As discussed below, this index is created from all of the documents 822 in the user tree that have the name "index" as well. An implication 823 of this is that a client operating on behalf of a user SHOULD define 824 its RLS services within the document named "index". If the root 825 services URI is http://xcap.example.com/root, for user "joe" the URI 826 for this document would be: 828 http://xcap.example.com/root/rls-services/users/joe/index 830 If a client elects to define RLS services in a different document, 831 this document will not be "picked up" in the global index, and 832 therefore, not used as an RLS service. 834 4.4.8 Resource Interdependencies 836 As with other application usages, the XML schema along with the XCAP 837 resource naming conventions describes most of the resource 838 interdependencies applicable to this application usage. 840 This application usage defines an additional resource interdependence 841 between a single document in the global tree and all documents in the 842 user tree with the name "index". This global document is formed as 843 the union of all of the index documents for all users within the same 844 XCAP root. In this case, the union operation implies that each 845 element in a user document will also be present as a 846 element in the global document. The inverse is true as 847 well. Every element in the global document exists within a 848 user document within the same XCAP root. 850 As an example, consider the RLS services document for user joe: 852 853 854 855 http://xcap.example.com/resource-lists/users/joe/index/~~/ 856 resource-lists/list%5b@name=%22l1%22%5d 857 858 presence 859 860 861 863 And consider the RLS services document for user bob: 865 866 867 868 869 870 871 872 873 presence 874 875 876 878 The global document at 879 http://xcap.example.com/root/rls-services/global/index would look 880 like: 882 883 886 887 http://xcap.example.com/resource-lists/users/joe/index/~~/ 888 resource-lists/list%5b@name=%22l1%22%5d 889 890 presence 891 892 893 894 895 896 897 898 899 presence 900 901 902 904 Requests made against the global document MUST generate responses 905 that reflect the most recent state of all the relevant user 906 documents. This requirement does not imply that the server must 907 actually store this global document. It is anticipated that most 908 systems will dynamically construct the responses to any particular 909 request against the document resource. 911 The uniqueness constraint on the "uri" attribute of will 912 ensure that no two elements in the global document have the 913 same value of that attribute. 915 4.4.9 Authorization Policies 917 This application usage does not modify the default XCAP authorization 918 policy, which is that only a user can read, write or modify their own 919 documents. A server can allow privileged users to modify documents 920 that they don't own, but the establishment and indication of such 921 policies is outside the scope of this document. It is anticipated 922 that a future application usage will define which users are allowed 923 to modify an RLS services document. 925 The index document maintained in the global tree represents sensitive 926 information, as it contains the union of all of the information for 927 all users on the server. As such, its access MUST be restricted to 928 trusted elements within domain of the server. Typically, this would 929 be limited to the RLSs that need access to this document. 931 4.5 Usage of an RLS Services Document by an RLS 933 This section discusses how an RLS, on receipt of a SUBSCRIBE request, 934 uses XCAP and the RLS services document to guide its operation. 936 When an RLS receives a SUBSCRIBE request for a URI (present in the 937 Request URI), it obtains the element whose uri attribute 938 matches (based on URI equality) the URI in the SUBSCRIBE request. 939 This document makes no normative statements on how this might be 940 accomplished. The following paragraph provides one possible 941 approach. 943 The RLS canonicalizes the Request URI as described in Section 5. It 944 then performs an XCAP GET operation against the URI formed by 945 combining the XCAP root with the document selector of the global 946 index with a node selector of the form 947 "rls-services/service[@uri=]", where 948 is the canonicalized version of the Request URI. If the response is 949 a 200 OK, it will contain the service definition for that URI. 951 Once the element has been obtained, it is examined. If the 952 element is present, and the event package in the SUBSCRIBE 953 request is not amongst those listed in the elements within 954 , the request MUST be rejected with a 489 (Bad Event) 955 response code, as described in [14]. Otherwise, it SHOULD be 956 processed. The next step is to authorize that the client is allowed 957 to subscribe to the resource. This can be done using the data 958 defined in [13], for example. Assuming the subscriber is authorized 959 to subscribe to that resource, the subscription is processed 960 according to the procedures defined in [15]. This processing 961 requires the RLS to compute a flat list of URIs that are to be 962 subscribed to. If the element had a element, it is 963 extracted. If the element had a element, 964 its URI content is dereferenced. The result should be a 965 element. If it is not, the request SHOULD be rejected with a 502 966 (Bad Gateway). Otherwise, that element is extracted. 968 At this point the RLS has a element in its possession. The 969 next step is to obtain a flat list of URIs from this element. To do 970 that, it traverses the tree of elements rooted in the element. 971 Before traversal begins, the RLS initializes two lists - the "flat 972 list", which will contain the flat list of URI after traversal, and 973 the "traversed list", which contains a list of HTTP URIs in 974 elements that have already been visited. Once these lists 975 are initialized, tree traversal begins. A server can use any 976 tree-traversal ordering it likes, such as depth first search or 977 breadth first search. The processing at each element in the tree 978 depends on the name of the element: 980 o If the element is the URI in the "uri" attribute of the 981 element is added to the flat list if it is not already present 982 (based on case sensitive string equality) in that list, and the 983 URI scheme represents one that can be used to service 984 subscriptions, such as SIP [4] and pres [16]. 986 o If the element is an , the relative path reference 987 making up the value of the "ref" attribute is resolved into an 988 absolute URI. This is done using the procedures defined in 989 Section 5.2 of RFC 3986 [7], using the XCAP root of the RLS 990 services document as the base URI. This absolute URI is resolved. 991 If the result is not a 200 OK containing a element, the 992 SUBSCRIBE request SHOULD be rejected with a 502 (Bad Gateway). 993 Otherwise, the element returned is processed as described 994 in the previous step. 996 o If the element is an element, the absolute URI making 997 up the value of the "anchor" attribute of the element is examined. 998 If the URI is on the traversed list, the server MUST cease 999 traversing the tree, and SHOULD reject the SUBSCRIBE request with 1000 a 502 (Bad Gateway). If the URI is not on the traversed list, the 1001 server adds the URI to the traversed list, and de-references the 1002 URI. If the result is not a 200 OK containing an element, 1003 the SUBSCRIBE request SHOULD be rejected with a 502 (Bad Gateway). 1004 Otherwise, the RLS replaces the element in its local 1005 copy of the tree with the element that was returned, and 1006 tree traversal continues. 1008 Because the element is used to dynamically construct the 1009 tree, there is a posibility of recursive evaluation of references. 1010 The traversed list is used to prevent this from happening. 1012 Once the tree has been traversed, the RLS can create virtual 1013 subscriptions to each URI in the flat list, as defined in [15]. 1015 In the processing steps outlined above, when an or 1016 element contains a reference that cannot be resolved, 1017 failing the request is at SHOULD strength. In some cases, an RLS may 1018 provide better service by creating virtual subscriptions to the URIs 1019 in the flat list that could be obtained, omitting those that could 1020 not. Only in those cases should the SHOULD recommendation be 1021 ignored. 1023 5. SIP URI Canonicalization 1025 This section provides a technique for URI canonicalization. This 1026 canonicalization produces a URI that, in most cases, is equal to the 1027 original URI (where equality is based on the URI comparison rules in 1028 RFC 3261). Furthermore, the canonicalized URI will usually be 1029 lexically equivalent to the canonicalized version of any other URI 1030 equal to the original. 1032 To canonicalize the URI, the following steps are followed: 1034 1. First, the domain part of the URI is converted into all 1035 lowercase, and any tokens (such as "user" or "transport" or 1036 "udp") are converted to all lowercase. 1038 2. Secondly, the URI is un-escape coded. Then, it is re-coded. 1039 However, when it is recoded, the only characters that are coded 1040 are those which are not permitted to appear based on the grammar 1041 of that portion of the URI. For example, if a SIP URI is 1042 sip:%6aoe%20smith@example.com, it is decoded to sip:joe 1043 smith@example.com and the re-coded to 1044 sip:joe%20smith@example.com. In the original URI, the character 1045 'j' was escape coded. This is allowed, but not required, since 1046 the grammar allows a 'j' to appear in the user part. As a 1047 result, it appears as 'j' after this step of canonicalization. 1049 3. Thirdly, any URI parameters are reordered so that they appear in 1050 lexical order based on parameter name. The ordering of a 1051 character is determined by the US-ASCII numerical value of that 1052 character, with smaller numbers coming first. Parameters are 1053 ordered with the leftmost character as most significant. For 1054 parameters that contain only letters, this is equivalent to an 1055 alphabetical ordering. 1057 4. Finally, any header parameters are discarded. This canonicalized 1058 URI is used instead of the original URI. 1060 If two URIs A and B are functionally equal (meaning that they are 1061 equal according to the URI comparison rules in RFC 3261), their 1062 canonicalized URIs are equal under case sensitive string comparison 1063 if the following are true: 1065 o Neither URI contains header parameters 1067 o If one of the URI contains a URI parameter not defined in RFC 1068 3261, the other does as well. 1070 6. Extensibility 1072 Resource-lists and RLS services documents are meant to be extended. 1073 An extension takes place by defining a new set of elements in a new 1074 namespace, governed by a new schema. Every extension MUST have an 1075 appropriate XML namespace assigned to it. The XML namespace of the 1076 extension MUST be different from the namespaces defined in this 1077 specification. The extension MUST NOT change the syntax or semantics 1078 of the schemas defined in this document. All XML tags and attributes 1079 that are part of the extension MUST be appropriately qualified so as 1080 to place them within that namespace. 1082 This specification defines explict places where new elements or 1083 attributes from an extension can be placed. These are explicitly 1084 indicated in the schemas by the and elements. 1085 Extensions to this specification MUST specify where their elements 1086 can be placed within the document. 1088 As a result, a document that contains extensions will require 1089 multiple schemas in order to determine its validity - a schema 1090 defined in this document, along with those defined by extensions 1091 present in the document. Because extensions occur by adding new 1092 elements and attributes governed by new schemas, the schemas defined 1093 in this document are fixed and would only be changed by a revision to 1094 this specification. Such a revision, should it take place, would 1095 endeavor to allow documents compliant to the previous schema to 1096 remain compliant to the new one. As a result, the schemas defined 1097 here don't provide explicit schema versions, as this is not expected 1098 to be needed. 1100 7. Security Considerations 1102 The information contained in rls-services and resource-lists 1103 documents are particularly sensitive. It represents the principle 1104 set of people with whom a user would like to communicate. As a 1105 result, clients SHOULD use TLS when contacting servers in order to 1106 fetch this information. Note that this does not represent a change 1107 in requirement strength from XCAP. 1109 8. IANA Considerations 1111 There are several IANA considerations associated with this 1112 specification. 1114 8.1 XCAP Application Unique IDs 1116 This section registers two new XCAP Application Unique ID (AUID) 1117 according to the IANA procedures defined in [10]. 1119 8.1.1 resource-lists 1120 Name of the AUID: resource-lists 1122 Description: A resource lists application is any application that 1123 needs access to a list of resources, identified by a URI, to which 1124 operations, such as subscriptions, can be applied. 1126 8.1.2 rls-services 1128 Name of the AUID: rls-services 1130 Description: An Resource List Server (RLS) services application is 1131 Session Initiation Protocol (SIP) application whereby a server 1132 receives SIP SUBSCRIBE requests for resource, and generates 1133 subscriptions towards the a resource list. 1135 8.2 MIME Type Registrations 1137 This specification requests the registration of two new MIME types 1138 according to the procedures of RFC 2048 [9] and guidelines in RFC 1139 3023 [5]. 1141 8.2.1 application/resource-lists+xml 1143 MIME media type name: application 1145 MIME subtype name: resource-lists+xml 1147 Mandatory parameters: none 1149 Optional parameters: Same as charset parameter application/xml as 1150 specified in RFC 3023 [5]. 1152 Encoding considerations: Same as encoding considerations of 1153 application/xml as specified in RFC 3023 [5]. 1155 Security considerations: See Section 10 of RFC 3023 [5] and 1156 Section 7 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace 1157 XXXX with the RFC number of this specification]]. 1159 Interoperability considerations: none. 1161 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: 1162 Please replace XXXX with the RFC number of this specification]] 1163 Applications which use this media type: This document type has 1164 been used to support subscriptions to lists of users [15] for 1165 SIP-based presence [12]. 1167 Additional Information: 1169 Magic Number: None 1171 File Extension: .rl 1173 Macintosh file type code: "TEXT" 1175 Personal and email address for further information: Jonathan 1176 Rosenberg, jdrosen@jdrosen.net 1178 Intended usage: COMMON 1180 Author/Change controller: The IETF. 1182 8.2.2 application/rls-services+xml 1184 MIME media type name: application 1186 MIME subtype name: rls-services+xml 1188 Mandatory parameters: none 1190 Optional parameters: Same as charset parameter application/xml as 1191 specified in RFC 3023 [5]. 1193 Encoding considerations: Same as encoding considerations of 1194 application/xml as specified in RFC 3023 [5]. 1196 Security considerations: See Section 10 of RFC 3023 [5] and 1197 Section 7 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace 1198 XXXX with the RFC number of this specification]]. 1200 Interoperability considerations: none. 1202 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: 1203 Please replace XXXX with the RFC number of this specification]] 1205 Applications which use this media type: This document type has 1206 been used to support subscriptions to lists of users [15] for 1207 SIP-based presence [12]. 1209 Additional Information: 1211 Magic Number: None 1213 File Extension: .rs 1215 Macintosh file type code: "TEXT" 1217 Personal and email address for further information: Jonathan 1218 Rosenberg, jdrosen@jdrosen.net 1220 Intended usage: COMMON 1222 Author/Change controller: The IETF. 1224 8.3 URN Sub-Namespace Registrations 1226 This section registers two new XML namespace, as per the guidelines 1227 in RFC 3688 [8]. 1229 8.3.1 urn:ietf:params:xml:ns:resource-lists 1231 URI: The URI for this namespace is 1232 urn:ietf:params:xml:ns:resource-lists. 1234 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1235 Jonathan Rosenberg (jdrosen@jdrosen.net). 1237 XML: 1239 BEGIN 1240 1241 1243 1244 1245 1247 Resource Lists Namespace 1248 1249 1250

Namespace for Resource Lists

1251

urn:ietf:params:xml:ns:resource-lists

1252

See RFCXXXX [NOTE 1253 TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this 1254 specification.].

1255 1256 1257 END 1259 8.3.2 urn:ietf:params:xml:ns:rls-services 1261 URI: The URI for this namespace is 1262 urn:ietf:params:xml:ns:rls-services. 1264 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1265 Jonathan Rosenberg (jdrosen@jdrosen.net). 1267 XML: 1269 BEGIN 1270 1271 1273 1274 1275 1277 Resource List Server (RLS) Services Namespace 1278 1279 1280

Namespace for Resource List Server (RLS) Services

1281

urn:ietf:params:xml:ns:rls-services

1282

See RFCXXXX [NOTE 1283 TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this 1284 specification.].

1285 1286 1287 END 1289 8.4 Schema Registrations 1291 This section registers two XML schemas per the procedures in [8]. 1293 8.4.1 urn:ietf:params:xml:schema:resource-lists 1295 URI: urn:ietf:params:xml:schema:resource-lists 1297 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1298 Jonathan Rosenberg (jdrosen@jdrosen.net). 1300 The XML for this schema can be found as the sole content of 1301 Section 3.2. 1303 8.4.2 urn:ietf:params:xml:schema:rls-services 1305 URI: urn:ietf:params:xml:schema:rls-services 1307 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1308 Jonathan Rosenberg (jdrosen@jdrosen.net). 1310 The XML for this schema can be found as the sole content of 1311 Section 4.2. 1313 9. Acknowledgements 1315 The authors would like to thank Hisham Khartabil, Jari Urpalainen and 1316 Spencer Dawkins for their comments and input. Thanks to Ted Hardie 1317 for his encouragement and support of this work. 1319 10. References 1321 10.1 Normative References 1323 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1324 Levels", BCP 14, RFC 2119, March 1997. 1326 [2] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 1327 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 1328 FirstEdition REC-xml-20001006, October 2000. 1330 [3] Moats, R., "URN Syntax", RFC 2141, May 1997. 1332 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1333 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1334 Session Initiation Protocol", RFC 3261, June 2002. 1336 [5] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 1337 3023, January 2001. 1339 [6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1340 August 1999. 1342 [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1343 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 1344 January 2005. 1346 [8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1347 January 2004. 1349 [9] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet 1350 Mail Extensions (MIME) Part Four: Registration Procedures", BCP 1351 13, RFC 2048, November 1996. 1353 [10] Rosenberg, J., "The Extensible Markup Language (XML) 1354 Configuration Access Protocol (XCAP)", 1355 draft-ietf-simple-xcap-05 (work in progress), November 2004. 1357 10.2 Informative References 1359 [11] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 1360 Instant Messaging", RFC 2778, February 2000. 1362 [12] Rosenberg, J., "A Presence Event Package for the Session 1363 Initiation Protocol (SIP)", RFC 3856, August 2004. 1365 [13] Rosenberg, J., "Presence Authorization Rules", 1366 draft-ietf-simple-presence-rules-01 (work in progress), October 1367 2004. 1369 [14] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1370 Notification", RFC 3265, June 2002. 1372 [15] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation 1373 Protocol (SIP) Event Notification Extension for Resource 1374 Lists", draft-ietf-simple-event-list-07 (work in progress), 1375 January 2005. 1377 [16] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, 1378 August 2004. 1380 Author's Address 1382 Jonathan Rosenberg 1383 Cisco Systems 1384 600 Lanidex Plaza 1385 Parsippany, NJ 07054 1386 US 1388 Phone: +1 973 952-5000 1389 EMail: jdrosen@cisco.com 1390 URI: http://www.jdrosen.net 1392 Intellectual Property Statement 1394 The IETF takes no position regarding the validity or scope of any 1395 Intellectual Property Rights or other rights that might be claimed to 1396 pertain to the implementation or use of the technology described in 1397 this document or the extent to which any license under such rights 1398 might or might not be available; nor does it represent that it has 1399 made any independent effort to identify any such rights. Information 1400 on the procedures with respect to rights in RFC documents can be 1401 found in BCP 78 and BCP 79. 1403 Copies of IPR disclosures made to the IETF Secretariat and any 1404 assurances of licenses to be made available, or the result of an 1405 attempt made to obtain a general license or permission for the use of 1406 such proprietary rights by implementers or users of this 1407 specification can be obtained from the IETF on-line IPR repository at 1408 http://www.ietf.org/ipr. 1410 The IETF invites any interested party to bring to its attention any 1411 copyrights, patents or patent applications, or other proprietary 1412 rights that may cover technology that may be required to implement 1413 this standard. Please address the information to the IETF at 1414 ietf-ipr@ietf.org. 1416 Disclaimer of Validity 1418 This document and the information contained herein are provided on an 1419 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1420 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1421 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1422 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1423 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1424 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1426 Copyright Statement 1428 Copyright (C) The Internet Society (2005). This document is subject 1429 to the rights, licenses and restrictions contained in BCP 78, and 1430 except as set forth therein, the authors retain all their rights. 1432 Acknowledgment 1434 Funding for the RFC Editor function is currently provided by the 1435 Internet Society.