Session Initiation Proposal                                      V. Hilt
Investigation
SIPPING Working Group                                            V. Hilt
Internet-Draft                             Bell Labs/Lucent Technologies
Internet-Draft                                              G. Camarillo
Expires: April 24, August 10, 2005                                    G. Camarillo
                                                                Ericsson
                                                            J. Rosenberg
                                                           Cisco Systems
                                                        October 24, 2004

    Session-Independent
                                                        February 9, 2005

 Session Initiation  Protocol (SIP) Session Policies -
                      Mechanism Document Format
               and Policy Schema
               draft-ietf-sipping-session-indep-policy-01 Session-Independent Delivery Mechanism
               draft-ietf-sipping-session-indep-policy-02

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 24, August 10, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004). (2005).

Abstract

   This draft specifies an XML schema for profile data for SIP
   session-policies.  It defines a delivery mechanism for SIP
   session-policies session policies that are
   is independent of a specific SIP session.  It also defines the Basic
   Session Policy Format (BSPF), which is a minimal, XML-based format
   for session policies.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Session-Independent Policy Mechanism . . . . . . . . . . . . .   4
     3.1  Subscriber Behavior  . . . . . . . . . . . . . . . . . . .   4
     3.2  Notifier Behavior  . . . . . . . . . . . . . . . . . . . .   6
   4.  Session   Policy Schemas Format Design . . . . . . . . . . . . . . . . . . . .   6
     4.1   Specifying Constraints  Policy Model . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2   Extensibility  Unidirectional Policies  . . . . . . . . . . . . . . . . .   7
     4.3  Per-Stream Policies  . . . . . . . . . . . . . . . . . . .   7
     4.3   General Policy Schema
     4.4  Merging Policies . . . . . . . . . . . . . . . . . . . . .   7
       4.3.1   Elements
   5.   Basic Session Policy Format  . . . . . . . . . . . . . . . .   8
     5.1  MIME Type and Attributes Namespace  . . . . . . . . . . . . . . . . .   8
     4.4   Media Policy Schema
     5.2  Extensibility  . . . . . . . . . . . . . . . . . . . . . .   9
       4.4.1   Elements and Attributes
     5.3  XML Format Definition  . . . . . . . . . . . . . . . . . .   9
       4.4.2   Conflict Resolution
       5.3.1  The <session-policy> Element . . . . . . . . . . . . .   9
       5.3.2  The <context> Element  . . . . 11
       4.4.3   Example . . . . . . . . . . . .   9
       5.3.3  The <domain> Element . . . . . . . . . . . 11
     4.5   Protocol Policy Schema . . . . . .  10
       5.3.4  The <contact> Element  . . . . . . . . . . . . 12
       4.5.1   Elements and Attributes . . . .  10
       5.3.5  The <info> Element . . . . . . . . . . . 12
       4.5.2   Conflict Resolution . . . . . . .  10
       5.3.6  The <entity> Element . . . . . . . . . . 14
       4.5.3   Example . . . . . . .  10
       5.3.7  The <media-types> Element  . . . . . . . . . . . . . .  10
       5.3.8  The <media-type> Element . . 15
     4.6   Media Routing Policy Schema . . . . . . . . . . . . .  11
       5.3.9  The <codecs> Element . . 15
       4.6.1   Elements and Attributes . . . . . . . . . . . . . . . 16
       4.6.2   Conflict Resolution  11
       5.3.10   The <codec> Element  . . . . . . . . . . . . . . . .  12
       5.3.11   The <media-intermediary> Element . 17
       4.6.3   Example . . . . . . . . .  12
       5.3.12   The <int-uri> Element  . . . . . . . . . . . . . . 17
   5.  Schema Definitions .  13
       5.3.13   The <int-lroute> Element . . . . . . . . . . . . . .  13
       5.3.14   The <max-bandwidth> Element  . . . . . . . 18
     5.1   General Policy Schema . . . . .  13
       5.3.15   The <qos> Element  . . . . . . . . . . . . . 18
     5.2   Media Policy Schema . . . .  14
       5.3.16   Open Issue: Other Elements . . . . . . . . . . . . .  14
     5.4  Example  . . 18
     5.3   Protocol Policy Schema . . . . . . . . . . . . . . . . . . 19
     5.4   Media Routing Policy . . . . .  14
     5.5  Schema Definition  . . . . . . . . . . . . . . . 20 . . . . .  15
   6.   Security Considerations  . . . . . . . . . . . . . . . . . . . 22  18
   7.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  18
     7.1  MIME Registration for application/session-policy+xml . . .  18
     7.2  URN Sub-Namespace Registration for
          urn:ietf:params:xml:ns:sessionpolicy . . . . . . . . . . . 22  19
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23  21
   8.   References . . . . . . . . . . . . . . . . . . . . . . . . . . 22  20
   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23  21
        Intellectual Property and Copyright Statements . . . . . . . . 24  23

1.  Introduction

   Some domains have policies in place, which impact the sessions
   established using the Session Initiation Protocol (SIP) [10]. [15].  These
   policies are often needed to support the network infrastructure or
   for the execution of services.  For example, wireless networks
   usually have limited resources for media traffic.  During periods of high
   activity, a  A wireless network
   provider may want to restrict codec usage on the network to lower
   rate codecs. codecs or disallow the use of high bandwidth media types such as
   video.

   In another example, a SIP network has a resource reservation
   infrastructure in place, which enables user agent agents to request Quality
   of Service (QoS) for media streams.  With session policies, the
   network can tell user agents that a QoS infrastructure is using present and
   ask user agents to use specific parameters or provide certain
   credentials when requesting QoS.

   In a network which
   connects third example, a user has subscribed to a service that requires
   the public Internet media streams to be routed through a firewall at the network
   edge. media intermediary.  The
   service provider would like to tell the user agent to direct the
   media streams to the appropriate open ip/ports on that firewall. this intermediary and to use a certain source
   routing scheme (e.g.  IP-in-IP tunneling).  Knowing this policy
   enables these user agents to setup sessions with
   user agents on the public Internet.

   In a third example, a domain A has a limited bandwidth pipe to
   another domain B.  The pipe is realized through two routers that are
   managed.  Domain A would like to direct each call user to one of the
   routers based on their capacity.  With session policies, use this service in any network from which the domain
   intermediary can inform the user agent about the route with the most capacity
   available. be reached.

   Domains sometimes enforce policies they have in place.  For example,
   a domain might have a configuration in which all packets containing a
   certain audio codec are dropped.  Unfortunately, enforcement
   mechanisms usually do not inform the user about the policies they are
   enforcing and silently keep the user from doing anything against
   them.  This may lead to the malfunctioning of devices that is
   incomprehensible to the user.  With session policies, the user knows
   about the restricted codecs and can use a different codec or simply
   connect to a domain with less stringent policies.  Session policies
   provide an important combination of consent coupled with enforcement.
   That is, the user becomes aware of the policy and needs to act on it,
   but the provider still retains the right to enforce the policy.

   Some policies are created

   Session-policies can be set up in two different ways: specifically
   for a certain session or independent of a session.  Such  Session-specific policies
   are created for one particular session, usually require that the user agent provides information
   about the under consideration
   of certain aspects of this session to (e.g.  the network IP addresses and receives policies ports
   that are used for media).  Since session-specific policies are
   tailored to this session.  Session-specific a session, they only apply to the session they are
   created for.  These policies can be set up
   using require a delivery mechanism that
   enables the exchange of session policy information at the time a
   session is established.  The framework for session-specific policies [3].

   Session
   [3] defines such a delivery mechanism for session-specific policies.

   Session-independent policies on the other hand are often independent of a certain
   specific session and generally apply to the sessions that are set up by a user
   agent.  An example is a policy which prohibits the use of
   high-bandwidth codecs.  In principle, these policies could also be set up on a
   session-to-session basis.
   delivered to user agents individually for each session, using the
   session-specific policy framework.  However, since these policies
   apply to many sessions, it is much more efficient to
   enable user agents to obtain the policies relevant for deliver them and to
   inform the user
   agents about changes in these policies. only when the user agent is initialized or a policy changes.
   This draft defines a delivery mechanism for delivering session-independent policies to
   user agents.
   policies.

   This draft also defines XML schemas for session policies.  It defines the Basic Session Policy Format (BSPF).  BSPF
   is a general minimal session policy schema acting as format aimed at achieving
   interoperability between different user agents and policy servers.
   This format introduces a framework for session
   policies.  It also common data model and defines schemas for media policies, protocol
   policies a basic set of
   policy elements.  The format is based on XML [16] and media routing policies.  Policy instance documents can be delivered to user agents as session-independent policies extended
   using the
   mechanisms below or as session-specific policies [3].

      Note: XML extension mechanisms.  The difference between document format is independent
   of the policy delivery mechanism and can be used for
   session-independent and session-specific policies needs more discussion here. session policies.

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.  Session-Independent Policy Mechanism

   This draft defines a mechanism for the delivery of
   session-independent policies to UAs.

   Session-independent policies can be part of delivered to UAs using the device configuration and
   mechanism defined in the Framework for SIP User  Agent Profile
   Delivery [12].  Session-independent policies can reside on the same
   server as other configuration server.  They information and they can be delivered
   to UAs in conjunction with the device configuration. this information.  Session-independent
   policies may can also
   be reside on a separate policy server, which is
   independent of other a configuration information and reside on
   different servers.

   This mechanism enables UAs to indicate their support for session
   policies and to server.  A UA may receive
   session-independent policies from different multiple policy servers.  A UA
   subscribes  The
   following sections describe the subscription to the
   session-independent policies.  It receives these
   policies when the subscription is established and is notified  if
   updates to session policies become available.  The
   session-independent policy mechanism is based on the Framework relevant for
   SIP User  Agent Profile Delivery [7] and RFC3265 [9]. a UA.

3.1  Subscriber Behavior

   A UA can express interest in session-independent policies by
   subscribing to session policies a policy server. using the mechanism defined in [12].
   If the UA has already received the URIs of all relevant session
   policy documents servers (e.g., through configuration) it SHOULD use these URIs
   to create a
   subscription as defined in [7]. subscribe to session-independent policies.

   Session-independent policies are frequently provided to a UA by the
   following two network domains: the domain a user registers at (i.e.,
   the domain in the address-of-record (AoR)) and the domain the UA is
   physically connected to.  The  A policy server in the AoR-domain may, for
   example, provide policies that are needed for services the user has subscribed. subscribed
   to.  The domain that provides the physical network connection may hand
   have policies helping needed to maintain ensure the functionality operativeness of the network,
   e.g., by limiting the bandwidth available to a single UA can consume. UA.  A UA can SHOULD
   attempt to subscribe to these two domains without having previous knowledge
   about the policy server URI by servers in both domains.  These
   subscriptions are established using the profile-types "user" (for subscriptions to
   the AoR-domains) and the "local" defined in [7].  Since a (for subscriptions to the network
   domain) profile-types [12].  A UA has no way of knowing whether a
   domain has a policy server, it SHOULD attempt to subscribe to modify these
   two profile-types if the subscriptions
   as described below in following events occur: events:

   o  One (or more) AoRs registered by the  The UA change.  This might be due
      to a change in changes the AoR registration status of an existing user one of its AoR.  This
      occurs, for example, when a UA starts up and registers its AoRs,
      when it shuts down and deregisters AoRs, or when a user new AoR is
      added
      to/removed from the set of users of to a device.  The UA.  In these events, the UA SHOULD
      subscribe establish
      subscriptions for each new AoR that as changed using the "user" as well as and the "local" profile-type.
      profile-types.  It SHOULD terminate all the subscriptions for all AoRs not in use any more.
      that have been removed.
   o  The domain the UA is connected to changes.  The UA SHOULD create a
      new subscription for each AoR it maintains using the "local" profile-type.  It
      SHOULD terminate all existing subscriptions for the "local"
      profile-type.  It does not need to change the subscriptions for
      "user" profiles.

   If a subscriber is unable to successfully establish a subscription,
   it SHOULD NOT attempt to re-try this particular subscription at a
   later point, subscription, unless one of the
   above events occurs again.  This is to limit the number of SUBSCRIBE
   requests sent within domains that do not support session-policies.

   A subscriber compliant to this specification MUST indicate its
   support for session-independent session policies by adding the MIME
   types of supported session policy formats to the Accept header of the
   SUBSCRIBE request.  This specification defines the new MIME type
   "application/session-policy+xml".  All
   "application/session-policy+xml", which MUST be supported by UAs
   compliant to this
   specification MUST support this MIME type and MUST include it in the
   Accept header of SUBSCRIBE requests.

      OPEN ISSUE: The subscriber specification.  UAs MAY also needs to be able to indicate support for a certain XML schema, i.e.,
   MIME type extensions (e.g.  an additional XML namespace! namespace) using [4].

   A subscriber may receive a 406 in response to a SUBSCRIBE request.
   This indicates that the notifier requires the support of a session
   policy format that was not in the Accept header of the SUBSCRIBE
   request.  This means that the notifier has session policies that are
   required in the network but not supported by the subscriber.  As a
   consequence, the subscriber may experience difficulties when setting
   up a session without these policies.

3.2  Notifier Behavior

   A network may have session policies in place that must be supported
   by a UA.  UAs that do not support these policies may experience
   problems when setting up a session.  For example, a network may have
   a policy enabling firewall traversal.

   A UA lists all the session policy formats it supports in the Accept
   header of a SUBSCRIBE request.  If the notifier receives a SUBSCRIBE
   request that request, which does
   not contain the list all MIME types of all policy formats
   required and MIME type extensions in the network, Accept header
   that are needed for policies, it MUST reject the request with a 406
   response.  A policy format is required, needed, if the network has policy
   documents policies in
   this format and these documents contain constraints that must be applied used by the UA.  The notifier SHOULD NOT
   return a 406 if an unsupported format only contains optional policies.

4.  Session  Policy Schemas Format Design

   The schemas for session policies defined in this document extend the
   schema following sections describe design considerations for user agent profile data sets [8].  This simplifies the
   processing of policy data and other user agent configuration data and
   enables them to share the delivery mechanisms and to co-exist in the
   same instance documents.

   This draft specifies a general schema an
   XML-based model for session policies, which
   covers the common policies.

4.1  Policy Model

   Session policies influence aspects of session policies.  It acts as a
   framework schema for SIP session policies.  Based on this framework, by defining
   constraints.  A constraint impacts a specific aspect of a SIP session policy schemas
   (e.g.  the codecs that can be defined.  This draft defines used in this session).  Policy
   constraints are modeled as XML elements.  Each policy schemas element
   expresses a certain constraint.  Policy elements can contain a simple
   value or act as a container, which holds multiple alternative values
   for media policies, protocol policies and media
   routing policies.  It is expected this policy.

   Elements that other session policy schemas
   will be defined in the future. express policies have a 'policy' attribute.  This specification makes use
   attribute defines the constraining properties of the XML namespaces. element.
   The namespace URIs
   for schemas following values are defined for the 'policy' attribute:

   o  mandatory: the value contained in this specification are URNs [5], using the
   namespace identifier 'ietf' defined by RFC 2648 [6] element is mandatory and extended by
   [4].

4.1  Specifying Constraints

   Policies are defined by using the constraint elements defined
      MUST be used in [8].
   The specification of constraints sessions.  This is centered around the concept of a
   working profile.  A working profile default value that is used
      if the set of properties a UA 'policy' attribute is
   actually using during operation.  The following sections defines how
   session policies constraints influence the working profile of a UA.

   forbid - omitted.
   o  allow: the values of elements value contained inside of a forbid in the element
      MUST NOT is allowed and MAY be
      used in sessions.
   o  disallow: the working profile.  If a policy element value contained in a forbid the element is in the working profile, it forbidden and MUST
      NOT be
      removed.  For example, the forbid element may contain the name of
      codecs that are prohibited used in the local local network.  The forbid
      element sessions.

   Polices consisting of one single value can contain empty be expressed by a simple
   policy elements.  This means that all
      possible values element.  The following is an example of a policy defining an
   upper limit for that element MUST media bandwidth:

   <max-bandwidth>80</max-bandwidth>

   Policies consisting of multiple values can be removed from the working
      profile.  For example, expressed using a <codec /> element in
   container element.  The container contains multiple elements, which
   define possible values.  The policy attribute of the forbid container
      indicates that all codecs must be removed from
   specifies the working
      profile.  Specific codecs can be added policy that applies to the working profile
      again by listing them all values not listed in a set_all, set_one or set_any the
   container.  The policy attribute of each element
      inside in the same container
   defines the same property_set.  Policy element values policy for that item.  The following example shows a
   policy that
      were removed requires the media type audio and allows video in
   sessions:

   <media-types policy="disallow">
     <media-type policy="mandatory">audio</media-type>
     <media-type policy="allow">video</media-type>
   </media-types>

4.2  Unidirectional Policies

   Some policies only affect media streams flowing into one property_set can't direction,
   e.g., only outgoing streams.  Unidirectional policies can be added again
   expressed by adding a
      different property_set.  This would constitute a 'direction' attribute to the respective policy conflict
      between
   element.

   The 'direction' attribute can have the two property_sets.
   set_all - following values:

   o  recvonly: the set_all element contains policy element values that
      MUST be present in only applies to incoming streams.
   o  sendonly: the working profile of a UA.  They MUST be
      added policy only applies to outgoing streams.
   o  sendrecv: the working profile policy applies to streams in both directions.  This
      is the default value that is used if they are supported by the UA and
      not forbidden by another property_set.  A 'direction' attribute is
      omitted.

4.3  Per-Stream Policies

   Policies can be specific to a certain media stream.  The stream to
   which a policy conflict occurs
      if they can't applies to must be added identifiable through a label [7].
   Per-stream policies can be expressed by adding a 'label' attribute to
   the working profile.
   set_one - respective policy element.  Such a policy only applies to the semantics of
   identified stream.  If the set_one element label value is similar unknown to the
      set_all element except that the set_one element may contain
      alternative policy element and the UA MUST apply recipient,
   the first policy
      element must be ignored.

   Per-stream policies require that does not cause conflicts.
   set_any - the set_any element contains policy element values that
      SHOULD be added server has access to the working profile if they are supported by
   session description in order to extract the UA and do not conflict with other stream label.  For this
   reason, per-stream policies are typically used in session-specific
   policies.

4.4  Merging Policies

   A UA MUST process may receive policy documents from multiple sources, which need
   to be merged into a single combined policy document the UA can work
   with.

   Policies that define a single value (e.g.  maximum bandwidth) require
   the selection of one value during the forbid merging process.  The selection
   criteria must be defined individually for each element before processing (e.g.  select
   lowest value) in the set_all,
   set_one, schema definition.

   Policies that allow multiple values can be merged by combining all
   values and set_any elements within adjusting the 'policy' attribute for values that exist in
   both documents.  Table 1 provides a property_set.

      Note: The structure of matrix for merging the 'policy'
   attributes.  Additional merging rules may be required for some
   elements.  They must be specified in the schema definition.

   Some constellations are not feasible and constitute a policy conflict
   that can not be resolved automatically.  If the way constraints conflicting policies
   are
      specified has changed significantly since enforced by the network, the UA may experience difficulties when
   setting up a session.

   pol 1 \ pol 2 | mandatory |   allow   | disallow
   --------------+-----------+-----------+-----------
   mandatory     | mandatory | mandatory | conflict!
   allow         | mandatory |   allow   | disallow
   disallow      | conflict! | disallow  | disallow

               Table 1: merging policies.

   The combined policy MUST again be valid and well-formed according to
   policy schema definitions.  A policy conflict occurs if the combined
   policy is not a well-formed document after the last revision. merging process is
   completed.

5.  Basic Session Policy Format

   The Basic Session Policy Format (BSPF) defines the structure of and a
   root element for session policy documents.  It provides a minimal set
   of policy elements as required by [14].  To enable interoperability
   between UAs and policy servers, this format MUST be supported by all
   UAs compliant to this specification.

      Note: It is the goal was to better align keep this specification aligned with the
      schema for user agent profile data set framework and sets [13] to simplify the
      processing of policy and configuration data.

5.1  MIME Type and Namespace

   The MIME type for the Basic Session Policy Format is:

      application/session-policy+xml

   This specification makes use of policies.

4.2 XML namespaces [5].  The namespace
   URIs for schemas defined in this specification are URNs [8], using
   the namespace identifier 'ietf' defined by [9] and extended by [6].
   The namespace URN for the BSPF schema is:

      urn:ietf:params:xml:ns:sessionpolicy

5.2  Extensibility

   Other

   The BSPF format can be extended using XML extension mechanisms.  In
   particular, elements from different XML namespaces MAY be present
   within an
   element of a policy schema BSPF document for the purposes of extensibility; elements or
   attributes from unknown namespaces MUST be ignored.

4.3  General Policy Schema

   The general session policy schema defines

5.3  XML Format Definition

   A BSPF document is an XML [16] document that MUST be well-formed and
   MUST be valid according to schemas, including extension schemas,
   available to the elements validator and attributes
   that are common applicable to all session policy schemas.  All session policy the XML document.  BSPF
   documents MUST import this schema. be based on XML 1.0 and MUST be encoded using UTF-8.

5.3.1  The namespace <session-policy> Element

   The root element of the general session policy schema is:
      urn:ietf:params:xml:ns:sessionpolicy

   This document specifies a MIME type for policy instance documents. BSPF document is the <session-policy> element.

   The new MIME type is:
      application/session-policy+xml

4.3.1  Elements <session-policy> element MAY contain an optional <context>
   element and Attributes

   The following elements are defined in the session policy schema.
   They are optional elements that MAY appear once inside a settings
   element [8].  They do not refer to a particular property set and
   therefore appear outside of a property_set element.

4.3.1.1  Version

   The version element allows the recipient to properly order setting
   instances.  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.

4.3.1.2  Domain

   The domain element contains a URI that identifies the domain to which
   this setting instance belongs to.

4.3.1.3  Entity

   The entity element contains a URI that identifies the user or device
   whose policy information is reported in this setting instance.  If
   this element is not present, the setting applies to all entities on a
   device.

4.3.1.4  Include Target

   The includeTarget element contains a URI that identifies the remote
   target of a dialog.  A setting which in which this element is
   contained applies to all dialogs which have this URI as their remote
   target.  Missing URI elements MUST match to any value.  For example,
   a URI without a user name matches to all users in this domain.

4.3.1.5  Exclude Target

   The excludeTarget element contains a URI that identifies the remote
   target of a dialog.  The setting in which this element is contained
   applies to all dialogs which do not have this URI as the remote
   target.  Missing URI elements MUST match to any value.  For example,
   a URI without a user name matches to all users in this domain.

4.3.1.6  Info

   The info element provides a short textual description of the setting
   that should be intelligible to the human user.

4.4  Media Policy Schema

   The media policy schema defines the elements and attributes needed to
   describe the characteristics of media streams.

   The namespace of the media policy schema is:
      urn:ietf:params:xml:ns:mediapolicy

4.4.1  Elements and Attributes

   The following elements and attributes are defined in the media policy
   schema.

4.4.1.1  Media

   The media element defines a media policy.  A media element MAY appear
   zero, one or multiple times in a constraint element.

   The media element has the following sub-elements.

4.4.1.1.1  Max Bandwidth

   The maxBandwidth element defines the maximum bandwidth in kilobits
   per second an entity can count on.

   The maxBandwidth element is optional and can only appear once within
   a media element.  All subsequent instances MUST be ignored.  It has
   no meaning and MUST be ignored if it is inside a forbid constraint.

4.4.1.1.2  Maxno Streams

   The maxnoStreams element defines the maximum number of streams an
   entity is allowed to handle at the same time.

   The maxnoStreams element is optional and can only appear once within
   a media element.  All subsequent instances MUST be ignored.  It has
   no meaning and MUST be ignored if it is inside a forbid constraint.

4.4.1.1.3  Maxno Sessions

   The maxnoSessions element defines the maximum number of sessions an
   entity is allowed to establish at the same time.

   The maxnoSessions element is optional and can only appear once within
   a media element.  All subsequent instances MUST be ignored.  It has
   no meaning and MUST be ignored if it is inside a forbid constraint.

4.4.1.1.4  Maxno Streams Session

   The maxnoStreamsSession element defines the maximum number of streams
   an entity is allowed to establish within a session.

   The maxnoStreamsSession element is optional and can only appear once
   within a media element.  All subsequent instances MUST be ignored.
   It has no meaning and MUST be ignored if it is inside a forbid
   constraint.

4.4.1.1.5  Max Bandwidth Session

   The maxBandwidthSession element defines the maximum bandwidth in
   kilobits per second available to the entity within one session.

   The maxBandwidthSession element is optional and can only appear once
   within a media element.  All subsequent instances MUST be ignored.
   It has no meaning and MUST be ignored if it is inside a forbid
   constraint.

4.4.1.1.6  Max Bandwidth Stream

   The maxBandwidthStream element defines the maximum bandwidth in
   kilobits per second available to the entity for one stream.

   The maxBandwidthStream element is optional and can only appear once
   within a media element.  All subsequent instances MUST be ignored.
   It has no meaning and MUST be ignored if it is inside a forbid
   constraint.

4.4.1.1.7  Type

   The type element identifies a media type.  The value of this element
   MUST be the name of a IANA registered media type (see [2]), such as
   "audio", "video", "text", or "application".

   The type element is optional and MAY appear multiple times within a
   media element.

4.4.1.1.8  Codec

   The codec element identifies a media codec.  The value of this
   element MUST be the name of a registered MIME type for a encoding
   (see [2]), such as "PCMA", "G729", or "H263".

   The codec element is optional (including zero) <media-types>, <codecs>,
   <media-intermediary>, <qos>, and MAY appear multiple times within a
   media element.

4.4.1.1.9  Transport

   The transport element identifies a transport protocol for media
   streams.  The value of this element MUST be the name of a IANA
   registered protocol (see [2]), such <max-bandwidth> elements as "udp", "RTP/AVP", or
   "RTP/SAVP".

   The transport element has an optional attribute:

   type - the type attribute identifies the media type to which the
      transport element applies to.  The value of this attribute MUST be
      a legal type element value.

   The transport element is optional and MAY appear multiple times
   within a media element.

4.4.1.1.10  Direction

   The direction element identifies a media stream direction.  The value
   of this element MUST be "sendrec", "sendonly", or "recvonly". well as
   elements from other namespaces.

5.3.2  The direction element has an optional attribute:

   type - the type attribute identifies the media type to which the
      direction element applies to. <context> Element

   The value of this attribute MUST be
      a legal type <context> element value. provides context information about this policy.

   The direction <context> element is optional and in a <session-policy> element.  It
   MAY appear contain a <domain>, multiple times
   within <contact>, a media element.

4.4.2  Conflict Resolution

   The UA SHOULD alert <info>, and multiple
   <entity> elements.

      Merging policies: the user <context> element is not subject to merging.
      Information in case a media policy conflicts with
   another policy.

      OPEN ISSUE: Can we the context element may be more specific what used to do if a conflict
      occurs in assist the general case?

4.4.3  Example

   The following example describes user
      if a policy conflict occurs.  Policies that limits the number of
   streams affect different
      entities (e.g.  different AoRs) on a UA can create to 4.  It only allows audio streams and
   prohibits the use of the PCMU user agent and PCMA codecs.  It requires the UA therefore have
      different <entity> values do not need to
   support RTP/AVP as be merged.  A policy
      affecting all entities on a transport and optionally allows RTP/SAVP but user agent (i.e.  no
   other transport protocols.  Audio streams can only <entity> element
      is specified) must be sent.

   <property_set>
     <forbid>
       <media>
         <type />
         <codec>PCMU</codec>
         <codec>PCMA</codec>
         <transport />
       </media>
     </forbid>
     <set_all>
       <media>
         <maxnoStreams>4</maxnoStreams>
         <type>audio</type>
         <transport>RTP/AVP</transport>
         <direction type="audio">sendonly</direction>
       </media>
     </set_all>
     <set_any>
       <media>
         <transport>RTP/SAVP</transport>
       </media>
     </set_any>
   </property_set>

4.5  Protocol Policy Schema

   The protocol policy schema defines the elements and attributes needed
   to describe protocol characteristics.

   The namespace of merged with the protocol policy schema is:
      urn:ietf:params:xml:ns:protocolpolicy

4.5.1  Elements and Attributes for a specific
      entity.

5.3.3  The following elements and attributes are defined in the protocol
   policy schema.

4.5.1.1  Protocol <domain> Element

   The protocol element defines a protocol policy.  Each protocols <domain> element contains the policy related to the usage of a particular
   protocol.  A protocol element MAY appear zero, one or multiple times
   in a constraint element.

   The protocol element has an optional attribute:

   name - the name attribute URI that identifies the name of the protocol, to domain which the policy of the protocol
   has issued this policy.

   The <domain> element is referring to.

   Each protocol element has the following sub-elements.

4.5.1.1.1  Proxy optional and MAY occur only once inside a
   <context> element.

5.3.4  The proxy <contact> Element

   The <contact> element identifies the contains a contact address (e.g.  a SIP URI or
   email address) under which the issuer of a proxy.  The proxy values
   MUST this policy can be used to create a route set. reached.

   The proxy <contact> element is optional and may appear MAY occur multiple times inside
   a
   protocol <context> element.  Multiple appearances of this element are ordered.
   It has no meaning and MUST be ignored if it is inside a forbid
   constraint.

4.5.1.1.2  Method

5.3.5  The method element identifies a method. <info> Element

   The value of this <info> element
   MUST be the name of provides a valid method within short textual description of the protocol identified by
   in policy
   that should be intelligible to the protocol element. human user.

   The method <info> element is optional and MAY appear multiple times within occur only once inside a
   protocol
   <context> element.

4.5.1.1.3  Option Tag

5.3.6  The optionTag element identifies an optionTag. <entity> Element

   The value of this <entity> element MUST be the name of an option tag registered for contains a URI that identifies the protocol
   identified by user or
   device whose policy information is reported in this policy instance.
   The policy only applies to the protocol sessions that involve this entity.  If
   this element in is not present, the IANA registry. policy applies to all entities on a
   UA.

   The optionTag <entity> element is optional and MAY appear occur multiple times
   within inside
   a protocol <context> element.

4.5.1.1.4  Transport

5.3.7  The transport element identifies a transport protocol for the
   protocol identified by the protocol element. <media-types> Element

   The value of this <media-types> element MUST identify expresses a valid transport policy for the given protocol.  For
   SIP, use of media
   types (e.g.  audio, video).  A policy defines the value MUST a value media types that is registered for
   must be used, may be used, or must not be used in a session.

   This element has an mandatory 'policy' attribute as defined in
   Section 4.1.  The 'policy' attribute specifies the transport
   header field parameter, such default policy for
   all media types that are not listed inside this element.

   This element has an optional 'direction' attribute as "TCP", "UDP", or "SCTP". defined in
   Section 4.2.

   The transport <media-types> element is optional in a <session-policy> element
   and MAY appear occur multiple times
   within a protocol element.

4.5.1.1.5  Body-disposition times.  It MUST contain one or more
   <media-type> elements.

      Merging policies: the 'policy' attribute of the <media-types>
      element and <media-type> elements with the same value is adjusted
      according to Table 1.

5.3.8  The <media-type> Element

   The body-disposition <media-type> element identifies defines a body-disposition.  The
   value policy for the use of the media
   type identified by this element elements value.  This value MUST be a the name
   of a IANA registered media type (see [2]), such as 'audio', 'video',
   'text', or 'application'.

   This element has a mandatory 'policy' attribute as defined in the IANA registry
   for Content-Dispositions. Section
   4.1.

   The body-disposition <media-type> element is optional mandatory and MAY appear occur multiple times within
   inside a protocol <media-types> element.

4.5.1.1.6  Body-format

5.3.9  The <codecs> Element

   A body-format

   The <codecs> element identifies expresses a body-format.  The value policy for the use of this
   element MUST codecs.  A
   policy can define that a codec must be used, may be used, or must not
   be used in a session.  A policy MUST allow the name use of at least one
   codec and MUST NOT define more than one mandatory codec for a MIME type registered media
   type.

   This element has a mandatory 'policy' attribute as defined in the IANA
   registry. Section
   4.1.  The body-format 'policy' attribute specifies the default policy for all
   codecs that are not listed inside this element.

   This element has an optional attribute:

   body-disposition - the body-disposition 'direction' attribute identifies the body
      disposition used with this body-format.  The value of this as defined in
   Section 4.2.

   This element has an optional 'label' attribute MUST be a value legal for the body-disposition element. as defined in Section
   4.3.

   The body-format <codecs> element is optional in a <session-policy> element and
   MAY appear occur multiple times
   within a protocol element.

4.5.1.1.7  Body-encryption

   The body-encryption indicates whether or not encryption is allowed
   for a particular body disposition.  This element times.  It MUST NOT have a
   value.

   The body-encryption element has the following optional attributes:

   body-disposition - contain one or more <codec>
   elements.

      Merging policies: the body-disposition 'policy' attribute identifies of the body
      disposition this encryption setting applies to.  The <codecs> element
      and <codec> elements with the same value of this
      attribute MUST be is adjusted according to
      Table 1.

5.3.10  The <codec> Element

   The <codec> element defines a value legal policy for the body-disposition element.
   body-format - the body-format attribute identifies use of the body format to
      which codec
   identified by this encryption setting applies to.  The elements value.  This value of this
      attribute MUST be the name of a
   registered MIME type for a encoding (see [2]), such as "PCMA",
   "G729", or "H263".

   This element has a value legal for the body-format element. mandatory 'policy' attribute as defined in Section
   4.1.

   The body-encryption <codec> element is optional mandatory and MAY appear occur multiple times
   within inside
   a protocol <codecs> element.

4.5.2  Conflict Resolution

5.3.11  The UA SHOULD alert the user in case <media-intermediary> Element

   The <media-intermediary> element expresses a protocol policy conflicts with
   another policy.

      OPEN ISSUE: Can we be more specific what to do if for routing a conflict
      occurs in the general case?

4.5.3  Example

   The following example describes
   media stream through a policy saying that use media intermediary.  The purpose of the
   MESSAGE method
   <media-intermediary> element is prohibited in the network.  It states that the use
   of to tell the option tag 100rel is required and preconditions are allowed.
   Other option tags are not allowed in UA to send the network.  The only MIME type media for message bodies allowed is "application/sdp" with
   a particular stream through an IP address and port of an
   intermediary.  Instead of merely sending the
   body-disposition "session".  Encryption is not allowed for bodies
   with body-disposition "session".

   <property_set>
     <forbid>
       <protocol name="SIP">
         <method>MESSAGE</method>
         <optionTag />
         <body-format />
         <body-encryption body-disposition="session" />
       </protocol>
     </forbid>
     <set_all>
       <protocol name="SIP">
         <optionTag>100rel</optionTag>
         <body-format body-disposition="session">application/sdp</body-format>
       </protocol>
     </set_all>
     <set_any>
       <protocol name="SIP">
         <optionTag>preconditions</optionTag>
       </protocol>
     </set_any>
   </property_set>

4.6  Media Routing Policy Schema

   The media routing schema defines there, the elements UA can
   instead specify a source route, which touches that intermediary, but
   also any other intermediaries and attributes needed then the final recipient.  Thus, if
   there are N hops, including the final recipient, there needs to describe address and ports of be a
   way for the media stream.  This schema can be
   used stream to route specify N destinations.  The way these N
   destinations should be identified when sending the media stream through a NAT, is
   expressed using the <int-lroute> element.

   This element has a firewall mandatory 'policy' attribute as defined in Section
   4.1).  This attribute defines whether routing media streams through
   this intermediary is mandatory or allowed.

   This element has an optional 'label' attribute as defined in Section
   4.3.

   The <media-intermediary> element is optional in a media
   relay. <session-policy>
   element and MAY occur multiple times.  The namespace order of
   <media-intermediary> element instances is significant.  It defines
   the protocol policy schema is:
      urn:ietf:params:xml:ns:mediaroutingpolicy

      OPEN ISSUE: This schema probably needs order in which the media intermediaries must be traversed.  The
   UA sends the media stream to go into a separate draft
      along with some text about the mechanics.

4.6.1  Elements intermediary listed first, then to
   the intermediary listed next and Attributes so on.  The following elements <media-intermediary>
   element MUST contain one <int-uri> and attributes one <int-lroute> element.

      Merging policies: the intermediaries defined in all policies are
      traversed.  For session-independent policies, intermediaries
      received through a subscription using the "local" profile-type are defined
      traversed before those received through a "user" profile-type
      subscription.  For session-specific policies, intermediaries are
      traversed in the protocol order in which policy schema.

4.6.1.1  Media Routing URIs are received (i.e.

      local intermediaries first).

5.3.12  The mediaRouting element defines a media routing policy.  A media
   routing element MAY appear zero, one or multiple times in a
   constraint element.

   Each protocol element has the following sub-elements.

4.6.1.1.1  Address <int-uri> Element

   The address <int-uri> element contains a URI that identifies the destination IP address
   and port number of a media
   stream, i.e., intermediary.  The UA uses this URI to
   send its media streams to the address that is contained in an SDP announcement
   for intermediary.  If a media stream. protocol uses
   multiple subsequent ports (e.g.  RTP) only the lowest port number
   needs to be identified.

   The address <int-uri> element occurs exactly once inside a
   <media-intermediary> element.

5.3.13  The <int-lroute> Element

   The <int-lroute> element MUST have the following attribute:

   direction - the direction attribute identifies the direction of a
      media stream. loose source routing protocol
   to be used with this intermediary.  The value of this element MUST can be "send" or "recv".
      It determines whether
   one of the element applies following:

   o  ip-in-ip: IP-in-IP tunneling  is used to specify the session
      description offer or answer. hops of media
      traversal.  The address element ultimate destination is optional and MAY appear at most once within specified in the
      destination IP of the innermost packet.  Each subsequent hop
      results in another encapsulation, with the destination of that hop
      in the destination IP address of the packet.
   o  ip-loose: IP provides a
   media loose routing element.

4.6.1.1.2  Port

   The port element identifies mechanism that allows the destination port
      sender of an IP datagram to specify a set of IP addresses that are
      to be visited on the way before reaching the final destination.
   o  media-specific: media stream,
   i.e., protocols can provide their own loose
      routing mechanism.  If that is the address case, the loose routing
      mechanism of that protocol is contained in used.  As an SDP announcement for example, SIP provides
      its own loose routing mechanisms with the Route header.  It can be
      used to direct an instant message using the SIP MESSAGE method
      through a set of intermediaries.
   o  none: if there is no loose-routing mechanism available, the media stream.

   The address element MUST have
      is just sent to the first media intermediary listed in the following attribute:

   direction - header.
      Note that this requires the direction attribute identifies intermediary to know where to forward
      the direction of packets to.  Such a
      media stream.  The value of this element MUST route must be "send" or "recv".
      It determines whether set up in the element applies to intermediary
      through other means.  For example, with session-specific policies,
      the policy server can extract the destination address from the
      session
      description offer or answer. description.

   The port <int-lroute> element is optional and MAY appear multiple times within occurs exactly once inside a
   media routing
   <media-intermediary> element.

4.6.1.1.3  Port Range

5.3.14  The <max-bandwidth> Element

   The portRange <max-bandwidth> element identifies a range of ports that apply to the
   destination of a media stream.  This can, for example, be used to
   determine contains the range of ports that maximum bandwidth in
   kilobits per second an entity can be used use for its media streams in
   SDP announcements.

   The address streams.

   This element MUST have the following attribute:

   direction - has an optional 'direction' attribute as defined in
   Section 4.2.  If the direction attribute identifies is present, the direction of a
      media stream.  The value of this
   <max-bandwidth> element MUST be "send" or "recv".
      It determines whether contains the element applies to bandwidth available in the session
      description offer or answer.
   identified direction.

   The portRange <max-bandwidth> element is optional and MAY appear multiple times
   within in a media routing element.  It has the following two
   sub-elements.

4.6.1.1.3.1  Start Port

   The startPort <session-policy> element identifies
   and MAY occur only once.

      Merging policies: the lowest port number that belongs
   to the port range.

   The startPort element MUST appear exactly once inside a port range
   element.

4.6.1.1.3.2  End Port max-bandwidth value is used.

      Open issue: The endPort element identifies the highest port number that belongs
   to maximum bandwidth policy is not part of the port range. policy
      requirements.  Should it be part of BSPF?

5.3.15  The endPort element MUST appear exactly once inside <qos> Element

      Open issue: what needs to go in here?

5.3.16  Open Issue: Other Elements

   A number of additional elements have been proposed for a policy
   language:

   o  maximum number of streams
   o  maximum number of sessions
   o  maximum number of streams per session
   o  maximum bandwidth per session
   o  maximum bandwidth per stream
   o  external address and port range
   element.

4.6.2  Conflict Resolution

   The UA SHOULD alert the user in case a
   o  media route policy conflicts
   with another policy.

      OPEN ISSUE: Can we be more specific what 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

   Is it desirable to add any of these to do if a conflict
      occurs in the general case?

4.6.3 BSPF format? Some of these
   items could become part of an extension to BSPF.

5.4  Example

   The following example describes a policy that instructs requires the UA to use of
   audio, allows the address 123.124.125.126 use of video and a port in prohibits the range use of 8000 - 9000 in other media
   types.  It allows the session descriptions it creates.  This information can assist a
   UA, for example, to traverse use of any codec except G.723 and G.729.  The
   policy also inserts a NAT.

   <property_set>
     <set_all>
       <mediaRouting>
         <address direction="recv">123.124.125.126</address>
         <portRange direction="recv">
           <startPort>8000</startPort>
           <startPort>9000</startPort>
         </portRange>
       </mediaRouting>
     </set_all>
   </property_set>

5.  Schema Definitions

5.1  General Policy Schema

   [TBD.]

5.2  Media Policy media intermediary into outgoing media streams.

   <session-policy>
     <context>
       <domain>example.com</domain>
       <contact>sip:policy_manager@example.com</contact>
       <info>Access network policies</info>
     </context>
     <media-types policy="disallow">
       <media-type policy="mandatory">audio</media-type>
       <media-type policy="allow">video</media-type>
     </media-types>
     <codecs policy="allow">
       <codec policy="disallow">G729</codec>
       <codec policy="disallow">G723</codec>
     </codecs>
     <media-intermediary direction="sendonly" policy="mandatory">
       <int-uri>123.234.123.234:6000</int-uri>
       <int-lroute>ip-in-ip</int-lroute>
     </media-intermediary>
   </session-policy>

5.5  Schema Definition

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:mediapolicy"
         xmlns:tns="urn:ietf:params:xml:ns:mediapolicy" targetNamespace="urn:ietf:params:xml:ns:sessionpolicy"
         xmlns:tns="urn:ietf:params:xml:ns:sessionpolicy"
         xmlns:xs="http://www.w3.org/2001/XMLSchema"
         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

     <xs:element name="media" type="tns:media"/> name="session-policy" type="tns:session-policy"/>

     <xs:complexType name="media"> name="session-policy">
       <xs:sequence>
         <xs:element name="maxBandwidth" type="xs:positiveInteger"
           minOccurs="0" maxOccurs="1"/>
         <xs:element name="maxnoStreams" type="xs:positiveInteger" name="context" type="tns:context" minOccurs="0"
           maxOccurs="1"/>
         <xs:element name="maxnoSessions" type="xs:positiveInteger"
           minOccurs="0" maxOccurs="1"/>
         <xs:element name="maxnoStreamsSession"
           type="xs:positiveInteger" minOccurs="0" maxOccurs="1"/>
         <xs:element name="maxBandwidthSession"
           type="xs:positiveInteger" minOccurs="0" maxOccurs="1"/>
         <xs:element name="maxBandwidthStream"
           type="xs:positiveInteger" minOccurs="0" maxOccurs="1"/>
         <xs:element name="type" type="xs:string" name="media-types" type="tns:media-types"
           minOccurs="0" maxOccurs="unbounded"/>
         <xs:element name="codec" type="xs:string" name="codecs" type="tns:codecs" minOccurs="0"
           maxOccurs="unbounded"/>
         <xs:element name="transport" type="tns:transport" name="media-intermediary"
           type="tns:media-intermediary" minOccurs="0"
           maxOccurs="unbounded"/>
         <xs:element name="direction" type="tns:direction" name="max-bandwidth" type="tns:max-bandwidth"
           minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:complexType>

     <xs:complexType name="transport">
       <xs:simpleContent>
         <xs:extension base="xs:string">
           <xs:attribute name="type" type="xs:string" use="optional"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

     <xs:complexType name="direction">
       <xs:simpleContent>
         <xs:extension base="tns:directionValue">
           <xs:attribute name="type" type="xs:string" use="optional"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

     <xs:simpleType name="directionValue">
       <xs:restriction base="xs:string">
         <xs:enumeration value="sendrec"/>
         <xs:enumeration value="sendonly"/>
         <xs:enumeration value="recvonly"/>
       </xs:restriction>
     </xs:simpleType>

   </xs:schema>

5.3  Protocol Policy Schema

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:protocolpolicy"
         xmlns:tns="urn:ietf:params:xml:ns:protocolpolicy"
         xmlns:xs="http://www.w3.org/2001/XMLSchema"
         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

     <xs:element name="protocol" type="tns:protocol"/>

     <xs:complexType name="protocol"> name="context">
       <xs:sequence>
         <xs:element name="proxy" name="domain" type="xs:anyURI" minOccurs="0"
            maxOccurs="unbounded"/>
         <xs:element name="method" type="xs:string" minOccurs="0"
            maxOccurs="unbounded"/>
         <xs:element name="optionTag" type="xs:string"
            minOccurs="0" maxOccurs="unbounded"/>
         <xs:element name="transport" type="xs:string"
            minOccurs="0" maxOccurs="unbounded"/>
         <xs:element name="body-disposition" type="xs:string"
            minOccurs="0" maxOccurs="unbounded"/>
         <xs:element name="body-format" type="tns:body-format"
            minOccurs="0" maxOccurs="unbounded"/>
           maxOccurs="1"/>
         <xs:element name="body-encryption" type="tns:body-encryption" name="contact" type="xs:anyURI" minOccurs="0"
           maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="name" type="xs:string" use="optional"/>
     </xs:complexType>

     <xs:complexType name="body-format">
       <xs:simpleContent>
         <xs:extension base="xs:string">
           <xs:attribute name="body-disposition" type="xs:string"
             use="optional"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

     <xs:complexType name="body-encryption">
       <xs:simpleContent>
         <xs:extension base="xs:string">
           <xs:attribute name="body-disposition" type="xs:string"
             use="optional"/>
           <xs:attribute name="body-format" type="xs:string"
             use="optional"/>
          </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

   </xs:schema>

5.4  Media Routing Policy Schema

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:mediaroutingpolicy"
         xmlns:tns="urn:ietf:params:xml:ns:mediaroutingpolicy"
         xmlns:xs="http://www.w3.org/2001/XMLSchema"
         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

           <xs:attribute name="type" type="xs:string" use="optional"/>
         <xs:element name="mediaRouting" type="tns:mediaRouting"/>

     <xs:complexType name="mediaRouting">
       <xs:sequence>
         <xs:element name="address" type="xs:anyURI" name="info" type="xs:string"
            minOccurs="0" maxOccurs="1"/>
         <xs:element name="port" type="tns:port" name="entity" type="xs:anyURI" minOccurs="0"
           maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:complexType>

     <xs:complexType name="media-types">
       <xs:sequence>
         <xs:element name="portRange" type="tns:portRange"
            minOccurs="0" name="media-type" type="tns:media-type" minOccurs="1"
           maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="policy" type="tns:policyValue"
         use="required"/>
       <xs:attribute name="direction" type="tns:directionValue"
         use="optional" default="sendrecv"/>
     </xs:complexType>

     <xs:complexType name="port">
       <xs:simpleContent>
         <xs:extension base="xs:anyURI"> name="codecs">
       <xs:sequence>
         <xs:element name="codec" type="tns:codec" minOccurs="1"
           maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="policy" type="tns:policyValue"
         use="required"/>
       <xs:attribute name="direction" type="tns:directionValue"
         use="optional" default="sendrecv"/>
       <xs:attribute name="label" type="xs:string" use="optional"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

     <xs:complexType name="portRange"> name="media-intermediary">
       <xs:sequence>
         <xs:element name="startPort" name="int-uri" type="xs:anyURI" minOccurs="1"
           maxOccurs="1"/>
         <xs:element name="endPort" type="xs:anyURI" name="int-lroute" type="tns:int-lroute" minOccurs="1"
           maxOccurs="1"/>
       </xs:sequence>
       <xs:attribute name="direction" type="tns:directionValue" name="policy" type="tns:policyValue"
         use="required"/>
       <xs:attribute name="label" type="xs:string" use="optional"/>
     </xs:complexType>

     <xs:complexType name="max-bandwidth">
       <xs:simpleContent>
         <xs:extension base="xs:positiveInteger">
           <xs:attribute name="policy" type="tns:policyValue"
             use="required"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

     <xs:complexType name="media-type">
       <xs:simpleContent>
         <xs:extension base="xs:string">
           <xs:attribute name="policy" type="tns:policyValue"
             use="required"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

     <xs:complexType name="codec">
       <xs:simpleContent>
         <xs:extension base="xs:string">
           <xs:attribute name="policy" type="tns:policyValue"
             use="required"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

     <xs:simpleType name="int-lroute">
       <xs:restriction base="xs:string">
         <xs:enumeration value="ip-in-ip"/>
         <xs:enumeration value="ip-loose"/>
         <xs:enumeration value="media-specific"/>
         <xs:enumeration value="none"/>
       </xs:restriction>
     </xs:simpleType>

     <xs:simpleType name="policyValue">
       <xs:restriction base="xs:string">
         <xs:enumeration value="mandatory"/>
         <xs:enumeration value="allow"/>
         <xs:enumeration value="disallow"/>
       </xs:restriction>
     </xs:simpleType>
     <xs:simpleType name="directionValue">
       <xs:restriction base="xs:string">
         <xs:enumeration value="send"/> value="sendrecv"/>
         <xs:enumeration value="sendonly"/>
         <xs:enumeration value="recv"/> value="recvonly"/>
       </xs:restriction>
     </xs:simpleType>

   </xs:schema>

6.  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.

7.  IANA Considerations

   [TBD.]

   This document registers a new MIME type,
   application/session-policy+xml, and registers a new XML namespace.

7.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 [10].

   Encoding considerations: Same as encoding considerations of
   application/xml as specified in RFC 3023 [10].

   Security considerations: See Section 10 of RFC 3023 [10] and Section
   6 of this specification.

   Interoperability considerations: none.

   Published specification: This document.

   Applications which use this media type: This document type has been
   used to download the session policy of a domain to SIP user agents.

   Additional Information:

   Magic Number: None

   File Extension: .wif or .xml

   Macintosh file type code: "TEXT"

   Personal and email address for further information: Volker Hilt,
   <volkerh@bell-labs.com>

   Intended usage: COMMON

   Author/Change controller: The IETF.

7.2  URN Sub-Namespace Registration for
    urn:ietf:params:xml:ns:sessionpolicy

   This section registers a new XML namespace, as per the guidelines in
   [6]

   URI: The URI for this namespace is
   urn:ietf:params:xml:ns:sessionpolicy.

   Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>,
   Volker Hilt, <volkerh@bell-labs.com>

           XML:

                BEGIN
                <?xml version="1.0"?>
                <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
                          "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
                <html xmlns="http://www.w3.org/1999/xhtml">
                <head>
                  <meta http-equiv="content-type"
                     content="text/html;charset=iso-8859-1"/>
                  <title>Session Policy Namespace</title>
                </head>
                <body>
                  <h1>Namespace for Session Policy Information</h1>
                  <h2>urn:ietf:params:xml:ns:sessionpolicy</h2>
                  <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
                </body>
                </html>
                END

8  References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Handley, M., Jacobson, V. and C. Perkins, "SDP: Session
         Description Protocol", draft-ietf-mmusic-sdp-new-20 (work in
         progress), September 2004.

   [3]   Hilt, V., Camarillo, G. and J. Rosenberg, "A Framework for
         Session-Specific Session Policies in the Session Initiation
         Protocol (SIP)", draft-hilt-sipping-session-spec-policy-01
         (work in progress), October 2004.

   [4]   Hilt, V., Rosenberg, J. and G. Camarillo, "Media Type Extension
         Negotiation in the Session Initiation Protocol (SIP) Accept
         Header Field", draft-hilt-sip-ext-neg-00 (work in progress),
         January 2005.

   [5]   Hollander, D., Bray, T. and A. Layman, "Namespaces in XML", W3C
         REC REC-xml-names-19990114, January 1999.

   [6]   Mealling, M., "The IETF XML Registry",
         draft-mealling-iana-xmlns-registry-05 (work in progress), June
         2003.

   [5]

   [7]   Levin, O. and G. Camarillo, "The SDP (Session Description
         Protocol) Label Attribute",
         draft-ietf-mmusic-sdp-media-label-01 (work in progress),
         January 2005.

   [8]   Moats, R., "URN Syntax", RFC 2141, May 1997.

   [6]

   [9]   Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
         August 1999.

   [7]

   [10]  Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
         3023, January 2001.

   [11]  Perkins, C., "IP Encapsulation within IP", RFC 2003, October
         1996.

   [12]  Petrie, D., "A Framework for Session Initiation Protocol User
         Agent Profile Delivery", draft-ietf-sipping-config-framework-04 draft-ietf-sipping-config-framework-05
         (work in progress), July October 2004.

   [8]

   [13]  Petrie, D., "A Schema for Session Initiation Protocol User
         Agent Profile Data Sets",
         draft-petrie-sipping-profile-datasets-00 (work in progress),
         July 2004.

   [9]   Roach, A., "Session

   [14]  Rosenberg, J., "Requirements for Session Policy for the Session
         Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [10] (SIP)",
         draft-ietf-sipping-session-policy-req-02 (work in progress),
         July 2004.

   [15]  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.

   [16]  Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T. and E.
         Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)",
         W3C REC REC-xml-20040204, February 2004.

Authors' Addresses

   Volker Hilt
   Bell Labs/Lucent Technologies
   101 Crawfords Corner Rd
   Holmdel, NJ  07733
   USA

   EMail: volkerh@bell-labs.com

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com

   Jonathan Rosenberg
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07054
   USA

   EMail: jdrosen@dynamicsoft.com jdrosen@cisco.com

Appendix A.  Acknowledgements

   Many thanks to Allison Mankin for the discussions and the suggestions
   for this draft.  Many thanks also to Dan Petrie and Martin Dolly.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2004). (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.