RFC 4354

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

📅 published January 2006, from ietf

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

Okay bestie, let's start with the title block so you know what you're looking at 💖

  • RFC number: 4354
  • Series: Network Working Group
  • Author: M. Garcia-Martin, Nokia
  • Category: Informational
  • Date: January 2006
  • Obsoletes / Updates: The title block doesn't list any obsoletes or updates ✨

Status of This Memo 📜

This memo gives information to the Internet community. It is not an Internet standard of any kind 🙈 Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2006).

Abstract 🌸

Okay so, the Open Mobile Alliance (OMA) is defining Push-to-talk over Cellular (PoC), and SIP is the protocol it uses to set up half-duplex media sessions between different participants, plus sending instant messages and stuff 📱 This doc defines a SIP event package for publishing, subscribing to, and getting notified about the extra capabilities PoC needs 🦋 It's applicable to PoC, but it may not be applicable to the general Internet, so don't go trying it everywhere 😭

Table of Contents 🗂️

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

1. Introduction ✨

The Open Mobile Alliance (OMA) (http://www.openmobilealliance.org) is currently specifying the Push-to-talk over Cellular (PoC) service 📣 This service lets one SIP User Agent (a PoC terminal) set up a session with one or more SIP User Agents (UAs) at the same time, and it's usually kicked off when the initiating user pushes a button 🔥

OMA has defined a collection of very stringent requirements for the PoC service 😤 To give users a good experience, the initial session setup (from the moment the user presses the button to the moment they get a signal to start talking) must be minimized ⏱️

The PoC terminal may support hardware like a speakerphone and/or headset, plus software that lets the user set it to accept session invitations immediately and play out media as soon as it arrives, without the called user having to do anything 🎧 This is called Auto-Answer mode, or automatic mode 🧚 The user can also set the terminal to alert them first and make them accept the session invitation by hand before any media comes through. That's called Manual-Answer mode 🙋‍♀️ A PoC terminal may support both of these modes or just one. The user can change the Answer Mode (AM) setting pretty often depending on their situation and preferences, like when they're busy or in a public place where they can't use a speakerphone 💅

SIP PoC terminals can also support other SIP-based communication services besides Push-to-talk, like VoIP telephony, presence services, messaging, and so on 📞 Sometimes a user wants to turn off Push-to-talk sessions but still stay SIP registered for one or more of those other services 🙈 When a PoC terminal is set to not accept any incoming Push-to-talk sessions, that's called Incoming Session Barring (ISB) 🚫

A user may want to reach someone whose PoC terminal has Incoming Session Barring turned on 👀 They can send an Instant Personal Alert to tell that person they want to start a PoC Session with them 💌 This alert still gets through even when the destination terminal has Incoming Session Barring enabled ✨ If a user wants to stop getting Instant Personal Alerts, they can set their PoC terminal to not accept any incoming ones, and that's called Instant Personal Alert Barring (IPAB) 🔕

Some PoC terminals can handle multiple PoC sessions at once, while others can only do one at a time 🧠 And even if a terminal can juggle several sessions, the user might still want just one session at a time 🫶 Whether a terminal supports multiple PoC sessions at once is called Simultaneous PoC Sessions Support (SSS) 🌈

The OMA PoC Architecture uses SIP servers in the network that can play roles like a conference focus [12], an RTP translator, or a policy server 🖥️ One possible optimization to cut down the delay before the caller gets a signal to speak is for the SIP network server to buffer media packets. That lets it give the caller an early or unconfirmed signal to speak, so the caller can start talking before the called PoC terminal has answered 🏃‍♀️ This optimization is only appropriate when the called PoC terminal is currently accepting PoC sessions and its Answer Mode is set to Auto-Answer 🎯 Which means the network SIP server needs to know the current ISB and AM settings of the called PoC terminal 🤓

It's the same deal with Instant Personal Alerts. To avoid sending pointless Instant Personal Alerts across the radio interface, the network SIP server needs to know the current IPAB setting on the terminal 📡

When a UA supports multiple PoC sessions at once, the server has to act as a B2BUA so it can multiplex media and floor control signaling across several sessions over a single bandwidth-limited radio bearer 🎀 If there's no need to handle multiple PoC sessions at once, the server can act as a SIP proxy instead 💜 So it's a big plus for the server to know whether the UA currently intends to support multiple PoC sessions at once 🙌

This document proposes additional SIP capabilities so that the ISB, AM, IPAB, and SSS settings can be communicated between the SIP PoC terminal and the SIP network server 🦋

We define a SIP event package that lets a SIP Event Publication Agent (EPA) publish the user's settings at that particular EPA, which may affect certain session attempts 📮 This lets subscribers subscribe to the Event State Compositor for this event package, gather that info, and anticipate what the user needs when a session is attempted with them 🔮 It's believed that the SIP event package defined here is not applicable to the general Internet, because it was designed to serve the PoC service architecture 🏗️ Specifically, and in the context defined by RFC 3903 [8], OMA intends for PoC terminals to behave as Event Publication Agents (EPA), and network servers to behave as Event State Compositors (ESC) 🧩 PoC terminals and network servers may also subscribe to the user's PoC related settings, so that changes made on one terminal stay in sync across all of the user's terminals or with the network server 🔄

This document defines a PoC-settings document that lets an EPA send its ISB, AM, IPAB, and SSS settings to an ESC 💌 The EPA sends the PoC-settings document in PUBLISH requests [8] 🚀 The PoC-settings document represents the settings view at that particular EPA 👑 The ESC can collect PoC-settings documents for the same user from different EPAs, apply a composition policy, and send out notifications 🎁 Notifications can include a composed view of the settings, or a list of settings per EPA, depending on whether the ESC is able to resolve conflicts 🧐 A subscriber can get notifications about changes to this document following the procedures in RFC 3265 [5] 📬 The goal of this memo is to follow the procedure in RFC 3427 [6] and register a new poc-settings event package with IANA 🌸

2. Terminology 📖

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations 💅

3. Applicability Statement 🧚

The event package defined in this document is intended for use with network-based application servers that provide a Push-to-Talk over Cellular service 🏆

4. Requirements ✨

okay so the full list of every Push-to-Talk over Cellular requirement from the Open Mobile Alliance lives on their web page at http://www.openmobilealliance.org 🌐 but we only need the ones that touch this solution, so here's the tea 🫶

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

so these requirements lead to a solution where the user can tell a network node whether they can accept or reject sessions, or certain types of messages 💅 pushing those settings to a network node lets it respond to the originator faster, and it might even decline or filter some SIP requests headed to the destination ⚡ that's how we get closer to the goal of cutting session setup time, iconic 🙌

5. The "poc-settings" Event Package 🎀

okay so RFC 3265 [5] defines a SIP extension for subscribing to remote nodes and getting notified when their states change (events) 👀 it leaves a lot of the details about those events to specific extensions called event packages, and this document counts as one of those 💖 this section fills in all the info that RFC 3265 [5] says every event package needs ✨

and then RFC 3903 [8] adds an extension that lets SIP User Agents publish event state 📮 according to RFC 3903 [8], any event package meant to go with the SIP PUBLISH method has to include a considerations section, so this section also covers that for anything used with PUBLISH requests 🦋

we're defining a brand new "poc-settings" event package 🌸 Event Publication Agents (EPA) use PUBLISH requests to tell an Event State Compositor (ESC) about changes in the poc-settings package, and the ESC, acting as a notifier, tells subscribers to the user's poc-settings whenever those change 🔔

5.1. Package Name

the name of this package is "poc-settings" 🏷️ as RFC 3265 [5] specifies, this value shows up in the Event header field of SUBSCRIBE and NOTIFY requests, and as RFC 3903 [8] specifies, it also shows up in the Event header field of PUBLISH requests 💜

5.2. Event Package Parameters

RFC 3265 [5] lets event packages define extra parameters carried in the Event header field 🧚 the "poc-settings" package, though, does not define any extra parameters, so none here 🙅‍♀️

5.3. SUBSCRIBE Bodies

according to RFC 3265 [5], a SUBSCRIBE request can contain a body, and what the body is for depends on its type 🎁 subscriptions to the poc-settings package will normally not contain bodies 🙈

the Request-URI of the SUBSCRIBE request identifies the user whose poc-settings the subscriber wants to hear about 💌

5.4. Subscription Duration

the default expiration time for subscriptions in 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 RFC 3265 [5] describes, the NOTIFY message will contain bodies describing the state of the subscribed resource 📦 the body is in a format listed in the Accept header field of the SUBSCRIBE request, or in a package-specific default format if the Accept header field was left out of the SUBSCRIBE request 🌈

in this package, the notification body holds a PoC-settings document (see Section 6) 🎀 the ESC has collected PoC-settings documents for the user from different EPAs, then applies a composition policy and builds one PoC-settings document with a shared view of all those settings across the EPAs ✨ and if the ESC can't resolve a conflict, because two different EPAs gave contradictory info, it provides a PoC-settings document with the settings from each terminal so the subscriber can sort it out 🫠

okay now the big rules 📜 all subscribers and notifiers of the "poc-settings" package MUST support the "application/poc-settings+xml" data format described in Section 6 🔥 the SUBSCRIBE request MAY contain an Accept header field 💖 if there's no such header field, it defaults to "application/poc-settings+xml" (assuming the Event header field has a value of "poc-settings") 🌸 and if the Accept header field is present, it MUST include "application/poc-settings+xml" and MAY include any other types that can represent user settings for PoC 🦋

5.6. Notifier Processing of SUBSCRIBE Requests

this part is the bodyguard era 🛡️ PoC-settings documents can hold sensitive info that reveals some privacy stuff, so PoC-settings documents MUST only be sent to authorized subscribers 🔒 to figure out whether a subscription comes from an authorized user, the user MUST be authenticated as described in Section 5.6.1, and then they MUST be authorized to be a subscriber as described in Section 5.6.2 💅

5.6.1. Authentication

notifiers MUST authenticate all subscription requests 🔐 this can be done with any of the mechanisms defined in RFC 3261 [4] and other authentication extensions 🧩

5.6.2. Authorization

once someone is authenticated, the notifier makes an authorization decision ⚖️ a notifier MUST NOT accept a subscription unless the user has provided authorization 🚫 how that authorization gets provided is outside the scope of this document 🤷‍♀️ it might have been provided ahead of time through access lists, maybe in a web page, or by uploading some kind of standardized access control list document 📄

5.7. Notifier Generation of NOTIFY Requests

RFC 3265 [5] details how NOTIFY messages are formatted and structured 📐 but packages are required to give detailed info on when to send a NOTIFY, how to compute the state of the resource, how to generate neutral or fake state info, and whether the state info is complete or partial 🧠 this section covers all of that for poc-settings 💜

a notifier MAY send a NOTIFY at any time 🕰️ typically it'll send one when a user's poc-settings stage changes 🔄 the NOTIFY request MAY contain a body with a PoC-settings document 🎁 when a NOTIFY goes out to a particular subscriber, and what's in its body, follow any rules set by the authorization policy governing that subscription 📋 still, the NOTIFY will typically say which PoC-related services had a change 👀

for a pending subscription, a NOTIFY can be sent once the final authorization decision is made ⏳ if that decision was a success, a NOTIFY SHOULD be sent and SHOULD contain a complete PoC-settings document with the user's current PoC settings 💯 if the subscription gets rejected, a NOTIFY MAY be sent 🚪 as RFC 3265 [5] describes, the Subscription-State header field shows the state of the subscription 📊

the body of the NOTIFY MUST be sent using one of the types listed in the Accept header field of 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), so they learn the poc-settings event state from PUBLISH requests sent by the user's Event Publication Agent (EPA) whenever the user changes one of those settings 📬 it's possible that a notifier generates a NOTIFY for a user who has never had a publication 🫥 in that case, the PoC-settings document won't contain any <entity> element (see Section 6.1 for the full scoop on the <entity> element) 🧁

for privacy reasons, it'll often be necessary to encrypt the contents of the notifications 🔏 this can be done with S/MIME [9] 🔑 the encryption can use the key of the subscriber as identified in the From field of the SUBSCRIBE request 🗝️ integrity matters too, so the contents of the notifications MAY provide authentication and message integrity using S/MIME [9] ✅ since the NOTIFY is made by the notifier, which might not have the key of the user represented by the poc-settings, the NOTIFY will often be signed by a third party 🕵️‍♀️ the NOTIFY request SHOULD be signed by an authority over the user's domain 🏛️ so 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 what the subscriber does when a NOTIFY request arrives, including any logic needed to form a coherent resource state 🧩

in this spec, each NOTIFY request has either no PoC-settings document, or a document showing one or more PoC-related settings for a given user 📄 within a dialog, the PoC-settings document in the NOTIFY request with the highest CSeq header field value is the current one 🔝 when there's no document in that NOTIFY, the PoC-settings document in the NOTIFY with the next highest CSeq value is used 🪜

5.9. Handling of Forked Requests

RFC 3265 [5] requires each package to describe how forked SUBSCRIBE requests are handled 🍴

this specification only allows a single dialog to be built from emitting an initial SUBSCRIBE request 🎯 that guarantees only one subscriber is generating notifications for a particular subscription to a particular user 🙌 the result is that a user can have multiple SIP User Agents active, but they should be homogeneous, so 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're used, to specify how authentication and authorization are done 🕵️

this specification allows state agents to be located in the network 🌐 publication of a PoC-settings document is linked to a user, but a user can be logged in at different PoC terminals at the same time 💻📱 if a user changes their PoC settings from one terminal, that terminal sends a PUBLISH request containing a PoC-settings document 📤 those settings apply to the user no matter which terminal they're logged in on 🧍‍♀️ in other words, PoC settings changes made on one terminal affect every PoC terminal the user is logged in to 💫 it is RECOMMENDED that each terminal where the user is logged in subscribes to its own PoC-settings document, so everyone keeps a coherent state view with the state agent 🫶

5.12. Examples

an example of a PoC-setting document is in Section 6.2 📖✨

5.13. Use of URIs to Retrieve State 🔗

Okay so, RFC 3265 [5] lets packages use URIs to grab big state documents 🌸

PoC-settings docs are honestly pretty small 🥹 so this event package doesn't have a way to use URIs to fetch large state documents. 💅

5.14. PUBLISH Bodies 📮

RFC 3903 [8] requires event packages to define the content types expected in PUBLISH requests. ✨

In this event package, the body of a PUBLISH request contains a PoC-settings document (see Section 6). This PoC-settings document describes the PoC-related settings of a user at an EPA. EPAs SHOULD include their own information in a PoC-settings document; i.e., there SHOULD be a single <entity> element in the body of the PUBLISH request (See Section 6.1 for a detailed description of the <entity> element). 🎀

All EPAs and ESCs MUST support the "application/poc-settings+xml" data format described in Section 6 and MAY support other formats. 💖

5.15. PUBLISH Response Bodies 🦋

This specification does not associate semantics to a body in a PUBLISH response. 🤷‍♀️

5.16. Multiple Sources for Event State 🌈

RFC 3903 [8] requires event packages to specify whether multiple sources can contribute to the event state view at the ESC. 👀

This event package lets different EPAs publish the PoC settings for a particular user. Each EPA publishes its own settings, grouped in an <entity> element. The EPA provides a globally unique identifier for a given address of record. This lets the ESC tell EPAs apart and either compose a state that resolves conflicts or provide the union of the states of all the EPAs that contributed to it. The composition policy at the ESC is outside the scope of this document. 🧚

5.17. Event State Segmentation 🍓

RFC 3903 [8] defines segments within a state document. Each segment is defined as one of potentially many identifiable sections in the published event state. 🧩

This event package defines, for a given EPA, four segments identified by the elements <isb-settings>, <am-settings>, <ipab-settings>, and <sss-settings>, respectively. Each of them refers to different states of the EPA. 💜

5.18. Rate of Publication ⭐

RFC 3903 [8] allows event packages to define their own rate of publication. 🙌

There are no rate-limiting recommendations for poc-settings publication. Since changes in a PoC-settings document are typically triggered by interaction with a human user, there is not periodicity, nor a minimum or maximum rate of publication. 😌

6. PoC-Settings Document 📄

PoC-settings is an XML document [10] that MUST be well-formed and SHOULD be valid. PoC-settings documents MUST be based on XML 1.0 and MUST be encoded using UTF-8 [7]. This specification makes use of XML namespaces for identifying PoC-settings documents. The namespace URI for elements defined by this specification is a URN [2], using the namespace identifier 'oma'. This URN is:

      urn:oma:params:xml:ns:poc:poc-settings

PoC-settings documents are identified with the MIME type "application/poc-settings+xml" and are instances of the XML schema defined in Section 6.1. 🎀

A PoC-settings document begins with the root element tag <poc-settings>. It consists of zero or more <entity> elements, each one including an 'id' attribute that contains a globally unique identifier for a given address of record that represents an EPA. An <entity> element represents an EPA, and it is uniquely identified by the 'id' attribute. EPAs SHOULD include a single <entity> element in a PoC-settings document. ESCs MAY include several <entity> elements in a PoC-settings document, typically when the ESC is unable to resolve conflicts due to incongruent publication from different sources. 🍰

A valid PoC-settings document can include zero <entity> elements if the ESC provides a notification for which no publication has occurred. 🙈

The <entity> element MAY contain other elements and attributes from different namespaces for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. 🧸

The <entity> element consists of zero or one <isb-settings> elements, zero or one <am-settings> elements, zero or one <ipab-settings>, and zero or one <sss-settings> elements. Other elements and attributes 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 a 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 a 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 ✨

okay so here's a full example of a PoC-settings document 🎀 it's giving everything you need in one tidy package 💅

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

bestie, this part is serious, so let's be serious for a sec 🥺 The "poc-settings" event package is meant to ride along inside SIP PUBLISH requests, which means the Security Considerations in Section 14 of RFC 3903 [8] apply here too 🫶 The settings in this package belong to whichever user generated that PUBLISH request. So any server receiving a SIP PUBLISH carrying a "poc-settings" event package SHOULD authenticate the user before it authorizes the publication (as RFC 3903 [8] already requires) 🔒

We talked about authentication and authorization of subscriptions in Section 5.6 ✨ If nobody checks who's asking, poc-settings info can leak to people who shouldn't have it, and they can use it to plan attacks 😭 Like, an unauthorized recipient could learn that the publisher's terminal answers PoC sessions in automatic answer mode, then start a malicious session with inappropriate media that the UAS will just play automatically 💀 Or the attacker could find out the terminal is happy to take simultaneous PoC sessions, and then flood it with bogus sessions to drain resources in the SIP UA and leave hung states behind 🙈

Integrity protection and confidentiality of notifications are covered in Section 5.7 🌸 If a notifier doesn't encrypt the bodies of NOTIFY requests, an eavesdropper could see the status of a SIP user agent and use it to set up malicious PoC sessions 👀 And if the notifier doesn't integrity protect those bodies, a man-in-the-middle or a malicious SIP proxy could tweak the poc-settings notification contents 🙃 That one doesn't do real harm, but it can cause annoyances, like a media clip stuttering because there's no buffering, when PoC sessions get delivered to the user 🎧

8. Acknowledgements 🌈

huge thank-you to Ilkka Westman, Andrew Allen, Chinmay Padhye, Gonzalo Camarillo, Paul Kyzivat, Haris Zisimopoulos, Joel M. Halpern, and Russ Housley for all their comments 🫶💖 you're literally the reason this spec slays 👑

9. IANA Considerations 📋

9.1. Registration of the "poc-settings" Event Package

so IANA needs the deets to register this event package, and the rules come from RFC 3265 [5] 🧚 Here's exactly what they need:

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

this is the form for registering the MIME type, which goes to ietf-types@iana.org 💌 Here's the whole thing, verbatim:

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

these are the must-read refs, the ones the spec leans on hard 💅

[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

these ones are just for extra context, not required reading 🦋

[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

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 on whether any Intellectual Property Rights might apply to the technology in this document, or whether any license for them is available, and it hasn't independently gone looking for any such rights 🔍 For the procedures around rights in RFC documents, check BCP 78 and BCP 79.

Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of attempts to get a general license or permission for implementers or users, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites anyone to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that information to ietf-ipr@ietf.org 💌

Acknowledgement 💖

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

📦 where this page comes from