Session Initiation Proposal V. Hilt Investigation Working Group Bell Labs/Lucent Technologies Internet-Draft G. Camarillo Expires: April 18, 2004 Ericsson J. Rosenberg dynamicsoft October 19, 2003 A Framework for Session-Independent Intermediary Session Policies in SIP draft-hilt-sipping-session-indep-policy-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 April 18, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Domains may have policies in place that impact the way sessions are established by user agents. Some of these policies are independent of a specific session and need to be considered for a certain period of time. It is therefore desirable to convey these policies to user agents once they become active instead of requesting them for every session. In this document, we propose a framework that enables user agents to subscribe to session policies. Hilt, et al. Expires April 18, 2004 [Page 1] Internet-Draft Session-Independent SIP Session Policies October 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Framework for Session-Independent Policies . . . . . . . . . 6 3.1 Policy Server Discovery . . . . . . . . . . . . . . . . . . 6 3.2 Subscribing to Session-Independent Policies . . . . . . . . 7 3.3 Accepting or Rejecting Session-Independent Policies . . . . 8 4. Event Package Definition . . . . . . . . . . . . . . . . . . 9 4.1 Event Package Name . . . . . . . . . . . . . . . . . . . . . 9 4.2 Event Package Parameters . . . . . . . . . . . . . . . . . . 9 4.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . 9 4.4 Subscription Duration . . . . . . . . . . . . . . . . . . . 9 4.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 9 4.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . . 10 4.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . . 10 4.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 11 4.9 Handling of Forked Request . . . . . . . . . . . . . . . . . 12 4.10 Rate of Notifications . . . . . . . . . . . . . . . . . . . 12 4.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Policy Packages . . . . . . . . . . . . . . . . . . . . . . 13 5.1 Policy Object Format . . . . . . . . . . . . . . . . . . . . 13 5.2 XCAP Considerations . . . . . . . . . . . . . . . . . . . . 14 6. Basic Session Policy Package . . . . . . . . . . . . . . . . 15 6.1 Policy Object Format . . . . . . . . . . . . . . . . . . . . 15 6.1.1 Protocols Element . . . . . . . . . . . . . . . . . . . . . 15 6.1.2 Media Element . . . . . . . . . . . . . . . . . . . . . . . 17 6.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 8.1 MIME Registration for application/session-policy+xml . . . . 21 8.2 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:sessionpolicy . . . . . . . . . . . . 21 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25 References . . . . . . . . . . . . . . . . . . . . . . . . . 24 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . 27 Hilt, et al. Expires April 18, 2004 [Page 2] Internet-Draft Session-Independent SIP Session Policies October 2003 1. Introduction Some domains have policies in place, which influence the sessions a user sets up. These policies are often established to support the network infrastructure, enable user agents to use services or to prevent user agents from overly burdening the network. For example, a SIP user agent might be located in a domain, that is connected to the public Internet via a Network Address Translator (NAT). This domain might have a policy in place that requires the user agent to contact a TURN [11] relay before setting up a session. Information about this policy is essential for a user agent to successfully set up a session. In another example, SIP is used in a wireless network. The network provider has limited resources for media traffic. During periods of high activity, the provider would like to restrict codec usage on the network to lower rate codecs. In existing approaches, this is frequently accomplished by having the proxies examine the SDP [2] in the body and remove the higher rate codecs or reject the call and require the UA to start over with a different set of codecs. Having information about the current policy would enable user agents to initiate a session with an acceptable codec. In a third example, a domain has established policies regarding the type of user agents that can use their network. For example, a domain could require that user agents using its network use a particular protocol (e.g., SIP) with a set of extensions (e.g., preconditions must be used). A user agent needs to know the exact policy of a domain in order to be able to use the right configuration to send and receive traffic in that domain. In yet a fourth example, a user has subscribed to a network-based call recording service to record calls to certain destinations. The recording server acts as a media intermediary which needs to be included in the media path. Knowing the address of the recording server enables the user agent to route its traffic through the recording server if desired. Some domains enforce certain session policies. For example, if the policy of a domain disallows the use of a particular codec, access routers will discard packets that transport media encoded with that codec. Unfortunately, enforcement mechanisms do not usually inform the user about what is happening. They silently keep the user from doing anything against the policy. It is therefore important for the user agent to know about session policies and the consequences of not accepting them. Session policies may be specific to a certain session and may change Hilt, et al. Expires April 18, 2004 [Page 3] Internet-Draft Session-Independent SIP Session Policies October 2003 from session to session. Such policies can be set up using the framework for session-specific policies [3]. Other session policies remain stable for a longer period of time, typically in the range of hours or days. In principle, these policies could also be set up on a session-to-session basis. However, establishing the same policies over and over again is expensive, causing the continuous transmission of the same information during session setup, and possibly adding to session setup latencies. It is therefore desirable, to enable user agents to obtain the policies relevant for them and to inform the user agents about changes in these policies. Our solution for supporting session-independent session policies is to introduce a framework that allows user agents to subscribe to session policies. This framework satisfies the requirements listed in [13]. This document is structured as follows: Section 3 introduces a framework that enables user agents to subscribe to session policies. Section 4 provides the necessary details to define an event package for the SUBSCRIBE/NOTIFY framework. Section 5 discusses the creation of policy packages for this framework and Section 6 describes a basic policy package. Section 7 discusses Security and Section 8 IANA considerations. Section 9 talks about open issues. Hilt, et al. Expires April 18, 2004 [Page 4] Internet-Draft Session-Independent SIP Session Policies October 2003 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, [1] and indicate requirement levels for compliant implementations. Hilt, et al. Expires April 18, 2004 [Page 5] Internet-Draft Session-Independent SIP Session Policies October 2003 3. Framework for Session-Independent Policies The conveying session-independent policies to a user agent is most beneficial for network providers, that are frequently involved in the sessions established by a user agent. Typically, these are the following two providers: o The Home Domain Provider is responsible for providing SIP service to a SIP user. Typically, this is the domain present in the URI in the address-of-record of a registration. The home domain provider will usually maintain user preferences and subscriptions to services. Thus, it may want to provide session-independent policies, that are needed for services, a user has subscribed to. o The Access Network Provider is responsible for providing IP service to a SIP agent. This may be the same provider as the home domain provider or it may be a different provider in case the user roams in a foreign network or obtains SIP services and IP connectivity from different operators. Access Network Providers often provide session-independent policies, which generally impact the traffic in their networks. A solution for session-independent policies should enable a user agent to detect the policy servers in the domains of these two providers and retrieve the relevant policies. User agents should also be enabled to retrieve policies from different policy servers. This framework allows user agents to subscribe to session policies based on the SIP SUBSCRIBE/NOTIFY mechanism [10]. This framework does not define the structure or semantics of policies. Session-independent policies need to be defined in policy packages. An basic policy package is discussed in Section 6. 3.1 Policy Server Discovery In the first step, a UA needs to discover the relevant policy servers. The UA MUST attempt to discover the policy servers of the home domains of all local users. In order to do so, the UA constructs a SIP URI for each registered address of record by taking the host component of the address of record and adding "sessionpolicy" as userinfo component to this address. For example, if an address of record is sip:bob@example.com, the UA would generate the URI sip:sessionpolicy@example.com. It uses this URI to subscribe to the policies of the home domain policy server of user Bob. Using "sessionpolicy" as the userinfo component enables proxies to route the request to a policy server. Hilt, et al. Expires April 18, 2004 [Page 6] Internet-Draft Session-Independent SIP Session Policies October 2003 The UA MUST also attempt to discover the policy servers of the access network provider. The UA MUST execute the discovery procedures in the order as they appear in the following sections. It SHOULD support all procedures but it MUST support the first (outbound proxy). 1. If the UA is configured with an outbound proxy for the current access domain (e.g. by using the procedures defined in [9] or via manual configuration) the UA MUST construct a URI by adding "sessionpolicy" as userinfo component to the address of the outbound proxy. For example, if the address of an outbound proxy is sip.example.com:6060, the UA would create the URI sip:sessionpolicy@sip.example.com:6060. 2. If no outbound proxy is configured or the subscription to the above URI fails, the UA SHOULD construct a fully qualified host name by adding "sessionpolicy" to the local domain name if defined (in analogy to the DNS lookup procedure defined in [9]). For example, a UA would create the host name sessionpolicy.example.com if the local domain is example.com. The UA SHOULD then try a DNS A record lookup on this domain name. If the name resolves in a DNS record, it should create a URI by adding "sessionpolicy" as userinfo component. In the above example, the UA would create the URI sip:sessionpolicy@policy.example.com. 3. If the above hostname could not be resolved via DNS, the UA SHOULD use multicast to subscribe to policies. TBD: define this multicast address. In addition to the discovered URIs, the UA may also have manually configured URIs to policy servers. 3.2 Subscribing to Session-Independent Policies A UA sends SUBSCRIBE requests to the discovered policy server URIs. A UA compliant with this specification MUST support content indirection [8] including support for content indirection with multiple URIs. In addition, it MUST support the "application/basic-session-policy+xml" data format of the basic policy package described in Section 6. It MAY support the data formats of other policy packages. The UA SHOULD insert an Accept header into the SUBSCRIBE request. If an Accept header is created, its MUST include the MIME types "multipart/mixed", "message/external-body" and "application/basic-session-policy+xml". The UA MUST include the event package name "session-policy" in the Event header. When creating the SUBSCRIBE request, the UA MUST populate the To Hilt, et al. Expires April 18, 2004 [Page 7] Internet-Draft Session-Independent SIP Session Policies October 2003 header field with the SIP URI of the policy server it wants to subscribe to. The UA populates the From header field with the address of record of the user for whom it subscribes. The UA MUST send a separate SUBSCRIBE message for each address of records to each policy server. The only exception are the home policy servers. This enables policy servers to learn about all users a UA has registered and allows them to provide different policies for each user. A home policy server will typically not be able to provide policies for foreign users. Therefore, a UA SHOULD only subscribe the associated address of record to a home policy server. The UA SHOULD subscribe to all discovered home domain and all manually configured policy servers. It SHOULD subscribe to access network policy servers until the first successful response is received. 3.3 Accepting or Rejecting Session-Independent Policies Once a UA has received a session policy from a policy server, it can decide whether it wants to accept or reject these policies. The UA does not need to inform the policy server or proxies about its decision. The UA applies the accepted policies to new sessions it is creating. For example, if the policy lists the audio codecs allowed in a wireless network, the UA includes only those audio codecs in the session description offers and answers it creates. The way policies are applied differs from policy package to policy package and must be defined in the policy packet specification. The UA does not explicitly indicate its use of policies in an INVITE or UPDATE message. A proxy might be able to determine the acceptance of a session-independent policy by examining the actions of the UA (e.g. contacting a TURN relay) or the information it exposes in Media-Interface headers for session-specific policies [3]. The proxy may have mechanisms in place to enforce its policies. A provider may have session-independent and session-specific policies in place, which influence the same aspect of a session (e.g. the codecs allowed). Since session-specific policies are requested during the establishment or modification of a session, they are applied after session-independent policies and may override them. A UA, which has received an updated set of session-independent policies, MAY apply them to existing sessions for example by issuing a re-INVITE request. Hilt, et al. Expires April 18, 2004 [Page 8] Internet-Draft Session-Independent SIP Session Policies October 2003 4. Event Package Definition This section provides the details needed to specify an event package as defined in Section 4.4 of RFC 3265 [10]. 4.1 Event Package Name The name of this package is "session-policy". As specified in RFC 3265 [10], this value appears in the Event header field present in SUBSCRIBE and NOTIFY requests. Event: session-policy 4.2 Event Package Parameters No package specific Event header field parameters are defined for this event package. 4.3 SUBSCRIBE Bodies A SUBSCRIBE for session policy events MAY contain a body. This body would serve the purpose of filtering the subscription. The definition of such a body is outside the scope of this specification. A SUBSCRIBE for the session policy package MAY be sent without a body. This implies that the default session policy filtering policy has been requested. The default policy is that notifications are generated every time there is any change in the policies for the user. 4.4 Subscription Duration The default expiration of subscriptions to session policy state is one hour (3600 seconds). 4.5 NOTIFY Bodies This event package uses content indirection to convey policy information. As such, the body of a NOTIFY message contains one or more URIs, which point to a policy object on a policy object server (typically a HTTP server). This saves bandwidth, allows for larger policy objects and enables a policy server to insert all current policies in a NOTIFY instead of tracking the policies that are actually updated or new to a UA. The UA can then decide, which policy objects it needs to retrieve. All subscribers and notifiers MUST support the MIME types "multipart/ Hilt, et al. Expires April 18, 2004 [Page 9] Internet-Draft Session-Independent SIP Session Policies October 2003 mixed" and "message/external-body" [8]. In addition, they MUST support the "application/basic-session-policy+xml" data format of the basic policy package described in Section 6. Subscribers MAY support the data formats of other policy packages. If the notifier receives a SUBSCRIBE request without an Accept header field, it MUST use the default value of "multipart/mixed, message/external-body, application/basic-session-policy+xml". The data format of policy objects is not specified within this framework and must be defined in a policy package. A basic policy package for this framework is described in Section 6. A policy package may be based on XCAP [12]. XCAP enables fine grained access to XML-based configuration documents on a HTTP server. 4.6 Notifier Processing of SUBSCRIBE Requests Session policy state can be sensitive information. Therefore, all subscriptions to it SHOULD be authenticated and authorized before approval. Authentication MAY be performed using any of the techniques available through SIP, including digest, S/MIME, TLS or other transport specific mechanisms. It is RECOMMENDED that a user be allowed to subscribe to their own session policy. If the notifier determines that it can't provide any policy object to the subscriber now and in the near future, it SHOULD return a 480 "Temporarily Unavailable" response. This response SHOULD contain a Retry-After header indicating the time at which the subscriber should re-try the subscription. If the notifier determines that a policy object might become available in the near future, it SHOULD instead accept the subscription and create empty NOTIFY messages until the policy object is available. If the policy server requires the use of a certain policy package and detects that the UA has not indicated support for the respective document format in the Accept header, it MAY reject a SUBSCRIBE request with a 406 "Not Acceptable" response. This way, a policy server can inform the user agent that is has session-independent policies place, which are mandatory but not understood. For example, a domain could restricts the use of certain audio codecs using a policy document format that is not understood by a user agent. By returning a 406 response to the SUBSCRIBE, the user agent would be informed that something might go wrong when establishing a session. Policy documents may contain attributes that define the required status for each policy on a fine grained basis. 4.7 Notifier Generation of NOTIFY Requests Notifications SHOULD be generated whenever a change in one or more Hilt, et al. Expires April 18, 2004 [Page 10] Internet-Draft Session-Independent SIP Session Policies October 2003 session policy objects relevant to the subscribed user occurs. A notifier will typically want to provide multiple policy objects to a user. For example, the notifier could have policy objects describing the general policies of a domain and user-specific policy objects, which describe policies only relevant for a particular user. It may also have policy objects that were created by the network provider and policy objects created by the user. The notifier MUST insert the URIs of all relevant policy objects into the NOTIFY message, even if only some of the policy objects have changed. In that sense, a notifier always provides complete state information to the subscriber. Each URI MUST have an associated Content-ID entity header, which MUST change every time the referred policy object changes. This enables subscribers to determine if they have the latest version of the policy object without downloading and comparing the objects. The notifier MUST ensure that all URIs, it is inserting into a NOTIFY body, point to policy objects that are actually accessible on the policy object server. This is in particular important if the policy server creates policy objects on the fly. For example, a new policy object might be generated when a new user requests policies for the first time. A policy server MUST NOT delay the transmission of a NOTIFY if policy object is not yet available on the policy object server. Instead, it SHOULD not include the respective URI in the NOTIFY body and create an additional NOTIFY as soon as the new policy object is available. If no policy object is available at the time a NOTIFY is created, the notifier SHOULD create an empty NOTIFY message which does not contain a body. This ensures that the subscription is established and the notifier can convey policy objects to the subscriber as soon as they become available. 4.8 Subscriber Processing of NOTIFY Requests After receiving a NOTIFY, the subscriber MUST determine if any of the included URIs are pointing to a policy object, that is new or has been update since it was last downloaded. The subscriber SHOULD retrieve new or updated policy objects as soon as possible. Session policies are typically created and maintained by network providers. They provide certain information to or request a certain behavior from user agents. The provider generated policies MUST NOT be changed by a user. However, a user MAY cerate personal session policies and store them on a policy server. A user may of course modify these policies. A policy object server MUST enforce access permissions to policy objects accordingly. Hilt, et al. Expires April 18, 2004 [Page 11] Internet-Draft Session-Independent SIP Session Policies October 2003 4.9 Handling of Forked Request A subscriber establishes multiple subscription with different policy servers (home domain, access network domain, etc.). Similarly, a subscriber MAY establish multiple subscriptions on forked SUBSCRIBE requests. The NOTIFY messages created by the notifiers can be processed individually and do not need to be merged. 4.10 Rate of Notifications For reasons of congestion control, it is important that the rate of notifications not become excessive. As a result, it is RECOMMENDED that the server not generate notifications for a single subscriber at a rate faster than once every 5 seconds. 4.11 State Agents State agents have no role in the handling of this event package. Hilt, et al. Expires April 18, 2004 [Page 12] Internet-Draft Session-Independent SIP Session Policies October 2003 5. Policy Packages This section describes aspects that need to be considered when packages for session-independent policies are defined. 5.1 Policy Object Format This section MUST be present in a policy package. A Policy Object (PO) is used to convey policies to the subscriber. Each package MUST specify or cite detailed specifications for the syntax and semantics associated with such a Policy Object. The PO MUST have a version attribute that allows the recipient of POs to properly order them. A PO MAY have an expires attribute that defines the time, at which the policy object expires. If this attribute is not present, a policy object expires at the time the subscription, through which it was received, is terminated. A policy object also expires when a policy object with a higher version number becomes available at the same URI. A PO can have different scopes. It could be applicable to all sessions established by the UA or just to a subset of them. The scope of a PO MUST be defined in a policy package, by either specifying a default value or defining a scope attribute that can be populated by policy server when creating the PO. Possible scopes are: o Sessions for a certain address of record (i.e. sessions created for a certain local user). This is useful if an end device supports multiple identities and, for example, only a subset of them has subscribed to a service requiring policies. o Sessions to a certain remote URI. For example, a policy for NAT traversal might only apply to sessions to or from external addresses. o Outgoing/incoming sessions only. A policy may apply only to sessions initiated by the local/the remote UA. o A certain media stream. This enables the specification of policies on a stream-by-stream basis. For example, a policy for audio codec selection only applies to audio streams. o Media streams in the incoming or outgoing direction. This enables independent policies for the media streams in each direction. Hilt, et al. Expires April 18, 2004 [Page 13] Internet-Draft Session-Independent SIP Session Policies October 2003 A PO SHOULD contain a consequences attribute. The consequences attribute is used by the policy server to indicate what the consequences of rejecting the policy are. The this attribute MUST also enable a UA to determine if the acceptance of a policy is mandatory or optional. If the consequences attribute is not present in a PO, the default value is used. The default value is optional if not defined otherwise in the policy package. The PO MAY contain a signature attribute allowing the UA to verify the identity of the domain, which has requested policies, and the integrity of those policies. A policy package MUST describe exactly how a UA is supposed to apply the policy contained in an PO. In particular, the policy package MUST describe how the information in the PO influences the session description a UA uses to establish sessions and if additional steps need to be taken either when accepting the policy or when setting up or modifying a session. This process MUST enable a UA to determine the consequences of accepting the policy before actually executing the necessary steps. A PO MAY contain an attribute that explains the reasoning behind the session policy. The end device may present this text string to a human when querying whether the requested policies should be accepted or not. 5.2 XCAP Considerations The developer of a policy package might find it helpful to specify the policy package based on XCAP [12]. In this case, a policy package defines an XCAP application usage specification. Hilt, et al. Expires April 18, 2004 [Page 14] Internet-Draft Session-Independent SIP Session Policies October 2003 6. Basic Session Policy Package This section defines a basic policy package, that must be understood by all user agents. Policy object is an XML document that MUST be well-formed and SHOULD be valid. Session policy documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying session policy documents. The namespace URI for elements defined by this specification is a URN [5], using the namespace identifier 'ietf' defined by RFC 2648 [6] and extended by [4]. This URN is: urn:ietf:params:xml:ns:sessionpolicy A session policy document begins with the root element tag "sessionpolicy". 6.1 Policy Object Format A session policy document starts with a sessionpolicy element. This element has three mandatory attributes: version: This attribute allows the recipient of session policy information documents to properly order them. Versions start at 0, and increment by one for each new document sent to a subscriber. Versions are scoped within a subscription. Versions MUST be representable using a 32 bit integer. domain: This attribute contains the domain the policy belongs to. entity: This attribute contains a URI that identifies the user whose media policy information is reported in the remainder of the document. The sessionpolicy element has a series of sessionpolicy sub-elements: zero or one protocols element and zero or one media element. 6.1.1 Protocols Element The protocols element contains a series of protocol sub-elements. Each protocol sub-element contains the policy related to the usage of a particular protocol. The protocol element has a single mandatory attribute, name. The name attribute identifies a protocol the policy of each protocol element is referring to. The protocol element has a series of sub-elements: methods, option-tags, feature-tags, and bodies. Hilt, et al. Expires April 18, 2004 [Page 15] Internet-Draft Session-Independent SIP Session Policies October 2003 6.1.1.1 Methods Element The methods element contains a default-policy attribute and method elements. The default-policy attribute contains the policy for methods that are not listed as method elements. A method element has two attributes: name and policy. The name attribute identifies a method, and the policy attribute contains the policy for that method (allowed or disallowed). 6.1.1.2 Option-tags Element The option-tags element contains a default-policy attribute and option-tag elements. The default-policy attribute contains the policy for option-tags that are not listed as option-tag elements. An option-tag element has two attributes: name and policy. The name attribute identifies a method, and the policy attribute contains the policy for that method (mandatory, allowed, or disallowed). 6.1.1.3 Feature-tags Element The feature-tags element contains a default-policy attribute and feature-tag elements. The default-policy attribute contains the policy for feature-tags that are not listed as feature-tag elements. An feature-tag element has two attributes: name and policy. The name attribute identifies a method, and the policy attribute contains the policy for that method (allowed, or disallowed). 6.1.1.4 Bodies Element The bodies element contains a default-policy attribute, a default-encryption attribute and body-disposition elements. The default-policy attribute contains the policy for body dispositions that are not listed as body-disposition elements. The default-encryption attribute contains the encryption policy for body dispositions that are not listed as body-disposition elements. A body-disposition element can have a number of attributes: name, policy, default-policy, and encryption. The name attribute identifies a body-disposition, and the policy attribute contains the policy for that body-disposition (allowed, or disallowed). The default-policy attribute contains the policy for body formats that are not listed as body-format elements. The encryption attribute indicates whether or not encryption is allowed for a particular body disposition. A body-disposition element contains body-format elements. A body-format element can have a two attributes: name and policy. The name attribute identifies a body-format, and the policy attribute contains the policy for that body-format (allowed or disallowed). Hilt, et al. Expires April 18, 2004 [Page 16] Internet-Draft Session-Independent SIP Session Policies October 2003 6.1.1.5 Extensibility Other elements from different namespaces MAY be present within a protocol element for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. 6.1.1.6 Example of a Protocol Element 6.1.2 Media Element The media element contains the policy related to the characteristics of media streams of different types. It has three attributes: maxbandwidth, maxnostreams, and default-policy. They contain the maximum bandwidth the user can count on, the maximum number of media streams that the user is allowed to established at the same time, and the default policy (allowed or disallowed) for stream types that are not listed as stream elements. The media element contains a series of stream elements. 6.1.2.1 Stream Element A stream element can have a number of attributes: type, policy, maxbandwidth, and maxnostreams. The type attribute identifies a media type, and the policy attribute contains the policy for that media Hilt, et al. Expires April 18, 2004 [Page 17] Internet-Draft Session-Independent SIP Session Policies October 2003 type (allowed or disallowed). The stream element has a number of optional sub-element: the codecs element, the transports element and the directions element. 6.1.2.1.1 Codecs Element The codecs element contains a default-policy attribute and codec elements. The default-policy attribute contains the policy for codecs that are not listed as codec elements. A codec element can have two attributes: name and policy. The name attribute identifies a codec, and the policy attribute contains the policy for that codec (allowed, or disallowed). 6.1.2.1.2 Transports Element The transports element contains a default-policy attribute and transport elements. The default-policy attribute contains the policy for transports that are not listed as transport elements. A transport element can have two attributes: name and policy. The name attribute identifies a transport, and the policy attribute contains the policy for that transport (allowed, or disallowed). 6.1.2.1.3 Directions Element The directions element contains a default-policy attribute and direction elements. The default-policy attribute contains the policy for directions that are not listed as direction elements. A direction element can have two attributes: name and policy. The name attribute identifies a direction (sendrecv, sendonly, recvonly), and the policy attribute contains the policy for that direction (allowed, or disallowed). 6.1.2.1.4 Extensibility Other elements from different namespaces MAY be present within a stream element for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. 6.1.2.2 Example of a Media Element Hilt, et al. Expires April 18, 2004 [Page 18] Internet-Draft Session-Independent SIP Session Policies October 2003 6.2 Schema The following is the schema for the application/session-policy+xml type: TBD 6.3 Example The following is is an example of an application/session-policy+xml document: Hilt, et al. Expires April 18, 2004 [Page 19] Internet-Draft Session-Independent SIP Session Policies October 2003 7. Security Considerations Session policy information can be sensitive information. The protocol used to distribute it SHOULD ensure privacy, message integrity and authentication. Furthermore, the protocol SHOULD provide access controls which restrict who can see who else's session policy information. Hilt, et al. Expires April 18, 2004 [Page 20] Internet-Draft Session-Independent SIP Session Policies October 2003 8. IANA Considerations This document registers a new MIME type, application/ session-policy+xml, and registers a new XML namespace. 8.1 MIME Registration for application/session-policy+xml MIME media type name: application MIME subtype name: session-policy+xml Mandatory parameters: none Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [7]. Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [7]. Security considerations: See Section 10 of RFC 3023 [7] and Section 7 of this specification. Interoperability considerations: none. Published specification: This document. Applications which use this media type: This document type has been used to download the session policy of a domain to SIP user agents. Additional Information: Magic Number: None File Extension: .wif or .xml Macintosh file type code: "TEXT" Personal and email address for further information: Gonzalo Camarillo, Intended usage: COMMON Author/Change controller: The IETF. 8.2 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:sessionpolicy This section registers a new XML namespace, as per the guidelines in Hilt, et al. Expires April 18, 2004 [Page 21] Internet-Draft Session-Independent SIP Session Policies October 2003 [4] URI: The URI for this namespace is urn:ietf:params:xml:ns:sessionpolicy. Registrant Contact: IETF, SIPPING working group,, Gonzalo Camarillo, XML: BEGIN Session Policy Namespace

Namespace for Session Policy Information

application/session-policy+xml

See RFCXXXX.

END Hilt, et al. Expires April 18, 2004 [Page 22] Internet-Draft Session-Independent SIP Session Policies October 2003 9. Open Issues The following issues are still open: o Policy server discovery. Is automatic discovery of home domain and access network domain policy server desirable? It seems that these are the two domains that will most likely want to provide policies. Automatic discovery of policy servers in both domains would make deployment of policies easier and manual configuration of multiple policy servers does not seem to be attractive. However, it complicates user agents and the current procedure overloads the user name sessionpolicies. o XCAP. Would it make sense to require the use of XCAP for policy packages? XCAP already provides a number of functionalities that are most likely needed in a policy package. Requiring XCAP restricts the number of protocols that need to be supported by a client. Otherwise, a client that supports multiple packages might need to implement a lot of different protocols and document formats. Would requiring HTTP and XML do the job? o Mandatory and optional policies. What is the best way to indicate if the acceptance of a policy is required or optional? Does it make sense to define this case-by-case or is a general required/ optional definition sufficient for a policy package? Hilt, et al. Expires April 18, 2004 [Page 23] Internet-Draft Session-Independent SIP Session Policies October 2003 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [3] Hilt, V. and J. Rosenberg, "A Framework for Session-Specific Intermediary Session Policies in SIP", September 2003. [4] Mealling, M., "The IETF XML Registry", draft-mealling-iana-xmlns-registry-05 (work in progress), June 2003. [5] Moats, R., "URN Syntax", RFC 2141, May 1997. [6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [7] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [8] Olson, S., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", draft-ietf-sip-content-indirect-mech-03 (work in progress), June 2003. [9] Petrie, D., "A Framework for SIP User Agent Configuration", draft-ietf-sipping-config-framework-00 (work in progress), March 2003. [10] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [11] Rosenberg, J., "Traversal Using Relay NAT (TURN)", draft-rosenberg-midcom-turn-01 (work in progress), March 2003. [12] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-rosenberg-simple-xcap-00 (work in progress), May 2003. [13] Rosenberg, J., "Requirements for Session Policy for the Session Initiation Protocol (SIP)", draft-ietf-sipping-session-policy-req-00 (work in progress), June 2003. [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Hilt, et al. Expires April 18, 2004 [Page 24] Internet-Draft Session-Independent SIP Session Policies October 2003 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [15] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. Authors' Addresses Volker Hilt Bell Labs/Lucent Technologies 101 Crawfords Corner Rd Holmdel, NJ 07733 USA EMail: volkerh@bell-labs.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue East Hanover, NJ 07936 USA EMail: jdrosen@dynamicsoft.com Hilt, et al. Expires April 18, 2004 [Page 25] Internet-Draft Session-Independent SIP Session Policies October 2003 Appendix A. Acknowledgements Many thanks to Markus Hofmann for his contributions to this draft. Hilt, et al. Expires April 18, 2004 [Page 26] Internet-Draft Session-Independent SIP Session Policies October 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Hilt, et al. Expires April 18, 2004 [Page 27] Internet-Draft Session-Independent SIP Session Policies October 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hilt, et al. Expires April 18, 2004 [Page 28]