GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4354

Network Working Group M. Garcia-Martin Request for Comments: 4354 Nokia Category: Informational January 2006

 A Session Initiation Protocol (SIP) Event Package and Data Format
                  for Various Settings in Support
          for the Push-to-Talk over Cellular (PoC) Service

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2006).

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, to 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
 applicable to the PoC service and may not be applicable to the
 general Internet.

Garcia-Martin Informational [Page 1] RFC 4354 PoC Settings Event Package January 2006

Table of Contents

 1. Introduction ....................................................3
 2. Terminology .....................................................5
 3. Applicability Statement .........................................5
 4. Requirements ....................................................5
 5. The "poc-settings" Event Package ................................6
    5.1. Package Name ...............................................6
    5.2. Event Package Parameters ...................................7
    5.3. SUBSCRIBE Bodies ...........................................7
    5.4. Subscription Duration ......................................7
    5.5. NOTIFY Bodies ..............................................7
    5.6. Notifier Processing of SUBSCRIBE Requests ..................8
         5.6.1. Authentication ......................................8
         5.6.2. Authorization .......................................8
    5.7. Notifier Generation of NOTIFY Requests .....................8
    5.8. Subscriber Processing of NOTIFY Requests ...................9
    5.9. Handling of Forked Requests ...............................10
    5.10. Rate of Notifications ....................................10
    5.11. State Agents .............................................10
    5.12. Examples .................................................10
    5.13. Use of URIs to Retrieve State ............................10
    5.14. PUBLISH Bodies ...........................................11
    5.15. PUBLISH Response Bodies ..................................11
    5.16. Multiple Sources for Event State .........................11
    5.17. Event State Segmentation .................................11
    5.18. Rate of Publication ......................................12
 6. PoC-Settings Document ..........................................12
    6.1. XML Schema ................................................14
    6.2. Example ...................................................16
 7. Security Considerations ........................................17
 8. Acknowledgements ...............................................17
 9. IANA Considerations ............................................17
    9.1. Registration of the "poc-settings" Event Package ..........17
    9.2. Registration of the "application/poc-settings+xml"
         MIME type .................................................18
 10. References ....................................................19
    10.1. Normative References .....................................19
    10.2. Informative References ...................................20

Garcia-Martin Informational [Page 2] RFC 4354 PoC Settings Event Package January 2006

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 User Agent (PoC terminal) to establish a
 session to one or more SIP User Agents (UAs) simultaneously, usually
 initiated when the initiating user pushes a button.
 OMA has defined a collection of very stringent requirements in
 support of the PoC service.  In order 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 hardware capabilities such as a
 speakerphone and/or headset and software that provide the capability
 for the user to configure the PoC terminal to accept session
 initiations immediately and play out the media as soon as it is
 received without requiring the intervention of the called user.  This
 mode of operation is known as Auto-Answer mode or automatic mode.
 The user may alternatively configure the PoC terminal to first alert
 the user and require the user to accept the session invitation
 manually before media is accepted.  This 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.).
 SIP PoC terminals can support various SIP-based communication
 services in addition to Push-to-talk (e.g., VoIP telephony, presence
 services, messaging services, 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).
 A user may wish to contact another user who has a PoC terminal with
 Incoming Session Barring enabled.  A user may send an Instant
 Personal Alert to another user to inform him that he wishes to engage
 him in a PoC Session.  This Instant Personal Alert is received even
 when the destination PoC terminal has enabled Incoming Session
 Barring.  If a user wishes to disable the acceptance of Instant
 Personal Alerts, he can configure his PoC terminal not accept any
 incoming Instant Personal Alerts.  This is known as Instant Personal
 Alert Barring (IPAB).

Garcia-Martin Informational [Page 3] RFC 4354 PoC Settings Event Package January 2006

 Some PoC terminals may provide support for handling multiple PoC
 sessions simultaneously whereas other terminals are only able to
 handle one PoC session at time.  Or, even if the terminal is able to
 handle multiple PoC sessions simultaneously, the user may desire to
 have just one single PoC session at a time.  This indication of
 support for multiple PoC sessions simultaneously is known as
 Simultaneous PoC Sessions Support (SSS).
 The OMA PoC Architecture utilizes SIP servers within the network that
 may perform roles such as a conference focus [12], an RTP translator,
 or a policy server.  A possible optimization to minimize the delay in
 providing the caller with an indication to speak consist of the SIP
 network server to perform buffering of media packets in order to
 provide an early or unconfirmed indication 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 PoC sessions and its Answer Mode is
 set to Auto-Answer.  This optimization therefore requires the network
 SIP server to have knowledge of the current ISB and AM settings of
 the called PoC terminal.
 Similarly, in order to avoid unnecessary transmission of Instant
 Personal Alerts across the radio interface, the network SIP server
 needs to have knowledge of the current IPAB setting at the terminal.
 When the UA supports multiple PoC sessions simultaneously the server
 needs to act as a B2BUA in order to multiplex media and floor control
 signaling between multiple sessions using a single bandwidth limited
 radio bearer.  When handling of multiple PoC sessions simultaneously
 is not needed the server can act as a SIP proxy.  It is therefore
 advantageous for the server to be informed whether the UA currently
 intends to support multiple PoC sessions simultaneously.
 This document proposes additional SIP capabilities to enable the
 communication of the ISB, AM, IPAB, and SSS 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 at that particular EPA
 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 serve the architecture of the PoC
 service.  In particular, and in the context defined by RFC 3903 [8],
 it is the intention of OMA to make PoC terminals behave as Event
 Publication Agents (EPA), and network servers behave as Event State

Garcia-Martin Informational [Page 4] RFC 4354 PoC Settings Event Package January 2006

 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 a PoC-settings document that allows an EPA to
 convey its ISB, AM, IPAB, and SSS settings to an ESC.  The EPA sends
 a PoC-settings document in PUBLISH requests [8].  The PoC-settings
 document contain represents the settings view at that particular EPA.
 The ESC can collect PoC-settings document for the same user at
 different EPAs, apply a composition policy, and provide
 notifications.  Notifications can contain a composed view of the
 settings or a list of settings per EPA, depending on whether the ESC
 is able to resolve conflicts.  A subscriber can receive notifications
 of changes in this document according to the procedures specified in
 RFC 3265 [5].  The aim of this memo is to follow the procedure
 indicated in RFC 3427 [6] and to register a new poc-settings 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 over
 Cellular service.

4. Requirements

 A comprehensive description of all the requirements that affect the
 Push-to-Talk over Cellular service developed by the Open Mobile
 Alliance can be found in the Open Mobile Alliance web page at
 http://www.openmobilealliance.org.
 For the sake of simplicity, we briefly discuss here those
 requirements that affect the solution described in this document.
 These requirements can be summarized as follows:

Garcia-Martin Informational [Page 5] RFC 4354 PoC Settings Event Package January 2006

 1.  There must be a mechanism that reduces the session setup time as
     much as possible.
 2.  In order to allow proper usage of scarce resources, there must be
     a mechanism that saves the air interface from being congested
     with unneeded or undesired traffic.
 3.  The mechanism should not involve the implementation of new
     protocols, unless strictly needed.
 These requirements lead to a solution whereby the user can indicate
 to a network node his ability to accept or reject sessions or certain
 types of messages.  Pushing these settings to a network node allows
 the network node to produce a faster response to the originator,
 perhaps even declining or filtering some SIP requests towards the
 destination.  This approaches the goal of reducing the session setup
 time.

5. The "poc-settings" Event Package

 RFC 3265 [5] defines a SIP extension for subscribing to remote nodes
 and receiving notifications of changes (events) in their states.  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].
 Additionally, RFC 3903 [8] defines an extension that allows SIP User
 Agents to publish event state.  According to RFC 3903 [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 an Event State Compositor
 (ESC) of changes in the poc-settings event package.  Acting as a
 notifier, the ESC 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 RFC 3903 [8], this
 value also appears in the Event header field present in PUBLISH
 requests.

Garcia-Martin Informational [Page 6] RFC 4354 PoC Settings Event Package January 2006

5.2. Event Package Parameters

 RFC 3265 [5] allows event packages to define additional parameters
 carried in the Event header field.  This event package,
 "poc-settings", does not define 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 about
 whose poc-settings the subscriber wants to be informed.

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.

5.5. NOTIFY Bodies

 As described in RFC 3265 [5], the NOTIFY message will contain bodies
 describing 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 format 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).  The ESC has gathered PoC-
 settings documents for the user at different EPAs.  The ESC applies a
 composition policy and composes a PoC-settings document with a common
 view of all these settings across different EPAs.  In case the ESC is
 not able to resolve a conflict, due to contradictory information
 provided by two different EPAs, the ESC provides a PoC-settings
 document containing the settings at each terminal so that the
 subscriber can resolve the conflict.
 All subscribers and notifiers of the "poc-settings" event package
 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.

Garcia-Martin Informational [Page 7] RFC 4354 PoC Settings Event Package January 2006

5.6. Notifier Processing of SUBSCRIBE Requests

 The contents of a PoC-settings document can contain sensitive
 information that can reveal some privacy information.  Therefore,
 PoC-settings documents MUST only be sent to authorized subscribers.
 In order to determine if a subscription originates in an authorized
 user, the user MUST be authenticated as described in Section 5.6.1
 and then he MUST be authorized to be a subscriber as described in
 Section 5.6.2.

5.6.1. Authentication

 Notifiers 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
 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
 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.  However, typically the NOTIFY 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

Garcia-Martin Informational [Page 8] RFC 4354 PoC Settings Event Package January 2006

 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.  It is possible that the notifier
 generates a NOTIFY request for a user for which no publication has
 taken place.  In that case, the PoC-settings document will not
 contain any <entity> element (see Section 6.1 for a detailed
 description of the <entity> element).
 For reasons of privacy, it will frequently be necessary to encrypt
 the contents of the notifications.  This can be accomplished using
 S/MIME [9].  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 [9].  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, often the
 NOTIFY will be signed by a third party.  The NOTIFY request SHOULD be
 signed by an authority over the domain of the user.  In other words,
 for a user whose SIP URI is 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,
 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 for a given user.  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.

Garcia-Martin Informational [Page 9] RFC 4354 PoC Settings Event Package January 2006

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 at 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 at which 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 where the user is logged in
 subscribes to its own PoC-settings document in order to keep a
 coherent state view with the state agent.

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.

Garcia-Martin Informational [Page 10] RFC 4354 PoC Settings Event Package January 2006

 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

 RFC 3903 [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 of a user at an EPA.  EPAs SHOULD
 include their own information in a PoC-settings document; i.e., there
 SHOULD be a single <entity> element in the body of the PUBLISH
 request (See Section 6.1 for a detailed description of the <entity>
 element).
 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

 RFC 3903 [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.  Each EPA publishes its own settings grouped
 in an <entity> element.  The EPA provides a globally unique
 identifier for a given address of record.  This allows the ESC to
 differentiate EPAs and either compose a state resolving conflicts or
 provide the union of the states of all the EPAs that contributed to
 it.  The composition policy at the ESC is outside the scope of this
 document.

5.17. Event State Segmentation

 RFC 3903 [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, for a given EPA, four segments identified
 by the elements <isb-settings>, <am-settings>, <ipab-settings>, and
 <sss-settings>, respectively.  Each of them refers to different
 states of the EPA.

Garcia-Martin Informational [Page 11] RFC 4354 PoC Settings Event Package January 2006

5.18. Rate of Publication

 RFC 3903 [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 interaction with a human user, there is not periodicity,
 nor a minimum or maximum rate of publication.

6. PoC-Settings Document

 PoC-settings is an XML document [10] 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:poc-settings
 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.
 A PoC-settings document begins with the root element tag
 <poc-settings>.  It consists of zero or more <entity> elements, each
 one including an 'id' attribute that contains a globally unique
 identifier for a given address of record that represents an EPA.  An
 <entity> element represents an EPA, and it is uniquely identified by
 the 'id' attribute.  EPAs SHOULD include a single <entity> element in
 a PoC-settings document.  ESCs MAY include several <entity> elements
 in a PoC-settings document, typically when the ESC is unable to
 resolve conflicts due to incongruent publication from different
 sources.
    A valid PoC-settings document can include zero <entity> elements
    if the ESC provides a notification for which no publication has
    occurred.
 The <entity> element MAY contain other elements and attributes from
 different namespaces for the purposes of extensibility; elements or
 attributes from unknown namespaces MUST be ignored.
 The <entity> element consists of zero or one <isb-settings> elements,
 zero or one <am-settings> elements, zero or one <ipab-settings>, and
 zero or one <sss-settings> elements.  Other elements and attributes

Garcia-Martin Informational [Page 12] RFC 4354 PoC Settings Event Package January 2006

 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 that contains a boolean 'active' attribute.  The
 'active' attribute indicates whether incoming sessions are barred at
 the UA, depending on the user's preferences for this setting.  Other
 elements and attributes 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".  Other elements
 and attributes from different namespaces MAY be present for the
 purposes of extensibility; elements or attributes from unknown
 namespaces MUST be ignored.
 A server such as a URI-list server [11] receives a SIP request
 addressed to one or more recipients.  If the intended recipient set
 the <answer-mode> 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.
 An <ipab-settings> element contains a single <incoming-personal-
 alert-barring> element that contains a boolean 'active' attribute.
 The 'active' attribute indicates whether incoming personal alert
 messages are barred at the UA, depending on the user's preferences
 for this setting.  Other elements from different namespaces MAY be
 present for the purposes of extensibility; elements or attributes
 from unknown namespaces MUST be ignored.
 An <sss-settings> element contains a single <simultaneous-sessions-
 support> element that contains a boolean 'active' attribute.  The
 'active' attribute indicates whether the SIP UA is willing to handle
 more than one PoC session simultaneously.  If the 'active' attribute
 is set to "false" or "0", then when the SIP UA is engaged in a PoC
 session, and the SIP UA receives an second incoming request for a SIP
 PoC session, the UA will decline the invitation.  If the 'active'
 attribute is set to "true" or "1", then when the SIP UA is engaged in
 a PoC session, and the SIP UA receives an second incoming request for
 a SIP PoC session, the UA will possibly accept the invitation.  Other
 elements and attributes from different namespaces MAY be present for
 the purposes of extensibility; elements or attributes from unknown
 namespaces MUST be ignored.

Garcia-Martin Informational [Page 13] RFC 4354 PoC Settings Event Package January 2006

6.1. XML Schema

 Implementations according to this specification MUST comply to the
 following XML Schema, which defines the constraints of the PoC-
 settings document:
 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema targetNamespace="urn:oma:params:xml:ns:poc:poc-settings"
     xmlns="urn:oma:params:xml:ns:poc:poc-settings"
     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, Answer Mode, Incoming Personal Alert Barring,
       and Simultaneous Sessions Support 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="entity" type="entityType"
                   minOccurs="0" maxOccurs="unbounded" />
       <xs:any namespace="##other" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>
   <xs:complexType name="entityType">
     <xs:sequence>
       <xs:element name="isb-settings" type="isbSettingType"
                   minOccurs="0"/>
       <xs:element name="am-settings" type="amSettingType"
                   minOccurs="0"/>
       <xs:element name="ipab-settings" type="ipabSettingType"
                   minOccurs="0"/>
       <xs:element name="sss-settings" type="sssSettingType"
                   minOccurs="0"/>
       <xs:any namespace="##other" processContents="lax"
               minOccurs="0" maxOccurs="unbounded"/>

Garcia-Martin Informational [Page 14] RFC 4354 PoC Settings Event Package January 2006

     </xs:sequence>
     <xs:attribute name="id" type="xs:string" use="required"/>
     <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>
   <xs:complexType name="isbSettingType">
     <xs:sequence>
       <xs:element name="incoming-session-barring">
         <xs:complexType>
           <xs:attribute name="active" type="xs:boolean"
                         use="required" />
         </xs:complexType>
       </xs:element>
       <xs:any namespace="##any" processContents="lax"
               minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:anyAttribute namespace="##any" processContents="lax"/>
   </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:any namespace="##any" processContents="lax"
               minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>
   <xs:complexType name="ipabSettingType">
     <xs:sequence>
       <xs:element name="incoming-personal-alert-barring">
         <xs:complexType>
           <xs:attribute name="active" type="xs:boolean"
                         use="required" />
         </xs:complexType>
       </xs:element>
       <xs:any namespace="##any" processContents="lax"
               minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>

Garcia-Martin Informational [Page 15] RFC 4354 PoC Settings Event Package January 2006

   <xs:complexType name="sssSettingType">
     <xs:sequence>
       <xs:element name="simultaneous-sessions-support">
         <xs:complexType>
           <xs:attribute name="active" type="xs:boolean"
                         use="required"/>
         </xs:complexType>
       </xs:element>
      <xs:any namespace="##any" processContents="lax"
              minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>
 </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:poc-settings">
   <entity id="do39s8zksn2d98x">
      <isb-settings>
        <incoming-session-barring active="true"/>
      </isb-settings>
      <am-settings>
        <answer-mode>automatic</answer-mode>
      </am-settings>
      <ipab-settings>
        <incoming-personal-alert-barring active="false"/>
      </ipab-settings>
      <sss-settings>
        <simultaneous-sessions-support active="true"/>
      </sss-settings>
   </entity>
 </poc-settings>

Garcia-Martin Informational [Page 16] RFC 4354 PoC Settings Event Package January 2006

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 RFC 3903 [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, servers that receive SIP PUBLISH requests
 containing a "poc-settings" event package SHOULD authenticate the
 user prior to authorizing the event publication (as required by RFC
 3903 [8]).
 Authentication and authorization of subscriptions have been discussed
 in Section 5.6.  Lack of authentication or authorization may provide
 poc-settings information to unauthorized parties, who can use that
 information for creating attacks.  For example, an unauthorized
 recipient of a PoC-settings document can learn that the publisher's
 terminal is set to answer PoC sessions in automatic answer mode and
 then create a malicious session containing inappropriate media that
 the UAS will play automatically.  Or the attacker can learn that the
 terminal is willing to receive simultaneous PoC sessions and then try
 to exhaust resources in the SIP UA by creating bogus PoC sessions
 that leave hung states in the attacked SIP UA.
 Integrity protection and confidentiality of notifications are also
 discussed in Section 5.7.  If a notifier does not encrypt bodies of
 NOTIFY requests, an eavesdropper could learn the status of a SIP user
 agent and use it to create malicious PoC sessions.  If the notifier
 does not integrity protect the bodies of NOTIFY requests, a man-in-
 the-middle attacker or malicious SIP proxy could modify the contents
 of the poc-settings event package notification.  Although this does
 not cause harm, it can create annoyances (e.g., media clip due to
 lack of buffering) when PoC sessions are delivered to the user.

8. Acknowledgements

 The author wants to thank Ilkka Westman, Andrew Allen, Chinmay
 Padhye, Gonzalo Camarillo, Paul Kyzivat, Haris Zisimopoulos, Joel M.
 Halpern, and Russ Housley for their comments.

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:

Garcia-Martin Informational [Page 17] RFC 4354 PoC Settings Event Package January 2006

 Package Name: poc-settings
 Package or Template-Package: This is a package.
 Published Document: RFC 4354
 Person to Contact: Miguel A. Garcia-Martin,
 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.
 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 4354 (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

Garcia-Martin Informational [Page 18] RFC 4354 PoC Settings Event Package January 2006

 Person & email address to contact for further information: Miguel
 A. Garcia-Martin, 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
       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., "Session Initiation Protocol (SIP) Extension for
       Event State Publication", RFC 3903, October 2004.
 [9]   Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
       (S/MIME) Version 3.1 Message Specification", RFC 3851,
       July 2004.

Garcia-Martin Informational [Page 19] RFC 4354 PoC Settings Event Package January 2006

 [10]  Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler,
       "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
       FirstEdition REC-xml-20001006, October 2000.

10.2. Informative References

 [11]  Camarillo, G. and A. Roach, "Requirements and Framework for
       Session Initiation Protocol (SIP) Uniform Resource Identifier
       (URI)-List Services", Work in Progress, April 2005.
 [12]  Rosenberg, J., "A Framework for Conferencing with the Session
       Initiation Protocol (SIP)", RFC 4353, January 2006.

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 Informational [Page 20] RFC 4354 PoC Settings Event Package January 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 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.
 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.

Intellectual Property

 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.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

Garcia-Martin Informational [Page 21]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4354.txt · Last modified: 2006/01/13 17:54 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki