idnits 2.17.1 draft-garcia-sipping-poc-isb-am-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 947. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 924. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 931. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 937. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 27, 2005) is 6786 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) ** Obsolete normative reference: RFC 2141 (ref. '2') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3023 (ref. '3') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3265 (ref. '5') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3427 (ref. '6') (Obsoleted by RFC 5727) ** Obsolete normative reference: RFC 3851 (ref. '9') (Obsoleted by RFC 5751) -- Possible downref: Non-RFC (?) normative reference: ref. '10' == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-03 Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group M. Garcia-Martin 3 Internet-Draft Nokia 4 Expires: March 31, 2006 September 27, 2005 6 A Session Initiation Protocol (SIP) Event Package and Data Format for 7 Various Settings in Support for the Push-to-talk Over Cellular (PoC) 8 Service 9 draft-garcia-sipping-poc-isb-am-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 31, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The Open Mobile Alliance (OMA) is defining the Push-to-talk Over 43 Cellular (PoC) service where SIP is the protocol used to establish 44 half duplex media sessions across different participants, send 45 instant messages, etc. This document defines a SIP event package to 46 support publication, subscription, and notification of additional 47 capabilities required by the PoC service. This SIP event package is 48 applicable to the PoC service and may not be applicable to the 49 general Internet. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 56 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 5. The "poc-settings" Event Package . . . . . . . . . . . . . . . 6 58 5.1. Package Name . . . . . . . . . . . . . . . . . . . . . . . 6 59 5.2. Event Package Parameters . . . . . . . . . . . . . . . . . 7 60 5.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 7 61 5.4. Subscription duration . . . . . . . . . . . . . . . . . . 7 62 5.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 7 63 5.6. Notifier processing of SUBSCRIBE requests . . . . . . . . 8 64 5.6.1. Authentication . . . . . . . . . . . . . . . . . . . . 8 65 5.6.2. Authorization . . . . . . . . . . . . . . . . . . . . 8 66 5.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 8 67 5.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 9 68 5.9. Handling of Forked Requests . . . . . . . . . . . . . . . 10 69 5.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 10 70 5.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 5.13. Use of URIs to Retrieve State . . . . . . . . . . . . . . 10 73 5.14. PUBLISH bodies . . . . . . . . . . . . . . . . . . . . . . 11 74 5.15. PUBLISH Response Bodies . . . . . . . . . . . . . . . . . 11 75 5.16. Multiple Sources for Event State . . . . . . . . . . . . . 11 76 5.17. Event State Segmentation . . . . . . . . . . . . . . . . . 11 77 5.18. Rate of Publication . . . . . . . . . . . . . . . . . . . 12 78 6. PoC-Settings Document . . . . . . . . . . . . . . . . . . . . 12 79 6.1. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 14 80 6.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 9.1. Registration of the "poc-settings" Event Package . . . . . 17 85 9.2. Registration of the "application/poc-settings+xml" 86 MIME type . . . . . . . . . . . . . . . . . . . . . . . . 18 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 89 10.2. Informational References . . . . . . . . . . . . . . . . . 20 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 Intellectual Property and Copyright Statements . . . . . . . . . . 22 93 1. Introduction 95 The Open Mobile Alliance (OMA) (http://www.openmobilealliance.org) is 96 currently specifying the Push-to-talk over Cellular (PoC) service. 97 This service allows a SIP UA (PoC terminal) to establish a session to 98 one or more SIP UAs simultaneously, usually initiated by the 99 initiating user pushing a button. 101 OMA has defined a collection of very stringent requirements in 102 support of the PoC service. In order to provide the user with a 103 satisfactory experience the initial session establishment from the 104 time the user presses the button to the time they get an indication 105 to speak must be minimized. 107 The PoC terminal may support such hardware capabilities as a 108 speakerphone and/or headset and software that provide the capability 109 for the user to configure the PoC terminal to accept session 110 initiations immediately and play out the media as soon as it is 111 received without requiring the intervention of the called user. This 112 mode of operation is known as Auto-Answer mode or automatic mode. 113 The user may alternatively configure the PoC terminal to first alert 114 the user and require the user to manually accept the session 115 invitation before media is accepted. This mode of operation is known 116 as Manual-Answer mode. The PoC terminal may support both or only one 117 of these modes of operation. The user may change the Answer Mode 118 (AM) configuration of the PoC terminal frequently based on their 119 current circumstances and preference, (perhaps because the user is 120 busy or in a public area where she cannot use a speaker phone, etc.). 122 SIP PoC terminals can support various SIP-based communication 123 services in addition to Push-to-talk (e.g., VoIP telephony, presence 124 services, messaging services, etc.). The user may at times wish to 125 disable the acceptance of Push-to-talk sessions whilst still 126 remaining SIP registered for one or more other SIP based services. 127 When the PoC terminal is configured to not accept any incoming Push- 128 to-talk sessions this is known as Incoming Session Barring (ISB). 130 A user may wish to contact a user who has their PoC terminal with 131 Incoming Session Barring enabled. A user may send an Instant 132 Personal Alert to another user to inform them that they wish to 133 engage them in a PoC Session. This Instant Personal Alert is 134 received even when the destination PoC terminal has enabled Incoming 135 Session Barring. If a user wishes to disable the acceptance of 136 Instant Personal Alerts they can configure their PoC terminal not 137 accept any incoming Instant Personal Alerts. This is known as 138 Instant Personal Alert Barring (IPAB). 140 Some PoC terminals may provide support for handling multiple PoC 141 sessions simultaneously whereas other terminals are only able to 142 handle one single PoC session at time. Or even if the terminal is 143 able to handle multiple PoC sessions simultaneously, the user may 144 desire to have just one single PoC session at a time. This 145 indication of support for multiple PoC sessions simultaneously is 146 known as Simultaneous PoC Sessions Support (SSS). 148 The OMA PoC Architecture utilizes SIP servers within the network that 149 may perform roles such as a conference focus [12], RTP translator, or 150 a policy server. A possible optimization to minimize the delay in 151 providing the caller with an indication to speak consist of the SIP 152 network server to perform buffering of media packets in order to 153 provide an early or unconfirmed indication to the caller and allow 154 the caller to start speaking before the called PoC terminal has 155 answered. This optimization only is appropriate when the called PoC 156 terminal is currently accepting PoC sessions and its Answer Mode is 157 set to Auto-Answer. This optimization therefore requires the network 158 SIP server to have knowledge of the current ISB and AM settings of 159 the called PoC terminal. 161 Similarly, in order to avoid unnecessary transmission of Instant 162 Personal Alerts across the radio interface, the network SIP server 163 needs to have knowledge of the current IPAB setting at the terminal. 165 When the UA supports multiple PoC sessions simultaneously the server 166 needs to act as a B2BUA in order to multiplex media and floor control 167 signaling between multiple sessions using a single bandwidth limited 168 radio bearer. When handling of multiple PoC sessions simultaneously 169 is not needed the server can act as a SIP proxy. It is therefore 170 advantageous for the server to be informed whether the UA currently 171 intends to support multiple PoC sessions simultaneously. 173 This document proposes additional SIP capabilities to enable the 174 communication of the ISB, AM, IPAB, and SSS settings between the SIP 175 PoC terminal and the SIP network server. 177 We define a SIP event package that allows a SIP Event Publication 178 Agent (EPA) to publish the user's settings at that particular EPA 179 which may impact some specific session attempts. This allows 180 subscribers to subscribe to the Event State Compositor to this event 181 package to gather this information, and anticipate to the user's 182 needs when a session is attempted to that user. It is believed that 183 the SIP event package defined here is not applicable to the general 184 Internet: it has been designed to serve the architecture of the PoC 185 service. In particular, and in the context defined by RFC 3903 [8], 186 it is the intention of OMA to make PoC terminals behave as Event 187 Publication Agents (EPA), and network servers behave as Event State 188 Compositors (ESC). It is possible that PoC terminals and network 189 servers may also subscribe to the user's PoC related settings, so 190 that changes in this state made in one terminal are kept in 191 synchronization across all different terminals or with the network 192 server for a particular user. 194 This document defines a PoC-settings document that allows an EPA to 195 convey its ISB, AM, IPAB, and SSS settings to an ESC. The EPA sends 196 a PoC-settings document in PUBLISH requests [8]. The PoC-settings 197 document contain represents the settings view at that particular EPA. 198 The ESC can collect PoC-settings document for the same user at 199 different EPAs, apply a composition policy, and provide 200 notifications. Notifications can contain a composed view of the 201 settings or a list of settings per EPA, depending on whether the ESC 202 is able to resolve conflicts or not. A subscriber can receive 203 notifications of changes in this document according to the procedures 204 specified in RFC 3265 [5]. The aim of this memo is to follow the 205 procedure indicated in RFC 3427 [6] and to register a new poc- 206 settings event package with IANA. 208 2. Terminology 210 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 211 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 212 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 213 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 214 compliant implementations. 216 3. Applicability Statement 218 The event package defined in this document is intended for use with 219 network based application servers that provide a Push-to-Talk over 220 Cellular service. 222 4. Requirements 224 A comprehensive description of all the requirements that affect the 225 Push-to-Talk over Cellular service developed by the Open Mobile 226 Alliance can be found in the Open Mobile Alliance web page at 227 http://www.openmobilealliance.org. 229 For the sake of simplicity, we briefly discuss here those 230 requirements that affect the solution described in this document. 231 These requirements can be summarized in: 233 1. There must be a mechanism that reduces the session setup time as 234 much as possible. 235 2. In order to allow a proper usage of scarce resources, there must 236 be a mechanism that saves the air interface from be congested 237 with unneeded or undesired traffic. 238 3. The mechanism should not involve the implementation of new 239 protocols, unless strictly needed. 241 These requirements lead to develop a solution whereby the user can 242 indicate to a network node his ability to accept or reject sessions 243 or certain types of messages. Pushing these settings to a network 244 node allows the network node to produce a faster response the 245 originator, perhaps even declining or filtering some SIP requests 246 towards the destination, leading to achieving the goal of reducing 247 the session setup time. 249 5. The "poc-settings" Event Package 251 RFC 3265 [5] defines a SIP extension for subscribing to, and 252 receiving notifications of changes (events) in the state of remote 253 nodes. It leaves the definition of many aspects of these events to 254 concrete extensions, known as event packages. This document 255 qualifies as an event package. This section fills in the information 256 required for all event packages by RFC 3265 [5]. 258 Additionally, RFC 3903 [8] defines an extension that allows SIP User 259 Agents to publish event state. According to RFC 3903 [8] any event 260 package intended to be used in conjunction with the SIP PUBLISH 261 method has to include a considerations section. This section also 262 fills the information for all event packages to be used with PUBLISH 263 requests. 265 We define a new "poc-settings" event package. Event Publication 266 Agents (EPA) use PUBLISH requests to inform an Event State Compositor 267 (ESC) of changes in the poc-settings event package. The ESC, acting 268 as a notifier, notifies subscribers to the user's poc-settings 269 information when changes occur. 271 5.1. Package Name 273 The name of this package is "poc-settings". As specified in RFC 3265 274 [5], this value appears in the Event header field present in 275 SUBSCRIBE and NOTIFY requests. As specified in the RFC 3903 [8], 276 this value appears as well in the Event header field present in 277 PUBLISH requests. 279 5.2. Event Package Parameters 281 RFC 3265 [5] allows event packages to define additional parameters 282 carried in the Event header field. This event package, "poc- 283 settings", does not define additional parameters. 285 5.3. SUBSCRIBE Bodies 287 According to RFC 3265 [5], a SUBSCRIBE request can contain a body. 288 The purpose of the body depends on its type. Subscriptions to the 289 poc-settings event package will normally not contain bodies. 291 The Request-URI of the SUBSCRIBE request identifies the user to which 292 the subscriber wants to be informed of the poc-settings. 294 5.4. Subscription duration 296 The default expiration time for subscriptions within this package is 297 3600 seconds. As per RFC 3265 [5], the subscriber MAY specify an 298 alternate expiration in the Expires header field. 300 5.5. NOTIFY Bodies 302 As described in RFC 3265 [5], the NOTIFY message will contain bodies 303 describing the state of the subscribed resource. This body is in a 304 format listed in the Accept header field of the SUBSCRIBE request, or 305 a package-specific default if the Accept header field was omitted 306 from the SUBSCRIBE request. 308 In this event package, the body of the notification contains a PoC- 309 settings document (see Section 6). The ESC has gathered PoC-settings 310 document for the user at different EPAs. The ESC applies a 311 composition policy, and composes a PoC-settings document with a 312 common view of all these settings across different EPAs. In case the 313 ESC is not able to resolve a conflict, due to contradictory 314 information provided by two different EPAs, the ESC provides a PoC- 315 settings document containing the settings at each terminal, so that 316 the subscriber can resolve the conflict. 318 All subscribers and notifiers of the "poc-settings" event package 319 MUST support the "application/poc-settings+xml" data format described 320 in Section 6. The SUBSCRIBE request MAY contain an Accept header 321 field. If no such header field is present, it has a default value of 322 "application/poc-settings+xml" (assuming that the Event header field 323 contains a value of "poc-settings"). If the Accept header field is 324 present, it MUST include "application/poc-settings+xml", and MAY 325 include any other types capable of representing user settings for 326 PoC. 328 5.6. Notifier processing of SUBSCRIBE requests 330 The contents of a PoC-settings document can contain sensitive 331 information that can reveal some privacy information. Therefore, 332 PoC-settings documents MUST only be sent to authorized subscribers. 333 In order to determine if a subscription originates in an authorized 334 user, the user MUST be authenticated as described in Section 5.6.1 335 and then he MUST be authorized to be a subscriber as described in 336 Section 5.6.2. 338 5.6.1. Authentication 340 Notifiers MUST authenticate all subscription requests. This 341 authentication can be done using any of the mechanisms defined in RFC 342 3261 [4] and other authentication extensions. 344 5.6.2. Authorization 346 Once authenticated, the notifier makes an authorization decision. A 347 notifier MUST NOT accept a subscription unless authorization has been 348 provided by the user. The means by which authorization are provided 349 are outside the scope of this document. Authorization may have been 350 provided ahead of time through access lists, perhaps specified in a 351 web page. Authorization may have been provided by means of uploading 352 of some kind of standardized access control list document. 354 5.7. Notifier Generation of NOTIFY Requests 356 RFC 3265 [5] details the formatting and structure of NOTIFY messages. 357 However, packages are mandated to provide detailed information on 358 when to send a NOTIFY, how to compute the state of the resource, how 359 to generate neutral or fake state information, and whether state 360 information is complete or partial. This section describes those 361 details for the poc-settings event package. 363 A notifier MAY send a NOTIFY at any time. Typically, it will send 364 one when the poc-settings stage of a user changes. The NOTIFY 365 request MAY contain a body containing a PoC-settings document. The 366 times at which the NOTIFY is sent for a particular subscriber, and 367 the contents of the body within that notification, are subject to any 368 rules specified by the authorization policy that governs the 369 subscription, but typically will contain an indication of those PoC 370 related services for which a change has occurred. 372 In the case of a pending subscription, when final authorization is 373 determined, a NOTIFY can be sent. If the result of the authorization 374 decision was success, a NOTIFY SHOULD be sent and SHOULD contain a 375 complete PoC-settings document with the current state of the user's 376 PoC settings. If the subscription is rejected, a NOTIFY MAY be sent. 377 As described in RFC 3265 [5], the Subscription-State header field 378 indicates the state of the subscription. 380 The body of the NOTIFY MUST be sent using one of the types listed in 381 the Accept header field in the most recent SUBSCRIBE request, or 382 using the type "application/poc-settings+xml" if no Accept header 383 field was present. 385 Notifiers will typically act as Event State Compositors (ESC) and 386 thus, will learn the poc-settings event state via PUBLISH requests 387 sent from the user's Event Publication Agent (EPA) when the user 388 changes one of those settings. It is possible that the notifier 389 generates a NOTIFY request for a user for which no publication has 390 taken place. In that case the PoC-settings document will not contain 391 any element (see Section 6.1 for a detailed description of 392 the element). 394 For reasons of privacy, it will frequently be necessary to encrypt 395 the contents of the notifications. This can be accomplished using 396 S/MIME [9]. The encryption can be performed using the key of the 397 subscriber as identified in the From field of the SUBSCRIBE request. 398 Similarly, integrity of the notifications is important to 399 subscribers. As such, the contents of the notifications MAY provide 400 authentication and message integrity using S/MIME [9]. Since the 401 NOTIFY is generated by the notifier, which may not have access to the 402 key of the user represented by the poc-settings user, it will 403 frequently be the case that the NOTIFY is signed by a third party. 404 The NOTIFY request SHOULD be signed by an authority over the domain 405 of the user. In other words, for a user whose SIP URI is 406 sip:user@example.com, the signator of the NOTIFY SHOULD be the 407 authority for example.com. 409 5.8. Subscriber Processing of NOTIFY Requests 411 RFC 3265 [5] leaves it to event packages to describe the process 412 followed by the subscriber upon receipt of a NOTIFY request, 413 including any logic required to form a coherent resource state. 415 In this specification, each NOTIFY request contains either no PoC- 416 settings document, or a document representing one or more PoC related 417 settings for a given user. Within a dialog, the PoC-settings 418 document in the NOTIFY request with the highest CSeq header field 419 value is the current one. When no document is present in that 420 NOTIFY, the PoC-settings document present in the NOTIFY with the next 421 highest CSeq value is used. 423 5.9. Handling of Forked Requests 425 RFC 3265 [5] requires each package to describe handling of forked 426 SUBSCRIBE requests. 428 This specification only allows a single dialog to be constructed as a 429 result of emitting an initial SUBSCRIBE request. This guarantees 430 that only a single subscriber is generating notifications for a 431 particular subscription to a particular user. The result of this is 432 that a user can have multiple SIP User Agents active, but these 433 should be homogeneous, so that each can generate the same set of 434 notifications for the user's poc-settings. 436 5.10. Rate of Notifications 438 RFC 3265 [5] requires each package to specify the maximum rate at 439 which notifications can be sent. 441 Poc-settings notifiers SHOULD NOT generate notifications for a single 442 user at a rate of more than once every five seconds. 444 5.11. State Agents 446 RFC 3265 [5] requires each package to consider the role of state 447 agents in the package, and if they are used, to specify how 448 authentication and authorization are done. 450 This specification allows state agents to be located in the network. 451 Publication of PoC-settings document is linked to a user. However, a 452 user may be simultaneously logged in different PoC terminals. If a 453 user changes her PoC settings from a terminal, it will send a PUBLISH 454 request containing a PoC-settings document. These settings are 455 applicable to the user independently of the terminal she is logged 456 in. In other words, PoC settings changes done in a terminal affect 457 all the PoC terminals where the user is logged. It is RECOMMENDED 458 that each of the terminals the user is logged in subscribes to its 459 own PoC-settings document in order to keep a coherent state view with 460 the state agent. 462 5.12. Examples 464 An example of a PoC-setting document is provided in Section 6.2. 466 5.13. Use of URIs to Retrieve State 468 RFC 3265 [5] allows packages to use URIs to retrieve large state 469 documents. 471 PoC-settings documents are fairly small. This event package does not 472 provide a mechanism to use URIs to retrieve large state documents. 474 5.14. PUBLISH bodies 476 RFC 3903 [8] requires event packages to define the content types 477 expected in PUBLISH requests. 479 In this event package, the body of a PUBLISH request contains a PoC- 480 settings document (see Section 6). This PoC-settings document 481 describes the PoC related settings of a user at an EPA. EPAs SHOULD 482 include information of its own EPA in a PoC-settings document, i.e., 483 there SHOULD be a single element in the body of the PUBLISH 484 request (See Section 6.1 for a detailed description of the 485 element). 487 All EPAs and ESCs MUST support the "application/poc-settings+xml" 488 data format described in Section 6 and MAY support other formats. 490 5.15. PUBLISH Response Bodies 492 This specification does not associate semantics to a body in a 493 PUBLISH response. 495 5.16. Multiple Sources for Event State 497 RFC 3903 [8] requires event packages to specify whether multiple 498 sources can contribute to the event state view at the ESC. 500 This event package allows different EPAs to publish the PoC settings 501 for a particular user. Each EPA publishes its own settings grouped 502 in an element. The EPA provides a globally unique 503 identifier for a given address of record, that allows the ESC to 504 differentiate EPAs and either compose a state resolving conflicts or 505 provide the union of the states of all the EPAs that contributed to 506 it. The composition policy at the ESC is outside the scope of this 507 document. 509 5.17. Event State Segmentation 511 RFC 3903 [8] defines segments within a state document. Each segment 512 is defined as one of potentially many identifiable sections in the 513 published event state. 515 This event package defines, for a given EPA, four segments identified 516 by the elements , , , and 517 , respectively. Each of them refer to different states 518 of the EPA. 520 5.18. Rate of Publication 522 RFC 3903 [8] allows event packages to define their own rate of 523 publication. 525 There are no rate limiting recommendations for poc-settings 526 publication. Since changes in a PoC-settings document are typically 527 triggered by the interaction of a human user, there is not 528 periodicity nor minimum or maximum rate of publication. 530 6. PoC-Settings Document 532 PoC-settings is an XML document [10] that MUST be well-formed and 533 SHOULD be valid. PoC-settings documents MUST be based on XML 1.0 and 534 MUST be encoded using UTF-8 [7]. This specification makes use of XML 535 namespaces for identifying PoC-settings documents. The namespace URI 536 for elements defined by this specification is a URN [2], using the 537 namespace identifier 'oma'. This URN is: 539 urn:oma:params:xml:ns:poc:poc-settings 541 PoC-settings documents are identified with the MIME type 542 "application/poc-settings+xml" and are instances of the XML schema 543 defined in Section 6.1. 545 A PoC-settings document begins with the root element tag . It consists or zero or more elements, each one 547 including an 'id' attribute that contains a globally unique 548 identifier for a given address of record that represents an EPA. An 549 element represents an EPA and it is uniquely identify by the 550 'id' attribute. EPAs SHOULD include a single element in a 551 PoC-settings document. ESCs MAY include several elements in 552 a PoC-settings document, typically when the ESC is unable to resolve 553 conflicts due to incongruent publication from different sources. 555 A valid PoC-settings document can include zero elements 556 if the ESC provides a notification for which no publication has 557 occurred. 559 The element MAY contain other elements and attributes from 560 different namespaces for the purposes of extensibility; elements or 561 attributes from unknown namespaces MUST be ignored. 563 The element consists of zero or one elements, 564 zero or one elements, zero or one , and 565 zero or one elements. Other elements and attributes 566 from different namespaces MAY be present for the purposes of 567 extensibility; elements or attributes from unknown namespaces MUST be 568 ignored. 570 An element contains a single element that contains a boolean 'active' attribute. The 572 'active' attribute indicates whether incoming sessions are barred or 573 not at the UA, depending on the user's preferences for this setting. 574 Other elements and attributes from different namespaces MAY be 575 present for the purposes of extensibility; elements or attributes 576 from unknown namespaces MUST be ignored. 578 An element contains an element, whose 579 value can be set to either "automatic" or "manual". Other elements 580 and attributes from different namespaces MAY be present for the 581 purposes of extensibility; elements or attributes from unknown 582 namespaces MUST be ignored. 584 A server such as a URI-list server [11] receives a SIP request 585 addressed to one or more recipients. If the intended recipient set 586 the to "manual", the URI-list server proceeds with the 587 session attempt. If she set it to "automatic", the URI-list server 588 generates a 200-class response prior to contacting the intended 589 recipient. 591 An element contains a single element that contains a boolean 'active' attribute. 593 The 'active' attribute indicates whether incoming personal alert 594 messages are barred or not at the UA, depending on the user's 595 preferences for this setting. Other elements from different 596 namespaces MAY be present for the purposes of extensibility; elements 597 or attributes from unknown namespaces MUST be ignored. 599 An element contains a single element that contains a boolean 'active' attribute. The 601 'active' attribute indicates whether the SIP UA is willing to handle 602 more than one PoC session simultaneously. If the 'active' attribute 603 is set to "false" or "0", then when the SIP UA is engaged in a PoC 604 session, and the SIP UA receives an second incoming request for a SIP 605 PoC session, the UA will decline the invitation. If the 'active' 606 attribute is set to "true" or "1", then when the SIP UA is engaged in 607 a PoC session, and the SIP UA receives an second incoming request for 608 a SIP PoC session, the UA will possibly accept the invitation. Other 609 elements and attributes from different namespaces MAY be present for 610 the purposes of extensibility; elements or attributes from unknown 611 namespaces MUST be ignored. 613 6.1. XML Schema 615 Implementations according to this specification MUST comply to the 616 following XML Schema that defines the constraints of the PoC-settings 617 document: 619 620 626 628 629 630 XML Schema Definition in support of the Incoming Session 631 Barring, Answer Mode, Incoming Personal Alert Barring, 632 and Simultaneous Sessions Support in the Push-to-talk 633 over Cellular (PoC) service. 634 635 637 639 640 641 643 645 646 647 649 650 651 653 655 657 659 662 663 664 665 667 668 669 670 671 673 674 675 677 678 679 681 682 683 684 685 686 687 688 689 690 691 693 694 695 697 698 699 700 701 703 704 705 707 708 709 710 711 712 713 714 716 717 718 720 721 722 724 726 6.2. Example 728 The following is an example of a PoC-settings document: 730 732 733 734 735 736 737 738 automatic 739 740 741 742 743 744 745 746 747 749 7. Security Considerations 751 The "poc-settings" event package defined by this document is meant to 752 be transported with SIP PUBLISH requests. Therefore, the Security 753 Considerations (Section 14) in the RFC 3903 [8] apply to this 754 document. In particular, the settings contained in the "poc- 755 settings" event package are applicable to the user that generated the 756 SIP PUBLISH request. Therefore, servers that receive SIP PUBLISH 757 requests containing a "poc-settings" event package SHOULD 758 authenticate the user prior to authorizing the event publication (as 759 required by the RFC 3903 [8]). 761 Authentication and authorization of subscriptions have been discussed 762 in Section 5.6. Lack of authentication or authorization may provide 763 poc-settings information to unauthorized parties, who can use that 764 information for creating attacks. For example, an unauthorized 765 recipient of a PoC-settings document can learn that the publisher's 766 terminal is set to answer PoC sessions in automatic answer mode and 767 then create a malicious session containing inappropriate media that 768 the UAS will play automatically. Or the attacker can learn that the 769 terminal is willing to receive simultaneous PoC sessions, and then he 770 can try to exhaust resources in the SIP UA by creating bogus PoC 771 sessions that leave hung states in the attacked SIP UA. 773 Integrity protection and confidentiality of notifications are also 774 discussed in Section 5.7. If a notifier does not encrypt bodies of 775 NOTIFY requests, an eavesdropper could learn the status of a SIP user 776 agent and use it to create malicious PoC sessions. If the notifier 777 does not integrity protect the bodies of NOTIFY requests, a man-in- 778 the-middle or malicious SIP proxy could modify the contents of the 779 poc-settings event package notification. Although this does not 780 create a harm, it can create annoyances (e.g., media clip due to lack 781 of buffering) when PoC sessions are delivered to the user. 783 8. Acknowledgements 785 The author wants to thank Ilkka Westman, Andrew Allen, Chinmay 786 Padhye, Gonzalo Camarillo, Paul Kyzivat, Haris Zisimopoulos, Joel M. 787 Halpern, and Russ Housley for their comments. 789 9. IANA Considerations 791 9.1. Registration of the "poc-settings" Event Package 793 This specification registers an event package, based on the 794 registration procedures defined in RFC 3265 [5]. The following is 795 the information required for such a registration: 797 Package Name: poc-settings 798 Package or Template-Package: This is a package. 800 Published Document: RFC XXX [Replace by the RFC number of this 801 specification]. 803 Person to Contact: Miguel A. Garcia-Martin, 804 miguel.an.garcia@nokia.com 806 9.2. Registration of the "application/poc-settings+xml" MIME type 808 To: ietf-types@iana.org 810 Subject: Registration of MIME media type application/ 811 poc-settings+xml 813 MIME media type name: application 815 MIME subtype name: poc-settings+xml 817 Required parameters: (none) 819 Optional parameters: charset; Indicates the character encoding of 820 enclosed XML. Default is UTF-8 [7]. 822 Encoding considerations: Uses XML, which can employ 8-bit 823 characters, depending on the character encoding used. See RFC 824 3023 [3], Section 3.2. 826 Security considerations: This content type is designed to carry 827 information about current PoC user settings, which in some cases 828 may be considered private information. Appropriate precautions 829 should be adopted to limit disclosure of this information. 831 Interoperability considerations: This content type provides a 832 common format for exchange of PoC settings information. 834 Published specification: RFC XXXX (this document). 836 Applications which use this media type: Push-to-talk over Cellular 837 systems in compliance with the Open Mobile Alliance (OMA) PoC 838 specifications. 840 Additional information: The Open Mobile Alliance publishes the 841 Push-to-talk over Cellular specifications in the OMA web site at 842 http://www.openmobilealliance.org 843 Person & email address to contact for further information: Miguel 844 A. Garcia-Martin, miguel.an.garcia@nokia.com 846 Intended usage: Limited use, restricted to PoC terminals and 847 servers. 849 Author/Change controller: Open Mobile Alliance 850 (http://www.openmobilealliance.org), PoC working group. 852 Other information: This media type is a specialization of 853 application/xml RFC 3023 [3], and many of the considerations 854 described there also apply to application/poc-settings+xml. 856 10. References 858 10.1. Normative References 860 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 861 Levels", BCP 14, RFC 2119, March 1997. 863 [2] Moats, R., "URN Syntax", RFC 2141, May 1997. 865 [3] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 866 RFC 3023, January 2001. 868 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 869 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 870 Session Initiation Protocol", RFC 3261, June 2002. 872 [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 873 Notification", RFC 3265, June 2002. 875 [6] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. 876 Rosen, "Change Process for the Session Initiation Protocol 877 (SIP)", BCP 67, RFC 3427, December 2002. 879 [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 880 STD 63, RFC 3629, November 2003. 882 [8] Niemi, A., "Session Initiation Protocol (SIP) Extension for 883 Event State Publication", RFC 3903, October 2004. 885 [9] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 886 (S/MIME) Version 3.1 Message Specification", RFC 3851, 887 July 2004. 889 [10] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, 890 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 891 FirstEdition REC-xml-20001006, October 2000. 893 10.2. Informational References 895 [11] Camarillo, G. and A. Roach, "Requirements and Framework for 896 Session Initiation Protocol (SIP)Uniform Resource Identifier 897 (URI)-List Services", draft-ietf-sipping-uri-services-03 (work 898 in progress), April 2005. 900 [12] Rosenberg, J., "A Framework for Conferencing with the Session 901 Initiation Protocol", 902 draft-ietf-sipping-conferencing-framework-05 (work in 903 progress), May 2005. 905 Author's Address 907 Miguel A. Garcia-Martin 908 Nokia 909 P.O.Box 407 910 NOKIA GROUP, FIN 00045 911 Finland 913 Email: miguel.an.garcia@nokia.com 915 Intellectual Property Statement 917 The IETF takes no position regarding the validity or scope of any 918 Intellectual Property Rights or other rights that might be claimed to 919 pertain to the implementation or use of the technology described in 920 this document or the extent to which any license under such rights 921 might or might not be available; nor does it represent that it has 922 made any independent effort to identify any such rights. Information 923 on the procedures with respect to rights in RFC documents can be 924 found in BCP 78 and BCP 79. 926 Copies of IPR disclosures made to the IETF Secretariat and any 927 assurances of licenses to be made available, or the result of an 928 attempt made to obtain a general license or permission for the use of 929 such proprietary rights by implementers or users of this 930 specification can be obtained from the IETF on-line IPR repository at 931 http://www.ietf.org/ipr. 933 The IETF invites any interested party to bring to its attention any 934 copyrights, patents or patent applications, or other proprietary 935 rights that may cover technology that may be required to implement 936 this standard. Please address the information to the IETF at 937 ietf-ipr@ietf.org. 939 Disclaimer of Validity 941 This document and the information contained herein are provided on an 942 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 943 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 944 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 945 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 946 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 947 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 949 Copyright Statement 951 Copyright (C) The Internet Society (2005). This document is subject 952 to the rights, licenses and restrictions contained in BCP 78, and 953 except as set forth therein, the authors retain all their rights. 955 Acknowledgment 957 Funding for the RFC Editor function is currently provided by the 958 Internet Society.