idnits 2.17.1 draft-urpalainen-sip-xcap-diff-event-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 553. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 476 has weird spacing: '... Change in...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: During the initial subscription the notifier must first resolve the requested XCAP resources. Once there are superfluous resource selections in the requested URI list, the notifier SHOULD not provide overlapping similar responses for these resources. Only the resources where the authenticated user has read privilege will be included in the XCAP-Diff format. Note that for example, an XCAP component which could not be located with XCAP semantics, does not produce an error. Instead, the request remains in "pending" state, that is, waiting for this resource to be created. Subscriptions to collections have a similar property: once a new document is created into the subscribed collection, the creation of a new resource is notified with the next NOTIFY request. After the authorized XCAP resources are known, the notifier will generate the first full response with the list of found and authorized resources. At this time depending on the "diff-processing" parameter, the notifier typically starts also the follow-up of XCAP component updates and unless otherwise directed, it reports all individual XCAP component updates with ETag changes to the subscriber. If the notifier process receives then a re-subscription with the diff-processing=aggregate value it MUST re-send the current full XML-Diff content unless the request or body can be suppressed with the SubNot-Etags [I-D.ietf-sip-subnot-etags] semantics by using e.g. the header Suppress-Notify-If-Match: xxxx. The notifier SHOULD then start to aggregate "diff-processing". -- 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 (November 16, 2007) is 6005 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-14) exists of draft-ietf-simple-xcap-diff-06 == Outdated reference: A later version (-04) exists of draft-ietf-simple-xml-patch-ops-03 == Outdated reference: A later version (-10) exists of draft-ietf-simple-partial-notify-09 == Outdated reference: A later version (-03) exists of draft-ietf-sip-subnot-etags-01 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP J. Urpalainen 3 Internet-Draft Nokia 4 Intended status: Standards Track November 16, 2007 5 Expires: May 19, 2008 7 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) 8 Diff Event Package 9 draft-urpalainen-sip-xcap-diff-event-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 19, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes an "xcap-diff" SIP event package, with the 43 aid of which clients can receive notifications of the partial changes 44 of Extensible Markup Language (XML) Configuration Access Protocol 45 (XCAP) resources. The initial synchronization and document updates 46 are based on using the XCAP-Diff format. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. XCAP-Diff Event Package . . . . . . . . . . . . . . . . . . . 4 54 4.1. XCAP-Diff Processing . . . . . . . . . . . . . . . . . . . 4 55 4.2. Event Package Name . . . . . . . . . . . . . . . . . . . . 4 56 4.3. 'diff-processing' Event Package Parameter . . . . . . . . 5 57 4.4. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 5 58 4.5. Subscription Duration . . . . . . . . . . . . . . . . . . 6 59 4.6. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 6 60 4.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 6 61 4.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 8 62 4.9. Handling of Forked Requests . . . . . . . . . . . . . . . 8 63 4.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 8 64 4.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 8 65 5. An Initial Example NOTIFY document . . . . . . . . . . . . . . 9 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 6.1. Registration of the "xcap-diff" Event Package . . . . . . 11 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 Intellectual Property and Copyright Statements . . . . . . . . . . 14 76 1. Introduction 78 The SIP Events framework [RFC3265] describes subscription and 79 notification conventions for the SIP [RFC3261] protocol. The 80 Extensible Markup Language (XML) [W3C.REC-xml-20060816] Configuration 81 Access Protocol (XCAP) [RFC4825] allows a client to read, write and 82 modify XML formatted application usage data in an XCAP server. 84 While XCAP allows several authorized users or devices to modify the 85 same XML document, XCAP does not provide an effective synchronization 86 mechanism (except polling) to keep resources equivalent between the 87 server and the client. This memo defines an "xcap-diff" event 88 package that, together with the SIP event notification framework 89 [RFC3265] and the XCAP-diff format [I-D.ietf-simple-xcap-diff], 90 allows a user to subscribe to changes in an XML document, and to 91 receive notifications whenever a change in an XML document takes 92 place. It is also possible to subscribe to documents within some 93 collection, the notifier provides those documents where the user has 94 read privilege. 96 Before being able to apply any patches into documents, a client needs 97 to first retrieve initial reference documents. With XCAP, this is 98 done with the HTTP [RFC2616] protocol. The first "xcap-diff" 99 notification thus contains references to subscribed documents, 100 thereafter notifications MAY contain patches to these documents. 101 Optionally some clients MAY want to retrieve only specific element or 102 attribute content from these XCAP documents. All this information 103 can be transformed with the XCAP-Diff [I-D.ietf-simple-xcap-diff] 104 format. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119, BCP 14 111 [RFC2119] and indicate requirement levels for compliant 112 implementations. 114 3. Definitions 116 The following terms are used in this document: 118 XCAP Component: An XML element or an attribute, which can be updated 119 with the XCAP protocol. 121 Aggregating: While XCAP clients update only single XCAP components 122 at a time, several of these modifications can be aggregated 123 together with the XML-Patch-Ops semantics. 125 4. XCAP-Diff Event Package 127 4.1. XCAP-Diff Processing 129 When a client starts the "xcap-diff" subscription they may not be 130 aware of all the XCAP resources they are subscribing to. This may 131 for instance happen when the user subscribes to his/her collection 132 [RFC4918] of a given XCAP Application Usage. The initial 133 notification will then contain references to documents the user is 134 authorized to read. After receiving these documents and resolving 135 the initial synchronization stage, the subsequent notifications MAY 136 contain patches to these documents. 138 While the initial document synchronization is based on separate HTTP 139 retrievals of full documents, XML elements or attributes may be 140 received "in-band", that is within the notification 141 format. For example, the subscribed element has different semantics 142 than XML-Patch-Ops [I-D.ietf-simple-xml-patch-ops] elements, because 143 the intent is just to get the content of an element without the need 144 of a separate HTTP GET request. If during the initial subscription 145 stage the requested node can not be found, there is not any need for 146 a result element or an attribute either. Once they will be created, 147 the notify will contain their content. And similarly, their removals 148 will be reported, for example after a successful HTTP DELETE request. 150 In another usage scenario, a subscriber to the "xcap-diff" event 151 might not need XML-Patch operations at all. Indeed, the subscriber 152 just wants to be informed that an update has happened, but the 153 subscriber is not interested in learning the actual changes in the 154 document(s). The XCAP-Diff [I-D.ietf-simple-xcap-diff] format will 155 then only indicate document creations, updates and removals. 157 4.2. Event Package Name 159 The name of this event package is "xcap-diff". This package name is 160 carried in the Event and Allow-Events header, as defined in RFC3265 161 [RFC3265]. 163 4.3. 'diff-processing' Event Package Parameter 165 The optional "diff-processing" parameter will tell the notifier how 166 to apply the "XML diffing process". The possible values are "no- 167 patching", "xcap-patching", "aggregate". The "no-patching" value 168 means that only document or XCAP component existences MUST be 169 indicated. The "xcap-patching" value means that all individual XCAP 170 component updates with entity tag (ETag) changes MUST be indicated. 171 The "aggregate" value means that the notifier is free to aggregate 172 several individual XCAP component updates into a single XCAP-Diff 173 element. If the subscription does not contain this 174 additional "diff-processing" parameter, the notifier MUST send all 175 individual changes so that the client receives the full ETag change 176 history of a document. In other words, "xcap-patching" is the 177 default mode. 179 The formal grammar (RFC4234 [RFC4234]) of the "diff-processing" 180 parameter: 182 diff-processing = "diff-processing" EQUALS 183 "aggregate" / "no-patching" / 184 "xcap-patching" / token 186 4.4. SUBSCRIBE Bodies 188 When generating the subscribe request, the subscriber needs to define 189 the resources it is interested in getting information. This can be 190 done simply by sending a URI list to the SIP notifier. This list can 191 be described with the XCAP resource list [RFC4826] document format. 192 Only a simple subset of that format is needed here, i.e. a flat list 193 of XCAP URIs. The usage of hierarchical lists and 194 references, etc. can thus be discarded. However, using this format 195 allows adding some future semantics to these subscriptions. Also it 196 is anticipated that the XCAP server will be collocated with the SIP 197 notifier so relative XCAP URIs MAY be used. Note that although the 198 node-selector of XCAP allows requesting all in-scope namespaces of an 199 element, it is disallowed to subscribe to them with this package. 201 Figure 1 shows an example to a subscription of several XCAP 202 resources: a "resource-list" document, a specific element in a "rls- 203 services" document and a collection in "pidf-manipulation" 204 Application Usage. For all of these resources the client MUST have 205 read privilege in order to actually receive them in a NOTIFY request. 206 The "Content-Type" header of this SUBSCRIBE request is "application/ 207 resource-lists+xml". 209 210 211 212 213 215 216 217 219 Figure 1: Example subscription body 221 Note that when collections are being selected as "pidf-manipulation" 222 in the example, the conventions applied follow the WebDAV [RFC4918] 223 semantics, that is, the subscriber MUST add the forward slash "/" 224 character to the end of the path segment. 226 4.5. Subscription Duration 228 The default expiration time for subscriptions within this package is 229 3600 seconds. As per RFC 3265 [RFC3265], the subscriber MAY specify 230 an alternative expiration timer in the Expires header field. 232 4.6. NOTIFY Bodies 234 The NOTIFY bodies will follow the conventions of the XCAP-Diff format 235 [I-D.ietf-simple-xcap-diff]. 237 4.7. Notifier Generation of NOTIFY Requests 239 During the initial subscription the notifier must first resolve the 240 requested XCAP resources. Once there are superfluous resource 241 selections in the requested URI list, the notifier SHOULD not provide 242 overlapping similar responses for these resources. Only the 243 resources where the authenticated user has read privilege will be 244 included in the XCAP-Diff format. Note that for example, an XCAP 245 component which could not be located with XCAP semantics, does not 246 produce an error. Instead, the request remains in "pending" state, 247 that is, waiting for this resource to be created. Subscriptions to 248 collections have a similar property: once a new document is created 249 into the subscribed collection, the creation of a new resource is 250 notified with the next NOTIFY request. After the authorized XCAP 251 resources are known, the notifier will generate the first full 252 response with the list of found and authorized resources. At this 253 time depending on the "diff-processing" parameter, the notifier 254 typically starts also the follow-up of XCAP component updates and 255 unless otherwise directed, it reports all individual XCAP component 256 updates with ETag changes to the subscriber. If the notifier process 257 receives then a re-subscription with the diff-processing=aggregate 258 value it MUST re-send the current full XML-Diff content unless the 259 request or body can be suppressed with the SubNot-Etags 260 [I-D.ietf-sip-subnot-etags] semantics by using e.g. the header 261 Suppress-Notify-If-Match: xxxx. The notifier SHOULD then start to 262 aggregate "diff-processing". 264 It MAY happen in some corner cases that the notifier can not or will 265 not provide patches with the XML-Patch-Ops 266 [I-D.ietf-simple-xml-patch-ops] semantics. One example of this is 267 when the diff format produces a larger content than the original 268 document is. When this happens, and if the server has been in this 269 diff "aggregation" mode, it MUST fall back to the "xcap-patching" 270 mode for this particular resource. 272 It should be noted that the whole diff-processing is truly 273 implementation specific and in essence, also OPTIONAL. If the server 274 so desires, it MAY elect not to produce XML-diffing at all although 275 it is RECOMMENDED to implement it. Support for XCAP component 276 subscriptions is mandatory in the server, however. Note that if for 277 example, the subscriber has selected too many elements to subscribe, 278 so that the notification body becomes impractically large, the 279 notifier MAY discard the element content. The existence of elements 280 is indicated with an empty element but the content is not shown for 281 those resources. 283 Event packages like this require in practice a reliable transfer of 284 events. This means that all events MUST be successfully transfered 285 as otherwise patching will most likely fail or at least the document 286 content becomes to be different. RFC 3265 [RFC3265] proposes 287 utilization of a "version" attribute information to state deltas in 288 chapter 4.4. Partial-PIDF-Notify [I-D.ietf-simple-partial-notify] 289 requires that notifiers will not send a new request to the same 290 dialog unless a successful response (200 OK) has been received for 291 the last request. The latter applies also to this "xcap-diff" event 292 package. If the NOTIFY request fails due to a timeout condition, the 293 notifier MUST remove the subscription. 295 4.8. Subscriber Processing of NOTIFY Requests 297 The first NOTIFY request will typically contain references to HTTP 298 resources including their strong ETag values. If the subscriber does 299 not have similar locally cached versions, it will start an 300 unconditional HTTP GET request for those resources. During this HTTP 301 retrieval time it MAY also receive patches to these documents 302 (notifications) if they are changing frequently. So it MAY happen 303 that the subscriber receives newer versions (with HTTP) than what was 304 indicated in the initial notification. However, once all atomic XCAP 305 modifications are indicated with both previous and new ETags of each 306 resource, it is easy to chain the modification list for a document 307 and possibly omit some of the patches based on the received ETag 308 (with HTTP) of a document. After that the subscriber MAY send a re- 309 subscription to start the diff "aggregation" on the server. 311 The subscriber can use CSeq values to keep track of possible missing 312 requests. These values can be used to detect missing events also if 313 there are no multiple usages in the current "xcap-diff" dialog. The 314 event bodies, i.e. failing patches and especially the consistent ETag 315 value changes MAY also be used to detect possible missing events. 316 Once the client detects an error it MUST renew the subscription. 318 If a diff format can not be applied because of some patching errors, 319 look Section 5.1 of [I-D.ietf-simple-xml-patch-ops], the subscriber 320 SHOULD fall back to not to enable any patching within the 321 subscription. It is hardly reasonable to signal this error to the 322 notifier even if the error exists in the notifier process. 324 4.9. Handling of Forked Requests 326 This specification only allows a single dialog to be constructed as a 327 result of emitting an initial SUBSCRIBE request. In case a SUBSCRIBE 328 request is forked and the subscriber receives forked responses, the 329 subscriber MUST apply the procedures indicated in Section 4.4.9 of 330 RFC 3265 [RFC3265] for handling non-allowed forked requests. 332 4.10. Rate of Notifications 334 Notifiers of "xcap-diff" event package SHOULD NOT generate 335 notifications for a single user at a rate of more than once every 336 five seconds. 338 4.11. State Agents 340 State agents play no role in this package. 342 5. An Initial Example NOTIFY document 344 Figure 2 shows an example initial XCAP-Diff document provided by the 345 first NOTIFY request. The subscriber used the list as in the example 346 in Figure 1. An example event header of this SUBSCRIBE request: 348 Event: xcap-diff; diff-processing=aggregate 350 The subscriber requests the notifier to actually "aggregate" XCAP 351 component updates together. It is anticipated that the subsequent 352 notifications would contain aggregated patches to these documents. 354 Note: If these documents are changing frequently during the 355 initial synchronization stage, it may happen that the subscriber 356 can not synchronize the contents of all documents properly. 357 However, the subscriber can always begin with the default "xcap- 358 patching" mode where all individual changes with the full ETag 359 change history are shown and this issue does not occur. Also a 360 future extension to XCAP specification MAY solve this versioning 361 issue in a better way. 363 364 367 370 373 379 380 381 382 383 384 presence 385 386 388 390 Figure 2: An example initial XCAP-Diff document 392 Note that the resource-list "index" document included only the new 393 ETag value, as the document existed during the subscription time 394 (resource was not created, it just exists by the subscription time). 395 In the "pidf-manipulation" collection there was only a single 396 document where the user had read privilege. The element 397 existed within the rls-services "index" document and its content was 398 shown. 400 6. IANA Considerations 402 This memo calls for IANA to: 404 o register a new package name per [RFC3265]. 406 6.1. Registration of the "xcap-diff" Event Package 408 This specification instructs IANA to register an event package in the 409 SIP Event Types Namespace, based on the registration procedures 410 defined in RFC 3265 [RFC3265]. The following is the information 411 required for such a registration: 413 Package Name: xcap-diff 415 Package or Template-Package: This is a package. 417 Published Document: RFCXXXX 419 Person to Contact: Jari Urpalainen, jari.urpalainen@nokia.com 421 7. Security Considerations 423 This document defines a new SIP event package for the SIP event 424 notification framework specified in RFC 3265 [RFC3265]. As such, all 425 the Security considerations of RFC 3265 [RFC3265] apply. The 426 configuration data can contain sensitive information, and both the 427 client and the server need to authenticate each other. XCAP provides 428 basic authorization policy for resources. Notifiers and subscribers 429 MAY use S/MIME feature to provide authentication and message 430 integrity. This is described in Section 23 of RFC 3261 [RFC3261]. 432 8. Acknowledgments 434 The author would like to thank Jonathan Rosenberg for his valuable 435 comments and providing the initial event package, and Miguel Garcia, 436 Pavel Dostal, Krisztian Kiss, Anders Lindgren and Sofie Lassborn for 437 their valuable comments. 439 9. References 441 9.1. Normative References 443 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 444 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 445 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 447 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 448 A., Peterson, J., Sparks, R., Handley, M., and E. 449 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 450 June 2002. 452 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 453 Event Notification", RFC 3265, June 2002. 455 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 456 Specifications: ABNF", RFC 4234, October 2005. 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, March 1997. 461 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 462 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 464 [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats 465 for Representing Resource Lists", RFC 4826, May 2007. 467 [W3C.REC-xml-20060816] 468 Maler, E., Paoli, J., Bray, T., Yergeau, F., and C. 469 Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 470 (Fourth Edition)", World Wide Web Consortium 471 Recommendation REC-xml-20060816, August 2006, 472 . 474 [I-D.ietf-simple-xcap-diff] 475 Urpalainen, J. and J. Rosenberg, "An Extensible Markup 476 Language (XML) Document Format for Indicating A Change in 477 XML Configuration Access Protocol (XCAP) Resources", 478 draft-ietf-simple-xcap-diff-06 (work in progress), 479 August 2007. 481 [I-D.ietf-simple-xml-patch-ops] 482 Urpalainen, J., "An Extensible Markup Language (XML) Patch 483 Operations Framework Utilizing XML Path Language (XPath) 484 Selectors", draft-ietf-simple-xml-patch-ops-03 (work in 485 progress), August 2007. 487 9.2. Informative References 489 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed 490 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 492 [I-D.ietf-simple-partial-notify] 493 Lonnfors, M., "Session Initiation Protocol (SIP) extension 494 for Partial Notification of Presence Information", 495 draft-ietf-simple-partial-notify-09 (work in progress), 496 February 2007. 498 [I-D.ietf-sip-subnot-etags] 499 Niemi, A., "An Extension to Session Initiation Protocol 500 (SIP) Events for Conditional Event Notification", 501 draft-ietf-sip-subnot-etags-01 (work in progress), 502 August 2007. 504 Author's Address 506 Jari Urpalainen 507 Nokia 508 Itamerenkatu 11-13 509 Helsinki 00180 510 Finland 512 Phone: +358 7180 37686 513 Email: jari.urpalainen@nokia.com 515 Full Copyright Statement 517 Copyright (C) The IETF Trust (2007). 519 This document is subject to the rights, licenses and restrictions 520 contained in BCP 78, and except as set forth therein, the authors 521 retain all their rights. 523 This document and the information contained herein are provided on an 524 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 525 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 526 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 527 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 528 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 529 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 531 Intellectual Property 533 The IETF takes no position regarding the validity or scope of any 534 Intellectual Property Rights or other rights that might be claimed to 535 pertain to the implementation or use of the technology described in 536 this document or the extent to which any license under such rights 537 might or might not be available; nor does it represent that it has 538 made any independent effort to identify any such rights. Information 539 on the procedures with respect to rights in RFC documents can be 540 found in BCP 78 and BCP 79. 542 Copies of IPR disclosures made to the IETF Secretariat and any 543 assurances of licenses to be made available, or the result of an 544 attempt made to obtain a general license or permission for the use of 545 such proprietary rights by implementers or users of this 546 specification can be obtained from the IETF on-line IPR repository at 547 http://www.ietf.org/ipr. 549 The IETF invites any interested party to bring to its attention any 550 copyrights, patents or patent applications, or other proprietary 551 rights that may cover technology that may be required to implement 552 this standard. Please address the information to the IETF at 553 ietf-ipr@ietf.org. 555 Acknowledgment 557 Funding for the RFC Editor function is provided by the IETF 558 Administrative Support Activity (IASA).