idnits 2.17.00 (12 Aug 2021) /tmp/idnits48164/draft-ietf-simple-xcap-package-01.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 7 instances of too long lines in the document, the longest one being 9 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 134: '...al-xcap-user" is RECOMMENDED, and SHOU...' RFC 2119 keyword, line 159: '...UBSCRIBE request MAY contain a body. T...' RFC 2119 keyword, line 176: '...o be applied. The notifier SHOULD send...' RFC 2119 keyword, line 222: '...rs and notifiers MUST support the "app...' RFC 2119 keyword, line 224: '... request MAY contain an Accept heade...' (22 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 (February 16, 2004) is 6668 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: '9' is defined on line 579, but no explicit reference was found in the text ** 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') ** Obsolete normative reference: RFC 2616 (ref. '9') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: draft-ietf-simple-xcap has been published as RFC 4825 == 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 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 4 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: August 16, 2004 February 16, 2004 5 A Session Initiation Protocol (SIP) Event Package for Modification 6 Events for the Extensible Markup Language (XML) Configuration Access 7 Protocol (XCAP) Managed Documents 8 draft-ietf-simple-xcap-package-01 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 16, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This specification defines a Session Initiation Protocol (SIP) event 39 package for finding out about changes to documents managed by the 40 Extensible Markup Language (XML) Configuration Access Protocol 41 (XCAP). XCAP allows a client to manipulate XML documents on a server 42 which contain configuration information for application protocols. 43 Multiple clients can potentially access the same document, in which 44 case the other clients would like to be notified of a change in the 45 document made by another. This event package allows a client to do 46 that. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Document Change Event Package . . . . . . . . . . . . . . . 4 52 2.1 Package Name . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.2 Event Package Parameters . . . . . . . . . . . . . . . . . . 4 54 2.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . 5 55 2.4 Subscription Duration . . . . . . . . . . . . . . . . . . . 5 56 2.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . . 6 58 2.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . . 7 59 2.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 7 60 2.9 Handling of Forked Requests . . . . . . . . . . . . . . . . 8 61 2.10 Rate of Notifications . . . . . . . . . . . . . . . . . . . 8 62 2.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . . 8 63 3. application/xml-change+xml Media Type . . . . . . . . . . . 9 64 3.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 3.2 Example Document . . . . . . . . . . . . . . . . . . . . . . 11 66 4. Security Considerations . . . . . . . . . . . . . . . . . . 13 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 68 5.1 SIP Event Package . . . . . . . . . . . . . . . . . . . . . 14 69 5.2 application/xcap-change+xml MIME Type . . . . . . . . . . . 14 70 5.3 URN Sub-Namespace Registration for 71 urn:ietf:params:xml:ns:xcap-change . . . . . . . . . . . . . 15 72 Normative References . . . . . . . . . . . . . . . . . . . . 17 73 Informative References . . . . . . . . . . . . . . . . . . . 18 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . 18 75 Intellectual Property and Copyright Statements . . . . . . . 19 77 1. Introduction 79 The Extensible Markup Language (XML) Configuration Access Protocol 80 (XCAP) [10] is a protocol that allows clients to manipulate XML 81 documents stored on a server. These XML documents serve as 82 configuration information for application protocols. As an example, 83 resource list [11] subscriptions (also known as presence lists) allow 84 a client to have a single SIP subscription to a list of users, where 85 the list is maintained on a server. The server will obtain presence 86 for those users and report it back to the client. This application 87 requires the server, called a Resource List Server (RLS), to have 88 access to the list of presentities. This list needs to be manipulated 89 by clients so they can add and remove their friends as they desire. 91 Complexities arise when multiple clients attempt to simultaneously 92 manipulate a document, such as a presence list. Frequently, a client 93 will keep a copy of the current list in memory, so it can render it 94 to users. However, if another client modifies the document, the 95 cached version becomes stale. This information must be made known to 96 all clients which have cached copies of the document, so that they 97 can fetch the most recent one. 99 This problem is addressed by this specification, which provides a 100 Session Initiation Protocol (SIP) [1]event package [2] for 101 subscribing to changes in documents managed by an XCAP server. This 102 package would be used by any client which is retaining a cached copy 103 of a document obtained by XCAP, so that it can find out when a change 104 has been made, invalidating its cached copy. In fact, the 105 notifications generated by this package indicate the specific change 106 which occurred in the document, so the client can decide whether the 107 change is significant enough to warrant a refetch from the XCAP 108 server. 110 2. Document Change Event Package 112 The SIP event framework [2] defines a SIP extension for subscribing 113 to, and receiving notifications of, events. It leaves the definition 114 of many aspects of these events to concrete extensions, known as 115 event packages. This document qualifies as an event package. This 116 section fills in the information required for all event packages by 117 RFC 3265. 119 2.1 Package Name 121 The name of this package is "xcap-change". As specified in RFC 3265 122 [2], this value appears in the Event header field present in 123 SUBSCRIBE and NOTIFY requests. 125 2.2 Event Package Parameters 127 The SIP event framework allows event packages to define additional 128 parameters carried in the Event header field. This package defines a 129 single event header parameter, called "doc-component", which 130 specifies a particular document and document component which is being 131 to subscribed to. The request-URI specifies the user whose data is 132 being subscribed to. To subscribe to global data, a user agent would 133 subscribed to a special user name that is configured into the UA. The 134 name "global-xcap-user" is RECOMMENDED, and SHOULD be used if no 135 explicit user name is provisioned. By default, a subscription is for 136 all XCAP data associated with that user. The header field parameter 137 allows the subscription to specify a specific document and document 138 sub-tree. 140 The format of this header field parameter is a quoted string. The 141 value of this string is the portion of an XCAP URI to the right of 142 the directory for the user, in the case of user data, or to the right 143 of the global directory for global data. The XCAP URI can only refer 144 to a document or to an element within that document. When the URI 145 represents a document, the subscription is to changes anywhere in the 146 document. When it is to an element, the subscription is to changes 147 that occur in the attributes or content of that element, including 148 all children. For example, if a user wishes to subscribe to http:// 149 xcap.example.com/services/presence-lists/users/joe/mydir/friends.xml, 150 the event header parameter would be "mydir/friends.xml". 152 OPEN ISSUE: There is no way to specify that a subscription is to 153 multiple documents. Multiple subscriptions would be needed for 154 that. Is that limitation OK for now? A filter can fix that down 155 the road. 157 2.3 SUBSCRIBE Bodies 159 A SUBSCRIBE request MAY contain a body. The purpose of the body 160 depends on its type. Subscriptions will normally not contain bodies. 161 The Request-URI, which identifies the user whose data is being 162 subscribed to, combined with the event package name and parameter, is 163 sufficient for this package. 165 One type of body that can be included in a SUBSCRIBE request is a 166 filter document. These filters request that only document change 167 events generate notifications, or would ask for a restriction on the 168 set of data returned in NOTIFY requests. Filter documents are not 169 specified in this document, and at the time of writing, are expected 170 to be the subject of future standardization activity. 172 Honoring of these filters is at the policy discretion of the 173 notifier. 175 If the SUBSCRIBE request does not contain a filter, this tells the 176 notifier that no filter is to be applied. The notifier SHOULD send 177 NOTIFY requests at the discretion of its own policy. 179 2.4 Subscription Duration 181 Generally speaking, changes to application configuration data are 182 relatively infrequent. Of course, this depends on the type of 183 application, but generally configuration data is static. As a result, 184 notifications are expected infrequently, and subscriptions will 185 typically be held for long periods of time. This would argue for long 186 subscription refresh intervals. For this reason, the default 187 subscription duration is two hours. Of course, a different duration 188 can be requested by a client, or set by a server, using the Expires 189 header field, as per RFC 3265 [2]. 191 2.5 NOTIFY Bodies 193 As described in RFC 3265 [2], the NOTIFY message will contain bodies 194 that describe the state of the subscribed resource. This body is in a 195 format listed in the Accept header field of the SUBSCRIBE, or a 196 package-specific default if the Accept header field was omitted from 197 the SUBSCRIBE. 199 In this event package, the body of the notification contains a 200 document change document. This document describes the current version 201 of an XML document managed by XCAP, in addition to the changes in 202 this document from the previous version. Note that a listing of 203 changes from the previous version is only sent in a NOTIFY triggered 204 by a change to the document. NOTIFY requests sent in response to an 205 initial SUBSCRIBE, or a SUBSCRIBE refresh, only indicate the current 206 version of the XML document. They do not contain the actual full 207 contents of the XML document. In other words, the resource being 208 subscribed to is NOT the XML document itself, but rather, the version 209 history for the document. 211 OPEN ISSUE: This is the main issue in this specification. There 212 are three potential scopes. The first is that subscription is to 213 the document itself, in which case a full state update in a NOTIFY 214 contains the current document. The second is a subscription to the 215 revision history, which gives you changes, but not the full state 216 of the document. The third option is to just subscribe to the 217 etag, so that you know that something changed, but the 218 notifications don't tell you anything about what changed. Which do 219 we need? The latter is the simplest, good for the case where third 220 party modification of documents is rare. 222 All subscribers and notifiers MUST support the "application/ 223 xcap-change+xml" data format described in Section 3. The subscribe 224 request MAY contain an Accept header field. If no such header field 225 is present, it has a default value of "application/xcap-change+xml". 226 If the header field is present, it MUST include "application/ 227 xcap-change+xml", and MAY include any other types capable of 228 representing changes in XCAP documents. 230 2.6 Notifier Processing of SUBSCRIBE Requests 232 This subsection defines package-specific processing at the notifier 233 when it receives a SUBSCRIBE request. General processing rules for 234 requests are covered in Section 8.2 of RFC 3261 [1], in addition to 235 general SUBSCRIBE processing in RFC 3265 [2]. 237 A notifier for this package SHOULD authenticate all subscribers. 238 Generally, subscribers will have a pre-existing relationship with the 239 notifier. This is because the principle application of this package 240 is for a client of XCAP (which will have a relationship with the XCAP 241 server) to find out about changes in cached documents. Therefore, the 242 HTTP Digest mechanism in SIP is a good match for authentication, and 243 MUST be supported by all clients and servers. Note that this 244 authentication mechanism is already mandatory for all SIP-compliant 245 implementations. 247 Once authenticated, the server SHOULD authorize the subscriber. 248 Generally, this authorization policy SHOULD mirror the authorization 249 policy defined in an XCAP application usage for read access. Thats 250 because this package provides a form of read-access, and the 251 permissions should not differ based on whether the read is performed 252 with XCAP or with a SIP SUBSCRIBE request. 254 2.7 Notifier Generation of NOTIFY Requests 256 RFC 3265 details the formatting and structure of NOTIFY messages. 257 However, packages are mandated to provide detailed information on 258 when to send a NOTIFY, how to compute the state of the resource, how 259 to generate neutral or fake state information, and whether state 260 information is complete or partial. This section describes those 261 details for the presence event package. 263 A notifier MAY send a notification at any time. Typically, it will 264 send one after a document managed by an XCAP server has changed as 265 the result of an XCAP operation. This notification contains an 266 application/xcap-change+xml document that specifies the current 267 version (as a server modification time) for the XML document being 268 subscribed to. It also contains information about what changed - 269 whether a new element or attribute was added, whether an existing one 270 changed, or whether an existing one was deleted, and indicates 271 against which version those changes were made. The xcap-change 272 document also contains a hash of the new XML document. 274 Notifications sent in response to SUBSCRIBE requests (either initial 275 or refresh), or sent when there is a change in subscription state, 276 will normally only contain the current version of the XML document 277 being subscribed to. 279 The body of the NOTIFY MUST be sent using one of the types listed in 280 the Accept header field in the most recent SUBSCRIBE request, or 281 using the type "application/xcap-change+xml" if no Accept header 282 field was present. 284 2.8 Subscriber Processing of NOTIFY Requests 286 RFC 3265 [2] leaves it to event packages to describe the process 287 followed by the subscriber upon receipt of a NOTIFY request, 288 including any logic required to form a coherent resource state. 290 In this package, the notifications can be optionally used by the 291 client to determine the state of the XML document being subscribed 292 to. When a client receives a notification, it checks the version 293 against which the changes are relative. If this is not the same as 294 the version currently cached by the client, the client SHOULD use 295 XCAP to fetch the latest version of the document. If it is the same, 296 the client applies the change to its local cache of the document. To 297 apply the changes, the client follows the procedures defined by XCAP 298 [10] as if it were the HTTP server. After applying the changes, the 299 client applies the mandatory XML canonicalization defined in the 300 Canonical XML 1.0 [3] specification, and computes an HMAC [12] using 301 SHA1 over this canonical document, with a key whose value is 0x2238a. 303 The resulting string is compared with the hash attribute of the 304 xml-change document. If they match, the client can be sure that it 305 has the most up to date version. If they don't match, the client 306 SHOULD fetch the most current version of the document. 308 Of course, this mechanism for computing the most current document 309 from the hash is optional. A client can elect to ignore the 310 information on what changed and simply fetch the most recent document 311 every time it gets a change indication where the new version is not 312 the same as the one cached by the client. 314 2.9 Handling of Forked Requests 316 RFC 3265 [2] requires each package to describe handling of forked 317 SUBSCRIBE requests. 319 This specification only allows a single dialog to be constructed as a 320 result of emitting an initial SUBSCRIBE request. Section 4.4.9 of RFC 321 3265 [2] describes the processing that is required to guarantee the 322 creation of a single dialog in response to a SUBSCRIBE request. 324 2.10 Rate of Notifications 326 RFC 3265 [2] requires each package to specify the maximum rate at 327 which notifications can be sent. A notifier SHOULD NOT generate 328 notifications at a rate of more than once every five seconds. 330 2.11 State Agents 332 RFC 3265 [2] requires each package to consider the role of state 333 agents in the package, and if they are used, to specify how 334 authentication and authorization are done. 336 State agents play no role in this package. 338 3. application/xml-change+xml Media Type 340 An xml-change document is an XML [4] document that MUST be 341 well-formed and SHOULD be valid. XML-change documents MUST be based 342 on XML 1.0 and MUST be encoded using UTF-8. This specification makes 343 use of XML namespaces for identifying xml-change documents and 344 document fragments. The namespace URI for elements defined by this 345 specification is a URN [5], using the namespace identifier 'ietf' 346 defined by [7] and extended by [8]. This URN is: 348 urn:ietf:params:xml:ns:xml-change 350 An xml-change document begins with the root element tag "documents". 351 It consists of any number of "document" sub-elements, each of which 352 conveys information on a particular document. Other elements from 353 different namespaces MAY be present for the purposes of 354 extensibility; elements or attributes from unknown namespaces MUST be 355 ignored. 357 Each "document" element consists of zero or more "change" elements, 358 each of which conveys information about a specific change to the 359 document. Other elements from different namespaces MAY be present for 360 the purposes of extensibility; elements or attributes from unknown 361 namespaces MUST be ignored. There are four attributes associated with 362 the "document" element: 364 uri: specifies the HTTP URI that identifies the document. 366 new-etag: specifies the etag of the document after the application of 367 the change. This attribute is mandatory. 369 previous-etag: specifies the etag of the version of the document 370 against which the change was made. This attribute MUST be present 371 if any change sub-elements are present. 373 hash: specifies an HMAC of the new document, represented in canonical 374 form. See Section 2.8 for details on how this value is computed. 375 This attribute MUST be present if any change sub-elements are 376 present. 378 Each "change" element contains text. This text contains the exact 379 value present in the HTTP request that caused the change in the 380 document. If that content was XML, it is represented in the 381 xml-change document as CDATA. There are two attributes associated 382 with this element: 384 uri: contains the URI that the HTTP request contained in the 385 Request-URI. This attribute is mandatory. 387 method: contains the method of the HTTP request. This attribute is 388 mandatory. 390 OPEN ISSUE: Probably it would be better to describe the changes 391 more generically, rather than binding them to the specifics of 392 XCAP. Indeed, if there is any non-determinism in how the server 393 computes the document resulting from an XCAP operation, this 394 approach will not work. We can either use patch or define a 395 specific XML patch format. 397 3.1 XML Schema 399 400 404 405 406 407 408 409 410 411 413 414 415 416 417 418 419 420 422 423 424 425 426 427 428 429 430 431 433 3.2 Example Document 435 The following is an example of a document compliant to the schema: 437 438 439 444 447 448 450 4. Security Considerations 452 The security considerations for this package are similar to those of 453 XCAP. The configuration data can contain sensitive information, and 454 both the client and the server need to authenticate each other. As 455 such, a notifier for this package MUST support HTTP Digest to 456 authenticate subscribers. Notifiers and subscribers MAY use SIPs S/ 457 MIME feature to provide authentication and message integrity. 459 5. IANA Considerations 461 There are several IANA considerations associated with this 462 specification. 464 5.1 SIP Event Package 466 This specification registers an event package, based on the 467 registration procedures defined in RFC 3265 [2]. The following is the 468 information required for such a registration: 470 Package Name: xml-change 472 Package or Template-Package: This is a package. 474 Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX 475 with the RFC number of this specification). 477 Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net. 479 5.2 application/xcap-change+xml MIME Type 481 MIME media type name: application 483 MIME subtype name: xcap-change+xml 485 Mandatory parameters: none 487 Optional parameters: Same as charset parameter application/xml as 488 specified in RFC 3023 [6]. 490 Encoding considerations: Same as encoding considerations of 491 application/xml as specified in RFC 3023 [6]. 493 Security considerations: See Section 10 of RFC 3023 [6] and 494 Section 4 of this specification. 496 Interoperability considerations: none. 498 Published specification: This document. 500 Applications which use this media type: This document type has 501 been used to support manipulation of presence lists [13] using 502 XCAP. 504 Additional Information: 506 Magic Number: None 508 File Extension: .xcd or .xml 510 Macintosh file type code: "TEXT" 512 Personal and email address for further information: Jonathan 513 Rosenberg, jdrosen@jdrosen.net 515 Intended usage: COMMON 517 Author/Change controller: The IETF. 519 5.3 URN Sub-Namespace Registration for 520 urn:ietf:params:xml:ns:xcap-change 522 This section registers a new XML namespace, as per the guidelines in 523 [8] 525 URI: The URI for this namespace is 526 urn:ietf:params:xml:ns:xcap-change. 528 Registrant Contact: IETF, SIMPLE working group, 529 (simple@mailman.dynamicsoft.com), Jonathan Rosenberg 530 (jdrosen@jdrosen.net). 532 XML: 534 BEGIN 535 536 538 539 540 542 XCAP Change Namespace 543 544 545

Namespace for XCAP Change

546

urn:ietf:params:xml:ns:change-xml

547

See RFCXXXX.

548 549 550 END 552 Normative References 554 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 555 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 556 Session Initiation Protocol", RFC 3261, June 2002. 558 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 559 Notification", RFC 3265, June 2002. 561 [3] Boyer, J., "Canonical XML Version 1.0", W3C REC 562 REC-xml-c14n-20010315, March 2001. 564 [4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 565 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 566 FirstEdition REC-xml-20001006, October 2000. 568 [5] Moats, R., "URN Syntax", RFC 2141, May 1997. 570 [6] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 571 3023, January 2001. 573 [7] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 574 August 1999. 576 [8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 577 January 2004. 579 [9] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 580 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 581 HTTP/1.1", RFC 2616, June 1999. 583 [10] Rosenberg, J., "The Extensible Markup Language (XML) 584 Configuration Access Protocol (XCAP)", 585 draft-ietf-simple-xcap-01 (work in progress), October 2003. 587 Informative References 589 [11] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation 590 Protocol (SIP) Event Notification Extension for Resource 591 Lists", draft-ietf-simple-event-list-04 (work in progress), 592 June 2003. 594 [12] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 595 for Message Authentication", RFC 2104, February 1997. 597 [13] Rosenberg, J., "An Extensible Markup Language (XML) 598 Configuration Access Protocol (XCAP) Usage for Presence 599 Lists", draft-ietf-simple-xcap-list-usage-01 (work in 600 progress), October 2003. 602 Author's Address 604 Jonathan Rosenberg 605 dynamicsoft 606 600 Lanidex Plaza 607 Parsippany, NJ 07054 608 US 610 Phone: +1 973 952-5000 611 EMail: jdrosen@dynamicsoft.com 612 URI: http://www.jdrosen.net 614 Intellectual Property Statement 616 The IETF takes no position regarding the validity or scope of any 617 intellectual property or other rights that might be claimed to 618 pertain to the implementation or use of the technology described in 619 this document or the extent to which any license under such rights 620 might or might not be available; neither does it represent that it 621 has made any effort to identify any such rights. Information on the 622 IETF's procedures with respect to rights in standards-track and 623 standards-related documentation can be found in BCP-11. Copies of 624 claims of rights made available for publication and any assurances of 625 licenses to be made available, or the result of an attempt made to 626 obtain a general license or permission for the use of such 627 proprietary rights by implementors or users of this specification can 628 be obtained from the IETF Secretariat. 630 The IETF invites any interested party to bring to its attention any 631 copyrights, patents or patent applications, or other proprietary 632 rights which may cover technology that may be required to practice 633 this standard. Please address the information to the IETF Executive 634 Director. 636 Full Copyright Statement 638 Copyright (C) The Internet Society (2004). All Rights Reserved. 640 This document and translations of it may be copied and furnished to 641 others, and derivative works that comment on or otherwise explain it 642 or assist in its implementation may be prepared, copied, published 643 and distributed, in whole or in part, without restriction of any 644 kind, provided that the above copyright notice and this paragraph are 645 included on all such copies and derivative works. However, this 646 document itself may not be modified in any way, such as by removing 647 the copyright notice or references to the Internet Society or other 648 Internet organizations, except as needed for the purpose of 649 developing Internet standards in which case the procedures for 650 copyrights defined in the Internet Standards process must be 651 followed, or as required to translate it into languages other than 652 English. 654 The limited permissions granted above are perpetual and will not be 655 revoked by the Internet Society or its successors or assignees. 657 This document and the information contained herein is provided on an 658 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 659 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 660 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 661 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 662 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 664 Acknowledgment 666 Funding for the RFC Editor function is currently provided by the 667 Internet Society.