idnits 2.17.1 draft-lonnfors-simple-partial-notify-02.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 25 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** There are 5 instances of lines with control characters in the document. 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 (June 19, 2003) is 7611 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) ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '2') == Outdated reference: A later version (-01) exists of draft-ietf-simple-presinfo-deliv-reg-00 -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 3265 (ref. '7') (Obsoleted by RFC 6665) == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-04 == Outdated reference: A later version (-05) exists of draft-ietf-sip-content-indirect-mech-02 == Outdated reference: A later version (-03) exists of draft-kiss-simple-presence-wireless-reqs-01 -- Obsolete informational reference (is this intentional?): RFC 3023 (ref. '13') (Obsoleted by RFC 7303) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE WG M. Lonnfors 3 Internet-Draft Nokia Research Center 4 Expires: December 18, 2003 J. Costa-Requena 5 E. Leppanen 6 H. Khartabil 7 Nokia 8 June 19, 2003 10 Partial Notification of Presence Information 11 draft-lonnfors-simple-partial-notify-02 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-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 http:// 28 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 December 18, 2003. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 A Presence service can have constraints for delivering presence 42 information to devices with low data processing capabilities, small 43 display, and limited battery power. Other limitations can be caused 44 by the interface between the terminal and the network, i.e. over 45 radio links with high latency and low bandwidth. This memo presents a 46 solution that aids in reducing the impact of those constrains and to 47 increase efficiency, by introducing a mechanism called partial 48 notification. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Introduction of the partial notification mechanism . . . . . 4 55 3.1 Normal presence server operation . . . . . . . . . . . . . . 4 56 3.2 Operation of the partial notification . . . . . . . . . . . 4 57 4. Client and server operations . . . . . . . . . . . . . . . . 5 58 4.1 Content-type for partial notifications . . . . . . . . . . . 5 59 4.2 Watcher generating SUBSCRIBE requests . . . . . . . . . . . 5 60 4.3 Notifier processing of SUBSCRIBE requests . . . . . . . . . 5 61 4.4 Notifier generating partial notifications . . . . . . . . . 5 62 4.5 Watcher processing of partial notifications . . . . . . . . 6 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 64 5.1 URN sub-namespace registration for 65 'urn:ietf:params:xml:ns:pidf-partial' . . . . . . . . . . . 8 66 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 8. Security Considerations . . . . . . . . . . . . . . . . . . 15 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 70 10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 10.1 Changes since -00 . . . . . . . . . . . . . . . . . . . . . 15 72 10.2 Changes since -01 . . . . . . . . . . . . . . . . . . . . . 16 73 Normative references . . . . . . . . . . . . . . . . . . . . 16 74 Informative references . . . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 76 Intellectual Property and Copyright Statements . . . . . . . 19 78 1. Introduction 80 SIP extensions for presence [4] allow users ('watchers') to subscribe 81 to other users' ('presentities') presence information. The presence 82 information is composed of multiple pieces of data that are delivered 83 to the watcher. The size of the presence information document can be 84 large (i.e. the presence document can contain an arbitrary number of 85 elements called presence tuples that convey data). It may not be 86 reasonable to send the complete presence information over low 87 bandwidth and high latency links when only part of that information 88 changes. This may end up degrading the presence service and causing 89 bad perception at the watcher side. 91 Presence based applications in wireless terminals have certain 92 limitations because it is envisioned that the presence service may 93 demand high bandwidth. Requirements for wireless environments can be 94 found in [12]. 96 There are some mechanisms, such as signaling compression [14] and 97 content indirection [11], [10] that might be used to help in this 98 problem. However, none of the existing solutions are optimal because 99 they set additional requirements on basic network functionalities 100 such as security. Some of the existing solutions enforce certain 101 requirements on the network and terminals for supporting compression 102 mechanism, while other solutions require having a specific server to 103 store the requested presence information until the terminal fetches 104 it using another protocol (HTTP) and therefore increases possible 105 security concerns. 107 This draft presents a solution to these problems, called Partial 108 Notifications. Requirements for this mechanism are presented in [3]. 109 Other set of requirements can be found from [12]. The idea is already 110 identified by the SIP Extensions for Presence document [4] as a 111 potential solution. 113 In general, the partial notification approach means that the Presence 114 Server (PS) delivers to the watchers only those parts of the presence 115 information that have changed compared to the presence information 116 sent in the previous notification. Note that partial notification is 117 not IMPP compliant. 119 This document introduces a new MIME-Type 'application/pidf- 120 partial+xml'. 122 2. Conventions 124 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 125 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 126 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 127 indicate requirement levels for compliant implementations. 129 3. Introduction of the partial notification mechanism 131 This chapter briefly introduces the current functionality of the 132 presence service, and gives an overview of the partial notification 133 solution and new items needed to implement it. 135 3.1 Normal presence server operation 137 The presence service normally operates so that the watcher sends the 138 SIP SUBSCRIBE request targeted to the presentity. The request is 139 routed up to the presence server responsible for terminating the 140 request. The SUBSCRIBE request MAY include an Accept header field for 141 indicating the supported content types [5]. 143 The PS receives the SUBSCRIBE request and if there is no Accept 144 header indicating the supported content types, the PS will generate 145 the presence notification using the default PIDF format [6]. The PIDF 146 may contain one or multiple tuples and presence document level 147 information. The tuples include a set of elements defined in the 148 presence model [2] for representing the presence information. The 149 presence information is sent to the watcher in the body of the NOTIFY 150 request according to [7]. By default, the presence information 151 contains the full state corresponding to the presence status of the 152 presentity, as determinated by the PS local policy and authorization 153 rules. 155 3.2 Operation of the partial notification 157 The mechanism for implementing the partial notification consists of 158 defining a new content type. The new content type is named as 159 'application/pidf-partial+xml'. It is similar to PIDF [6] except that 160 it adds new XML items to element in order to enable the 161 partial notifications. The new XML attributes are "version" and 162 "state". The new XML element is "removed". 164 The "version" attribute is a sequence number that is progressively 165 incremented for each watcher when notification is sent. The "state" 166 attribute indicates the nature of the presence information included 167 in the notified document, whether it contains full or partial state 168 corresponding to the cases when the full presence information or only 169 changed parts of the presence information are delivered. The use of 170 these attributes is similar to the watcher information template 171 package [9]. 173 In the scope of this document the partial updates apply only to 174 level XML elements and everything what is contained inside 175 these elements, in other words: tuples are considered to be atomic 176 data elements. This means the when an update is send to a tuple it is 177 assumed that the whole tuple is completely replaced by the new one. 178 All the data which is located outside the elements must be 179 processed as specified in [4]. Usually this means that all those XML 180 elements (for example the element) must be included in every 181 notification. 183 4. Client and server operations 185 This document assumes that unless otherwise specified in this 186 document the normal subscriber and notifier behavior is applied as 187 defined in [4]. The watcher has the same behavior as a subscriber. 189 4.1 Content-type for partial notifications 191 The entities supporting the partial notification extension described 192 in this document MUST support the 'application/pidf-partial+xml' 193 content-type. 195 4.2 Watcher generating SUBSCRIBE requests 197 The SUBSCRIBE request can be used to negotiate the preferred content 198 type to be used in the notifications. The Accept header is used for 199 this purpose as specified in [5]. When watcher wants to allow PS to 200 send partial notifications it MUST include the Accept header value 201 'application/pidf-partial+xml' in the SUBSCRIBE request. The qvalue 202 parameter of the Accept header can be used to indicate the most 203 preferred content type to be used. 205 4.3 Notifier processing of SUBSCRIBE requests 207 The Presence Server receives the subscriptions from the watchers and 208 generates the notifications according to [4]. If the watcher has 209 indicated the supported content types in the Accept header the 210 Presence Server compares the content types included in the Accept 211 header with the supported ones, and decides which one to use. If the 212 watcher has used the qvalue parameter of the Accept header for the 213 content types the decision should be based on them. Otherwise the 214 decision is made according to the local policy of the server. 216 4.4 Notifier generating partial notifications 218 If the content type negotiation between the watcher and the PS 219 resulted in the agreement to use partial notifications, then the PS 220 MUST use the 'application/pidf-partial+xml' content type in the 221 NOTIFY requests. 223 The PS MUST deliver the full state of the presence information 224 according to [4] in the first notification. In this case, the "state" 225 attribute of the element in the presence document MUST be 226 set to the value "full". The "version" attribute MUST also be present 227 and it MUST be initialized to value zero. 229 When the PS generates subsequent notifications, the presence document 230 includes only the tuples that have changed compared to the previous 231 notification. It is up to the local policy to determine what is 232 considered as a change to the previous state. The "state" attribute's 233 value MUST be set to "partial". 235 The PS constructs the presence document according to the following 236 logic: 238 o The delivered presence information is constructed according to [4] 239 in such a way that only the changed tuples are delivered. New 240 tuples are also be added to the presence information, if any. 242 o The "version" and "state" attributes are also included in the 243 presence document. The version number is incremented by one 244 compared to the earlier delivered presence document to the watcher 245 associated with a certain subscription. The version number should 246 follow the COUNTER32 format so that after reaching the maximum 247 value it starts from zero [15]. 249 o When there are changes (e.g. in the authorization) which lead to 250 removal of tuples from the previously delivered presence 251 information the PS lists the IDs of the removed tuples in the 252 "removed" element. 254 o All the presence information outside the elements MUST be 255 included in each notification, i.e., all the notifications which 256 convey partial notifications MUST always have that data. 258 4.5 Watcher processing of partial notifications 260 If the negotiation between the watcher and the PS resulted in the 261 agreement to use the partial notifications, then the watcher receives 262 'application/pidf-partial+xml' content type in the NOTIFY requests. 264 The watcher receives the full state of the presence information 265 according to [4] in the first notification using the partial 266 notifications. In this case, the "state" element of the presence 267 document has the value "full". When the watcher receives the full 268 state notification it MUST perform the following actions: 270 o The watcher MUST discard all previously received presence 271 information from that particular presentity. 273 o The watcher MUST initialize an internal version counter, related 274 that particular presentity or subscription, to the value received 275 in the notification. 277 o The watcher MUST store the values of all tuple IDs together with 278 the content received in the notification. 280 When the watcher receives subsequent notifications and the PS has not 281 changed the used content type, the presence document includes only 282 those tuples that have changed compared to the previous notification. 283 The "state" element includes the value of "partial" telling to the 284 watcher that the notification includes partial information. The 285 watcher MUST construct the presence information according to the 286 following logic: 288 o The "version" attribute of the element is compared with 289 the version information in the previously received presence 290 document. If the version number is incremented by one, the watcher 291 continues handling the content present in the notification. 293 o The Watcher compares tuple IDs to the tuple IDs received in the 294 previous notifications. If a tuple ID in the notification matches 295 an existing tuple ID, the existing tuple is replaced with the 296 newly received in the notification. If the tuple ID does not match 297 to those received in the earlier notifications, it is stored as 298 new tuple. 300 o If the presence document includes the "removed" element the tuples 301 which IDs are listed are removed from the local storage. 303 o Tuples whose IDs are missing in the NOTIFY remain unchanged. 305 In case the watcher receives a partial notification with the 306 "version" attribute value higher than the stored value by more than 307 one, the watcher assumes that one or more NOTIFY were lost and SHOULD 308 either refresh the subscription within the existing dialog in order 309 to receive a complete update (full state) of the presence information 310 or terminate the subscription. If the watcher receives a notification 311 with "state" attribute value "partial" and the "version" attribute 312 value equal or smaller than the one in the previous notification, it 313 is considered a PS failure and the watcher SHOULD either refresh or 314 terminate the subscription. 316 All information received in the notification which is located outside 317 the element must be processed as specified in [4]. I.e., the 318 watcher must replace the existing data with data received in the 319 latest notification. 321 In case the PS changes the content type used in notifications within 322 the existing dialog the watcher must discard all previously received 323 presence information from that particular presentity and process the 324 new content as specified for that content type. 326 5. IANA Considerations 328 This memo calls for IANA to register a new XML namespace URN per [8]. 329 A new content type 'application/pidf-partial+xml' is defined to 330 represent an XML MIME for the partial presence information content. 331 This specification follows the guidelines of RFC3023 [13]. 333 5.1 URN sub-namespace registration for 334 'urn:ietf:params:xml:ns:pidf-partial' 336 URI: 337 uurn:ietf:params:xml:ns:pidf-partial 339 Description: 340 This is the XML namespace for XML elements defined by [[[RFCXXXX]]] 341 to describe the 'application/pidf-partial+xml' content type for 342 partial notifications. 344 Registrant Contact: 345 IETF, SIMPLE working group, 346 Mikko Lonnfors, 348 XML: 350 BEGIN 351 352 354 358 PIDF extension for partial notifications 359 360 361

Namespace for PIDF extension for partial 362 notifications

363

application/pidf-partial+xml

364

See RFCXXXX.

365 366 367 END 369 6. Examples 371 The following message flow show an example applying the partial 372 notifications mechanism. The document of the 'application/ 373 pidf-partial+xml' format mentioned in the message details is 374 constructed according to the XML schema described in the chapter 375 Section 7. 377 The watcher sends a SUBSCRIBE request including the default presence 378 format (PIDF) and the content type for the partial notification in 379 the Accept header field. The watcher uses the qvalue parameter to set 380 the preference for receiving partial notifications. The PS accepts 381 the subscription and based on the qvalue information selects to send 382 partial notifications in NOTIFY requests. The first NOTIFY request 383 includes the full state of presence information represented in the 384 'application/pidf-partial+xml' content type. The following 385 notifications only include the delta of the presence information from 386 the previous NOTIFY request. 388 Watcher Presence Server PUA 389 | F1 SUBSCRIBE | | 390 |-------------------------->| | 391 | F2 200 OK | | 392 |<--------------------------| | 393 | F3 NOTIFY | | 394 |<--------------------------| | 395 | F4 200 OK | | 396 |-------------------------->| | 397 | | | 398 | | Update presence | 399 | |<----------------------- | 400 | | | 401 | F5 NOTIFY | | 402 |<--------------------------| | 403 | F6 200 OK | | 404 |-------------------------->| | 406 Message Details 408 F1 SUBSCRIBE watcher->example.com server 410 SUBSCRIBE sip:resource@example.com SIP/2.0 411 Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7 412 To: sip:resource@example.com 413 From: sip:watcher@somewhere.com ;tag=xfg9 414 Call-ID: 2010@watcherhost.example.com 415 CSeq: 17766 SUBSCRIBE 416 Max-Forwards: 70 417 Event: presence 418 Accept: application/cpim-pidf+xml;q=0.3, application/pidf-partial+xml;q=1 419 Contact: user@watcherhost.example.com 420 Expires: 600 421 Content-Length: 0 423 F2 200 OK example.com server->watcher 425 The Presence Server accepts the subscription and based on the qvalue 426 information in the Accept header uses the partial notitifcations. 427 (See that the value 'application/pidf-partial+xml' in the Content-Type header). 429 SIP/2.0 200 OK 430 Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7 431 ;received=192.0.2.1 432 To: sip:resource@example.com;tag=ffd2 433 From: sip:watcher@somewhere.com;tag=xfg9 434 Call-ID: 2010@watcherhost.example.com 435 CSeq: 17766 SUBSCRIBE 436 Event: presence 437 Expires: 600 438 Contact: sip:server.example.com 439 Content-Length: 0 441 F3 NOTIFY example.com server-> watcher 443 NOTIFY sip:user@watcherhost.example.com SIP/2.0 444 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk 445 To: sip:watcher@somewhere.com;tag=xfg9 446 From: sip:resource@example.com;tag=ffd2 447 Call-ID: 2010@watcherhost.example.com 448 Event: presence 449 Subscription-State: active;expires=599 450 Max-Forwards: 70 451 CSeq: 8775 NOTIFY 452 Contact: sip:server.example.com 453 Content-Type: application/pidf-partial+xml 454 Content-Length: .. 456 PIDF-PARTIAL+XML Document with FULL STATE information: 458 459 462 463 open 464 tel:09012345678 465 467 468 open 469 470 im:pep@example.com 471 472 473 closed 474 475 sip:pep@example.com 476 477 479 F4 200 OK watcher-> example.com server 481 SIP/2.0 200 OK 482 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk 483 ;received=192.0.2.2 484 To: sip:watcher@somewhere.com;tag=xfg9 485 From: sip:resource@example.com;tag=ffd2 486 Call-ID: 2010@watcherhost.example.com 487 CSeq: 8775 NOTIFY 488 Content-Length: 0 490 F5 NOTIFY example.com server -> watcher 491 It is the local policy issue to construct the 'PIDF-partial+xml' 492 formated document including the delta from the previous NOTIFY. 493 Note that the tuple which id was "r1230d" was deleted. 495 NOTIFY sip:user@watcherhost.example.com SIP/2.0 496 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl 497 To: sip:watcher@somewhere.com;tag=xfg9 498 From: sip:resource@example.com;tag=ffd2 499 Call-ID: 2010@watcherhost.example.com 500 CSeq: 8776 NOTIFY 501 Event: presence 502 Subscription-State: active;expires=543 503 Max-Forwards: 70 504 Contact: sip:server.example.com 505 Content-Type: application/pidf-partial+xml 506 Content-Length: ... 508 New PIDF-PARTIAL+XML Document with PARTIAL STATE information: 510 511 514 r1230d 516 517 closed 518 519 im:pep@examploe.com 520 This is an update of existing tuple 521 sent in previous notification 522 524 525 open 526 527 im:mac@hut.com 528 This is a completely new tuple not 529 sent in previous notification 530 531 533 F6 200 OK watcher-> example.com server 535 SIP/2.0 200 OK 536 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl 537 ;received=192.0.2.2 538 To: sip:watcher@somewhere.com;tag=xfg9 539 From: sip:resource@example.com;tag=ffd2 540 Call-ID: 2010@watcherhost.example.com 541 CSeq: 8776 NOTIFY 542 Content-Length: 0 544 7. XML Schema 546 The XML schema for the 'pidf-partial+xml' data format. 548 549 555 556 559 561 562 563 565 567 569 571 572 573 575 576 577 578 579 580 581 582 583 584 585 586 587 589 590 592 593 594 595 597 598 599 600 602 603 604 605 606 607 608 609 611 612 613 614 615 616 617 618 619 620 621 622 623 624 626 627 628 629 630 631 632 633 634 636 637 639 640 641 642 643 This attribute may be used on any element within an optional 644 PIDF extension to indicate that the corresponding element must 645 be understood by the PIDF processor if the enclosing optional 646 element is to be handled. 647 648 649 650 652 8. Security Considerations 654 Presence information may contain highly sensitive information about 655 the presentities. Presence related security considerations are 656 extensively discussed in [4] and all those identified security 657 consideration apply to this document as well. Partial notification 658 mechanism does not add anything new which (in term of the security) 659 is not already specified in [4] and [5]. Thus no new security 660 considerations are introduced here. 662 9. Acknowledgements 664 The authors would like to thank Jyrki Aarnos, Jonathan Rosenberg, 665 Dean Willis, Kriztian Kiss, Juha Kalliokulju and Tim Moran for their 666 valuable comments. 668 10. Changes 670 10.1 Changes since -00 672 o Section comparing the existing mechanisms removed. 674 o Solution on the removal of the tuple changed. Texts, XML Schema 675 and examples modified accordinly. 677 o Reduntant texts and issues specified in other specifications 678 removed. 680 o Other editorial changes, e.g., more normative style, references 681 devided into Informal and Normative. 683 10.2 Changes since -01 685 o Open issues concerning the usage of Require header was solved by 686 the qvalue, and caused changes were incorporated to the text. 688 o Open issue concerning the change of content type in mid-dialog 689 incorporated to the text. 691 Normative references 693 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 694 Levels", BCP 14, RFC 2119, March 1997. 696 [2] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 697 Instant Messaging", RFC 2778, February 2000. 699 [3] Lonnfors, M., Leppanen, E., Requena, J. and H. Khartabil, 700 "Requirements for Efficient Delivery of Presence Information", 701 draft-ietf-simple-presinfo-deliv-reg-00 (work in progress), 702 April 2003. 704 [4] Rosenberg, J., "SIP Extensions for Presence", 705 draft-ietf-simple-presence-10 (work in progress), January 2003. 707 [5] Rosenberg, J., "SIP: Session Initiation Protocol", RFC 3261, 708 June 2002. 710 [6] Sugano, H., "CPIM presence information data format", 711 draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. 713 [7] Roach, A., "SIP-Specific Event Notification", RFC 3265, June 714 2002. 716 Informative references 718 [8] Mealling, M., "The IETF XML Registry", 719 draft-mealling-iana-xmlns-registry-04 (work in progress), June 720 2002. 722 [9] Rosenberg, J., "A Watcher Information Event Template-Package 723 for the Session Initiation Protocol (SIP)", 724 draft-ietf-simple-winfo-package-05 (work in progress), January 725 2003. 727 [10] Khartabil, H., "Congestion safety and Content Indirection", 728 draft-khartabil-sip-congestionsafe-ci-02 (work in progress), 729 March 2003. 731 [11] Olson, S., "Mechanism for Content Indirection in Session 732 Initiation Protocol (SIP) Messages", 733 draft-ietf-sip-content-indirect-mech-02 (work in progress), 734 February 2003. 736 [12] Kiss, K., "Requirements for Presence Service based on 3GPP 737 specifications and wireless environment characheristics", 738 draft-kiss-simple-presence-wireless-reqs-01 (work in progress), 739 February 2003. 741 [13] Murata, M., "XML media types", RFC 3023, January 2001. 743 [14] Price, R., "Signaling Compression (SigComp)", RFC 3320, January 744 2003. 746 [15] McCloghrie, K., "Structure of Management Information Version 2 747 (SMIv2)", RFC 2578, April 1999. 749 Authors' Addresses 751 Mikko Lonnfors 752 Nokia Research Center 753 Itamerenkatu 11-13 00180 754 Helsinki 755 Finland 757 Phone: +358 50 4836402 758 EMail: mikko.lonnfors@nokia.com 760 Jose Costa-Requena 761 Nokia 762 Valimotie 9 00380 763 Helsinki 764 Finland 766 Phone: +358 71 8008000 767 EMail: jose.costa-requena@nokia.com 768 Eva Leppanen 769 Nokia 770 P.O BOX 785 771 Tampere 772 Finland 774 Phone: +358 7180 77066 775 EMail: eva-maria.leppanen@nokia.com 777 Hisham Khartabil 778 Nokia 779 P.O. Box 321 780 Helsinki 781 Finland 783 Phone: +358 7180 76161 784 EMail: hisham.khartabil@nokia.com 786 Intellectual Property Statement 788 The IETF takes no position regarding the validity or scope of any 789 intellectual property or other rights that might be claimed to 790 pertain to the implementation or use of the technology described in 791 this document or the extent to which any license under such rights 792 might or might not be available; neither does it represent that it 793 has made any effort to identify any such rights. Information on the 794 IETF's procedures with respect to rights in standards-track and 795 standards-related documentation can be found in BCP-11. Copies of 796 claims of rights made available for publication and any assurances of 797 licenses to be made available, or the result of an attempt made to 798 obtain a general license or permission for the use of such 799 proprietary rights by implementors or users of this specification can 800 be obtained from the IETF Secretariat. 802 The IETF invites any interested party to bring to its attention any 803 copyrights, patents or patent applications, or other proprietary 804 rights which may cover technology that may be required to practice 805 this standard. Please address the information to the IETF Executive 806 Director. 808 Full Copyright Statement 810 Copyright (C) The Internet Society (2003). All Rights Reserved. 812 This document and translations of it may be copied and furnished to 813 others, and derivative works that comment on or otherwise explain it 814 or assist in its implementation may be prepared, copied, published 815 and distributed, in whole or in part, without restriction of any 816 kind, provided that the above copyright notice and this paragraph are 817 included on all such copies and derivative works. However, this 818 document itself may not be modified in any way, such as by removing 819 the copyright notice or references to the Internet Society or other 820 Internet organizations, except as needed for the purpose of 821 developing Internet standards in which case the procedures for 822 copyrights defined in the Internet Standards process must be 823 followed, or as required to translate it into languages other than 824 English. 826 The limited permissions granted above are perpetual and will not be 827 revoked by the Internet Society or its successors or assignees. 829 This document and the information contained herein is provided on an 830 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 831 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 832 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 833 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 834 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 836 Acknowledgement 838 Funding for the RFC Editor function is currently provided by the 839 Internet Society.