idnits 2.17.1 draft-lonnofors-simple-partial-notify-00.txt: -(69): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(70): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(101): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(239): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(240): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(243): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(251): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(255): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(257): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(261): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(264): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(281): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(282): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(285): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(290): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(291): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(296): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(314): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(344): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(391): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(396): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(417): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(426): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(453): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(465): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(539): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(582): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(585): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(616): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(617): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(618): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(619): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(928): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(932): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(936): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(960): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There are 68 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 660 has weird spacing: '...tension exam...' -- 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 2003) is 7764 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) == Outdated reference: A later version (-10) exists of draft-ietf-simple-presence-07 == Outdated reference: A later version (-03) exists of draft-kiss-simple-presence-wireless-reqs-01 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-05) exists of draft-ietf-sip-content-indirect-mech-01 == Outdated reference: A later version (-02) exists of draft-khartabil-sip-congestionsafe-ci-01 -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-08) exists of draft-ietf-impp-cpim-pidf-05 ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '9') ** Obsolete normative reference: RFC 3265 (ref. '10') (Obsoleted by RFC 6665) == Outdated reference: A later version (-05) exists of draft-ietf-simple-winfo-package-04 ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '12') == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-04 ** Obsolete normative reference: RFC 3023 (ref. '15') (Obsoleted by RFC 7303) Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERET-DRAFT J.Costa-Requena 3 draft-lonnofors-simple-partial-notify-00.txt Eva Leppanen 4 Expires: July 2003 Hisham Khartabi 5 Mikko Lonnfors 6 Nokia 7 January 2003 9 Partial Notification of Presence Information 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 A Presence service implemented using SIMPLE has some constraints for 34 delivering presence information to devices with low data processing 35 capabilities, small display, and limited battery power. Other 36 limitations can be caused by the interface between the terminal and 37 the network, i.e. over radio links with high latency and low 38 bandwidth. This memo presents a solution that aids in reducing the 39 impact of those constrains and increasing efficiency, by introducing 40 a new MIME-type �partial notifications� and a Require header 41 extension �partial-notification�. 43 Table of Contents 45 1 Introduction....................................................2 46 1.1 Existing mechanisms........................................3 47 2 Conventions used in this document...............................4 48 3 Introduction of the partial notification solution...............4 49 3.1 Normal presence server operation...........................5 50 3.2 Operation of the partial notification......................5 51 4 Client and server operations....................................5 52 4.1.1 Watcher generating SUBSCRIBE requests.................6 53 4.1.2 Notifier processing of SUBSCRIBE requests.............6 54 4.1.3 NOTIFY body for partial notifications.................7 55 4.1.4 Notifier generation of partial notifications..........7 56 4.1.5 Watcher processing of partial notifications...........8 57 5 IANA considerations.............................................9 58 6 Examples.......................................................10 59 6.1.1 Subscription with partial notification as optional...10 60 6.1.2 Subscription with partial notification as requirement14 61 7 XML Schema.....................................................18 62 8 Security Considerations........................................20 63 9 Acknowledgements...............................................20 64 10 References....................................................20 65 11 Author's Addresses............................................22 67 1 Introduction 69 SIP extensions for presence [1] allow users (�watchers�) to subscribe 70 to other users (�presentities�) presence information. The presence 71 information is composed of multiple pieces of data that is delivered 72 to the watcher. The size of the presence information can be large 73 (i.e. an arbitrary number of elements called 'Presence tuples' that 74 convey data). It may not be reasonable to send the complete presence 75 information over low bandwidth and high latency links when only part 76 of that information changes. This may end up in degrading the 77 presence service and causing bad perception at the watcher side. 78 Thus, it is necessary to provide solutions to overcome this problem 79 for the sake of success of the presence service. 81 Presence based applications in wireless terminals have certain 82 limitations because it is envisioned that the presence service may 83 demand high bandwidth. It is foreseen that the presence information 84 may have a considerable size, especially if large content is included 85 in presence information. Requirements of wireless environments can 86 also be found in [2]. 88 There are some mechanisms which might be used to help the problem, 89 such as signaling compression [3] and content indirection [4] and 91 [5]. However, none of the existing solutions are optimal because they 92 set additional requirements on basic network functionalities such as 93 charging and security. Some of the existing solutions enforce certain 94 requirements on the network and terminals for supporting compression 95 mechanism, while other solutions require having a specific server to 96 store the requested presence information until the terminal fetches 97 it using another protocol (HTTP) and therefore increases possible 98 security concerns. 100 This draft presents another approach as a solution to the problem, 101 namely �Partial Notifications�. The idea is already identified by the 102 SIP Extensions for Presence document [1] as a potential solution. In 103 general, the partial notification approach means that the Presence 104 Server (PS) delivers to the watchers only that part of the presence 105 information that has changed compared to the previous notification. 106 (See also [2] for requirements). Note that the �Partial 107 Notifications� are not IMPP compliant. 109 This document introduces a new MIME-Type 'application/pidf- 110 partial+xml' and a Require-header extension 'partial-notification'. 112 1.1 Existing mechanisms 114 The SIMPLE Working Group has already proposed a set of mechanisms in 115 order to accommodate excessive message size when messages are 116 delivered over links with limited bandwidth. 118 - SigComp[3]: Signalling compression. 119 This mechanism provides a reasonable message size reduction because 120 of the text-based nature of SIP. However, this approach has certain 121 limitations when the messages contain binary content and it does not 122 reduce the size after the compression process. This approach also 123 requires having additional functionality in the terminal and in the 124 server. (I.e. the SigComp dictionaries require additional memory that 125 is a scarce resource in small devices, especially when the dictionary 126 includes binary content). 128 - Content Indirection [4],[5]: 129 Consists of sending a URL pointing to the content. This approach 130 solves the problem of excessive message size sent in the presence 131 notifications. The notification only includes a URL pointing to the 132 location where the content is stored. The watcher receiving the URL 133 has the option to use amore appropriate data protocol such as HTTP to 134 fetch the content every time a notification is received. 136 The inconvenience with this mechanism is that the URL has an 137 expiration time and after expiry, the URL becomes obsolete. There are 138 also security concerns since the URL should also include some 139 security credentials for authentication purposes when fetching the 140 content. In addition to this, the terminal has to fetch the content 141 after receiving the notification, causing delays in receiving the 142 presence information. In some systems this may also complicate the 143 charging system. 145 - Embedded URL in Presence Content: 146 Include a URL, that points to the binary content, in the 147 notification. This approach is similar to the previous Content 148 Indirection approach but instead of sending the URL for the whole 149 presence document, the URL included in the presence information is 150 pointing only to some pieces of information (e.g. images or other 151 binary content). 153 This mechanism would be the most suitable one because if it were used 154 in conjunction with the compression mechanism, it would lead into a 155 reduced size of the message to be delivered in the notification. The 156 inconveniences with this approach are the security, charging and 157 performance problems identified for the 'Content Indirection' 158 approach. Another inconvenience is that he watcher receives the 159 notification and thereafter has to fetch the content that is included 160 in the presence document with URLs. 162 2 Conventions used in this document 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119 [6]. 168 3 Introduction of the partial notification solution 170 This chapter briefly introduces the current functionality of the 171 Presence service, and gives an overview of the partial notification 172 solution and new items needed to implement it. 174 The motivation for introducing a partial notification mechanism, in 175 addition to the existing solutions described in Section 1.1, is to 176 mitigate the excessive message size in certain circumstances 177 (notifications with large un-compressed content). The approach is 178 Presence Server (PS) centric in a sense that the watcher, also 179 referred to as subscriber in this document, initiates the negotiation 180 in order to inform the Presence server (PS) about its ability to 181 receive partial notifications. The PS is the ultimate element that 182 decides whether the partial notification capability is used or not in 183 the particular subscription. 185 3.1 Normal presence server operation 187 The presence service normally operates so that the watcher sends the 188 SIP SUBSCRIBE method targeted to the presentity. The request is 189 routed up to the PS responsible for storing the presence information 190 of the presentity. The SUBSCRIBE request MAY include an Accept-header 191 field for indicating the supported content types [7]. 193 The PS receives the SUBSCRIBE request and if there is no Accept 194 header indicating supported content types, PS will generate the 195 presence notification using the default PIDF format [8]. PIDF may 196 contain one or multiple 'tuples' and presence document level 197 information. The 'tuples' include a set of elements defined in the 198 presence model [9] for representing the presence information. The 199 presence information is sent to the watcher in the body of the NOTIFY 200 request according to [10]. By default, the presence information 201 contains the full state corresponding to the presence status of the 202 presentity, as allowed by the PS local policy. 204 3.2 Operation of the partial notification 206 The proposed mechanism for implementing the partial notification 207 consists of defining a new content type as extension to the existing 208 'PIDF' format [8]. The new content type is named as 209 'application/pdif-partial+xml' and it adds new elements in addition 210 to the existing 'PIDF' schema in order to enable the partial 211 notifications. The new elements are 'version' and 'state'. 213 The 'version' information is a sequence number that is progressively 214 incremented for each watcher when notification is sent. The 'state' 215 indicates the nature of the presence information included in the 216 notified document, whether it contains 'full' or 'partial' state 217 corresponding to the cases when the full presence information or only 218 changed parts of the presence information are delivered. The use of 219 these attributes is similar to watcher information template package 220 [11]. 222 In addition the 'content-type' header of the NOTIFY request also 223 refers to the format type included in the document (i.e. 'CPIM- 224 PIDF+xml' or 'PIDF-partial+xml'). 226 4 Client and server operations 228 This document assumes that unless otherwise specified in this 229 document normal subscriber and notifier behavior is applied as 230 defined in [12]. The watcher has the same behavior as a subscriber. 232 4.1.1 Watcher generating SUBSCRIBE requests 234 The SUBSCRIBE request can be used to negotiate the prefered content 235 type to be used in the notifications. The 'Accept' header is used for 236 this purpose as specified in [7]. When sending a SUBSCRIBE request, 237 the watcher has the following options: 239 - Watcher may omit the �Accept� header or place default content type 240 as a value of �Accept� header. In this case the watcher is willing to 241 receive only the default presence format. 243 - Watcher may add the �Accept� header with values: application/cpim- 244 pidf+xml and application/pidf-partial+xml. In this case the watcher 245 is able to process both the default content type and the partial 246 notification content type. 248 Therefore, the watcher can indicate the content types that it is 249 willing to receive in the NOTIFY using the 'Accept' header. At least 250 the default content type specified for the Presence service MUST be 251 indicated. If the �Accept� header is omitted the default content type 252 (PDIF[8]) MUST be used by the Presence Server. 254 The watcher MAY include a �Require� header field with the value 255 �partial-notification� if the watcher wants to be sure that the PS 256 supports and uses the extensions defined in this specification. If PS 257 does understand the extension indicated in the �Require� header field 258 the PS SHOULD reject the subscription or alternatively accept the 259 subscription and send back an error response. 261 The �Supported� header achieves the same result as the �Accept� 262 header field. Since the �Accept� header MUST be present in a 263 SUSBSCRIBE request that requires a NOTIFY request with a content type 264 that is not the default one, the field presence of �Supported� header 265 is considered to be redundant, but it is not strictly disallowed. 267 4.1.2 Notifier processing of SUBSCRIBE requests 269 The Presence Server receives the subscriptions from the watchers and 270 generates the notifications according to [1]. The watcher might have 271 indicated the supported formats of the presence document by listing 272 the content types in the 'Accept' header. The Presence Server MUST 273 compare the content types included in the 'Accept' header with 274 supported ones, and decide which one to use according to its local 275 policy. There are the following cases: 277 - There is no �Accept� header field present in the request or the 278 �Accept� header field contains the default content type. In this 279 case, the subscription processing proceeds as defined in [1]. 281 - The �Accept� header field contains both �application/cpim-pidf+xml� 282 and �application/pidf-partial+xml�. Choosing either of these content 283 types is up to the local configuration as defined in [1] 285 - The �Accept� header field contains both �application/cpim-pidf+xml� 286 and �application/pidf-partial+xml� the �Require� header field 287 includes �partial-notification�. If the PS does not support the 288 �partial-notification� extension, then it rejects the request as 289 defined in [1]. If the PS supports the extension, it MUST use the 290 �application/pidf-partial+xml� content type in all subsequent NOTIFY 291 requests. The semantics for the �Require� header with value �partial- 292 notification� apply to the content type included in the �Accept� 293 header with value �application/pidf-partial+xml�. 295 Note: If Accept-header field does not include �application/pidf- 296 partial+xml� but a Require-header field with �partial-notification� 297 was present, the PS rejects the subscription. 299 4.1.3 NOTIFY body for partial notifications 301 The watchers supporting the partial notification extension described 302 in this document MUST support the 'application/pidf-partial+xml' 303 content-type. 305 4.1.4 Notifier generation of partial notifications 307 If the negotiation between the watcher and the PS resulted in the 308 agreement to use partial notifications, then the PS MUST use 309 'application/pdif-partial+xml' content type in NOTIFY requests. 311 The PS MUST deliver the full state of the presence information 312 according to [1] in the first notification. In this case, the 'state' 313 element of the presence document MUST be set to the value 'full'. The 314 �version� attribute MUST also be present and it MUST be initialized 315 to value zero. 317 When the PS generates subsequent notifications, the presence document 318 includes only the tuples that have changed compared to the previous 319 notification. Except in the case when the tuples are removed, the 320 complete presence document is sent. It is up to the local 321 configuration to determine what is considered as change to previous 322 state. The 'state' element's value MUST be set to 'partial�. 324 The PS constructs the presence document according to the following 325 logic: 327 The delivered presence information is constructed according to [1] in 328 such a way that only changed tuples are delivered. There might also 329 be new tuples added to the presence information because presentity 330 has published more information or because authorization policy has 331 been changed. 333 In addition, the version number and state element are also included 334 in the presence document. The version number is incremented by one 335 compared to the earlier delivered presence document to the watcher 336 associated with a certain subscription. The version number should 337 follow the COUNTER32 format that after reaching the maximum value it 338 starts from zero [13]. 340 When there are changes (e.g. in the authorisation) which lead to the 341 removal of a tuple from the previously delivered presence information 342 the PS sends the full presence information by setting the value 343 'full' for the 'state' element, and restarting the version numbering 344 again. The decision to send �full� state is up to the local policy. 346 4.1.5 Watcher processing of partial notifications 348 If the negotiation between the watcher and the PS resulted in the 349 agreement to use partial notifications, then the watcher receives 350 'application/pdif-partial+xml' content type in the subsequent NOTIFY 351 requests. 353 The watcher receives the full state of the presence information 354 according to [1] in the first notification. In this case, the 'state' 355 element of the presence document has the value 'full'. When the 356 watcher receives full state notifications it MUST perform the 357 following actions: 359 - Watcher MUST discard all previously received presence information 360 from that particular presentity. 362 - Watcher MUST initialize internal version counter, related that 363 particular presentity or subscription, to the value received in the 364 notification 366 - Watcher MUST store the values of all tuple IDs together with the 367 content received in the notification. 369 When the watcher receives subsequent notifications, the presence 370 document includes only those tuples that have changed compared to the 371 previous notification. The 'state' element includes the value of 372 'partial' telling to the watcher that the notification includes 373 partial information. The watcher MUST construct the presence 374 information according to the following logic: 376 - The version number of the presence document SHOULD be compared with 377 the version number of the previously received presence document. If 378 the version number is incremented by one, the watcher SHOULD continue 379 handling the content present in the notification. 381 - The Watcher MUST compare tuple IDs to tuple IDs received in 382 previous notifications. If a tuple ID in the notification matches an 383 existing tuple ID, the existing tuple must be replaced with the newly 384 received in the notification. If the tuple ID does not match to the 385 ones received in earlier notifications, it will be stored as new 386 tuple. 388 - The missing tuples means that they remained unchanged. 390 In case the watcher receives a partial notification, which has a 391 �version� number that is higher than the stored value by more than 392 one, the watcher assumes that one or more NOTIFY were lost and SHOULD 393 refresh the subscription within the existing dialog in order to 394 receive a complete update (full state) of the presence information. 395 If the watcher receives a notification with �sate� value equal 396 �partial� and the �version� number equal or smaller than the previous 397 notification, it is considered a PS failure and the watcher SHOULD 398 refresh the subscription. 400 OPEN ISSUE: Handling of element. PIDF and application/pidf- 401 partial+xml can have elements located as child elements to 402 element. It must be specified how these elements are 403 handled when partial notifications are send to watchers. The simplest 404 approach is to send them with the complete information even if they 405 did not change. 407 5 IANA considerations 409 This memo calls for IANA to register a new XML namespace URN as 410 defined in [14]. 412 A new content type �application/pidf-partial+xml� is defined to 413 represent an XML MIME for the partial presence information content. 414 This specification follows the guidelines of RFC3023 [15]. 416 It may also be needed an IANA registration for the value �partial- 417 notification� of the �Require� header as a SIP extension and the 418 required information for this registration, as specified in RFC3261 419 [7], is: 421 Name: partial-notification 423 URI: 424 urn:ietf:params:xml:ns:pidf-partial 426 Description: This option tag is used in the �Require� header field by 427 a UAC to ensure that partial notifications are honored at the PS. 429 Registrant Contact: IETF, SIMPLE working group, 431 BEGIN 432 433 435 439 PIDF extension for partial notifications 440 441 442

Namespace for PIDF extension for partial 443 notifications

444

application/pidf-partial+xml

445

See RFCXXXX.

446 447 448 END 450 6 Examples 452 The following flows show examples when applying the proposed partial 453 notification extension. The document of the �pidf-partial+xml� format 454 mentioned in the message details is constructed according to the XML 455 schema described in the chapter 6.2. 457 6.1.1 Subscription with partial notification as optional 459 The watcher sends a SUBSCRIBE request including the default presence 460 format (PIDF) and the PDIF partial extension using the �Accept� 461 header field. The PS accepts the subscription and based on a local 462 policy it selects to send partial notifications in NOTIFY requests 463 according to the logic described in this document. The first NOTIFY 464 request includes the full state of presence information represented 465 in the �application/pidf-partial+xml� contenttype�. The following 466 notifications only include the delta of the presence information from 467 the previous NOTIFY request. 469 Watcher Presence Server PUA 470 | F1 SUBSCRIBE | | 471 |-------------------------->| | 472 | F2 200 OK | | 473 |<--------------------------| | 474 | F3 NOTIFY | | 475 |<--------------------------| | 476 | F4 200 OK | | 477 |-------------------------->| | 478 | | | 479 | | Update presence | 480 | |<----------------------- | 481 | | | 482 | F5 NOTIFY | | 483 |<--------------------------| | 484 | F6 200 OK | | 485 |-------------------------->| | 487 Message Details 489 F1 SUBSCRIBE watcher->example.com server 491 SUBSCRIBE sip:resource@example.com SIP/2.0 492 Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7 493 To: sip:resource@example.com 494 From: sip:watcher@somewhere.com ;tag=xfg9 495 Call-ID: 2010@watcherhost.example.com 496 CSeq: 17766 SUBSCRIBE 497 Max-Forwards: 70 498 Event: presence 499 Accept: application/cpim-pidf+xml, application/pidf-partial+xml 500 Contact: user@watcherhost.example.com 501 Expires: 600 502 Content-Length: 0 503 F2 200 OK example.com server->watcher 505 The Presence Server accepts the subscription and based on the local 506 policy it applies the partial notitifcation. (See �Content-Type�= 507 �application/pidf-partial+xml�). 509 SIP/2.0 200 OK 510 Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7 511 ;received=192.0.2.1 512 To: sip:resource@example.com;tag=ffd2 513 From: sip:watcher@somewhere.com;tag=xfg9 514 Call-ID: 2010@watcherhost.example.com 515 CSeq: 17766 SUBSCRIBE 516 Event: presence 517 Expires: 600 518 Contact: sip:server.example.com 519 Content-Length: 0 521 F3 NOTIFY example.com server-> watcher 523 NOTIFY sip:user@watcherhost.example.com SIP/2.0 524 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk 525 To: sip:watcher@somewhere.com;tag=xfg9 526 From: sip:resource@example.com;tag=ffd2 527 Call-ID: 2010@watcherhost.example.com 528 Event: presence 529 Subscription-State: active;expires=599 530 Max-Forwards: 70 531 CSeq: 8775 NOTIFY 532 Contact: sip:server.example.com 533 Content-Type: application/pidf-partial+xml 534 Content-Length: .. 536 PIDF-PARTIAL+XML Document with �FULL STATE� information: 537 538 541 542 open 543 tel:09012345678 544 546 547 open 548 549 im:pep@nokia.com 550 551 553 F4 200 OK watcher-> example.com server 555 SIP/2.0 200 OK 556 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk 557 ;received=192.0.2.2 558 To: sip:watcher@somewhere.com;tag=xfg9 559 From: sip:resource@example.com;tag=ffd2 560 Call-ID: 2010@watcherhost.example.com 561 CSeq: 8775 NOTIFY 562 Content-Length: 0 564 F5 NOTIFY example.com server -> watcher 566 It is the local policy issue to construct the �PIDF-partial+xml� 567 formated document including the delta from the previous NOTIFY. 569 NOTIFY sip:user@watcherhost.example.com SIP/2.0 570 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl 571 To: sip:watcher@somewhere.com;tag=xfg9 572 From: sip:resource@example.com;tag=ffd2 573 Call-ID: 2010@watcherhost.example.com 574 CSeq: 8776 NOTIFY 575 Event: presence 576 Subscription-State: active;expires=543 577 Max-Forwards: 70 578 Contact: sip:server.example.com 579 Content-Type: application/pidf-partial+xml 580 Content-Length: ... 582 New PIDF-PARTIAL+XML Document with �PARTIAL STATE� information: 583 584 587 588 closed 589 590 im:pep@nokia.com 591 This is an update of existing tuple 592 sent in previous notification 593 595 596 open 597 598 im:mac@hut.com 599 This is a completely new tuple not 600 sent in previous notification 601 602 604 F6 200 OK watcher-> example.com server 605 SIP/2.0 200 OK 606 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl 607 ;received=192.0.2.2 608 To: sip:watcher@somewhere.com;tag=xfg9 609 From: sip:resource@example.com;tag=ffd2 610 Call-ID: 2010@watcherhost.example.com 611 CSeq: 8776 NOTIFY 612 Content-Length: 0 614 6.1.2 Subscription with partial notification as requirement 616 The watcher sends SUBSCRIBE request including �partial-notification� 617 extension in the �Require� header field. The PS does not support the 618 �partial-notification� extension, so it rejects the subscription. The 619 watcher re-subscribed without including the �require� header field. 621 Watcher Presence Server PUA 622 | F1 SUBSCRIBE | | 623 |-------------------------->| | 624 | F2 420 Bad Extension | | 625 |<--------------------------| | 626 | F3 SUBSCRIBE | | 627 |-------------------------->| | 628 | F4 200 OK | | 629 |<--------------------------| | 630 | F5 NOTIFY | | 631 |<--------------------------| | 632 | F6 200 OK | | 633 |-------------------------->| | 634 | | | 635 | | Update presence | 636 | |<----------------------- | 637 | | | 638 | F7 NOTIFY | | 639 |<--------------------------| | 640 | F8 200 OK | | 641 |-------------------------->| | 643 Message Details: 645 F1 SUBSCRIBE watcher->example.com server 646 SUBSCRIBE sip:resource@example.com SIP/2.0 647 Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7 648 To: sip:resource@example.com 649 From: sip:watcher@somewhere.com;tag=xfg9 650 Call-ID: 2010@watcherhost.example.com 651 CSeq: 17766 SUBSCRIBE 652 Max-Forwards: 70 653 Event: presence 654 Require: partial-notification 655 Contact: sip:user@watcherhost.example.com 656 Expires: 600 658 Content-Length: 0 660 F2 420 Bad Extension example.com server->watcher 662 The Presence Server does not support the extension indicated in the 663 �Require� header and the subscription is rejected. 665 SIP/2.0 420 OK 666 Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7 667 ;received=192.0.2.1 668 To: sip:resource@example.com 669 From: sip:watcher@somewhere.com;tag=xfg9 670 Call-ID: 2010@watcherhost.example.com 671 CSeq: 17766 SUBSCRIBE 672 Event: presence 673 Expires: 600 674 Unsupported: partial-notification 675 Contact: sip:server.example.com 676 Content-Length: 0 678 F3 SUBSCRIBE watcher -> example.com server 680 The watcher makes subscribtion without any requirements for partial 681 notification. The default presence service and PDIF format [1] are 682 applied. 684 SUBSCRIBE sip:resource@example.com SIP/2.0 685 Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7 686 To: sip:resource@example.com 687 From: sip:watcher@somewhere.com;tag=xfg9 688 Call-ID: 2010@watcherhost.example.com 689 CSeq: 17767 SUBSCRIBE 690 Max-Forwards: 70 691 Event: presence 692 Contact: sip:user@watcherhost.example.com 693 Expires: 600 694 Content-Length: 0 696 F4 200 OK example.com server->watcher 698 SIP/2.0 200 OK 699 Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7 700 ;received=192.0.2.1 701 To: sip:resource@example.com 702 From: sip:watcher@somewhere.com;tag=xfg9 703 Call-ID: 2010@watcherhost.example.com 704 CSeq: 17767 SUBSCRIBE 705 Event: presence 706 Expires: 600 707 Contact: sip:server.example.com 708 Content-Length: 0 710 F5 NOTIFY example.com server -> watcher 712 NOTIFY sip:user@watcherhost.example.com SIP/2.0 713 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk 714 To: sip:watcher@somewhere.com;tag=xfg9 715 From: sip:resource@example.com;tag=ffd2 716 Call-ID: 2010@watcherhost.example.com 717 Event: presence 718 Subscription-State: active;expires=599 719 Max-Forwards: 70 720 CSeq: 8775 NOTIFY 721 Contact: sip:server.example.com 722 Content-Type: application/cpim-pidf+xml 723 Content-Length: .. 725 CPIM-PIDF+XML formatted document: 726 727 730 731 open 732 tel:09012345678 733 735 736 open 737 738 im:pep@nokia.com 739 741 743 F6 200 OK watcher-> example.com server 745 SIP/2.0 200 OK 746 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk 747 ;received=192.0.2.2 748 To: sip:watcher@somewhere.com;tag=xfg9 749 From: sip:resource@example.com;tag=ffd2 750 Call-ID: 2010@watcherhost.example.com 751 CSeq: 8775 NOTIFY 752 Content-Length: 0 754 F7 NOTIFY example.com server -> watcher 756 NOTIFY sip:user@watcherhost.example.com SIP/2.0 757 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl 758 To: sip:watcher@somewhere.com;tag=xfg9 759 From: sip:resource@example.com;tag=ffd2 761 Call-ID: 2010@watcherhost.example.com 762 CSeq: 8776 NOTIFY 763 Event: presence 764 Subscription-State: active;expires=543 765 Max-Forwards: 70 766 Contact: sip:server.example.com 767 Content-Type: application/cpim-pidf+xml 768 Content-Length: ... 770 New CPIM-PIDF+XML formatted_document: 771 772 775 776 open 777 tel:09012345678 778 780 781 closed 782 783 im:pep@nokia.com 785 This is an update of existing 786 tuple sent in previous notification 787 789 790 open 791 792 im:mac@hut.com 793 This is a completely new tuple not 794 sent in previous notification 795 797 799 F8 200 OK 800 SIP/2.0 200 OK 801 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl 802 ;received=192.0.2.2 803 To: sip:watcher@somewhere.com;tag=xfg9 804 From: sip:resource@example.com;tag=ffd2 806 Call-ID: 2010@watcherhost.example.com 807 CSeq: 8776 NOTIFY 808 Content-Length: 0 810 7 XML Schema 812 The XML schema for the �pidf-partial+xml� data format. 814 815 821 822 825 827 828 829 831 833 835 836 837 839 840 841 842 843 844 845 846 847 849 850 851 852 854 855 857 858 859 860 862 863 864 865 867 868 869 870 871 872 873 874 876 877 878 879 880 881 882 883 884 885 886 887 888 889 891 892 893 894 895 896 898 899 900 901 902 This attribute may be used on any element within an optional 903 PIDF extension to indicate that the corresponding element must 904 be understood by the PIDF processor if the enclosing optional 905 element is to be handled. 906 907 908 909 911 8 Security Considerations 913 The security considerations for the presence are considered in [2], 914 and RFC 2779 [5] also outlines them. Furthermore, the PDIF [8] 915 document includes additional security requirements to be considered 916 in the data format for the partial notifications. 917 9 Acknowledgements 919 The authors would like to thank Kriztian Kiss, Juha Kalliokulju and 920 Tim Moran for their valuable comments. 922 10 References 924 [1] Rosenberg, J., et al, "SIP Extensions for Presence", draft-ietf- 925 simple-presence-07.txt. Internet Draft, May 2002, Work in progress. 927 [2] K.Kiss, �Requirements for Presence Service based on 3GPP 928 specifications and wireless environment characheristics� draft-kiss- 929 simple-presence-wireless-reqs-01.txt. Internet Draft, October 2002. 930 Work in progress. 932 [3] Price, R., et al, �Signaling Compression (SigComp)�, RFC 3320, 933 Internet Engineering Task Force, January 2003. 935 [4] Olson, S.,� A Mechanism for Content Indirection in Session 936 Initiation Protocol (SIP) Messages�, draft-ietf-sip-content-indirect- 937 mech-01. Internet Draft, November 2002, Work in progress. 939 [5] Khartabil. H.,� Congestion safety and Content Indirection�, 940 draft-khartabil-sip-congestionsafe-ci-01.txt, Internet Draft, October 941 2002, Work in progress. 943 [6] S. Bradner, "Key words for use in RFCs to indicate requirement 944 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 946 [7] J. Rosenberg, et al. �SIP: Session Initiation Protocol�. RFC 947 3261, Internet Engineering Task Force, June 2002. 949 [8] H. Sugano, S. Fujimoto, et al, "CPIM presence information data 950 format," draft-ietf-impp-cpim-pidf-05.txt. Internet Draft, May 2002. 951 Work in progress. 953 [9] M. Day, J. Rosenberg, H. Sugano, "A Model for Presence and 954 Instant Messaging", RFC 2778, Internet Engineering Task Force, 955 February 2000. 957 [10] Roach, A., "SIP-Specific Event Notification", RFC 3265, Internet 958 Engineering Task Force, June 2002. 960 [11] Rosenberg, J.,� A Watcher Information Event Template-Package for 961 the Session Initiation Protocol (SIP)�, draft-ietf-simple-winfo- 962 package-04.txt, Internet Draft, December 2002. Work in progress. 964 [12] Day, M., Aggarwal, S., Mohr, G., Vincent,K., "Instant Messaging/ 965 Presence Protocol Requirements", RFC 2779, Internet Engineering Task 966 Force, February 2000. 968 [13] K. McCloghrie et al, �Structure of Management Information 969 Version 2 (SMIv2)�, RFC 2578, STD 58, April 1999. 971 [14] Mealling, M., "The IETF XML Registry", draft-mealling-iana- 972 xmlns-registry-04, June 2002, work in progress. 974 [15] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," RFC 975 3023, Internet Engineering Task Force, Jan. 2001. 977 11 Author's Addresses 979 Jose Costa-Requena 980 Nokia 981 Valimotie 9 982 00380 HELSINKI 983 Finland 984 Tel: +358-71-8008000 985 E-mail: jose.costa-requena@nokia.com 987 Mikko Lonnfors 988 Nokia Research Center 989 P.O. Box 407 990 FIN-00045 NOKIA GROUP 991 Finland 992 Tel: +358 50 4836402 993 Email: mikko.lonnfors@nokia.com 995 Eva Leppanen 996 Nokia 997 P.O Box 785 998 FIN-33101 Tampere 999 FINLAND 1000 Tel: +358 7180 77066 1001 Email: eva-maria.leppanen@nokia.com 1003 Hisham Khartabil 1004 Nokia 1005 P.O. Box 321 1006 FIN-00045 1007 NOKIA GROUP 1008 FINLAND 1009 Email: hisham.khartabil@nokia.com 1010 Tel: + 358 7180 76161