SIPPING Working Group M. Garcia-Martin Internet-Draft Nokia Expires: April 18, 2005 October 18, 2004 A Session Initiation Protocol (SIP) Event Package and Data Format for Incoming Session Barring and Answer Mode in support for the Push-to-talk Over Cellular (PoC) service draft-garcia-sipping-poc-isb-am-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 18, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract The Open Mobile Alliance (OMA) is defining the Push-to-talk Over Cellular (PoC) service where SIP is the protocol used to establish half duplex media sessions across different participants, send instant messages, etc. This document defines a SIP event package to support publication, subscription and notification of additional capabilities required by the PoC service. This SIP event package is Garcia-Martin Expires April 18, 2005 [Page 1]
Internet-Draft PoC ISB AM October 2004 applicable to the PoC service and may not be applicable to the general Internet. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 4. Overview of operation . . . . . . . . . . . . . . . . . . . . 4 5. The "poc-settings" Event Package . . . . . . . . . . . . . . . 5 5.1 Package Name . . . . . . . . . . . . . . . . . . . . . . . 5 5.2 Event Package Parameters . . . . . . . . . . . . . . . . . 5 5.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 5 5.4 Subscription duration . . . . . . . . . . . . . . . . . . 5 5.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 6 5.6 Notifier processing of SUBSCRIBE requests . . . . . . . . 6 5.6.1 Authentication . . . . . . . . . . . . . . . . . . . . 6 5.6.2 Authorization . . . . . . . . . . . . . . . . . . . . 6 5.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . 6 5.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . 7 5.9 Handling of Forked Requests . . . . . . . . . . . . . . . 8 5.10 Rate of Notifications . . . . . . . . . . . . . . . . . . 8 5.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . 8 5.12 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.13 Use of URIs to Retrieve State . . . . . . . . . . . . . . 9 5.14 PUBLISH bodies . . . . . . . . . . . . . . . . . . . . . . 9 5.15 PUBLISH Response Bodies . . . . . . . . . . . . . . . . . 9 5.16 Multiple Sources for Event State . . . . . . . . . . . . . 9 5.17 Event State Segmentation . . . . . . . . . . . . . . . . . 9 5.18 Rate of Publication . . . . . . . . . . . . . . . . . . . 10 6. PoC Settings Document . . . . . . . . . . . . . . . . . . . . 10 6.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9.1 Registration of the "poc-settings" Event Package . . . . . 15 9.2 Registration of the "application/poc-settings+xml" MIME type . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 10.2 Informational References . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Garcia-Martin Expires April 18, 2005 [Page 2]
Internet-Draft PoC ISB AM October 2004 1. Introduction The Open Mobile Alliance (OMA) (http://www.openmobilealliance.org) is currently specifying the Push-to-talk over Cellular (PoC) service. This service allows a SIP UA (PoC terminal) to establish a session to one or more SIP UAs simultaneously, usually initiated by the initiating user pushing a button. OMA has defined a collection of very stringent requirements in support of the PoC service. In oder to provide the user with a satisfactory experience the initial session establishment from the time the user presses the button to the time they get an indication to speak must be minimized. The PoC terminal may support such hardware capabilities as a speaker phone and/or headset and software that provide the capability for the user to configure the PoC terminal to accept the session initiations immediately and play out the media as soon as it is received without requiring the intervention of the called user. This is mode of operation is known as Auto-Answer mode. The user may alternatively configure the PoC terminal to first alert the user and require the user to manually accept the session invitation before media is accepted. This is mode of operation is known as Manual-Answer mode. The PoC terminal may support both or only one of these modes of operation. The user may change the Answer Mode (AM) configuration of the PoC terminal frequently based on their current circumstances and preference,(perhaps because the user is busy, or in a public area where she cannot use a speaker phone, etc). The SIP PoC terminal may support various SIP based communication services in addition to Push-to-talk (e.g VoIP telephony, Presence, messaging etc). The user may at times wish to disable the acceptance of Push-to-talk sessions whilst still remaining SIP registered for one or more other SIP based services. When the PoC terminal is configured to not accept any incoming Push-to-talk sessions this is known as Incoming Session Barring (ISB). The OMA PoC Architecture utilizes SIP servers within the network that may perform such roles as a conference focus [12], a RTP translator or a policy server. A possible optimization to minimize the delay in the providing of the caller with an indication to speak is for the SIP network server to perform buffering of media packets in order to provide an early or unconfirmed indication back to the caller and allow the caller to start speaking before the called PoC terminal has answered. This optimization only is appropriate when the called PoC terminal is currently accepting Push-to-Talk session and its Answer Mode is set to automatic. This optimization therefore requires the network SIP server to have knowledge of the current ISB and AM Garcia-Martin Expires April 18, 2005 [Page 3]
Internet-Draft PoC ISB AM October 2004 settings of the called PoC terminal. This document proposes additional SIP capabilities to enable the communication of the ISB and Answer Mode settings between the SIP PoC terminal and the SIP network server. We define a SIP event package that allows a SIP Event Publication Agent (EPA) to publish the user's settings which may impact some specific session attempts. This allows subscribers to subscribe to the Event State Compositor to this event package to gather this information, and anticipate to the user's needs when a session is attempted to that user. It is believed that the SIP event package defined here is not applicable to the general Internet: it has been designed to server the architecture of the PoC service. In particular, and in the context defined by the SIP PUBLISH extension [8], it is the intention of OMA to make PoC terminals behave as Event Publication Agents (EPA), and network servers behave as Event State Compositors (ESC). It is possible that PoC terminals and network servers may also subscribe to the user's PoC related settings, so that changes in this state made in one terminal are kept in synchronization across all different terminals or with the network server for a particular user. This document defines the format of a SIP event package that is able to convey the ISB and AM settings from a SIP UA to another SIP UA that either acts as an ESC and receives the event package in PUBLISH requests [8] from the SIP UA acting as an EPA, or subscribes to this event package according to RFC 3265 [5]. The aim of this document is to follow the procedure indicated in RFC 3427 [6] and to register this new event package with IANA. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. 3. Applicability Statement The event package defined in this document is intended for use with network based application servers that provide a Push-to-talk service. 4. Overview of operation Garcia-Martin Expires April 18, 2005 [Page 4]
Internet-Draft PoC ISB AM October 2004 5. The "poc-settings" Event Package RFC 3265 [5] defines a SIP extension for subscribing to, and receiving notifications of, events. It leaves the definition of many aspects of these events to concrete extensions, known as event packages. This document qualifies as an event package. This section fills in the information required for all event packages by RFC 3265 [5]. According to the SIP PUBLISH specification [8] any event package intended to be used in conjunction with the SIP PUBLISH method has to include a considerations section. This section also fills the information for all event packages to be used with PUBLISH requests. We define a new "poc-settings" event package. Event Publication Agents (EPA) use PUBLISH requests to inform a Event State Compositor (ESC) of changes in the poc-settings event package. The ESC, acting as a notifier, notifies subscribers to the user's poc-settings information when changes occur. 5.1 Package Name The name of this package is "poc-settings". As specified in RFC 3265 [5], this value appears in the Event header field present in SUBSCRIBE and NOTIFY requests. As specified in the PUBLISH specification [8], this value appears as well in the Event header field present in PUBLISH requests. 5.2 Event Package Parameters RFC 3265 [5] allows event packages to define additional parameters carried in the Event header field. This package, presence, does not define any additional parameters. 5.3 SUBSCRIBE Bodies According to RFC 3265 [5], a SUBSCRIBE request can contain a body. The purpose of the body depends on its type. Subscriptions to the poc-settings event package will normally not contain bodies. The Request-URI of the SUBSCRIBE request identifies the user to which the subscriber wants to be informed of the poc-settings. 5.4 Subscription duration The default expiration time for subscriptions within this package is 3600 seconds. As per RFC 3265 [5], the subscriber MAY specify an alternate expiration in the Expires header field. Garcia-Martin Expires April 18, 2005 [Page 5]
Internet-Draft PoC ISB AM October 2004 5.5 NOTIFY Bodies As described in RFC 3265 [5], the NOTIFY message will contain bodies that describe the state of the subscribed resource. This body is in a format listed in the Accept header field of the SUBSCRIBE request, or a package-specific default if the Accept header field was omitted from the SUBSCRIBE request. In this event package, the body of the notification contains a poc-settings document (see Section 6). This poc-settings document describes the PoC related settings at the EPA. All subscribers, and notifier MUST support the "application/poc-settings+xml" data format described in Section 6. The SUBSCRIBE request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/poc-settings+xml" (assuming that the Event header field contains a value of "poc-settings"). If the Accept header field is present, it MUST include "application/poc-settings+xml", and MAY include any other types capable of representing user settings for PoC. 5.6 Notifier processing of SUBSCRIBE requests 5.6.1 Authentication The contents of a poc-settings document can contain sensitive information, for instance, it may contain a pointer to a list of users for which the user will be giving an automatic session attempt treatment. Therefore, a notifier MUST authenticate all subscription requests. This authentication can be done using any of the mechanisms defined in RFC 3261 [4] and other authentication extensions. 5.6.2 Authorization Once authenticated, the notifier makes an authorization decision. A notifier MUST NOT accept a subscription unless authorization has been provided by the user The means by which authorization are provided are outside the scope of this document. Authorization may have been provided ahead of time through access lists, perhaps specified in a web page. Authorization may have been provided by means of uploading of some kind of standardized access control list document. 5.7 Notifier Generation of NOTIFY Requests RFC 3265 [5] details the formatting and structure of NOTIFY messages. However, packages are mandated to provide detailed information on when to send a NOTIFY, how to compute the state of the resource, how to generate neutral or fake state information, and whether state Garcia-Martin Expires April 18, 2005 [Page 6]
Internet-Draft PoC ISB AM October 2004 information is complete or partial. This section describes those details for the poc-settings event package. A notifier MAY send a NOTIFY at any time. Typically, it will send one when the poc-settings stage of a user changes. The NOTIFY request MAY contain a body containing a poc-settings document. The times at which the NOTIFY is sent for a particular subscriber, and the contents of the body within that notification, are subject to any rules specified by the authorization policy that governs the subscription, but typically will contain an indication of those PoC related services for which a change has occurred. In the case of a pending subscription, when final authorization is determined, a NOTIFY can be sent. If the result of the authorization decision was success, a NOTIFY SHOULD be sent and SHOULD contain a complete poc-settings document with the current state of the user's PoC settings. If the subscription is rejected, a NOTIFY MAY be sent. As described in RFC 3265 [5], the Subscription-State header field indicates the state of the subscription. The body of the NOTIFY MUST be sent using one of the types listed in the Accept header field in the most recent SUBSCRIBE request, or using the type "application/poc-settings+xml" if no Accept header field was present. Notifiers will typically act as Event State Compositors (ESC) and thus, will learn the poc-settings event state via PUBLISH requests sent from the user's Event Publication Agent (EPA) when the user changes one of those settings. For reasons of privacy, it will frequently be necessary to encrypt the contents of the notifications. This can be accomplished using S/MIME. The encryption can be performed using the key of the subscriber as identified in the From field of the SUBSCRIBE request. Similarly, integrity of the notifications is important to subscribers. As such, the contents of the notifications MAY provide authentication and message integrity using S/MIME. Since the NOTIFY is generated by the notifier, which may not have access to the key of the user represented by the poc-settings user, it will frequently be the case that the NOTIFY is signed by a third party. It is RECOMMENDED that the signature be by an authority over the domain of the user. In other words, for a user sip:user@example.com, the signator of the NOTIFY SHOULD be the authority for example.com. 5.8 Subscriber Processing of NOTIFY Requests RFC 3265 [5] leaves it to event packages to describe the process followed by the subscriber upon receipt of a NOTIFY request, Garcia-Martin Expires April 18, 2005 [Page 7]
Internet-Draft PoC ISB AM October 2004 including any logic required to form a coherent resource state. In this specification, each NOTIFY request contains either no poc-settings document, or a document representing one or more PoC related settings. Within a dialog, the poc-settings document in the NOTIFY request with the highest CSeq header field value is the current one. When no document is present in that NOTIFY, the poc-settings document present in the NOTIFY with the next highest CSeq value is used. 5.9 Handling of Forked Requests RFC 3265 [5] requires each package to describe handling of forked SUBSCRIBE requests. This specification only allows a single dialog to be constructed as a result of emitting an initial SUBSCRIBE request. This guarantees that only a single subscriber is generating notifications for a particular subscription to a particular user. The result of this is that a user can have multiple SIP User Agents active, but these should be homogeneous, so that each can generate the same set of notifications for the user's poc-settings. 5.10 Rate of Notifications RFC 3265 [5] requires each package to specify the maximum rate at which notifications can be sent. Poc-settings notifiers SHOULD NOT generate notifications for a single user at a rate of more than once every five seconds. 5.11 State Agents RFC 3265 [5] requires each package to consider the role of state agents in the package, and if they are used, to specify how authentication and authorization are done. This specification allows state agents to be located in the network. Publication of poc-settings document is linked to a user. However, a user may be simultaneously logged in different PoC terminals. If a user changes her PoC settings from a terminal, it will send a PUBLISH request containing a poc-settings document. These settings are applicable to the user independently of the terminal she is logged in. In other words, PoC settings changes done in a terminal affect all the PoC terminals where the user is logged. It is RECOMMENDED that each of the terminals the user is logged in subscribes to its own poc-settings document in order to keep a coherent state view with the state agent. Garcia-Martin Expires April 18, 2005 [Page 8]
Internet-Draft PoC ISB AM October 2004 5.12 Examples An example of a poc-setting document is provided in Section 6.2. 5.13 Use of URIs to Retrieve State RFC 3265 [5] allows packages to use URIs to retrieve large state documents. Poc-settings documents are fairly small. This event package does not provide a mechanism to use URIs to retrieve large state documents. 5.14 PUBLISH bodies The PUBLISH specification [8] requires event packages to define the content types expected in PUBLISH requests. In this event package, the body of a PUBLISH request contains a poc-settings document (see Section 6). This poc-settings document describes the PoC related settings at the EPA. All EPAs and ESCs MUST support the "application/poc-settings+xml" data format described in Section 6 and MAY support other formats. 5.15 PUBLISH Response Bodies This specification does not associate semantics to a body in a PUBLISH response. 5.16 Multiple Sources for Event State The PUBLISH specification [8] requires event packages to specify whether multiple sources can contribute to the event state view at the ESC. This event package allows different EPAs to publish the PoC settings for a particular user. For a particular user, the ESC will consider the last received PoC settings document segment as the valid updated event state. 5.17 Event State Segmentation The PUBLISH specification [8] defines segments within a state document. Each segment is defined as one of potentially many identifiable sections in the published event state. This event package defines two segments identified by the elements <isb-settings> and <am-settings>, respectively. Each of them refer to different states of the SIP UA. Garcia-Martin Expires April 18, 2005 [Page 9]
Internet-Draft PoC ISB AM October 2004 5.18 Rate of Publication The PUBLISH specification [8] allows event packages to define their own rate of publication. There are no rate limiting recommendations for poc-settings publication. Since changes in a poc-settings document are typically triggered by the interaction of a human user, there is not periodicity nor minimum or maximum rate of publication. 6. PoC Settings Document PoC settings is an XML document [9] that MUST be well-formed and SHOULD be valid. PoC settings documents MUST be based on XML 1.0 and MUST be encoded using UTF-8 [7]. This specification makes use of XML namespaces for identifying PoC settings documents. The namespace URI for elements defined by this specification is a URN [2], using the namespace identifier 'oma'. This URN is: urn:oma:params:xml:ns:poc:isb-am A PoC settings document begins with the root element tag <poc-settings>. It consists of zero or more <isb-settings> elements and zero or more <am-settings> elements. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. An <isb-settings> element contains a single <incoming-session-barring> element, whose value can be set to either "on" or "off", indicating the user's preferences for this setting. The settings can indicate one more or URIs and one or more media type for which this setting applies. An <isb-settings> element also contains zero or more <applied-to> elements, each of them points to a URI that stores a SIP URI-list. This element restricts the applicability of the setting to sessions originated by one or more users. This allows the Event Publication Agent to selectively set different ISB settings for sessions initiated by different users. The ISB settings of the parent <isb-settings> are applicable to each of the URIs included in the list indicated in <applied-to> elements. Session originated by any of these URIs will be subject to these ISB settings. The absence of an <applied-to> element indicates that the settings are applicable to any URI. When more than one <applied-to> element is present, all of them are considered as OR logical operations. An <isb-settings> element also contains zero or more <media> Garcia-Martin Expires April 18, 2005 [Page 10]
Internet-Draft PoC ISB AM October 2004 elements. A <media> element restricts the media for which the setting is applicable. This allows the user to selectively set different ISB settings depending on the type of media offered in the session. The absence of an <media> element indicates that the setting is applicable to any URI. When more than one <media> element is present, all of them are considered as OR logical operations. The media type values are the same as defined in the "m" line in SDP [10]. A value of "any" indicates that the setting is applicable to any media type. The rest of the values are those registered with IANA for the media type in SDP. When one or more <applied-to> elements are present together with one or more <media> elements in the same setting, the restriction is considered an AND logical operation. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. An <am-settings> element contains an <answer-mode> element, whose value can be set to either "automatic" or "manual". The settings can indicate one more or URIs and one or more media type for which this setting applies. An <am-settings> element also contains zero or more <applied-to> elements, each of them points to a URI that stores a SIP URI-list. This element restricts the applicability of the setting to sessions originated by one or more users, as previously explained. An <am-settings> element also contains zero or more <media> elements. A <media> element restricts the media for which the setting is applicable, as previously explained. When one or more <applied-to> elements are present together with one or more <media> elements in the same setting, the restriction is considered an AND logical operation. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. When the session originator identity is one of the SIP URIs stored in the <applied-to> list and it includes one media type listed in the <media> element, the watcher of this setting can apply the intended recipient's answer mode settings. If the intended recipient set it to "manual", the URI-list server proceeds with the session attempt. If she set it to "automatic", the URI-list server generates a 200-class response prior to contacting the intended recipient. Other Garcia-Martin Expires April 18, 2005 [Page 11]
Internet-Draft PoC ISB AM October 2004 elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. PoC Settings documents are identified with the MIME type "application/poc-settings+xml" and are instances of the XML schema defined in Section 6.1. 6.1 XML Schema Implementations according to this specification MUST comply to the following XML Schema that defines the constraints of the PoC settings document: <?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:oma:params:xml:ns:poc:isb-am" xmlns="urn:oma:params:xml:ns:poc:isb-am" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/> <xs:annotation> <xs:documentation xml:lang="en"> XML Schema Definition in support of the Incoming Session Barring and Answer Mode in the Push-to-talk over Cellular (PoC) service. </xs:documentation> </xs:annotation> <xs:element name="poc-settings" type="poc-settingsType"/> <xs:complexType name="poc-settingsType"> <xs:sequence> <xs:element name="isb-settings" type="IsbSettingType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="am-settings" type="AmSettingType" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other"/> </xs:complexType> <xs:complexType name="IsbSettingType"> <xs:sequence> Garcia-Martin Expires April 18, 2005 [Page 12]
Internet-Draft PoC ISB AM October 2004 <xs:element name="incoming-session-barring"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="on"/> <xs:enumeration value="off"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="applied-to" type="applied-toType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="media " type="mediaType" minOccurs="0" maxOccurs="unbounded" /> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other"/> </xs:complexType> <xs:complexType name="AmSettingType"> <xs:sequence> <xs:element name="answer-mode"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="automatic"/> <xs:enumeration value="manual"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="applied-to" type="applied-toType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="media " type="mediaType" minOccurs="0" maxOccurs="unbounded" /> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other"/> </xs:complexType> <xs:simpleType name="applied-toType"> <xs:restriction base="xs:anyURI"/> </xs:simpleType> <xs:simpleType name="mediaType"> <xs:restriction base="xs:string"> <xs:enumeration value="any" /> <xs:enumeration value="audio"/> <xs:enumeration value="video"/> <xs:enumeration value="message"/> Garcia-Martin Expires April 18, 2005 [Page 13]
Internet-Draft PoC ISB AM October 2004 <xs:enumeration value="text"/> <xs:enumeration value="application"/> </xs:restriction> </xs:simpleType> </xs:schema> 6.2 Example The following is an example of a PoC settings document: <?xml version="1.0" encoding="UTF-8"?> <poc-settings xmlns="urn:oma:params:xml:ns:poc:isb-am" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oma:params:xml:ns:poc:isb-am"> <isb-settings> <incoming-session-barring>on</incoming-session-barring> <applied-to> http://xcap.example.com/rls-services/users/joe/friends.xml </applied-to> <media>audio</media> <media>video</media> </isb-settings> <am-settings> <answer-mode>automatic</answer-mode> <applied-to> http://xcap.example.com/rls-services/users/joe/buddies.xml </applied-to> <applied-to> http://xcap.example.com/rls-services/users/joe/family.xml </applied-to> </am-settings> </poc-settings> 7. Security Considerations The "poc-settings" event package defined by this document is meant to be transported with SIP PUBLISH requests. Therefore, the Security Considerations (Section 14) in the SIP PUBLISH specification [8] apply to this document. In particular, the settings contained in the "poc-settings" event package are applicable to the user that generated the SIP PUBLISH request. Therefore, URI-list servers that receive SIP PUBLISH requests containing a "poc-settings" event Garcia-Martin Expires April 18, 2005 [Page 14]
Internet-Draft PoC ISB AM October 2004 package SHOULD authenticate the user prior to authorizing the event publication (as required by the SIP PUBLISH specification [8]). 8. Acknowledgements The author wants to thank Ilkka Westman and Andrew Allen for the comments supplied for the initial version of this document. 9. IANA Considerations 9.1 Registration of the "poc-settings" Event Package This specification registers an event package, based on the registration procedures defined in RFC 3265 [5]. The following is the information required for such a registration: Package Name: poc-settings Package or Template-Package: This is a package. Published Document: RFC XXX [Replace by the RFC number of this specification]. Person to Contact: Miguel Garcia, miguel.an.garcia@nokia.com 9.2 Registration of the "application/poc-settings+xml" MIME type To: ietf-types@iana.org Subject: Registration of MIME media type application/poc-settings+xml MIME media type name: application MIME subtype name: poc-settings+xml Required parameters: (none) Optional parameters: charset; Indicates the character encoding of enclosed XML. Default is UTF-8 [7]. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [3], Section 3.2. Garcia-Martin Expires April 18, 2005 [Page 15]
Internet-Draft PoC ISB AM October 2004 Security considerations: This content type is designed to carry information about current PoC user settings, which in some cases may be considered private information. Appropriate precautions should be adopted to limit disclosure of this information. Interoperability considerations: This content type provides a common format for exchange of PoC settings information. Published specification: RFC XXXX (this document). Applications which use this media type: Push-to-talk over Cellular systems in compliance with the Open Mobile Alliance (OMA) PoC specifications. Additional information: The Open Mobile Alliance publishes the Push-to-talk over Cellular specifications in the OMA web site at http://www.openmobilealliance.org Person & email address to contact for further information: Miguel Garcia, miguel.an.garcia@nokia.com Intended usage: Limited use, restricted to PoC terminals and servers. Author/Change controller: Open Mobile Alliance (http://www.openmobilealliance.org), PoC working group. Other information: This media type is a specialization of application/xml RFC 3023 [3], and many of the considerations described there also apply to application/poc-settings+xml. 10. References 10.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Moats, R., "URN Syntax", RFC 2141, May 1997. [3] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Garcia-Martin Expires April 18, 2005 [Page 16]
Internet-Draft PoC ISB AM October 2004 Notification", RFC 3265, June 2002. [6] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002. [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [8] Niemi, A., "An Event State Publication Extension to the Session Initiation Protocol (SIP)", draft-ietf-sip-publish-04 (work in progress), May 2004. [9] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C FirstEdition REC-xml-20001006, October 2000. [10] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", draft-ietf-mmusic-sdp-new-20 (work in progress), September 2004. 10.2 Informational References [11] Camarillo, G., "Requirements and Framework for Session Initiation Protocol (SIP)Uniform Resource Identifier (URI)-List Services", draft-ietf-sipping-uri-services-00 (work in progress), July 2004. [12] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-02 (work in progress), June 2004. [13] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", July 2003. Author's Address Miguel A. Garcia-Martin Nokia P.O.Box 407 NOKIA GROUP, FIN 00045 Finland EMail: miguel.an.garcia@nokia.com Garcia-Martin Expires April 18, 2005 [Page 17]
Internet-Draft PoC ISB AM October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Garcia-Martin Expires April 18, 2005 [Page 18]
