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

Namespace for Resource Lists

1237

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

1238

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

1241 1242 1243 END 1245 8.3.2 urn:ietf:params:xml:ns:rls-services 1247 URI: The URI for this namespace is 1248 urn:ietf:params:xml:ns:rls-services. 1250 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1251 Jonathan Rosenberg (jdrosen@jdrosen.net). 1253 XML: 1255 BEGIN 1256 1257 1259 1260 1261 1263 Resource List Server (RLS) Services Namespace 1264 1265 1266

Namespace for Resource List Server (RLS) Services

1267

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

1268

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

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