[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 RFC 4354

SIPPING Working Group                                   M. Garcia-Martin
Internet-Draft                                                     Nokia
Expires: June 15, 2005                                 December 15, 2004


 A Session Initiation Protocol (SIP) Event Package and Data Format for
  various settings in support for the Push-to-talk Over Cellular (PoC)
                                service
                   draft-garcia-sipping-poc-isb-am-01

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 June 15, 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 June 15, 2005                  [Page 1]

Internet-Draft              PoC ISB AM IPAB                December 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  . . . . . . . . . . . . . . . . . . .  5
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  The "poc-settings" Event Package . . . . . . . . . . . . . . .  5
     5.1   Package Name . . . . . . . . . . . . . . . . . . . . . . .  6
     5.2   Event Package Parameters . . . . . . . . . . . . . . . . .  6
     5.3   SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . .  6
     5.4   Subscription duration  . . . . . . . . . . . . . . . . . .  6
     5.5   NOTIFY Bodies  . . . . . . . . . . . . . . . . . . . . . .  6
     5.6   Notifier processing of SUBSCRIBE requests  . . . . . . . .  7
       5.6.1   Authentication . . . . . . . . . . . . . . . . . . . .  7
       5.6.2   Authorization  . . . . . . . . . . . . . . . . . . . .  7
     5.7   Notifier Generation of NOTIFY Requests . . . . . . . . . .  7
     5.8   Subscriber Processing of NOTIFY Requests . . . . . . . . .  8
     5.9   Handling of Forked Requests  . . . . . . . . . . . . . . .  9
     5.10  Rate of Notifications  . . . . . . . . . . . . . . . . . .  9
     5.11  State Agents . . . . . . . . . . . . . . . . . . . . . . .  9
     5.12  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.13  Use of URIs to Retrieve State  . . . . . . . . . . . . . .  9
     5.14  PUBLISH bodies . . . . . . . . . . . . . . . . . . . . . . 10
     5.15  PUBLISH Response Bodies  . . . . . . . . . . . . . . . . . 10
     5.16  Multiple Sources for Event State . . . . . . . . . . . . . 10
     5.17  Event State Segmentation . . . . . . . . . . . . . . . . . 10
     5.18  Rate of Publication  . . . . . . . . . . . . . . . . . . . 10
   6.  PoC Settings Document  . . . . . . . . . . . . . . . . . . . . 11
     6.1   XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.2   Example  . . . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     9.1   Registration of the "poc-settings" Event Package . . . . . 14
     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 June 15, 2005                  [Page 2]

Internet-Draft              PoC ISB AM IPAB                December 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 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 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 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).

   A user may wish to contact a user who has their PoC terminal with
   Incoming Session Barring enabled.  A user may send an Instant
   Personal Alert to another user to inform them that they wish to
   engage them in a PoC Session.  This Instant Personal Alert is
   received even when the destination PoC terminal has Incoming Session
   Barring enabled.  If a user wishes to disable the acceptance of
   Instant Personal Alerts they can configure their PoC terminal not
   accept any incoming Instant Personal Alerts.  This is known as
   Instant Personal Alert Barring (IPAB).

   The OMA PoC Architecture utilizes SIP servers within the network that



Garcia-Martin            Expires June 15, 2005                  [Page 3]

Internet-Draft              PoC ISB AM IPAB                December 2004


   may perform such roles as a conference focus [11], 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
   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.

   This document proposes additional SIP capabilities to enable the
   communication of the ISB, AM, and IPAB 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 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 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, AM, and IPAB 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",



Garcia-Martin            Expires June 15, 2005                  [Page 4]

Internet-Draft              PoC ISB AM IPAB                December 2004


   "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 in:

   1.  There must be a mechanism that reduces the session setup time as
       much as possible.
   2.  In order to allow a proper usage of scarce resources, there must
       be a mechanism that saves the air interface from be congested
       with unneeded or undesired traffic.
   3.  The mechanism should not involve the implementation of new
       protocols, unless strictly needed.

   These requirements lead to develop 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 the
   originator, perhaps even declining or filtering some SIP requests
   towards the destination, leading to achieving the goal of reducing
   the session setup time.

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 RFC 3903 [8] any event package intended to be used in



Garcia-Martin            Expires June 15, 2005                  [Page 5]

Internet-Draft              PoC ISB AM IPAB                December 2004


   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 RFC 3903 [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.

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



Garcia-Martin            Expires June 15, 2005                  [Page 6]

Internet-Draft              PoC ISB AM IPAB                December 2004


   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
   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



Garcia-Martin            Expires June 15, 2005                  [Page 7]

Internet-Draft              PoC ISB AM IPAB                December 2004


   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,
   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.



Garcia-Martin            Expires June 15, 2005                  [Page 8]

Internet-Draft              PoC ISB AM IPAB                December 2004


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.

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            Expires June 15, 2005                  [Page 9]

Internet-Draft              PoC ISB AM IPAB                December 2004


   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 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

   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.  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

   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 three segments identified by the elements
   <isb-settings>, <am-settings>, and <ipab-settings>, respectively.
   Each of them refer to different states of the SIP UA.

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



Garcia-Martin            Expires June 15, 2005                 [Page 10]

Internet-Draft              PoC ISB AM IPAB                December 2004


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: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 <isb-settings> elements,
   zero or more <am-settings> elements, and zero or more<ipab-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 that contains a boolean 'active'
   attribute.  The 'active' attribute indicates whether incoming
   sessions are barred or not 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 <am-settings> element contains an <answer-mode> element, whose
   value can be set to either "automatic" or "manual".

   Other elements from different namespaces MAY be present for the
   purposes of extensibility; elements or attributes from unknown
   namespaces MUST be ignored.

   A server such as URI-list server 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.  Other elements from different namespaces MAY be present
   for the purposes of extensibility; elements or attributes from
   unknown namespaces MUST be ignored.




Garcia-Martin            Expires June 15, 2005                 [Page 11]

Internet-Draft              PoC ISB AM IPAB                December 2004


   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 or not 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.

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: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, and Incoming Personal Alert Barring
         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:element name="ipab-settings" type="ipabSettingType"
                     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">



Garcia-Martin            Expires June 15, 2005                 [Page 12]

Internet-Draft              PoC ISB AM IPAB                December 2004


       <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="##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:any namespace="##other" processContents="lax"
                 minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##other"/>
     </xs:complexType>

     <xs:complexType name="ipabSettingType">
        <xs:sequence>
         <xs:element name="incoming-personal-alert-barring">
           <xs:complexType>
             <xs:attribute name="active" type="xs:boolean"
                           user="required" />
           </xs:complexType>
         </xs:element>
         <xs:any namespace="##other" processContents="lax"
                 minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##other"/>
     </xs:complexType>

   </xs:schema>







Garcia-Martin            Expires June 15, 2005                 [Page 13]

Internet-Draft              PoC ISB AM IPAB                December 2004


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"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:oma:params:xml:ns:poc:poc-settings">

     <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>

   </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 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 the RFC 3903 [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



Garcia-Martin            Expires June 15, 2005                 [Page 14]

Internet-Draft              PoC ISB AM IPAB                December 2004


   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.

      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.







Garcia-Martin            Expires June 15, 2005                 [Page 15]

Internet-Draft              PoC ISB AM IPAB                December 2004


      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
        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]  Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
        "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C



Garcia-Martin            Expires June 15, 2005                 [Page 16]

Internet-Draft              PoC ISB AM IPAB                December 2004


        FirstEdition REC-xml-20001006, October 2000.

10.2  Informational References

   [10]  Camarillo, G. and A. Roach, "Requirements and Framework for
         Session Initiation Protocol (SIP)Uniform  Resource Identifier
         (URI)-List Services", draft-ietf-sipping-uri-services-02 (work
         in progress), December 2004.

   [11]  Rosenberg, J., "A Framework for Conferencing with the Session
         Initiation Protocol",
         draft-ietf-sipping-conferencing-framework-03 (work in
         progress), October 2004.

   [12]  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 June 15, 2005                 [Page 17]

Internet-Draft              PoC ISB AM IPAB                December 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 June 15, 2005                 [Page 18]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/