idnits 2.17.00 (12 Aug 2021) /tmp/idnits42426/draft-ietf-simple-xcap-diff-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 654. ** 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. 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 8 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 18, 2005) is 6150 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- 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. '4') (Obsoleted by RFC 7303) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '5') == Outdated reference: draft-ietf-simple-xcap has been published as RFC 4825 == Outdated reference: draft-ietf-sipping-config-framework has been published as RFC 6080 -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '11') (Obsoleted by RFC 6665) == Outdated reference: draft-ietf-simple-event-list has been published as RFC 4662 == Outdated reference: draft-ietf-simple-xcap-list-usage has been published as RFC 4826 == Outdated reference: draft-ietf-sip-content-indirect-mech has been published as RFC 4483 Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: January 19, 2006 July 18, 2005 6 An Extensible Markup Language (XML) Document Format for Indicating 7 Changes in XML Configuration Access Protocol (XCAP) Resources 8 draft-ietf-simple-xcap-diff-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 19, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This specification defines a document format that can be used to 42 describe the differences between versions of resources managed by the 43 Extensible Markup Language (XML) Configuration Access Protocol 44 (XCAP). XCAP diff documents can be delivered to clients using a 45 number of means, including the Session Initiation Protocol (SIP) 46 event package for configuration data. By subscribing to this event 47 package, clients can learn about document changes made by other 48 clients. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Structure of an XCAP Diff Document . . . . . . . . . . . . . 4 55 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 5. Example Document . . . . . . . . . . . . . . . . . . . . . . 7 57 6. Usage with the Config Framework . . . . . . . . . . . . . . 8 58 7. Constructing a Document from the Change Log . . . . . . . . 10 59 8. Security Considerations . . . . . . . . . . . . . . . . . . 11 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 61 9.1 application/xcap-diff+xml MIME Type . . . . . . . . . . . 11 62 9.2 URN Sub-Namespace Registration for 63 urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 12 64 9.3 Schema Registration . . . . . . . . . . . . . . . . . . . 13 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 10.1 Normative References . . . . . . . . . . . . . . . . . . 13 67 10.2 Informative References . . . . . . . . . . . . . . . . . 14 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . 15 69 Intellectual Property and Copyright Statements . . . . . . . 16 71 1. Introduction 73 The Extensible Markup Language (XML) Configuration Access Protocol 74 (XCAP) [8] is a protocol that allows clients to manipulate XML 75 documents stored on a server. These XML documents serve as 76 configuration information for application protocols. As an example, 77 resource list [12] subscriptions (also known as presence lists) allow 78 a client to have a single SIP subscription to a list of users, where 79 the list is maintained on a server. The server will obtain presence 80 for those users and report it back to the client. This application 81 requires the server, called a Resource List Server (RLS), to have 82 access to the list of presentities. This list needs to be 83 manipulated by clients so they can add and remove their friends as 84 they desire. 86 Complexities arise when multiple clients attempt to simultaneously 87 manipulate a document, such as a presence list. Frequently, a client 88 will keep a copy of the current list in memory, so it can render it 89 to users. However, if another client modifies the document, the 90 cached version becomes stale. This modification event must be made 91 known to all clients which have cached copies of the document, so 92 that they can fetch the most recent one. 94 To deal with this problem, clients can use the Session Initiation 95 Protocol (SIP) [10] event package [11] for subscribing to changes in 96 configuration and profile information [9], including application data 97 that resides on an XCAP server. With that package, a user gets 98 notified that a particular document has changed. This notification 99 can include the full content of the new document, or it can be a 100 content indirection [15]. However, in both cases, the transfer of 101 the entire document is ultimately required. This may require a lot 102 of bandwidth, particularly for wireless devices with large documents 103 (such as a resource list [12] with hundreds of users listed). 104 Furthermore, though content indirection can tell a client that a 105 document has changed, it provides it with MIME Content-ID indicating 106 the new version of the document. The MIME Content-ID is not the same 107 as the entity tag, which is used by XCAP for document versioning. As 108 such, a client cannot easily ascertain whether an indication of a 109 change in a document is due to a change it just made, or due to a 110 change another client made at around the same time. 112 To resolve this problem, this document defines a data format which 113 can convey changes in XML documents managed by an XCAP server. This 114 data format is an XML document format, called an XCAP diff document. 115 This format can indicate that a document has changed, provide its 116 previous and new entity tags, and optionally include the xcap 117 operation that was performed which resulted in that change. This 118 specification also explains how this format is used in conjunction 119 with the configuration profile framework. 121 2. Terminology 123 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 124 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 125 and "OPTIONAL" are to be interpreted as described in RFC 2119 [7] and 126 indicate requirement levels for compliant implementations. 128 This specification also defines the following additional terms: 130 Document: When the term document is used without the "XCAP diff" in 131 front of it, it refers to the XCAP document resource about whom 132 the XCAP diff document is reporting a change. 134 XCAP diff document: The XML document defined by this specification 135 that reports on a set of changes in an XCAP document resource. 137 Server: Typically an XCAP server, this is a protocol entity that 138 generates XCAP diff documents based on its knowledge of a set of 139 XCAP documents. 141 Client: Typically an XCAP client and SIP User Agent (UA) that acts as 142 a subscriber to the configuration event package, this is a 143 protocol entity that consumes XCAP diff documents in order to 144 reconstruct the document stored on the server. 146 3. Structure of an XCAP Diff Document 148 An XCAP diff document is an XML [2] document that MUST be well-formed 149 and SHOULD be valid. XCAP diff documents MUST be based on XML 1.0 150 and MUST be encoded using UTF-8. This specification makes use of XML 151 namespaces for identifying XCAP diff documents and document 152 fragments. The namespace URI for elements defined by this 153 specification is a URN [3], using the namespace identifier 'ietf' 154 defined by [5] and extended by [6]. This URN is: 156 urn:ietf:params:xml:ns:xcap-diff 158 An XCAP diff document begins with the root element tag . 159 This element has a single mandatory attribute, "xcap-root". The 160 value of this attribute is the XCAP root URI for the documents in 161 which the changes have taken place. A single XCAP diff document can 162 only represent changes in documents within the same XCAP root. The 163 content of the element is a sequence of 164 elements. Each element specifies changes in a specific 165 document within the XCAP root. It has one mandatory attribute, "doc- 166 selector", and a three optional attributes, "new-etag", "previous- 167 etag" and "hash". The "doc-selector" identifies the specific 168 document within the XCAP root for which changes are indicated. Its 169 content MUST be a relative path reference, with the base URI being 170 equal to the XCAP root URI. The "new-etag" attribute provides the 171 etag for the document after the application of the changes, assuming 172 the document exists after those changes. If the change being 173 reported is the deletion of the document, the "new-etag" attribute 174 will not be present. A server MUST include the "new-etag" unless the 175 document does not exist subsequent to the changes reported in the 176 XCAP diff document. If The "previous-etag" attribute provides an 177 identifier for the document instance prior to the change. If the 178 document did not exist prior to the change (that is, the change was 179 the creation of the document), the "previous-etag" is not present. 180 If the server is reporting a specific set of document changes via the 181 element described below, a server MUST include the 182 "previous-etag" unless the document did not exist prior to changes 183 reported in the XCAP diff document. If the element is 184 not present, the "previous-etag" SHOULD be present. The "previous- 185 etag" and "new-etag" need not have been sequentially assigned etags 186 at the server. An XCAP diff document can describe changes that have 187 occurred over a series of XCAP operations. 189 The optional "hash" attribute provides an HMAC of the document 190 instance whose etag is "new-etag", once that document is represented 191 in canonical form. See Section 6 for details on how this value is 192 computed. This attribute is optional, and a server MAY elect not to 193 include it. Even if present, a client MAY elect to ignore it. 195 Each element contains zero or one element, 196 followed by any number of elements from another namespace for the 197 purposes of extensibility. Any such unknown elements MUST be ignored 198 by the client. When present, the element tells the 199 client the specific set of XCAP operations that can be applied to 200 transform the document from the version whose etag was "previous- 201 etag" to the version whose etag is "new-etag". If the "previous- 202 etag" is not present, the element tells the client the 203 specific set of XCAP operations that can be applied to create a 204 document from nothing, and result in the document whose etag is "new- 205 etag". The series of operations in the do not have to 206 be the same exact series of operations that occurred at the server. 207 The only requirement is that, if the server includes the 208 element, the sequence of events, when executed serially, will result 209 in the transformation of the document with the etag "previous-etag" 210 to the one whose etag is "new-etag". If the element is 211 not present, it means that the document has changed in some way, but 212 the XCAP server has elected not to provide the set of changes. In 213 that case, a client can retrieve the latest document if its cached 214 etag doesn't match the value of "new-etag". 216 It is important to note that a element with no child is not equivalent to a element with a child that is itself empty. The latter means that the document 219 has been assigned a new etag but its content is unchanged. The 220 former means that it has been assigned a new etag as a result of a 221 change, but the specific changes are not being reported in the XCAP 222 diff document. 224 Each element contains zero or more or 225 elements. It can also contain elements from other 226 namespaces, which allows for extensibility to other events in the 227 future. A client MUST ignore any such elements it does not 228 understand. Each element reports an HTTP DELETE 229 operation, and each element reports an HTTP PUT 230 operation. Both and have a single 231 optional attribute, "node-selector", which contains the node selector 232 in the Request URI (after removing any escape coding) of the HTTP PUT 233 or DELETE request. The server MUST include the "node-selector" when 234 the PUT or DELETE operation was against an XML element or attribute. 235 The "node-selector" attribute MUST NOT be present if the PUT or 236 DELETE operation was against the document itself. The 237 element also has the mandatory attribute "content-type", which 238 indicates the Content-Type of the HTTP PUT request. The content of 239 the element is text. This text contains the body of the 240 HTTP PUT request. If that content was an XML type (including 241 application/xcap-el+xml) that contains angle brackets, it MUST be 242 represented as CDATA. If the content did not contain angle brackets 243 (as is the case with application/xcap-att+xml), it MAY be represented 244 as CDATA. 246 4. XML Schema 248 249 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 302 5. Example Document 304 The following is an example of a document compliant to the schema. 305 Line wrapping is for readability purposes only: 307 308 312 315 316 319 Jane Doe]]> 324 325 326 327 329 This example XCAP diff document will transform the example document 330 in Section 3.3 of [14] by removing the entry for Bill Smith and 331 adding one for Jane Doe. 333 6. Usage with the Config Framework 335 The framework for user agent profile delivery [9] defines an event 336 package which can be used to subscribe to user, device, application 337 or local-network data that defines the configuration of a client. 338 This data can be present in an XCAP server. Normally, content 339 indirection [15] will be used as the NOTIFY body format, to indicate 340 the specific document that has changed, and should be re-fetched. 341 However, if the client includes an Accept header field including the 342 MIME type "application/xcap-diff+xml", the server has the option of 343 returning documents in this format instead. 345 When the client performs an initial subscription, the rules in [9] 346 are used to select the set of documents which the subscription 347 applies to. Upon initial subscription, the server does not know 348 which instances of each document (where each instance is identified 349 by an etag) the client currently posessses, if any. Indeed, upon 350 startup, the client will not have any documents. The initial NOTIFY 351 in this case MUST include a element for each document 352 associated with the subscription. The for each of those 353 elements MUST be absent. The "previous-etag" attribute 354 MUST be absent, and the "new-etag" attribute MUST be present and 355 contain the entity tag for the current version of that document 356 resource. An XCAP diff document structured this way is called a 357 "reference" XCAP diff document. It establishes the baseline etags 358 and document URIs for the documents covered by the subscription. 360 Upon receipt of this document, the client can determine whether its 361 local instance documents, if any, match the etags in the XCAP diff 362 document. If they do not match, the client SHOULD perform a 363 conditional GET for each document. The document URI is constructed 364 by appending the XCAP root in the "xcap-root" attribute of the element to the escape coded "doc-selector" from each 366 element. The request is made conditional by including an If-Match 367 header field, with the value of the etag from each 368 element. So long as the documents haven't changed between the NOTIFY 369 and the GET, the client will obtain the reference versions that the 370 server will use for subsequent notifications. 372 If the conditional GET should fail, the client SHOULD generate a 373 SUBSCRIBE refresh request to trigger a new NOTIFY. The server will 374 always generate a "reference" XML diff document on receipt of a 375 SUBSCRIBE refresh. This establishes a new set of baseline etags, and 376 the client can then attempt to do another fetch. It is anticipated 377 that future extensions to the profile delivery framework will allow a 378 client to include, in its SUBSCRIBE request, an indicator of the 379 current version of the documents it holds. That would obviate the 380 need for a potentially never-ending stream of SUBSCRIBE/GET sequences 381 should the documents be rapidly changing, for some reason. 383 Once the client has obtained the versions of the documents identified 384 in the reference XML diff, it can process NOTIFY requests on that 385 subscription. To process the NOTIFY requests, it makes sure that its 386 current version matches the version in the "previous-etag" attribute 387 of the element. It then follows the procedures of 388 Section 7. 390 Once the client has finished applying the instructions to the 391 document, it should end up with the same document the server has. To 392 verify this, the client MAY apply the mandatory XML canonicalization 393 defined in the Canonical XML 1.0 [1] specification, and computes an 394 HMAC [13] using SHA1 over this canonical document, with a key whose 395 value is 0x2238a. The resulting string is compared with the "hash" 396 attribute of the element. If they match, the client can 397 be sure that it has the most up to date version. If they don't 398 match, the client MUST flush its current version of the document from 399 memory. It can then obtain a new XCAP diff reference by sending a 400 SUBSCRIBE refresh request on the dialog. 402 Of course, this mechanism for computing the most current document 403 from the hash is optional. A client can elect to ignore the 404 information on what changed and simply fetch the most recent document 405 every time it gets a change indication where the new version is not 406 the same as the one cached by the client. Furthermore, the server 407 may elect to not send the hash, in which case this check cannot be 408 made. 410 7. Constructing a Document from the Change Log 412 When the XCAP diff document contains a element for a 413 document, and the client possesses the document instance whose etag 414 matches the "previous-etag" for the document, the client can follow 415 the procedures defined here to obtain the instance document with the 416 etag value of "new-etag". This procedure is relatively 417 straightforward, and is done by having the client emulate XCAP server 418 behavior as defined in [8] 420 The client starts with the its version of the document whose etag is 421 "previous-etag" as the current document. If there was no "previous- 422 etag", the client starts with no document. The client MUST iterate 423 through each child of , in order. For each element, it 424 MUST apply processing depending on the name of the element. 426 If the element is , the client takes the current 427 document. If the "node-selector" attribute was absent, it deletes 428 the entire document. If the "node-selector" attribute was present, 429 it selects the element or attribute using that node selector, as 430 described in Section 6.3 of [8]. Note that the node selector present 431 in the "node-selector" attribute is not escape coded, and will follow 432 the grammar defined in that section. The selected element or 433 attribute is deleted from the document, and the result becomes the 434 current document. There is no need for the client to run the 435 validity checks or idempotency checks normally performed by the 436 server; a client will always be provided with 437 operations that succeeded at the server. 439 If the element is , the client takes the current document. 440 It then computes the Request URI that was seen by the server, by 441 concatenating the XCAP root with the "doc-selector" attribute of th 442 element, appending the path separator, and then adding the 443 "node-selector" attribute of the element, if present. 444 The client then "acts" as if it were the server, having receive an 445 HTTP PUT request with the Request URI equal to this value prior to 446 escape coding, with a body of Content-Type equal to the value of the 447 "content-type" attribute, and whose body equals the value of the 448 element. It follows the logic of Section 8.2 of [8] to 449 apply the PUT, ignorning all validity checks, resource 450 interdependency computations, error processing and verification of 451 document content. The resulting document becomes the current 452 document. An actual implementation need not literally act as a 453 server; the behavior is defined in these terms to specify what the 454 correct output of the processing has to be. 456 If the element is unknown to the client, it is skipped. 458 When each child element of has been processed, the 459 current document is equal to the document on the server whose etag 460 equals "new-etag". 462 8. Security Considerations 464 XCAP diff documents contain the same information in the documents 465 whose differences they describe. As such, the security 466 considerations associated with those documents apply to XCAP diff 467 documents. 469 9. IANA Considerations 471 There are several IANA considerations associated with this 472 specification. 474 9.1 application/xcap-diff+xml MIME Type 476 MIME media type name: application 478 MIME subtype name: xcap-diff+xml 480 Mandatory parameters: none 482 Optional parameters: Same as charset parameter application/xml as 483 specified in RFC 3023 [4]. 485 Encoding considerations: Same as encoding considerations of 486 application/xml as specified in RFC 3023 [4]. 488 Security considerations: See Section 10 of RFC 3023 [4] and 489 Section 8 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace 490 XXXX with the RFC number of this specification.]]. 492 Interoperability considerations: none. 494 Published specification: This document. 496 Applications which use this media type: This document type has 497 been used to support manipulation of resource lists [14] using 498 XCAP. 500 Additional Information: 502 Magic Number: None 504 File Extension: .xdf 506 Macintosh file type code: "TEXT" 508 Personal and email address for further information: Jonathan 509 Rosenberg, jdrosen@jdrosen.net 511 Intended usage: COMMON 513 Author/Change controller: The IETF. 515 9.2 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:xcap-diff 517 This section registers a new XML namespace, as per the guidelines in 518 [6] 520 URI: The URI for this namespace is 521 urn:ietf:params:xml:ns:xcap-diff. 523 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 524 Jonathan Rosenberg (jdrosen@jdrosen.net). 526 XML: 528 BEGIN 529 530 532 533 534 536 XCAP Diff Namespace 537 538 539

Namespace for XCAP Diff

540

urn:ietf:params:xml:ns:xcap-diff

541

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

544 545 546 END 548 9.3 Schema Registration 550 This section registers a new XML schema per the procedures in [6]. 552 URI: urn:ietf:params:xml:schema:xcap-diff 554 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 555 Jonathan Rosenberg (jdrosen@jdrosen.net). 557 The XML for this schema can be found as the sole content of 558 Section 4. 560 10. References 562 10.1 Normative References 564 [1] Boyer, J., "Canonical XML Version 1.0", W3C REC REC-xml-c14n- 565 20010315, March 2001. 567 [2] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, 568 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 569 FirstEdition REC-xml-20001006, October 2000. 571 [3] Moats, R., "URN Syntax", RFC 2141, May 1997. 573 [4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 574 RFC 3023, January 2001. 576 [5] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 577 August 1999. 579 [6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 580 January 2004. 582 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 583 Levels", BCP 14, RFC 2119, March 1997. 585 [8] Rosenberg, J., "The Extensible Markup Language (XML) 586 Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-07 587 (work in progress), June 2005. 589 [9] Petrie, D., "A Framework for Session Initiation Protocol User 590 Agent Profile Delivery", draft-ietf-sipping-config-framework-06 591 (work in progress), February 2005. 593 10.2 Informative References 595 [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 596 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 597 Session Initiation Protocol", RFC 3261, June 2002. 599 [11] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 600 Notification", RFC 3265, June 2002. 602 [12] Roach, A., Rosenberg, J., and B. Campbell, "A Session 603 Initiation Protocol (SIP) Event Notification Extension for 604 Resource Lists", draft-ietf-simple-event-list-07 (work in 605 progress), January 2005. 607 [13] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 608 for Message Authentication", RFC 2104, February 1997. 610 [14] Rosenberg, J., "Extensible Markup Language (XML) Formats for 611 Representing Resource Lists", 612 draft-ietf-simple-xcap-list-usage-05 (work in progress), 613 February 2005. 615 [15] Burger, E., "A Mechanism for Content Indirection in Session 616 Initiation Protocol (SIP) Messages", 617 draft-ietf-sip-content-indirect-mech-05 (work in progress), 618 October 2004. 620 Author's Address 622 Jonathan Rosenberg 623 Cisco Systems 624 600 Lanidex Plaza 625 Parsippany, NJ 07054 626 US 628 Phone: +1 973 952-5000 629 Email: jdrosen@cisco.com 630 URI: http://www.jdrosen.net 632 Intellectual Property Statement 634 The IETF takes no position regarding the validity or scope of any 635 Intellectual Property Rights or other rights that might be claimed to 636 pertain to the implementation or use of the technology described in 637 this document or the extent to which any license under such rights 638 might or might not be available; nor does it represent that it has 639 made any independent effort to identify any such rights. Information 640 on the procedures with respect to rights in RFC documents can be 641 found in BCP 78 and BCP 79. 643 Copies of IPR disclosures made to the IETF Secretariat and any 644 assurances of licenses to be made available, or the result of an 645 attempt made to obtain a general license or permission for the use of 646 such proprietary rights by implementers or users of this 647 specification can be obtained from the IETF on-line IPR repository at 648 http://www.ietf.org/ipr. 650 The IETF invites any interested party to bring to its attention any 651 copyrights, patents or patent applications, or other proprietary 652 rights that may cover technology that may be required to implement 653 this standard. Please address the information to the IETF at 654 ietf-ipr@ietf.org. 656 Disclaimer of Validity 658 This document and the information contained herein are provided on an 659 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 660 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 661 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 662 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 663 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 664 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 666 Copyright Statement 668 Copyright (C) The Internet Society (2005). This document is subject 669 to the rights, licenses and restrictions contained in BCP 78, and 670 except as set forth therein, the authors retain all their rights. 672 Acknowledgment 674 Funding for the RFC Editor function is currently provided by the 675 Internet Society.