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

      Profile Data for

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

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, I certify each
   author represents that any applicable patent or other IPR claims of
   which I am he or she is aware have been or will be disclosed, and any of
   which I 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.
   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 January 8, April 24, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This draft specifies an XML schema for profile data for SIP session
   policies. This schema can be used within the user agent profile
   devliery framework to implement session-independent
   session-policies.  It defines a delivery mechanism for SIP session
   policies.
   session-policies that are independent of a specific SIP session.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Considerations for Policy-related Profile Data  Session-Independent Policy Mechanism . . . . . . . . . . . . .  4
   4.  User Agent Profile Data for Session Policies
     3.1   Subscriber Behavior  . . . . . . . . .  5
     4.1 . . . . . . . . . .  4
     3.2   Notifier Behavior  . . . . . . . . . . . . . . . . . . . .  6
   4.  Session Policy Document Format Schemas . . . . . . . . . . . . . . . . . .  5
       4.1.1   Protocols Element . .  6
     4.1   Specifying Constraints . . . . . . . . . . . . . . . . .  5
       4.1.2   Media Element .  6
     4.2   Extensibility  . . . . . . . . . . . . . . . . . . . . . .  7
     4.2
     4.3   General Policy Schema  . . . . . . . . . . . . . . . . . .  7
       4.3.1   Elements and Attributes  . . . . . . . . .  9
     4.3   Example . . . . . .  8
     4.4   Media Policy Schema  . . . . . . . . . . . . . . . . . . .  9
   5.  Security Considerations
       4.4.1   Elements and Attributes  . . . . . . . . . . . . . . .  9
       4.4.2   Conflict Resolution  . . . . 10
   6.  IANA Considerations . . . . . . . . . . . . . 11
       4.4.3   Example  . . . . . . . . . 10
     6.1   MIME Registration for application/session-policy+xml . . . 10
     6.2   URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:sessionpolicy . . . . . . . . . . . 11
       Authors' Addresses
     4.5   Protocol Policy Schema . . . . . . . . . . . . . . . . . . 12
       4.5.1   Elements and Attributes  . . . . . . . . . . . . . . . 12
   7.  References
       4.5.2   Conflict Resolution  . . . . . . . . . . . . . . . . . 14
       4.5.3   Example  . . . . . . . . . . . . . . 11
   A.  Acknowledgements . . . . . . . . . 15
     4.6   Media Routing Policy Schema  . . . . . . . . . . . . . . 13
       Intellectual Property . 15
       4.6.1   Elements and Copyright Statements Attributes  . . . . . . . . 14

1.  Introduction

   Some domains have policies in place, which impact the sessions
   established using the Session Initiation Protocol (SIP). These
   policies are typically needed to support the operation of the network
   infrastructure or certain services. For example, a SIP user agent
   might be located in a domain that is behind a Network Address
   Translator (NAT). This domain might have a  policy in place that
   requires the user agent to contact a TURN [10] relay before . . . . . . . 16
       4.6.2   Conflict Resolution  . . . . . . . . . . . . . . . . . 17
       4.6.3   Example  . . . . . . . . . . . . . . . . . . . . . . . 17
   5.  Schema Definitions . . . . . . . . . . . . . . . . . . . . . . 18
     5.1   General Policy Schema  . . . . . . . . . . . . . . . . . . 18
     5.2   Media Policy Schema  . . . . . . . . . . . . . . . . . . . 18
     5.3   Protocol Policy Schema . . . . . . . . . . . . . . . . . . 19
     5.4   Media Routing Policy Schema  . . . . . . . . . . . . . . . 20
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
       Intellectual Property and Copyright Statements . . . . . . . . 24

1.  Introduction

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

   In another example, a SIP user agent is using a network which
   connects to the public Internet through a firewall at the network
   edge.  The provider would like to tell the user agent to direct the
   media streams to the appropriate open ip/ports on that firewall.
   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 to one of the
   routers based on their capacity.  With session policies, the domain
   can inform the user agent about the route with the most capacity
   available.

   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 specifically for a certain session.  Such
   policies usually require that the user agent provides information
   about the session to the network and receives policies that are
   tailored to this session.  Session-specific policies can be set up
   using the framework for session-specific policies [3].

   Session policies are often independent of a certain session and
   generally apply to the sessions that are set up by a user agent.  In
   principle, these policies could also be set up on a
   session-to-session basis.  However, it is much more efficient to
   enable user agents to obtain the policies relevant for them and to
   inform the user agents about changes in these policies.  This draft
   defines a mechanism for delivering session-independent policies to
   user agents.

   This draft also defines XML schemas for session policies.  It defines
   a general session policy schema acting as a framework for session
   policies.  It also defines schemas for media policies, protocol
   policies and media routing policies.  Policy instance documents can
   be delivered to user agents as session-independent policies using the
   mechanisms below or as session-specific policies [3].

      Note: The difference between session-independent and
      session-specific policies needs more discussion here.

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 the device configuration and reside on the same
   configuration server.  They can be delivered to UAs in conjunction
   with the device configuration.  Session-independent policies may also
   be independent of other configuration information and reside on
   different servers.

   This mechanism enables UAs to indicate their support for session
   policies and to receive policies from different policy servers.  A UA
   subscribes to 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 for
   SIP User  Agent Profile Delivery [7] and RFC3265 [9].

3.1  Subscriber Behavior

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

   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 AoR-domain may, for example, provide
   policies that are needed for services the user has subscribed.  The
   domain that provides the physical network connection may hand have
   policies helping to maintain the functionality of the network, e.g.,
   by limiting the bandwidth a single UA can consume.  A UA can
   subscribe to these two domains without having previous knowledge
   about the policy server URI by using the profile-types "user" and
   "local" defined in [7].  Since a UA has no way of knowing whether a
   domain has a policy server, it SHOULD attempt to subscribe to these
   two profile-types if the following events occur:

   o  One (or more) AoRs registered by the UA change.  This might be due
      to a change in the AoR of an existing user or a user is added
      to/removed from the set of users of a device.  The UA SHOULD
      subscribe each AoR that as changed using the "user" as well as the
      "local" profile-type.  It SHOULD terminate all subscriptions for
      AoRs not in use any more.
   o  The domain the UA is connected to changes.  The UA SHOULD create a
      subscription for each AoR it maintains using the "local"
      profile-type.  It SHOULD terminate all existing subscriptions for
      the "local" profile-type.

   If a subscriber is unable to successfully establish a subscription,
   it SHOULD NOT attempt to re-try this particular subscription at a
   later point, 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 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 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 also needs to be able to indicate
      support for a certain XML schema, i.e., an XML namespace!

   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. Information about 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 does not contain the MIME types of all policy formats
   required in the network, it MUST reject the request with a 406
   response.  A policy format is required, if the network has policy
   documents in this format and these documents contain constraints that
   must be applied by the UA.  The notifier SHOULD NOT return a 406 if
   an unsupported format only contains optional policies.

4.  Session Policy Schemas

   The schemas for session policies defined in this document extend the
   schema 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 for session policies, which
   covers the common aspects of session policies.  It acts as a
   framework schema for session policies.  Based on this framework,
   specific session policy schemas can be defined.  This draft defines
   policy schemas for media policies, protocol policies and media
   routing policies.  It is essential expected that other session policy schemas
   will be defined in the future.

   This specification makes use of XML namespaces.  The namespace URIs
   for schemas defined in this specification are URNs [5], using the
   namespace identifier 'ietf' defined by RFC 2648 [6] and extended by
   [4].

4.1  Specifying Constraints

   Policies are defined by using the constraint elements defined in [8].
   The specification of constraints is centered around the concept of a user
   agent to successfully
   working profile.  A working profile is the set up of properties a session.

   In another example, SIP UA is
   actually using during operation.  The following sections defines how
   session policies constraints influence the working profile of a UA.

   forbid - the values of elements contained inside of a forbid element
      MUST NOT be used in the working profile.  If a wireless policy element
      value in a forbid element is in the working profile, it MUST be
      removed.  For example, the forbid element may contain the name of
      codecs that are prohibited in the local local network.  The network
   provider has limited resources forbid
      element can contain empty policy elements.  This means that all
      possible values for media traffic. During periods of
   high activity, that element MUST be removed from the working
      profile.  For example, a <codec /> element in the forbid container
      indicates that all codecs must be removed from the working
      profile.  Specific codecs can be added to the working profile
      again by listing them in a set_all, set_one or set_any element
      inside the same the same property_set.  Policy element values that
      were removed in one property_set can't be added again by a
      different property_set.  This would constitute a policy conflict
      between the two property_sets.
   set_all - the set_all element contains policy element values that
      MUST be present in the provider would like working profile of a UA.  They MUST be
      added to restrict codec usage on the
   network to lower rate codecs. In existing approaches, this is
   frequently accomplished working profile if they are supported by having the proxies examine UA and
      not forbidden by another property_set.  A policy conflict occurs
      if they can't be added to the SDP [2] in working profile.
   set_one - the body and remove semantics of the higher rate codecs or reject set_one element is similar to the call
      set_all element except that the set_one element may contain
      alternative policy element and
   require the UA MUST apply the first policy
      element that does not cause conflicts.
   set_any - the set_any element contains policy element values that
      SHOULD be added to start over the working profile if they are supported by
      the UA and do not conflict with other policies.

   A UA MUST process the forbid element before processing the set_all,
   set_one, and set_any elements within a different set property_set.

      Note: The structure of codecs. Having
   information about the current policy would enable user agents schema and the way constraints are
      specified has changed significantly since the last revision.  The
      goal was to
   initiate a session better align with the profile data set framework and
      to simplify the specification of policies.

4.2  Extensibility

   Other elements from different namespaces MAY be present within an acceptable codec.

   In a third example,
   element of a domain has established policies regarding policy schema for the
   type purposes of user agents extensibility;
   elements or attributes from unknown namespaces MUST be ignored.

4.3  General Policy Schema

   The general session policy schema defines the elements and attributes
   that can use their network. For example, are common to all session policy schemas.  All session policy
   documents MUST import this schema.

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

   This document specifies a domain
   could require MIME type for policy instance documents.
   The new MIME type is:
      application/session-policy+xml

4.3.1  Elements and Attributes

   The following elements are defined in the session policy schema.
   They are optional elements that user agents using its network use MAY appear once inside a particular
   protocol (e.g., SIP) with settings
   element [8].  They do not refer to a particular property set of extensions (e.g., preconditions
   must be used). A user agent needs to know the exact policy and
   therefore appear outside of a
   domain in order to be able to use property_set element.

4.3.1.1  Version

   The version element allows the right configuration recipient to send properly order setting
   instances.  Versions start at 0, and
   receive traffic in that domain.

   Some domains have policies in place that are enforced increment by network
   elements. For example, 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 might have element contains a configuration in URI that identifies the domain to which
   all packets containing
   this setting instance belongs to.

4.3.1.3  Entity

   The entity element contains a certain voice encoding are dropped.
   Unfortunately, enforcement mechanisms usually do not inform URI that identifies the user
   about the policies they are enforcing and silently keep or device
   whose policy information is reported in this setting instance.  If
   this element is not present, the user from
   doing anything against them. This may lead setting applies to all entities on a
   device.

4.3.1.4  Include Target

   The includeTarget element contains a URI that identifies the malfunctioning remote
   target of
   devices that a dialog.  A setting which in which this element is in-apprehensible to the user. With session policies,
   the user could decide to switch
   contained applies to a different codec or connect all dialogs which have this URI as their remote
   target.  Missing URI elements MUST match to any value.  For example,
   a
   domain with less stringent policies.

   Session policies may be specific to URI without a certain session and may change
   from session user name matches to session. Such policies can be set up using the
   framework for session-specific policies [3]. Other session policies
   remain all users in place for this domain.

4.3.1.5  Exclude Target

   The excludeTarget element contains a longer period of time, typically in URI that identifies the range remote
   target 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 dialog.  The setting in which this element is therefore desirable
   to enable user agents contained
   applies to obtain all dialogs which do not have this URI as the policies relevant for them and remote
   target.  Missing URI elements MUST match to
   inform the user agents about changes in these policies.

   This draft specifies any value.  For example,
   a XML schema for media and protocol user agent
   profile data. The media data defines properties of media streams
   transmitted by URI without a user agent. name matches to all users in this domain.

4.3.1.6  Info

   The protocol data defines info element provides a short textual description of the methods,
   extensions, bodies, etc. setting
   that should be supported by a user agent.
   These formats can be used intelligible to define session policy documents. Session the human user.

4.4  Media Policy Schema

   The media policy documents can be transmitted schema defines the elements and attributes needed to user agents as part of their
   device configuration using
   describe the Framework for SIP User Agent Profile
   Delivery [8].

2.  Terminology

   In this document, characteristics of media streams.

   The namespace of the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", media policy schema is:
      urn:ietf:params:xml:ns:mediapolicy

4.4.1  Elements and "OPTIONAL" Attributes

   The following elements and attributes are to be interpreted as
   described defined in BCP 14, [1] and indicate requirement levels for
   compliant implementations.

3.  Considerations for Policy-related Profile Data

   Policy documents should support versioning so that the recipients of media policy document can properly order them. This may be achieved using
   schema.

4.4.1.1  Media

   The media element defines a
   version attribute. media policy.  A policy document may contain media element MAY appear
   zero, one or multiple policies. Each policy times in the
   document may have a different scope. For example, a policy for
   firewall traversal would only apply to external calls whereas a
   policy limiting constraint element.

   The media element has the following sub-elements.

4.4.1.1.1  Max Bandwidth

   The maxBandwidth element defines the maximum bandwidth available could be in effect during
   peak hours. A policy document may define a scope attribute that
   specifies to which sessions kilobits
   per second an entity can count on.

   The maxBandwidth element is optional and can only appear once within
   a certain policy applies. Possible scopes
   are:
   o  Time media element.  All subsequent instances MUST be ignored.  It has
   no meaning and day: limits MUST be ignored if it is inside a forbid constraint.

4.4.1.1.2  Maxno Streams

   The maxnoStreams element defines the use maximum number of a policy streams an
   entity is allowed to certain times or days.
   o  Local entity: limits handle at the use of same time.

   The maxnoStreams element is optional and can only appear once within
   a policy to media element.  All subsequent instances MUST be ignored.  It has
   no meaning and MUST be ignored if it is inside a specific 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
      certain local user. This media element.  All subsequent instances MUST be ignored.  It has
   no meaning and MUST be ignored if it is in particular useful for devices that
      supports multiple identities.
   o  Remote entity: limits inside a forbid constraint.

4.4.1.1.4  Maxno Streams Session

   The maxnoStreamsSession element defines the use maximum number of streams
   an entity is allowed to establish within a policy 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 sessions involving
      certain remote addresses, for example all non-local addresses.
   o  Media streams: limits the use of entity within one session.

   The maxBandwidthSession element is optional and can only appear once
   within a policy to certain media
      streams.

   The use of policies may element.  All subsequent instances MUST be mandatory or optional. A policy document
   may specify whether a policy ignored.
   It has no meaning and MUST be ignored if it is mandatory or optional.

4.  User Agent Profile Data for Session Policies

      TODO: This specification needs 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 be alinged the schema entity for SIP
      protocol user agent profile data sets so that it can co-exist with
      other data delivered through the user agent configuration
      framework.

   A session policy document one stream.

   The maxBandwidthStream element is an XML document that optional and can only appear once
   within a media element.  All subsequent instances MUST be well-formed ignored.
   It has no meaning and SHOULD MUST be valid. Policy documents 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 based on XML 1.0 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 encoded using UTF-8. This specification makes use the name of XML
   namespaces a registered MIME type for identifying session policy documents. a encoding
   (see [2]), such as "PCMA", "G729", or "H263".

   The namespace
   URI for elements defined by this specification codec element is a URN [5], using
   the namespace identifier 'ietf' defined by RFC 2648 [6] optional and extended
   by [4]. This URN is:
      urn:ietf:params:xml:ns:sessionpolicy

   A session policy document begins with the root element tag
   "sessionpolicy".

4.1  Policy Document Format

   A session policy document starts with MAY appear multiple times within a sessionpolicy
   media element. This

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 as "udp", "RTP/AVP", or
   "RTP/SAVP".

   The transport element has three mandatory attributes:
      version: This an optional attribute:

   type - the type attribute allows identifies the recipient of session policy
      information documents to properly order them. Versions start at 0,
      and increment by one for each new document sent media type to which the
      transport element applies to.  The value of this attribute MUST be
      a subscriber.
      Versions are scoped legal type element value.

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

4.4.1.1.10  Direction

   The direction element identifies a media stream direction.  The value
   of this element MUST be
      representable using a 32 bit integer.
      domain: This "sendrec", "sendonly", or "recvonly".

   The direction element has an optional attribute:

   type - the type attribute contains identifies the domain media type to which the policy belongs
      direction element applies to.
      entity: This  The value of this attribute contains MUST be
      a URI that identifies legal type element value.

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

4.4.2  Conflict Resolution

   The UA SHOULD alert the user
      whose in case a media policy information is reported conflicts with
   another policy.

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

4.4.3  Example

   The following example describes a policy that limits the number of
   streams a UA can create to 4.  It only allows audio streams and
   prohibits the use of the
      document.

   The sessionpolicy element has PCMU and PCMA codecs.  It requires the UA to
   support RTP/AVP as a series transport and optionally allows RTP/SAVP but no
   other transport protocols.  Audio streams can only 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 sessionpolicy sub-elements:
   zero or one protocols element the protocol policy schema is:
      urn:ietf:params:xml:ns:protocolpolicy

4.5.1  Elements and zero or one media element.

4.1.1  Protocols Element Attributes

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

4.5.1.1  Protocol

   The protocol element contains defines a series of protocol sub-elements. policy.  Each protocol sub-element protocols
   element contains the policy related to the usage of a particular protocol. particular
   protocol.  A protocol element MAY appear zero, one or multiple times
   in a constraint element.

   The protocol element has a single mandatory attribute, name. The an optional attribute:

   name - the name attribute identifies a protocol the name of the protocol, to
      which the policy of each the protocol element is referring to. The

   Each protocol element has a series the following sub-elements.

4.5.1.1.1  Proxy

   The proxy element identifies the URI of sub-elements:
   methods, option-tags, feature-tags, and bodies.

4.1.1.1  Methods Element a proxy.  The proxy values
   MUST be used to create a route set.

   The methods proxy element contains is optional and may appear multiple times inside a default-policy attribute
   protocol element.  Multiple appearances of this element are ordered.
   It has no meaning and method
   elements. MUST be ignored if it is inside a forbid
   constraint.

4.5.1.1.2  Method

   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. identifies a method.  The value of this element
   MUST be the name attribute identifies of a
   method, and valid method within the policy attribute contains protocol identified by
   in the policy for that method
   (allowed or disallowed).

4.1.1.2  Option-tags Element protocol element.

   The option-tags method element contains a default-policy attribute is optional and
   option-tag elements. MAY appear multiple times within a
   protocol element.

4.5.1.1.3  Option Tag

   The default-policy attribute contains optionTag element identifies an optionTag.  The value of this
   element MUST be the policy name of an option tag registered for option-tags that are not listed as option-tag elements. An
   option-tag the protocol
   identified by in the protocol element has two attributes: name in the IANA registry.

   The optionTag element is optional and policy. MAY appear multiple times
   within a protocol element.

4.5.1.1.4  Transport

   The name
   attribute transport element identifies a method, and transport protocol for the policy attribute contains
   protocol identified by the
   policy for that method (mandatory, allowed, or disallowed).

4.1.1.3  Feature-tags Element protocol element.  The feature-tags value of this
   element contains MUST identify a default-policy attribute and
   feature-tag elements. The default-policy attribute contains the
   policy valid transport for feature-tags the given protocol.  For
   SIP, the value MUST a value that are not listed is registered for the transport
   header field parameter, such as feature-tag elements.
   An feature-tag "TCP", "UDP", or "SCTP".

   The transport element has two attributes: name is optional and policy. The name
   attribute identifies MAY appear multiple times
   within a method, and the policy attribute contains the
   policy for that method (allowed, or disallowed).

4.1.1.4  Bodies Element protocol element.

4.5.1.1.5  Body-disposition

   The bodies body-disposition element contains a default-policy attribute, identifies a
   default-encryption attribute and body-disposition elements. body-disposition.  The
   default-policy attribute contains
   value of this element MUST be a name registered in the policy IANA registry
   for body dispositions
   that are not listed as body-disposition elements. Content-Dispositions.

   The
   default-encryption attribute contains the encryption policy for body
   dispositions that are not listed as body-disposition elements. element is optional and MAY appear multiple
   times within a protocol element.

4.5.1.1.6  Body-format Element

   A body-disposition body-format element can have identifies a number of attributes: name,
   policy, default-policy, and encryption. body-format.  The value of this
   element MUST be the name attribute identifies of a body-disposition, and MIME type registered in the policy attribute contains IANA
   registry.

   The body-format element has an optional attribute:

   body-disposition - the policy for
   that body-disposition (allowed, or disallowed). The default-policy attribute contains identifies the policy for body formats that are not listed as
   body-format elements.
      disposition used with this body-format.  The encryption value of this
      attribute MUST be a value legal for the body-disposition element.

   The body-format element is optional and MAY appear 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.

   A body-disposition element contains body-format elements. A
   body-format  This element can MUST NOT have a two attributes: name and policy.
   value.

   The
   name body-encryption element has the following optional attributes:

   body-disposition - the body-disposition attribute identifies the body
      disposition this encryption setting applies to.  The value of this
      attribute MUST be a body-format, and value legal for the policy body-disposition element.
   body-format - the body-format attribute
   contains identifies the policy body format to
      which this encryption setting applies to.  The value of this
      attribute MUST be a value legal for that the body-format (allowed or disallowed).

4.1.1.5  Extensibility

   Other elements from different namespaces element.

   The body-encryption element is optional and MAY be present appear multiple times
   within a protocol element element.

4.5.2  Conflict Resolution

   The UA SHOULD alert the user in case a protocol policy conflicts with
   another policy.

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

4.5.3  Example

   The following example describes a policy saying that use of the
   MESSAGE method is prohibited in the network.  It states that the use
   of the option tag 100rel is required and preconditions are allowed.
   Other option tags are not allowed in the network.  The only MIME type
   for message bodies allowed is "application/sdp" with the purposes of extensibility; elements or
   attributes from unknown namespaces MUST be ignored.

4.1.1.6  Example of a Protocol Element

   <protocols>
   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">
       <methods default-policy="allowed">
          <method name="MESSAGE" policy="disallowed"/>
       </methods>
       <option-tags default-policy="disallowed">
          <option-tag name="100rel" policy="mandatory"/>
          <option-tag name="preconditions" policy="allowed"/>
       </option-tags>
       <feature-tags default-policy="disallowed">
          <feature-tag name="video" policy="allowed"/>
       </feature-tags>
       <bodies default-policy="allowed" default-encryption="allowed">
          <body-disposition name="session" policy="allowed"
                            encryption="disallowed" default-policy="disallowed">
         <optionTag>100rel</optionTag>
         <body-format name="application/sdp" policy="allowed"/>
          </body-disposition>
       </bodies> body-disposition="session">application/sdp</body-format>
       </protocol>
   </protocols>

4.1.2
     </set_all>
     <set_any>
       <protocol name="SIP">
         <optionTag>preconditions</optionTag>
       </protocol>
     </set_any>
   </property_set>

4.6  Media Element Routing Policy Schema

   The media element contains routing schema defines the policy related elements and attributes needed
   to the characteristics describe address and ports of a media streams of different types. It has three attributes:
   maxbandwidth, maxnostreams, and default-policy. They contain the
   maximum bandwidth the user stream.  This schema can count on, be
   used to route the maximum number of media
   streams that stream through a NAT, a firewall or a media
   relay.

   The namespace of the user is allowed protocol policy schema is:
      urn:ietf:params:xml:ns:mediaroutingpolicy

      OPEN ISSUE: This schema probably needs to established at go into a separate draft
      along with some text about the same time, mechanics.

4.6.1  Elements and Attributes

   The following elements and attributes are defined in the default protocol
   policy (allowed or disallowed) for stream types that are
   not listed as stream elements. schema.

4.6.1.1  Media Routing

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

   Each protocol element has the following sub-elements.

4.6.1.1.1  Address

   The address element contains the destination address of stream elements.

4.1.2.1  Stream Element

   A stream a media
   stream, i.e., the address that is contained in an SDP announcement
   for a media stream.

   The address element can MUST have the following attribute:

   direction - the direction attribute identifies the direction of a number
      media stream.  The value of attributes: type, policy,
   maxbandwidth, this element MUST be "send" or "recv".
      It determines whether the element applies to the session
      description offer or answer.

   The address element is optional and maxnostreams. MAY appear at most once within a
   media routing element.

4.6.1.1.2  Port

   The type attribute port element identifies the destination port of a media
   type, and stream,
   i.e., the address that is contained in an SDP announcement for a
   media stream.

   The address element MUST have the following attribute:

   direction - the policy direction attribute contains identifies the policy for that direction of a
      media
   type (allowed or disallowed). stream.  The stream element has a number value of optional sub-element: this element MUST be "send" or "recv".
      It determines whether the codecs
   element, element applies to the transports session
      description offer or answer.

   The port element is optional and the directions MAY appear multiple times within a
   media routing element.

4.1.2.1.1  Codecs Element

4.6.1.1.3  Port Range

   The codecs portRange element contains identifies a default-policy attribute and codec
   elements. The default-policy attribute contains range of ports that apply to the policy
   destination of a media stream.  This can, for codecs example, be used to
   determine the range of ports that are not listed as codec elements. A codec element can have two
   attributes: name and policy. be used for media streams in
   SDP announcements.

   The name address element MUST have the following attribute:

   direction - the direction attribute identifies the direction of a codec
   name, and
      media stream.  The value of this element MUST be "send" or "recv".
      It determines whether the policy attribute contains element applies to the policy for that codec
   (allowed, session
      description offer or disallowed). answer.

   The codec name portRange element is optional and MAY appear multiple times
   within a media routing element.  It has the encoding name as
   defined by the respective RTP profile.

4.1.2.1.2  Transports Element following two
   sub-elements.

4.6.1.1.3.1  Start Port

   The transports startPort element contains a default-policy attribute and
   transport elements. The default-policy attribute contains identifies the policy
   for transports lowest port number that are not listed as transport elements. A transport belongs
   to the port range.

   The startPort element can have two attributes: name and policy. MUST appear exactly once inside a port range
   element.

4.6.1.1.3.2  End Port

   The name attribute endPort element identifies a transport, and the policy attribute contains the policy
   for highest port number that transport (allowed, or disallowed).

4.1.2.1.3  Directions Element belongs
   to the port range.

   The directions endPort element contains MUST appear exactly once inside a default-policy attribute and
   direction elements. port range
   element.

4.6.2  Conflict Resolution

   The default-policy attribute contains UA SHOULD alert the user in case a media route policy conflicts
   with another policy.

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

4.6.3  Example

   The following example describes a policy
   for directions that are not listed as direction elements. A direction
   element can have two attributes: name instructs the UA to use
   the address 123.124.125.126 and policy. The name attribute
   identifies a direction (sendrecv, sendonly, recvonly), and port in the policy
   attribute contains range of 8000 - 9000 in
   the policy for that direction (allowed, or
   disallowed).

4.1.2.1.4  Extensibility

   Other elements from different namespaces MAY be present within session descriptions it creates.  This information can assist a
   stream element
   UA, for the purposes of extensibility; elements or
   attributes from unknown namespaces MUST be ignored.

4.1.2.2  Example of example, to traverse 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 Element
   <media maxnostreams="4" default-policy="disallowed">
      <stream type="audio" policy="allowed">
           <codecs default-policy="allowed">
               <codec name="PCMU" policy="disallowed"/>
               <codec name="PCMA" policy="disallowed"/>
           </codecs>
           <transports default-policy="disallowed">
               <transport name="RTP/AVP" policy="allowed"/>
           </transports>
           <directions default-policy="disallowed">
               <direction name="sendonly" policy="allowed"/>
           </directions>
      </stream>
   </media>

4.2 Policy Schema

   The following is the schema for the application/session-policy+xml
   type:

   <?xml version="1.0" encoding="UTF-8"?>
   TBD

4.3  Example

   The following is is an example of an application/session-policy+xml
   document:
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:mediapolicy"
         xmlns:tns="urn:ietf:params:xml:ns:mediapolicy"
         xmlns:xs="http://www.w3.org/2001/XMLSchema"
         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

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

     <xs:complexType name="media">
       <xs:sequence>
         <xs:element name="maxBandwidth" type="xs:positiveInteger"
           minOccurs="0" maxOccurs="1"/>
         <xs:element name="maxnoStreams" type="xs:positiveInteger"
           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" minOccurs="0"
            maxOccurs="unbounded"/>
         <xs:element name="codec" type="xs:string" minOccurs="0"
            maxOccurs="unbounded"/>
         <xs:element name="transport" type="tns:transport"
            minOccurs="0" maxOccurs="unbounded"/>
         <xs:element name="direction" type="tns:direction"
            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"?>
   <sessionpolicy xmlns="urn:ietf:params:xml:ns:sessionpolicy"
                  version="0"
                  domain="example.com"
                  entity="sip:alice@example.com">
    <protocols>
     <protocol name="SIP">
       <methods default-policy="allowed"/>
       <option-tags default-policy="allowed"/>
       <feature-tags default-policy="allowed"/>
       <bodies default-policy="allowed" default-encryption="allowed"/>
     </protocol>
    </protocols>
    <media default-policy="allowed"/>
   </sessionpolicy>

5.
   <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">
       <xs:sequence>
         <xs:element name="proxy" 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"/>
         <xs:element name="body-encryption" type="tns:body-encryption"
            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" minOccurs="0"
            maxOccurs="1"/>
         <xs:element name="port" type="tns:port"
            minOccurs="0" maxOccurs="unbounded"/>
         <xs:element name="portRange" type="tns:portRange"
            minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:complexType>

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

     <xs:complexType name="portRange">
       <xs:sequence>
         <xs:element name="startPort" type="xs:anyURI" minOccurs="1"
           maxOccurs="1"/>
         <xs:element name="endPort" type="xs:anyURI" minOccurs="1"
           maxOccurs="1"/>
       </xs:sequence>
       <xs:attribute name="direction" type="tns:directionValue"
         use="optional"/>
     </xs:complexType>

     <xs:simpleType name="directionValue">
       <xs:restriction base="xs:string">
         <xs:enumeration value="send"/>
         <xs:enumeration value="recv"/>
       </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.

6.

7.  IANA Considerations

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

6.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 5
   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, <Gonzalo.Camarillo@ericsson.com>

   Intended usage: COMMON

   Author/Change controller: The IETF.

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

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

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

   Registrant Contact: IETF, SIPPING working group,<sipping@ietf.org>,
   Gonzalo Camarillo, <Gonzalo.Camarillo@ericsson.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>application/session-policy+xml</h2>
                  <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
                </body>
                </html>
                END

7

   [TBD.]

8  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. M., Jacobson, V. and C. Perkins, "SDP: Session
         Description Protocol", RFC 2327, April 1998. draft-ietf-mmusic-sdp-new-20 (work in
         progress), September 2004.

   [3]   Hilt, V. V., Camarillo, G. and J. Rosenberg, "A Framework for
         Session-Specific
         Intermediary Session Policies in SIP", September 2003. the Session Initiation
         Protocol (SIP)", October 2004.

   [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]   Petrie, D., "A Framework for Session Initiation Protocol User
         Agent Profile Delivery", draft-ietf-sipping-config-framework-03 draft-ietf-sipping-config-framework-04
         (work in progress), May July 2004.

   [8]   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 Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [10]  Rosenberg, J., "Traversal Using Relay NAT (TURN)",
         draft-rosenberg-midcom-turn-04 (work in progress), February
         2004.

   [11]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:

         Session Initiation Protocol", RFC 3261, June 2002.

Authors' Addresses

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

   EMail: volkerh@bell-labs.com

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com

   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Avenue
   East Hanover,
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07936  07054
   USA

   EMail: jdrosen@dynamicsoft.com

Appendix A.  Acknowledgements

   Many thanks to Allison Mankin for the discussions and Markus Hofmann the suggestions
   for their
   contributions to this draft.

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 IETF's procedures with respect to rights in IETF Documents 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).  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.