One document matched: draft-ietf-sipping-media-policy-dataset-04.txt
Differences from draft-ietf-sipping-media-policy-dataset-03.txt
SIPPING Working Group V. Hilt
Internet-Draft Bell Labs/Alcatel-Lucent
Expires: November 20, 2007 G. Camarillo
Ericsson
J. Rosenberg
Cisco Systems
May 19, 2007
A User Agent Profile Data Set for Media Policy
draft-ietf-sipping-media-policy-dataset-04
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 November 20, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This specification defines a document format for the media properties
of Session Initiation Protocol (SIP) sessions. Examples for media
properties are the codecs or media types used in a session. This
document format is based on XML and extends the Schema for SIP User
Agent Profile Data Sets. It can be used to describe the properties
Hilt, et al. Expires November 20, 2007 [Page 1]
Internet-Draft Media Policy Dataset May 2007
of a specific SIP session or to define policies that are then applied
to different SIP sessions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Design Considerations . . . . . . . . . . . . . . . . . . . . 5
3.1. Namespace and MIME Type . . . . . . . . . . . . . . . . . 5
3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Inheritance from the Profile Data Set . . . . . . . . . . 6
4. Session Info Documents . . . . . . . . . . . . . . . . . . . . 6
4.1. The <session-info> Element . . . . . . . . . . . . . . . . 7
4.2. Mapping SDP to Session Info Documents . . . . . . . . . . 7
5. Session Policy Documents . . . . . . . . . . . . . . . . . . . 7
5.1. The <session-policy> Element . . . . . . . . . . . . . . . 8
6. Media Property Elements . . . . . . . . . . . . . . . . . . . 8
6.1. The <media-types> Element . . . . . . . . . . . . . . . . 8
6.1.1. The <media-type> Element . . . . . . . . . . . . . . . 9
6.2. The <codecs> Element . . . . . . . . . . . . . . . . . . . 9
6.2.1. The <codec> Element . . . . . . . . . . . . . . . . . 10
6.3. The <streams> Element . . . . . . . . . . . . . . . . . . 10
6.3.1. The <stream> Element . . . . . . . . . . . . . . . . . 11
6.4. The <max-bandwidth> Element . . . . . . . . . . . . . . . 11
6.5. The <max-session-bandwidth> Element . . . . . . . . . . . 12
6.6. The <max-stream-bandwidth> Element . . . . . . . . . . . . 12
6.7. The <media-intermediaries> Element . . . . . . . . . . . . 13
6.7.1. The <fixed-intermediary> Element . . . . . . . . . . . 14
6.7.2. The <turn-intermediary> Element . . . . . . . . . . . 14
6.8. The <qos-dscp> Element . . . . . . . . . . . . . . . . . . 15
6.9. The <local-ports> Element . . . . . . . . . . . . . . . . 15
6.10. The <context> Element . . . . . . . . . . . . . . . . . . 16
6.10.1. The <domain> Element . . . . . . . . . . . . . . . . . 16
6.10.2. The <contact> Element . . . . . . . . . . . . . . . . 16
6.10.3. The <info> Element . . . . . . . . . . . . . . . . . . 17
6.10.4. The <request-URI> Element . . . . . . . . . . . . . . 17
6.11. Other Session Properties . . . . . . . . . . . . . . . . . 17
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Session Policy Documents . . . . . . . . . . . . . . . . . 17
7.2. Session Information Documents . . . . . . . . . . . . . . 18
7.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 18
7.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 19
8. Relax NG Definition . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10.1. MIME Registration . . . . . . . . . . . . . . . . . . . . 29
10.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 30
Hilt, et al. Expires November 20, 2007 [Page 2]
Internet-Draft Media Policy Dataset May 2007
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34
Hilt, et al. Expires November 20, 2007 [Page 3]
Internet-Draft Media Policy Dataset May 2007
1. Introduction
The Framework for Session Initiation Protocol (SIP) [16] User Agent
Profile Delivery [15] and the Framework for SIP Session Policies [14]
define mechanisms to convey session policies and configuration
information from a network server to a user agent. An important
piece of the information conveyed to the user agent relates to the
media properties of the SIP sessions set up by the user agent.
Examples for these media properties are the codecs and media-types
used, the media-intermediaries to be traversed or the maximum
bandwidth available for media streams.
This specification 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 describe the
properties of a given SIP session (e.g. the media types and codecs
used). These MPDF documents are called session info documents and
they are usually created based on the session description of a
session. Second, the MPDF format can be used to define policies for
SIP sessions in a session policy document. A session policy document
defines properties (e.g. the media types) that can or can not be used
in a session, independent of a specific session description.
If used with the Framework for SIP Session Policies [14], session
info documents are used in conjunction with session-specific
policies. A session info document is created by a UA based on the
current session description and submitted to the policy server. The
policy server examines the session info document, modifies it if
necessary (e.g. by removing video streams if video is not permitted)
and returns the possibly modified session info document to the UA.
Session policy documents on the other hand are used to describe
session-independent policies that can be submitted to the UA
independent of a specific session.
The two types of MPDF documents, session information and session
policy documents, share the same set of XML elements to describe
session properties. Since the usage of these elements differs
between the two document types, they both use different root
elements: <session-info> is the root element for session information
documents and <session-policy> is the root element for session policy
documents. This enables the recipient of a document to determine the
document type and to correctly interpret the media properties
defined.
A user agent may receive multiple session policy documents from
different sources. These documents need to be merged into a single
document the user agent can work with. This document specifies rules
for merging each of the XML elements defined. It should be noted
Hilt, et al. Expires November 20, 2007 [Page 4]
Internet-Draft Media Policy Dataset May 2007
that these merging rules are part of the semantics of the XML
element. User agents implement the merging rules as part of
implementing the element semantics. As a consequence, it is not
possible to build an entity that can mechanically merge two session
policy documents without understanding the semantics of all elements
in the input documents. [11] describes common merging rules that are
referred to in this specification.
Merging is not needed for session information documents since they
are created by one source and describe a specific session.
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. Design Considerations
This section discusses design considerations for the Media Policy
Dataset Format.
3.1. Namespace and MIME Type
The MPDF format is based on XML [13]. 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.
MPDF makes use of XML namespaces [4]. The namespace URIs for schemas
defined in this specification are URNs [6], using the namespace
identifier 'ietf' defined by [7] 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/media-policy-dataset+xml
Hilt, et al. Expires November 20, 2007 [Page 5]
Internet-Draft Media Policy Dataset May 2007
3.2. Extensibility
The MPDF format extends the Schema for SIP User Agent Profile Data
Sets [11] by specifying a data set for media properties. 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 if additional media properties are needed. 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.
3.3. Inheritance from the Profile Data Set
The MPDF format inherits the following attributes from the Profile
Data Set Schema [11]:
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.
The MPDF format also uses merging algorithms that are defined in the
Profile Data Set Schema. The use of these algorithms is defined
individually for each element in the XML format below.
4. Session Info Documents
Session info documents describe key properties of a SIP session such
as the media streams used in the session. Session info documents are
typically created based on an SDP [3] session description or an SDP
offer/answer pair [9].
Session info documents can be used for session-specific policies
[14]. In this usage, a UA creates a session info document based on
its SDP description(s) and sends this document to the policy server.
The policy server modifies this document according to the policies
that apply to the described session and returns a version of the
session info document that is compliant to all policies. For
example, if video streams are not permissible under current policies
and the UA submits a session info document that contains a video
stream, the policy server will remove the video stream from the XML
markup and return the modified session info document to the UA.
Hilt, et al. Expires November 20, 2007 [Page 6]
Internet-Draft Media Policy Dataset May 2007
Session info documents use the <session-info> element.
4.1. The <session-info> Element
The <session-info> element describes the properties of a specific SIP
session. The <session-info> element MAY occur multiple times inside
a <property_set> [11] element.
The <session-info> element MAY contain one optional <streams>,
<context> and multiple (including zero) <max-bandwidth>, <max-
session-bandwidth>, <max-stream-bandwidth>, <media-intermediaries>
and <qos-dscp> elements as well as elements from other namespaces.
The MPDF elements are defined in Section 6.
4.2. Mapping SDP to Session Info Documents
If a UA has an SDP offer as well as an answer [9] and wants to create
a session info document, it MUST use the answer to fill in the
elements of the session info document except for the remote-host-port
and local-host-port elements, which are taken from the remote and
local session description respectively. The local session
description is the one created locally by the UA (i.e. the offer if
the UA has initiated the offer/answer exchange). The remote session
description is the one received from the remote UA.
The following rules describe the creation of session info documents
based on SDP description(s) for a few exemplary elements. Other
elements are created following the same principles.
A UA MUST create a separate <stream> element for each m= line in an
SDP description. It MUST insert the media type from the m= line into
a <media-type> element and MUST create a <codec> element for each
codec listed in the m= line.
The UA MUST create a <local-host-port> element for each stream using
the port taken from the m= line and the address from the
corresponding c= line of the local session description. It MUST
create a <remote-host-port> element using the port and address from
the m= and c= lines for the same stream taken from the remote session
description if this session description is available.
The mapping from a session info document to a SDP description follows
the same rules in the reverse direction.
5. Session Policy Documents
Session policy documents describe a policy for SIP sessions. Session
Hilt, et al. Expires November 20, 2007 [Page 7]
Internet-Draft Media Policy Dataset May 2007
policy documents are independent of a specific session description
and express general policies for SIP sessions. A session policy
document is used to determine if a SIP session is policy conformant
and to modify this session, if needed, according to the described
policies.
Session policy documents can be used to encode session-independent
policies [14]. In this usage, a policy server creates a session
policy document and passes this document to a UA. The UA applies the
policies defined to the SIP sessions it is establishing. For
example, a session policy document can contain an element that
prohibits the use of video. To set up a session that is compliant to
this policy, a UA does not include the media type video in its SDP
offer or answer.
Session policy documents use the <session-policy> element.
5.1. The <session-policy> Element
The <session-policy> element describes a policy that applies to SIP
sessions. The <session-policy> element MAY occur multiple times
inside a <property_set> [11] element.
The <session-policy> element MAY contain one optional <context> and
multiple (including zero) <media-types>, <codecs>, <max-bandwidth>,
<max-session-bandwidth>, <max-stream-bandwidth>, <media-
intermediaries>, <qos-dscp>, and <local-ports> elements as well as
elements from other namespaces. The MPDF elements are defined in
Section 6.
6. Media Property Elements
This section describes XML elements that are used in session info and
session policy documents to encode the media properties of SIP
sessions.
6.1. The <media-types> Element
The <media-types> element is a container that is used to define the
set of media types (e.g. audio, video) that can or cannot be used in
a session. A specific media type is included in the set by adding
the corresponding <media-type> element to this container.
The <media-types> element can only be used in session policy document
(i.e. inside the <session-policy> container).
This element MAY have the following attribute (see Section 3.3):
Hilt, et al. Expires November 20, 2007 [Page 8]
Internet-Draft Media Policy Dataset May 2007
direction, visibility, excluded-policy.
Multiple <media-types> elements MAY only be present in a container
element if each applies to a different set of streams (e.g. one
<media-types> element for incoming and one for outgoing streams).
The <media-types> element MUST contain one or more <media-type>
elements.
Merging of session-policy documents: <media-types> containers are
merged using the "Multiple Enumerated Value Merging Algorithm"
defined in [11].
6.1.1. The <media-type> Element
The <media-type> element identifies a specific 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 3.3): q.
If used inside a <session-policy> element, this element MAY have the
following additional attribute (see Section 3.3): policy. Media
types that have the policy 'allowed' MAY be used and media types with
the policy 'disallowed' MUST NOT be used.
6.2. The <codecs> Element
The <codecs> element is a container that is used to define the set of
codecs that may or may not be used in a session. A policy MUST allow
the use of at least one codec per media type. A specific codec is
included in the set by adding the corresponding <codec> element to
this container.
The <codecs> element can only be used in a session policy document
(i.e. inside the <session-policy> container).
This element MAY have the following attributes (see Section 3.3):
direction, visibility, excluded-policy.
Multiple <codecs> elements MAY only be present in a container element
if each applies to a different set of streams (e.g. one <codecs>
element for incoming and one for outgoing streams). The <codecs>
element MUST contain one or more <codec> elements.
Merging of session-policy documents: <codecs> containers are
merged using the "Multiple Enumerated Value Merging Algorithm"
defined in [11].
Hilt, et al. Expires November 20, 2007 [Page 9]
Internet-Draft Media Policy Dataset May 2007
6.2.1. The <codec> Element
The <codec> element identifies a specific 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 3.3): q.
If used inside a <session-policy> element, this element MAY have the
following additional attribute (see Section 3.3): policy. Codecs
that have the policy 'allowed' MAY be used and codecs with the policy
'disallowed' MUST NOT be used.
The <codec> element MUST contain one <mime-type> element and MAY
contain multiple optional <mime-parameter> elements.
6.2.1.1. The <mime-type> Element
The <mime-type> element contains a MIME type that 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.2.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".
6.3. The <streams> Element
The <streams> element is a container that is used to describe the
media streams used in a session. A <streams> element can contain
multiple <stream> elements. Each <stream> element describes the
properties (e.g. media type, codecs and IP addresses and ports) of a
single media stream.
The <streams> element is only defined for session information
documents (i.e. in a <session-info> container).
The <streams> element MUST contain one or more <stream> elements.
Hilt, et al. Expires November 20, 2007 [Page 10]
Internet-Draft Media Policy Dataset May 2007
6.3.1. The <stream> Element
The <stream> element describes a specific media stream. It contains
the media type, codecs and the hostname(s) or IP address(es) and
port(s) of this stream.
The hostname(s) or IP address(es) and port number(s) of a stream
correspond to the ones listed in the session description(s). A UA
that generates <stream> element MUST insert the hostname/port found
in the local session description for this media stream into the
local-host-port element. It MUST insert the hostname/port of the
remote session description into the remote-host-port element, if the
remote session description is available to the UA. If not, the UA
generates a stream element that only contains the local-host-port
element.
This element may have the following attributes (see Section 3.3):
direction.
The <stream> element MUST contain one <media-type> element, one or
more <codec> elements and one <local-host-port> element. It MAY
contain one <remote-host-port> element.
6.3.1.1. The <local-host-port> Element
The <local-host-port> element contains the hostname or IP address and
the port number of the media stream in the local session description.
The hostname or IP address is separated from the port by a ":". An
example is: "host.anywhere.com:49562".
The hostname or IP address of element is found in the c= element for
the stream in the local SDP description. The port number is found in
the m= element.
6.3.1.2. The <remote-host-port> Element
The <remote-host-port> element is structured exactly as the <local-
host-port> element. However, it identifies the hostname or IP
address and port number of the media stream in the remote session
description.
6.4. The <max-bandwidth> Element
The <max-bandwidth> element defines the overall maximum bandwidth in
kilobits per second an entity can/will use for media streams at any
point in time. It defines an upper bound for the media bandwidth
that includes all media streams in all sessions.
Hilt, et al. Expires November 20, 2007 [Page 11]
Internet-Draft Media Policy Dataset May 2007
This element MAY have the following attribute (see Section 3.3):
direction.
If used in a <session-policy> element, this element MAY have the
following additional attribute (see Section 3.3): visibility.
If the <max-bandwidth> element occurs multiple times in a container
element, each instance MUST apply to a different set of media streams
(i.e. one <max-bandwidth> element for outgoing and one for incoming
streams).
Merging of session-policy documents: the lowest max-bandwidth
value is used.
6.5. The <max-session-bandwidth> Element
The <max-session-bandwidth> element defines the maximum bandwidth in
kilobits per second an entity can/will use for media streams in the
described session. It defines an upper bound for the media bandwidth
over all media streams in a session.
This element MAY have the following attribute (see Section 3.3):
direction.
If used in a <session-policy> element, this element MAY have the
following additional attribute (see Section 3.3): visibility.
If the <max-session-bandwidth> element occurs multiple times in a
container element, each instance MUST apply to a different set of
media streams (i.e. one <max-session-bandwidth> element for outgoing
and one for incoming streams).
Merging of session-policy documents: the lowest max-session-
bandwidth value is used.
6.6. The <max-stream-bandwidth> Element
The <max-stream-bandwidth> element defines the maximum bandwidth in
kilobits per second an entity can/will use for one media stream in
the described session.
This element MAY have the following attribute (see Section 3.3):
direction.
If used in a <session-policy> element, this element MAY have the
following additional attribute (see Section 3.3): visibility.
If the <max-stream-bandwidth> element occurs multiple times in a
Hilt, et al. Expires November 20, 2007 [Page 12]
Internet-Draft Media Policy Dataset May 2007
container element, each instance MUST apply to a different set of
media streams (i.e. one <max-stream-bandwidth> element for outgoing
and one for incoming streams).
Merging of session-policy documents: the lowest max-stream-
bandwidth value is used.
6.7. 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 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.
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 3.3):
direction.
If used in a <session-policy> element, this element MAY have the
following additional attribute (see Section 3.3): visibility.
Multiple <media-intermediaries> elements MAY only be present in a
container if each 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: <fixed-intermediary> and <turn-
intermediary>.
Merging of session-policy documents: 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
Hilt, et al. Expires November 20, 2007 [Page 13]
Internet-Draft Media Policy Dataset May 2007
Merging Algorithm" [11]. 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.7.1. The <fixed-intermediary> Element
A fixed intermediary relies on pre-configured forwarding rules. The
user agent simply sends media to the first media intermediary listed.
It can assume that this media intermediary has been pre-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 <fixed-intermediary> element MUST contain one <int-host-port>
element and MAY contain multiple optional <int-addl-port> elements.
6.7.1.1. The <int-host-port> Element
The <int-host-port> element contains the hostname or IP address and
port number of a media intermediary. The UA uses this hostname/IP
address and port to send its media streams to the intermediary. The
hostname or IP address is separated from the port by a ":".
If a protocol uses multiple subsequent ports (e.g. RTP), the lowest
port number SHOULD be included in the <int-host-port> element. All
additional port numbers SHOULD be identified in <int-addl-port>
elements.
6.7.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-host-port> element. All
additional port numbers SHOULD be identified in <int-addl-port>
elements.
6.7.2. The <turn-intermediary> Element
The TURN [12] 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
Hilt, et al. Expires November 20, 2007 [Page 14]
Internet-Draft Media Policy Dataset May 2007
on the TURN server and uses this binding to transmit and receive
media.
The <turn-intermediary> element MUST contain one <int-host-port>
element and MAY contain multiple optional <int-addl-port> elements
and one optional <shared-secret> element.
6.7.2.1. The <shared-secret> Element
The <shared-secret> element contains the shared secret needed to
authenticate at the TURN server.
6.8. 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 3.3):
direction, media-type.
If used in a <session-policy> element, this element MAY have the
following additional attribute (see Section 3.3): visibility.
The media-type attribute is used to define that <qos-dscp> element
only applies to streams of a certain media type. For example, it may
only apply to audio streams. 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'.
The <qos-dscp> element is optional and MAY occur multiple times
inside a container. If the <qos-dscp> element 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 of session-policy documents: 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" [11]. The DSCP value from the closest server
is used.
6.9. 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
Hilt, et al. Expires November 20, 2007 [Page 15]
Internet-Draft Media Policy Dataset May 2007
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 3.3):
visibility.
The <local-ports> element is only defined for session policy
documents (i.e. in a <session-policy> container).
Merging of session-policy documents: 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" [11]. The value from the closest server
is used.
6.10. The <context> Element
The <context> element provides context information about a session
policy or session information document.
The <context> element MAY contain multiple <contact> and one <info>
element.
If used in a <session-policy> element, the <context> element MAY also
contain a <domain> element.
If used in a <session-info> element, the <context> element MAY also
contain a <request-URI> element.
Merging of session-policy documents: the <context> element is not
subject to merging.
6.10.1. The <domain> Element
The <domain> element contains a URI that identifies the domain which
has issued this policy.
The <domain> element is only defined inside a <session-info> element.
6.10.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 document can be
reached.
Hilt, et al. Expires November 20, 2007 [Page 16]
Internet-Draft Media Policy Dataset May 2007
6.10.3. The <info> Element
The <info> element provides a short textual description of the policy
or session that should be intelligible to the human user.
6.10.4. The <request-URI> Element
The <request-URI> element identifies the request-URI the dialog
initiating request of a session is sent to.
The <request-URI> element is only defined inside a <session-info>
element.
6.11. Other Session Properties
A number of additional elements have been proposed for a media
property language. These elements are deemed to be outside the scope
of this 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 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. Examples
7.1. Session Policy Documents
The following example describes a session policy document 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 fixed media intermediary into outgoing media
streams.
Hilt, et al. Expires November 20, 2007 [Page 17]
Internet-Draft Media Policy Dataset May 2007
<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="allow">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">
<fixed-intermediary>
<int-host-port>192.0.2.0:6000</int-host-port>
<int-addl-port>6001</int-addl-port>
</fixed-intermediary>
</media-intermediaries>
</session-policy>
</property-set>
7.2. Session Information Documents
The following examples contain session descriptions and the session
information documents that represent 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
Hilt, et al. Expires November 20, 2007 [Page 18]
Internet-Draft Media Policy Dataset May 2007
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
MPDF document:
<property-set>
<session-info>
<context>
<contact>sip:alice@atlanta.com</contact>
<info>session information</info>
</context>
<streams>
<stream>
<media-type>audio</media-type>
<codec><mime-type>audio/PCMU</mime-type></codec>
<codec><mime-type>audio/1016</mime-type></codec>
<codec><mime-type>audio/GSM</mime-type></codec>
<local-host-port>host.anywhere.com:49562</local-host-port>
</stream>
<stream>
<media-type>video</media-type>
<codec><mime-type>video/H261</mime-type></codec>
<codec><mime-type>video/H263</mime-type></codec>
<local-host-port>host.anywhere.com:51234</local-host-port>
</stream>
</streams>
</session-info>
</property-set>
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
Hilt, et al. Expires November 20, 2007 [Page 19]
Internet-Draft Media Policy Dataset May 2007
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:
<property-set>
<session-info>
<context>
<contact>sip:alice@atlanta.com</contact>
<info>session information</info>
</context>
<streams>
<stream>
<media-type>audio</media-type>
<codec><mime-type>audio/PCMU</mime-type></codec>
<codec><mime-type>audio/GSM</mime-type></codec>
<local-host-port>host.anywhere.com:49562</local-host-port>
<remote-host-port>host.example.com:52123</remote-host-port>
</stream>
<stream>
<media-type>video</media-type>
<codec><mime-type>video/H261</mime-type></codec>
<local-host-port>host.anywhere.com:51234</local-host-port>
<remote-host-port>host.example.com:50286</remote-host-port>
</stream>
</streams>
</session-info>
</property-set>
Hilt, et al. Expires November 20, 2007 [Page 20]
Internet-Draft Media Policy Dataset May 2007
8. Relax NG Definition
Note: the Relax NG-based definition below is in its initial revision
and needs to be reviewed by a Relax NG expert.
<?xml version="1.0"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0"
ns="urn:ietf:params:xml:ns:mediadataset"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<include href="uaprofile.rng">
<define name="ElementGenericSetting">
<ref name="ElementGenericMediaSetting"/>
</define>
<define name="ElementGenericSettingContainer">
<ref name="ElementGenericMediaSettingContainer"/>
</define>
</include>
<define name="ElementGenericMediaSettingContainer">
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:uaprof"/>
<nsName ns="urn:ietf:params:xml:ns:mediadataset"/>
<nsName ns=""/>
</except>
</anyName>
<ref name="SettingContainerAttributes"/>
<!-- container can have containers or settings not both -->
<choice>
<zeroOrMore>
<ref name="ElementGenericMediaSetting"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementGenericMediaSettingContainer"/>
</zeroOrMore>
</choice>
</element>
</define>
<define name="ElementGenericMediaSetting">
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:uaprof"/>
<nsName ns="urn:ietf:params:xml:ns:mediadataset"/>
Hilt, et al. Expires November 20, 2007 [Page 21]
Internet-Draft Media Policy Dataset May 2007
<nsName ns=""/>
</except>
</anyName>
<ref name="SettingAttributes"/>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
<zeroOrMore>
<choice>
<text/>
<ref name="ElementGenericMediaSetting"/>
</choice>
</zeroOrMore>
</element>
</define>
<define name="PropertySetExtensionInfo" combine="interleave">
<optional>
<element name="session-info">
<ref name="SettingContainerAttributes"/>
<optional>
<ref name="ElementContext"/>
</optional>
<optional>
<ref name="ElementStreams"/>
</optional>
<zeroOrMore>
<ref name="ElementMaxBandwidth"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementMaxSessionBandwidth"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementMaxStreamBandwidth"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementMediaIntermediaries"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementQosDSCP"/>
</zeroOrMore>
</element>
</optional>
</define>
<define name="PropertySetExtensionPolicy" combine="interleave">
<optional>
<element name="session-policy">
<ref name="SettingContainerAttributes"/>
<optional>
Hilt, et al. Expires November 20, 2007 [Page 22]
Internet-Draft Media Policy Dataset May 2007
<ref name="ElementContext"/>
</optional>
<optional>
<ref name="ElementLocalPorts"/>
</optional>
<zeroOrMore>
<ref name="ElementMediaTypes"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementCodecs"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementMaxBandwidth"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementMaxSessionBandwidth"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementMaxStreamBandwidth"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementMediaIntermediaries"/>
</zeroOrMore>
<zeroOrMore>
<ref name="ElementQosDSCP"/>
</zeroOrMore>
</element>
</optional>
</define>
<define name="ElementMediaTypes">
<element name="media-types">
<interleave>
<optional>
<ref name="AttributeVisibility"/>
</optional>
<optional>
<ref name="AttributeDirection"/>
</optional>
<optional>
<ref name="AttributeExcludedPolicy"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
<ref name="ElementMediaType"/>
</element>
Hilt, et al. Expires November 20, 2007 [Page 23]
Internet-Draft Media Policy Dataset May 2007
</define>
<define name="ElementMediaType">
<element name="media-type">
<data type="string" />
<interleave>
<optional>
<ref name="AttributeQ"/>
</optional>
<optional>
<ref name="AttributePolicy"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
</element>
</define>
<define name="ElementCodecs">
<element name="codecs">
<interleave>
<optional>
<ref name="AttributeVisibility"/>
</optional>
<optional>
<ref name="AttributeDirection"/>
</optional>
<optional>
<ref name="AttributeExcludedPolicy"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
<ref name="ElementCodec"/>
</element>
</define>
<define name="ElementCodec">
<element name="codec">
<interleave>
<optional>
<ref name="AttributeQ"/>
</optional>
<optional>
<ref name="AttributePolicy"/>
</optional>
Hilt, et al. Expires November 20, 2007 [Page 24]
Internet-Draft Media Policy Dataset May 2007
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
<element name="mime-type">
<data type="string" />
</element>
<zeroOrMore>
<element name="mime-parameter">
<data type="string" />
</element>
</zeroOrMore>
</element>
</define>
<define name="ElementStreams">
<element name="streams">
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
<oneOrMore>
<ref name="ElementStream"/>
</oneOrMore>
</element>
</define>
<define name="ElementStream">
<element name="stream">
<optional>
<ref name="AttributeDirection"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
<ref name="ElementMediaType"/>
<oneOrMore>
<ref name="ElementCodec"/>
</oneOrMore>
<element name="local-host-port">
<data type="string" />
</element>
<optional>
<element name="remote-host-port">
<data type="string" />
</element>
</optional>
</element>
</define>
Hilt, et al. Expires November 20, 2007 [Page 25]
Internet-Draft Media Policy Dataset May 2007
<define name="ElementMaxBandwidth">
<element name="max-bandwidth">
<data type="integer" />
<interleave>
<optional>
<ref name="AttributeVisibility"/>
</optional>
<optional>
<ref name="AttributeDirection"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
</element>
</define>
<define name="ElementSessionMaxBandwidth">
<element name="max-session-bandwidth">
<data type="integer" />
<interleave>
<optional>
<ref name="AttributeVisibility"/>
</optional>
<optional>
<ref name="AttributeDirection"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
</element>
</define>
<define name="ElementMaxStreamBandwidth">
<element name="max-stream-bandwidth">
<data type="integer" />
<interleave>
<optional>
<ref name="AttributeVisibility"/>
</optional>
<optional>
<ref name="AttributeDirection"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
Hilt, et al. Expires November 20, 2007 [Page 26]
Internet-Draft Media Policy Dataset May 2007
</element>
</define>
<define name="ElementMediaIntermediaries">
<element name="media-intermediaries">
<interleave>
<optional>
<ref name="AttributeVisibility"/>
</optional>
<optional>
<ref name="AttributeDirection"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
<oneOrMore>
<choice>
<element name="fixed-intermediary">
<element name="int-host-port">
<data type="string" />
</element>
<zeroOrMore>
<element name="int-addl-port">
<data type="integer" />
</element>
</zeroOrMore>
</element>
<element name="turn-intermediary">
<element name="int-host-port">
<data type="string" />
</element>
<zeroOrMore>
<element name="int-addl-port">
<data type="integer" />
</element>
</zeroOrMore>
<zeroOrMore>
<element name="shared-secret">
<data type="string" />
</element>
</zeroOrMore>
</element>
</choice>
</oneOrMore>
</element>
</define>
Hilt, et al. Expires November 20, 2007 [Page 27]
Internet-Draft Media Policy Dataset May 2007
<define name="ElementQoSDSCP">
<element name="qos-dscp">
<data type="integer" />
<interleave>
<optional>
<ref name="AttributeVisibility"/>
</optional>
<optional>
<ref name="AttributeDirection"/>
</optional>
<optional>
<ref name="AttributeMediaType"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
</element>
</define>
<define name="ElementLocalPorts">
<element name="local-ports">
<data type="string" />
<interleave>
<optional>
<ref name="AttributeVisibility"/>
</optional>
<zeroOrMore>
<ref name="AttributeGenericAttributes"/>
</zeroOrMore>
</interleave>
</element>
</define>
<define name="ElementContext">
<element name="context">
<interleave>
<optional>
<element name="info">
<data type="string" />
</element>
</optional>
<optional>
<element name="domain">
<data type="string" />
</element>
</optional>
<optional>
Hilt, et al. Expires November 20, 2007 [Page 28]
Internet-Draft Media Policy Dataset May 2007
<element name="request-URI">
<data type="string" />
</element>
</optional>
<zeroOrMore>
<element name="contact">
<data type="string" />
</element>
</zeroOrMore>
</interleave>
</element>
</define>
</grammar>
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/
media-policy-dataset+xml, and a new XML namespace.
10.1. MIME Registration
MIME media type name: application
MIME subtype name: media-policy-dataset+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [8].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [8].
Security considerations: See Section 10 of RFC 3023 [8] and Section 9
of this specification.
Interoperability considerations: none.
Hilt, et al. Expires November 20, 2007 [Page 29]
Internet-Draft Media Policy Dataset May 2007
Published specification: This document.
Applications which use this media type: This document type has been
used to convey media policy information between SIP user agents and a
domain.
Additional Information:
Magic Number: None
File Extension: .mpf 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
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 November 20, 2007 [Page 30]
Internet-Draft Media Policy Dataset May 2007
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>Media Policy Dataset Namespace</title>
</head>
<body>
<h1>Namespace for Media Policy Datasets</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
discussions and suggestions. Many thanks to Roni Even and Mary
Barnes for reviewing the draft and 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., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[4] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML",
World Wide Web Consortium FirstEdition REC-xml-names-19990114,
January 1999,
<http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[5] Mealling, M., "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-05 (work in progress),
Hilt, et al. Expires November 20, 2007 [Page 31]
Internet-Draft Media Policy Dataset May 2007
June 2003.
[6] Moats, R., "URN Syntax", RFC 2141, May 1997.
[7] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[8] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[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] 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-04
(work in progress), October 2006.
[12] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal
Underneath NAT (STUN)", draft-ietf-behave-turn-03 (work in
progress), March 2007.
[13] Bray, T., Maler, E., Sperberg-McQueen, C., Paoli, J., and F.
Yergeau, "Extensible Markup Language (XML) 1.0 (Third
Edition)", World Wide Web Consortium FirstEdition REC-xml-
20040204, February 2004,
<http://www.w3.org/TR/2004/REC-xml-20040204>.
11.2. Informative References
[14] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for
Session Initiation Protocol (SIP) Session Policies",
draft-ietf-sip-session-policy-framework-01 (work in progress),
February 2007.
[15] Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-11 (work in progress),
March 2007.
[16] 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 November 20, 2007 [Page 32]
Internet-Draft Media Policy Dataset May 2007
Authors' Addresses
Volker Hilt
Bell Labs/Alcatel-Lucent
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 November 20, 2007 [Page 33]
Internet-Draft Media Policy Dataset May 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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 November 20, 2007 [Page 34]
| PAFTECH AB 2003-2026 | 2026-04-23 12:11:07 |