Session Initiation Proposal V. Hilt
Investigation Working Group Bell Labs/Lucent Technologies
Internet-Draft G. Camarillo
Expires: April 18, 2004 Ericsson
J. Rosenberg
dynamicsoft
October 19, 2003
A Framework for Session-Independent Intermediary Session Policies in
SIP
draft-hilt-sipping-session-indep-policy-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 18, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Domains may have policies in place that impact the way sessions are
established by user agents. Some of these policies are independent of
a specific session and need to be considered for a certain period of
time. It is therefore desirable to convey these policies to user
agents once they become active instead of requesting them for every
session. In this document, we propose a framework that enables user
agents to subscribe to session policies.
Hilt, et al. Expires April 18, 2004 [Page 1]
Internet-Draft Session-Independent SIP Session Policies October 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Framework for Session-Independent Policies . . . . . . . . . 6
3.1 Policy Server Discovery . . . . . . . . . . . . . . . . . . 6
3.2 Subscribing to Session-Independent Policies . . . . . . . . 7
3.3 Accepting or Rejecting Session-Independent Policies . . . . 8
4. Event Package Definition . . . . . . . . . . . . . . . . . . 9
4.1 Event Package Name . . . . . . . . . . . . . . . . . . . . . 9
4.2 Event Package Parameters . . . . . . . . . . . . . . . . . . 9
4.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . 9
4.4 Subscription Duration . . . . . . . . . . . . . . . . . . . 9
4.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 9
4.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . . 10
4.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . . 10
4.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 11
4.9 Handling of Forked Request . . . . . . . . . . . . . . . . . 12
4.10 Rate of Notifications . . . . . . . . . . . . . . . . . . . 12
4.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Policy Packages . . . . . . . . . . . . . . . . . . . . . . 13
5.1 Policy Object Format . . . . . . . . . . . . . . . . . . . . 13
5.2 XCAP Considerations . . . . . . . . . . . . . . . . . . . . 14
6. Basic Session Policy Package . . . . . . . . . . . . . . . . 15
6.1 Policy Object Format . . . . . . . . . . . . . . . . . . . . 15
6.1.1 Protocols Element . . . . . . . . . . . . . . . . . . . . . 15
6.1.2 Media Element . . . . . . . . . . . . . . . . . . . . . . . 17
6.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
8.1 MIME Registration for application/session-policy+xml . . . . 21
8.2 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:sessionpolicy . . . . . . . . . . . . 21
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25
References . . . . . . . . . . . . . . . . . . . . . . . . . 24
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . 27
Hilt, et al. Expires April 18, 2004 [Page 2]
Internet-Draft Session-Independent SIP Session Policies October 2003
1. Introduction
Some domains have policies in place, which influence the sessions a
user sets up. These policies are often established to support the
network infrastructure, enable user agents to use services or to
prevent user agents from overly burdening the network. For example, a
SIP user agent might be located in a domain, that is connected to the
public Internet via a Network Address Translator (NAT). This domain
might have a policy in place that requires the user agent to contact
a TURN [11] relay before setting up a session. Information about this
policy is essential for a user agent to successfully set up a
session.
In another example, SIP is used in a wireless network. The network
provider has limited resources for media traffic. During periods of
high activity, the provider would like to restrict codec usage on the
network to lower rate codecs. In existing approaches, this is
frequently accomplished by having the proxies examine the SDP [2] in
the body and remove the higher rate codecs or reject the call and
require the UA to start over with a different set of codecs. Having
information about the current policy would enable user agents to
initiate a session with an acceptable codec.
In a third example, a domain has established policies regarding the
type of user agents that can use their network. For example, a domain
could require that user agents using its network use a particular
protocol (e.g., SIP) with a set of extensions (e.g., preconditions
must be used). A user agent needs to know the exact policy of a
domain in order to be able to use the right configuration to send and
receive traffic in that domain.
In yet a fourth example, a user has subscribed to a network-based
call recording service to record calls to certain destinations. The
recording server acts as a media intermediary which needs to be
included in the media path. Knowing the address of the recording
server enables the user agent to route its traffic through the
recording server if desired.
Some domains enforce certain session policies. For example, if the
policy of a domain disallows the use of a particular codec, access
routers will discard packets that transport media encoded with that
codec. Unfortunately, enforcement mechanisms do not usually inform
the user about what is happening. They silently keep the user from
doing anything against the policy. It is therefore important for the
user agent to know about session policies and the consequences of not
accepting them.
Session policies may be specific to a certain session and may change
Hilt, et al. Expires April 18, 2004 [Page 3]
Internet-Draft Session-Independent SIP Session Policies October 2003
from session to session. Such policies can be set up using the
framework for session-specific policies [3]. Other session policies
remain stable for a longer period of time, typically in the range of
hours or days. In principle, these policies could also be set up on a
session-to-session basis. However, establishing the same policies
over and over again is expensive, causing the continuous transmission
of the same information during session setup, and possibly adding to
session setup latencies. It is therefore desirable, to enable user
agents to obtain the policies relevant for them and to inform the
user agents about changes in these policies.
Our solution for supporting session-independent session policies is
to introduce a framework that allows user agents to subscribe to
session policies. This framework satisfies the requirements listed in
[13].
This document is structured as follows: Section 3 introduces a
framework that enables user agents to subscribe to session policies.
Section 4 provides the necessary details to define an event package
for the SUBSCRIBE/NOTIFY framework. Section 5 discusses the creation
of policy packages for this framework and Section 6 describes a basic
policy package. Section 7 discusses Security and Section 8 IANA
considerations. Section 9 talks about open issues.
Hilt, et al. Expires April 18, 2004 [Page 4]
Internet-Draft Session-Independent SIP Session Policies October 2003
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, [1] and indicate requirement levels for
compliant implementations.
Hilt, et al. Expires April 18, 2004 [Page 5]
Internet-Draft Session-Independent SIP Session Policies October 2003
3. Framework for Session-Independent Policies
The conveying session-independent policies to a user agent is most
beneficial for network providers, that are frequently involved in the
sessions established by a user agent. Typically, these are the
following two providers:
o The Home Domain Provider is responsible for providing SIP service
to a SIP user. Typically, this is the domain present in the URI in
the address-of-record of a registration. The home domain provider
will usually maintain user preferences and subscriptions to
services. Thus, it may want to provide session-independent
policies, that are needed for services, a user has subscribed to.
o The Access Network Provider is responsible for providing IP
service to a SIP agent. This may be the same provider as the home
domain provider or it may be a different provider in case the user
roams in a foreign network or obtains SIP services and IP
connectivity from different operators. Access Network Providers
often provide session-independent policies, which generally impact
the traffic in their networks.
A solution for session-independent policies should enable a user
agent to detect the policy servers in the domains of these two
providers and retrieve the relevant policies. User agents should also
be enabled to retrieve policies from different policy servers.
This framework allows user agents to subscribe to session policies
based on the SIP SUBSCRIBE/NOTIFY mechanism [10]. This framework does
not define the structure or semantics of policies.
Session-independent policies need to be defined in policy packages.
An basic policy package is discussed in Section 6.
3.1 Policy Server Discovery
In the first step, a UA needs to discover the relevant policy
servers.
The UA MUST attempt to discover the policy servers of the home
domains of all local users. In order to do so, the UA constructs a
SIP URI for each registered address of record by taking the host
component of the address of record and adding "sessionpolicy" as
userinfo component to this address. For example, if an address of
record is sip:bob@example.com, the UA would generate the URI
sip:sessionpolicy@example.com. It uses this URI to subscribe to the
policies of the home domain policy server of user Bob. Using
"sessionpolicy" as the userinfo component enables proxies to route
the request to a policy server.
Hilt, et al. Expires April 18, 2004 [Page 6]
Internet-Draft Session-Independent SIP Session Policies October 2003
The UA MUST also attempt to discover the policy servers of the access
network provider. The UA MUST execute the discovery procedures in the
order as they appear in the following sections. It SHOULD support all
procedures but it MUST support the first (outbound proxy).
1. If the UA is configured with an outbound proxy for the current
access domain (e.g. by using the procedures defined in [9] or via
manual configuration) the UA MUST construct a URI by adding
"sessionpolicy" as userinfo component to the address of the
outbound proxy. For example, if the address of an outbound proxy
is sip.example.com:6060, the UA would create the URI
sip:sessionpolicy@sip.example.com:6060.
2. If no outbound proxy is configured or the subscription to the
above URI fails, the UA SHOULD construct a fully qualified host
name by adding "sessionpolicy" to the local domain name if
defined (in analogy to the DNS lookup procedure defined in [9]).
For example, a UA would create the host name
sessionpolicy.example.com if the local domain is example.com. The
UA SHOULD then try a DNS A record lookup on this domain name. If
the name resolves in a DNS record, it should create a URI by
adding "sessionpolicy" as userinfo component. In the above
example, the UA would create the URI
sip:sessionpolicy@policy.example.com.
3. If the above hostname could not be resolved via DNS, the UA
SHOULD use multicast to subscribe to policies.
TBD: define this multicast address.
In addition to the discovered URIs, the UA may also have manually
configured URIs to policy servers.
3.2 Subscribing to Session-Independent Policies
A UA sends SUBSCRIBE requests to the discovered policy server URIs. A
UA compliant with this specification MUST support content indirection
[8] including support for content indirection with multiple URIs. In
addition, it MUST support the "application/basic-session-policy+xml"
data format of the basic policy package described in Section 6. It
MAY support the data formats of other policy packages. The UA SHOULD
insert an Accept header into the SUBSCRIBE request. If an Accept
header is created, its MUST include the MIME types "multipart/mixed",
"message/external-body" and "application/basic-session-policy+xml".
The UA MUST include the event package name "session-policy" in the
Event header.
When creating the SUBSCRIBE request, the UA MUST populate the To
Hilt, et al. Expires April 18, 2004 [Page 7]
Internet-Draft Session-Independent SIP Session Policies October 2003
header field with the SIP URI of the policy server it wants to
subscribe to. The UA populates the From header field with the address
of record of the user for whom it subscribes. The UA MUST send a
separate SUBSCRIBE message for each address of records to each policy
server. The only exception are the home policy servers. This enables
policy servers to learn about all users a UA has registered and
allows them to provide different policies for each user. A home
policy server will typically not be able to provide policies for
foreign users. Therefore, a UA SHOULD only subscribe the associated
address of record to a home policy server.
The UA SHOULD subscribe to all discovered home domain and all
manually configured policy servers. It SHOULD subscribe to access
network policy servers until the first successful response is
received.
3.3 Accepting or Rejecting Session-Independent Policies
Once a UA has received a session policy from a policy server, it can
decide whether it wants to accept or reject these policies. The UA
does not need to inform the policy server or proxies about its
decision.
The UA applies the accepted policies to new sessions it is creating.
For example, if the policy lists the audio codecs allowed in a
wireless network, the UA includes only those audio codecs in the
session description offers and answers it creates. The way policies
are applied differs from policy package to policy package and must be
defined in the policy packet specification. The UA does not
explicitly indicate its use of policies in an INVITE or UPDATE
message. A proxy might be able to determine the acceptance of a
session-independent policy by examining the actions of the UA (e.g.
contacting a TURN relay) or the information it exposes in
Media-Interface headers for session-specific policies [3]. The proxy
may have mechanisms in place to enforce its policies.
A provider may have session-independent and session-specific policies
in place, which influence the same aspect of a session (e.g. the
codecs allowed). Since session-specific policies are requested during
the establishment or modification of a session, they are applied
after session-independent policies and may override them.
A UA, which has received an updated set of session-independent
policies, MAY apply them to existing sessions for example by issuing
a re-INVITE request.
Hilt, et al. Expires April 18, 2004 [Page 8]
Internet-Draft Session-Independent SIP Session Policies October 2003
4. Event Package Definition
This section provides the details needed to specify an event package
as defined in Section 4.4 of RFC 3265 [10].
4.1 Event Package Name
The name of this package is "session-policy". As specified in RFC
3265 [10], this value appears in the Event header field present in
SUBSCRIBE and NOTIFY requests.
Event: session-policy
4.2 Event Package Parameters
No package specific Event header field parameters are defined for
this event package.
4.3 SUBSCRIBE Bodies
A SUBSCRIBE for session policy events MAY contain a body. This body
would serve the purpose of filtering the subscription. The definition
of such a body is outside the scope of this specification.
A SUBSCRIBE for the session policy package MAY be sent without a
body. This implies that the default session policy filtering policy
has been requested. The default policy is that notifications are
generated every time there is any change in the policies for the
user.
4.4 Subscription Duration
The default expiration of subscriptions to session policy state is
one hour (3600 seconds).
4.5 NOTIFY Bodies
This event package uses content indirection to convey policy
information. As such, the body of a NOTIFY message contains one or
more URIs, which point to a policy object on a policy object server
(typically a HTTP server). This saves bandwidth, allows for larger
policy objects and enables a policy server to insert all current
policies in a NOTIFY instead of tracking the policies that are
actually updated or new to a UA. The UA can then decide, which policy
objects it needs to retrieve.
All subscribers and notifiers MUST support the MIME types "multipart/
Hilt, et al. Expires April 18, 2004 [Page 9]
Internet-Draft Session-Independent SIP Session Policies October 2003
mixed" and "message/external-body" [8]. In addition, they MUST
support the "application/basic-session-policy+xml" data format of the
basic policy package described in Section 6. Subscribers MAY support
the data formats of other policy packages. If the notifier receives a
SUBSCRIBE request without an Accept header field, it MUST use the
default value of "multipart/mixed, message/external-body,
application/basic-session-policy+xml".
The data format of policy objects is not specified within this
framework and must be defined in a policy package. A basic policy
package for this framework is described in Section 6. A policy
package may be based on XCAP [12]. XCAP enables fine grained access
to XML-based configuration documents on a HTTP server.
4.6 Notifier Processing of SUBSCRIBE Requests
Session policy state can be sensitive information. Therefore, all
subscriptions to it SHOULD be authenticated and authorized before
approval. Authentication MAY be performed using any of the techniques
available through SIP, including digest, S/MIME, TLS or other
transport specific mechanisms. It is RECOMMENDED that a user be
allowed to subscribe to their own session policy.
If the notifier determines that it can't provide any policy object to
the subscriber now and in the near future, it SHOULD return a 480
"Temporarily Unavailable" response. This response SHOULD contain a
Retry-After header indicating the time at which the subscriber should
re-try the subscription. If the notifier determines that a policy
object might become available in the near future, it SHOULD instead
accept the subscription and create empty NOTIFY messages until the
policy object is available.
If the policy server requires the use of a certain policy package and
detects that the UA has not indicated support for the respective
document format in the Accept header, it MAY reject a SUBSCRIBE
request with a 406 "Not Acceptable" response. This way, a policy
server can inform the user agent that is has session-independent
policies place, which are mandatory but not understood. For example,
a domain could restricts the use of certain audio codecs using a
policy document format that is not understood by a user agent. By
returning a 406 response to the SUBSCRIBE, the user agent would be
informed that something might go wrong when establishing a session.
Policy documents may contain attributes that define the required
status for each policy on a fine grained basis.
4.7 Notifier Generation of NOTIFY Requests
Notifications SHOULD be generated whenever a change in one or more
Hilt, et al. Expires April 18, 2004 [Page 10]
Internet-Draft Session-Independent SIP Session Policies October 2003
session policy objects relevant to the subscribed user occurs.
A notifier will typically want to provide multiple policy objects to
a user. For example, the notifier could have policy objects
describing the general policies of a domain and user-specific policy
objects, which describe policies only relevant for a particular user.
It may also have policy objects that were created by the network
provider and policy objects created by the user. The notifier MUST
insert the URIs of all relevant policy objects into the NOTIFY
message, even if only some of the policy objects have changed. In
that sense, a notifier always provides complete state information to
the subscriber. Each URI MUST have an associated Content-ID entity
header, which MUST change every time the referred policy object
changes. This enables subscribers to determine if they have the
latest version of the policy object without downloading and comparing
the objects.
The notifier MUST ensure that all URIs, it is inserting into a NOTIFY
body, point to policy objects that are actually accessible on the
policy object server. This is in particular important if the policy
server creates policy objects on the fly. For example, a new policy
object might be generated when a new user requests policies for the
first time. A policy server MUST NOT delay the transmission of a
NOTIFY if policy object is not yet available on the policy object
server. Instead, it SHOULD not include the respective URI in the
NOTIFY body and create an additional NOTIFY as soon as the new policy
object is available.
If no policy object is available at the time a NOTIFY is created, the
notifier SHOULD create an empty NOTIFY message which does not contain
a body. This ensures that the subscription is established and the
notifier can convey policy objects to the subscriber as soon as they
become available.
4.8 Subscriber Processing of NOTIFY Requests
After receiving a NOTIFY, the subscriber MUST determine if any of the
included URIs are pointing to a policy object, that is new or has
been update since it was last downloaded. The subscriber SHOULD
retrieve new or updated policy objects as soon as possible.
Session policies are typically created and maintained by network
providers. They provide certain information to or request a certain
behavior from user agents. The provider generated policies MUST NOT
be changed by a user. However, a user MAY cerate personal session
policies and store them on a policy server. A user may of course
modify these policies. A policy object server MUST enforce access
permissions to policy objects accordingly.
Hilt, et al. Expires April 18, 2004 [Page 11]
Internet-Draft Session-Independent SIP Session Policies October 2003
4.9 Handling of Forked Request
A subscriber establishes multiple subscription with different policy
servers (home domain, access network domain, etc.). Similarly, a
subscriber MAY establish multiple subscriptions on forked SUBSCRIBE
requests. The NOTIFY messages created by the notifiers can be
processed individually and do not need to be merged.
4.10 Rate of Notifications
For reasons of congestion control, it is important that the rate of
notifications not become excessive. As a result, it is RECOMMENDED
that the server not generate notifications for a single subscriber at
a rate faster than once every 5 seconds.
4.11 State Agents
State agents have no role in the handling of this event package.
Hilt, et al. Expires April 18, 2004 [Page 12]
Internet-Draft Session-Independent SIP Session Policies October 2003
5. Policy Packages
This section describes aspects that need to be considered when
packages for session-independent policies are defined.
5.1 Policy Object Format
This section MUST be present in a policy package.
A Policy Object (PO) is used to convey policies to the subscriber.
Each package MUST specify or cite detailed specifications for the
syntax and semantics associated with such a Policy Object.
The PO MUST have a version attribute that allows the recipient of POs
to properly order them.
A PO MAY have an expires attribute that defines the time, at which
the policy object expires. If this attribute is not present, a policy
object expires at the time the subscription, through which it was
received, is terminated. A policy object also expires when a policy
object with a higher version number becomes available at the same
URI.
A PO can have different scopes. It could be applicable to all
sessions established by the UA or just to a subset of them. The scope
of a PO MUST be defined in a policy package, by either specifying a
default value or defining a scope attribute that can be populated by
policy server when creating the PO. Possible scopes are:
o Sessions for a certain address of record (i.e. sessions created
for a certain local user). This is useful if an end device
supports multiple identities and, for example, only a subset of
them has subscribed to a service requiring policies.
o Sessions to a certain remote URI. For example, a policy for NAT
traversal might only apply to sessions to or from external
addresses.
o Outgoing/incoming sessions only. A policy may apply only to
sessions initiated by the local/the remote UA.
o A certain media stream. This enables the specification of policies
on a stream-by-stream basis. For example, a policy for audio codec
selection only applies to audio streams.
o Media streams in the incoming or outgoing direction. This enables
independent policies for the media streams in each direction.
Hilt, et al. Expires April 18, 2004 [Page 13]
Internet-Draft Session-Independent SIP Session Policies October 2003
A PO SHOULD contain a consequences attribute. The consequences
attribute is used by the policy server to indicate what the
consequences of rejecting the policy are. The this attribute MUST
also enable a UA to determine if the acceptance of a policy is
mandatory or optional. If the consequences attribute is not present
in a PO, the default value is used. The default value is optional if
not defined otherwise in the policy package.
The PO MAY contain a signature attribute allowing the UA to verify
the identity of the domain, which has requested policies, and the
integrity of those policies.
A policy package MUST describe exactly how a UA is supposed to apply
the policy contained in an PO. In particular, the policy package MUST
describe how the information in the PO influences the session
description a UA uses to establish sessions and if additional steps
need to be taken either when accepting the policy or when setting up
or modifying a session. This process MUST enable a UA to determine
the consequences of accepting the policy before actually executing
the necessary steps.
A PO MAY contain an attribute that explains the reasoning behind the
session policy. The end device may present this text string to a
human when querying whether the requested policies should be accepted
or not.
5.2 XCAP Considerations
The developer of a policy package might find it helpful to specify
the policy package based on XCAP [12]. In this case, a policy package
defines an XCAP application usage specification.
Hilt, et al. Expires April 18, 2004 [Page 14]
Internet-Draft Session-Independent SIP Session Policies October 2003
6. Basic Session Policy Package
This section defines a basic policy package, that must be understood
by all user agents.
Policy object is an XML document that MUST be well-formed and SHOULD
be valid. Session policy documents MUST be based on XML 1.0 and MUST
be encoded using UTF-8. This specification makes use of XML
namespaces for identifying session policy documents. The namespace
URI for elements defined by this specification is a URN [5], using
the namespace identifier 'ietf' defined by RFC 2648 [6] and extended
by [4]. This URN is:
urn:ietf:params:xml:ns:sessionpolicy
A session policy document begins with the root element tag
"sessionpolicy".
6.1 Policy Object Format
A session policy document starts with a sessionpolicy element. This
element has three mandatory attributes:
version: This attribute allows the recipient of session policy
information documents to properly order them. Versions start at 0,
and increment by one for each new document sent to a subscriber.
Versions are scoped within a subscription. Versions MUST be
representable using a 32 bit integer.
domain: This attribute contains the domain the policy belongs to.
entity: This attribute contains a URI that identifies the user
whose media policy information is reported in the remainder of the
document.
The sessionpolicy element has a series of sessionpolicy sub-elements:
zero or one protocols element and zero or one media element.
6.1.1 Protocols Element
The protocols element contains a series of protocol sub-elements.
Each protocol sub-element contains the policy related to the usage of
a particular protocol.
The protocol element has a single mandatory attribute, name. The name
attribute identifies a protocol the policy of each protocol element
is referring to. The protocol element has a series of sub-elements:
methods, option-tags, feature-tags, and bodies.
Hilt, et al. Expires April 18, 2004 [Page 15]
Internet-Draft Session-Independent SIP Session Policies October 2003
6.1.1.1 Methods Element
The methods element contains a default-policy attribute and method
elements. The default-policy attribute contains the policy for
methods that are not listed as method elements. A method element has
two attributes: name and policy. The name attribute identifies a
method, and the policy attribute contains the policy for that method
(allowed or disallowed).
6.1.1.2 Option-tags Element
The option-tags element contains a default-policy attribute and
option-tag elements. The default-policy attribute contains the policy
for option-tags that are not listed as option-tag elements. An
option-tag element has two attributes: name and policy. The name
attribute identifies a method, and the policy attribute contains the
policy for that method (mandatory, allowed, or disallowed).
6.1.1.3 Feature-tags Element
The feature-tags element contains a default-policy attribute and
feature-tag elements. The default-policy attribute contains the
policy for feature-tags that are not listed as feature-tag elements.
An feature-tag element has two attributes: name and policy. The name
attribute identifies a method, and the policy attribute contains the
policy for that method (allowed, or disallowed).
6.1.1.4 Bodies Element
The bodies element contains a default-policy attribute, a
default-encryption attribute and body-disposition elements. The
default-policy attribute contains the policy for body dispositions
that are not listed as body-disposition elements. The
default-encryption attribute contains the encryption policy for body
dispositions that are not listed as body-disposition elements.
A body-disposition element can have a number of attributes: name,
policy, default-policy, and encryption. The name attribute identifies
a body-disposition, and the policy attribute contains the policy for
that body-disposition (allowed, or disallowed). The default-policy
attribute contains the policy for body formats that are not listed as
body-format elements. The encryption attribute indicates whether or
not encryption is allowed for a particular body disposition.
A body-disposition element contains body-format elements. A
body-format element can have a two attributes: name and policy. The
name attribute identifies a body-format, and the policy attribute
contains the policy for that body-format (allowed or disallowed).
Hilt, et al. Expires April 18, 2004 [Page 16]
Internet-Draft Session-Independent SIP Session Policies October 2003
6.1.1.5 Extensibility
Other elements from different namespaces MAY be present within a
protocol element for the purposes of extensibility; elements or
attributes from unknown namespaces MUST be ignored.
6.1.1.6 Example of a Protocol Element
6.1.2 Media Element
The media element contains the policy related to the characteristics
of media streams of different types. It has three attributes:
maxbandwidth, maxnostreams, and default-policy. They contain the
maximum bandwidth the user can count on, the maximum number of media
streams that the user is allowed to established at the same time, and
the default policy (allowed or disallowed) for stream types that are
not listed as stream elements.
The media element contains a series of stream elements.
6.1.2.1 Stream Element
A stream element can have a number of attributes: type, policy,
maxbandwidth, and maxnostreams. The type attribute identifies a media
type, and the policy attribute contains the policy for that media
Hilt, et al. Expires April 18, 2004 [Page 17]
Internet-Draft Session-Independent SIP Session Policies October 2003
type (allowed or disallowed).
The stream element has a number of optional sub-element: the codecs
element, the transports element and the directions element.
6.1.2.1.1 Codecs Element
The codecs element contains a default-policy attribute and codec
elements. The default-policy attribute contains the policy for codecs
that are not listed as codec elements. A codec element can have two
attributes: name and policy. The name attribute identifies a codec,
and the policy attribute contains the policy for that codec (allowed,
or disallowed).
6.1.2.1.2 Transports Element
The transports element contains a default-policy attribute and
transport elements. The default-policy attribute contains the policy
for transports that are not listed as transport elements. A transport
element can have two attributes: name and policy. The name attribute
identifies a transport, and the policy attribute contains the policy
for that transport (allowed, or disallowed).
6.1.2.1.3 Directions Element
The directions element contains a default-policy attribute and
direction elements. The default-policy attribute contains the policy
for directions that are not listed as direction elements. A direction
element can have two attributes: name and policy. The name attribute
identifies a direction (sendrecv, sendonly, recvonly), and the policy
attribute contains the policy for that direction (allowed, or
disallowed).
6.1.2.1.4 Extensibility
Other elements from different namespaces MAY be present within a
stream element for the purposes of extensibility; elements or
attributes from unknown namespaces MUST be ignored.
6.1.2.2 Example of a Media Element
Hilt, et al. Expires April 18, 2004 [Page 18]
Internet-Draft Session-Independent SIP Session Policies October 2003
6.2 Schema
The following is the schema for the application/session-policy+xml
type:
TBD
6.3 Example
The following is is an example of an application/session-policy+xml
document:
Hilt, et al. Expires April 18, 2004 [Page 19]
Internet-Draft Session-Independent SIP Session Policies October 2003
7. Security Considerations
Session policy information can be sensitive information. The protocol
used to distribute it SHOULD ensure privacy, message integrity and
authentication. Furthermore, the protocol SHOULD provide access
controls which restrict who can see who else's session policy
information.
Hilt, et al. Expires April 18, 2004 [Page 20]
Internet-Draft Session-Independent SIP Session Policies October 2003
8. IANA Considerations
This document registers a new MIME type, application/
session-policy+xml, and registers a new XML namespace.
8.1 MIME Registration for application/session-policy+xml
MIME media type name: application
MIME subtype name: session-policy+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [7].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [7].
Security considerations: See Section 10 of RFC 3023 [7] and Section 7
of this specification.
Interoperability considerations: none.
Published specification: This document.
Applications which use this media type: This document type has been
used to download the session policy of a domain to SIP user agents.
Additional Information:
Magic Number: None
File Extension: .wif or .xml
Macintosh file type code: "TEXT"
Personal and email address for further information: Gonzalo
Camarillo,
Intended usage: COMMON
Author/Change controller: The IETF.
8.2 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:sessionpolicy
This section registers a new XML namespace, as per the guidelines in
Hilt, et al. Expires April 18, 2004 [Page 21]
Internet-Draft Session-Independent SIP Session Policies October 2003
[4]
URI: The URI for this namespace is
urn:ietf:params:xml:ns:sessionpolicy.
Registrant Contact: IETF, SIPPING working group,,
Gonzalo Camarillo,
XML:
BEGIN
Session Policy Namespace
Namespace for Session Policy Information
application/session-policy+xml
See RFCXXXX.
END
Hilt, et al. Expires April 18, 2004 [Page 22]
Internet-Draft Session-Independent SIP Session Policies October 2003
9. Open Issues
The following issues are still open:
o Policy server discovery. Is automatic discovery of home domain and
access network domain policy server desirable? It seems that these
are the two domains that will most likely want to provide
policies. Automatic discovery of policy servers in both domains
would make deployment of policies easier and manual configuration
of multiple policy servers does not seem to be attractive.
However, it complicates user agents and the current procedure
overloads the user name sessionpolicies.
o XCAP. Would it make sense to require the use of XCAP for policy
packages? XCAP already provides a number of functionalities that
are most likely needed in a policy package. Requiring XCAP
restricts the number of protocols that need to be supported by a
client. Otherwise, a client that supports multiple packages might
need to implement a lot of different protocols and document
formats. Would requiring HTTP and XML do the job?
o Mandatory and optional policies. What is the best way to indicate
if the acceptance of a policy is required or optional? Does it
make sense to define this case-by-case or is a general required/
optional definition sufficient for a policy package?
Hilt, et al. Expires April 18, 2004 [Page 23]
Internet-Draft Session-Independent SIP Session Policies October 2003
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[3] Hilt, V. and J. Rosenberg, "A Framework for Session-Specific
Intermediary Session Policies in SIP", September 2003.
[4] Mealling, M., "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-05 (work in progress), June
2003.
[5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[7] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[8] Olson, S., "A Mechanism for Content Indirection in Session
Initiation Protocol (SIP) Messages",
draft-ietf-sip-content-indirect-mech-03 (work in progress),
June 2003.
[9] Petrie, D., "A Framework for SIP User Agent Configuration",
draft-ietf-sipping-config-framework-00 (work in progress),
March 2003.
[10] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[11] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-01 (work in progress), March 2003.
[12] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-rosenberg-simple-xcap-00 (work in progress), May 2003.
[13] Rosenberg, J., "Requirements for Session Policy for the Session
Initiation Protocol (SIP)",
draft-ietf-sipping-session-policy-req-00 (work in progress),
June 2003.
[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Hilt, et al. Expires April 18, 2004 [Page 24]
Internet-Draft Session-Independent SIP Session Policies October 2003
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[15] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.
Rayhan, "Middlebox communication architecture and framework",
RFC 3303, August 2002.
Authors' Addresses
Volker Hilt
Bell Labs/Lucent Technologies
101 Crawfords Corner Rd
Holmdel, NJ 07733
USA
EMail: volkerh@bell-labs.com
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
East Hanover, NJ 07936
USA
EMail: jdrosen@dynamicsoft.com
Hilt, et al. Expires April 18, 2004 [Page 25]
Internet-Draft Session-Independent SIP Session Policies October 2003
Appendix A. Acknowledgements
Many thanks to Markus Hofmann for his contributions to this draft.
Hilt, et al. Expires April 18, 2004 [Page 26]
Internet-Draft Session-Independent SIP Session Policies October 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Hilt, et al. Expires April 18, 2004 [Page 27]
Internet-Draft Session-Independent SIP Session Policies October 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hilt, et al. Expires April 18, 2004 [Page 28]