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
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.
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"/>
</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>
<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>
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:
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
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.
[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
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).