idnits 2.17.00 (12 Aug 2021) /tmp/idnits49280/draft-ietf-simple-xcap-package-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 155: '...UBSCRIBE request MAY contain a body. T...' RFC 2119 keyword, line 172: '...o be applied. The notifier SHOULD send...' RFC 2119 keyword, line 207: '...rs and notifiers MUST support the "app...' RFC 2119 keyword, line 209: '... request MAY contain an Accept heade...' RFC 2119 keyword, line 211: '...d is present, it MUST include "applica...' (21 more instances...) 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 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 (June 23, 2003) is 6906 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) ** Obsolete normative reference: RFC 3265 (ref. '2') (Obsoleted by RFC 6665) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2141 (ref. '5') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3023 (ref. '6') (Obsoleted by RFC 7303) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '7') == Outdated reference: draft-mealling-iana-xmlns-registry has been published as RFC 3688 ** Obsolete normative reference: RFC 2616 (ref. '9') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: draft-ietf-simple-event-list has been published as RFC 4662 Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE J. Rosenberg 3 Internet-Draft dynamicsoft 4 Expires: December 22, 2003 June 23, 2003 6 A Session Initiation Protocol (SIP) Event Package for Modification 7 Events for the Extensible Markup Language (XML) Configuration Access 8 Protocol (XCAP) Managed Documents 9 draft-ietf-simple-xcap-package-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 22, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This specification defines a Session Initiation Protocol (SIP) event 40 package for finding out about changes to documents managed by the 41 Extensible Markup Language (XML) Configuration Access Protocol 42 (XCAP). XCAP allows a client to manipulate XML documents on a server 43 which contain configuration information for application protocols. 44 Multiple clients can potentially access the same document, in which 45 case the other clients would like to be notified of a change in the 46 document made by another. This event package allows a client to do 47 that. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Document Change Event Package . . . . . . . . . . . . . . . 4 53 2.1 Package Name . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.2 Event Package Parameters . . . . . . . . . . . . . . . . . . 4 55 2.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . 4 56 2.4 Subscription Duration . . . . . . . . . . . . . . . . . . . 5 57 2.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . . 6 59 2.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . . 6 60 2.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 7 61 2.9 Handling of Forked Requests . . . . . . . . . . . . . . . . 7 62 2.10 Rate of Notifications . . . . . . . . . . . . . . . . . . . 8 63 2.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3. application/xml-change Media Type . . . . . . . . . . . . . 9 65 3.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 3.2 Example Document . . . . . . . . . . . . . . . . . . . . . . 10 67 4. Security Considerations . . . . . . . . . . . . . . . . . . 11 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 69 5.1 SIP Event Package . . . . . . . . . . . . . . . . . . . . . 12 70 5.2 application/xcap-change+xml MIME Type . . . . . . . . . . . 12 71 5.3 URN Sub-Namespace Registration for 72 urn:ietf:params:xml:ns:xcap-change . . . . . . . . . . . . . 13 73 Normative References . . . . . . . . . . . . . . . . . . . . 15 74 Informative References . . . . . . . . . . . . . . . . . . . 16 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . 16 76 Intellectual Property and Copyright Statements . . . . . . . 17 78 1. Introduction 80 The Extensible Markup Language (XML) Configuration Access Protocol 81 (XCAP) [10] is a protocol that allows clients to manipulate XML 82 documents stored on a server. These XML documents serve as 83 configuration information for application protocols. As an example, 84 resource list [11] subscriptions (also known as presence lists) allow 85 a client to have a single SIP subscription to a list of users, where 86 the list is maintained on a server. The server will obtain presence 87 for those users and report it back to the client. This application 88 requires the server, called a Resource List Server (RLS), to have 89 access to the list of presentities. This list needs to be manipulated 90 by clients so they can add and remove their friends as they desire. 92 Complexities arise when multiple clients attempt to simultaneously 93 manipulate a document, such as a presence list. Frequently, a client 94 will keep a copy of the current list in memory, so it can render it 95 to users. However, if another client modifies the document, the 96 cached version becomes stale. This information must be made known to 97 all clients which have cached copies of the document, so that they 98 can fetch the most recent one. 100 This problem is addressed by this specification, which provides a 101 Session Initiation Protocol (SIP) [1]event package [2] for 102 subscribing to changes in documents managed by an XCAP server. This 103 package would be used by any client which is retaining a cached copy 104 of a document obtained by XCAP, so that it can find out when a change 105 has been made, invalidating its cached copy. In fact, the 106 notifications generated by this package indicate the specific change 107 which occurred in the document, so the client can decide whether the 108 change is significant enough to warrant a refetch from the XCAP 109 server. 111 2. Document Change Event Package 113 The SIP event framework [2] defines a SIP extension for subscribing 114 to, and receiving notifications of, events. It leaves the definition 115 of many aspects of these events to concrete extensions, known as 116 event packages. This document qualifies as an event package. This 117 section fills in the information required for all event packages by 118 RFC 3265. 120 2.1 Package Name 122 The name of this package is "xcap-change". As specified in RFC 3265 123 [2], this value appears in the Event header field present in 124 SUBSCRIBE and NOTIFY requests. 126 2.2 Event Package Parameters 128 The SIP event framework allows event packages to define additional 129 parameters carried in the Event header field. This package defines a 130 single event header parameter, called "doc-component", which 131 specifies a particular document and document component which is being 132 to subscribed to. The request-URI specifies the user whose data is 133 being subscribed to. By default, a subscription is for all XCAP data 134 associated with that user. The header field parameter allows the 135 subscription to specify a specific document and document sub-tree. 137 The format of this header field parameter is a quoted string, whose 138 value is the portion of an XCAP URI to the right of the directory for 139 the user. For example, if a user wishes to subscribe to http:// 140 xcap.example.com/services/presence-lists/users/joe/mydir/friends.xml, 141 the event header parameter would be "mydir/friends.xml". 143 OPEN ISSUE: What does the request URI look like for subscriptions 144 to global data? Should the request URI instead contain the XCAP 145 URI as the user part? Might make sense, but interacts badly with 146 general SIP routing which is user-based. 148 OPEN ISSUE: There is no way to specify that a subscription is to 149 multiple documents. Multiple subscriptions would be needed for 150 that. Is that limitation OK for now? A filter can fix that down 151 the road. 153 2.3 SUBSCRIBE Bodies 155 A SUBSCRIBE request MAY contain a body. The purpose of the body 156 depends on its type. Subscriptions will normally not contain bodies. 157 The Request-URI, which identifies the user whose data is being 158 subscribed to, combined with the event package name and parameter, is 159 sufficient for this package. 161 One type of body that can be included in a SUBSCRIBE request is a 162 filter document. These filters request that only document change 163 events generate notifications, or would ask for a restriction on the 164 set of data returned in NOTIFY requests. Filter documents are not 165 specified in this document, and at the time of writing, are expected 166 to be the subject of future standardization activity. 168 Honoring of these filters is at the policy discretion of the 169 notifier. 171 If the SUBSCRIBE request does not contain a filter, this tells the 172 notifier that no filter is to be applied. The notifier SHOULD send 173 NOTIFY requests at the discretion of its own policy. 175 2.4 Subscription Duration 177 Generally speaking, changes to application configuration data are 178 relatively infrequent. Of course, this depends on the type of 179 application, but generally configuration data is static. As a result, 180 notifications are expected infrequently, and subscriptions will 181 typically be held for long periods of time. This would argue for long 182 subscription refresh intervals. For this reason, the default 183 subscription duration is two hours. Of course, a different duration 184 can be requested by a client, or set by a server, using the Expires 185 header field, as per RFC 3265 [2]. 187 2.5 NOTIFY Bodies 189 As described in RFC 3265 [2], the NOTIFY message will contain bodies 190 that describe the state of the subscribed resource. This body is in a 191 format listed in the Accept header field of the SUBSCRIBE, or a 192 package-specific default if the Accept header field was omitted from 193 the SUBSCRIBE. 195 In this event package, the body of the notification contains a 196 document change document. This document describes the current version 197 of an XML document managed by XCAP, in addition to the changes in 198 this document from the previous version. Note that a listing of 199 changes from the previous version is only sent in a NOTIFY triggered 200 by a change to the document. NOTIFY requests sent in response to an 201 initial SUBSCRIBE, or a SUBSCRIBE refresh, only indicate the current 202 version of the XML document. They do not contain the actual full 203 contents of the XML document. In other words, the resource being 204 subscribed to is NOT the XML document itself, but rather, the version 205 history for the document. 207 All subscribers and notifiers MUST support the "application/ 208 xcap-change+xml" data format described in Section 3. The subscribe 209 request MAY contain an Accept header field. If no such header field 210 is present, it has a default value of "application/xcap-change+xml". 211 If the header field is present, it MUST include "application/ 212 xcap-change+xml", and MAY include any other types capable of 213 representing changes in XCAP documents. 215 2.6 Notifier Processing of SUBSCRIBE Requests 217 This subsection defines package-specific processing at the notifier 218 when it receives a SUBSCRIBE request. General processing rules for 219 requests are covered in Section 8.2 of RFC 3261 [1], in addition to 220 general SUBSCRIBE processing in RFC 3265 [2]. 222 A notifier for this package SHOULD authenticate all subscribers. 223 Generally, subscribers will have a pre-existing relationship with the 224 notifier. This is because the principle application of this package 225 is for a client of XCAP (which will have a relationship with the XCAP 226 server) to find out about changes in cached documents. Therefore, the 227 HTTP Digest mechanism in SIP is a good match for authentication, and 228 MUST be supported by all clients and servers. Note that this 229 authentication mechanism is already mandatory for all SIP-compliant 230 implementations. 232 Once authenticated, the server SHOULD authorize the subscriber. 233 Generally, this authorization policy SHOULD mirror the authorization 234 policy defined in an XCAP application usage for read access. Thats 235 because this package provides a form of read-access, and the 236 permissions should not differ based on whether the read is performed 237 with XCAP or with a SIP SUBSCRIBE request. 239 2.7 Notifier Generation of NOTIFY Requests 241 RFC 3265 details the formatting and structure of NOTIFY messages. 242 However, packages are mandated to provide detailed information on 243 when to send a NOTIFY, how to compute the state of the resource, how 244 to generate neutral or fake state information, and whether state 245 information is complete or partial. This section describes those 246 details for the presence event package. 248 A notifier MAY send a notification at any time. Typically, it will 249 send one after a document managed by an XCAP server has changed as 250 the result of an XCAP operation. This notification contains an 251 application/xcap-change+xml document that specifies the current 252 version (as a server modification time) for the XML document being 253 subscribed to. It also contains information about what changed - 254 whether a new element or attribute was added, whether an existing one 255 changed, or whether an existing one was deleted, and indicates 256 against which version those changes were made. The xcap-change 257 document also contains a hash of the new XML document. 259 Notifications sent in response to SUBSCRIBE requests (either initial 260 or refresh), or sent when there is a change in subscription state, 261 will normally only contain the current version of the XML document 262 being subscribed to. 264 The body of the NOTIFY MUST be sent using one of the types listed in 265 the Accept header field in the most recent SUBSCRIBE request, or 266 using the type "application/xcap-change+xml" if no Accept header 267 field was present. 269 2.8 Subscriber Processing of NOTIFY Requests 271 RFC 3265 [2] leaves it to event packages to describe the process 272 followed by the subscriber upon receipt of a NOTIFY request, 273 including any logic required to form a coherent resource state. 275 In this package, the notifications can be optionally used by the 276 client to determine the state of the XML document being subscribed 277 to. When a client receives a notification, it checks the version 278 against which the changes are relative. If this is not the same as 279 the version currently cached by the client, the client SHOULD use 280 XCAP to fetch the latest version of the document. If it is the same, 281 the client applies the change to its local cache of the document. To 282 apply the changes, the client follows the procedures defined by XCAP 283 [10] as if it were the HTTP server. After applying the changes, the 284 client applies the mandatory XML canonicalization defined in the 285 Canonical XML 1.0 [3] specification, and computes an HMAC [12] using 286 SHA1 over this canonical document, with a key whose value is 0x2238a. 287 The resulting string is compared with the hash attribute of the 288 xml-change document. If they match, the client can be sure that it 289 has the most up to date version. If they don't match, the client 290 SHOULD fetch the most current version of the document. 292 Of course, this mechanism for computing the most current document 293 from the hash is optional. A client can elect to ignore the 294 information on what changed and simply fetch the most recent document 295 every time it gets a change indication where the new version is not 296 the same as the one cached by the client. 298 2.9 Handling of Forked Requests 300 RFC 3265 [2] requires each package to describe handling of forked 301 SUBSCRIBE requests. 303 This specification only allows a single dialog to be constructed as a 304 result of emitting an initial SUBSCRIBE request. Section 4.4.9 of RFC 305 3265 [2] describes the processing that is required to guarantee the 306 creation of a single dialog in response to a SUBSCRIBE request. 308 2.10 Rate of Notifications 310 RFC 3265 [2] requires each package to specify the maximum rate at 311 which notifications can be sent. A notifier SHOULD NOT generate 312 notifications at a rate of more than once every five seconds. 314 2.11 State Agents 316 RFC 3265 [2] requires each package to consider the role of state 317 agents in the package, and if they are used, to specify how 318 authentication and authorization are done. 320 State agents play no role in this package. 322 3. application/xml-change Media Type 324 An xml-change document is an XML [4] document that MUST be 325 well-formed and SHOULD be valid. XML-change documents MUST be based 326 on XML 1.0 and MUST be encoded using UTF-8. This specification makes 327 use of XML namespaces for identifying xml-change documents and 328 document fragments. The namespace URI for elements defined by this 329 specification is a URN [5], using the namespace identifier 'ietf' 330 defined by [7] and extended by [8]. This URN is: 332 urn:ietf:params:xml:ns:xml-change 334 An xml-change document begins with the root element tag "documents". 335 It consists of any number of "document" sub-elements, each of which 336 conveys information on a particular document. Other elements from 337 different namespaces MAY be present for the purposes of 338 extensibility; elements or attributes from unknown namespaces MUST be 339 ignored. There is one attribute associated with this element: 341 uri: specifies the HTTP URI that references this document. This 342 attribute is mandatory. 344 Each "document" element consists of zero or more "change" elements, 345 each of which conveys information about a specific change to the 346 document. Other elements from different namespaces MAY be present for 347 the purposes of extensibility; elements or attributes from unknown 348 namespaces MUST be ignored. There are three attributes associated 349 with this element: 351 version: specifies the new version of the document, expressed as an 352 HTTP-Date [9]. This attribute is mandatory. 354 previous: specifies the previous version of the document, expressed 355 as an HTTP-Date, against which the changes are relative. This 356 attribute MUST be present if any change sub-elements are present. 358 hash: specifies an HMAC of the new document, represented in canonical 359 form. See Section 2.8 for details on how this value is computed. 360 This attribute MUST be present if any change sub-elements are 361 present. 363 Each "change" element contains either text, or additional XML 364 content. This content is the same as that which appeared in the body 365 of the HTTP request which caused modification of the document. There 366 are two attributes associated with this element: 368 uri: contains the URI that the HTTP request contained in the 369 Request-URI. This attribute is mandatory. 371 method: contains the method of the HTTP request. This attribute is 372 mandatory. 374 OPEN ISSUE: Probably it would be better to describe the changes 375 more generically, rather than binding them to the specifics of 376 XCAP. 378 3.1 XML Schema 380 TBD. 382 3.2 Example Document 384 The following is an example of a document compliant to the schema: 386 387 388 393 396 sip:bob@example.com 397 398 400 4. Security Considerations 402 The security considerations for this package are similar to those of 403 XCAP. The configuration data can contain sensitive information, and 404 both the client and the server need to authenticate each other. As 405 such, a notifier for this package MUST support HTTP Digest to 406 authenticate subscribers. Notifiers and subscribers MAY use SIPs S/ 407 MIME feature to provide authentication and message integrity. 409 5. IANA Considerations 411 There are several IANA considerations associated with this 412 specification. 414 5.1 SIP Event Package 416 This specification registers an event package, based on the 417 registration procedures defined in RFC 3265 [2]. The following is the 418 information required for such a registration: 420 Package Name: presence 422 Package or Template-Package: This is a package. 424 Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX 425 with the RFC number of this specification). 427 Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net. 429 5.2 application/xcap-change+xml MIME Type 431 MIME media type name: application 433 MIME subtype name: xcap-change+xml 435 Mandatory parameters: none 437 Optional parameters: Same as charset parameter application/xml as 438 specified in RFC 3023 [6]. 440 Encoding considerations: Same as encoding considerations of 441 application/xml as specified in RFC 3023 [6]. 443 Security considerations: See Section 10 of RFC 3023 [6] and 444 Section 4 of this specification. 446 Interoperability considerations: none. 448 Published specification: This document. 450 Applications which use this media type: This document type has 451 been used to support manipulation of presence lists [13] using 452 XCAP. 454 Additional Information: 456 Magic Number: None 458 File Extension: .xcd or .xml 460 Macintosh file type code: "TEXT" 462 Personal and email address for further information: Jonathan 463 Rosenberg, jdrosen@jdrosen.net 465 Intended usage: COMMON 467 Author/Change controller: The IETF. 469 5.3 URN Sub-Namespace Registration for 470 urn:ietf:params:xml:ns:xcap-change 472 This section registers a new XML namespace, as per the guidelines in 473 [8] 475 URI: The URI for this namespace is 476 urn:ietf:params:xml:ns:xcap-change. 478 Registrant Contact: IETF, SIMPLE working group, 479 (simple@mailman.dynamicsoft.com), Jonathan Rosenberg 480 (jdrosen@jdrosen.net). 482 XML: 484 BEGIN 485 486 488 489 490 492 XCAP Change Namespace 493 494 495

Namespace for XCAP Change

496

application/xcap-change+xml

497

See RFCXXXX.

498 499 500 END 502 Normative References 504 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 505 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 506 Session Initiation Protocol", RFC 3261, June 2002. 508 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 509 Notification", RFC 3265, June 2002. 511 [3] Boyer, J., "Canonical XML Version 1.0", W3C REC 512 REC-xml-c14n-20010315, March 2001. 514 [4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 515 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 516 REC REC-xml-20001006, October 2000. 518 [5] Moats, R., "URN Syntax", RFC 2141, May 1997. 520 [6] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 521 3023, January 2001. 523 [7] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 524 August 1999. 526 [8] Mealling, M., "The IETF XML Registry", 527 draft-mealling-iana-xmlns-registry-05 (work in progress), June 528 2003. 530 [9] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 531 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 532 HTTP/1.1", RFC 2616, June 1999. 534 [10] Rosenberg, J., "The Extensible Markup Language (XML) 535 Configuration Access Protocol (XCAP)", 536 draft-rosenberg-simple-xcap-00 (work in progress), May 2003. 538 Informative References 540 [11] Rosenberg, J., Roach, A. and B. Campbell, "A Session Initiation 541 Protocol (SIP) Event Notification Extension for Resource 542 Lists", draft-ietf-simple-event-list-04 (work in progress), 543 June 2003. 545 [12] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 546 for Message Authentication", RFC 2104, February 1997. 548 [13] Rosenberg, J., "An Extensible Markup Language (XML) 549 Configuration Access Protocol (XCAP) Usage for Presence Lists", 550 draft-rosenberg-simple-xcap-list-usage-00 (work in progress), 551 May 2003. 553 Author's Address 555 Jonathan Rosenberg 556 dynamicsoft 557 600 Lanidex Plaza 558 Parsippany, NJ 07054 559 US 561 Phone: +1 973 952-5000 562 EMail: jdrosen@dynamicsoft.com 563 URI: http://www.jdrosen.net 565 Intellectual Property Statement 567 The IETF takes no position regarding the validity or scope of any 568 intellectual property or other rights that might be claimed to 569 pertain to the implementation or use of the technology described in 570 this document or the extent to which any license under such rights 571 might or might not be available; neither does it represent that it 572 has made any effort to identify any such rights. Information on the 573 IETF's procedures with respect to rights in standards-track and 574 standards-related documentation can be found in BCP-11. Copies of 575 claims of rights made available for publication and any assurances of 576 licenses to be made available, or the result of an attempt made to 577 obtain a general license or permission for the use of such 578 proprietary rights by implementors or users of this specification can 579 be obtained from the IETF Secretariat. 581 The IETF invites any interested party to bring to its attention any 582 copyrights, patents or patent applications, or other proprietary 583 rights which may cover technology that may be required to practice 584 this standard. Please address the information to the IETF Executive 585 Director. 587 Full Copyright Statement 589 Copyright (C) The Internet Society (2003). All Rights Reserved. 591 This document and translations of it may be copied and furnished to 592 others, and derivative works that comment on or otherwise explain it 593 or assist in its implementation may be prepared, copied, published 594 and distributed, in whole or in part, without restriction of any 595 kind, provided that the above copyright notice and this paragraph are 596 included on all such copies and derivative works. However, this 597 document itself may not be modified in any way, such as by removing 598 the copyright notice or references to the Internet Society or other 599 Internet organizations, except as needed for the purpose of 600 developing Internet standards in which case the procedures for 601 copyrights defined in the Internet Standards process must be 602 followed, or as required to translate it into languages other than 603 English. 605 The limited permissions granted above are perpetual and will not be 606 revoked by the Internet Society or its successors or assignees. 608 This document and the information contained herein is provided on an 609 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 610 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 611 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 612 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 613 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 615 Acknowledgement 617 Funding for the RFC Editor function is currently provided by the 618 Internet Society.