idnits 2.17.1 draft-kiss-simple-presence-wireless-reqs-03.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 13) being 71 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 18, 2003) is 7493 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) -- Missing reference section? '1' on line 13 looks like a reference -- Missing reference section? '24' on line 152 looks like a reference -- Missing reference section? '25' on line 68 looks like a reference -- Missing reference section? '26' on line 68 looks like a reference -- Missing reference section? '27' on line 69 looks like a reference -- Missing reference section? '28' on line 70 looks like a reference -- Missing reference section? '29' on line 72 looks like a reference -- Missing reference section? '19' on line 482 looks like a reference -- Missing reference section? '5' on line 75 looks like a reference -- Missing reference section? '6' on line 399 looks like a reference -- Missing reference section? '7' on line 80 looks like a reference -- Missing reference section? '9' on line 457 looks like a reference -- Missing reference section? '11' on line 82 looks like a reference -- Missing reference section? '12' on line 82 looks like a reference -- Missing reference section? '17' on line 134 looks like a reference -- Missing reference section? '15' on line 84 looks like a reference -- Missing reference section? '8' on line 90 looks like a reference -- Missing reference section? '10' on line 467 looks like a reference -- Missing reference section? '14' on line 249 looks like a reference -- Missing reference section? '16' on line 256 looks like a reference -- Missing reference section? '21' on line 444 looks like a reference -- Missing reference section? '23' on line 167 looks like a reference -- Missing reference section? '37' on line 114 looks like a reference -- Missing reference section? '2' on line 123 looks like a reference -- Missing reference section? '31' on line 133 looks like a reference -- Missing reference section? '20' on line 134 looks like a reference -- Missing reference section? '32' on line 161 looks like a reference -- Missing reference section? '13' on line 284 looks like a reference -- Missing reference section? '30' on line 330 looks like a reference -- Missing reference section? '35' on line 330 looks like a reference -- Missing reference section? '36' on line 330 looks like a reference -- Missing reference section? '33' on line 473 looks like a reference -- Missing reference section? '18' on line 476 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 35 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Krisztian Kiss (ed.) 3 Internet-Draft Nokia 4 Expires: April 19, 2003 October 18, 2003 6 Requirements for Presence Service in 3GPP Wireless Systems 7 draft-kiss-simple-presence-wireless-reqs-03 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026 [1]. 14 Internet-Drafts are working documents of the Internet 15 Engineering Task Force (IETF), its areas, and its working 16 groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. Internet-Drafts are draft 18 documents valid for a maximum of six months and may be 19 updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed 27 at http://www.ietf.org/shadow.html. 29 The distribution of this memo is unlimited. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights 34 Reserved. 36 Abstract 38 This Internet-Draft defines requirements for Presence Service 39 in 3GPP wireless systems. 41 Krisztian Kiss 3GPP Presence Requirements October 2003 43 Table of contents 45 1. Introduction 2 46 1.1 Conventions used in this document 3 47 2. General characteristics of Wireless Systems 3 48 3. Requirements 3 49 3.1 Addressing Requirements 4 50 3.2 Publishing requirements 4 51 3.3 Subscription and notification requirements 5 52 3.4 Requirements for the content of the presence document 6 53 3.5 Authorization requirements 7 54 3.6 Watcher information requirements 8 55 3.7 Presencelist requirements 9 56 4. Security requirements 9 57 5. Charging Requirements 9 58 6. Proposal for next steps 9 59 Normative References 9 60 Informative References 10 61 Author's address 12 62 Appendix A. Contributors 12 63 Full Copyright Statement 13 65 1. Introduction 67 This Internet-Draft lists the requirements for Presence 68 Service in 3GPP wireless systems [24][25][26]. The 3GPP 69 Presence Service requirements are defined in [27], the 3GPP 70 Presence Service architecture is defined in [28], presence 71 service information flows and protocol details are defined in 72 [29]. The requirements on the Session Initiation Protocol 73 (SIP) for the Release 5 of the 3GPP IP Multimedia Subsystem 74 are described in [19]. Presence Service is referenced as 75 defined in IMPP Working Group in documents [5] and [6]. 77 This document does not document requirements that have led to 78 the creation and work in progress on a number of SIMPLE WG 79 specifications, i.e. subscriptions and notifications of user 80 presence [7], the SIP event notification extension for 81 collections [9], the SIP Event Template-Package for Watcher 82 Information documents [11][12], the content indirection 83 mechanism [17] and the SIMPLE Presence Publication Mechanism 84 [15]. Rather this document lists only requirements that are 85 additional to those that have led to the mechanisms proposed 86 in these documents. 88 The document also assumes the usage of the Common Presence and 89 Instant Messaging (CPIM) Presence Information Data Format 90 (PIDF) defined in [8] as the default presence document data 91 format, however some of the requirements presented here might 92 require extensions to PIDF. 94 Krisztian Kiss 3GPP Presence Requirements October 2003 96 The requirements presented in this document are proposed to be 97 evaluated by the SIMPLE Working Group. The result of this 98 evaluation process would help to determine the work expected 99 to be done in IETF and identify the work which might be done 100 in other standardization bodies, such as 3GPP. Thus, a more 101 precise work-share between standardization bodies could be 102 worked out. The overall goal of these requirements is to allow 103 the development of a fully standardized presence application 104 for wireless terminals, utilizing existing IETF and 3GPP 105 specifications. 107 Note that some of the requirements herein may be already 108 addressed in specific requirements documents, i.e. the data 109 manipulation requirements of SIMPLE systems [10], the presence 110 specific event notification filters requirements [14], the 111 rate limiting of event notifications requirements [16], the 112 watcher information filtering requirements [21], the SIMPLE 113 Presence Publication Requirements [23], the Efficient Delivery 114 of Presence Information requirements [37]. 116 1.1 Conventions used in this document 118 This document does not specify any protocol of any kind. 119 Therefore, the use of the key words "MUST", "MUST NOT", 120 "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 121 "RECOMMENDED", "MAY", and "OPTIONAL" in this document, as 122 described in RFC 2119 [2], does not apply. 124 2. General characteristics of Wireless Systems 126 The radio interface of wireless systems is often a scarce 127 resource. As such, the message exchange over the radio 128 interface and the size of the messages should be efficiently 129 compact and kept to a minimum. All the mechanisms developed 130 should make an efficient use of the radio interface. 132 There are existing mechanisms to fulfill this requirement, 133 such as signaling compression [31], partial publication, 134 partial notification [20], content indirection [17]. These 135 mechanisms must not be exclusive and must be capable to work 136 together. 138 As terminals could be rather small devices, the memory and 139 power consumption requirements, requirements for processing 140 power, and for screen size and rendering capabilities should 141 be kept to a minimum. Mandating support for additional 142 protocols and mechanisms in the wireless terminal must meet 143 this criteria. 145 3. Requirements 147 This section lists the requirements for Presence Service in the 148 3GPP IP Multimedia Subsystem wireless environment. Generally, 149 these protocol requirements stem from the special characteristics 150 of wireless systems, and the specific set of capabilities 151 specified by the 3GPP. More information on these aspects can be 152 found in 3GPP TS 23.228 [24]. 154 Krisztian Kiss 3GPP Presence Requirements October 2003 156 3.1 Addressing Requirements 158 ADDR-REQ1: It must be possible to use a single address to 159 identify the presentity and the watcher. 161 ADDR-REQ2: Use of E.164 numbers [32] in addressing presence 162 service entities must be supported. 164 3.2 Publishing requirements 166 Generic SIMPLE Presence Publication Requirements are listed in 167 [23]. 169 PUBL-REQ1: Standardized mechanism to publish presence information 170 There must be a standardized mechanism to publish the 171 presence information. 173 PUBL-REQ2: Partial publishing 174 The publish mechanism must allow a PUA to change only part 175 of the presentity's presence information. For example, a 176 PUA must be able to publish one single element of 177 the presentity's PIDF document, while the document 178 contains several elements. 180 PUBL-REQ3: Basic operations of publishing 181 It must be possible for the PUA to add segments to the 182 presence information as well as overwrite, modify or 183 remove existing elements of the presence information. 185 PUBL-REQ4: Mandatory-to-implement MIME type for presence document 186 There must be one mandatory-to-implement MIME type for the 187 publish mechanism. 189 PUBL-REQ5: Inclusion of direct content in the presence document 190 It must be possible for the presentity to include direct 191 content in the presence document. If the direct content is 192 part of the presence document, the signaling compression 193 should be able to maintain the compression efficiency. 195 PUBL-REQ6: Multiple PUAs 196 The publication mechanism must allow simultaneous 197 publishing from multiple distinct PUAs of a single 198 presentity. 200 PUBL-REQ7: Identifiers for PUAs 201 It must be possible to allocate unique identifiers for 202 every distinct PUAs of a particular presentity. 204 PUBL-REQ8: Identification of segments 205 The PUA must be able to publish to a specific segment of 206 the presence document, shared among many PUAs (the number 207 of sources must neither be limited nor pre-defined). This 208 means that the published segments need to be identified 209 across all of the PUAs of a particular presentity. The PUA 210 must be able to generate identifiers for the published 211 segments. 213 Krisztian Kiss 3GPP Presence Requirements October 2003 215 PUBL-REQ9: Discovering existing segments 216 It must be possible for the PUA to discover existing 217 segment identifiers together with their content published 218 by other PUAs belonging to the same presentity. 220 PUBL-REQ10: Hard-state segments 221 It must be possible to include hard-state segments in the 222 presence documents. This means that in case the PUAs do 223 not refresh presence information, the hard-state segments 224 remain available for the watchers. 226 PUBL-REQ11: Feedback on publishing 227 The PUA must be able to receive feedback about the result 228 of a publishing transaction, the feedback must contain 229 enough information for the principal controlling the 230 presentity to know that the published presence information 231 was successfully composed into the presence document by 232 the Presence Compositor. 234 3.3 Subscription and notification requirements 236 SUBNOT-REQ1: Presence information filtering 237 It must be possible for a watcher to select certain 238 elements from the presence information that he wants (or 239 does not want) to receive notifications for. As an 240 example, the watcher may only want to be notified when the 241 presentity becomes available for conferencing. 242 The Presence Server must be able to construct the presence 243 document to be delivered to the watcher according to the 244 watcher's filtering preferences. 245 Note that when determining the elements to be included in 246 the presence document, authorization rules are also needed 247 to be taken into account. 248 Note that there are detailed presence event filtering 249 requirements listed in [14]. 251 SUBNOT-REQ2: Limiting the rate of event notification 252 The watcher must be able to limit the maximum rate at 253 which the notifier can generate notifications in a 254 subscription. 255 Note that there are detailed requirements for the throttle 256 mechanism listed in [16]. 258 SUBNOT-REQ3: Anonymous subscription 259 It must be possible for the watcher to request an 260 anonymous subscription (i.e. the watcher's identifier will 261 not be revealed to the presentity). The anonymous request 262 may be accepted or rejected, depending on the presentity's 263 authorization rules as described by the AUTH-REQs. 264 Note that this requirement may be met with the overall 265 privacy solution for SIP. 267 Krisztian Kiss 3GPP Presence Requirements October 2003 269 SUBNOT-REQ4: Gathering information on presence information 270 It must be possible for the watcher to determine what presence 271 information is available for a particular presentity before 272 fetching or subscribing to the presence information elements 273 with actual values. 275 SUBNOT-REQ5: Direct content inclusion in presence information 276 It must be possible for the watcher to receive 277 notifications including direct contents. The mechanism 278 selected for notifying large size content must make 279 efficient use of the network resources and satisfy generic 280 wireless requirements as described in section 2. 282 SUBNOT-REQ6: Content indirection 283 Generic requirements for content indirection are listed in 284 [13]. In connection to presence the following requirements 285 have been identified: the Presence Server should be able 286 to perform content indirection. Watchers should have the 287 capability to indicate the support of content indirection. 288 The Presence Server must honor watcher's preferences 289 whether to perform content indirection or not when it 290 detects a situation where content indirection should be 291 performed. 293 SUBNOT-REQ7: Subscription on behalf of another user 294 It must be possible for a watcher to subscribe to the 295 presentity�s presence information on behalf of another 296 user. As an example, an Application Server may act as a 297 network-based watcher to provide presence based call 298 control, or a Resource List Server may collect 299 notifications from the individual resources of the 300 presentity collection on behalf of the watcher. 302 3.4 Requirements for the content of the presence document 304 CONT-REQ1: Unique identifiers for presence segments 305 The presence document contains presence segments. Each 306 presence segment must contain a unique identity which 307 makes it distinguishable from other presence segments 308 inside the presence document. 310 CONT-REQ2: Application specific identifiers 311 It must be possible to include application specific 312 identifiers in a presence tuple. This means that a 313 publishing application running in a PUA is able to address 314 a specific presence tuple to its peer watcher application 315 running in the watcher user agent. 317 CONT-REQ3: Rich content of the presence segments 318 RFC 2778 [6] defines the presence information element to 319 consist of a STATUS marker, an optional COMMUNICATION 320 ADDRESS, and optional OTHER PRESENCE MARKUP. A 321 COMMUNICATION ADDRESS includes a COMMUNICATION MEANS and a 322 CONTACT ADDRESS. 324 Krisztian Kiss 3GPP Presence Requirements October 2003 326 As a further requirement for this definition, it must be 327 possible to define rich content for a presence information 328 element (e.g. for the communication means: voice, video, 329 instant messaging, application). One possible solution to 330 fulfill this requirement is defined in [30], [35] and [36]. 332 CONT-REQ4: Multivalue concept 333 It must be possible to include multiple instances of the 334 semantically same presence information in the presence 335 document. The different instances should contain different 336 values of the same presence information and used to be 337 shown for different watchers. The different watchers must 338 only receive those instances of the presence information 339 they are authorized to by the presentity. As an example, 340 one group of watchers is shown a different value for the 341 status of presentity than the other. 342 The Presence Server must be able to distinguish whether 343 two presence information elements contain semantically 344 different presence information or they are different 345 instances of the semantically same presence information. 347 CONT-REQ5: Geographic location information 348 There must be a standardized attribute for the geographic 349 location information within the presence document. 351 CONT-REQ6: Presentity�s status 352 There must be a standardized attribute for the 353 presentity�s status within the presence document. 355 3.5 Authorization requirements 357 This section defines the requirements for how presentity is 358 able to authorize the presence subscriptions. Generic SIMPLE 359 data manipulation requirements are listed in [10]. 361 AUTH-REQ1: Standardized setting of authorization policy 362 There must be a standardized mechanism for the presentity 363 to control the authorization policy related to his own 364 presence information. 365 This means that the authorization policy document format 366 and a set of manipulation operations upon that format must 367 be standardized. 369 AUTH-REQ2: Extensibility of authorization policy 370 It should be possible for network operators to extend the 371 format of the authorization policy document and the 372 operations upon that format based on local policy. 374 AUTH-REQ3: Expressiveness of authorization rules 375 It must be possible for the presentity to set separate 376 authorization rules for different watchers and groups of 377 watchers. With these rules the presentity must be able to 378 override the default behaviour of the presence server for 379 the generation of notifications and content of the 380 notifications. As an example, only watchers belonging to a 381 particular group are allowed to receive information 382 related to presentity's location. 384 Krisztian Kiss 3GPP Presence Requirements October 2003 386 AUTH-REQ4: Managing the authorization policy from multiple sources 387 It must be possible for the presentity to manage the 388 authorization rules from multiple sources (e.g. from 389 different terminals of the presentity or by the service 390 provider on behalf of the presentity). It must be possible 391 for the presentity from one source to learn the changes in 392 the authorization rules changed by other sources belonging 393 to the same presentity. 395 AUTH-REQ5: Granularity of access rights 396 It must be possible for the presentity to grant access 397 rights separately for all elements of the presence 398 information. 399 RFC 2778 [6] defines a model for presence information. 400 Based on this model more specific requirements can be 401 stated: 402 It must be possible for the Presence Server to decide 403 based on authorization rules whether to include a certain 404 tuple in the notification. It must be possible to base 405 that decision on any element in the tuple. In the default 406 case these must include at least TUPLE ID, CONTACT 407 ADDRESS, COMMUNICATION MEANS and STATUS attributes. As a 408 special case, it must be possible for the Presence Server 409 to provide different status values for same COMMUNICATION 410 ADDRESS or combination of COMMUNICATION ADDRESS and OTHER 411 PRESENCE MARKUPs. 413 AUTH-REQ6: Expiry of access rights 414 It must be possible to grant access rights with an expiry 415 time to a particular watcher or group. 417 AUTH-REQ7: Presence authorization policy manipulation alignment 418 with conferencing 419 The solution for authorization policy manipulation should 420 be aligned with other data manipulation operations used 421 for similar purposes (such as conferencing). 423 AUTH-REQ8: Authorization of subscriptions generated on behalf 424 of another user 425 It must be possible for the Presence Server to authorize 426 subscriptions to presentity�s presence information which 427 are generated on behalf of another user. It should be 428 possible for the presentity to set authorization rules 429 taking into account both the identity of the watcher and 430 the identity of the user on whose behalf the subscription 431 is made. 433 3.6 Watcher information requirements 435 WATCHINF-REQ1: Pending watcher notification 436 It must be possible for a presentity to be informed of a 437 pending watcher subscription from a currently unauthorized 438 and/or unknown watcher. 440 WATCHINF-REQ2: Watcher information filtering 441 It must be possible for the presentity to monitor the 442 watcher status of certain watchers. 443 Note that there are detailed watcher information filtering 444 requirements listed in [21]. 446 Krisztian Kiss 3GPP Presence Requirements October 2003 448 WATCHINF-REQ3: Watcher history 449 It must be possible for the presentity to fetch the list 450 of the watchers who have accessed (by subscription or 451 fetch) his presence information during a well-defined time- 452 period (e.g. last 7 days). 454 3.7 Presencelist requirements 456 PRLIST-REQ1: Filtering for presentity collection 457 It must be possible for the Resource List Server [9] to 458 construct and store appropriate filtering rules for every 459 URI in the presencelist based on the watcher's filtering 460 preferences. 462 PRLIST-REQ2: Management of presentity collection data element 463 Requirements for creating a presentity collection, adding 464 new URIs to an existing presentity collection, modifying 465 or removing existing URIs from an existing presentity 466 collection, or deleting a presentity collection are listed 467 in [10]. 469 4. Security requirements 471 Presence specifications must not preclude authentication on 472 behalf of presence entities by other entities within a trust 473 domain, and communication as defined by RFC 3325 [33]. 475 Security requirements assume requirements that have led to 476 existing security mechanism described in [18]. Further 477 security requirements over and above this have not yet been 478 identified. 480 5. Charging Requirements 482 This document refers to the charging requirements of [19], and 483 does not list any additional charging requirements at this 484 time. 486 6. Proposal for next steps 488 It is proposed that SIMPLE Working Group evaluates the 489 requirements presented in this document and incorporates the 490 relevant ones in its current work items. Those requirements 491 possibly falling out of the scope of the SIMPLE WG should find 492 a more suitable home, possibly also in other standardization 493 bodies. 495 It is not expected that this document be published as an RFC by the 496 IETF, but rather serve as a reference to various working group 497 requirements documents. It is also expected that this document is 498 used as a check list as requirements get included to other documents. 500 Krisztian Kiss 3GPP Presence Requirements October 2003 502 Normative References 504 1. S. Bradner, "The Internet Standards Process -- Revision 3", 505 BCP 9, RFC 2026, October 1996. 507 2. S. Bradner, "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, March 1997. 510 Informative References 512 3. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 513 Peterson, R. Sparks, M. Handley, E. Schooler: "SIP, Session 514 Initiation Protocol", RFC 3261, June 2002 516 4. A. Roach, "ession Initiation Protocol (SIP)-Specific Event 517 Notification", RFC 3265, June 2002 519 5. M. Day, S. Aggarwal, G. Mohr, J. Vincent "Instant Messaging 520 / Presence Protocol Requirements", RFC 2779 522 6. M. Day, J. Rosenberg, H. Sugano, "A Model for Presence and 523 Instant Messaging", RFC 2778 525 7. J. Rosenberg et al., "SIP Extensions for Presence", draft- 526 ietf-simple-presence-10.txt, January 2003, work in progress 528 8. H. Sugano, S. Fujimoto, G. Klyne, A. Bateman: "CPIM 529 Presence Information Data Format", draft-ietf-impp-cpim-pidf- 530 08.txt, May 2003, work in progress 532 9. A. Roach, J. Rosenberg, B. Campbell, "A Session Initiation 533 Protocol (SIP) Event Notification Extension for Collections", 534 draft-ietf-simple-event-list-04.txt, June 2003, work in 535 progress 537 10. J. Rosenberg, M. Isomaki, "Requirements for Manipulation 538 of Data Elements in SIMPLE Systems", draft-ietf-simple-data- 539 req-03.txt, June 2003, work in progress 541 11. J. Rosenberg, "A Session Initiation Protocol (SIP) Event 542 Template-Package for Watcher Information", draft-ietf-simple- 543 winfo-package-05.txt, January 2003, work in progress 545 12. J. Rosenberg, "An Extensible Markup Language (XML) Based 546 Format for Watcher Information", draft-ietf-simple-winfo- 547 format-04.txt, January 2003, work in progress 549 13. S. Olson, "Requirements for Content Indirection in SIP 550 Messages", draft-ietf-sipping-content-indirect-03.txt, 551 February 2003, work in progress 553 14. E. Leppanen, et al, "Requirements for Presence 554 specific Event Notification Filtering", draft-ietf-simple- 555 pres-filter-reqs-02, August 2003, work in progress 557 Krisztian Kiss 3GPP Presence Requirements October 2003 559 15. A. Niemi, et al, "Session Initiation Protocol (SIP) 560 Extension for Event State Publication", draft-ietf-sip- 561 publish-00, September 2003, work in progress 563 16. A. Niemi, "Requirements for Limiting the Rate of Event 564 Notifications", draft-niemi-sipping-event-throttle-reqs-02, 565 June 2003, work in progress 567 17. S. Olson, "A Mechanism for Content Indirection in SIP 568 Messages", draft-olson-sip-content-indirect-mech-02, 569 February 2003, work in progress 571 18. J. Arkko, V. Torvinen, G. Camarillo, T. Haukka, S. Sen, 572 "Security Mechanism Agreement for SIP Sessions", RFC 3329, 573 January 2003 575 19. M. Garcia-Martin, "3rd-Generation Partnership Project 576 (3GPP) Release 5 requirements on the Session Initiation 577 Protocol (SIP), draft-ietf-sipping-3gpp-r5-requirements- 578 00.txt, October 2002, work in progress 580 20. J. Costa-Requena, E. Leppanen, H. Khartabil, M. Lonnfors, 581 "Partial Notification of Presence Information", draft- 582 ietf-simple-partial-notify-00.txt, September 2003, work in 583 progress 585 21. K. Kiss, E. Leppanen, H. Khartabil, "Requirements for 586 Filtering of Watcher Information", draft-ietf-simple-winfo- 587 filter-reqs-00.txt, May 2003, work in progress 589 22. J. Costa-Requena, E. Leppanen, H. Khartabil, M. Lonnfors, 590 "Functional Description of Event Notification Filtering", 591 draft-khartabil-simple-presence-filter-funct-00.txt, 592 May 2003, work in progress 594 23. B. Campbell, S. Olson, J. Peterson, J. Rosenberg, B. 595 Stucker, "SIMPLE Presence Publication Requirements", draft- 596 ietf-simple-publish-reqs-00, February 2003, work in progress 598 24. 3GPP TS 23.228 "IP Multimedia Subsystem (IMS) (Stage 2) - 599 Release 5", Version 6.3.0 available at 600 ftp://ftp.3gpp.org/specs/latest/Rel-5/23_series/ 602 25. 3GPP TS 24.228: "Signaling flows for the IP Multimedia 603 call control based on SIP and SDP", Version 5.6.0 available at 604 ftp://ftp.3gpp.org/specs/archive/24_series/24.228/ 606 26. 3GPP TS 24.229: "IP Multimedia Call Control Protocol based 607 on SIP and SDP, stage 3", Version 6.0.0 available at 608 ftp://ftp.3gpp.org/specs/archive/24_series/24.229/ 610 27. 3GPP TS 22.141: "Presence Service, Stage 1", Version 6.2.0 611 available at 612 ftp://ftp.3gpp.org/specs/archive/22_series/22.141/ 614 Krisztian Kiss 3GPP Presence Requirements October 2003 616 28. 3GPP TS 23.141: "Presence Service, Architecture and 617 Functional Description, Stage 2", Version 6.4.0 available at 618 ftp://ftp.3gpp.org/specs/archive/23_series/23.141/ 620 29. 3GPP TS 24.841: "Presence service based on Session 621 Initiation Protocol (SIP); Functional models, information 622 flows and protocol details", Version 1.1.0 available at 623 ftp://ftp.3gpp.org/specs/latest-drafts 625 30. H. Schulzrinne, et al, "RPID -- Rich Presence Information 626 Data Format", draft-ietf-simple-rpid-00.txt, July 2003, 627 work in progress 629 31. R. Price, C. Bormann, J. Christoffersson, H. Hannu, Z. 630 Liu, J. Rosenberg, "Signaling Compression (SigComp)", RFC 631 3320, January 2003 633 32. International Telecommunications Union, "The International 634 Public Telecommunication Numbering Plan", ITU-T Recommendation 635 E.164, 1991. 637 33. C. Jennings, J. Peterson, M. Watson, "Private Extensions 638 to the Session Initiation Protocol (SIP) for Asserted Identity 639 within Trusted Networks", RFC 3325, November 2002 641 34. J. Costa-Requena, E. Leppanen, H. Khartabil, M. Lonnfors, 642 "An Extensible Markup Language (XML) Based Format for Event 643 Notification Filtering", draft-khartabil-simple-presence- 644 format-00.txt, April 2003, work in progress 646 35. H. Schulzrinne, et al, "CIPID -- Contact Information in 647 Presence Information Data Format", draft-ietf-simple- 648 cipid-00.txt, August 2003, work in progress 650 36. M. Lonnfors, K. Kiss, "Device capability PIDF status 651 extension", draft-lonnfors-simple-prescaps-ext-02, October 652 2003, work in progress 654 37. M. Lonnfors, et al, "Requirements for Efficient Delivery 655 of Presence Information ", draft-ietf-simple-presinfo-deliv- 656 reg-00.txt, May 2003, work in progress 658 Author's address 660 Krisztian Kiss 661 Nokia 662 12278 Scripps Summit Drive 663 San Diego, CA 92131, USA 664 Phone: +1 858 2049141 665 Email: krisztian.kiss@nokia.com 667 Krisztian Kiss 3GPP Presence Requirements October 2003 669 Appendix A. Contributors 671 The author would like to thank the following people for their 672 interest, support and efforts when writing this Internet- 673 Draft: 675 Gabor Bajko (Nokia), Markus Isomaki (Nokia), Mikko 676 Lonnfors (Nokia), Juha Kalliokulju (Nokia), Eva-Maria 677 Leppanen (Nokia), Georg Mayer (Nokia), Mark Beckmann 678 (Siemens), Sonia Garapaty (Nortel), Jayshree Bharatia 679 (Nortel), Keith Drage (Lucent), Andrew Allen, Kevan Hobbis 680 (3), Alexandre Harmand (O2), Duncan Mills (Vodafone), 681 Miguel A. Garcia (Ericsson), Milo Orsic (Lucent), Hugh 682 Shieh (AWS), Aki Niemi (Nokia). 684 Although not an official communication of the 3GPP, this 685 document has been discussed and commented by a number of 686 delegates in the relevant 3GPP working groups. 688 Full Copyright Statement 690 Copyright (C) The Internet Society (2003). All Rights 691 Reserved. 693 This document and translations of it may be copied and 694 furnished to others, and derivative works that comment on or 695 otherwise explain it or assist in its implementation may be 696 prepared, copied, published and distributed, in whole or in 697 part, without restriction of any kind, provided that the above 698 copyright notice and this paragraph are included on all such 699 copies and derivative works. However, this document itself 700 may not be modified in any way, such as by removing the 701 copyright notice or references to the Internet Society or 702 other Internet organizations, except as needed for the purpose 703 of developing Internet standards in which case the procedures 704 for copyrights defined in the Internet Standards process must 705 be followed, or as required to translate it into languages 706 other than English. 708 The limited permissions granted above are perpetual and will 709 not be revoked by the Internet Society or its successors or 710 assigns. 712 This document and the information contained herein is provided 713 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 714 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 715 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 716 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 717 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 718 PARTICULAR PURPOSE. 720 Acknowledgement 722 Funding for the RFC Editor function is currently provided by 723 the Internet Society.