SIPPING Working Group V. Hilt
Internet-Draft Bell Labs/Lucent Technologies
Expires: October 6, 2006 G. Camarillo
Ericsson
J. Rosenberg
Cisco Systems
April 4, 2006
A User Agent Profile Data Set for Media Policy
draft-ietf-sipping-media-policy-dataset-01
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 October 6, 2006.
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 to be used. This format can used to define media
properties in SIP user agent profile data sets and SIP session
policies. It extends the Schema for SIP User Agent Profile Data
Hilt, et al. Expires October 6, 2006 [Page 1]
Internet-Draft Media Policy Dataset April 2006
Sets.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. The 'stream-label' Attribute . . . . . . . . . . . . . . . 4
5.2. The 'media-type' Attribute . . . . . . . . . . . . . . . . 5
6. Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. The <session-policy> Element . . . . . . . . . . . . . . . 5
6.2. The <context> Element . . . . . . . . . . . . . . . . . . 5
6.2.1. The <domain> Element . . . . . . . . . . . . . . . . . 6
6.2.2. The <contact> Element . . . . . . . . . . . . . . . . 6
6.2.3. The <info> Element . . . . . . . . . . . . . . . . . . 6
6.3. The <media-types> Element . . . . . . . . . . . . . . . . 6
6.3.1. The <media-type> Element . . . . . . . . . . . . . . . 7
6.4. The <codecs> Element . . . . . . . . . . . . . . . . . . . 7
6.4.1. The <codec> Element . . . . . . . . . . . . . . . . . 7
6.5. The <media-intermediaries> Element . . . . . . . . . . . . 8
6.5.1. The <configured-intermediary> Element . . . . . . . . 9
6.5.2. The <turn-intermediary> Element . . . . . . . . . . . 10
6.5.3. The <ipinip-intermediary> Element . . . . . . . . . . 11
6.5.4. The <iploose-intermediary> Element . . . . . . . . . . 11
6.6. The <max-bandwidth> Element . . . . . . . . . . . . . . . 11
6.7. The <qos-dscp> Element . . . . . . . . . . . . . . . . . . 11
6.8. The <local-ports> Element . . . . . . . . . . . . . . . . 12
6.9. Other Elements . . . . . . . . . . . . . . . . . . . . . . 12
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10.1. MIME Registration for application/session-policy+xml . . . 18
10.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:mediadataset . . . . . . . . . . . 19
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
Hilt, et al. Expires October 6, 2006 [Page 2]
Internet-Draft Media Policy Dataset April 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 to define configuration data sets and session policies. 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.
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 documents from different
sources. These documents need to merged into a single document the
user agent can work with. General rules for merging MPDF documents
are described in [12]. Specific merging rules for each of the MPDF
elements are described below.
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:
Hilt, et al. Expires October 6, 2006 [Page 3]
Internet-Draft Media Policy Dataset April 2006
urn:ietf:params:xml:ns:mediadataset
The MIME type for the Media Policy Dataset Format is:
application/session-policy+xml
OPEN ISSUE: do we need a separate MIME type might or is the MIME
type of the Schema for SIP User Agent Profile Data Sets
sufficient.
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]:
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 to must be identifiable through a label [6].
Per-stream properties can be expressed by adding a 'stream-label'
Hilt, et al. Expires October 6, 2006 [Page 4]
Internet-Draft Media Policy Dataset April 2006
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, for example, 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 <session-policy> Element
The <session-policy> element is a container for media policy
elements. It MAY occur multiple times inside a <property_set> [12]
element.
The <session-policy> element MAY contain one optional <context>
element and multiple (including zero) <media-types>, <codecs>,
<media-intermediaries>, <max-bandwidth>, <qos-dscp>, and <local-
ports> elements as well as elements from other namespaces.
OPEN ISSUE: the <session-policy> is a container for policies.
This may not be needed if policy element are directly placed in a
<property_set> element. In this case, the <context> element needs
to be a child of the <property_set> element.
6.2. The <context> Element
The <context> element provides context information about this media
policy.
The <context> element is optional in a <session-policy> element. It
Hilt, et al. Expires October 6, 2006 [Page 5]
Internet-Draft Media Policy Dataset April 2006
MAY contain a <domain>, multiple <contact> and an <info> element.
Merging rule: the <context> 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.
6.2.1. The <domain> Element
The <domain> element contains a URI that identifies the domain which
has issued this policy.
The <domain> element is optional and MAY occur only once inside a
<context> element.
6.2.2. The <contact> Element
The <contact> element contains a contact address (e.g. a SIP URI or
email address) under which the issuer of this policy can be reached.
The <contact> element is optional and MAY occur multiple times inside
a <context> element.
6.2.3. The <info> Element
The <info> element provides a short textual description of the policy
that should be intelligible to the human user.
The <info> element is optional and MAY occur only once inside a
<context> element.
6.3. The <media-types> Element
The <media-types> element expresses a policy for the use of media
types (e.g. audio, video). It defines the media types that must be
used, may be used, and must not be used in a session.
This element may have the following attributes (see Section 5):
visibility, excluded-policy, direction. The 'excluded-policy'
attribute specifies the default policy for all media types that are
not listed inside this element.
The <media-types> element is optional in a <session-policy> element
and MAY occur multiple times. Multiple <media-types> elements MAY
only be present if each element applies to a different set of streams
(e.g. one <media-types> for incoming and one for outgoing streams).
The <media-types> MUST contain one or more <media-type> elements.
Hilt, et al. Expires October 6, 2006 [Page 6]
Internet-Draft Media Policy Dataset April 2006
Merging rule: <media-types> containers are merged using the
"Multiple Enumerated Value Merging Algorithm" defined in [12].
6.3.1. The <media-type> Element
The <media-type> element defines a policy for the use of the media
type identified by this element. 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 attributes (see Section 5):
policy, q. Media types that have the policy 'mandatory' MUST be used
in a session, media types with the policy 'allowed' MAY be used and
media types with the policy 'disallowed' MUST NOT be used.
The <media-type> element is mandatory and MAY occur multiple times
inside a <media-types> element.
6.4. The <codecs> Element
The <codecs> element expresses a policy for the use of codecs. A
policy can define that a codec must be used, may be used, or must not
be used in a session. A policy MUST allow the use of at least one
codec and MUST NOT define more than one mandatory codec for a media
type.
This element may have the following attributes (see Section 5):
visibility, excluded-policy, direction, stream-label. The 'excluded-
policy' attribute specifies the default policy for all codecs that
are not listed inside this element.
The <codecs> element is optional in a <session-policy> element and
MAY occur multiple times. Multiple <codecs> elements MAY only be
present if each element applies to a different set of streams (e.g.
one <codecs> for incoming and one for outgoing streams). The
<codecs> element MUST contain one or more <codec> elements.
Merging rule: <codecs> containers are merged using the "Multiple
Enumerated Value Merging Algorithm" defined in [12].
6.4.1. The <codec> Element
The <codec> element defines a policy for the use of the codec
identified by this element. A codec is identified based on a
registered MIME type [2] using media-type and subtype (e.g. audio/
PCMA or video/H263) and possibly additional registered MIME type
parameters.
Hilt, et al. Expires October 6, 2006 [Page 7]
Internet-Draft Media Policy Dataset April 2006
This element may have the following attributes (see Section 5):
policy, q. Codecs that have the policy 'mandatory' MUST be used in a
session, codecs with the policy 'allowed' MAY be used and codecs with
the policy 'disallowed' MUST NOT be used.
The <codec> element is mandatory and MAY occur multiple times inside
a <codecs> element. The <codec> element MUST contain one <mime-type>
element and MAY contain multiple optional <mime-parameter> elements.
6.4.1.1. The <mime-type> Element
The <mime-type> 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).
The <mime-type> element occurs exactly once inside a <codec> element.
6.4.1.2. The <mime-parameter> Element
The <mime-parameter> 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
are separated by a "=". For example, the parameter "profile=0" can
be used to specify a specific profile for the codec "video/
H263-2000".
The <mime-parameter> element is optional and MAY occur multiple times
inside a <codec> element.
6.5. The <media-intermediaries> Element
The <media-intermediaries> element expresses a policy for routing a
media stream through a media intermediary. The purpose of the
<media-intermediaries> 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 <media-intermediaries> 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.
Hilt, et al. Expires October 6, 2006 [Page 8]
Internet-Draft Media Policy Dataset April 2006
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 <media-intermediaries> element SHOULD
therefore only contain intermediary elements of the same type.
This element may have the following attributes (see Section 5):
visibility, policy, direction, stream-label.
The <media-intermediaries> element is optional in a <session-policy>
element and MAY occur multiple times. Multiple <media-
intermediaries> elements MAY only be present if each element applies
to a different set of streams (e.g. one <media-intermediaries>
element for incoming and one for outgoing streams). The <media-
intermediaries> element MUST contain one or more of the following
elements (all of the same type): <configured-intermediary>, <turn-
intermediary>, <ipinip-intermediary>, and <iploose-intermediary>.
Merging rule: the intermediaries defined in all policies are
traversed. In general, local intermediaries should be traversed
before remote intermediaries. During the merging process, <media-
intermediaries> element values from different servers are ordered
using the "Closest Value First Merging Algorithm" [12]. The
intermediaries should be traversed in this order.
Note: it is not intended that the <media-intermediaries> 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 <media-
intermediaries> element and the ones discovered through ICE may
overlap but don't have to.
6.5.1. The <configured-intermediary> 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 <configured-intermediary> element is optional and MAY occur
multiple times inside a <media-intermediaries> element. The
<configured-intermediary> element MUST contain one <int-uri> element
and MAY contain multiple optional <int-addl-port> elements.
Hilt, et al. Expires October 6, 2006 [Page 9]
Internet-Draft Media Policy Dataset April 2006
6.5.1.1. The <int-uri> Element
The <int-uri> 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 <int-addl-port> elements.
The <int-uri> element occurs exactly once inside the following
elements: <configured-intermediary>, <turn-intermediary>, <ipinip-
intermediary>, and <iploose-intermediary>.
6.5.1.2. The <int-addl-port> Element
If a protocol uses multiple subsequent ports (e.g. RTP), the lowest
port number SHOULD be included in the <int-uri> element. All
additional port numbers SHOULD be identified in <int-addl-port>
elements.
The <int-addl-port> element is optional and MAY occur multiple times
inside the following elements: <configured-intermediary>, <turn-
intermediary>, <ipinip-intermediary>, and <iploose-intermediary>.
6.5.2. The <turn-intermediary> 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 <turn-intermediary> element is optional and MAY occur multiple
times inside a <media-intermediaries> element. The <turn-
intermediary> element MUST contain one <int-uri> element and MAY
contain multiple optional <int-addl-port> elements and one optional
<shared-secret> element.
6.5.2.1. The <shared-secret> Element
The <shared-secret> element contains the shared secret needed to
authenticate at the TURN server.
The <shared-secret> element is optional and MAY occur only once
inside the <turn-intermediary> element.
Hilt, et al. Expires October 6, 2006 [Page 10]
Internet-Draft Media Policy Dataset April 2006
6.5.3. The <ipinip-intermediary> 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 <ipinip-intermediary> element is optional and MAY occur multiple
times inside a <media-intermediaries> element. The <ipinip-
intermediary> element MUST contain one <int-uri> element and MAY
contain multiple optional <int-addl-port> elements.
6.5.4. The <iploose-intermediary> 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 <iploose-intermediary> element is optional and MAY occur multiple
times inside a <media-intermediaries> element. The <iploose-
intermediary> element MUST contain one <int-uri> element and MAY
contain multiple optional <int-addl-port> elements.
6.6. The <max-bandwidth> Element
The <max-bandwidth> element contains the maximum bandwidth in
kilobits per second an entity can use for its media streams.
This element may have the following attributes (see Section 5):
visibility, policy, direction, media-type.
The <max-bandwidth> element is optional and MAY occur multiple times
inside a <session-policy> element. If it occurs multiple times, each
instance MUST apply to different media streams (i.e. one <max-
bandwidth> element for outgoing and one for incoming streams).
Merging rule: the lowest max-bandwidth value is used.
6.7. The <qos-dscp> Element
The <qos-dscp> element contains an Differentiated Services Codepoint
(DSCP) [10] value that should be used to populate the IP DS field of
media packets. The <qos-dscp> contains an integer value that
represents a 6 bit field and therefore ranges from 0 to 63.
This element may have the following attributes (see Section 5):
visibility, policy, direction, stream-label, media-type.
Hilt, et al. Expires October 6, 2006 [Page 11]
Internet-Draft Media Policy Dataset April 2006
The <qos-dscp> element is optional and MAY occur multiple times
inside a <session-policy> element. If it occurs multiple times, each
instance MUST apply to a different media stream (i.e. one <qos-dscp>
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, <qos-dscp> 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.8. The <local-ports> Element
Domains often require that a user agent only uses ports in a certain
range for media streams. The <local-ports> 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.
This element may have the following attributes (see Section 5):
visibility.
The <local-ports> element is optional and MAY occur multiple times
inside a <session-policy> element.
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, <local-ports> element values from different
servers are ordered using the "Closest Value First Merging
Algorithm" [12]. The value from the closest server is used.
6.9. 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.
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
Hilt, et al. Expires October 6, 2006 [Page 12]
Internet-Draft Media Policy Dataset April 2006
o SIP methods
o SIP option tags
o SIP transport protocol
o body disposition
o body format
o body encryption
7. Example
The following example describes a policy that requires the use of
audio, allows the use of 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.
<property-set>
<session-policy>
<context>
<domain>example.com</domain>
<contact>sip:policy_manager@example.com</contact>
<info>Access network policies</info>
</context>
<media-types excluded-policy="disallow">
<media-type policy="mandatory">audio</media-type>
<media-type policy="allow">video</media-type>
</media-types>
<codecs excluded-policy="allow">
<codec policy="disallow">
<mime-type>audio/G729</mime-type>
</codec>
<codec policy="disallow">
<mime-type>audio/G723</mime-type>
</codec>
</codecs>
<media-intermediaries direction="sendonly" policy="mandatory">
<ipinip-intermediary>
<int-uri>192.0.2.0:6000</int-uri>
<int-addl-port>6001</int-addl-port>
</ipinip-intermediary>
</media-intermediaries>
</session-policy>
</property-set>
Hilt, et al. Expires October 6, 2006 [Page 13]
Internet-Draft Media Policy Dataset April 2006
8. Schema Definition
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:mediadataset"
xmlns:tns="urn:ietf:params:xml:ns:mediadataset"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:spds="http://sipfoundry.org/schema/profile-data-sets-00">
<xs:attributeGroup name="single_stream_attributes" >
<xs:attribute name="stream-label"
type="xs:string" use="optional"/>
</xs:attributeGroup>
<xs:attributeGroup name="media_type_attributes" >
<xs:attribute name="media-type"
type="xs:string" use="optional"/>
</xs:attributeGroup>
<xs:element name="session-policy">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:context"
minOccurs="0" maxOccurs="1"/>
<xs:element ref="tns:media-types"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:codecs"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:media-intermediaries"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:max-bandwidth"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:qos-dscp"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:local-ports"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="context">
<xs:complexType>
<xs:sequence>
<xs:element name="domain" type="xs:anyURI" minOccurs="0"
maxOccurs="1"/>
Hilt, et al. Expires October 6, 2006 [Page 14]
Internet-Draft Media Policy Dataset April 2006
<xs:element name="contact" type="xs:anyURI" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="info" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="media-types"
substitutionGroup="spds:setting_container">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:media-type"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:directional_setting_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="codecs"
substitutionGroup="spds:setting_container">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:codec"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:directional_setting_attributes" />
<xs:attributeGroup ref="tns:single_stream_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="media-intermediaries"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:configured-intermediary"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:turn-intermediary"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:ipinip-intermediary"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="tns:iploose-intermediary"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:directional_setting_attributes" />
<xs:attributeGroup ref="tns:single_stream_attributes" />
</xs:complexType>
</xs:element>
Hilt, et al. Expires October 6, 2006 [Page 15]
Internet-Draft Media Policy Dataset April 2006
<xs:element name="max-bandwidth"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:positiveInteger" />
</xs:simpleContent>
<xs:attributeGroup ref="spds:directional_setting_attributes" />
<xs:attributeGroup ref="tns:media_type_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="qos-dscp"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:simpleContent>
<xs:restriction base="xs:integer" >
<xs:minInclusive value="0" />
<xs:maxInclusive value="63" />
</xs:restriction>
</xs:simpleContent>
<xs:attributeGroup ref="spds:directional_setting_attributes" />
<xs:attributeGroup ref="tns:single_stream_attributes" />
<xs:attributeGroup ref="tns:media_type_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="local-ports"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:simpleContent>
<xs:restriction base="xs:string" />
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="media-type"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:simpleContent>
<xs:restriction base="xs:string" />
</xs:simpleContent>
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="codec"
substitutionGroup="spds:setting">
<xs:complexType>
Hilt, et al. Expires October 6, 2006 [Page 16]
Internet-Draft Media Policy Dataset April 2006
<xs:sequence>
<xs:element name="mime-type" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<xs:element name="mime-parameter" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="configured-intermediary"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:sequence>
<xs:element name="int-uri" type="xs:anyURI"
minOccurs="1" maxOccurs="1"/>
<xs:element name="int-addl-port"
type="xs:positiveInteger"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="turn-intermediary"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:sequence>
<xs:element name="int-uri" type="xs:anyURI"
minOccurs="1" maxOccurs="1"/>
<xs:element name="int-addl-port"
type="xs:positiveInteger"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="shared-secret" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="ipinip-intermediary"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:sequence>
<xs:element name="int-uri" type="xs:anyURI"
minOccurs="1" maxOccurs="1"/>
<xs:element name="int-addl-port"
type="xs:positiveInteger"
Hilt, et al. Expires October 6, 2006 [Page 17]
Internet-Draft Media Policy Dataset April 2006
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType>
</xs:element>
<xs:element name="iploose-intermediary"
substitutionGroup="spds:setting">
<xs:complexType>
<xs:sequence>
<xs:element name="int-uri" type="xs:anyURI"
minOccurs="1" maxOccurs="1"/>
<xs:element name="int-addl-port"
type="xs:positiveInteger"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="spds:multi_setting_attributes" />
</xs:complexType>
</xs:element>
</xs:schema>
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].
Hilt, et al. Expires October 6, 2006 [Page 18]
Internet-Draft Media Policy Dataset April 2006
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"
Personal and email address for further information: Volker Hilt,
<volkerh@bell-labs.com>
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, <sipping@ietf.org>,
Volker Hilt, <volkerh@bell-labs.com>
Hilt, et al. Expires October 6, 2006 [Page 19]
Internet-Draft Media Policy Dataset April 2006
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Session Policy Namespace</title>
</head>
<body>
<h1>Namespace for Session Policy Information</h1>
<h2>urn:ietf:params:xml:ns:mediadataset</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
Appendix A. Acknowledgements
Many thanks to Allison Mankin, Dan Petrie and Martin Dolly for the
great discussions and suggestions. Many thanks also to everyone who
contributed by providing feedback.
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] Hollander, D., Bray, T., and A. Layman, "Namespaces in XML",
W3C REC REC-xml-names-19990114, January 1999.
[5] Mealling, M., "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-05 (work in progress),
June 2003.
Hilt, et al. Expires October 6, 2006 [Page 20]
Internet-Draft Media Policy Dataset April 2006
[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., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-08 (work in progress),
September 2005.
[14] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E.
Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)",
W3C REC 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-sipping-session-policy-framework-00 (work in
progress), March 2006.
[16] Petrie, D., "A Framework for Session Initiation Protocol User
Agent Profile Delivery", draft-ietf-sipping-config-framework-08
(work in progress), March 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.
Hilt, et al. Expires October 6, 2006 [Page 21]
Internet-Draft Media Policy Dataset April 2006
[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.
Hilt, et al. Expires October 6, 2006 [Page 22]
Internet-Draft Media Policy Dataset April 2006
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
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
USA
Email: jdrosen@cisco.com
Hilt, et al. Expires October 6, 2006 [Page 23]
Internet-Draft Media Policy Dataset April 2006
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 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.
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 (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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hilt, et al. Expires October 6, 2006 [Page 24]
