[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 02 03 04 05                                                
SIPPING                                                        D. Petrie
Internet-Draft                                                SIPez LLC.
Expires: April 26, 2006                                      S. Lawrence
                                                           Pingtel Corp.
                                                                M. Dolly
                                                               AT&T Labs
                                                                 V. Hilt
                                           Bell Labs/Lucent Technologies
                                                        October 23, 2005


 A Schema and Guidelines for Defining Session Initiation Protocol User
                        Agent Profile Data Sets
              draft-petrie-sipping-profile-datasets-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

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

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

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

   This Internet-Draft will expire on April 26, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines the requirements and a format for SIP user
   agent profile data.  An overall schema is specified for the



Petrie, et al.           Expires April 26, 2006                 [Page 1]


Internet-Draft              SIP UA Data Sets                October 2005


   definition of profile data sets.  The schema also provides for
   expressing constraints for how multiple sources of profile data are
   to be combined.  This document provides a guide to considerations,
   policies and syntax for defining data sets to be included in profile
   data.  It also explores some specific data sets to test the
   requirements, assumptions and syntax.


Table of Contents

   1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Requirements Terminology . . . . . . . . . . . . . . . . .  4
     2.2.  Profile Data Terminology . . . . . . . . . . . . . . . . .  5
     2.3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Design Considerations  . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.1.  Outbound Proxy Setting . . . . . . . . . . . . . . . .  7
       3.1.2.  Codec Settings . . . . . . . . . . . . . . . . . . . .  7
       3.1.3.  Transport Protocol Setting . . . . . . . . . . . . . . 11
     3.2.  Requirement Descriptions . . . . . . . . . . . . . . . . . 13
       3.2.1.  Implementer Extensibility  . . . . . . . . . . . . . . 13
       3.2.2.  Flexible Capabilities  . . . . . . . . . . . . . . . . 13
       3.2.3.  XML  . . . . . . . . . . . . . . . . . . . . . . . . . 14
       3.2.4.  Access Control . . . . . . . . . . . . . . . . . . . . 14
       3.2.5.  Data Constraints and Range Definition  . . . . . . . . 14
       3.2.6.  Support of User, Application, Device, Local
               Network Sources  . . . . . . . . . . . . . . . . . . . 15
       3.2.7.  The Ability to Specify Policy  . . . . . . . . . . . . 16
   4.  Overall Data Set Schema  . . . . . . . . . . . . . . . . . . . 16
     4.1.  Data Primitives  . . . . . . . . . . . . . . . . . . . . . 17
     4.2.  Use of Namespaces  . . . . . . . . . . . . . . . . . . . . 17
     4.3.  The 'property_set' Element . . . . . . . . . . . . . . . . 17
     4.4.  The Abstract 'setting_container' Element . . . . . . . . . 18
     4.5.  The Abstract 'setting' Element . . . . . . . . . . . . . . 18
       4.5.1.  The 'visibility' Attribute . . . . . . . . . . . . . . 18
       4.5.2.  The 'policy' Attributes  . . . . . . . . . . . . . . . 19
       4.5.3.  The 'excluded_policy' Attributes . . . . . . . . . . . 19
       4.5.4.  The 'direction' Attribute  . . . . . . . . . . . . . . 20
       4.5.5.  The 'q' Attribute  . . . . . . . . . . . . . . . . . . 20
     4.6.  The 'profile-uri' Element  . . . . . . . . . . . . . . . . 20
     4.7.  The 'profile-credential' Element . . . . . . . . . . . . . 21
       4.7.1.  realm Element  . . . . . . . . . . . . . . . . . . . . 21
       4.7.2.  auth_user Element  . . . . . . . . . . . . . . . . . . 21
       4.7.3.  a1_digest Element  . . . . . . . . . . . . . . . . . . 21
     4.8.  The 'profile-contact-uri' Element  . . . . . . . . . . . . 21
     4.9.  The 'profile-info' Element . . . . . . . . . . . . . . . . 22
     4.10. Merging Property Sets  . . . . . . . . . . . . . . . . . . 22



Petrie, et al.           Expires April 26, 2006                 [Page 2]


Internet-Draft              SIP UA Data Sets                October 2005


       4.10.1. Single Numeric Value Merging Algorithm . . . . . . . . 22
       4.10.2. Multiple Enumerated Value Merging Algorithm  . . . . . 23
       4.10.3. Closest Value First Merging Algorithm  . . . . . . . . 24
     4.11. Common Types . . . . . . . . . . . . . . . . . . . . . . . 25
   5.  Defining Data Sets . . . . . . . . . . . . . . . . . . . . . . 25
     5.1.  Namespace  . . . . . . . . . . . . . . . . . . . . . . . . 25
     5.2.  Property Definitions . . . . . . . . . . . . . . . . . . . 25
     5.3.  Merging Data Sets  . . . . . . . . . . . . . . . . . . . . 26
   6.  Candidate Data Sets  . . . . . . . . . . . . . . . . . . . . . 26
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
   9.  Change History . . . . . . . . . . . . . . . . . . . . . . . . 27
     9.1.  Changes from draft-petrie-sipping-profile-datasets-02  . . 27
     9.2.  Changes from draft-petrie-sipping-profile-datasets-01  . . 28
     9.3.  Changes from draft-petrie-sipping-profile-datasets-00  . . 28
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
     10.2. Informative References . . . . . . . . . . . . . . . . . . 30
   Appendix A.  SIP UA Profile Schema . . . . . . . . . . . . . . . . 30
   Appendix B.  Acknowledgments . . . . . . . . . . . . . . . . . . . 35
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
   Intellectual Property and Copyright Statements . . . . . . . . . . 37





























Petrie, et al.           Expires April 26, 2006                 [Page 3]


Internet-Draft              SIP UA Data Sets                October 2005


1.  Motivation

   Today all SIP user agent implementers use proprietary means of
   expressing and delivering user, device, and local network profile
   information to the user agent.  The SIP User Agent Profile Delivery
   Framework [I-D.ietf-sipping-config-framework] and the Framework for
   Session SIP Session Policies [I-D.hilt-sipping-session-policy-
   framework] specify how SIP user agents locate and retrieve profile
   data specific to the user, the device, and the local network.  It is
   important for SIP User Agents to be able to obtain and use these
   multiple sources of profile data in order to support a wide range of
   applications without undue complexity.

   While these frameworks define the mechanisms for transmitting profile
   data, they do not define a format for the actual profile data.  This
   document proposes the requirements, a high level schema for, and
   guide to how these data sets can be defined.  The goal is to enable
   any SIP user agent to obtain profile data and be functional in a new
   environment independent of the implementation or model of user agent.
   The nature of having profile data from four potential sources
   requires the definition of policies on how to apply the data in an
   interoperable way across implementations which may have widely
   varying capabilities.

   The ultimate objective of the framework described in the SIP User
   Agent Profile Delivery Framework and this document is to provide a
   start up experience similar to that of users of an analog telephone.
   From the point of view of a user, you just plug in an analog
   telephone and it works (assuming that you have made the right
   arrangements with your local phone company).  There is no end user
   setup required to make an analog phone work, at least in a basic
   sense.  So the objective here is to be able to take a new SIP user
   agent out of the box, plug it in or install the software and have it
   get its profiles without human intervention other than security
   measures.  This is necessary for cost effective deployment of large
   numbers of user agents.  All user agents do not provide telephone
   capabilities, but the user set up experience goal is applicable to
   most of the range of user agent capabilities.


2.  Introduction

2.1.  Requirements Terminology

   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
   "MAY" that appear in this document are to be interpreted as described
   in RFC 2119[RFC2119].




Petrie, et al.           Expires April 26, 2006                 [Page 4]


Internet-Draft              SIP UA Data Sets                October 2005


2.2.  Profile Data Terminology

   property - a named configurable characteristic of a user agent.  A
      given property has a well-defined range of possible values.  A
      given property may be defined to have a range of values, allow for
      simultaneous use of many values (as in a list of allowed
      possibilities), or a set of related values that collectively form
      a single profile information item.
   setting - the binding of a specific value or set of values to a given
      property.
   profile - a collection of settings to be applied for a specific user,
      device, or local network.
   device - SIP user agent, either software or hardware appliance.  This
      is a logical concept, as there may be no physical dedicated device
      or it may be part of an assembly of devices.  In this document,
      the terms "user agent" and "device" are interchangeable.
   user profile - the profile that applies to a specific user.  This is
      best illustrated by the "hotelling" use case - a user has an
      association for some period of time with a particular device.  The
      user profile is that set of profile data the user wants to
      associate with that device (e.g. ringtones used when someone calls
      them, the user's shortcuts).
   device profile - data profile that applies to a specific device.  In
      the "hotelling" use case, this is the data that is bound to the
      device itself independent of the user.  It relates to specific
      capabilities of the device and/or preferences of the owner of the
      device.
   local network profile - data that applies to the user agent in the
      context of the local network.  This is best illustrated by roaming
      applications; a new device appears in the local network (or a
      device appears in a new network, depending on the point of view).
      The local network profile includes settings and perhaps policies
      that allow the user agent to function in the local network (e.g.
      how to traverse NAT or firewall, bandwidth constraints).
   data set - a collection of properties.
   working profile - the set of property values actually set in a SIP
      User Agent as a result of merging the profiles from all sources;
      the actual effective profile for the user agent .
   merging - the operation of resolving overlapping settings from
      multiple profiles.  Overlap occurs when the same property occurs
      in multiple profiles (e.g. device, user, application, local
      network).

2.3.  Overview

   In this document requirements are specified for containing and
   expressing profile data for use on SIP user agents.  Though much of
   this can be considered independent of SIP there is one primary



Petrie, et al.           Expires April 26, 2006                 [Page 5]


Internet-Draft              SIP UA Data Sets                October 2005


   requirement that is not well satisfied through more generic profile
   data mechanisms.  SIP User Agent set up requires the agent to merge
   settings, which may overlap, from potentially four different sources
   (see [I-D.ietf-sipping-config-framework]); each source must not only
   be able to provide profile information, but also express policies
   regarding how the profile settings may be combined with that from
   other sources.

   A schema and syntax is defined in this document to specify properties
   that may be aggregated to construct profiles.  The general design
   philosophy is that many small data sets provide flexibility to the
   implementer to support the aggregated set that best matches the
   capability of the user agent.  The actual properties are not defined
   in this document (see [I-D.ietf-sipping-media-policy-dataset] and
   [reference: Core SIP Dataset]).  However, some examples are explored
   here to illustrate the proposed mechanisms and to validate the
   requirements.

   This document defines a set of considerations, syntax and policies
   that must be specified when defining data sets.  These are to help
   authors of data set specifications to define data sets that will work
   in the overall schema defined in this document.  The actual
   specification of these data sets is outside the scope of this
   document.


3.  Design Considerations

   The following section defines some of the design considerations that
   were taken into account when defining the schema, syntax and policies
   for generating and applying profile data.  Section 3.2.6 describes
   need for merging of the four data set sources provided in [I-D.ietf-
   sipping-config-framework].

3.1.  Use Cases

   In the following use case scenarios the device profile is provided by
   the device owner/manager.  The owner/manager may be a service
   provider, an enterprise or a user administering the device setup.
   The user is assumed to be the end user operating the user agent to
   perform SIP functions such as telephony, IM etc.  In the scenarios
   that the user profile is provided, the user profile contains user
   specific properties that the end user has set directly or indirectly
   through an administration process.  The local network profiles
   represent the suggested policy behavior that the local network
   operator would like user agents to adhere to [I-D.hilt-sipping-
   session-policy-framework].  From a security perspective, the local
   network operator cannot trust the user agent to follow the local



Petrie, et al.           Expires April 26, 2006                 [Page 6]


Internet-Draft              SIP UA Data Sets                October 2005


   network profile policy.  The local network operator must use a means
   external to the user agent to enforce these policies.  The local
   network profile is intended to express to the user agent, the
   policies that the user agent should follow if the user agent wants to
   function properly in the local network.

3.1.1.  Outbound Proxy Setting

   First consider the use cases for a simple user agent property: the
   outbound proxy.  It is not likely that the user would want to
   influence the outbound proxy for SIP signaling.  Conceptually an
   application might wish to use a specific outbound proxy for signaling
   related to that application.  For this use case, assume that the only
   the device owner/manager or the local network operator are likely to
   want to set the outbound proxy property.  The device profile defines
   an outbound proxy perhaps so that the device owner/manager can
   monitor all signaling.  The local network operator also defines an
   outbound proxy because the proxy allows the SIP signaling to get
   through a NAT or firewall.

   It seems there are few possible solutions to this conflict resolution
   problem:
   o  The simple solution is to define a policy where the local network
      profile overrides the device profile.  In this approach the local
      network profile wins.
   o  A comprehensive solution is to allow the aggregation of the
      outbound proxies.  In this scenario SIP messages would be sent
      with a pre-populated route set that had two hops.  First the
      outbound proxy set in the local network profile, then the outbound
      proxy set in the device profile.

   The aggregation approach is closest to solving the requirements to
   the use case above.  By aggregating the two outbound proxies, the
   local network provided outbound proxy allows the signaling to get out
   of the local network and the device profile provided outbound proxy
   is able to monitor all SIP signaling from the user agent.

3.1.2.  Codec Settings

   Use cases for the codec properties are illustrated here as they are
   likely one of the more complicated sets of properties with respect to
   merging and constraining across more than one profile.  There are
   reasonable scenarios where requirements can be rationalized that the
   device, user and local network profiles may each wish to express
   preferences and constrains of the codec properties.  Without getting
   into details or syntax of the codec properties, it is assumed that
   codec properties will need to express a codec definition and a
   preference order.  This is the order that these codecs will be put in



Petrie, et al.           Expires April 26, 2006                 [Page 7]


Internet-Draft              SIP UA Data Sets                October 2005


   SDP for codec negotiation purposes.

   The following scenarios illustrate some possible combinations of
   sources of codec properties from the device, user and local network
   profiles.  The scenarios identify rationale for providing codec
   properties in each of the profiles.

3.1.2.1.  Codec Setting Not Set

   In the scenario where a device has no profiles or the profiles
   contain no codec properties, the device will enable a default set and
   preference order of codecs.  The default set and preference order of
   codecs is a implementer specific choice.  In some implementations it
   is s subset of the codecs supported by the device.

3.1.2.2.  Codec Set in Device Profile

   Let us assume a scenario where user agents providing telephony
   capabilities are deployed.  The deployment has very simple
   requirements such that the user agents have fixed locations and are
   always associated with the same user.  This scenario does not need
   the separation between the user, device and local network profiles.
   A single profile would suffice.  Another scenario having similar
   requirements is one where the user and local network profiles do not
   provide any codec related properties.  This might be because the user
   does not care what codecs are used and the local network does not
   wish to impose any constraints on the codes used in the network.  In
   the following use case, the device profile is the only source of
   codec properties.

   The codecs in the device profile may differ from the set of codecs
   supported by the device, due to the administrator of the device
   profile wanting:
   o  To have a uniform set of codecs used across all device types
   o  To exclude the use of a specific codec due to performance issues/
      concerns

   The resulting device profile data further will constrain the list of
   codecs that get applied.  In addition, the administrator may want to
   list the order of which the codecs are to be applied.  In this
   scenario the device profile data will dictate the ordered list of
   codecs to be applied.  The use agent will ignore codec types included
   in the profile that the user agent does not support.

3.1.2.3.  Set in Device and User Profiles

   In the following scenario users are allowed to express a preference
   over codecs.  Users are probably not likely to express specific codes



Petrie, et al.           Expires April 26, 2006                 [Page 8]


Internet-Draft              SIP UA Data Sets                October 2005


   in the form of G.7XX, etc.  They are likely to want to express a
   preference in the form of wideband, normal and low bandwidth.  In the
   following use case, device and user profiles contain codec
   properties.

   The user may prefer a higher quality codec to be used, if available.
   Thereby the user profile data may provide an ordered list of codecs
   to be applied.  The device profile also specifies a list of codecs
   and a default preference order.

   The merging of the data sources is as follows:
   o  The ordering of the codecs will be determined from the user
      profile data, which overrides the codec preference ordering from
      the device profile data.
   o  The set of codecs that may be applied, are the codecs listed in
      the user data constrained by the list of codecs from the device
      profile data.

   The case in which none of the codecs in the resulting merged profile
   data sets are supported by the device, the profile data constitutes a
   misconfiguration between device and user profiles.  It may not be
   possible to successfully establish a session in this case.  It is
   suggested that the user agent provide feedback to the user indicating
   the misconfiguration.  The user agent may also attempt to function in
   the network by ignoring one or more of the profile constraints.

3.1.2.4.  Set in Device and Local Profiles

   In another scenario the user is not allowed or does not care to
   express codec preferences.  The owner/manager of the device defines
   the set of codecs which may be used on the device along with a
   preference ordering of codecs.  There is no user profile or the user
   profile contains no codec properties.  The local network wishes to
   define a policy over codec usage in the network.  It is not clear
   there is a requirement that the local network be able to express a
   preference order.  However the network operator is very likely to
   want to express a set of codecs that can or should not be used.  The
   constraints that the local network operator wishes suggest may relate
   to the goal of controlling bandwidth or conveying what will work over
   the available WAN connection.  In the following use case, device and
   local network profiles provide codec properties.  The local network
   may limit the type of codecs that can be applied due to resources
   available.

   The merging of the data sources is as follows:
   o  The set of codecs that may be used is the ordered list of codecs
      from the device profile data, further constrained by the local
      network profile data.



Petrie, et al.           Expires April 26, 2006                 [Page 9]


Internet-Draft              SIP UA Data Sets                October 2005


   The case in which none of the codecs in the resulting merged profile
   data sets are supported by the device, the profile data constitutes a
   misconfiguration between local network and device.  It may not be
   possible to successfully establish a session in this case.  It is
   suggested that the user agent provide feedback to the user indicating
   the misconfiguration.  The user agent may also attempt to function in
   the network by ignoring one or more of the profile constraints.

3.1.2.5.  Set in Device, User and Local Profiles

   In this scenario everyone has an opinion on the codecs to be used.
   The device owner/manager wishes to define a set of codes based upon
   best interoperability of known end points in the environment.  The
   user wishes to express preferences in the codecs (e.g. prefers
   wideband audio).  The local network wishes to constrain the codecs
   based upon bandwidth (e.g. a wireless network with limited local
   network bandwidth, a SOHO network with dialup connectivity, a small
   office with shared 256kbps WAN connectivity).  In the following
   scenario, device, user and local network profiles provide codec
   properties.

   The merging of the data sources is as follows:
   o  The ordering of the codecs will be determined from the user
      profile data, which overrides the ordering from the device profile
      data.
   o  The set of codecs that may be used are the codecs listed in the
      device profile data, constrained by the list of codecs from the
      user profile data and further constrained by the list of codecs
      from the local network profile data.

   The case in which none of the codecs in the resulting merged profile
   data sets are supported by the device, the profile data constitutes a
   misconfiguration between device, user and local network profiles.  It
   may not be possible to successfully establish a session in this case.
   It is suggested that the user agent provide feedback to the user
   indicating the misconfiguration.  The user agent may also attempt to
   function in the network by ignoring one or more of the profile
   constraints.

3.1.2.6.  Derived Requirements

   1.  A device will have a set of codecs supported, that may be
       offered.  The list of codecs supported by a device may differ
       from the list of codecs in the device profile data.  The list of
       codecs in the device profile data that get applied is the subset
       of the codecs supported by the device.  Codecs listed in profiles
       that are not supported by the device are ignored.




Petrie, et al.           Expires April 26, 2006                [Page 10]


Internet-Draft              SIP UA Data Sets                October 2005


   2.  The device profile data will have a default ordered list of
       codecs, which implies a preference order that may be offered.
   3.  The user profile data may provide an ordered list of user
       preferred codecs.  The ordering of the codecs in the user profile
       data will override the ordering of the codecs in the device
       profile data.  The user list of codecs may further constrain the
       list of codecs to be used.
   4.  The local network profile data may provide a list of codecs
       supported.  This list will further constrain the list of codecs
       that may be offered.
   5.  The application profile data containing codec data will be
       ignored.
   6.  The profiles need the ability to express codecs that may be used
       and codecs that should not be used.

3.1.3.  Transport Protocol Setting

   This section describes use cases related to the use of the SIP
   transport protocol settings for a user agent.  It is assumed that
   user agents are configurable to define what transport protocols (e.g.
   UDP, TCP, TLS) are to be used for the SIP signaling as well as the
   default order in which to attempt each of the protocol.

3.1.3.1.  Setting Not Set

   When none of the profiles are available or the profiles do not
   specify the SIP transport protocol setting, the device's default
   signaling transport(s) will be used.

3.1.3.2.  Set in Device Profile

   In the following scenario, the device profile is the only source of
   profile data.  The signaling transports contained in the device
   profile may differ from the set of signaling transports supported by
   the device.  This may be due to the administrator of the device
   profile wanting:
   o  To have a uniform use of signaling transports used across all
      device types.
   o  To mandate TLS for security reasons.
   o  To exclude the use of a specific signaling transport due to
      performance issues/concerns.
   o  To indicate the preferred, default order in which to attempt using
      each of the transport protocols.

   This will result in the device profile data further constraining the
   list of signaling transports that could be used.  The highest
   preference ordered signaling transport from the device profile data
   set will be used first.



Petrie, et al.           Expires April 26, 2006                [Page 11]


Internet-Draft              SIP UA Data Sets                October 2005


3.1.3.3.  Set in Device and User Profiles

   The following scenario extends the prior case described above.  SIP
   transport protocol properties are provided in both the device and
   user profiles.  Consider that SIP user agents, like email agents, may
   want to provide the user with options to:
   o  Mandate that secure transport must be used.  If secure transport
      is not possible the user does not want to use the user agent.
   o  Prefer secure transport.  Attempt to use secure transport.  If
      secure transport will not work, use which ever transport protocol
      will make communication work.

   When the user mandates the use of secure signaling transports only,
   the user wishes to constrain the available signaling transports to
   TLS.  When indicating a preference to secure transport, the use is
   specifying a preference order for the use of transport protocols
   where TLS is the highest priority.

   Now consider the merging strategy required to accomplish the goals of
   this use case scenario where the device and user profiles both
   contain SIP transport protocol properties.  The merging of the data
   sources is as follows:
   o  The set of signaling transports that are allowed to be used is
      constrained by the device profile data.  This is further
      constrained by the user profile data.
   o  The signaling transports attempted will be those from the merged,
      constrained list in order of highest to lowest priority.

3.1.3.4.  Set in Device and Local Profiles

   In the following scenario, device and local network profile data is
   available.  The local network may have a limited set of signaling
   transports that it supports due to NAT or firewall constraints.

   The merging of the data sources is as follows:
   o  The set of signaling transports that may be used is the ordered
      list of signaling transports from the device profile data, further
      constrained by the local network profile data.

   The case in which none of the local network data signaling transports
   are supported by the device profile data constitutes a
   misconfiguration between local network and device.  The device might
   not be able to successfully establish a session in this case.

3.1.3.5.  Derived Requirements






Petrie, et al.           Expires April 26, 2006                [Page 12]


Internet-Draft              SIP UA Data Sets                October 2005


   1.  A device will have a set of signaling transports that it supports
       (note: one can be a set), with a default signaling transport.
   2.  The set of signaling transports supported by a device may differ
       from the set of signaling transports in the device profile data.
       The set of signaling transports in the device profile data is an
       ordered list, that is a subset of the set of signaling transports
       supported by the device.  This may be due to performance issues
       associated with one of the signaling transport(s).
   3.  The user profile data may provide a list of preferred signaling
       transports to be used (e.g., TLS for securing the signaling).
   4.  The local network profile data provides a list of signaling
       transports supported, and will constrain the set of signaling
       transports that could be used.

3.2.  Requirement Descriptions

3.2.1.  Implementer Extensibility

   Implementers must be able to differentiate each implementation.  In
   addition, it does not serve user agent owners and administrators well
   to require an orchestrated upgrade for all user agent implementations
   and profile delivery servers before a new capability or feature can
   be supported with the required profile data.  Hence one of the most
   important requirements is to support the ability of implementers to
   extend specified standard data sets to include additional related
   features and flexibility.  It MUST be possible to extend a data set
   without breaking user agents that support that data set.  This may
   require that user agents ignore parts of a data set that it does not
   implement or extensions that it does support.

3.2.2.  Flexible Capabilities

   User agents vary quite widely in their capabilities.  Some user
   agents function like traditional telephones.  Some user agents
   support only text messaging.  Some user agents support many media
   types such as video.  Some user agents that function like a telephone
   have a single line, some have large numbers of lines.  There is no
   such thing as one size fits all.  It MUST be possible for an
   implementer to choose which data sets to support based upon the
   capabilities that are supported by the user agent.  The schema for
   containing the profile data MUST support a profile that contains only
   the data sets that a user agent supports.  This allows the profile
   delivery server to create small profiles for specific devices.
   However a user agent SHOULD ignore properties for capabilities that
   it does not support.  This allows the profile delivery server to be
   ignorant of the capabilities of the device.  The degree to which the
   profile delivery server has intelligence of the user agent
   capabilities is an implementation choice.



Petrie, et al.           Expires April 26, 2006                [Page 13]


Internet-Draft              SIP UA Data Sets                October 2005


3.2.3.  XML

   XML is perhaps not really a requirement, but a solution base upon
   requirements.  However it is hard to ignore the desire to utilize
   readily available tools to manage and manipulate profile data such as
   XSLT, XPATH and XCAP.  The requirement that should be considered when
   defining the schema and syntax is that many user agents have limited
   resources for supporting advanced XML operation.  The simplest XML
   construct possible should be used, that support the required
   functionality.  It is not a requirement that user agents validate the
   profile XML document.  This relieves the requirement that the XML
   schema defined in this and other data sets documents be enforced on
   the user agent.  The XML schema should not be used to strictly
   validate profile XML documents.  Unknown elements and attributes
   should be ignored to allow extensions to be supported.  Strict
   enforcement of the XML schema would make it very difficult to deploy
   new user agents without lock step upgrades of the profile delivery
   server.  Guidelines for the Use of Extensible Markup Language (XML)
   within IETF Protocols [RFC3470] provides useful information in this
   regard.

3.2.4.  Access Control

   Many user agents (e.g. appliances and softphones running on PCs)
   provide user interfaces that permit the user to edit properties that
   are logically part of user, application, device or local network
   profiles.  Operators and administrators would like to be able to
   specify what an end user can change in those profiles and what an end
   user is not allowed to change.  There may also be sensitive data the
   user agent requires to function, but that the operator of the system
   does not want the end user to see.  For some properties the system
   operator may allow the user a fixed set of choices among the
   supported set of possible values.  It MUST be possible to express
   whether an end user may change a data set property.  It MUST be
   possible to express that a property should not be made visible to the
   end user.  It MUST be possible to express allowable values or ranges
   that the end user may change a property to.  The access control
   information SHOULD be optional to the data set.  It might be useful
   if it was possible to express the access control independent of the
   properties themselves.  The access control specification by itself
   might be useful to express a general policy that the device owner or
   local network operator wish to impose.

3.2.5.  Data Constraints and Range Definition

   There is a need for property value types such as free form text,
   token/enumerations, integers, real numbers, etc.  Many of these
   properties will have constrained values as opposed to the range of



Petrie, et al.           Expires April 26, 2006                [Page 14]


Internet-Draft              SIP UA Data Sets                October 2005


   all possible values.  These constrains may be due to protocol
   definitions, implementation limitations, and/or the desire (e.g. by
   the user, device owner, local network operator) to impose policy on
   the user agent.  The ability to express the property constraints is
   useful from the perspective of access control as described in the
   above section.  It is also useful to parameterize a user interface
   (e.g. on the user agent itself or on the profile delivery server)
   which provides a facility to modify profile data.  It MUST be
   possible for the schema to specify property constraints as ranges or
   discrete sets of possible values.  These constrains SHOULD be
   optional to the data set.  It might be useful if it was possible to
   express the constraints independent of the properties themselves.
   The constraints without the property values might be used to specify
   the capabilities of a particular user agent implementation.

3.2.6.  Support of User, Application, Device, Local Network Sources

   [I-D.ietf-sipping-config-framework] specifies a mechanism where the
   user agent retrieves profile data from as many as four different
   sources.  The separation of the user profile facilitates a hotelling
   capability and the ability to easily re-assign a user to a different
   device.  The separation of the local network profile facilitates
   properties specific to operating in the local network in a roaming
   scenario (e.g. outbound proxy or NAT traversal properties).  The
   local network profile may also impose policy as describe in the next
   section.  The device profile facilitates device capability based
   properties as well as a means for the device owner or manager (e.g.
   enterprise or service provider) to impose policy.

   The multiple potential sources of profile data add some complexity to
   the user agent that must consolidate these separate profiles into a
   single working profile.  It would be simpler if we could define each
   property as only allowed in one of the profiles.  However it overly
   constrains the profiles and takes away desired functionality such as
   hotelling, roaming and shared profile management.  It would also be
   simpler if we could define one rule for all profile data sets and
   properties by which we merge the profile (e.g. local network profile
   overwrites user profile which overwrites device profile for all
   data).  However this too is overly restrictive and eliminates some
   very useful functionality.

   The rules to merge profile data sets needs to be defined for each
   data set.  In some cases an entire data set must be considered atomic
   when merging one profile source with another.  In other cases it
   makes sense to merge profile data sets, aggregating properties from
   the data set provided in each of the profiles.  It may also be
   desirable to have the effect of filtering of data set properties.
   The desired effect might be for the owner of the device or the local



Petrie, et al.           Expires April 26, 2006                [Page 15]


Internet-Draft              SIP UA Data Sets                October 2005


   network operator to constrain what values are allowed for properties
   in the profiles.  This may also be the mechanism to facilitate
   imposing of policy as described in the next section.  The operation
   of resolving overlapping data sets from multiple profiles, regardless
   of the means or net result, will be referred to as "merging" in this
   document.

   A profile must have the means to constrain the merging algorithm.
   Due to the differences in the desired outcome for each data setting,
   the merging algorithm is specific to the setting.  When defining a
   property setting, the merging algorithm must also be defined.  A few
   of the more commonly used merging algorithms are defined in this
   document.  Most settings are likely to use the common set defined in
   this document.  However authors of profile datasets may define new
   algorithms for merging dataset properties (see Section 4.10 and
   Section 5.3).

3.2.7.  The Ability to Specify Policy

   Local network operators would like to impose policy on users and
   devices operating in their network.  There is a need to constrain the
   operation and require specific behavior in the network.  This might
   be as simple as to get access to the Internet, user agents must use a
   specified outbound proxy and NAT traversal mechanism.  The network
   might have limited bandwidth such that the operator would like to
   constrain codecs or media streams to keep the network functional.
   The local network may provide emergency service behavior or
   functionality properties that are more specific than those provided
   by the device or user profile.  The examples here focus on
   constraints to impose policy from the local network.  However the
   facility to impose policy may be equally useful to the user and
   device profiles.

   It MUST be possible to impose policy in any of the profile sources
   that constrains, overwrites or modifies properties provided in data
   sets from other sources.


4.  Overall Data Set Schema

   This document defines an XML Schema, for SIP Profile Data Sets that
   provides:
   o  a base element type "setting" from which all settings in other
      schema definitions inherit (this allows other definitions to
      specify the content models for ways of combining settings; it is
      analogous to a C++ virtual base class).





Petrie, et al.           Expires April 26, 2006                [Page 16]


Internet-Draft              SIP UA Data Sets                October 2005


   o  Attributes to the "setting" element that define constraints and
      other properties used to impose policy that apply to the element
      value.  These attributes are inherited by elements that are
      derived from the abstract settings element.
   o  A root element for all property sets (the outermost container).

   The full text of the schema is in Appendix A; the following describes
   the usage of the schema in defining properties and combining them to
   construct the working profile of a User Agent.

4.1.  Data Primitives

   Each property in a profile data set is defined using XML Schema
   Datatypes [W3C.REC-xmlschema-2] and XML Schema Structures [W3C.REC-
   xmlschema-1].  A property is modeled by an XML element derived from
   the "setting" element in the SIP Profile Data Set Schema.  The
   element content is the setting value.

   Properties consisting of one single value can be expressed using a
   single XML element.  Properties that may consist of multiple values
   require the use of container elements.  A container element is
   defined for such a property.  This container can contain multiple XML
   elements, which each defines a possible value for that property (see
   examples in Section 4.5.2).

   When constructing a property set, the creator of a profile may not be
   able to know all of the capabilities of the User Agent that will
   receive that property set.  The creator of profile constraints or
   policies should be aware that a user agent may ignore properties that
   are unsupported or do not apply to its capabilities.

4.2.  Use of Namespaces

   XML namespaces [W3C.REC-xml-names-19990114] provide a means to
   uniquely identify the elements and datatypes defined in a data set.
   It is therefore RECOMMENDED that each data set specifies its own
   namespace.  The namespace URIs SHOULD be URNs [RFC2141], using the
   namespace identifier 'ietf' defined by [RFC2648] and extended by
   [I-D.mealling-iana-xmlns-registry].

4.3.  The 'property_set' Element

   The root element of a property set is "property_set"; it is the
   container that is provided to the user agent.  The elements contained
   within a property_set contain the specific properties which are to be
   applied to the user agent.  The properties may be simple types with a
   single value, complex types or container elements with a list of
   properties.



Petrie, et al.           Expires April 26, 2006                [Page 17]


Internet-Draft              SIP UA Data Sets                October 2005


4.4.  The Abstract 'setting_container' Element

   The "setting_container" element is the abstract element in which a
   list of properties which allow mutliple values may be contained.
   Elements derived from the "setting_container" element may contain
   zero or more elements derived from the "setting" element.  The
   "setting_container" element has an "excluded_policy" attribute.

4.5.  The Abstract 'setting' Element

   The setting element is the abstract element from which all profile
   properties or settings shall inherit.

   The setting element has a number of attributes that provide
   functionalities, which are generally useful for many properties.
   These attributes are inherited by properties that are derived from
   the settings element.  This enables the re-use of common
   functionalities and ensures a common syntax for these elements across
   different data sets.  The following functionalities are provided by
   attributes of the settings element:

   o  Property Access Control: 'visibility' attribute
   o  Policies: 'policy' attribute

   Additional attributes are defined in the schema that may used in
   elements derived from "setting".  By default these attributes cannot
   be set.  These attribute must be explicitly added to elements derived
   from the "setting" element:

   o  Unidirectional Properties: 'direction' attribute
   o  Preferences: 'q' attribute

4.5.1.  The 'visibility' Attribute

   The attribute "visibility" is defined on the "setting" element to
   specify whether or not the user agent is permitted to display the
   property value to the user.  This is used to hide setting values that
   the profile administrator may not want the user to see or know.  The
   "visibility" attribute has two possible values:

   o  visible: specifies that display of the property value is not
      restricted.  This is the default value of the attribute if it is
      not specified.
   o  hidden: Specifies that the user agent SHOULD NOT display the
      property value.  Display of the property value may be allowed
      using special administrative interfaces, but is not appropriate to
      the ordinary user.




Petrie, et al.           Expires April 26, 2006                [Page 18]


Internet-Draft              SIP UA Data Sets                October 2005


4.5.2.  The 'policy' Attributes

   The setting element has an optional 'policy' attribute.  The policy
   attribute is used to define the constraining properties of an
   element.  It defines how the element value is used by an endpoint
   (e.g. whether it can or can not be used in a session).  The following
   values are defined for the 'policy' attribute:

   o  allow: the value contained in the element is allowed and SHOULD be
      used in sessions.  This is the default value that is used if the
      'policy' attribute is omitted.
   o  disallow: the value contained in the element is forbidden and
      SHOULD NOT be used in sessions.

   The policy attribute can be omitted if the default policy 'allow'
   applies.

      OPEN ISSUE: The policy attribute may not be needed for elements
      outside of a settings_container.  Further clarification is needed
      on this.  Using the policy attribute only inside containers would
      further simplify the specification of profile data.

4.5.3.  The 'excluded_policy' Attributes

   The "setting_container" element has an optional 'excluded_policy'
   attribute.  This attribute specifies the default policy for all
   values that are not in the container.  Elements that are present in
   the container have their own 'policy' attribute, which defines the
   policy for that element.  The following values are defined for the
   'excluded_policy' attribute:

   o  allow: values not listed in the container are allowed and MAY be
      used in sessions.  This is the default value that is used if the
      'excluded_policy' attribute is omitted.
   o  disallow: values not listed in the container are forbidden and
      MUST NOT be used in sessions.

   The excluded_policy attribute can be omitted if the default policy
   'allow' applies.  The following example shows a policy that allows
   the media type audio and disallows all other media types in sessions
   (effectively, this construct requires the use of audio):


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





Petrie, et al.           Expires April 26, 2006                [Page 19]


Internet-Draft              SIP UA Data Sets                October 2005


4.5.4.  The 'direction' Attribute

   Some properties are unidirectional and only apply to messages or data
   streams transmitted into one direction.  For example, a property for
   media streams can be restricted to outgoing media streams only.
   Unidirectional properties can be expressed by adding a 'direction'
   attribute to the respective element.

   The 'direction' attribute can have the following values:

   o  recvonly: the property only applies to incoming messages/streams.
   o  sendonly: the property only applies to outgoing messages/streams.
   o  sendrecv: the property applies to messages/streams in both
      directions.  This is the default value that is used if the
      'direction' attribute is omitted.

4.5.5.  The 'q' Attribute

   It should be possible to express a preference for a certain value, if
   multiple values are allowed within a property.  For example, it
   should be possible to express that the codecs G.711 and G.729 are
   allowed, but G.711 is preferred.  Preferences can be expressed by
   adding a 'q' attribute to a property element.  Elements derived from
   the "setting" element for which multiple occurrences and values are
   allowed SHOULD have a "q" attribute if the order is significant.
   Typically these elements are contained in an element derived from the
   "setting_container" element.  The 'q' attribute is only meaningful if
   the 'policy' attribute set to 'allowed'.  It must be ignored in all
   other cases.

   An element with a higher 'q' value is preferred over one with a lower
   'q' value. 'q' attribute values range from 0 to 1.  The default value
   is 0.5.

4.6.  The 'profile-uri' Element

   The <profile-uri> element contains the URI of this profile on the
   profile server.  The value contained in the profile-uri element may
   be different than the URI subscribe to when retrieving this profile.
   When the user agent retrieves a profile where the profile-uri is
   different than the subscribe to URI, the user agent SHOULD
   unsubscribe to the current URI and then subscribe to the new URI.

   The <profile-uri> element is optional and MAY occur only once inside
   a <property_set> element.  The profile-uri element is specific to the
   local-network, device, user or application profile in which it
   occurs.  It has no meaning outside of the profile in which it occurs
   and SHOULD NOT be merged.



Petrie, et al.           Expires April 26, 2006                [Page 20]


Internet-Draft              SIP UA Data Sets                October 2005


4.7.  The 'profile-credential' Element

   The <profile-credential> element contains the digest authentication
   information that SHOULD be used for authentication for the profile
   subscription via SIP or profile retrieval via HTTP, HTTPS, etc.  The
   profile-credential element is optional and MAY occur only once inside
   a property_set element.  The profile-credential element is specific
   to the local-network, device, user or application profile in which it
   occurs.  It has no meaning outside of the profile in which it occurs
   and SHOULD NOT be merged.  The profile-credential element MUST
   contain exactly one of each of the elements: realm, auth-user, a1-
   digest.

4.7.1.  realm Element

   The realm element contains the string that defines the realm to which
   this credential pertains.  The value of the realm element is the same
   as the realm parameter in the [RFC2617] headers: WWW-Authenticate,
   Authorization and the SIP [RFC3261] headers: Proxy-Authenticate and
   Proxy-Authorization.  If a match of the realm value is found, the
   user agent uses the values in the auth_user and a1_digest elements
   contained in the sip_credential element.  The exactly one realm
   element SHOULD be contained in a profile-credential element.

4.7.2.  auth_user Element

   The auth_user element contains the string value of the "username"
   parameter which SHOULD be used in Authorization and Proxy-
   Authorization request headers when retrying a request that was
   challenged for authentication.  Exactly one auth_user element SHOULD
   be contained in a profile-credential element.

4.7.3.  a1_digest Element

   The a1_digest element contains a string with the value of the A1
   digest of the username, realm and password as defined in [RFC2617].
   Exactly one a1_digest element SHOULD be contained in a profile-
   credential element.  The username and realm used to construct the
   value of the a1_digest element MUST match the values of the realm and
   auth_user elements contained in the profile-credential element with
   the a1_digest element.

4.8.  The 'profile-contact-uri' Element

   The <profile-contact-uri> element contains a contact URI (e.g. a SIP,
   HTTP URI or email address) under which the issuer of this profile can
   be reached.  The contact element may, for example, contain the
   address of a support hotline.



Petrie, et al.           Expires April 26, 2006                [Page 21]


Internet-Draft              SIP UA Data Sets                October 2005


   The <profile-contact-uri> element is optional and MAY occur multiple
   times inside a <property_set> element.  Multiple instances of the
   profile-contact-uri element allow multiple URI schemes to be provided
   for contact information.  The user agent MAY use the URI contained
   profile-contact-info element which has a URI scheme that the user
   agent supports and can make work to provide support help for the
   profile.  The user agent MAY provide the URIs to the user to contact
   the creator of the profile through other communication channels.  The
   profile-contact-uri element is specific to the local-network, device,
   user or application profile in which it occurs.  It has no meaning
   outside of the profile in which it occurs and SHOULD NOT be merged.

4.9.  The 'profile-info' Element

   The <profile-info> element provides a short textual description of
   the property that should be intelligible to the human user.  This
   element may, for example, contain information about the nature of
   this profile, such as "Access Network Profile".  The text in the
   <profile-info> element is in particular be helpful when a user needs
   to decide whether or not to use a newly downloaded profile or when
   problems with a profile (e.g. a policy conflict) occur.  A user agent
   MAY display this information in these cases.

   The <profile-info> element is optional and MAY occur only once inside
   a <property_set> element.  Te profile-info element is specific to the
   local-network, device, user or application profile in which it
   occurs.  It has not meaning outside of the profile in which it occurs
   and SHOULD NOT be merged.

4.10.  Merging Property Sets

   A UA may receive property sets from multiple sources, which need to
   be merged into a single combined document the UA can work with.

   Properties that have a single value (e.g. the maximum bandwidth
   allowed) require that a common value is determined for this property
   during the merging process.  The merging rules for determining this
   value need to be defined individually for each element in the schema
   definition.  Properties that allow multiple values (i.e. property
   containers) need to be merged by combining the values from the
   different data sets.  The following sections describe common merging
   algorithms.  A data set definition may refer to these algorithms.

4.10.1.  Single Numeric Value Merging Algorithm

   A general merging rule for elements with numeric values is to select
   the largest or the smallest value.  For example, a merging rule for a
   <max-bandwidth> element would be to select the smallest value from



Petrie, et al.           Expires April 26, 2006                [Page 22]


Internet-Draft              SIP UA Data Sets                October 2005


   the values that are in the competing data sets.

4.10.2.  Multiple Enumerated Value Merging Algorithm

   Multiple values in property containers are merged by combining the
   values from each of the competing data sets.  This is accomplished by
   copying the elements from each property container into the merged
   container.  Elements with identical values are only copied once.  The
   'policy' attribute of two elements with the same value is adjusted
   during the merging process according to Table 1.  If an element
   exists only in one property container, then the default policy of the
   other container (i.e. the excluded_policy) is used when accessing
   Table 1.  For example, if an element is disallowed in one data set
   and the element is not contained in the other data set but the
   default policy is allowed for that data set, then the values
   disallowed and allowed are used to access Table 1.  Consequently, the
   element will be disallowed in the merged data set.  Finally, the
   excluded_policy attributes of the containers are also merged using
   Table 1.  In addition to these merging rules, each schema may define
   specific merging rules for each property container.


   set 1 \ set 2 |  allow   | disallow
   --------------+----------+----------
   allow         |  allow   | disallow
   disallow      | disallow | disallow

               Table 1: merging policies.

   The following example illustrates the merging process for two data
   sets.  All elements are merged into one container and the policy
   attributes are adjusted according to Table 1.  The merged container
   has the default policy disallow, which is determined using Table 1.
   The entry for PCMA in the merged data set is redundant since it has
   the default policy.
















Petrie, et al.           Expires April 26, 2006                [Page 23]


Internet-Draft              SIP UA Data Sets                October 2005


   Data set 1:
   <codecs excluded_policy='allow'>
     <codec policy='disallow'>PCMA</codec>
   </codecs>

   Data set 2:
   <codecs excluded_policy='disallow'>
     <codec policy='allow'>PCMA</codec>
     <codec policy='allow'>G729</codec>
   </codecs>

   Merged data set:
   <codecs excluded_policy='disallow'>
     <codec policy='disallow'>PCMA</codec>
     <codec policy='allow'>G729</codec>
   </codecs>

   Some constellations of policy attributes result in an illegal merged
   data set.  They constitute a conflict that can not be resolved
   automatically.  For example, two data sets may define two non-
   overlapping sets of allowed audio codecs and both disallow all other
   codes.  The resulting merged set of codecs would be empty, which is
   illegal according to the schema definition of the codecs element.  If
   the use of these properties is enforced by both networks, the UA may
   experience difficulties or may not be able to set up a session at
   all.

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

4.10.3.  Closest Value First Merging Algorithm

   Some properties require that the values from different data sets are
   ordered based on the origin of the data set during the merging
   process.  Property values that come from a domain close to the user
   agent take precedence over values that were in a data set delivered
   by a remote domain.  This order can be used, for example, to select
   the property value from the closest domain.  In many cases, this is
   the local domain of the user agent.  For example, the URI of an
   outbound proxy could be merged this way.  This order can also be used
   to generate an ordered list of property values during the merging
   process.  For example, multiple values for media intermediaries can
   be ordered so that the closest media intermediary is traversed before
   the second closest intermediary and so on.

   This merging algorithm requires that the source of a data set is



Petrie, et al.           Expires April 26, 2006                [Page 24]


Internet-Draft              SIP UA Data Sets                October 2005


   considered.

   If property sets are delivered through the configuration framework
   [I-D.ietf-sipping-config-framework], the value received through a
   subscription using the "local-network" profile-type takes precedence
   over values received through other profile-type subscriptions.

      OPEN ISSUE: Can we define an order for 'device', 'user', and
      'application' profiles?

   The session-specific policy mechanism [I-D.hilt-sipping-session-
   policy-framework] provides an order among policy servers.  This order
   is based on the order, in which a SIP message traverses the network,
   starting with the closest domain.  This order can directly be used to
   order property values as described above.

4.11.  Common Types

   [The schema will also define a set of common types that are used in
   defining data sets (e.g. name-addr) in a future version of this
   draft.]


5.  Defining Data Sets

   This section covers several issues that should be take into
   consideration when specifying new data set schemas.  This is intended
   to be a guide to authors writing specifications defining a new data
   set schema or extensions to existing ones.

5.1.  Namespace

   It is RECOMMENDED that a data set defines a new XML namespace
   [W3C.REC-xml-names-19990114] to scope all of the properties that are
   defined in the name space.

5.2.  Property Definitions

   The properties defined in a data set schema may be simple (i.e.
   having a single value) or they may be complex (i.e. a container with
   multiple values).  Each property in the data set SHOULD inherit from
   the "setting" element.  Complex properties and all of their child
   elements each should inherit from "setting" as well.

   A data set specification should contain a section which defines the
   meaning of all of the properties contained in the data set.  The
   objective is to define the property such that implementers have a
   clear definition and semantics to interpret properties in a



Petrie, et al.           Expires April 26, 2006                [Page 25]


Internet-Draft              SIP UA Data Sets                October 2005


   consistent way.  User agents not only need to use the same profile
   content, they need to apply the properties in a consistent way to
   achieve true interoperability.

   The following information should be defined for each property in a
   data set:
   o  description: describe the meaning and application of the property.
   o  cardinality: define how many instances of this property element
      may occur in a data set (e.g. zero, one or many) as well as its
      relationship to any other properties in this or other data sets.
   o  default value: define the default value of this property if it is
      not set.  Describe if the default is different if the property is
      present and not set vs. completely absent from the data set.
      Define if the default varies in relation to another property.

5.3.  Merging Data Sets

   User agents may receive data sets from multiple sources.  They need
   to merge these data sets in order to create an overall data set they
   can work with.  Collisions on data sets may occur if multiple sources
   provide different values for the same properties.  These collisions
   need to be resolved during the merging process.

   A data set schema MUST define rules for merging data sets from
   different sources for each property that is defined.  Considerations
   for merging data sets are discussed in Section 4.10.  A data set
   schema must define if and how these consideration apply and MAY
   define alternative merging rules for specific settings.  A data set
   schema must also identify combinations of properties that constitute
   a conflict that can't resolved.  It may provide additional guidelines
   for the behavior of a user agent in these cases.


6.  Candidate Data Sets

   The following sections name some of the candidate data sets that are
   or may be defined.  These data sets can be aggregated to form
   profiles appropriate to the capabilities of a user agent
   implementation.

   o  SIP Protocol Data Set: the lowest common denominator set of
      properties common to all SIP user agents of any capability.  A
      schema covering the elements of this data set can be found in
      [I-D.petrie-sipping-sip-dataset].
   o  Media Data Set: this data set contains media related policies.  A
      schema covering the elements of this data set can be found in
      [I-D.ietf-sipping-media-policy-dataset].




Petrie, et al.           Expires April 26, 2006                [Page 26]


Internet-Draft              SIP UA Data Sets                October 2005


   o  Identity Data Set: AORs and lines (see [I-D.petrie-sipping-
      identity-dataset])
   o  HTTP Protocol Data Set: server settings.  Proxy for clients.
   o  NAT Traversal Data Set: settings for STUN, TURN etc.
   o  SIP Digit Maps Data Set: [I-D.petrie-sipping-voip-features-
      dataset]
   o  VoIP Features: [I-D.petrie-sipping-voip-features-dataset]
   o  Address Book:
   o  Buddy List:


7.  Security Considerations

   Security is mostly a delivery problem.  The delivery framework SHOULD
   provide a secure means of delivering the profile data as it may
   contain sensitive data that would be undesirable if it were stolen or
   sniffed.  Storage of the profile on the profile delivery server and
   user agent is an implementation problem.  The profile delivery server
   and the user agent SHOULD provide protection that prevents
   unauthorized access of the profile data.  The profile delivery server
   and the user agent SHOULD enforce the access control policies defined
   in the profile data sets if present.
      [The point of the access control construct on the data set is to
      provide some security policy on the visibility and ability to
      change sensitive properties.  Does the access control mechanism
      also create a security problem where the local network can set or
      hide properties from the user?]

   Some transport mechanisms for delivery of the profile data do not
   provide a secure means of delivery.  In addition some user agents may
   not have the resources to support the secure mechanism used for
   delivery (e.g.  TLS).


8.  IANA Considerations

   [TBD] XML Schema name space registration


9.  Change History

9.1.  Changes from draft-petrie-sipping-profile-datasets-02

   Removed "mandatory" policy attribute value to simplify use and
   profile merging issues.

   Session Independent Policy draft was split into separate media
   dataset draft and policy drafts.  Fixed references and information in



Petrie, et al.           Expires April 26, 2006                [Page 27]


Internet-Draft              SIP UA Data Sets                October 2005


   this draft to reflect the two drafts.

   Added concrete properties contained in elements: profile-uri,
   profile-credential, profile-contact-uri and profile-info.  Prior to
   this draft, there were only abstract elements defined in this draft.
   These elements have been added to contain information that is
   specific to the profile and are independent of the specific profile
   data sets contained in the profile.

   Split references into normative and informative sections.

   Numerous editorial changes

9.2.  Changes from draft-petrie-sipping-profile-datasets-01

   Split out the core SIP Protocol dataset into a separate draft.

   Schema changes: created setting_container, added q and direction
   attributes along with other tweaks to the schema.

   Better integration and coordination with [I-D.ietf-sipping-media-
   policy-dataset].  The media/codec dataset is now completely contained
   in the policy draft.

9.3.  Changes from draft-petrie-sipping-profile-datasets-00

   Added use case scenarios for codecs, SIP transport protocol and
   outbound proxy to better illustrate requirements.  Some of the
   derived requirements are listed with the use cases.

   Added settings element attributes "policy" and "visibility" to
   provide merging constraints and access control capability.  Removed
   the element based merging constraints using the: forbid, set_any,
   set_all and set_one elements.  This greatly simplifies the degree of
   XML operations required to perform the request merging.

   Defined default merging policy and profile source precedence along
   with the option for different policies to be describe in specific
   settings definition documents.

   Added example merging with XML profiles from device and user for the
   SIP transport protocol.


10.  References






Petrie, et al.           Expires April 26, 2006                [Page 28]


Internet-Draft              SIP UA Data Sets                October 2005


10.1.  Normative References

   [I-D.hilt-sipping-session-policy-framework]
              Hilt, V., "A Framework for Session Initiation Protocol
              (SIP) Session Policies",
              draft-hilt-sipping-session-policy-framework-00 (work in
              progress), October 2005.

   [I-D.ietf-sipping-config-framework]
              Petrie, D., "A Framework for Session Initiation Protocol
              User Agent Profile Delivery",
              draft-ietf-sipping-config-framework-07 (work in progress),
              July 2005.

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

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

   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
              Leach, P., Luotonen, A., and L. Stewart, "HTTP
              Authentication: Basic and Digest Access Authentication",
              RFC 2617, June 1999.

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

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

   [W3C.REC-xmlschema-1]
              Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
              "XML Schema Part 1: Structures", W3C REC-xmlschema-1,
              May 2001, <http://www.w3.org/TR/xmlschema-1/>.

   [W3C.REC-xmlschema-2]
              Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes",
              W3C REC-xmlschema-2, May 2001,
              <http://www.w3.org/TR/xmlschema-2/>.






Petrie, et al.           Expires April 26, 2006                [Page 29]


Internet-Draft              SIP UA Data Sets                October 2005


10.2.  Informative References

   [I-D.ietf-sipping-media-policy-dataset]
              Hilt, V., "A User Agent Profile Data Set for Media
              Policy", draft-ietf-sipping-media-policy-dataset-00 (work
              in progress), October 2005.

   [I-D.petrie-sipping-identity-dataset]
              Petrie, D., "The Session Initiation Protocol User Agent
              Identity Profile Data Set",
              draft-petrie-sipping-identity-dataset-00 (work in
              progress), October 2005.

   [I-D.petrie-sipping-sip-dataset]
              Petrie, D., "The Core Session Initiation Protocol User
              Agent Profile Data Set",
              draft-petrie-sipping-sip-dataset-00 (work in progress),
              July 2005.

   [I-D.petrie-sipping-voip-features-dataset]
              Petrie, D., "The Session Initiation Protocol User Agent
              VoIP Features Data Set",
              draft-petrie-sipping-voip-features-dataset-00 (work in
              progress), October 2005.

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

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

   [RFC3470]  Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for
              the Use of Extensible Markup Language (XML) within IETF
              Protocols", BCP 70, RFC 3470, January 2003.


Appendix A.  SIP UA Profile Schema


   <?xml version='1.0' encoding='iso-8859-1' standalone='yes'?>
   <!DOCTYPE schema [
   <!ENTITY % doc_src
   "http://scm.sipfoundry.org/rep/ietf-draft/petrie/profile-data-sets">
   ]>
   <!--
       XML Schema for SIP Profile Data Sets
     -->
   <schema
   xmlns:spds='http://sipfoundry.org/schema/profile-data-sets-02'



Petrie, et al.           Expires April 26, 2006                [Page 30]


Internet-Draft              SIP UA Data Sets                October 2005


   targetNamespace='http://sipfoundry.org/schema/profile-data-sets-02'
   xmlns='http://www.w3.org/2001/XMLSchema'
       >
    <annotation>
      <documentation>
        Proposed XML metalanguage for the description of
        SIP User Agent Profile Data Sets.
      </documentation>
      <documentation source='%doc_src;'/>
    </annotation>

   <!-- Types
     Later versions of the Internet-Draft of which this is a part may
     include additional data type definitions and entities useful
     in defining SIP data.
    -->

    <simpleType name="port_num">
     <restriction base="integer">
      <minExclusive value='0' />
      <maxInclusive value='65535' />
     </restriction>
    </simpleType>

    <simpleType name="q_val">
     <restriction base="float">
      <minInclusive value='0' />
      <maxInclusive value='1' />
     </restriction>
    </simpleType>

    <simpleType name="transport_protocol">
      <restriction base="string">
        <enumeration value="TCP"/>
        <enumeration value="UDP"/>
        <enumeration value="TLS"/>
      </restriction>
    </simpleType>

   <!-- Attrubutes that may be optionally used
    -->

   <attributeGroup name="multi_setting_attributes" >
     <annotation>
       <documentation>
         The multi_setting_attributes attribute group is
         for attributes that are applicable to settings that
         may have multiple values in a container.



Petrie, et al.           Expires April 26, 2006                [Page 31]


Internet-Draft              SIP UA Data Sets                October 2005


       </documentation>
       <documentation source='%doc_src;'/>
     </annotation>
     <attribute name="q" type="q_val" default="0.5" >
       <annotation>
         <documentation>
           The q attribute is used to define a preference for a
           setting.  It can be used to define that one value
           of a setting is preferred over another value.
         </documentation>
         <documentation source='%doc_src;'/>
       </annotation>
     </attribute>
   </attributeGroup>

   <attributeGroup name="directional_setting_attributes" >
     <annotation>
       <documentation>
         The multi_setting_attributes attribute group is
         for attributes that are applicable to settings that
         have a directional implication (e.g. incoming or
         outgoing).
       </documentation>
       <documentation source='%doc_src;'/>
     </annotation>
     <attribute name="direction" default="sendrecv" >
       <annotation>
         <documentation>
           The direction attribute is used to define
           unidirectional settings.
         </documentation>
         <documentation source='%doc_src;'/>
       </annotation>
       <simpleType>
         <restriction>
           <enumeration value="sendrecv"/>
           <enumeration value="sendonly"/>
           <enumeration value="recvonly"/>
         </restriction>
       </simpleType>
     </attribute>
   </attributeGroup>

   <!-- Elements
     Later versions of the Internet-Draft of which this is a part may
     include additional data type definitions and entities useful
     in defining SIP data.
    -->



Petrie, et al.           Expires April 26, 2006                [Page 32]


Internet-Draft              SIP UA Data Sets                October 2005


    <element name="property_set">
      <annotation>
        <documentation>
        The property_set element is the root element returned in
        response to a request for a profile data set.
        </documentation>
      </annotation>
      <complexType>
        <sequence minOccurs="0" maxOccurs="unbounded">
          <choice>
            <element ref="spds:setting" />
            <element ref="spds:setting_container" />
          </choice>
        </sequence>
      </complexType>
    </element>

    <element name="setting_container" abstract="true">
    <!-- TBD -->
      <complexType>
        <complexContent>
          <restriction base="anyType">
            <sequence minOccurs="0" maxOccurs="unbounded">
              <element ref="spds:setting" />
            </sequence>
            <attribute name="excluded_policy"
                       default="allowed">
              <annotation>
                <documentation>
                   The container_policy attibute is used to define the
                   policy for settings not explcitly contained in the
                   container.  disallowed means that setting
                   values not included in the container are considered
                   to be diallowed.   The value of allowed
                   indicates that values not included in the container
                   are allowed.
                </documentation>
                <documentation source='%doc_src;'/>
              </annotation>
              <simpleType>
                <restriction>
                  <enumeration value="disallowed"/>
                  <enumeration value="allowed"/>
                </restriction>
              </simpleType>
            </attribute>
          </restriction>
        </complexContent>



Petrie, et al.           Expires April 26, 2006                [Page 33]


Internet-Draft              SIP UA Data Sets                October 2005


      </complexType>
    </element>

    <element name="setting" abstract="true">
     <annotation>
      <documentation>
       The 'setting' element is an abstract used as the basis for the
       definition of the setting elements in property schemas derived
       from this one.

       It serves here as a placeholder in constructing the content
       models for the container elements used to group settings into
       sets.
      </documentation>
      <documentation source='%doc_src;'/>
     </annotation>
     <complexType>
      <complexContent>
       <restriction base="anyType">
        <attribute name="policy" default="allow" >
          <annotation>
            <documentation>
              The policy attribute is used to define the strength to
              which a setting should be used.  It can also be viewed
              as the finality to which a setting may be overrided.
            </documentation>
            <documentation source='%doc_src;'/>
          </annotation>
          <simpleType>
           <restriction>
            <enumeration value="allow"/>
            <enumeration value="disallow"/>
           </restriction>
          </simpleType>
        </attribute>
        <attribute name="visibility" default="visible" >
          <annotation>
            <documentation>
              The visibility attribute indicates whether the user
              agent should show the setting value(s) to the user.
            </documentation>
            <documentation source='%doc_src;'/>
          </annotation>
          <simpleType>
           <restriction>
            <enumeration value="visible"/>
            <enumeration value="hidden"/>
           </restriction>



Petrie, et al.           Expires April 26, 2006                [Page 34]


Internet-Draft              SIP UA Data Sets                October 2005


          </simpleType>
        </attribute>
       </restriction>
      </complexContent>
     </complexType>
    </element>

   </schema>



Appendix B.  Acknowledgments







































Petrie, et al.           Expires April 26, 2006                [Page 35]


Internet-Draft              SIP UA Data Sets                October 2005


Authors' Addresses

   Daniel Petrie
   SIPez LLC.
   34 Robbins Rd.
   Arlington, MA  02476
   US

   Phone: +1 617 273 4000
   Email: dan.ietf AT SIPez DOT com
   URI:   http://www.SIPez.com/


   Scott Lawrence
   Pingtel Corp.
   400 W. Cummings Park
   Suite 2200
   Woburn, MA  01801
   US

   Phone: "Scott Lawrence (+1 781 938 5306)" <sip:slawrence@pingtel.com>
   Email: slawrence AT pingtel DOT com
   URI:   http://skrb.org/scott/


   Martin Dolly
   AT&T Labs
   200 Laurel Avenue
   Middletowm, NJ  07748
   US

   Phone:
   Email: mdolly AT att DOT com
   URI:


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

   Email: volkerh@bell-labs.com








Petrie, et al.           Expires April 26, 2006                [Page 36]


Internet-Draft              SIP UA Data Sets                October 2005


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




Petrie, et al.           Expires April 26, 2006                [Page 37]