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