idnits 2.17.1 draft-ietf-simple-partial-notify-10.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 667. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 678. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 691. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (January 21, 2008) is 5902 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 3265 (ref. '6') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 4346 (ref. '7') (Obsoleted by RFC 5246) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE WG M. Lonnfors 3 Internet-Draft J. Costa-Requena 4 Intended status: Standards Track E. Leppanen 5 Expires: July 24, 2008 Nokia 6 H. Khartabil 7 January 21, 2008 9 Session Initiation Protocol (SIP) extension for Partial Notification of 10 Presence Information 11 draft-ietf-simple-partial-notify-10 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on July 24, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 By default, presence delivered using the Presence Event Package for 45 the Session Initiation Protocol (SIP) is represented in the Presence 46 Information Data Format (PIDF). A PIDF document contains a set of 47 elements, each representing a different aspect of the presence being 48 reported. When any subset of the elements change, even just a single 49 element, a new document containing the full set of elements is 50 delivered. This memo defines an extension allowing delivery of only 51 the presence data that has actually changed. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Introduction to the partial notification mechanism . . . . . . 3 58 3.1. Basic presence agent operation . . . . . . . . . . . . . . 4 59 3.2. Operation with partial notification . . . . . . . . . . . 4 60 4. Client and server operations . . . . . . . . . . . . . . . . . 4 61 4.1. Content-type for partial notifications . . . . . . . . . . 5 62 4.2. Watcher generation of SUBSCRIBE requests . . . . . . . . . 5 63 4.3. Presence agent processing of SUBSCRIBE requests . . . . . 5 64 4.4. Presence agent generation of partial notifications . . . . 5 65 4.5. Watcher processing of NOTIFY requests . . . . . . . . . . 6 66 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 8.1. Normative references . . . . . . . . . . . . . . . . . . . 13 71 8.2. Informative references . . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 73 Intellectual Property and Copyright Statements . . . . . . . . . . 16 75 1. Introduction 77 A presence event package for Session Initiation Protocol (SIP) [3] 78 allow users ('watchers') to subscribe to other users' 79 ('presentities') presence information. The presence information is 80 composed of multiple pieces of data that are delivered to the 81 watcher. The size of the presence information document can be large 82 (i.e. the presence document can contain an arbitrary number of 83 elements called presence tuples that convey data). As specified in 84 RFC2778 [9] and the presence event package for SIP [3], a Presence 85 Agent (PA) always delivers in presence notifications all the presence 86 data that has been authorized for a certain watcher. This is done 87 regardless of what presence data has changed compared to last 88 notification. It may not be reasonable to send the complete presence 89 information over low bandwidth and high latency links when only part 90 of the presence information has actually changed. This may end up 91 degrading the presence service and causing bad perception at the 92 watcher side. 94 This document defines a partial notification approach where the 95 presence server delivers to the watchers only those parts of the 96 presence information that have changed compared to the presence 97 information sent in the previous notifications. This reduces the 98 amount of data that is transported over the network. 100 This mechanism utilizes the presence event package for SIP [3] and a 101 new MIME type for carrying partial Presence Information Data Format 102 documents [2]. 104 2. Conventions 106 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 107 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 108 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 109 indicate requirement levels for compliant implementations. 111 This document makes use of the vocabulary defined in RFC2778 [9], 112 RFC3265 [6], the presence event package for SIP [3], and the PIDF 113 extension for Partial Presence [2]. 115 3. Introduction to the partial notification mechanism 117 This chapter briefly introduces the regular functionality of the 118 presence service, and gives an overview of the partial notification 119 solution. This section is informational in nature. It does not 120 contain any normative statements. 122 3.1. Basic presence agent operation 124 The presence service normally operates so that a watcher sends a SIP 125 SUBSCRIBE request targeted to the presentity. The request is routed 126 to the presence agent where the presentity's presence information is 127 stored. The SUBSCRIBE request can include an Accept header field 128 that indicates the supported content types. 130 The presence agent receives the SUBSCRIBE request and if there is no 131 Accept header indicating the supported content types or the Accept 132 header contains the default PIDF content type, the PA will generate 133 presence notifications using the default PIDF format [5]. The PIDF 134 document can contain one or multiple XML elements. The PIDF document 135 include a set of elements defined in RFC2778 [9] and its extensions 136 for representing the presence information. This PIDF document will 137 be carried in the body of a NOTIFY request constructed as per RFC3265 138 [6]. During basic operation, the presence document always contains 139 the full state corresponding to the presence status of the 140 presentity, as determined by the PA local policy and authorization 141 rules. 143 3.2. Operation with partial notification 145 The partial notification mechanism allows a watcher to request that, 146 whenever possible, notifications contain only presence information 147 that has actually changed. A watcher that wants to receive partial 148 notifications according to this document, creates a SIP SUBSCRIBE 149 request similar to that of a regular presence subscription. However, 150 the SIP SUBSCRIBE request contains an Accept header field whose value 151 contains the "application/pidf-diff+xml" tag as well as the 152 "application/pidf+xml" tag. 154 When the presence agent receives the subscription, it examines the 155 Accept header field value and if the "application/pidf-diff+xml" 156 value is present, it can decide to use the partial notifications 157 mechanism specified in this memo. The presence agent builds NOTIFY 158 requests that contain the Content-Type header field set to 159 "application/pidf-diff+xml". The first NOTIFY request that contains 160 presence information will contain a full presence document. 161 Subsequent NOTIFY requests can contain partial presence documents. 162 This behavior is described in detail in Section 4. 164 4. Client and server operations 166 Unless otherwise specified in this document, the regular watcher and 167 presence agent behavior is applied as defined in the SIP presence 168 event package [3]. 170 4.1. Content-type for partial notifications 172 Entities supporting the partial notification extension described in 173 this document MUST support the 'application/pidf-diff+xml' content- 174 type specified in the PIDF extension for partial presence [2]. 176 4.2. Watcher generation of SUBSCRIBE requests 178 A SUBSCRIBE request can be used to negotiate the preferred content 179 type to be used in the notifications. The Accept header field is 180 used for this purpose as specified in RFC3261 [4]. When a watcher 181 wants to allow the presence agent to send partial notifications the 182 watcher MUST include an Accept header field in its SUBSCRIBE request. 183 The value of the Accept header field MUST contain 'application/ 184 pidf-diff+xml' (in addition to 'application/pidf+xml' required by the 185 SIP presence event package [3]). The watcher MAY include a "q" 186 parameter with each Accept value to indicate the relative preference 187 of that value. 189 4.3. Presence agent processing of SUBSCRIBE requests 191 The presence agent receives subscriptions from watchers and generates 192 notifications according to the SIP presence event package [3]. If 193 the watcher has indicated the supported content types in the Accept 194 header field of the SUBSCRIBE request, the presence agent compares 195 the values included in the Accept header field with the supported 196 ones, and decides which one to use. If the watcher has indicated 197 preferred accept values by means of "q" parameters, the presence 198 agent SHOULD base the decision on those preferences, unless otherwise 199 indicated by the presence agent local policy. 201 4.4. Presence agent generation of partial notifications 203 Once a subscription is accepted and installed, the PA MUST deliver 204 the full state of the presence information in the first partial 205 notification that contains a presence document having 206 root element. If the presence agent decides to send notifications 207 that include a presence document according to this specification, the 208 presence agent MUST build a presence document according to the PIDF 209 extension for Partial Presence [2] and MUST set the Content-Type 210 header field to the value 'application/pidf-diff+xml'. 212 When using the 'application/pidf-diff+xml' MIME type the PA MUST 213 include a "version" attribute and for the first partial notification 214 (within a given subscription) the PA MUST initialize version to value 215 one (1). This version counter is scoped to the subscription, and is 216 incremented by one within each partial notification. The version 217 value is only reset when the given subscription is terminated. It is 218 not reset when the subscription is refreshed. 220 When the PA generates a partial presence document, the PA SHOULD 221 include only that presence information that has changed compared to 222 the previous notifications. It is up to the PA's local policy to 223 determine what is considered as a change to the previous state. 225 The PA MUST construct the partial presence document according to the 226 following logic: 228 o The PA MUST construct the presence information according to the 229 PIDF extension for Partial Presence [2]. All the information that 230 have been added to the presence document are listed inside 231 elements. All information that have been removed from the 232 presence document are listed inside elements and all 233 information that have been changed are listed under 234 elements. 236 o The PA MUST include a "version" attribute in the presence 237 document. The PA MUST increment the version number by one 238 compared to the earlier successfully sent presence document in the 239 PIDF extension for Partial Presence [2] format to the watcher 240 associated with a certain subscription. 242 The PA MUST NOT send a new NOTIFY request that contains a partial 243 notification for the same Request-URI until it has received a final 244 response from the watcher for the previous one or the previous NOTIFY 245 request has timed out. 247 When the PA receives a SUBSCRIBE request (refresh or termination) 248 within the associated subscription, it SHOULD send a NOTIFY request 249 containing the full presence document. 251 If the PA has used other than the 'application/pidf-diff+xml' content 252 type in notifications within the existing subscription, and changes 253 to deliver partial notifications, the PA MUST deliver the full state 254 of the presence information containing a presence document having 255 root element as the first partial notification. 257 4.5. Watcher processing of NOTIFY requests 259 Watcher processes all NOTIFY requests that contain 'application/ 260 pidf+xml' content type as specified in RFC3856 [3]. 262 When the watcher receives the first notification containing the 263 'application/pidf-diff+xml' MIME body the watcher MUST initialize an 264 internal version counter, related to this subscription, to the value 265 of the "version" included in the presence document. This version 266 counter is scoped to the subscription. The watcher MUST also store 267 the received full presence presence document as its local copy. 269 When the watcher receives a subsequent 'application/pidf-diff+xml' 270 encoded presence document the watcher MUST compare the received 271 "version" attribute with the local version counter. If the watcher 272 receives a presence document with the "version" attribute value equal 273 or lower than the locally stored version number, it is considered a 274 PA failure and the watcher SHOULD discard the document without 275 further processing. Otherwise the watcher MUST modify its locally 276 stored information according to the following logic: 278 o If the root element of the presence document is , the 279 watcher must replace its local copy of the presence document with 280 the presence document received in the 'application/pidf-diff+xml' 281 body and set the internal version value to the value of the 282 "version" attribute included in the presence document. 284 o If the root element of the presence document is and 285 the received version number is incremented by one compared with 286 the local version counter, the watcher MUST apply the changes to 287 its local copy of the full presence document indicated in the 288 received 'application/pidf-diff+xml' document as specified in PIDF 289 extension for Partial Presence [2]. The watcher MUST increment 290 the local version counter by one. 292 o If the root element of the presence document is and 293 the received "version" value is higher by more than one compared 294 with the locally stored value the watcher assumes that one or more 295 NOTIFYs were lost. The watcher SHOULD either refresh the 296 subscription in order to receive a full presence document or 297 terminate the subscription. 299 if watcher encounters a processing error while processing received 300 'application/pidf-diff+xml' encoded presence document, look at 301 Section 5.1 of [8]. In this case watcher SHOULD renew the 302 subscription. Watcher MAY also fall back to normal presence 303 operations by not inserting 'application/pidf-diff+xml' in a new 304 SUBSCRIBE request. It is hardly reasonable to signal this error to 305 the notifier even if the error exists in the notifier process. 307 If the PA changes the content type used in notifications within the 308 existing subscription the watcher MUST discard all the previously 309 received presence information (except local version counter) from 310 that particular presentity and process the new content as specified 311 for that content type. Local version counter MUST NOT be discarded 312 because if PA changes back to 'application/pidf-diff+xml' MIME type 313 version counter will continue to increase from the last version 314 value. 316 5. Examples 318 The following message flow shows an example applying the partial 319 notifications mechanism. 321 A watcher sends a SUBSCRIBE request declaring support for the default 322 presence format ('application/pidf+xml) and for the partial 323 notification format ('application/pidf-diff+xml') in the Accept 324 header field value. The watcher uses the "q" parameter to set the 325 preference for receiving partial notifications. The PA accepts the 326 subscription and, based on the "q" parameter value, selects to send 327 partial notifications in NOTIFY requests. The first NOTIFY request 328 includes the full state of presence information. The following 329 notifications only include information about delta of the presence 330 information from the previous NOTIFY requests. 332 Watcher Presence Agent PUA 333 | F1 SUBSCRIBE | | 334 |-------------------------->| | 335 | F2 200 OK | | 336 |<--------------------------| | 337 | F3 NOTIFY | | 338 |<--------------------------| | 339 | F4 200 OK | | 340 |-------------------------->| | 341 | | | 342 | | Update presence | 343 | |<----------------------- | 344 | | | 345 | F5 NOTIFY | | 346 |<--------------------------| | 347 | F6 200 OK | | 348 |-------------------------->| | 350 Message Details 352 F1 SUBSCRIBE watcher->example.com server 354 SUBSCRIBE sip:resource@example.com SIP/2.0 355 Via: SIP/2.0/TCP watcherhost.example.com; 356 branch=z9hG4bKnashds7 357 To: 358 From: ;tag=xfg9 359 Call-ID: 2010@watcherhost.example.com 360 CSeq: 17766 SUBSCRIBE 361 Max-Forwards: 70 362 Event: presence 363 Accept: application/pidf+xml;q=0.3, 364 application/pidf-diff+xml;q=1 365 Contact: 366 Expires: 3600 367 Content-Length: 0 369 The PA accepts the subscription and generates a 200 OK response 370 to the SUBSCRIBE request 372 F2 200 OK example.com server ->watcher 374 SIP/2.0 200 OK 375 Via: SIP/2.0/TCP watcherhost.example.com; 376 branch=z9hG4bKnashds7 377 ;received=192.0.2.1 378 To: ;tag=ffd2 379 From: ;tag=xfg9 380 Call-ID: 2010@watcherhost.example.com 381 CSeq: 17766 SUBSCRIBE 382 Event: presence 383 Expires: 3600 384 Contact: 385 Content-Length: 0 387 The PA, based on the "q" parameter value in the Accept header 388 of the SUBSCRIBE request (F1), decides to use partial 389 notifications. The PA creates the first NOTIFY request that 390 includes the full presence document. 392 F3 NOTIFY example.com server -> watcher 394 NOTIFY sip:user@watcherhost.example.com SIP/2.0 395 Via: SIP/2.0/TCP server.example.com; 396 branch=z9hG4bKna998sk 397 To: ;tag=xfg9 398 From: ;tag=ffd2 399 Call-ID: 2010@watcherhost.example.com 400 Event: presence 401 Subscription-State: active;expires=3599 402 Max-Forwards: 70 403 CSeq: 8775 NOTIFY 404 Contact: 405 Content-Type: application/pidf-diff+xml 406 Content-Length: [replace with real content length] 408 409 418 419 420 open 421 422 423 true 424 false 425 true 426 427 428 tel:09012345678 429 431 432 433 open 434 435 im:res@example.com 436 438 439 440 closed 441 442 http://example.com/~res/ 443 http://example.com/~res/icon.gif 444 http://example.com/~res/card.vcd 445 sip:resource@example.com 446 448 Full state presence document 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 mac:xxx 465 467 469 F4 200 OK watcher -> example.com server 471 SIP/2.0 200 OK 472 Via: SIP/2.0/TCP server.example.com; 473 branch=z9hG4bKna998sk 474 ;received=192.0.2.2 475 To: ;tag=xfg9 476 From: ;tag=ffd2 477 Call-ID: 2010@watcherhost.example.com 478 CSeq: 8775 NOTIFY 479 Content-Length: 0 481 At a later time, the presentity's presence information 482 changes. The PA generates a NOTIFY request 483 that includes information about the changes. 485 F5 NOTIFY example.com server -> watcher 487 NOTIFY sip:user@watcherhost.example.com SIP/2.0 488 Via: SIP/2.0/TCP server.example.com; 489 branch=z9hG4bKna998sl 490 To: ;tag=xfg9 491 From: ;tag=ffd2 492 Call-ID: 2010@watcherhost.example.com 493 CSeq: 8776 NOTIFY 494 Event: presence 495 Subscription-State: active;expires=3543 496 Max-Forwards: 70 497 Contact: 498 Content-Type: application/pidf-diff+xml 499 Content-Length: [replace with real content length] 501 502 509 510 511 open 512 513 mailto:res@example.com 514 This is a new tuple inserted 515 between the last tuple and note element 516 518 520 open 523 525 0.7 528 530 F6 200 OK watcher-> example.com server 532 SIP/2.0 200 OK 533 Via: SIP/2.0/TCP server.example.com; 534 branch=z9hG4bKna998sl 535 ;received=192.0.2.2 536 To: ;tag=xfg9 537 From: ;tag=ffd2 538 Call-ID: 2010@watcherhost.example.com 539 CSeq: 8776 NOTIFY 540 Content-Length: 0 542 6. Security Considerations 544 This specification relies on the presence event package for SIP [3]. 545 Partial notifications can reveal information about what has changed 546 compared to the previous notification. This can make it easier for 547 eavesdropper to know what kind of changes are happening in the 548 presentity's presence information. However, the same information can 549 be found if the presence event package is used with baseline PIDF 550 [5]. 552 A third party can inject a NOTIFY request with partial state that 553 will cause the watcher to think it has missed a partial notification 554 and to request a new full presence document. This is no worse than 555 what we have without this extension since a party that could perform 556 such action could also send a NOTIFY with Subscription-State: 557 terminated and achieve the same effect without knowing about the 558 extension. Partial Notification does not make the situation any 559 worse, and the protection mechanisms from the existing system apply 560 to preventing this attack against the partial notification mechanism. 562 Presence related security considerations are extensively discussed in 563 the presence event package for SIP [3] and all those identified 564 security considerations apply to this document as well. Issues 565 described in the presence event package for SIP [3], including 566 confidentiality, message integrity and authenticity, outbound 567 authentication, replay prevention, DoS attacks against thirst parties 568 and DoS attacks against servers all apply here without any change. 570 It is RECOMMENDED that TLS [7] be used between elements to provide 571 hop by hop confidentially protection. Furthermore, S/MIME MAY be 572 used for integrity and authenticity of SUBSCRIBE and NOTIFY requests. 573 This is described in Section 23 of RFC 3261. 575 7. Acknowledgments 577 The authors would like to thank Jari Urpalainen, Jyrki Aarnos, 578 Jonathan Rosenberg, Dean Willis, Kriztian Kiss, Juha Kalliokulju, 579 Miguel Garcia, Anders Kristensen, Yannis Pavlidis, Ben Cambell, 580 Robert Sparks, and Tim Moran for their valuable comments. 582 8. References 584 8.1. Normative references 586 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 587 Levels", BCP 14, RFC 2119, March 1997. 589 [2] Lonnfors, M., Khartabil, H., Leppanen, E., and J. Urpalainen, 590 "Presence Information Data Format (PIDF) Extension for Partial 591 Presence", draft-ietf-simple-partial-pidf-format-10 (work in 592 progress), November 2007. 594 [3] Rosenberg, J., "A Presence Event Package for the Session 595 Initiation Protocol (SIP)", RFC 3856, August 2004. 597 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 598 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 599 Session Initiation Protocol", RFC 3261, June 2002. 601 [5] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and 602 J. Peterson, "Presence Information Data Format (PIDF)", 603 RFC 3863, August 2004. 605 [6] Roach, A., "SIP-Specific Event Notification", RFC 3265, 606 June 2002. 608 [7] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", 609 RFC 4346, April 2006. 611 [8] Urpalainen, J., "An Extensible Markup Language (XML) Patch 612 Operations Framework Utilizing XML Path Language (XPath) 613 Selectors", draft-ietf-simple-xml-patch-ops-04, November 2007. 615 8.2. Informative references 617 [9] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and 618 Instant Messaging", RFC 2778, February 2000. 620 Authors' Addresses 622 Mikko Lonnfors 623 Nokia 624 P.O. Box 321 625 Helsinki 626 Finland 628 Phone: +358 71 8008000 629 Email: mikko.lonnfors@nokia.com 631 Jose Costa-Requena 632 Nokia 633 P.O. Box 321 634 Helsinki 635 Finland 637 Phone: +358 71 8008000 638 Email: jose.costa-requena@nokia.com 639 Eva Leppanen 640 Nokia 641 Lempaala 642 Finland 644 Email: eva.leppanen@saunalahti.fi 646 Hisham Khartabil 647 Melbourne 648 Australia 650 Phone: +61 416 108 890 651 Email: hisham.khartabil@gmail.com 653 Full Copyright Statement 655 Copyright (C) The IETF Trust (2008). 657 This document is subject to the rights, licenses and restrictions 658 contained in BCP 78, and except as set forth therein, the authors 659 retain all their rights. 661 This document and the information contained herein are provided on an 662 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 663 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 664 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 665 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 666 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 667 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 669 Intellectual Property 671 The IETF takes no position regarding the validity or scope of any 672 Intellectual Property Rights or other rights that might be claimed to 673 pertain to the implementation or use of the technology described in 674 this document or the extent to which any license under such rights 675 might or might not be available; nor does it represent that it has 676 made any independent effort to identify any such rights. Information 677 on the procedures with respect to rights in RFC documents can be 678 found in BCP 78 and BCP 79. 680 Copies of IPR disclosures made to the IETF Secretariat and any 681 assurances of licenses to be made available, or the result of an 682 attempt made to obtain a general license or permission for the use of 683 such proprietary rights by implementers or users of this 684 specification can be obtained from the IETF on-line IPR repository at 685 http://www.ietf.org/ipr. 687 The IETF invites any interested party to bring to its attention any 688 copyrights, patents or patent applications, or other proprietary 689 rights that may cover technology that may be required to implement 690 this standard. Please address the information to the IETF at 691 ietf-ipr@ietf.org. 693 Acknowledgment 695 Funding for the RFC Editor function is provided by the IETF 696 Administrative Support Activity (IASA).