SIPPING Working Group V. Hilt Internet-Draft Bell Labs/Lucent Technologies Expires: April 24, 2007 G. Camarillo Ericsson J. Rosenberg Cisco Systems October 21, 2006 A User Agent Profile Data Set for Media Policy draft-ietf-sipping-media-policy-dataset-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 24, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This specification defines a document format for media properties of Session Initiation Protocol (SIP) sessions, such as the codecs or media types used. This format is based on XML and extends the Schema for SIP User Agent Profile Data Sets. It is capable of expressing the media properties of a SIP session and can be used to summarize a Hilt, et al. Expires April 24, 2007 [Page 1] Internet-Draft Media Policy Dataset October 2006 SIP session or to formulate policies for a SIP session. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. The 'stream-label' Attribute . . . . . . . . . . . . . . . 6 5.2. The 'media-type' Attribute . . . . . . . . . . . . . . . . 6 6. Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. The Element . . . . . . . . . . . . . . . 6 6.2. The Element . . . . . . . . . . . . . . . . 7 6.3. The Element . . . . . . . . . . . . . . . . . . 7 6.3.1. The Element . . . . . . . . . . . . . . . . . 8 6.3.2. The Element . . . . . . . . . . . . . . . . 8 6.3.3. The Element . . . . . . . . . . . . . . . . . . 8 6.3.4. The Element . . . . . . . . . . . . . . . . 8 6.3.5. The Element . . . . . . . . . . . . . . 8 6.4. The Element . . . . . . . . . . . . . . . . 9 6.4.1. The Element . . . . . . . . . . . . . . . 9 6.5. The Element . . . . . . . . . . . . . . . . . . . 9 6.5.1. The Element . . . . . . . . . . . . . . . . . 10 6.6. The Element . . . . . . . . . . . . 11 6.6.1. The Element . . . . . . . . 12 6.6.2. The Element . . . . . . . . . . . 12 6.6.3. The Element . . . . . . . . . . 13 6.6.4. The Element . . . . . . . . . . 13 6.7. The Element . . . . . . . . . . . . . . . 13 6.8. The Element . . . . . . . . . . . . . . . . . . 14 6.9. The Element . . . . . . . . . . . . . . . . 14 6.10. The Element . . . . . . . . . . . . . . . . . . 14 6.10.1. The Element . . . . . . . . . . . . . . . . . 15 6.11. Other Elements . . . . . . . . . . . . . . . . . . . . . . 15 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Media Policy . . . . . . . . . . . . . . . . . . . . . . . 16 7.2. Session Information . . . . . . . . . . . . . . . . . . . 17 7.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 17 7.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 19 7.2.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 20 8. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10.1. MIME Registration for application/session-policy+xml . . . 26 10.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:mediadataset . . . . . . . . . . . 27 Hilt, et al. Expires April 24, 2007 [Page 2] Internet-Draft Media Policy Dataset October 2006 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.1. Normative References . . . . . . . . . . . . . . . . . . . 28 11.2. Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 31 Hilt, et al. Expires April 24, 2007 [Page 3] Internet-Draft Media Policy Dataset October 2006 1. Introduction The Framework for Session Initiation Protocol (SIP) [18] User Agent Profile Delivery [16] and the Framework for SIP Session Policies [15] define mechanisms to convey session policies and configuration information from a network server to a user agent. An important part of this information are properties that define media-related aspects of SIP sessions. These properties include, for example, codecs and media-types to be used, media-intermediaries to be traversed or the maximum bandwidth available in a session. This draft defines a document format for media properties of SIP sessions, the Media Policy Dataset Format (MPDF). This format can be used in two ways: first, it can be used to summarize the properties of a given SIP session. In this case, an MPDF document is created based on the session descriptions for this session (i.e. the offer and the answer). Second, the MPDF format can be used to express configuration information and policies for a session. In this usage, an MPDF document describes properties that can be used in a SIP session. The MPDF format is based on XML [14] and extends the Schema for SIP User Agent Profile Data Sets [12] by specifying a data set for media properties. The format also satisfies the requirements of a minimal set of media-level session policy elements as described in [17]. It can be extended through the XML extension mechanisms if additional media properties are needed. The two types of MPDF documents, session information and session policy documents, share the same set of XML elements to describe session properties. However, session information and session policy documents use different root elements: for session information documents and for session policy documents. This enables the recipient of a document to determine the specific document type. Also, some XML elements can only appear inside one or the other root element since they are only defined for one of the usages. A MPDF document MUST be well-formed and MUST be valid according to schemas, including extension schemas, available to the validator and applicable to the XML document. MPDF documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. A user agent may receive multiple MPDF policy documents from different sources. These documents need to be merged into a single document the user agent can work with. General rules for merging MPDF policy documents are described in [12]. Specific merging rules for each of the MPDF policy elements are described below. Hilt, et al. Expires April 24, 2007 [Page 4] Internet-Draft Media Policy Dataset October 2006 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. Namespace This specification makes use of XML namespaces [4]. The namespace URIs for schemas defined in this specification are URNs [7], using the namespace identifier 'ietf' defined by [8] and extended by [5]. The namespace URN for the MPDF schema is: urn:ietf:params:xml:ns:mediadataset The MIME type for the Media Policy Dataset Format is: application/session-policy+xml 4. Extensibility The MPDF format is an extension of the Schema for SIP User Agent Profile Data Sets [12]. Elements from the MPDF namespace can be used in conjunction with elements from other extensions of this schema. The MPDF format itself can also be extended using XML extension mechanisms. In particular, elements from different XML namespaces MAY be present within a MPDF document for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. 5. Attributes The following attributes provide common functionalities, which are generally useful for media properties: o Per-stream properties: 'stream-label' attribute o Media-type specific properties: 'media-type' attribute These attributes are defined in addition to the attributes inherited from the Profile Data Set Schema [12]: Hilt, et al. Expires April 24, 2007 [Page 5] Internet-Draft Media Policy Dataset October 2006 o Property Access Control: 'visibility' attribute o Policies: 'policy' and 'excluded-policy' attribute o Unidirectional Properties: 'direction' attribute o Preferences: 'q' attribute The use of these attributes is defined individually for each element in the XML format below. 5.1. The 'stream-label' Attribute Some properties only apply to a specific media stream. The stream to which a property applies MUST be identifiable through a label [6]. Per-stream properties can be expressed by adding a 'stream-label' attribute to the respective element. Such a property only applies to the identified stream. If there is no stream with this label, the element must be ignored. Per-stream properties require that the labels of media streams are known to the creator of a document (i.e. the profile delivery/policy server). These labels are part of the session description. 5.2. The 'media-type' Attribute Some properties only apply to streams of a certain media type. For example, a property may only apply to audio streams. Media-type specific properties can be defined by adding a 'media-type' attribute to the respective element. Such a property only applies to media streams of that type. The value of the 'media-type' attribute MUST be the name of a IANA registered media type (see [3]), such as 'audio', 'video', 'text', or 'application'. 6. Elements The following elements are defined for the MPDF format. 6.1. The Element The element describes a policy for a SIP session. I.e. the contents of this element specify which properties are allowed or disallowed in a SIP session. Documents containing elements are typically sent from a policy server to a UA. The MAY occur multiple times inside a [12] element. Hilt, et al. Expires April 24, 2007 [Page 6] Internet-Draft Media Policy Dataset October 2006 The element MAY contain one optional element and multiple (including zero) , , , , , and elements as well as elements from other namespaces. 6.2. The Element The element summarizes the properties of a specific SIP session. This element is typically created based on a session description and reflects the properties that are describe in this session description, for example, the codecs and media types used. Documents containing elements are typically sent from a UA to a policy server. The MAY occur multiple times inside a [12] element. The element MAY contain one optional and element and multiple (including zero) , , and elements as well as elements from other namespaces. OPEN ISSUE: need to determine which elements are needed in the element (e.g. are the , , elements needed. Is a media encryption key element needed). 6.3. The Element The element provides context information about the MPDF document. The element MAY contain multiple and an element. If used in a element, the element MAY also contain a element. If used in a element, the element MAY also contain a element. Merging rule: the element is not subject to merging. Information in the context element may be used to assist the user if a conflict occurs during the merging process. Hilt, et al. Expires April 24, 2007 [Page 7] Internet-Draft Media Policy Dataset October 2006 6.3.1. The Element The element contains a URI that identifies the domain which has issued this policy. The element is optional and MAY occur only once inside a element. The element is only defined inside a element. 6.3.2. The Element The element contains a contact address (e.g. a SIP URI or email address) under which the issuer of this document can be reached. The element is optional and MAY occur multiple times inside a element. 6.3.3. The Element The element provides a short textual description of the policy that should be intelligible to the human user. The element is optional and MAY occur only once inside a element. 6.3.4. The Element The element contains the call-ID of a session. If used in a element, all properties defined in this container MUST only be applied to the identified session. If used in a element, the contains the call ID of the session that is summarized in this document. 6.3.5. The Element The element identifies the request-URI the dialog initiating request of a session is sent to. The element is only defined inside a element. Hilt, et al. Expires April 24, 2007 [Page 8] Internet-Draft Media Policy Dataset October 2006 6.4. The Element The element describes the usage of media types (e.g. audio, video) in a session. If used in a element, it defines the media types that can be used and those that must not be used in a session. If used in a element, it describes the media types that appear in a session description. This element MAY have the following attribute (see Section 5): direction. If used in a element, this element MAY have the following additional attributes (see Section 5): visibility, excluded-policy. The 'excluded-policy' attribute specifies the default policy for all media types that are not listed inside this element. Multiple elements MAY only be present in or element if each element applies to a different set of streams (e.g. one for incoming and one for outgoing streams). The MUST contain one or more elements. Merging rule: containers are merged using the "Multiple Enumerated Value Merging Algorithm" defined in [12]. 6.4.1. The Element The element specifies a media type. The value of this element MUST be the name of a IANA registered media type (see [3]), such as 'audio', 'video', 'text', or 'application'. This element MAY have the following attribute (see Section 5): q. If used in a element, this element MAY have the following additional attribute (see Section 5): policy. Media types that have the policy 'allowed' MAY be used and media types with the policy 'disallowed' MUST NOT be used. 6.5. The Element The element describes the usage of codecs in a session. If used in a element, it defines the codecs that may be used or must not be used in a session. A policy MUST allow the use of at least one codec per media type. If used in a element, it describes the codecs that appear in a session description. Hilt, et al. Expires April 24, 2007 [Page 9] Internet-Draft Media Policy Dataset October 2006 This element MAY have the following attributes (see Section 5): direction, stream-label. If used in a element, this element MAY have the following additional attributes (see Section 5): visibility, excluded-policy. The 'excluded-policy' attribute specifies the default policy for all codecs that are not listed inside this element. Multiple elements MAY only be present in or element if each element applies to a different set of streams (e.g. one for incoming and one for outgoing streams). The element MUST contain one or more elements. Merging rule: containers are merged using the "Multiple Enumerated Value Merging Algorithm" defined in [12]. 6.5.1. The Element The element specifies a codec. The content of this element MUST be a registered MIME type [2] using media-type and subtype (e.g. audio/PCMA or video/H263) and possibly additional registered MIME type parameters. This element MAY have the following attribute (see Section 5): q. If used in a element, this element MAY have the following additional attribute (see Section 5): policy. Codecs that have the policy 'allowed' MAY be used and codecs with the policy 'disallowed' MUST NOT be used. The element MUST contain one element and MAY contain multiple optional elements. 6.5.1.1. The Element The element identifies a codec. The value of this element MUST be a combination of a registered MIME media-type and subtype [2] separated by a "/" (e.g. audio/PCMA, audio/G726-16, video/H263). 6.5.1.2. The Element The element may be needed for some codecs to identify a particular encoding or profile. The value of this element MUST be a name-value pair containing the name and the value of a registered MIME type parameter for the codec [2]. The name and value Hilt, et al. Expires April 24, 2007 [Page 10] Internet-Draft Media Policy Dataset October 2006 are separated by a "=". For example, the parameter "profile=0" can be used to specify a specific profile for the codec "video/ H263-2000". 6.6. The Element The element expresses a policy for routing a media stream through a media intermediary. The purpose of the element is to tell the UA to send a media stream through one (or a chain of) media intermediaries. Instead of sending the media directly to its final destination, the UA instead specifies a source route, which touches each intermediary and then reaches the final recipient. If there are N hops, including the final recipient, there needs to be a way for the media stream to specify N destinations. The element is only defined in a element. The element is a container that lists all media intermediaries to be traversed. Media intermediaries should be traversed in the order in which they appear in this list. The topmost entry should be traversed first, the last entry should be traversed last. Different types of intermediaries exist. These intermediaries are not necessarily interoperable and it may not be possible to chain them in an arbitrary order. A element SHOULD therefore only contain intermediary elements of the same type. This element may have the following attributes (see Section 5): visibility, direction, stream-label. Multiple elements in a element MAY only be present if each element applies to a different set of streams (e.g. one element for incoming and one for outgoing streams). The element MUST contain one or more of the following elements (all of the same type): , , , and . Merging rule: the intermediaries defined in all policies are traversed. In general, local intermediaries should be traversed before remote intermediaries. During the merging process, element values from different servers are ordered using the "Closest Value First Merging Algorithm" [12]. The intermediaries should be traversed in this order. Hilt, et al. Expires April 24, 2007 [Page 11] Internet-Draft Media Policy Dataset October 2006 Note: it is not intended that the element replaces connectivity discovery mechanisms such as ICE. Instead of finding media relays that provide connectivity, this element defines a policy for media intermediaries that should be traversed. The set of intermediaries defined in the element and the ones discovered through ICE may overlap but don't have to. 6.6.1. The Element A configured intermediary relies on configured forwarding rules. The user agent simply sends media to the first media intermediary listed. It can assume that this media intermediary has been configured with a forwarding rule for the media stream and knows where to forward the packets to. The configuration of forwarding rules in the intermediary must be done through other means. The element is optional and MAY occur multiple times inside a element. The element MUST contain one element and MAY contain multiple optional elements. 6.6.1.1. The Element The element contains a URI that identifies the IP address and port number of a media intermediary. The UA uses this URI to send its media streams to the intermediary. If a protocol uses multiple subsequent ports (e.g. RTP), the lowest port number SHOULD be included in the URI. All additional port numbers SHOULD be identified in elements. 6.6.1.2. The Element If a protocol uses multiple subsequent ports (e.g. RTP), the lowest port number SHOULD be included in the element. All additional port numbers SHOULD be identified in elements. 6.6.2. The Element The TURN [13] protocol provides a mechanism for inserting a relay into the media path. Although the main purpose of TURN is NAT traversal, it is possible for a TURN relay to perform other media intermediary functionalities. The user agent establishes a binding on the TURN server and uses this binding to transmit and receive media. The element MUST contain one element Hilt, et al. Expires April 24, 2007 [Page 12] Internet-Draft Media Policy Dataset October 2006 and MAY contain multiple optional elements and one optional element. 6.6.2.1. The Element The element contains the shared secret needed to authenticate at the TURN server. 6.6.3. The Element For these intermediaries, IP-in-IP tunneling [11] is used to specify the hops of media intermediary traversal. The ultimate destination is specified in the destination IP address of the innermost packet. Each subsequent hop results in another encapsulation, with the destination of that hop in the destination IP address of the packet. The element MUST contain one element and MAY contain multiple optional elements. 6.6.4. The Element IP provides a loose routing mechanism that allows the sender of an IP datagram to specify a set of IP addresses that are to be visited on the way before reaching the final destination. The element MUST contain one element and MAY contain multiple optional elements. 6.7. The Element The element contains the maximum bandwidth in kilobits per second an entity can use for its media streams. If used in a element, this is the maximum media bandwidth a UA can count on. If used in a element, this is the maximum bandwidth a UA is planning on using for media streams. This element MAY have the following attribute (see Section 5): direction, media-type. If used in a element, this element MAY have the following additional attribute (see Section 5): visibility. If the element occurs multiple times in a or element, each instance MUST apply to different media streams (i.e. one element for outgoing and one for incoming streams). Hilt, et al. Expires April 24, 2007 [Page 13] Internet-Draft Media Policy Dataset October 2006 Merging rule: the lowest max-bandwidth value is used. 6.8. The Element The element contains an Differentiated Services Codepoint (DSCP) [10] value that should be used to populate the IP DS field of media packets. The contains an integer value that represents a 6 bit field and therefore ranges from 0 to 63. The element is only defined in a element. This element may have the following attributes (see Section 5): visibility, direction, stream-label, media-type. The element is optional and MAY occur multiple times inside a element. If the element occurs multiple times in a element, each instance MUST apply to a different media stream (i.e. one element for audio and one for video streams). Merging rule: the domain that is first traversed by the media stream has precedence and its DSCP value is used. During the merging process, element values from different servers are ordered using the "Closest Value First Merging Algorithm" [12]. The DSCP value from the closest server is used. 6.9. The Element Domains often require that a user agent only uses ports in a certain range for media streams. The element defines a policy for the ports a user agent can use for media. The value of this element consists of a start port and an end port separated by a "-". The start/end port is the first/last port that can be used. The element is only defined in a element. This element may have the following attributes (see Section 5): visibility. Merging rule: the domain that is first traversed by the media stream has precedence and its local ports value is used. During the merging process, element values from different servers are ordered using the "Closest Value First Merging Algorithm" [12]. The value from the closest server is used. 6.10. The Element The element describes the media streams that are used in a session. It contains multiple elements, which each represents one media stream used in the session. The Hilt, et al. Expires April 24, 2007 [Page 14] Internet-Draft Media Policy Dataset October 2006 element is only defined in a element. The element MUST contain one or more elements. 6.10.1. The Element The element describes a media stream. It contains the media type and media URIs for of this stream. A URI consists of the address and a port number contained in a session description for this stream. A UA that generates a element MUST insert the address/port found in the local session description for this media stream into the local-uri element. It MUST insert the address/port of the remote session description into the remote URI, if this address/port is available to the UA. If not, the UA generates a stream element that only contains the local-URI. This element may have the following attributes (see Section 5): direction, stream-label. The element MUST contain one (see Section 6.4.1) and one element and MAY contain one optional element. 6.10.1.1. The Element The element contains a URI that identifies the IP address and port number of the media stream in the local session description. The address part of this URI is contained in the c= element of the local SDP description. The port number part of the URI is contained in the m= element of the stream. 6.10.1.2. The Element The element is structured exactly as the element. However, it contains a URI that identifies the IP address and port number of the described media stream in the remote session description. 6.11. Other Elements A number of additional elements have been proposed for a policy language. These elements are deemed to be outside the scope of this media policy format. However, they may be defined in extensions of MPDF or other profile data sets. Hilt, et al. Expires April 24, 2007 [Page 15] Internet-Draft Media Policy Dataset October 2006 o maximum number of streams o maximum number of sessions o maximum number of streams per session o maximum bandwidth per session o maximum bandwidth per stream o external address and port o media transport protocol o outbound proxy o SIP methods o SIP option tags o SIP transport protocol o body disposition o body format o body encryption 7. Example 7.1. Media Policy The following example describes a policy that allows the use of audio and video and prohibits the use of other media types. It allows the use of any codec except G.723 and G.729. The policy also inserts a media intermediary into outgoing media streams using IP-in-IP tunneling. Hilt, et al. Expires April 24, 2007 [Page 16] Internet-Draft Media Policy Dataset October 2006 example.com sip:policy_manager@example.com Access network policies audio video audio/G729 audio/G723 192.0.2.0:6000 6001 7.2. Session Information The following examples contain session descriptions and the MPDF documents that summarize these sessions. Examples 1 and 3 are based on one session description, example 2 is based on two session descriptions (i.e. the offer and answer). 7.2.1. Example 1 Local SDP session description (remote description unknown): v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 49562 RTP/AVP 0 1 3 a=rtpmap:0 PCMU/8000 a=rtpmap:1 1016/8000 a=rtpmap:3 GSM/8000 Hilt, et al. Expires April 24, 2007 [Page 17] Internet-Draft Media Policy Dataset October 2006 m=video 51234 RTP/AVP 31 34 a=rtpmap:31 H261/90000 a=rtpmap:34 H263/90000 MPDF document: sip:alice@atlanta.com session information audio video audio/PCMU audio/1016 audio/GSM video/H261 video/H263 audio host.anywhere.com:49562 video host.anywhere.com:51234 Hilt, et al. Expires April 24, 2007 [Page 18] Internet-Draft Media Policy Dataset October 2006 7.2.2. Example 2 Local SDP session description: v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 49562 RTP/AVP 0 1 3 a=rtpmap:0 PCMU/8000 a=rtpmap:1 1016/8000 a=rtpmap:3 GSM/8000 m=video 51234 RTP/AVP 31 34 a=rtpmap:31 H261/90000 a=rtpmap:34 H263/90000 Remote SDP session description: v=0 o=bob 2890844730 2890844730 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 52123 RTP/AVP 0 3 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 m=video 50286 RTP/AVP 31 a=rtpmap:31 H261/90000 MPDF document: sip:alice@atlanta.com session information audio video audio/PCMU audio/GSM Hilt, et al. Expires April 24, 2007 [Page 19] Internet-Draft Media Policy Dataset October 2006 video/H261 audio host.anywhere.com:49562 host.example.com:52123 video host.anywhere.com:51234 host.example.com:50286 7.2.3. Example 3 Local SDP session description (remote description unknown): v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 MPDF document: sip:alice@atlanta.com session information audio video audio/PCMU Hilt, et al. Expires April 24, 2007 [Page 20] Internet-Draft Media Policy Dataset October 2006 video/H261 video/MPV audio host.anywhere.com:49170 video host.anywhere.com:51372 video host.anywhere.com:53000 8. Schema Definition Note: the schema definition still reflects the -01 version of this draft. Hilt, et al. Expires April 24, 2007 [Page 21] Internet-Draft Media Policy Dataset October 2006 Hilt, et al. Expires April 24, 2007 [Page 22] Internet-Draft Media Policy Dataset October 2006 Hilt, et al. Expires April 24, 2007 [Page 23] Internet-Draft Media Policy Dataset October 2006 Hilt, et al. Expires April 24, 2007 [Page 24] Internet-Draft Media Policy Dataset October 2006 Hilt, et al. Expires April 24, 2007 [Page 25] Internet-Draft Media Policy Dataset October 2006 9. 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. 10. IANA Considerations This document registers a new MIME type, application/ session-policy+xml, and registers a new XML namespace. 10.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 [9]. Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [9]. Security considerations: See Section 10 of RFC 3023 [9] and Section 9 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 April 24, 2007 [Page 26] Internet-Draft Media Policy Dataset October 2006 Personal and email address for further information: Volker Hilt, Intended usage: COMMON Author/Change controller: The IETF. 10.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:mediadataset This section registers a new XML namespace, as per the guidelines in [5] URI: The URI for this namespace is urn:ietf:params:xml:ns:mediadataset. Registrant Contact: IETF, SIPPING working group, , Volker Hilt, XML: BEGIN Session Policy Namespace

Namespace for Session Policy Information

urn:ietf:params:xml:ns:mediadataset

See RFCXXXX.

END Appendix A. Acknowledgements Many thanks to Allison Mankin, Dan Petrie and Martin Dolly for the discussions and suggestions. Many thanks to Roni Even and Mary Barnes for reviewing the draft and providing feedback. Hilt, et al. Expires April 24, 2007 [Page 27] Internet-Draft Media Policy Dataset October 2006 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003. [3] Handley, M., "SDP: Session Description Protocol", draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. [4] Layman, A., Hollander, D., and T. Bray, "Namespaces in XML", World Wide Web Consortium Recommendation REC-xml-names- 19990114, January 1999, . [5] Mealling, M., "The IETF XML Registry", draft-mealling-iana-xmlns-registry-05 (work in progress), June 2003. [6] Levin, O. and G. Camarillo, "The SDP (Session Description Protocol) Label Attribute", draft-ietf-mmusic-sdp-media-label-01 (work in progress), January 2005. [7] Moats, R., "URN Syntax", RFC 2141, May 1997. [8] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [9] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [10] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [11] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [12] Petrie, D., Lawrence, S., Dolly, M., and V. Hilt, "A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Data Sets", draft-petrie-sipping-profile-datasets-03 (work in progress), October 2005. [13] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal Hilt, et al. Expires April 24, 2007 [Page 28] Internet-Draft Media Policy Dataset October 2006 Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in progress), October 2006. [14] Yergeau, F., Maler, E., Paoli, J., Bray, T., and C. Sperberg- McQueen, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium Recommendation REC-xml- 20040204, February 2004, . 11.2. Informative References [15] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for Session Initiation Protocol (SIP) Session Policies", draft-ietf-sip-session-policy-framework-00 (work in progress), October 2006. [16] Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-09 (work in progress), October 2006. [17] Rosenberg, J., "Requirements for Session Policy for the Session Initiation Protocol (SIP)", draft-ietf-sipping-session-policy-req-02 (work in progress), July 2004. [18] 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 April 24, 2007 [Page 29] Internet-Draft Media Policy Dataset October 2006 Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 USA Email: jdrosen@cisco.com Hilt, et al. Expires April 24, 2007 [Page 30] Internet-Draft Media Policy Dataset October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Hilt, et al. Expires April 24, 2007 [Page 31]