Session Initiation Proposal V. Hilt Investigation Working Group Bell Labs/Lucent Technologies Internet-Draft G. Camarillo Expires: January 8, 2005 Ericsson J. Rosenberg dynamicsoft July 10, 2004 Profile Data for Session Initiation Protocol (SIP) Policies draft-ietf-sipping-session-indep-policy-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 8, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This draft specifies an XML schema for profile data for SIP session policies. This schema can be used within the user agent profile devliery framework to implement session-independent SIP session policies. Hilt, et al. Expires January 8, 2005 [Page 1] Internet-Draft Profile Data for Session Policies July 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Considerations for Policy-related Profile Data . . . . . . . . 4 4. User Agent Profile Data for Session Policies . . . . . . . . . 5 4.1 Policy Document Format . . . . . . . . . . . . . . . . . . 5 4.1.1 Protocols Element . . . . . . . . . . . . . . . . . . 5 4.1.2 Media Element . . . . . . . . . . . . . . . . . . . . 7 4.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6.1 MIME Registration for application/session-policy+xml . . . 10 6.2 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:sessionpolicy . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Hilt, et al. Expires January 8, 2005 [Page 2] Internet-Draft Profile Data for Session Policies July 2004 1. Introduction Some domains have policies in place, which impact the sessions established using the Session Initiation Protocol (SIP). These policies are typically needed to support the operation of the network infrastructure or certain services. For example, a SIP user agent might be located in a domain that is behind a Network Address Translator (NAT). This domain might have a policy in place that requires the user agent to contact a TURN [10] 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. Some domains have policies in place that are enforced by network elements. For example, a domain might have a configuration in which all packets containing a certain voice encoding are dropped. Unfortunately, enforcement mechanisms usually do not inform the user about the policies they are enforcing and silently keep the user from doing anything against them. This may lead to the malfunctioning of devices that is in-apprehensible to the user. With session policies, the user could decide to switch to a different codec or connect to a domain with less stringent policies. Session policies may be specific to a certain session and may change from session to session. Such policies can be set up using the framework for session-specific policies [3]. Other session policies remain in place 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 Hilt, et al. Expires January 8, 2005 [Page 3] Internet-Draft Profile Data for Session Policies July 2004 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. This draft specifies a XML schema for media and protocol user agent profile data. The media data defines properties of media streams transmitted by a user agent. The protocol data defines the methods, extensions, bodies, etc. that should be supported by a user agent. These formats can be used to define session policy documents. Session policy documents can be transmitted to user agents as part of their device configuration using the Framework for SIP User Agent Profile Delivery [8]. 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. 3. Considerations for Policy-related Profile Data Policy documents should support versioning so that the recipients of policy document can properly order them. This may be achieved using a version attribute. A policy document may contain multiple policies. Each policy in the document may have a different scope. For example, a policy for firewall traversal would only apply to external calls whereas a policy limiting the bandwidth available could be in effect during peak hours. A policy document may define a scope attribute that specifies to which sessions a certain policy applies. Possible scopes are: o Time and day: limits the use of a policy to certain times or days. o Local entity: limits the use of a policy to a specific to a certain local user. This is in particular useful for devices that supports multiple identities. o Remote entity: limits the use of a policy to sessions involving certain remote addresses, for example all non-local addresses. o Media streams: limits the use of a policy to certain media streams. The use of policies may be mandatory or optional. A policy document may specify whether a policy is mandatory or optional. Hilt, et al. Expires January 8, 2005 [Page 4] Internet-Draft Profile Data for Session Policies July 2004 4. User Agent Profile Data for Session Policies TODO: This specification needs to be alinged the schema for SIP protocol user agent profile data sets so that it can co-exist with other data delivered through the user agent configuration framework. A session policy document is an XML document that MUST be well-formed and SHOULD be valid. 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". 4.1 Policy Document 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 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. 4.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 January 8, 2005 [Page 5] Internet-Draft Profile Data for Session Policies July 2004 4.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). 4.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). 4.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). 4.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 January 8, 2005 [Page 6] Internet-Draft Profile Data for Session Policies July 2004 4.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. 4.1.1.6 Example of a Protocol Element 4.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. 4.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 January 8, 2005 [Page 7] Internet-Draft Profile Data for Session Policies July 2004 type (allowed or disallowed). The stream element has a number of optional sub-element: the codecs element, the transports element and the directions element. 4.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 name, and the policy attribute contains the policy for that codec (allowed, or disallowed). The codec name is the encoding name as defined by the respective RTP profile. 4.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). 4.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). 4.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. 4.1.2.2 Example of a Media Element Hilt, et al. Expires January 8, 2005 [Page 8] Internet-Draft Profile Data for Session Policies July 2004 4.2 Schema The following is the schema for the application/session-policy+xml type: TBD 4.3 Example The following is is an example of an application/session-policy+xml document: Hilt, et al. Expires January 8, 2005 [Page 9] Internet-Draft Profile Data for Session Policies July 2004 5. 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. 6. IANA Considerations This document registers a new MIME type, application/ session-policy+xml, and registers a new XML namespace. 6.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 5 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" Hilt, et al. Expires January 8, 2005 [Page 10] Internet-Draft Profile Data for Session Policies July 2004 Personal and email address for further information: Gonzalo Camarillo, Intended usage: COMMON Author/Change controller: The IETF. 6.2 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:sessionpolicy This section registers a new XML namespace, as per the guidelines in [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 7 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. Hilt, et al. Expires January 8, 2005 [Page 11] Internet-Draft Profile Data for Session Policies July 2004 [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] Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-03 (work in progress), May 2004. [9] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [10] Rosenberg, J., "Traversal Using Relay NAT (TURN)", draft-rosenberg-midcom-turn-04 (work in progress), February 2004. [11] 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. Authors' Addresses Volker Hilt Bell Labs/Lucent Technologies 101 Crawfords Corner Rd Holmdel, NJ 07733 USA EMail: volkerh@bell-labs.com Hilt, et al. Expires January 8, 2005 [Page 12] Internet-Draft Profile Data for Session Policies July 2004 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 Appendix A. Acknowledgements Many thanks to Allison Mankin and Markus Hofmann for their contributions to this draft. Hilt, et al. Expires January 8, 2005 [Page 13] Internet-Draft Profile Data for Session Policies July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hilt, et al. Expires January 8, 2005 [Page 14]