idnits 2.17.1 draft-ietf-simple-xcap-list-usage-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1286. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1302), 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 (July 17, 2004) is 7216 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 1225, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1247, 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-02 == 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-04 Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIMPLE J. Rosenberg 2 Internet-Draft dynamicsoft 3 Expires: January 15, 2005 July 17, 2004 5 Extensible Markup Language (XML) Formats for Representing Resource 6 Lists 7 draft-ietf-simple-xcap-list-usage-03 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 January 15, 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 presence list service. If a user sends a Session 44 Initiation Protocol (SIP) SUBSCRIBE message to the URI representing 45 the presence list service, the server will obtain the presence 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 created and managed with the XML Configuration Access 53 Protocol (XCAP). 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3. Resource Lists Documents . . . . . . . . . . . . . . . . . . . 7 60 3.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 3.3 Example Document . . . . . . . . . . . . . . . . . . . . . 11 63 3.4 Usage with XCAP . . . . . . . . . . . . . . . . . . . . . 12 64 3.4.1 Application Unique ID . . . . . . . . . . . . . . . . 12 65 3.4.2 MIME Type . . . . . . . . . . . . . . . . . . . . . . 12 66 3.4.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . 12 67 3.4.4 Additional Constraints . . . . . . . . . . . . . . . . 13 68 3.4.5 Data Semantics . . . . . . . . . . . . . . . . . . . . 13 69 3.4.6 Naming Conventions . . . . . . . . . . . . . . . . . . 13 70 3.4.7 Resource Interdependencies . . . . . . . . . . . . . . 14 71 3.4.8 Authorization Policies . . . . . . . . . . . . . . . . 14 72 4. RLS Services Documents . . . . . . . . . . . . . . . . . . . . 15 73 4.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . 15 74 4.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 4.3 Example Document . . . . . . . . . . . . . . . . . . . . . 17 76 4.4 Usage with XCAP . . . . . . . . . . . . . . . . . . . . . 18 77 4.4.1 Application Unique ID . . . . . . . . . . . . . . . . 18 78 4.4.2 MIME Type . . . . . . . . . . . . . . . . . . . . . . 18 79 4.4.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . 18 80 4.4.4 Additional Constraints . . . . . . . . . . . . . . . . 18 81 4.4.5 Data Semantics . . . . . . . . . . . . . . . . . . . . 19 82 4.4.6 Naming Conventions . . . . . . . . . . . . . . . . . . 19 83 4.4.7 Resource Interdependencies . . . . . . . . . . . . . . 20 84 4.4.8 Authorization Policies . . . . . . . . . . . . . . . . 22 85 4.5 Usage of an RLS Services Document by an RLS . . . . . . . 23 86 5. SIP URI Canonicalization . . . . . . . . . . . . . . . . . . . 25 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 89 7.1 XCAP Application Usage IDs . . . . . . . . . . . . . . . . 27 90 7.1.1 resource-lists . . . . . . . . . . . . . . . . . . . . 27 91 7.1.2 rls-services . . . . . . . . . . . . . . . . . . . . . 27 92 7.2 MIME Type Registrations . . . . . . . . . . . . . . . . . 27 93 7.2.1 application/resource-lists+xml . . . . . . . . . . . . 27 94 7.2.2 application/rls-services+xml . . . . . . . . . . . . . 28 95 7.3 URN Sub-Namespace Registrations . . . . . . . . . . . . . 28 96 7.3.1 urn:ietf:params:xml:ns:resource-lists . . . . . . . . 28 97 7.3.2 urn:ietf:params:xml:ns:rls-services . . . . . . . . . 29 98 7.4 Schema Registrations . . . . . . . . . . . . . . . . . . . 30 99 7.4.1 urn:ietf:params:xml:schema:resource-lists . . . . . . 30 100 7.4.2 urn:ietf:params:xml:schema:rls-services . . . . . . . 30 101 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 102 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 31 103 8.2 Informative References . . . . . . . . . . . . . . . . . . . 31 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 32 105 Intellectual Property and Copyright Statements . . . . . . . . 33 107 1. Introduction 109 The Session Initiation Protocol (SIP) [4] defines the SIP Uniform 110 Resource Identifier (URI) as any resource to which a SIP request can 111 be generated for the purposes of establishing some form of 112 communications operation. These URIs can represent users (for 113 example, sip:joe@example.com). The SIP URI can also represent a 114 service, such as voicemail, conferencing, or a presence list. A 115 common pattern across such SIP services is that the service is 116 defined, and associated with a URI. In order to operate, that 117 service needs to make use of a list of users (or, more generally, a 118 list of resources). When a SIP request is sent to the service URI, 119 the server providing the service reads that list, and then performs 120 some kind of operation against each resource on the list. This is 121 shown pictorially in Figure 1. 123 /---\ 124 | | 125 \---/ Resource 126 +----| | List 127 | | | 128 | \---/ 129 | 130 | 131 | 132 | 133 V 134 +-------------+ 135 | | --------> 136 | SIP | 137 ---------------> | Service | --------> 138 service | | 139 URI | | --------> 140 +-------------+ 142 Figure 1 144 One important example of such a service is a presence [12] list 145 service. A presence list service allows a client to generate a SIP 146 SUBSCRIBE request to ask for presence information for a list of 147 users. The presence list server obtains the presence for the users 148 on the list, and provides them back to the client. A presence list 149 server is a specific case of a resource list server (RLS) [15], which 150 allows a client to generate a SIP SUBSCRIBE request to ask for 151 notifications of SIP events for a list of resources. 153 Another example of such a service is an instant conference service. 154 If a client sends a SIP INVITE request to the URI representing the 155 instance conference service, the conference server will create a 156 conference call containing the client and the associated group of 157 users. 159 It is very useful for a user of these systems to define the groups of 160 users or resources (generally called a resource list) separately from 161 the services which access those resource lists. Indeed, there are 162 usages for resource lists even in the absence of any associated 163 network-based service. As an example, rather than using a presence 164 list service, a client might generate individual SUBSCRIBE requests 165 to obtain the presence of each user in a locally stored presence 166 list. In such a case, there is a need for a format for storing the 167 list locally on disk. Furthermore, the user might wish to share the 168 list with friends, and desire to email it to those friends. This 169 also requires a standardized format for the resource list. 171 As such, this document defines two Extensible Markup Language (XML) 172 document formats. The first is used to represent resource lists, 173 independent of any particular service. The second is used to define 174 service URIs for an RLS, and to associate a resource list with the 175 service URI. This document also defines an XML Configuration Access 176 Protocol (XCAP) [10] application usage for managing each of these two 177 documents. 179 2. Terminology 181 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 182 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 183 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 184 indicate requirement levels for compliant implementations. 186 3. Resource Lists Documents 188 3.1 Structure 190 A resource lists document is an XML [2] document that MUST be 191 well-formed and SHOULD be valid. Resource lists documents MUST be 192 based on XML 1.0 and MUST be encoded using UTF-8. This specification 193 makes use of XML namespaces for identifying resource lists documents 194 and document fragments. The namespace URI for elements defined by 195 this specification is a URN [3], using the namespace identifier 196 'ietf' defined by RFC 2648 [6] and extended by RFC 3688 [8]. This 197 URN is: 198 urn:ietf:params:xml:ns:resource-lists 200 A resource lists document has the element as the 201 root element of the document. This element has no attributes. Its 202 content is a sequence of one or more elements, each of which 203 defines a single resource list. 205 Each element can contain an optional "name" attribute. This 206 attribute is a handle for the list. When present, it MUST be unique 207 amongst all other elements within the same parent element. 209 Each element is composed of an optional display name, a 210 sequence of zero or more elements, each of which may be an 211 element, a element, an element, or an 212 element, followed by any number of elements from other namespaces, 213 for the purposes of extensibility. The ability of a element 214 to contain other elements means that a resource list can be 215 hierarchically structured. The then allows for a 216 human-friendly name to be associated with each level in the 217 hierarchy. An element describes a single resource, defined 218 by a URI, that is part of the list. An element allows an 219 entry in a document within the same XCAP root to be included by 220 reference, rather than by value. An element contains a 221 reference to a list stored on this or another server. 223 The element describes a single resource. The element 224 has a single mandatory attribute, "uri". This attribute is equal to 225 the URI that is used to access the resource. The resource list 226 format itself does not constrain the type of URI that can be used. 227 However, the service making use of the resource list may require 228 specific URI schemes. For example, RLS services will require URIs 229 that represent subscribeable resources. This includes the SIP and 230 pres [16] URIs. The "uri" attribute MUST be unique amongst all other 231 "uri" attributes in elements within the same parent. 232 Uniqueness is determined by case sensitive string comparisons. As 233 such, it is possible that two "uri" attributes will have the same URI 234 when compared using the functional equality rules defined for that 235 URI scheme, but different ones when compared using case sensitive 236 string comparison. 238 The element contains a sequence elements that provide 239 information about the entry. Only one such element is defined at 240 this time, which is . This element provides a UTF-8 241 encoded string, meant for consumption by a human user, that describes 242 the resource. Unlike the "name" attribute of the element, 243 the has no uniqueness requirements. The 244 element can contain the "xml:lang" attribute, which 245 provides the language of the display name. The element can 246 contain other elements from other namespaces. This is meant to 247 support the inclusion of other information about the entry, such as a 248 phone number or postal address. 250 The 256 elements within the same parent. Uniqueness is determined by case 257 sensitive string comparisons. The content of an element 258 is an optional display name, followed by any number of elements from 259 other namespaces, for the purposes of extensibility. The display 260 name is useful for providing a localized nickname as an alternative 261 to the name defined in the to which the refers. 263 The content of the "ref" attribute is a relative HTTP URL [7]. 264 Specifically, it MUST be a relative path reference, where the base 265 URL is equal to the XCAP root URI of the document in which the 266 appears. This relative URL, if resolved into an absolute 267 URL according to the procedures in RFC 2396, MUST resolve to an 268 element within a resource-lists document. For example, if an 269 element within a specific XCAP root was identified by the 270 following HTTP URL: 272 http://xcap.example.com/root/resource-lists/users/bill/ 273 mylist/~~/resource-lists/list%5b@name=%22list1%22%5d/ 274 entry%5b@uri=%22sip:petri@example.com%22%5d 276 If http://xcap.example.com/root is the XCAP root URI, then an 277 element pointing to this entry would have the form: 279 283 Note that line folding within the HTTP URL and XML attribute above 284 are the purposes of readability only. Also note that, as described 285 in RFC 2396, the relative path URI does not begin with the "/". 286 Since the relative URL used within the "ref" attribute must be a 287 relative path URL, the "/" will never be present as the first 288 character within the content of a "ref" attribute. Since the content 289 of the "ref" attribute is a valid HTTP URL, it must be escape encoded 290 within the XML document. 292 The element is similar to the element. Like 293 , it is only meaningful in documents obtained from an XCAP 294 server. It too is a reference to content stored elsewhere. However, 295 it refers to an entire list, and furthermore, allows that list to be 296 present on another server. The element has a single 297 mandatory attribute, "anchor". The "anchor" attribute MUST be unique 298 amongst all other "anchor" attributes in elements within 299 the same parent. Uniqueness is determined by case sensitive string 300 comparisons. The content of an element is an optional 301 followed by any number of elements from another 302 namespace, for the purposes of extensibility. The value of the 303 "anchor" attribute MUST be an absolute HTTP URL. This URL MUST 304 identify an XCAP resource, and in particular, it MUST represent a 305 element within a resource lists document. The URL MUST be 306 escape coded. 308 For both the and elements, the responsibility 309 of resolving their references falls upon the entity that is making 310 use of the document. When used in conjunction with XCAP, this means 311 that the burden falls on the XCAP client. If the XCAP client is a PC 312 based application using the resource-lists document as a presence 313 list, the references would likely be resolved upon explicit request 314 by the user. They can, of course, be resolved at any time. If the 315 XCAP client is an RLS itself, the references would be resolved when 316 the RLS receives a SUBSCRIBE request for an RLS service associated 317 with a resource list that contains one of these references (see 318 below). An XCAP server defined by this specification will not 319 attempt to resolve the references before returning the document to 320 the client. Similarly, if, due to network errors or some other 321 problem, the references cannot be resolved, the handling is specific 322 to the usage of the document. For resource lists being used by RLS 323 services, the handling is discussed below. 325 3.2 Schema 326 327 332 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 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 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 401 3.3 Example Document 403 The following is an example of a document compliant to the schema. 404 All line feeds within element content is for display purposes only. 406 407 409 410 411 Bill Doe 412 413 415 416 Close Friends 417 418 Joe Smith 419 420 421 Nancy Gross 422 423 425 Marketing 426 427 428 429 431 3.4 Usage with XCAP 433 Resource lists documents can be manipulated with XCAP. This section 434 provides the details necessary for such a usage. 436 3.4.1 Application Unique ID 438 XCAP requires application usages to define a unique application usage 439 ID (AUID) in either the IETF tree or a vendor tree. This 440 specification defines the "resource-lists" AUID within the IETF tree, 441 via the IANA registration in Section 7. 443 3.4.2 MIME Type 445 The MIME type for this document is "application/resource-lists+xml". 447 3.4.3 XML Schema 449 The XML Schema for this document is defined as the sole content of 450 Section 3.2. 452 3.4.4 Additional Constraints 454 In addition to the schema, there are constraints on the values 455 present in the the "name" attribute of the element, the "uri" 456 attribute of the element, the "ref" attribute of the 457 element and the "anchor" attribute of the 458 element. These constraints are defined in Section 3.1. Some of 459 these constraints are enforced by the XCAP server. Those constraints 460 are: 461 o The "name" attribute in a element MUST be unique amongst 462 all other "name" attributes of elements within the same 463 parent element. 464 o The "uri" attribute in a element MUST be unique amongst 465 all other "uri" attributes of elements within the same 466 parent element. Uniqueness is determined by case sensitive string 467 comparison. 468 o The URI in the "ref" attribute of the element MUST be 469 unique amongst all other "ref" attributes of elements 470 within the same parent element. Uniqueness is determined by case 471 sensitive string comparison. The value of the attribute MUST be a 472 relative path reference. Note that the server is not responsible 473 for verifying that the reference resolves to an element in 474 a document within the same XCAP root. 475 o The URI in the "anchor" attribute of the element MUST 476 be unique amongst all other "anchor" attributes of 477 elements within the same parent element. Uniqueness is determined 478 by case sensitive string comparison. The value of the attribute 479 MUST be an absolute HTTP URL. Note that the server is not 480 responsible for verifying that the URL resolves to a 481 element in a document. Indeed, since the URL may reference a 482 server in another domain, referential integrity cannot be 483 guaranteed without adding substantial complexity to the system. 485 3.4.5 Data Semantics 487 Semantics for the document content are provided in Section 3.1. 489 3.4.6 Naming Conventions 491 Resource lists documents are usually identified as references from 492 other application usages. For example, an RLS services document 493 contains a reference to the resource list it uses. 495 Frequently, an XCAP client will wish to insert or remove an , 496 or element from a document without having a 497 cached copy of that document. In such a case, the "uri" attribute of 498 the element, the "ref" attribute of the element 499 or the "anchor" attribute of the element is used as an 500 index to select the element to operate upon. The XCAP server will 501 determine uniqueness by case sensitive string comparison. However, 502 each of these attributes contain URIs, and the URI equality rules for 503 their schemes may allow for two URI to be the same, even if they are 504 different by case sensitive string comparison. As such, it is 505 possible that a client will attempt a PUT or DELETE in an attempt to 506 modify or remove an existing element, but instead, the PUT ends up 507 inserting a new element, or the DELETE ends up returning an error 508 response. 510 To mitigate against this case, if the client knows that the user 511 intent is to explicitly modify an existing element, as opposed to 512 creating a new one, the client SHOULD make the request conditional, 513 using an If-None-Match header field with a value of *. This will 514 cause the request to fail if it is not a replacement. 516 If the XCAP client cannot determine whether the user intent is to 517 create or replace, the client SHOULD canonicalize the URI before 518 performing the operation. For a SIP URI (often present in the "uri" 519 attribute of the element), this canonicalization procedure is 520 defined in Section 5. We expect that the SIP URIs that will be 521 placed into resource lists documents will usually be of the form 522 sip:user@domain, and possibly include a user parameter. The 523 canonicalization rules work perfectly for these URIs. 525 For HTTP URLs, a basic canonicalization algorithm is as follows. If 526 the the port in the URL is equal to the default port (80 for http 527 URLs), the port is removed. The hostname is converted to all 528 lowercase. Any characters that are escape encoded are un-escaped, 529 and only re-escaped if they cannot be represented within their 530 component of the URL. 532 3.4.7 Resource Interdependencies 534 There are no resource interdependencies identified by this 535 application usage. 537 3.4.8 Authorization Policies 539 This application usage does not modify the default XCAP authorization 540 policy, which is that only a user can read, write or modify their own 541 documents. A server can allow priveleged users to modify documents 542 that they don't own, but the establishment and indication of such 543 policies is outside the scope of this document. It is anticipated 544 that a future application usage will define which users are allowed 545 to modify a list resource. 547 4. RLS Services Documents 549 4.1 Structure 551 An RLS services document is used to define URIs that represent 552 services provided by a Resource List Server (RLS) as defined in [15]. 553 An RLS services document is an XML [2] document that MUST be 554 well-formed and SHOULD be valid. RLS services documents MUST be 555 based on XML 1.0 and MUST be encoded using UTF-8. This specification 556 makes use of XML namespaces for identifying RLS services documents 557 and document fragments. The namespace URI for elements defined by 558 this specification is a URN [3], using the namespace identifier 559 'ietf' defined by RFC 2648 [6] and extended by RFC 3688 [8]. This 560 URN is: 561 urn:ietf:params:xml:ns:rls-services 563 The root element of an rls-services document is . It 564 contains a sequence of elements, each of which defines a 565 service available at an RLS. 567 Each element has a single mandatory attribute, "uri". This 568 URI defines the resource associated with the service. That is, if a 569 client subscribes to that URI, they will obtain the service defined 570 by the corresponding element. The element 571 contains child elements that define the service. For an RLS service, 572 very little service definition is needed - just the resource list to 573 which the server will perform virtual subscriptions [15] and the set 574 of event packages that the service supports. The former can be 575 conveyed in one of two ways. There can be a element, 576 which points to a element in a resource-lists document, or 577 there can be a element, which includes the resource list 578 directly. The supported packages are contained in the 579 element. The element can also contain elements from other 580 namespaces, for the purposes of extensibility. 582 By including the contents of the resource list directly, a user can 583 create lists and add members to them with a single XCAP operation. 584 However, the resulting list becomes "hidden" within the RLS service 585 definition, and is not usable by other application usages. For this 586 reason, the element exists as an alternative. It can 587 reference a element in a resource-lists document. Since the 588 list is separated from the service definition, it can be easily 589 reused by other application usages. 591 The element is of the list type defined by the schema for 592 resource lists. It is discussed in Section 3.1. 594 The element contains a URI. This element is only 595 meaningful when the document was obtained through XCAP. The URI MUST 596 be an absolute HTTP URL representing an XCAP element resource. Its 597 XCAP root MUST be the same as the XCAP root of the RLS services 598 document. When the RLS services document in present in a user's home 599 directory, the HTTP URL MUST exist underneath the same user's home 600 directory in the resource-lists application usage. When the RLS 601 services document is in the global directory, the HTTP URL MUST exist 602 underneath any user's home directory in the resource-lists 603 application usage. In either case, the element referenced by the URI 604 MUST be a element within a resource-lists document. All of 605 these constraints except for the latter one (which is a referential 606 integrity constraint) will be enforced by the XCAP server. 608 The element contains a sequence of elements. 609 The content of each element is the name of a SIP event 610 package [14]. The element may also contain elements from 611 additional namespaces, for the purposes of extensibility. The 612 element is optional. When not present, it means that the 613 RLS service will accept subscriptions for any event package. 615 4.2 Schema 616 617 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 640 641 642 643 644 645 646 648 649 650 651 652 653 655 4.3 Example Document 657 This document shows two services. One is sip:mybuddies@example.com, 658 and the other is sip:marketing@example.com. The former service 659 references a resource list in a resource-lists document, and the 660 latter one includes a list locally. Both services are for the 661 presence event package only. 663 664 667 668 http://xcap.example.com/resource-lists/users/joe/index/~~/ 669 resource-lists/list%5b@name=%22l1%22%5d 670 671 presence 672 673 674 675 676 677 678 679 680 presence 681 682 683 685 4.4 Usage with XCAP 687 RLS services documents can be manipulated with XCAP. This section 688 provides the details necessary for such a usage. 690 4.4.1 Application Unique ID 692 XCAP requires application usages to define a unique application usage 693 ID (AUID) in either the IETF tree or a vendor tree. This 694 specification defines the "rls-services" AUID within the IETF tree, 695 via the IANA registration in Section 7. 697 4.4.2 MIME Type 699 The MIME type for this document is "application/rls-services+xml". 701 4.4.3 XML Schema 703 The XML Schema for this document is defined as the sole content of 704 Section 4.2. 706 4.4.4 Additional Constraints 708 In addition to the schema, there are constraints on the URIs present 709 in the and elements. These constraints are 710 defined in Section 3.1. Some of these constraints are enforced by 711 the XCAP server. Those constraints are: 712 o The URI in the "uri" attribute of the element MUST be 713 unique amongst all other URIs in "uri" elements in any 714 element in any document on a particular server. This uniqueness 715 constraint spans across XCAP roots. Furthermore, the URI MUST NOT 716 correspond to an existing resource within the domain of the URI. 717 If a server is asked to set the URI to something that already 718 exists, the server MUST reject the request with a 409, and use the 719 mechanisms defined in [10] to suggest alternate URIs that have not 720 yet been allocated. 721 o The URI in a element MUST be an absolute URI. The 722 server MUST verify that the URI path contains "resource-lists" in 723 the path segment corresponding to the AUID. If the RLS services 724 document is within the XCAP user tree (as opposed to the global 725 tree), the server MUST verify that the XUI in the path is the same 726 as the XUI in the URI of to the RLS services document. These 727 checks are made by examining the URI value, as opposed to 728 de-referencing the URI. The server is not responsible for 729 verifying that the URI actually points to a element within 730 a valid resource lists document. 731 o In addition, an RLS services document can contain a 732 element, which in turn can contain , and 733 elements. The constraints defined for these elements 734 in Section 3.4.6 MUST be enforced. 735 o In some cases, an XCAP client will wish to create a new RLS 736 service, and wish to assign it a "vanity URI", such as 737 sip:friends@example.com. However, the client does not know 738 whether this URI meets the uniqueness constraints defined above. 739 In that case, it can simply attempt the creation operation, and if 740 the result is a 409 that contains a detailed conflict report with 741 the element, the client knows that the URI 742 could not be assigned. It can then retry with a different vanity 743 URI, or use one of the suggestions in the detailed conflict 744 report. 745 o If the client wishes to create a new RLS service, and it doesnt 746 care what the URI is, the client creates a random one, and 747 attempts the creation operation. As discussed in [10], if this 748 should fail the with a uniqueness conflict, the client can retry 749 with different URIs with increasing randomness. 751 4.4.5 Data Semantics 753 Semantics for the document content are provided in Section 4.1. 755 4.4.6 Naming Conventions 757 Typically, there are two distinct XCAP clients that access RLS 758 services documents. The first is a client acting on behalf of the 759 end user in the system. This client edits and writes both resource 760 lists and RLS services documents as they are created or modified by 761 the end user. The other XCAP client is the RLS itself, which reads 762 the RLS services documents in order to process SUBSCRIBE requests. 764 To make it easier for an RLS to find the element for a 765 particular URI, the XCAP server maintains, within the global tree, a 766 single RLS services document representing the union of all of the 767 elements across all documents created by all users within 768 the same XCAP root. There is a single instance of this document, and 769 its name is "index". Thus, if the root services URI is 770 http://xcap.example.com/root, the following is the URI that an RLS 771 would use to fetch this index: 773 http://xcap.example.com/root/rls-services/global/index 775 As discussed below, this index is created from all of the documents 776 in the user tree that have the name "index" as well. An implication 777 of this is that a client operating on behalf of a user SHOULD define 778 its RLS services within that document. If the root services URI is 779 http://xcap.example.com/root, for user "joe" the URI for this 780 document would be: 782 http://xcap.example.com/root/rls-services/users/joe/index 784 If a client elects to define RLS services in a different document, 785 this document will not be "picked up" in the global index, and 786 therefore, not used as an RLS service. 788 4.4.7 Resource Interdependencies 790 As with other application usages, the XML schema along with the XCAP 791 resource naming conventions describes most of the resource 792 interdependencies applicable to this application usage. 794 This application usage defines an additional resource interdependence 795 between a single document in the global tree and all documents in the 796 user tree with the name "index". This global document is formed as 797 the union of all of the index documents for all users within the same 798 XCAP root. In this case, the union operation implies that each 799 element in a user document will also be present as a 800 element in the global document. The inverse is true as 801 well. Every element in the global document exists within a 802 user document within the same XCAP root. 804 As an example, consider the RLS services document for user joe: 806 807 808 809 http://xcap.example.com/resource-lists/users/joe/index/~~/ 810 resource-lists/list%5b@name=%22l1%22%5d 811 812 presence 813 814 815 817 And consider the RLS services document for user bob: 819 820 821 822 823 824 825 826 827 presence 828 829 830 832 The global document at 833 http://xcap.example.com/root/rls-services/global/index would look 834 like: 836 837 840 841 http://xcap.example.com/resource-lists/users/joe/index/~~/ 842 resource-lists/list%5b@name=%22l1%22%5d 843 844 presence 845 846 847 848 849 850 851 852 853 presence 854 855 856 858 The server MUST, at all times, be capable of processing requests made 859 against the global document, and its contents MUST reflect the 860 current state of all the relevant user documents. This requirement 861 does not imply that the server must actually store this global 862 document. It is anticipated that most systems will dynamically 863 construct the responses to any particular request against the 864 document resource. 866 The uniqueness constraint on the "uri" attribute of will 867 ensure that no two elements in the global document have the 868 same value of that attribute. 870 4.4.8 Authorization Policies 872 This application usage does not modify the default XCAP authorization 873 policy, which is that only a user can read, write or modify their own 874 documents. A server can allow priveleged users to modify documents 875 that they don't own, but the establishment and indication of such 876 policies is outside the scope of this document. It is anticipated 877 that a future application usage will define which users are allowed 878 to modify an RLS services document. 880 The index document maintained in the global tree represents sensitive 881 information, as it contains the union of all of the information for 882 all users on the server. As such, its access MUST be restricted to 883 trusted elements within domain of the server. Typically, this would 884 be limited to the RLSs that need access to this document. 886 4.5 Usage of an RLS Services Document by an RLS 888 This section discusses how an RLS, on receipt of a SUBSCRIBE request, 889 uses XCAP and the RLS services document to guide its operation. 891 When an RLS receives a SUBSCRIBE request for a URI (present in the 892 Request URI), it obtains the element whose uri attribute 893 matches (based on URI equality) the URI in the SUBSCRIBE request. 894 This document makes no normative statements on how this might be 895 accomplished. The following paragraph provides one possible 896 approach. 898 The RLS canonicalizes the Request URI as described in Section 5. It 899 then performs an XCAP GET operation against the URI formed by 900 combining the XCAP root with the document selector of the global 901 index with a node selector of the form "rls-services/ 902 service[@uri=]", where is the 903 canonicalized version of the Request URI. If the response is a 200 904 OK, it will contain the service definition for that URI. 906 Once the element has been obtained, it is examined. If the 907 element is present, and the event package in the SUBSCRIBE 908 request is not amongst those listed in the elements within 909 , the request MUST be rejected with a 489 (Bad Event) 910 response code, as described in [14]. Otherwise, it SHOULD be 911 processed. The next step is to authorize that the client is allowed 912 to subscribe to the resource. This can be done using the data 913 defined in [13], for example. Assuming the subscriber is authorized 914 to subscribe to that resource, the subscription is processed 915 according to the procedures defined in [15]. This processing 916 requires the RLS to compute a flat list of URIs that are to be 917 subscribed to. If the element had a element, it is 918 extracted. If the element had a element, 919 its URI content is dereferenced. The result should be a 920 element. If it is not, the request SHOULD be rejected with a 502 921 (Bad Gateway). Otherwise, that element is extracted. 923 At this point the RLS has a element in its possession. The 924 next step is to obtain a flat list of URIs from this element. To do 925 that, it traverses the tree of elements rooted in the element. 926 Before traversal begins, the RLS initializes two lists - the "flat 927 list", which will contain the flat list of URI after traversal, and 928 the "traversed list", which contains a list of HTTP URLs in 929 elements that have already been visited. Once these lists 930 are initialized, tree traversal begins. A server can use any 931 tree-traversal ordering it likes, such as depth first search or 932 breadth first search. The processing at each element in the tree 933 depends on the name of the element: 934 o If the element is the URI in the "uri" attribute of the 935 element is added to the flat list if it is not already present 936 (based on case sensitive string equality) in that list, and the 937 URI scheme represents one that can be used to service 938 subscriptions, such as SIP [4] and pres [16]. 939 o If the element is an , the relative path reference 940 making up the value of the "ref" attribute is resolved into an 941 absolute URL. This is done using the procedures defined in 942 Section 5.2 of RFC 2396 [7], using the XCAP root of the RLS 943 services document as the base URL. This absolute URL is resolved. 944 If the result is not a 200 OK containing a element, the 945 SUBSCRIBE request SHOULD be rejected with a 502 (Bad Gateway). 946 Otherwise, the element returned is processed as described 947 in the previous step. 948 o If the element is an element, the absolute URL making 949 up the value of the "anchor" attribute of the element is examined. 950 If the URL is on the traversed list, the server MUST cease 951 traversing the tree, and SHOULD reject the SUBSCRIBE request with 952 a 502 (Bad Gateway). If the URL is not on the traversed list, the 953 server adds the URL to the traversed list, and de-references the 954 URL. If the result is not a 200 OK containing an element, 955 the SUBSCRIBE request SHOULD be rejected with a 502 (Bad Gateway). 956 Otherwise, the RLS replaces the element that was returned, and 958 tree traversal continues. 960 Because the element is used to dynamically construct the 961 tree, there is a posibility of recursive evaluation of references. 962 The traversed list is used to prevent this from happening. 964 Once the tree has been traversed, the RLS can create virtual 965 subscriptions to each URI in the flat list, as defined in [15]. 967 In the processing steps outlined above, when an or 968 element contains a reference that cannot be resolved, 969 failing the request is at SHOULD strength. In some cases, an RLS may 970 provide better service by creating virtual subscriptions to the URIs 971 in the flat list that could be obtained, omitting those that could 972 not. Only in those cases should the SHOULD recommendation be 973 ignored. 975 5. SIP URI Canonicalization 977 This section provides a technique for URI canonicalization. This 978 canonicalization produces a URI that, in most cases, is equal to the 979 original URI (where equality is based on the URI comparison rules in 980 RFC 3261). Furthermore, the canonicalized URI will usually be 981 lexically equivalent to the canonicalized version of any other URI 982 equal to the original. 984 To canonicalize the URI, the following steps are followed: 985 1. First, the domain part of the URI is converted into all 986 lowercase, and any tokens (such as "user" or "transport" or 987 "udp") are converted to all lowercase. 988 2. Secondly, the URI is un-escape coded. Then, it is re-coded. 989 However, when it is recoded, the only characters that are coded 990 are those which are not permitted to appear based on the grammar 991 of that portion of the URI. For example, if a SIP URI is 992 sip:%6aoe%20smith@example.com, it is decoded to "sip:joe 993 smith@example.com" and the re-coded to 994 sip:joe%20smith@example.com. In the original URI, the character 995 'j' was escape coded. This is allowed, but not required, since 996 the grammar allows a 'j' to appear in the user part. As a 997 result, it appears as 'j' after this step of canonicalization. 998 3. Thirdly, any URI parameters are reordered so that they appear in 999 lexical order based on parameter name. The ordering of a 1000 character is determined by the US-ASCII numerical value of that 1001 character, with smaller numbers coming first. Parameters are 1002 ordered with the leftmost character as most significant. For 1003 parameters that contain only letters, this is equivalent to an 1004 alphabetical ordering. 1005 4. Finally, any header parameters are discarded. This canonicalized 1006 URI is used instead of the original URI. 1008 If two URIs A and B are functionally equal (meaning that they are 1009 equal according to the URI comparison rules in RFC 3261), their 1010 canonicalized URIs are equal under case sensitive string comparison 1011 if the following are true: 1012 o Neither URI contains header parameters 1013 o If one of the URI contains a URI parameter not defined in RFC 1014 3261, the other does as well. 1016 6. Security Considerations 1018 The information contained in rls-services and resource-lists 1019 documents are particularly sensitive. It represents the principle 1020 set of people with whom a user would like to communicate. As a 1021 result, clients SHOULD use TLS when contacting servers in order to 1022 fetch this information. Note that this does not represent a change 1023 in requirement strength from XCAP. 1025 7. IANA Considerations 1027 There are several IANA considerations associated with this 1028 specification. 1030 7.1 XCAP Application Usage IDs 1032 This section registers two new XCAP Application Usage ID (AUID) 1033 according to the IANA procedures defined in [10]. 1035 7.1.1 resource-lists 1036 Name of the AUID: resource-lists 1037 Description: A resource lists application is any application that 1038 needs access to a list of resources, identified by a URI, to which 1039 operations, such as subscriptions, can be applied. 1041 7.1.2 rls-services 1042 Name of the AUID: rls-services 1043 Description: An Resource List Server (RLS) services application is 1044 Session Initiation Protocol (SIP) application whereby a server 1045 receives SIP SUBSCRIBE requests for resource, and generates 1046 subscriptions towards the a resource list. 1048 7.2 MIME Type Registrations 1050 This specification requests the registration of two new MIME types 1051 according to the procedures of RFC 2048 [9] and guidelines in RFC 1052 3023 [5]. 1054 7.2.1 application/resource-lists+xml 1055 MIME media type name: application 1056 MIME subtype name: resource-lists+xml 1057 Mandatory parameters: none 1058 Optional parameters: Same as charset parameter application/xml as 1059 specified in RFC 3023 [5]. 1060 Encoding considerations: Same as encoding considerations of 1061 application/xml as specified in RFC 3023 [5]. 1062 Security considerations: See Section 10 of RFC 3023 [5] and 1063 Section 6 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace 1064 XXXX with the RFC number of this specification]]. 1065 Interoperability considerations: none. 1066 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: 1067 Please replace XXXX with the RFC number of this specification]] 1068 Applications which use this media type: This document type has 1069 been used to support subscriptions to lists of users [15] for 1070 SIP-based presence [12]. 1072 Additional Information: 1073 Magic Number: None 1074 File Extension: .rl or .xml 1075 Macintosh file type code: "TEXT" 1076 Personal and email address for further information: Jonathan 1077 Rosenberg, jdrosen@jdrosen.net 1078 Intended usage: COMMON 1079 Author/Change controller: The IETF. 1081 7.2.2 application/rls-services+xml 1082 MIME media type name: application 1083 MIME subtype name: rls-services+xml 1084 Mandatory parameters: none 1085 Optional parameters: Same as charset parameter application/xml as 1086 specified in RFC 3023 [5]. 1087 Encoding considerations: Same as encoding considerations of 1088 application/xml as specified in RFC 3023 [5]. 1089 Security considerations: See Section 10 of RFC 3023 [5] and 1090 Section 6 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace 1091 XXXX with the RFC number of this specification]]. 1092 Interoperability considerations: none. 1093 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: 1094 Please replace XXXX with the RFC number of this specification]] 1095 Applications which use this media type: This document type has 1096 been used to support subscriptions to lists of users [15] for 1097 SIP-based presence [12]. 1098 Additional Information: 1099 Magic Number: None 1100 File Extension: .rl or .xml 1101 Macintosh file type code: "TEXT" 1102 Personal and email address for further information: Jonathan 1103 Rosenberg, jdrosen@jdrosen.net 1104 Intended usage: COMMON 1105 Author/Change controller: The IETF. 1107 7.3 URN Sub-Namespace Registrations 1109 This section registers two new XML namespace, as per the guidelines 1110 in RFC 3688 [8]. 1112 7.3.1 urn:ietf:params:xml:ns:resource-lists 1113 URI: The URI for this namespace is 1114 urn:ietf:params:xml:ns:resource-lists. 1115 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1116 Jonathan Rosenberg (jdrosen@jdrosen.net). 1118 XML: 1120 BEGIN 1121 1122 1124 1125 1126 1128 Resource Lists Namespace 1129 1130 1131

Namespace for Resource Lists

1132

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

1133

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

1136 1137 1138 END 1140 7.3.2 urn:ietf:params:xml:ns:rls-services 1141 URI: The URI for this namespace is 1142 urn:ietf:params:xml:ns:rls-services. 1143 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1144 Jonathan Rosenberg (jdrosen@jdrosen.net). 1145 XML: 1147 BEGIN 1148 1149 1151 1152 1153 1155 Resource List Server (RLS) Services Namespace 1156 1157 1158

Namespace for Resource List Server (RLS) Services

1159

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

1160

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

1163 1164 1165 END 1167 7.4 Schema Registrations 1169 This section registers two XML schemas per the procedures in [8]. 1171 7.4.1 urn:ietf:params:xml:schema:resource-lists 1172 URI: urn:ietf:params:xml:schema:resource-lists 1173 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1174 Jonathan Rosenberg (jdrosen@jdrosen.net). 1175 The XML for this schema can be found as the sole content of 1176 Section 3.2. 1178 7.4.2 urn:ietf:params:xml:schema:rls-services 1179 URI: urn:ietf:params:xml:schema:rls-services 1180 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1181 Jonathan Rosenberg (jdrosen@jdrosen.net). 1182 The XML for this schema can be found as the sole content of 1183 Section 4.2. 1185 8. References 1187 8.1 Normative References 1189 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1190 Levels", BCP 14, RFC 2119, March 1997. 1192 [2] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 1193 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 1194 FirstEdition REC-xml-20001006, October 2000. 1196 [3] Moats, R., "URN Syntax", RFC 2141, May 1997. 1198 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1199 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1200 Session Initiation Protocol", RFC 3261, June 2002. 1202 [5] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 1203 3023, January 2001. 1205 [6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1206 August 1999. 1208 [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1209 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1210 1998. 1212 [8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1213 January 2004. 1215 [9] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet 1216 Mail Extensions (MIME) Part Four: Registration Procedures", BCP 1217 13, RFC 2048, November 1996. 1219 [10] Rosenberg, J., "The Extensible Markup Language (XML) 1220 Configuration Access Protocol (XCAP)", 1221 draft-ietf-simple-xcap-02 (work in progress), February 2004. 1223 8.2 Informative References 1225 [11] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 1226 Instant Messaging", RFC 2778, February 2000. 1228 [12] Rosenberg, J., "A Presence Event Package for the Session 1229 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 1230 in progress), January 2003. 1232 [13] Rosenberg, J., "Presence Authorization Rules", 1233 draft-ietf-simple-presence-rules-00 (work in progress), May 1234 2004. 1236 [14] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1237 Notification", RFC 3265, June 2002. 1239 [15] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation 1240 Protocol (SIP) Event Notification Extension for Resource 1241 Lists", draft-ietf-simple-event-list-04 (work in progress), 1242 June 2003. 1244 [16] Peterson, J., "Common Profile for Presence (CPP)", 1245 draft-ietf-impp-pres-04 (work in progress), October 2003. 1247 [17] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of 1248 Data Elements in Session Initiation Protocol (SIP) for Instant 1249 Messaging and Presence Leveraging Extensions (SIMPLE) Systems", 1250 draft-ietf-simple-data-req-03 (work in progress), June 2003. 1252 Author's Address 1254 Jonathan Rosenberg 1255 dynamicsoft 1256 600 Lanidex Plaza 1257 Parsippany, NJ 07054 1258 US 1260 Phone: +1 973 952-5000 1261 EMail: jdrosen@dynamicsoft.com 1262 URI: http://www.jdrosen.net 1264 Intellectual Property Statement 1266 The IETF takes no position regarding the validity or scope of any 1267 Intellectual Property Rights or other rights that might be claimed to 1268 pertain to the implementation or use of the technology described in 1269 this document or the extent to which any license under such rights 1270 might or might not be available; nor does it represent that it has 1271 made any independent effort to identify any such rights. Information 1272 on the procedures with respect to rights in RFC documents can be 1273 found in BCP 78 and BCP 79. 1275 Copies of IPR disclosures made to the IETF Secretariat and any 1276 assurances of licenses to be made available, or the result of an 1277 attempt made to obtain a general license or permission for the use of 1278 such proprietary rights by implementers or users of this 1279 specification can be obtained from the IETF on-line IPR repository at 1280 http://www.ietf.org/ipr. 1282 The IETF invites any interested party to bring to its attention any 1283 copyrights, patents or patent applications, or other proprietary 1284 rights that may cover technology that may be required to implement 1285 this standard. Please address the information to the IETF at 1286 ietf-ipr@ietf.org. 1288 Disclaimer of Validity 1290 This document and the information contained herein are provided on an 1291 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1292 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1293 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1294 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1295 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1296 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1298 Copyright Statement 1300 Copyright (C) The Internet Society (2004). This document is subject 1301 to the rights, licenses and restrictions contained in BCP 78, and 1302 except as set forth therein, the authors retain all their rights. 1304 Acknowledgment 1306 Funding for the RFC Editor function is currently provided by the 1307 Internet Society.