One document matched: draft-garcia-sipping-poc-isb-am-02.txt
Differences from draft-garcia-sipping-poc-isb-am-01.txt
SIPPING Working Group M. Garcia-Martin
Internet-Draft Nokia
Expires: December 17, 2005 June 15, 2005
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-02
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 December 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
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
applicable to the PoC service and may not be applicable to the
Garcia-Martin Expires December 17, 2005 [Page 1]
Internet-Draft PoC ISB AM IPAB June 2005
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 . . . . . . . . . . . . . . . . . . . . . . . . . 13
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 December 17, 2005 [Page 2]
Internet-Draft PoC ISB AM IPAB June 2005
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 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 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.).
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 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 enabled Incoming
Session Barring. 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 December 17, 2005 [Page 3]
Internet-Draft PoC ISB AM IPAB June 2005
may perform roles such as a conference focus [12], 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.
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 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 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, and IPAB settings to an ESC. The EPA sends a
poc-settings document in PUBLISH requests [8]. 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",
Garcia-Martin Expires December 17, 2005 [Page 4]
Internet-Draft PoC ISB AM IPAB June 2005
"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 changes (events) in the state of remote
nodes. 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
Garcia-Martin Expires December 17, 2005 [Page 5]
Internet-Draft PoC ISB AM IPAB June 2005
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. 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 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 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.
Garcia-Martin Expires December 17, 2005 [Page 6]
Internet-Draft PoC ISB AM IPAB June 2005
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
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.
5.6 Notifier processing of SUBSCRIBE requests
5.6.1 Authentication
The contents of a poc-settings document can contain sensitive
information that can reveal some privacy information. 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
subscription, but typically will contain an indication of those PoC
Garcia-Martin Expires December 17, 2005 [Page 7]
Internet-Draft PoC ISB AM IPAB June 2005
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 [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, 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 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. 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 December 17, 2005 [Page 8]
Internet-Draft PoC ISB AM IPAB June 2005
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 December 17, 2005 [Page 9]
Internet-Draft PoC ISB AM IPAB June 2005
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 given user the ESC will consider the
last received PoC settings documents 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 December 17, 2005 [Page 10]
Internet-Draft PoC ISB AM IPAB June 2005
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 one <isb-settings> elements, zero
or one <am-settings> elements, and zero or one <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 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 or not at the UA, depending on the user's
preferences for this setting. Other elements from different
Garcia-Martin Expires December 17, 2005 [Page 11]
Internet-Draft PoC ISB AM IPAB June 2005
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"/>
<xs:element name="am-settings" type="amSettingType"
minOccurs="0"/>
<xs:element name="ipab-settings" type="ipabSettingType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other"/>
</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>
Garcia-Martin Expires December 17, 2005 [Page 12]
Internet-Draft PoC ISB AM IPAB June 2005
<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>
6.2 Example
The following is an example of a PoC settings document:
Garcia-Martin Expires December 17, 2005 [Page 13]
Internet-Draft PoC ISB AM IPAB June 2005
<?xml version="1.0" encoding="UTF-8"?>
<poc-settings xmlns="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]).
Privacy, integrity protection and confidentiality have been also
discussed in Section 5.7.
8. Acknowledgements
The author wants to thank Ilkka Westman, Andrew Allen, and Gonzalo
Camarillo 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 Expires December 17, 2005 [Page 14]
Internet-Draft PoC ISB AM IPAB June 2005
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 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 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 December 17, 2005 [Page 15]
Internet-Draft PoC ISB AM IPAB June 2005
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
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,
Garcia-Martin Expires December 17, 2005 [Page 16]
Internet-Draft PoC ISB AM IPAB June 2005
July 2004.
[10] 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.2 Informational References
[11] Camarillo, G. and A. Roach, "Requirements and Framework for
Session Initiation Protocol (SIP)Uniform Resource Identifier
(URI)-List Services", draft-ietf-sipping-uri-services-03 (work
in progress), April 2005.
[12] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol",
draft-ietf-sipping-conferencing-framework-05 (work in
progress), May 2005.
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 December 17, 2005 [Page 17]
Internet-Draft PoC ISB AM IPAB June 2005
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 (2005). 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 December 17, 2005 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-23 11:46:44 |