SIPPING                                                        D. Petrie
Internet-Draft                                                SIPez LLC.
Intended status: Standards Track                   S. Channabasappa, Ed.
Expires: April 6, September 2, 2007                                   October 3, 2006                                     CableLabs

A Framework for Session Initiation Protocol User Agent Profile Delivery
               draft-ietf-sipping-config-framework-09.txt
                 draft-ietf-sipping-config-framework-10

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 6, September 2, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

Abstract

   This document defines the application of a set of protocols for
   providing profile data framework to enable configuration of Session
   Initiation Protocol (SIP) User Agents in SIP user agents. deployments.  The objective is to
   define
   framework provides a means for automatically providing to deliver profile data that a user
   agent needs User Agents
   need to be functional, without user or administrative automatically and with minimal (preferably
   none) User and Administrative intervention.  The framework for discovery, delivery, notification describes
   how SIP User Agents can discover sources, request profiles and updates of user agent
   receive notifications related to profile data is defined here. modifications.  As part of
   this framework framework, a new SIP event package is defined here for the notification
   of profile changes.  This  The framework is also intended to
   ease ongoing administration and upgrading of large scale deployments
   of SIP user agents. provides for multiple data
   retrieval options, without requiring or defining retrieval protocols.
   The contents and format framework does not include specification of the profile data to
   be defined is outside the scope of this document.
   within its scope.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requirements  Terminology  . . . . . . . . . . . . . . . . . . .  4
   3.  Profile Delivery Framework Terminology . . . . . .  4
   3.  Overview . . . . . .  5
   4.  Overview . . . . . . . . . . . . . . . . . . . . .  6
     3.1.   Reference Model . . . . . .  5
   5.  Use Cases . . . . . . . . . . . . . . .  6
     3.2.   Profile Life Cycle  . . . . . . . . . . .  7
     5.1.   Service Provider Use Case Scenario Bootstrapping with
            Digest Authentication . . . . . . . .  9
     3.3.   Data Model and Profile Types  . . . . . . . . . .  7
     5.2.   Service Provider Use Case Scenario Bootstrapping with
            Device Certificate . . . . 10
   4.  Use Cases  . . . . . . . . . . . . . . .  9
   6.  Data Model . . . . . . . . . . . 11
     4.1.   Client with different Data and SIP Service Providers  . . 11
     4.2.   Clients supporting multiple users from different
            Service Providers . . . . . . . . . . . . . 10
   7.  Profile Change Event Notification Package . . . . . . . 13
   5.  Profile Delivery Framework . . . 11
     7.1.   Event Package Name . . . . . . . . . . . . . . . 15
     5.1.   Profile Discovery . . . . 12
     7.2.   Event Package Parameters . . . . . . . . . . . . . . . . 12
     7.3. 18
       5.1.1.  SIP SUBSCRIBE Bodies for the Local-Network Profile Type . . . 19
       5.1.2.  SIP SUBSCRIBE for the Device Profile Type  . . . . . . 20
       5.1.3.  SIP SUBSCRIBE for the User Profile Type  . . . . . . . 24
       5.1.4.  Caching of SIP Subscription URIs . . . . 16
     7.4.   Subscription Duration . . . . . . . 24
     5.2.   Profile Enrollment  . . . . . . . . . . . 16
     7.5.   NOTIFY Bodies . . . . . . . . 25
     5.3.   Profile Notification  . . . . . . . . . . . . . . 16
     7.6.   Notifier processing of SUBSCRIBE requests . . . . 26
     5.4.   Profile Retrieval . . . . 17
     7.7.   Notifier generation of NOTIFY requests . . . . . . . . . 19
     7.8.   Subscriber processing of NOTIFY requests  . . . . . . . . 19
     7.9.   Handling of forked requests 26
     5.5.   Profile Change Upload . . . . . . . . . . . . . . . 20
     7.10.  Rate of notifications . . . 26
     5.6.   Additional Considerations . . . . . . . . . . . . . . . 20
     7.11.  State Agents . 27
       5.6.1.  Manual retrieval of the Device Profile . . . . . . . . 27
       5.6.2.  Client Types . . . . . . . . . . . . . 20
     7.12.  Examples . . . . . . . . 28
       5.6.3.  Profile Data . . . . . . . . . . . . . . . . 20
     7.13.  Use of URIs to Retrieve State . . . . . 28
       5.6.4.  Profile Data Frameworks  . . . . . . . . . 21
       7.13.1.  Device URIs . . . . . . 28
       5.6.5.  Additional Profile Types . . . . . . . . . . . . . . . 22
       7.13.2.  User URIs 29
   6.  Event Package Definition . . . . . . . . . . . . . . . . . . . 29
     6.1.   Event Package Name  . . . 24
       7.13.3.  Local Network URIs . . . . . . . . . . . . . . . . 29
     6.2.   Event Package Parameters  . 24
   8.  Profile Delivery Framework Details . . . . . . . . . . . . . . 25
     8.1.   Discovery of Subscription URI . 29
     6.3.   SUBSCRIBE Bodies  . . . . . . . . . . . . . 25
       8.1.1.   Discovery of Local Network URI . . . . . . . 33
     6.4.   Subscription Duration . . . . 25
       8.1.2.   Discovery of Device URI . . . . . . . . . . . . . . 33
     6.5.   NOTIFY Bodies . 26
       8.1.3.   Discovery of User URI . . . . . . . . . . . . . . . . 29
     8.2.   Enrollment with Profile Server . . . . . 34
     6.6.   Notifier Processing of SUBSCRIBE Requests . . . . . . . . 29
     8.3.   Notification 34
     6.7.   Notifier Generation of Profile Changes NOTIFY Requests  . . . . . . . . . 35
     6.8.   Subscriber Processing of NOTIFY Requests  . . . . . 29
     8.4.   Retrieval of Profile Data . . . 35
     6.9.   Handling of Forked Requests . . . . . . . . . . . . . 30
     8.5.   Upload . . 36
     6.10.  Rate of Profile Changes Notifications . . . . . . . . . . . . . . . . 30
   9.  IANA Considerations . . 36
     6.11.  State Agents  . . . . . . . . . . . . . . . . . . . 30
     9.1.   SIP Event Package . . . 36
   7.  Examples . . . . . . . . . . . . . . . . . 30
     9.2.   New HTTP Event Header . . . . . . . . . . 36
     7.1.   Example 1: Client requesting profile  . . . . . . . . 31
   10. Security Considerations . . 36
     7.2.   Example 2: Client obtaining change notification . . . . . 40
   8.  IANA Considerations  . . . . . . . . . . . . 31
     10.1.  Confidential Profile Content in NOTIFY Request . . . . . 32
     10.2.  Confidential Profile Content via Content Indirection . . 33
     10.3.  Integrity protection for non-confidential profiles . . 44
     8.1.   SIP Event Package . 34
     10.4.  Initial Enrollment Using a Manufacturer's Certificate . . 34
   11. Acknowledgements . . . . . . . . . . . . . . . . . 44
     8.2.   New HTTP Event Header . . . . . . 36
   12. Change History . . . . . . . . . . . . 44
   9.  Security Considerations  . . . . . . . . . . . . 36
     12.1.  Changes from
            draft-ietf-sipping-config-framework-08.txt . . . . . . . 36
     12.2.  Changes from
            draft-ietf-sipping-config-framework-07.txt 45
     9.1.   Event Package . . . . . . . 36
     12.3.  Changes from
            draft-ietf-sipping-config-framework-06.txt . . . . . . . 37
     12.4.  Changes from
            draft-ietf-sipping-config-framework-05.txt . . . . . . . 37
     12.5.  Changes from
            draft-ietf-sipping-config-framework-04.txt . 45
     9.2.   Profile Life Cycle  . . . . . . 38
     12.6.  Changes from
            draft-ietf-sipping-config-framework-03.txt . . . . . . . 38
     12.7.  Changes from
            draft-ietf-sipping-config-framework-02.txt . . . . . . 46
     9.3.   Profile Data  . 38 . . . . . . . . . . . . . . . . . . . . . 46
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
   11. Open Items . . . . . . . . . . . . . . . . . . . . . . . . . . 47
   12. Change History . . . . . . . . . . . . . . . . . . . . . . . . 48
     12.1.  Changes from
            draft-ietf-sipping-config-framework-09.txt  . . . . . . . 48
     12.2.  Changes from
            draft-ietf-sipping-config-framework-08.txt  . . . . . . . 49
     12.3.  Changes from
            draft-ietf-sipping-config-framework-07.txt  . . . . . . . 49
     12.4.  Changes from
            draft-ietf-sipping-config-framework-06.txt  . . . . . . . 49
     12.5.  Changes from
            draft-ietf-sipping-config-framework-05.txt  . . . . . . . 50
     12.6.  Changes from
            draft-ietf-sipping-config-framework-04.txt  . . . . . . . 50
     12.7.  Changes from
            draft-ietf-sipping-config-framework-03.txt  . . . . . . . 51
     12.8.  Changes from
            draft-ietf-sipping-config-framework-01.txt
            draft-ietf-sipping-config-framework-02.txt  . . . . . . . 39 51
     12.9.  Changes from
            draft-ietf-sipping-config-framework-00.txt
            draft-ietf-sipping-config-framework-01.txt  . . . . . . . 39 51
     12.10. Changes from
            draft-petrie-sipping-config-framework-00.txt
            draft-ietf-sipping-config-framework-00.txt  . . . . . . . 39 51
     12.11. Changes from draft-petrie-sip-config-framework-01.txt
            draft-petrie-sipping-config-framework-00.txt  . . 40 . . . . 52
     12.12. Changes from draft-petrie-sip-config-framework-01.txt . . 52
     12.13. Changes from draft-petrie-sip-config-framework-00.txt . . 40 52
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 53
     13.1.  Normative References  . . . . . . . . . . . . . . . . . . 40 53
     13.2.  Informative References  . . . . . . . . . . . . . . . . . 41
   Author's Address . 54
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 54
   Intellectual Property and Copyright Statements . . . . . . . . . . 45 56

1.  Introduction

   Today all

   SIP (Session Initiation Protocol) [RFC3261] user agent
   implementers use proprietary means of delivering user, device and
   local network policy profiles User Agents require configuration data to the function properly.
   Examples include network, Client and user agent.  The profile
   delivery framework defined in specific information.
   Ideally, this document is intended to enable a
   first phase migration to a standard means of providing profiles to
   SIP user agents.  It is expected that UA (User Agent) implementers
   will configuration process should be able to use this automatic and require
   minimal or no user intervention.

   Many deployments of SIP User Agents require dynamic configuration and
   cannot rely on pre-configuration.  This framework as provides a standard
   means of delivering their
   existing proprietary data profiles (i.e. using their existing
   proprietary binary or text formats).  This in itself is a tremendous
   advantage in that a providing dynamic configuration which simplifies deployments
   containing SIP environment can use a single profile delivery
   server for profile data to user agents User Agents from multiple implementers.
   Follow-on standardization activities can:
   1.  define a standard profile content format framework (e.g.  XML
       with namespaces [W3C.REC-xml-names11-20040204] or name-value
       pairs [RFC0822]).
   2.  specify the content (i.e. name the profile data parameters, xml
       schema, name spaces) of the data profiles.

   One of the objectives of the vendors.

   This framework described in this document is
   to provide a start up experience similar also addresses modifications to that of users of an
   analog telephone.  When you plug in an analog telephone it just works
   (assuming the line is live profiles and the switch has been provisioned).
   There is no end user configuration required
   corresponding change notifications to make analog phone
   work, at least in a basic sense.  So the objective here is to be able
   to take SIP User Agents using a new SIP user agent out of
   event package.  However, the box, plug it in or install framework does not define 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.

   Another objective is to provide a scalable means for ongoing
   administration content or
   format of profiles.  Administrators and users are likely to
   want to make changes to profiles.

   Additional requirements for the framework defined in this document
   are described in: [I-D.ietf-sipping-ua-prof-framewk-reqs],
   [I-D.sinnreich-sipdev-req] actual profile data, leaving that to future
   standardization activities.

2.  Requirements  Terminology

   Keywords

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT" NOT", "RECOMMENDED", "MAY", and
   "MAY" that appear "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Profile Delivery Framework Terminology

   profile - data set specific to a user, device, or

   In addition, this document introduces and utilizes the local network.
   device - following
   terms:

   Client:  software or hardware appliance entity containing one or more SIP user
      agents.
   profile content server - The server that provides

   Device:  the content terms 'Client' and 'Device' are used interchangeably
      within this framework.

   Service Provider:  a logical entity providing one or more services.
      This can refer to private enterprises or public entities.

   Profile:  configuration data set specific to an entity (for example,
      user, device, local network or other).

   Profile Type:  a particular category of Profile data (for example,
      User, Device, Local Network or other).

   Profile Delivery Server (PDS):  the source of a Profile, it is the
      profiles using
      logical collection of the protocol specified Profile Notification Component (PNC) and
      the Profile Content Component(PCC).

   Profile Notification Component (PNC):  the logical component of a
      Profile Delivery Server that is responsible for enrolling Clients
      and providing profile notifications.

   Profile Content Component (PCC):  the logical component of a Profile
      Delivery Server that is responsible for storing, providing and
      accepting profile content.

   Profile Discovery:  discovery of a Profile Delivery Server (PDS) by
      the URI scheme.
   notifier - As Client.

   Profile Enrollment:  process of enrolling with one or more Profile
      Delivery Server(s) by a Client.

   Profile Notification:  notification of a requested or changed profile
      by the PDS.

   Profile Retrieval:  retrieval of Profile data from a PDS by a Client.

   Profile Change Upload:  upload of profile data changes to one or more
      PDSs by authorized entities such as a Client

   Notifier:  as defined in [RFC3265] the SIP user agent server which
      processes SUBSCRIBE requests for events and sends NOTIFY requests
      with profile data or URIs (Uniform Resource Identifiers) that
      point to the data.
   profile delivery server - The logical collection

   Instance ID:  text identifier globally unique across all Clients.

3.  Overview

   This section provides an overview of the notifier configuration framework.  It
   introduces the reference model and explains key concepts such as the server which provides
   Profile Life Cycle and the contents Profile types.  The framework is presented
   in Section 5.

3.1.  Reference Model

   The design of the notification either
      directly in framework was the NOTIFY requests or indirectly via profile URI(s).
   hotelling- when result of a user moves careful analysis to
   identify the configuration needs of a new user agent (i.e. that is not
      already provisioned to know wide range of SIP deployments.
   As such, the user's identity, credentials or
      profile data) and gives reference model provides for a great deal of
   flexibility, while breaking down the user agent sufficient information interactions to
      retrieve their basic
   forms which can be reused in many different scenarios.

   In its simplest form, the user's profile(s).  The user agent either permanently
      or temporarily makes reference model for the user's profiles effective on that user
      agent.
   nomadic- when framework defines
   the user agent moves to a different local network
   instance id- text identifier globally unique across all user agent
      (soft interactions between the Profile Delivery Server(PDS) and hard devices)

4.  Overview the
   Client.  The profile life cycle can be described by five functional steps.
   These steps are not necessarily discrete.  However it Client is useful to
   describe these steps as logically distinct.  These steps are named as
   follows:

   Discovery -  discover a profile delivery server
   Enrollment - enroll with SIP UA which needs the profile delivery server
   Profile Retrieval - retrieve profile data
   Profile Change Notification - receive notification of profile changes
   Profile Change Upload - upload profile data changes back to
   effectively function in the
      profile delivery server

   Discovery network.  The PDS is the process by which a UA finds the address responsible for
   responding to Client requests and port at
   which it enrolls with providing the profile delivery server.  As there is no
   single discovery mechanism which will work in all network
   environments, a number of discovery mechanisms are defined with a
   prescribed order in which the UA tries them until one succeeds. data.  The
   means
   set of discovery is described in Section 8.1.

   Enrollment interactions between these entities is the process by which a UA makes itself known referred to as the
   profile delivery server.  In enrolling,
   Profile Life Cycle.  This reference model is illustrated in the UA provides identity
   information, requested profile type(s) and supported protocols for
   profile retrieval.  It also subscribes
   diagram below.

                                           +-------------------------+
    +---------+       Interactions         | Profile Delivery Server |
    | Client  |<==========================>|  +---+          +---+   |
    | (SIP UA)|    (Profile Life Cycle)    |  |PNC|          |PCC|   |
    +---------+                            |  +---+          +---+   |
                                           +-------------------------+

                                PNC = Profile Notification Component
                                PCC = Profile Content Component

                         Framework Reference Model
   The PDS is subdivided into two logical components:
   o  Profile Notification Component (PNC), responsible for enrolling
      Clients in Profile event subscriptions and providing Profile
      change notifications;
   o  Profile Content Component (PCC), responsible for storing,
      providing access to, and accepting updates related to profile
      content.

   SIP deployments vary considerably.  To be effective, the
   configuration framework needs to consider a mechanism for
   notification comprehensive set of profile changes.  As
   scenarios that is representative of most deployments.  The figure
   below provides a result system level view of enrollment, the UA
   receives the device, user and Service
   Provider relationships that may be involved.

        --------
      /          \
     |   Service  |
     |  Provider  |            - > Provides 'Client'(e.g. allowed Users)
      \     Y    /                 & 'User'(such as Services) profile
        --------
            |         -----
            |       / Local \
            |      | Network |
            |      | Provider| - > Provides 'Local Network' profile
            |       \   Z   /      data or (e.g. STUN Server Address)
            |         -----
            |         /
            |        /
      ===============
     ( Local Network )
      ===============
            |
            |
            |
        ---------
       | Client X|            - > Needs the URI for each of 'Client' profile (from Y)
        ---------                  & 'local network' profile (from Z)
         /     \
        /       \
      ------   ------
     |User A| |User B|        - > Users need 'User' profile (from Y)
      ------   ------
                       Framework System Level Model

   Based on the profiles that system level model, the
   profile delivery server is able following considerations are
   relevant.

   Client connectivity:
   o  Clients can connect either directly to provide.  Each profile type (set)
   requires a separate enrollment or SUBSCRIBE session.  A profile type
   may represent one Service Provider or more data sets.  Enrollment via
      other local networks (for example, home network, Public Wi-Fi
      Hotspots, enterprise managed LAN, etc.);
   o  Local networks through which is performed
   by the device by constructing and sending a SUBSCRIBE request Clients connect may wish to
   profile delivery provide
      their own configuration information particular to that specific
      network (for example, STUN server for the event package described in Section 7.

   Profile Retrieval information, local Proxy, etc.)
      which is the process independent of retrieving the content for each
   of the profiles requested by Service Provider (who provides
      services) or the UA. particular User.

   Service provider relationships:
   o  The profiles are retrieved
   either directly or indirectly from local network provider (the network the NOTIFY request body as
   described in Section 7.5 Client connects to)
      and Section 8.4.

   Profile Change Notification is the process by which the profile
   delivery server notifies Service Provider (that hosts the actual voice or other
      services) can often be different entities, with no administrative
      or business relationship to each other;
   o  There may be multiple different Service Providers involved, one
      for each service type a User subscribes to (telephony service,
      instant messaging, etc); this Framework does not specify explicit
      behavior in such a scenario, but it does not prohibit its usage
      either
   o  Each User accessing services via a Client may subscribe to
      different sets of services, from different Service Providers;

   User-Client relationship:
   o  The relationship between Clients and Users can be many-to-many
      (for example, a particular UA that instance may allow for many Users to
      obtain subscription services through it, and individual Users may
      have access to multiple different UA devices);
   o  Each User may have different preferences for use of services, and
      presentation of those services in the content Client user interface;
   o  Each User may have different personal information applicable to
      use of one the Client device, either as related to particular
      services, or more independent of them.

   The observations above show a need for a clear distinction between
   different Profile Types, based on the source and purpose of the
   configuration data contained, and a need for these profiles has changed.  If the content is provided indirectly, to be
   manageable by different PDSs.  Accordingly, the
   UA MAY retrieve framework identifies
   the following minimal Profile Types.

   Local-Network Profile:  refers to profile from the specified URI upon receipt of data as provided by the change notification.  Profile change notification
      Local Network to which a Client is directly connected;

   Device Profile:  refers to profile data provided by the NOTIFY request for the event package as described in Section 7.8
   and Section 8.3.

   Profile Change Upload is the process by which a UA Service
      Provider or other entity
   (e.g. corporate directory or configuration management server) pushes
   a change which is specific to the particular
      Client;

   User Profile:  refers to profile data back up to provided by the profile delivery server.
   This process Service
      Provider or other entity which is described in Section 8.5.

   This framework defines a new SIP event package [RFC3265] specific to solve
   enrollment and profile change notification steps.  The event package
   in Section 7 defines everything but the mandatory content type.  This
   makes this event package abstract until the content type is bound. particular User.

   The profile content type definition of additional Profile Types and their usage is
   allowed, but is outside of the scope for of this document.  It is the author's belief that it would be a huge
   accomplishment if all SIP user agents used this framework for
   delivering their existing proprietary profiles.  Even though this
   does not accomplish interoperability

   The remainder of profiles, it is a big first
   step in easing this section provides more information on the administration of SIP user agents.  The definition two
   vital components of standard profiles the framework: Profile Life Cycle and data sets (see [I-D.petrie-sipping-profile-
   datasets] ) will enable interoperability as a subsequent step.

   The question arises as Profile
   Types.

3.2.  Profile Life Cycle

   Automated Profile delivery to why SIP should be used for Clients requires proactive behavior on
   the profile
   delivery framework.  In this document SIP is used for only a small
   portion part of the framework.  Other existing protocols are a Client.  It also requires one or more
   appropriate for transport of PDSs which
   provide the profile contents (to and from data.  Profile Delivery is usually initiated when
   the
   user agent) Client discovers PDSs and are suggested in this document. requests profile data.  The discovery step
   is simply profile
   data can be modified by the Client (for example, by a specified order User) and application of existing protocols
   (see Section 8.1).  SIP is only needed for the enrollment (see
   Section 8.2) and change notification functionality (see Section 8.3)
   of the profile delivery framework.  In many SIP environments (e.g.
   carrier/subscriber and multi-site enterprise) firewall, NAT (Network
   Address Translation) and IP addressing issues make it difficult
   subsequently uploaded to
   get messages between the profile delivery server and PDS.  Alternatively, the profile data
   can be modified by an authorized entity such as an administrative or
   user agent
   requiring the profiles.

   With SIP the users interface and devices already are assigned globally routable
   addresses.  In addition the firewall and NAT problems are already
   presumably solved Client is notified through an event
   notification.

   The specific functional steps involved in these interactions,
   collectively termed Profile Life Cycle, are as follows:

   Profile Discovery:  The process by which a Client finds PDS(s)
      capable of providing the environments in Profiles it requires.  This Framework
      defines multiple Profile Types which SIP user agents are to may be used. served by one or more
      PDSs.

   Profile Enrollment:  The local network profile (see Section 6, Section 7.13.3
   and Section 8.1.1) provides the means to get firewall and NAT
   traversal mechanism information process by which a Client makes itself known
      to a PDS.  While enrolling, the device.  Therefore SIP is the
   best solution Client provides identity
      information and requested Profile Type(s) for allowing the user agent to enroll with the profile
   delivery server, which may require traversal of multiple firewalls
   and NATs.  For the same reason the retrieval.
      It also subscribes for notification of profile changes is
   best solved changes.  As a
      result of enrollment, the Client receives profile information
      (contents or content indirection information).  Each Profile Type
      requires a separate enrollment or SUBSCRIBE session.

   Profile Notification:  The process by SIP.  It should be noted that this document is scoped
   to providing profiles for devices which contain the PDS notifies the
      Client that either requested Profile contents are available, or
      the content of one or more SIP user
   agents.  This framework may be applied to non-SIP devices, however
   more general requirements for non-SIP devices are beyond the scope of
   this document.

   The content delivery server may be either in the public network or
   accessible through a private network.  The user agents requiring
   profiles may be behind firewalls and NATs and many protocols, such as
   HTTP, may be used for profile Profiles has changed.  If the
      content retrieval without special
   consideration in is provided indirectly, the firewalls and NATs (e.g. an HTTP client on Client may retrieve the
   UA can typically pull content
      profile from a server outside the NAT/
   firewall.).

5.  Use Cases specified URI upon receipt of the change
      notification.

   Profile Retrieval:  The following use cases are intended to help give an understanding process of
   how retrieving the profile delivery framework can be used.  These use cases are
   not intended to be exhaustive in demonstrating all content for each of
      the
   capabilities Profiles requested by the Client.

   Profile Change Upload:  The process by which a Client or ways other entity
      (for example, configuration management server) pushes a change to
      Profile data to the PDS.

3.3.  Data Model and Profile Types

   As outlined previously, this framework can defines three specific Profile
   Types.  Additional extended profiles may also be applied.

5.1.  Service Provider Use Case Scenario Bootstrapping with Digest
      Authentication defined.  The following describes
   Profile Types specified in this framework are:

   Local Network Profile:  Contains configuration data related to the
      Local Network to which a use case scenario Client is directly connected, as required
      for bootstrapping a new
   user agent, which has had no prior provisioned information, the Client to operate effectively in that network.  It is
      expected to be provided by a PDS in the
   point of being functional with Local Network (or proxied
      in some way).

   Device Profile:  Contains configuration data related to a SIP specific
      Client, required for operation in the Service Provider's system.  In
   this example scenario,
      environment.  It is expected to be provided by the user has purchased a new SIP user agent.
   The user signs up Service
      Provider responsible for configuring the service Client.

   User Profile:  Contains configuration data related to obtain three pieces of
   information: a hostname, a user ID and a password.  These three
   pieces of information may be one-time use, that become invalid after
   the one use.  This scenario assumes that no association or mapping
   between the device and the user's account is created before the
   following steps:

   |Service Provider       |
   |Profile Delivery Server|
   |  ___           _____  |
   | |SIP|         |HTTPS| |
   |_|___|_________|_____|_|
       A               A
       |               |
        \___           |-5A) HTTP GET of device profile
            \          |-6) HTTPS response w/device profile
              \        |                    ______________
                \      |                   | Residential  |
     4) NOTIFY on-\     \                  | Router ____  |
       existing TLS \    \                 |       |DHCP| |
       connetion      \    \               |_______|____|_|
                        \    \                   A    A
                          \    \   1B) SUBSCRIBE-|    |
                            \    \  local network|    |
                              \    \      profile|    |
                                \    \           |    |
                                  \    \         |    |-1A) DHCP
                                    \    \       |    |request
                                      \    \     |    |
                                        \    \ C=======D
   3) SIP/TLS SUBSCRIBE to device profile-\    \  /^\
        7) reSUBSCRIBE to device profile as-\   /     \
           configured in device profile       /  Device \
                                              -----------
                 2) User enters service provider hostname
                5B) User enters HTTP profile userID and password

   1.  The user plugs the device in specific
      User, as required to provide power reflect that User's preferences and network
       connectivity the first time (or installs the software in the case
       of a software user agent).  The device subscribes to the local
       network to get the local network profile.  However as the device
       is plugged into a residential LAN or router, there
      particular services subscribed to.  It is no profile
       delivery server for the local network profile (see Section 8.1.1
       and Section 7.13.3).
   2.  The device prompts the user for the hostname to subscribe expected to for
       the device profile.  The hostname was be provided
      by Service Provider(s) responsible for maintaining the service
       provider and is used as User's
      configuration data.

   To function effectively, the host part Client should obtain all of the SUBSCRIBE
   necessary Profiles.  Since each profile
       URI described in Section 7.13.1.  Note: in may potentially be served by
   a scenario where different source and the
       system operator (e.g. enterprise) Client has control no way of ascertaining that in
   advance, the network, framework requires the
       hostname for Client to discover the SUBSCRIBE can PDS
   sources independently and request the corresponding Profiles from
   each individually.

4.  Use Cases

   This section provides a small - non-comprehensive - set of
   representative use cases to further illustrate how this Framework can
   be discovered (see Section 8.1.2) utilized in SIP deployments.

   For Security Considerations please refer to avoid the need for the Section 9.

4.1.  Client with different Data and SIP Service Providers

   Description: Consider a user to enter the hostname.

   3.  The device creates who obtains data (broadband) and SIP
   Services from two different Service Providers.  For example, a TLS [RFC2246] connection for the user
   obtaining SIP
       SUBSCRIBE request to the services from a SIP Service Provider, via data
   connectivity provided hostname. through a WiFi hotspot or hotel network.

   The device verifies
       the server's certificate.  If the SubjectAltName does not match following assumptions apply:
   o    For the hostname or sake of simplicity, the certificate Client is not valid (as described in
       Section 23 assumed to be pre-
        configured with a) the domain name of [RFC3261]), the device warns SIP Service Provider,
        b) the user and prompts
       whether ability to generate a Client identifier (such as, based
        on MAC address) that can be used to continue.
   4.  The profile delivery server receives the SUBSCRIBE request for the device profile profile,
        and sends b) a NOTIFY with content indirection
       containing the HTTPS URI for the device profile (see
       Section 7.5).
   5.  The device receives the NOTIFY user identity which can be used to request with the device user
        profile
       URI.
   o    The device prompts the user for the user ID Client is pre-configured to request local-network, Client
        and password
       provided by the service provider.  The device does an HTTPS GET user profiles - in that order - to obtain information
        related to retrieve the device profile (see Section 8.4 local-network, itself and Section 7.8).
       The profile delivery server challenges for Digest authentication.
       The device re-sends the HTTPS GET with Digest credentials using the pre-configured user ID and password entered by the user.
   6.
   o    The profile delivery server receives the HTTP GET data provided upon request for are based on data models
        that are comprehenisble by the
       device profile along with Client, i.e. the user ID and password Client
        understands the data models used for the
       specific user.  At this point, creation of the profile delivery server has
       authenticated the user
        data

   The following diagram illustrates this use case and can create an association between a
       specific device identified in highlights the HTTPS URI and
   communications relevant to the user or user
       account (see Section 10.2).  The framework specified in this document.

                    +-----------------+  +----------------------+
    +--------+      |  Data Service   |  | SIP Service Provider |
    | Client |      |     Provider    |  |                      |
    |(SIP UA)|      |                 |  |  SIP     PDS    PDS  |
    +--------+      |  DHCP     PDS   |  | PROXY (Client) (User)|
                    +-----------------+  +----------------------+
         |               |       |           |       |      |
     (A) |<==== DHCP ===>|       |           |       |      |
         |                       |           |       |      |
         |                       |           |       |      |
         |   SUBSCRIBE/NOTIFY    |           |       |      |
     (B) |<=== local-network ===>|           |       |      |
         |        profile delivery server provides
       the
         |
         |   <<Profile Retrieval>>
         |
         |          SUBSCRIBE/NOTIFY         |       |      |
     (C) |<========= device profile which may contain the on-going SUBSCRIBE
       request URIs for the device, ========>|<=====>|      |
         |                                   |       |      |
         |   <<Profile Retrieval>>
         |
         |
         |          SUBSCRIBE/NOTIFY         |              |
     (D) |<========== user and other profiles along with
       credentials for retrieving the profiles.
   7. profile  ========>|<============>|
         |                                   |              |
         |   <<Profile Retrieval>>
         |

   The device receives following is an explanation of the device profile from interactions in the HTTPS response,
       re-SUBSCRIBEs diagram.
   (A)  Upon initialization, the Client obtains IP parameters (IP
        address, DNS) using DHCP (as an example)
   (B)  The Client proceeds to request the device profile URI provided 'local-network' Profile Type.
        The PDS in the
       profile.  The device profile also may contain URIs for local network responds, allowing the
       default user's user and other Client to
        retrieve the local-network profile SUBSCRIBE
   (C)  The Client then proceeds to request URIs for the 'device' Profile Type
        using the pre-configured SIP event package defined Service Provider's domain name.
        This request is received by a SIP Proxy in Section 7. the SIP Service
        Provider's network.  The device uses
       these URIs request is then proxied to retrieve user and other profiles in a similar way
       to the device profile.  After retrieving these profiles the
       device is fully functional in the service provider's SIP service.

5.2.  Service Provider Use Case Scenario Bootstrapping with Device
      Certificate relevant
        PDS within its network.  The following describes another use case scenario where the device
   implementor provides a certificate for the device which authenticates
   the device ID.  In this scenario, the user signs up for the SIP
   service with PDS responds to the service provider request and
        provides profile retrieval information.  The Client retrieves
        the device ID (see
   Section 7.13.1 for more Device Profile (this can contain information such as
        enabling or disabling usage, based on device ID) to the service
   provider prior subscription status)
   (D)  The Client then proceeds to request the following steps, so that the service provider
   has an association or mapping between the device ID and the user
   account ahead of time.  The service provider gives 'User' Profile Type for
        the user a
   hostname pre-configured User.  This message is proxied to be entered on the device.

   1.  Steps 1-3 occur the same as in the prior use case described in
       Section 5.1.
   2.  The device receives or
        different PDS (diagram assumes the NOTIFY request latter) which responds with
        the device profile
       URI. retrieval information.  The device does an HTTPS GET to retrieve Client retrieves the device profile
       (see Section 8.4 and Section 7.8).
   3.  The
        User profile delivery server requests the device certificate in
       the TLS connection used for (this can contain information such as service
        profiles to be retrieved, based on the HTTPS GET. subscription).  The device has
        Client then starts providing services.

4.2.  Clients supporting multiple users from different Service Providers

   Description: Consider a
       certificate single Client (for example, Kiosk at an
   airport) that contains the MAC address used in the device ID. allows for multiple users to obtain services from a
   list of pre-configured SIP Service Providers.

   The device certificate following assumptions apply:
   o    The Client is signed and provided and managed by the implementor
       for the purpose of authenticating the device ID in the initial
       bootstrapping process only.  The profile delivery server
       validates the device ID and returns the device profile using
       HTTPS.
   4.  The device receives the device profile in the HTTPS response.
       The process continues in a similar way SIP Service Provider A. It
        is not pre-configured with any User Identities, but offers an
        interactive User Interface to step 7 in the above use
       case.  The device profile contains a more permanent device
       certificate enter Service Provider and private key or Digest authentication credentials
       which are used for on-going device ID authentication.

6.  Data Model User
        information
   o    SIP Service Provider A conscious separation of device, user and provides the local network profiles is
   made in this document.  This is useful to provide features such as
   hotelling (described above) as well as securing or restricting user
   agent functionality.  For example, by maintaining this separation,
   Alice may walk up to Bob's user agent and direct Bob's user agent to
   get the Alice's profile data.  In doing so the user agent can replace
   the previous user's profile data while still keeping the device's connectivity,
        'local-network' and 'device' profiles for the local network's profile data which may be necessary Client.  The
        Service Provider also provides 'user' profiles for core
   functionality existing
        subscribers
   o    SIP Service Provider B provides SIP services and communication described in this document.  The
   local network has pre-
        existing agreements with SIP Service Provider A. This Service
        Provider also provides 'user' profiles are relevant to a visiting device which gets
   plugged in to a foreign network. for existing subscribers

   The concept of the local network
   providing profile data is useful to provide nomadic capabilities
   (described above) as well as local policy data that may constrain the
   user or device behavior relative to following diagram illustrates the local network.  For example,
   media types use case and codecs may be constrained to reflect the network's
   capabilities.

   The separation of these profiles also enables highlights the separation of the
   management of
   communications relevant to the profiles.  The user profile may be managed by a
   profile delivery server operated by the user's ISP.  The framework specified in this document.

     User User
       A   B        +----------------------+  +----------------------+
    +--------+      | SIP Service Provider |  | SIP Service Provider |
    | Client |      |           A          |  |          B           |
    |(SIP UA)|      |                      |  |                      |
    +--------+      | DHCP    PROXY   PDS  |  |  PROXY        PDS    |
                    +----------------------+  +----------------------+
         |              |        |      |          |           |
     (A) |<====DHCP====>|        |      |          |           |
         |                       |      |          |           |
         |                       |      |          |           |
         |  SUBSCRIBE/NOTIFY     |      |          |           |
     (B) |<local-network profile>|<====>|          |           |
         |
         |   <<Profile Retrieval>>
         |
         |
         |  SUBSCRIBE/NOTIFY     |      |          |           |
     (C) |<== device profile may be delivered from a ==> |<====>|          |           |
         |
         |   <<Profile Retrieval>>
         |
                      .
                      .
                      .
             [[User A attempts services]]

         |     SUBSCRIBE/NOTIFY  |      |          |           |
     (D) |<= user profile delivery server operated by
   the user's employer.  Other profile(s) may be delivered from the
   user's ASP (Application Service Provider).  The local network (A) => |<====>|          |           |
         |                       |      |          |           |
         |
         |   <<Profile Retrieval>>
                              .
                      .
                      .
                      .
             [[User B attempts services]]

         |
         |            SUBSCRIBE/NOTIFY             |           |
     (E) |<=========== user profile
   may delivered by a WLAN (Wireless LAN) hotspot service provider.
   Some interesting services and mobility applications are enabled with
   this separation of profiles.

   A very high level data model (B) ==========>|<=========>|
         |                                         |           |
         |   <<Profile Retrieval>>
         |
   The following is implied here with the separation an explanation of
   these three profile types.  Each profile type instance requires a
   separate subscription to retrieve the profile.  A loose hierarchy
   exists mostly for interactions in the purpose of bootstrapping and discovery or
   formation of diagram.
   (A)  Upon initialization, the profile URIs.  No other meaning Client obtains IP parameters (IP
        address, DNS) using DHCP
   (B)  Once local IP connectivity is implied by this
   hierarchy.  However, the profile format established and data sets to be defined
   outside this document may define additional meaning the SIP stack
        initialized, the Client proceeds to this
   hierarchy.  In request the bootstrapping scenario, 'local-network'
        Profile Type.  It receives a device straight out of response from the box (software or hardware) does not know anything about its user
   or PDS in Service
        Provider A's network (the local network. network).  The one thing that it does know is its instance
   id.  So the hierarchy of the profiles exists as follows.

   The local network profile is subscribed to and retrieved based upon a
   URI formed from Client retrieves
        the local network domain.  The local network profile
   is subscribed to first as it (this may contain useful information on how to
   communicate to the Internet or primary network from the local network
   (e.g.  HTTP proxy, SIP such as
        firewall or NAT traversal information). port restrictions, available bandwidth etc)
   (C)  The
   device instance id is used Client then proceeds to form the user id part of request the URI for
   subscribing to 'device' Profile Type.
        It receives a response containing the device and local network profiles.  The device profile may contain a default user AOR (Address of Record) for that
   device.  The default user AOR may then be used to retrieve retrieval from the user
   profile.  Applications to be used on
        PDS in Service Provider A's network.  The Client retrieves the device may be defined
        data provided in the
   device and user profiles.

7. Client Profile Change Event Notification Package

   This section defines a new SIP event package [RFC3265].  The purpose
   of this event package is to send to subscribers notification of
   content changes to the profile(s) of interest and to (this may provide data
        regarding Users such as the
   location list of SIP Service Providers the profile(s) via content indirection [I-D.ietf-sip-
   content-indirect-mech] or directly in
        Client can communicate with).  The Client initializes the body of User
        interface for services.
   (D)  User A with a pre-existing subscription with Service Provider A
        attempts communication via the NOTIFY.
   Frequently User Interface.  This results in
        a prompt - and responses - for identification and
        authentication.  The Client uses the profiles delivered provided information and
        communicates with Service Provider A. Once authenticated and
        authorized, it proceeds to request the user agent are much larger
   (e.g. several KB or even several MB) than the MTU of 'User' Profile Type.  The
        PDS responds with the network.
   These larger profiles will cause larger than normal SIP messages and
   consequently higher impact on profile retrieval information.  The Client
        provides services to User A.
   (E)  At a different point in time, User B with a pre-existing
        subscription with Service Provider B attempts communication via
        the SIP servers User Interface.  This results in a prompt - and infrastructure.  To
   avoid responses -
        for identification and authentication.  Since Service Provider B
        is in the higher impact list of approved Service Provider, the Client uses the
        provided information and load on communicates with Service Provider B.
        Once authenticated and authorized, it proceeds to request the SIP infrastructure, content
   indirection SHOULD be used if
        'User' Profile Type.  The PDS responds with the profile
        retrieval information.  The Client provides services to User B.

   It is large enough to cause
   packet fragmentation over be noted that this Client may allow for exclusive or
   simultaneous access to both Users.

5.  Profile Delivery Framework

   This section details the transport protocol. framework requirements.  The presence of
   the MIME type for content indirection [I-D.ietf-sip-content-indirect-
   mech] Profile Life
   Cycle (introduced in the Accept header indicates Section 3), is examined in further detail, with
   requirements that apply to the user agent supports
   content indirection Client and that the profile delivery server SHOULD use
   content indirection.  Similarly PDS.  Unless explicitly
   enhanced or indicated by an implementing specification, the content type for Client
   and the differential
   notification of profile changes [I-D.ietf-simple-xcap-diff] may be
   used in PDS MUST follow the Accept header to express support Profile Life Cycle requirements stated in
   this section for receiving profile
   change deltas.

   The MIME types or formats all supported Profile Types.

   A high-level representation of profiles to be delivered via this the framework are to be defined is shown in the documents that define
   following state diagram.  Each of the profile
   contents.  These profile MIME types specified Profile Types is
   retrieved individually, in the Accept header
   along with the profile types specified in the Event header parameter
   "profile-type" SHOULD be used to specify which profiles get delivered
   either directly or indirectly in order (see below), until all
   needed Profiles have been received.  For each retrieved Profile, the NOTIFY requests.  As this event
   package does not specify the mandatory content type, this package is
   abstract.  The profile definition documents will specify the
   mandatory content type to make a concrete event package.

7.1.  Event Package Name
   Client then awaits any Change Notifications

                          ---------------
                         /    Client     \
                         \ Initialization/
                          ---------------
                                |
                                | Completes IP initialization;
                                | Initializes SIP stack
                                |
                                V
                          --------------  YES    ---------------
               ________\ / All profiles?\_____\ | Await Change  |
              |        / \ retrieved?   /     / | Notifications |
              |           --------------         ---------------
              |                 |
              |                 | NO; attempt
              |                 | Profile Request
              |                 | in specified order
              |                 |
              |                 V
              |            ------------
               ___________/  Profile   \
                          \ Life Cycle /
                           ------------

                          Framework state diagram

   The name of this package Profile Life Cycle, within each Profile Type, is "ua-profile".  This value appears in the
   Event header field present in SUBSCRIBE and NOTIFY requests for this
   package illustrated
   further as defined in [RFC3265].

7.2.  Event Package Parameters

   This package defines the following new parameters state diagram below.

                           -------------   All methods   --------
                ________\ /   Profile   \ ............\ / Error  \
               |        / \  Discovery  /   exhausted / \Handling/
               |           -------------                 --------
               |                 |
               |                 |
               |   Try           | Send request
               | alternate       | for the event
   header: "profile-type", "vendor", "model", "version", "effective-by",
   and "network-user". Profile
               | method(s)       | Enrollment
               |                 |
               |                 |
               |                 V
               | FAILURE   ------------
               |__________/   Profile   \
               ^          \  Enrollment /
               ^           ------------
               |                 |
               | FAILURE         |
               |                 |
               |                 |
               |                 V
               |  Timeout  -------------
                _________ /   Profile   \
                          \ Notification/
                           -------------
                                 |
                                 |
                                 |SUCCESS
                                 |
                                 V
                              -------    Failure    ---------
                            / Profile \ _________\ /  Error  \
                            \Retrieval/          / \ Handling/
                              -------               ---------
                                 .
                                 .     If allowed
                                 . by Profile Retrieval
            ------               .     Framework
           (Client)  --          V
            ------      \  -------------
                          /Profile Change\
                          \    Upload    /
          ----------    /  -------------
         {Authorized}--
         {  Entity  }
          ----------
   The "effective-by" parameter Profile Life Cycle is initiated when the Client starts the
   'Profile Discovery' process for use in
   NOTIFY requests only.  The "effective-by" parameter is ignored if it
   appears in a SUBSCRIBE request.  The other parameters are particular Profile Type.  Discovery
   leads to transmission of a request for use 'Profile Enrollment'.
   Successful enrollment leads to 'Profile Notification'.  Successful
   initial notification results in
   the SUBSCRIBE request and are ignored if they appear in NOTIFY
   requests.

   The "profile-type" parameter is used to indicate the token name of
   the profile type the user agent wishes to obtain 'Profile Retrieval' (either as data
   within the notification or URIs for using content indirection).  'Profile
   Change Upload' can be initiated by any authorized entity (examples
   include Clients and administrative interfaces).

   'Profile Discovery' and 'Profile Enrollment' are closely coupled.
   Failure to be notified of subsequent changes.  Using a token enroll (for example, no response is received for the
   SUBSCRIBE) results in this
   parameter allows alternate 'Profile Discovery' methods until
   success is achieved or all the URI semantics for retrieving methods are exhausted (resulting in
   error handling).  Simiarly, the profiles initial 'Profile Notification' is
   closely coupled to be
   opaque enrollment.  Failure to receive the subscribing user agent.  All it needs to know initial
   notification also results in alternate discovery methods.

   'Profile Retrieval' is accomplished using the
   token value for this parameter.  This document defines three logical
   types of profiles and their token names.  The contents or format of
   the profiles is outside the scope of this document.

   The three types of profiles defined here are "device", "user" and
   "local-network".  Specifying "device" type profile(s) indicates the
   desire for Profile
   Notification.  This can either contain the profile data (URI when or a content
   indirection method to achieve it.

   The Profile Life Cycle is used)
   and change notification of the contents of same for all the profile Profile Types, but
   there are different requirements in each step based on the Profile
   Types.  This framework defines three Profile Types and an order that is
   specific to
   MUST be followed by the device Client in requesting them (when it retrieves
   two or user agent.  Specifying "user" type profile
   indicates more of the desire for defined Profile Types), as follows:

   o  local-network
   o  device
   o  user

   The sub-sections that follow specify the Profile Life Cycle details,
   with specific requirements based on each Profile Type.

5.1.  Profile Discovery

   The first step to obtaining a profile data (URI when content
   indirection is used) and change notification of the PDS Discovery.  This is
   accomplished by creating a profile content subscription using the Event
   Package described in Section 6, and preparing for Profile Enrollment.

   Each Profile Type requires its own subscription and based on the user.  Specifying "local-network" type profile indicates
   entity requesting it, presents certain unique requirements (for
   example, the
   desire Client identifier is provided for profile data (URI when content indirection the Device Profile
   Type where as the User identifier is used)
   specific to provided for the local network.  The device, user or local network User Profile
   Type).  Further, the Profile Types are aimed at different PDSs and
   hence are identified differently (for example, the local-network is
   identified in by the URI of local domain name where as the SUBSCRIBE request.  A separate SUBSCRIBE
   dialog Service Provider is used for each profile type.  The profile type associated
   with
   identified based on the dialog Service Provider's domain name).  Some of
   this information can then be used obtained in multiple ways (such as local
   domain information that can be configured statically or dynamically)
   and the Client may have to infer which profile type changed try different information sources to
   obtain the required information (for example, dynamic configuration
   can override statically configured information).  Based on these
   considerations, the framework defines different rules for obtaining
   and presenting the information for each Profile Type.  Additionally,
   when more than one information source is contained possible for the
   information, it is presented as well.  This is highlighted in the NOTIFY or content indirection URI.  The
   Accept header of
   following sub-sections.

5.1.1.  SIP SUBSCRIBE for the Local-Network Profile Type

   Before attempting to create a SIP SUBSCRIBE request requesting the Local-
   Network Profile, the Client MUST include have established local network
   connectivity.  It MUST also have knowledge of the MIME types
   for all profile content types for which local network
   domain either via static configuration or dynamic discovery (using
   DHCP [RFC2131], option 15 [RFC2132]).  The following requirements
   apply:
   o  the subscribing user agent
   wishes to retrieve profiles or receive change notifications.  In part of the
   following ABNF, EQUAL and token are defined in [RFC3261].  Additional
   profile types may Request URI MUST NOT be defined in subsequent documents.

   Profile-type   = "profile-type" EQUAL profile-value
   profile-value  = profile-types / token
   profile-types  = "device" / "user" / "local-network" provided.  The "device", "user" or "local-network" token in host
      and port part of the profile-type
      parameter may represent a class or Request URI MUST be set of profile properties.  As
      standards are defined for specific profile contents related to the
      user, device or local network, it may be desirable to define
      additional tokens for network
      domain
   o  the profile-type parameter.  Also additional
      content types may be defined along with user part of the profile formats that
      can "From" field MUST be used in the Accept header of Identifier that the SUBSCRIBE
      Client will use to filter or
      indicate what data sets of request the profile are desired.

   The rationale for 'device' Profile Type
   o  the separation of user, device host and local network
   type profiles is provided in Section 4.  It should be noted that any port part of the types may result in zero or more profiles or URIs being
   provided in the NOTIFY request.  As discussed, a default user may "From" field MUST be
   assigned set to the
      local network domain
   o  a device.  The default user's user AOR, if defined in the
   device profile, may in turn be used as the URI to SUBSCRIBE known to the
   "user" profile type.

   The data Client MUST be provided in the three types of profiles may overlap.  As an
   example,
      "network-user" event header parameter, unless privacy requirements
      prohibit its use (this is useful if the codecs that a user prefers to use, the codecs that has privileges in the
   device supports (and
      local network beyond those of the enterprise or device owner wishes to use), default user)

   For example: If the codecs that Client requested and received the local network can support (and the network
   operator wishes domain
   name via DHCP to allow) all may overlap in how they are specified
   in be: airport.example.net, then the three corresponding profiles.  This policy for merging Local-Network
   Profile SUBSCRIBE Request URI would look like:

   sip:airport.example.net

   The Event header would look like the
   constraints across following if the multiple profile types can only unambiguously
   be defined in Client decided
   to provide sip:alice@example.com as the context of user's AOR.  (Alice may have
   a prior arrangement with the profile syntax and semantics.  This
   is out of scope for this document and will be defined in local network operator giving her
   special privileges.):

   Event: ua-profile;profile-type=local-network;
          network-user="sip:alice@example.com"
   The Local-Network Profile SUBSCRIBE Request URI does not have a subsequent
   document(s) user
   part so that define the data profile format.

   The "vendor", "model" and "version" parameter values are tokens
   specified by URI is distinct between the implementer of "local" and "device"
   URIs when the user agent.  These parameters
   MUST be provided in domain is the SUBSCRIBE request same for all profile types.  The
   implementer SHOULD use their DNS domain name (e.g. example.com) as the value two.  This provides a means
   of the "vendor" parameter so that it is known to be unique.
   These parameters are useful routing to the profile delivery server to affect appropriate PDS in domains where they are distinct
   servers.  The From field uses the profiles provided.  In some scenarios it is desirable to provide
   different profiles based upon these parameters.  For example, feature
   property X device ID in a profile may work differently on two versions of the
   same user agent.  This gives the profile delivery server the ability
   to compensate for or take advantage of the differences.  In the
   following ABNF, EQUAL and quoted-string are defined in [RFC3261].

   Vendor       =  "vendor" EQUAL quoted-string
   Model        =  "model" EQUAL quoted-string
   Version      =  "version" EQUAL quoted-string

   The "network-user" parameter MUST be set when subscribing for device
   profiles if the user's AOR is known.  The "network-user" parameter
   MUST be set when subscribing for "local-network" profiles if it is
   known, unless the device is provisioned to preserve privacy within part of the
   local network.
      When the profile-type is "device", the SUBSCRIBE network Request URI addresses the so that every device which must contain in the device identity (see Section 7.13).
      When network has a
   unique and constant From field.  Even though every client may get the profile-type is "local-network",
   same (or similar) Local-Network Profile, the SUBSCRIBE URI
      addresses uniqueness of the From
   field provides an important capability.  Having unique From fields
   allows the management of the local network profile resource id which must contain
      the localdomain with no to track user part (see Section 7.13).  The URIs
      will not contain agents
   present in the user profile identifier. network and consequently also manage resources such as
   bandwidth and port allocation.

   For this reason example: If the
      "network-user" parameter is needed Client requested and received the local domain
   name via DHCP to indicate be: airport.example.net and the user profile
      resource identifier associated with device ID is: MAC:
   00DF1E004CD0, the "device" or URI.
   The From field would contain:

   sip:MAC%3a00DF1E004CD0@airport.example.net

5.1.2.  SIP SUBSCRIBE server SHOULD authenticate for the subscriber Device Profile Type

   The Device Profile Type allows the Service Provider managing a Client
   to verify provide Client-specific configuration information.  To enable
   this, the
   resource identifier in Request URI needs to identify the "network-user" parameter if Client and the profile
   provided PDS domain
   within which it is specific to recognizable.  Accordingly, this Framework
   presents the user (e.g. granting policies or
   privileges beyond those of a default user).  If following requirements for the value formation of a
   Subscription Request URI to request the
   "profile-type" parameter is not "device" or "local-network", the
   "network-user" parameter has no defined meaning and is ignored.  If Profile Type

   o  the "network-user" parameter is provided in user portion of the SUBSCRIBE request, it Request URI MUST be present in the NOTIFY request as well.  In the following
   ABNF, EQUAL, LDQUOT, RDQUOT and addr-spec are defined in [RFC3261].

   Network-User =  "network-user" EQUAL LDQUOT addr-spec RDQUOT

      The entity that is subscribing and getting set to a unique Client
      Identifier
   o  the "device" host and
      "local-network" profiles is the device.  For this reason port portion of the From
      field should indicate Request URI MUST be set to the device's identity.  These profiles types
      contain device specific information
      PDS domain

   The following sub-sections explain identification of - and it is the device's
      identity that gets authenticated for the "device" profile.
      Depending upon
   requirements related to - the local administration policy Client Identifier and segmentation of
      services, the device identity and user PDS domain
   discovery.

5.1.2.1.  Client Identifier

   The Client profile identity
      association may not could be known specific to each Client in a SIP
   deployment (for example, vendor/model) or shared across Client types
   (for example, based on services and service tiers).  Further, the
   same Client might be provided different configuration profiles based
   on deployment models.  Client Identifiers play a significant role in
   ensuring delivery server
      ahead of time.  Since the From field and SUBSCRIBE request URI
      indicate the "device" correct profile resource identifier, the "network-
      user" parameter is needed and hence need to indicate the additional resource
      identifier for the user associated with this device.
   When the profile-type is "device", the user agent SHOULD set the
   "network-user" parameter be unique
   within a PDS domain to support the "user" profile resource identifier if
   it is known. various deployment models.

   This is an indication to Framework requires that Client Identifiers MUST be unique and
   persistent over the profile delivery server to
   set lifetime of a Client.  Client Identifier
   representations auto-generated by Clients SHOULD be based on MAC
   address or change UUID ([RFC4122]) based representations.  A Client may use
   alternate Client identifiers (for example, SIP URIs) obtained via
   pre-configuration or dynamic configuration (for example, Client
   profile).

   If a MAC address is used, the following requirements apply:
   o  the association Client identifier MUST be formatted as the characters "MAC:"
      followed by a twelve digit hexadecimal upper case representation
      of the default user with MAC address to form a proper URN ([RFC2141]).  The MAC
      address representation MUST NOT include visual separators such as
      colons and whitespaces.  The representation is denoted using the device
   indicated
      following ABNF syntax

         mac-ident = MAC ":" 12UHEX
         MAC       = %x4d.41.43      ; MAC in caps
         UHEX      = DIGIT / %x41-46 ; uppercase A-F

   o  the SUBSCRIBE URI.  If MAC address MUST only be used to represent a single Client.
      It MUST NOT be used if more than one Client can potentially use
      the profile delivery server
   implements and allows this policy of setting same MAC Address (for example, multiple software Clients on a
      single platform).  In such cases, the default user with UUID representation SHOULD
      be used

   If a
   device, UUID is used, the user agent can utilize this mechanism following requirements MUST apply:
   o  the same approach to allow defining a user to
   login and make the user agent and user association permanent.

   If Instance ID as
      [RFC4122] MUST be used
   o  when the profile-type is "local-network" and users's AOR URN is known, used as the user agent SHOULD assign part of the "network-user" parameter to URI, it MUST be the
   user's AOR.  If URL
      escaped
         The colon (":") is not a legal character (without being
         escaped) in the user has special privileges beyond that part of an addr-spec ([RFC4122]).
         For example the instance ID:
         urn:uuid:f81d4fae-7ced-11d0-a765-00a0c91e6bf6@example.com
         would be escaped to look as follows in a
   default user URI:
         sip:urn%3auuid%3af81d4fae-7ced-11d0-a765-00a0c91e6bf6@
         example.com
      The ABNF for the UUID representation is provided in [RFC4122]

5.1.2.2.  PDS Domain Discovery

   A Client needs to identify the local network, PDS domain to form the "network-user" parameter
   identifies host and port
   part of the user Request URI.  Ideally, this information should be
   obtained via a single method.  However, support for various
   deployment models implies multiple Client environments (for example,
   residential routers, enterprise LANs, WLAN hotspots, dialup modem
   etc) and presents hurdles to the local network.

   The "effective-by" parameter specifying a single method (for example,
   if a Client is always in the Event header of SIP Service Provider's network one could
   use DHCP).  To accommodate multiple deployment scenarios, the NOTIFY
   request specifies
   framework specified in this document presents multiple approaches.

   Clients MUST follow the maximum number of seconds before procedures specified below in the order
   presented, unless exceptions are made by Client manufacturers or
   Service Providers who may provide an option for the user agent
   must attempt to make choose
   the new profile effective. order (to suit specific deployment models, for example).

   1. Service Provider pre-configuration

      The "effective-by"
   parameter Client MAY be provided in the NOTIFY request for any of the
   profile types.  A value of 0 (zero) indicates pre-configured with information that the subscribing
   user agent must attempt can be
      utilized to make the profiles effective immediately
   (despite possible service interruptions).  This gives identify the profile
   delivery server host and port of the power to control Request URI.  The
      information can be provided - as examples - when the profile Client is effective.
   This may be important to resolve an emergency problem
      manufactured, by using Service Provider entities (flash card, SIM
      card) or disable via a
   user agent immediately.  The "effective-by" parameter is ignored in
   all messages other than the NOTIFY request.  In Service Provider specific method (for example,
      information or methods that lead to self subscription).  If the following ABNF,
   EQUAL and DIGIT are defined in [RFC3261].

   Effective-By =  "effective-by" EQUAL 1*DIGIT

   The following are example Event headers which may occur in
   SUBSCRIBE requests.  These examples are not intended
      Client is specified to be
   complete SUBSCRIBE requests.

   Event: ua-profile;profile-type=device;
               vendor="vendor.example.com";model="Z100";version="1.2.3"

   Event: ua-profile;profile-type="user";
    vendor="premier.example.com";model="trs8000";version="5.5" utilize this approach, it MUST attempt to
      do so before trying other methods.  The following are example Event headers which may occur in
   NOTIFY requests.  These example headers details of how this is
      accomplished are beyond the scope of this document.

   2. IP Configuration

      If pre-configuration is not intended to an option, or not available, IP
      configuration MUST be complete SUBSCRIBE requests.

   Event: ua-profile;effective-by=0

   Event: ua-profile;effective-by=3600 utilized to try and obtain information that
      can help with identification of the host and port for the Request
      URI.  The framework defines the following table shows methods within this
      procedure to accomplish this.  Clients MUST follow the use of Event header parameters methods
      defined, in
   SUBSCRIBE requests for the three profile types:

   profile-type || device | user | local-network
   =============================================
   vendor       ||   m    |  m   |        m
   model        ||   m    |  m   |        m
   version      ||   m    |  m   |        m
   network-user ||   s    |      |        s
   effective-by ||        |      |

   m - mandatory
   s - SHOULD order specified, i.e. if the first option cannot
      be provided
   o - optional
   Non-specified means accomplished or results in a failure, then next method is
      tried.  Failure of a specific method is indicated when the Client
      cannot successfully complete Profile Enrollment.

      2a. DHCP option 120:

         Clients that support DHCP MUST attempt to obtain the parameter has no meaning host and
   should be ignored.

   The following table shows the use
         port of Event header parameters in
   NOTIFY requests for the three profile types:

   profile-type || device | user | local-network
   =============================================
   vendor       ||        |      |
   model        ||        |      |
   version      ||        |      |
   network-user ||   s    |      |        s
   effective-by ||   o    |  o   |        o

7.3.  SUBSCRIBE Bodies

   This package defines no outbound proxy during the DHCP process, using the
         SIP DHCP option 120 [RFC3361] and use these as the host and
         port part of the SUBSCRIBE request body.  A body
   contained in URI.

         For example, a SUBSCRIBE request for this event package is ignored.
   Future documents may specify MAC based Client Identifier with a filter-like mechanism using etags DHCP option
         120 indicating example.com, the Request URI would be
         constructed as sip:MAC%3aABC123EFD456@example.com
      2b. Local IP Network Domain:

         - Clients that support DHCP MUST attempt to
   minimize obtain the delivery or notification local IP
         network domain during the DHCP process, using DHCP option 15
         and use these as the host and port part of profiles where the user
   agent already has a current version.

7.4.  Subscription Duration

   As request URI
         using the presence (or lack of) technique specificed in [RFC3263]

         +  For example, a device or user agent is not very time
   critical to MAC based Client Identifier with a DHCP
            option 15 indicating local.example.com, the functionality of Request URI
            would be constructed as
            sip:MAC%3aABC123EFD456@local.example.com

         - If the profile delivery server, it local IP network domain is
   recommended that available (previous
         method), but the default subscription duration be 86400 seconds
   (one day).  A one-time fetch usage of a profile can be accomplished by
   setting the Expires parameter to 0 as defined in [RFC3265] resulting local IP Network domain results
         in a single NOTIFY with no change notification.

7.5.  NOTIFY Bodies

   The size of profile content is likely to be hundreds to several
   thousands of bytes in size.  For this reason, if the Accept header of failure, the SUBSCRIBE included Client MUST use the MIME type message/external-body, local IP network domain,
         prefixing it using the label "sipuaconfig."

         +  For example, a MAC based Client Identifier with a DHCP
            option 15 indicating support for content indirection, local.example.com, the profile delivery
   server SHOULD use content indirection [I-D.ietf-sip-content-indirect-
   mech] Request URI
            would be constructed as
            sip:MAC%3aABC123EFD456@sipuaconfig.local.example.com

   3. Manual

      If pre-configuration and IP Configuration are not options or
      result in failures, the NOTIFY body Client SHOULD provide a means for providing the profiles.

   When delivering profiles via content indirection, user
      to present information that may help with the profile
   delivery server MUST retrieval process.
      Exceptions to this requirement MAY include the Content-ID MIME header described in
   [I-D.ietf-sip-content-indirect-mech] Clients with no user
      interface appropriate for each profile URI. such entry.

      This is
   to avoid unnecessary download of framework provides the profiles.  Some user agents are
   not able to make a profile effective without rebooting or restarting.
   Rebooting is something to following alternatives which can be avoided on a
      considered individually or together, in any order.

      Service Provider PDS information:  The user agent performing
   services such as telephony.  By examining the Content-ID, SHOULD be allowed to
         present the user
   agent host and port information which can recognize if it already has help with the indirected content, thus
   avoiding unnecessary interruption
         creation of service.  The Content-Type MUST
   be specified for each URI.  For minimal interoperability, the profile
   delivery server MUST support the "http:" and "https:" URI schemes for
   content indirection.  Other Subscription URI schemes to locate a PDS capable of
         providing the profile.

      Service Provider Configuration Server information  The user MAY also be provided in the
   content indirection.  However
         allowed to present information pertaining to a configuration
         server that provides the security considerations are define
   for content indirection Device Profile, not using HTTP and HTTPS.  Other protocols MAY be
   supported for content indirection, but are out of scope of this
   document.

      Initially user agent implementers may use a proprietary content
      type PDS as
         defined in this framework.  This framework specifies one such
         possible process in Section 5.6.1.

5.1.3.  SIP SUBSCRIBE for the profiles retrieved from User Profile Type

   The User Profile allows the URI(s). responsible SIP Service Provider to
   provide user-specific configuration.  This is based on the User's
   Identity that is usually known in the network (for example,
   associated with a good
      first step towards easing subscription).  Similar to the management of user agents.  Standard
      profile contents, content type and formats will need profiles provided to be defined
      for true interoperability of profile delivery.  The specification
      of
   Clients, the content is out of the scope and propagation of this document.

   The URI scheme [RFC2396] used in content indirection User Profiles may be dictated
   by partake
   differently, based on deployment scenarios (for example, users
   belonging to the profile content that is required.  It is expected that FTP
   [RFC0959], HTTP [RFC2616], HTTPS [RFC2818], LDAP [RFC3377], XCAP
   [I-D.ietf-simple-xcap] and other URI schemes could same subscription might - or might not - be used by this
   package and framework if the subscribing user agent and profile
   delivery server both support provided
   the same scheme.  The negotiation of the
   URI scheme profile).  However, each User is described uniquely identified in the following sections.

7.6.  Notifier processing of SUBSCRIBE requests

   The general rules for processing SUBSCRIBE requests [RFC3265] apply
   to a
   SIP Service Provider's network using an Address Of Record (AOR).
   Clients implementing this package.  If content indirection is used for delivering the
   profiles, framework MUST use the notifier does not need User's AOR to authenticate
   populate the subscription
   as Request URI.

   A Client MAY obtain the profile content is not transported in User's AOR using various methods such as pre-
   configuration, via the SUBSCRIBE Device Profile or NOTIFY
   transaction messages.  With content indirection, only dynamically via a User
   Interface.

5.1.4.  Caching of SIP Subscription URIs

   Creation of Subscription URIs are
   transported in the NOTIFY request which may be secured using the
   techniques in Section 10.  If content indirection is not used, vital for successful Profile
   Enrollment, required for Profile Notification and ultimately Profile
   Retrieval.  Further - unlike the
   subscribe server SHOULD reject SUBSCRIBE requests from connections
   that User Profile - Local-Network and
   Device Profiles are not over TLS expected to be requested based on discovered
   information (for example, domain name discovered via DHCP).  These
   Profile Types have different goals and SHOULD challenge hence, caching of the SUBSCRIBE request with
   SIP Digest authentication.
   Subscription URI should be carefully considered.

   The subscriber MUST support Local-Network Profile Type is aimed at obtaining information from
   the "http:"
   or "https:" URI scheme for content indirection.  If local network.  The local network can change across Client
   initializations (for example, User moves the subscriber
   wishes Client from a home
   network to use a URI scheme other than "http:", the subscriber must
   use workplace LAN).  Thus, the "schemes" Contact header field parameter to indicate Client SHOULD NOT remember
   local-network profile subscription URIs across initializations.  The
   Client SHOULD re-create the Subscription URI
   scheme as defined in [I-D.ietf-sip-content-indirect-mech].  For
   example the subscriber every time it moves to a
   new network or gets re-initialized.  Exceptions may request that content indirection use be cases where
   the
   "ldaps:" URI scheme by including "ldaps" in Client can unambiguously determine changes to the "scheme" Contact
   header parameter of local network.

   The Device Profile Type is aimed at obtaining information from the SUBSCRIBE request.  If
   SIP Service Provider managing the subscriber Client.  Once established, the
   Service Provider does not specify the URI scheme, change often (an example of an exception
   would be the notifier may use either "http:" or
   "https:".

      The profile generation behavior re-use of Clients across Service Providers).  However,
   if the profile delivery server discovery process is
      left to the implementer.  The profile delivery server may be as
      simple as a SIP SUBSCRIBE UAS and NOTIFY UAC front end to a simple
      HTTP server delivering static files that are hand edited.  At the
      other extreme used, the profile delivery server Client can only be part sure of a
      configuration management system that integrates with a corporate
      directory and IT system or carrier operations support systems,
      where
   having reached the profiles are automatically generated.  The design of
      this framework intentionally provides Service Provider upon successful Profile
   Enrollment and Profile Notification.  Thus, the flexibility of
      implementation from simple/cheap to complex/expensive.

   The "profile-type" parameter can be thought of as a filter to
   indicate which profile(s) are to be provided.  If the profile type
   indicated in Client SHOULD cache
   the "profile-type" Event header parameter is not
   provisioned or provided to any users in Subscription URI for the domain, Device Profile.  When cached, the profile
   delivery server Client
   should use the Notifier SHOULD return cached Subscription URI upon a 404 responce to the
   SUBSCRIBE request.

   If reset.  Exceptions
   include cases where the specific Client identifier has changed (for example,
   new network card with a new MAC address), Service Provider
   information has changed (for example, user initiates change) or device is not known to the
   Client cannot obtain its profile delivery
   server, using the implementer MAY accept Subscription URI.

      Clients SHOULD NOT cache the subscription or reject it.  It Subscription URI for the Device
      Profile Type until successful Profile Notification.  The reason
      for this is that a policy decision whether PDS may send 202 responses to maintain the subscription dialog for
   an unprovisioned user SUBSCRIBE
      requests and NOTIFY responses to unknown Clients (see Section 6.6)
      with no profile data or device.  It URIs.  Thus, successful Profile
      Notification is recommended the only sure way to know that the
   implementer accept Subscription
      URI is valid.

5.2.  Profile Enrollment

   Clients implementing the subscription.  It framework specified in this document are
   required to perform Profile Enrollment prior to Profile Retrieval
   (the only exception is useful noted in Section 5.6.1).  Enrollment for the a
   specific profile
   delivery server to maintain happens once the subscription for unprovisioned users
   or devices specific Subscription URI is formed
   and is accomplished using the Event Package specified.

   Thus, a Client requesting a Profile Type specified in this document -
   and is successful in forming a Subscription URI - MUST enroll using
   the event package defined, and as an administrator may add specified, in this framework (see
   Section 6) .  The following requirements apply:

   o  the user or device Client MUST cater to the
   system after Event Package requirements specified
      in Section 6.2 (for example, indicate the initial subscription, defining Profile Type being
      requested in the profile contents.
   This allows profile-type parameter)
   o  the profile delivery server Client MUST use the Subscription URI pertaining to immediately send the Profile
      Type being requested, as specified in Section 5.1

   The SIP infrastructure receiving such requests is expected to relay
   and process profile enrollment requests.  When a NOTIFY Profile Enrollment
   request with the is received by a PDS, it SHOULD accept and respond to any
   profile URIs.  If requests.  Exceptions are when Service Provider policy
   prevents such a response (for example, requesting entity is unknown).

   Successful Profile Enrollment involves the profile delivery server does
   not accept following
   o  Acceptance of the subscription from SUBSCRIBE request by a PDS (indicated via a 200
      response)
   o  Receipt of an unknown user or device, the
   administer or user must manually provoke the user agent to re-
   subscribe.  This may be difficult if initial Profile Notification within the user agent and administrator
   are at different locations. timeouts as
      specified in [RFC3265]
   A user agent can provide hotelling by collecting a user's AOR Client SHOULD follow suitable BackOff and Retry mechanisms if a
   successful Profile Enrollment does not happen within the
   credentials needed expected
   period.

5.3.  Profile Notification

   Successful Profile Enrollment leads to SUBSCRIBE Profile Notification.  This
   serves two purposes a) initial profile content following successful
   Profile Enrollment and retrieve b) notification to the user's profiles.
   Hotelling functionality is achieved by subscribing Client of modifications
   to profile content.  Failure to receive the user's AOR
   and specifying initial NOTIFY following
   a successful enrollment MUST be treated the "user" profile type.  This same mechanism can also
   be used to secure as a user agent, requiring failed
   enrollment.  Whenever a non-mobile user profile is changed, the PDS MUST NOTIFY all
   Clients currently subscribed to login the changed profile.

   For NOTIFY content please refer to enable functionality beyond Section 6.5.

5.4.  Profile Retrieval

   Upon successful Profile Enrollment and Profile Notification, the default user's restricted
   functionality.

   When
   Client can retrieve the Event header "profile-type" is "device" and the user agent
   has provided the user's AOR in the "network-user" parameter, documents pertaining to the requested profile delivery server MAY set
   directly or change the default user associated
   with via the device indicated URI(s) provided in the SUBSCRIBE URI.  This is an
   implementation or policy decision. NOTIFY request as
   specified in Section 6.5.

   The profile delivery server
   SHOULD authenticate the user for following requirements hold good:

   o  the SUBSCRIBE request before
   changing PDS SHOULD secure the default user associated with content of the device.

7.7.  Notifier generation profiles using one of NOTIFY requests

   As the
      techniques described in [RFC3265], Section 9
   o  the profile delivery server Client MUST always send a
   NOTIFY request upon accepting a subscription.  If the device or user
   is unknown to the profile delivery server and it chooses to accept
   the subscription, make the implementer has two choices.  A NOTIFY MAY be
   sent with no body or content indirection containing new profiles effective within the profile
   URI(s).  Alternatively, a NOTIFY MAY be sent with a body or
      specified timeframe, as described in Section 6.2
   o  if content indirection containing URI(s) pointing to a default data set.  The
   data sets provided may allow for only limited functionality of is used, the
   user agent (e.g. a telephony user agent Client SHOULD verify that only permits calls to
   the help desk and emergency services).  This is an implementation and
   business policy decision for it
      has the latest profile delivery server.

   If content using the URI "hash" parameter defined
      in [RFC4483]
   o  the SUBSCRIBE request is a known identity and is
   provisioned with the requested profile type Client SHOULD cache (i.e. as specified in store persistently) the
   profile-type parameter contents of the Event header), the profile delivery
   server SHOULD send
      retrieved profiles, until overridden by subsequent Profile
      Notifications (this avoids situations where a NOTIFY with profile data or content indirection
   (if PDS is unavailable,
      leaving the content indirection mime type was included in the Accept
   header) containing Client without required configuration)

5.5.  Profile Change Upload

   Configuration Profiles can change over time.  This can be initiated
   by various entities (for example, via the URI Client, back-office
   components, end-user web interfaces into configuration servers, etc)
   and for the profile.  To protect the integrity
   of the profile data various reasons (such as, change in user preferences,
   modifications to services, enterprise-imposed common features or indirect content profile data URIs, the
   notifier SHOULD send
   restrictions).  This framework allows for such changes to be
   communicated to the NOTIFY request on PDS, using the same TLS connection term Profile Change Upload.

   Any changes to a Profile as
   the SUBSCRIBE request came a result of Profile Change Upload MUST
   result in on a Profile Notification to all enrolled clients for that
   Profile, if TLS was used.

   The profile delivery server may specify when the new profiles must be
   made effective by the user agent.  The profile delivery server MAY
   specify any.

   Definition of specific mechanisms for Profile Change Upload are out
   of scope of this document.

5.6.  Additional Considerations

   This section provides a maximum time in seconds (zero or more) in special case for retrieval of the
   "effective-by" event header parameter.  The user agent uses Device
   Profile and highlights considerations and requirements on external
   entities such as Profile Data Frameworks.

5.6.1.  Manual retrieval of the
   "effective-by" parameter to determine when to make Device Profile

   At a minimum, a Client requires the new profiles
   effective for all dialogs.

7.8.  Subscriber processing of NOTIFY requests

   The user agent subscribing Device Profile to this event package MUST adhere be able to
   function effectively.  However, the
   NOTIFY request processing behavior methods specified in [RFC3265].  The user
   agent MUST attempt this
   document many fail to make the profiles effective within the time in
   seconds given in the "effective-by" Event header parameter if present
   in provide a Client with a profile.  To illustrate
   with an example, consider the NOTIFY request (see Section 7.7).  By default, the user agent
   makes the profiles effective as soon as it thinks case of a Client that it is non-
   obtrusive to do so.  For example, when there are no active calls.
   Profile changes SHOULD affect behavior on all new dialogs finds itself
   behind a local network which are
   created after the notification, but may does not provide information about DNS
   servers in the network (for example, misconfigured home network).  In
   such cases, it would be able beneficial to affect
   existing dialogs.  The user agent SHOULD use one of the techniques
   specified in Section 10 employ an alternative means to securely retrieve the profiles.  If the
   subscriber included the MIME type message/external-body for content
   indirection in the SUBSCRIBE request Accept header, the subscriber
   MUST support
   obtain the http: or https: URI schemes for content indirection.
   If profile information (for example, resolvable DNS Servers
   could be part of the subscriber indicated alternative URI schemes for content
   indirection Client profile).  While this specification
   recommends that such a method be made available, it MUST also indicate support for http: or https:.  The
   subscriber should still be prepared specifies
   one such option using HTTP that is described in this sub-section.
   Clients expected to use http: or https: as the encounter scenarios where Client profile delivery server
   retrieval can be hindered may not support employ the specified - or any
   alternative URI schemes. - process.

   The subscriber MUST be prepared method being described involves the Client to receive utilize a NOTIFY request with no
   body.  The subscriber MUST NOT reject the NOTIFY request with no
   body.  The subscription dialog MUST NOT be termnated HTTPS URI
   (and any required credentials) based on either pre-configuration or
   manual entry by the NOTIFY
   with no body.
      The subscriber should maintain the dialog as it was the profile
      delivery server's policy decision User (in cases where such an interface is
   possible).  This can lead to create the dialog.  Most
      likely retrieval of the NOTIFY body is empty because Device Profile
   which may contain the user or device is not
      provisioned properties for the SUBSCRIBE Request URI and
   credentials for Profile Enrollment and Profile Notification.  This
   approach bootstraps the process in a different step in the profile delivery server. cycle, but
   uses the same framework.

   Further, this document defines a new HTTP request header "Event".
   The notifier decided syntax of the HTTP Event header is the same as the SIP Event
   header defined in this document.  Similar to maintain the dialog so that it can NOTIFY SIP Event header the subscribe
   purpose of the
      availablity HTTP Event header is to define the content of the profile immediately after
   state information to be retrieved.  In particular, the user state
   information is the Device, User or Local-Network Profile for the
   Client.  The SIP Event header parameters for this event package
   ("profile-type", "vendor", "model", "version") are also mandatory for
   the HTTP Event header as they are used to provide information as to
   what profile type is requested along with information about the
   device
      gets provisioned.  If which may impact the subscriber ended contents of the dialog after
      receiving profile.When the NOTIFY Client
   starts with no body, the subscriber would need to be
      manually provoked to resubscribe.

7.9.  Handling retrieval of forked requests

   This event package allows the creation profile via HTTPS (instead of only one dialog as a result
   of an initial SIP
   SUBSCRIBE request.  The techniques to achieve the event package), the device MUST provide the Event
   header defined.

5.6.2.  Client Types

   The examples in this framework tend to associate Clients with
   entities that are
   described in section 4.4.9 of [RFC3265].

7.10.  Rate of notifications

   It accessible to end-users.  However, this is anticipated that not
   necessarily the rate only type of change for user and device
   profiles will Client that can utilize the specified
   Framework.  Clients can be very infrequent (i.e. days or weeks apart).  For
   this reason no throttling or minimum period between NOTIFY requests
   is specified for this package.

7.11.  State Agents

   State agents are not applicable to this event package.

7.12.  Examples

   Example SUBSCRIBE and NOTIFY request using content indirection: Note:

   The Event and Via header fields are continued on a second line due to
   format constraints of this document.

   SUBSCRIBE sip:MAC%3aFF00000036C5@acme.example.com SIP/2.0
   Event: ua-profile;profile-type=device;vendor="vendor.example.com";
    model="Z100";version="1.2.3";network-user="sip:betty@example.com"
   From: sip:MAC%3aFF00000036C5@acme.example.com;tag=1234
   To: sip:MAC%3aFF00000036C5@acme.example.com
   Call-ID: 3573853342923422@10.1.1.44
   CSeq: 2131 SUBSCRIBE
   Contact: sip:MAC%3aFF00000036C5@10.1.1.44
   Via: SIP/2.0/TCP 10.1.1.41;
     branch=z9hG4bK6d6d35b6e2a203104d97211a3d18f57a
   Accept: message/external-body, application/x-z100-device-profile
   Content-Length: 0

   NOTIFY sip:MAC%3aFF00000036C5@10.1.1.44 SIP/2.0
   Event: ua-profile;effective-by=3600;
                     network-user="sip:betty@example.com"
   From: sip:MAC%3aFF00000036C5@acme.example.com;tag=abcd
   To: sip:MAC%3aFF00000036C5@acme.example.com;tag=1234
   Call-ID: 3573853342923422@10.1.1.44
   CSeq: 321 NOTIFY
   Via: SIP/2.0/UDP 192.168.0.3;
     branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d1
   MIME-Version: 1.0
   Content-Type: multipart/mixed; boundary=boundary42
   Content-Length: ...

   --boundary42
   Content-Type: message/external-body;
       access-type="URL";
       expiration="Mon, 24 June 2002 09:00:00 GMT";
           URL="http://www.example.com/devices/ff00000036c5";
           size=1234

   Content-Type: application/x-z100-device-profile
   Content-ID: <39EHF78SA@example.com>

   --boundary42--

7.13.  Use of URIs to Retrieve State

   The URI entities such as User Interfaces (that
   allow for Client Configuration), entities in the SUBSCRIBE request is formed differently depending
   upon which profile type network that do not
   directly communicate with any Users (for example, Service Provider
   deployed gateways) or elements in the subscription is for. Service Provider's network (for
   example, SIP servers).

5.6.3.  Profile Data

   This allows framework does not specify the
   different profile types to be potentially managed by different contents for any Profile Type.
   Follow-on standardization activities can address profile delivery servers (perhaps even operated by different
   entities).  The To contents.
   However, it makes the following assumptions and From field recommendations:

   o  When the Client receives multiple profiles, the contents of each
      Profile Type will typically only contain data relevant to the same URI
   as is used in entity it
      represents.  As an example, consider a Client that obtains all the original SUBSCRIBE request URI.

7.13.1.  Device URIs

   The URI for
      defined profiles.  Information pertaining to the "device" type profile (device URI) local network is based upon the
   identity of
      contained in the device.  The device URI MUST be unique across all
   devices 'local-network' profile and implementations.  If an instance id is used as the user
   part of the device URI, it SHOULD remain the same not the'user'
      profile.  This does not preclude relevant data about a different
      entity from being included in a Profile Type, for example, the lifetime of
      'device' Profile Type may contain information about the user agent.  The device URI is used Users
      allowed to identify which access services via the Client.  A profile may also
      contain starting information to obtain subsequent Profiles
   o  Data overlap SHOULD be avoided across Profile Types, unless
      necessary.  If data overlap is
   associated with a specific instance present, prioritization of a user agent.

      If the user agent changed its device URI, data
      is left to data definitions.  As an example, the profile delivery
      server would not know Device Profile
      may contain the association between list of codecs to be used by the profile Client and the
      device.  This would also make it difficult for
      User Profile (for a User on the profile
      delivery server to track user agents under profile management.
      The profile delivery server Client) may decide to provide contain the same device
      profile to all devices of codecs
      preferred by the User.  Thus, the same vendor, model and version.
      However this data (usable codecs) is a implementation choice of the profile delivery
      server.  The subscribing device has no way of knowing whether the
      profiles for each device are different.  For this reason the
      device must always use a unique id
      present in two profiles.  However, the device SUBSCRIBE request
      URI.  As an example the device profile for similar devices data definitions may
      differ with properties such as
      indicate that to function effectively, any codec chosen for
      communication needs to be present in both the default user. profiles.

5.6.4.  Profile Data Frameworks

   This is how the
      bootstrapping mechanism works as described framework specified in Section 8.1.3.

   The URI for the device type this document does not address profile MUST use a unique identifier as
   the user portion of the URI.  The host and port portion of the URI is
   set to that of the domain
   data representation, storage or address of the profile delivery server
   which manages retrieval protocols.  It assumes that user agent.  A means of discovering the host and
   port portion is discussed in Section 8.1.  There is an administration
   aspect of
   the unique identifier, that makes PDS has a PCC based on existing or other Profile Data Frameworks,
   for example, XCAP ([I-D.ietf-simple-xcap]).

   While it desirable does not impose vast constraints on any such framework, it
   does allow for the id
   to be obtainable or predictable prior to installation propagation of profile content to PDS
   (specifically the device
   (hard or soft).  Also from a human factors perspective, ids that are
   easily distinguished and communicated will make the administrators
   job a little easier.  The MAC address PCC).  Thus, Profile Data or a UUID [RFC4122] SHOULD be Retrieval frameworks
   used in conjunction with this framework MAY consider techniques for constructing
   propagating incremental, atomic changes to the PDS.  For example, a unique identifier
   means for propagating changes to be used a PDS is defined in the user
   portion of the XCAP
   ([I-D.ietf-simple-xcap]).

5.6.5.  Additional Profile Types

   This document specifies three profile types: local-network, device URI.

   If the identifier
   and user.  However, there may be use cases for additional profile
   types.  For example, Profile Types for application specific profile
   data.  Definition of such additional Profile Types is not prohibited,
   but considered out of scope for this document.

6.  Event Package Definition

   The framework specified in this document proposes and specifies a MAC address, it MUST be formatted new
   SIP Event Package as the
   characters "MAC:" followed allowed by a 12 digit hexadecimal representation
   of the MAC address. [RFC3265].  The address can not include ":", whitespace, purpose is to allow
   for Clients to subscribe to specific Profile Types with PDSs and for
   the PDSs to notify the Clients with - or
   other formatting. pointers to - profile data.

   The MAC address of requirements specified in [RFC3265] apply to this package.  The
   following sub-sections specify the device may Event Package description and the
   associated requirements.  The framework requirements are defined in
   Section 5.

6.1.  Event Package Name

   The name of this package is "ua-profile".  This value appears in the
   Event header field present in SUBSCRIBE and NOTIFY requests for this
   package as defined in [RFC3265].

6.2.  Event Package Parameters

   This package defines the following new parameters for the event
   header:
      "profile-type", "vendor", "model", "version", "effective-by" and
      "network-user".
   The following rules apply:
   o  All the new parameters, with the exception of the "effective-by"
      parameter MUST only be used in SUBSCRIBE requests and ignored if there will always be
      no more than one user agent using that MAC address over time (e.g.
      a dedicated telephone appliance).
      they appear in NOTIFY requests
   o  The MAC address may not "effective-by" parameter is for use in NOTIFY requests only
      and MUST be used ignored if more than one user agent instance exists using the same MAC
      address (e.g. multiple instances of a softphone may run on a
      general purpose computing device). it appears in SUBSCRIBE requests
   The advantage semantics of these new parameters are specified in the MAC
      address following
   sub-sections.

6.2.1.  profile-type

   The "profile-type" parameter is that many vendors put bar codes on the device with used to indicate the
      actual MAC address on it.  A bar code scanner is a convenient
      means token name of collecting
   the instance id Profile Type the user agent wishes to obtain data or URIs for input and provisioning on
      the
   to be notified of subsequent changes.  This document defines three
   logical types of profiles and their token names.  They are as
   follows:

   local-network  Specifying "local-network" type profile delivery server.  If indicates the MAC address is used, it
      desire for profile data (URI when content indirection is
      recommended that the MAC address is rendered in all upper case
      with no punctuation for consistency across implementations.  A
      prefix of "MAC:" should be added to the MAC address to form a
      proper URN [RFC2141].  For example a device managed by
      sipuaconfig.example.com using its MAC address to form used)
      specific to the local network.
   device
      URI might look like:
      sip:MAC%3a00DF1E004CD0@sipuaconfig.example.com.

          UHEX  =  DIGIT / %x41-46 ;uppercase A-F
          MAC  =  %x4d.41.43 ; MAC in caps
          mac-ident = MAC ":" 12UHEX

   When the MAC address is not used in  Specifying "device" type profile(s) indicates the device URI, a UUID [RFC4122] desire for
      the device SHOULD be used.

      For devices where there is no MAC address or the MAC address profile data (URI when content indirection is
      not unique to an instance used) and change
      notification of a user agent (e.g. multiple
      softphones on a computer or a gateway with multiple logical user
      agents) it is RECOMMENDED that a UUID [RFC4122] is used as the
      user portion contents of the device URI.  The same approach to defining a
      user agent instance ID as [I-D.ietf-sip-outbound] should be used.
      When constructing the instance id, the implementer should also
      consider profile that a human may need to manually enter the instance id is specific to provision
      the device in or user agent.
   user  Specifying "user" type profile indicates the desire for the
      profile delivery server (e.g.
      longer strings are more error prone in data entry).  When the URN (URI when content indirection is used as the user part used) and change
      notification of the URI, it MUST be URL escaped. profile content for the user.
   The
      ":" "profile-type" is not a legal character (without being escaped) identified is identified in the user
      part of a addr-spec [RFC4122].  For example Event header
   parameter: profile-type.  A separate SUBSCRIBE dialog is used for
   each Profile Type.  The Profile Type associated with the instance ID:
      urn:uuid:f81d4fae-7ced-11d0-a765-00a0c91e6bf6 would dialog can
   then be escaped used to
      look as follows infer which Profile Type changed and is contained in a URI:
      sip:urn%3auuid%3af81d4fae-7ced-11d0-a765-00a0c91e6bf6@example.com.
      Soft user agents are likely to need to use this approach due to
   the multi-user nature of general purpose computers. NOTIFY or content indirection URI.  The software
      installer program might generate the uuid as part Accept header of the install
      process so that it remains persistent
   SUBSCRIBE request MUST include the MIME types for all profile content
   types for which the subscribing user agent wishes to retrieve
   profiles or receive change notifications.

   In the installation. following syntax definition using ABNF, EQUAL and token are
   defined in [RFC3261].  It
      may also is to be desirable noted that any upgrades of the software maintain
      the unique id.  However these are all implementation choices.

7.13.2.  User URIs additional Profile
   Types may be defined in subsequent documents.

   Profile-type   = "profile-type" EQUAL profile-value
   profile-value  =  profile-types / token
   profile-types  = "device" / "user" / "local-network"

   The URI "device", "user" or "local-network" token in the profile-type
   parameter may represent a class or set of profile properties.
   Follow-on standards defining specific profile contents may find it
   desirable to define additional tokens for the "user" type profile-type parameter.
   Also additional content types may be defined along with the profile is based upon
   formats that can be used in the identity Accept header of the SUBSCRIBE to
   filter or indicate what data sets of the
   user.  It is an administration policy on how user profile identities are assigned.  Typically desired.

6.2.2.  vendor, model and version

   The "vendor", "model" and "version" parameter values are tokens
   specified by the user's address implementer of record (AOR) is used
   as the URI user agent.  These parameters
   MUST be provided in the SUBSCRIBE request.  A new user agent or device may
   not know the user's AOR. request for all Profile Types.  The user's AOR may be obtained
   implementer SHOULD use their DNS domain name (for example,
   example.com) as part of a
   default user property in the device profile.  Alternatively the user
   agent may prompt value of the user for an AOR and credentials "vendor" parameter so that it is
   known to be used unique.  These parameters are useful to
   authenticate the request.  This can PDS to affect
   the profiles provided.  In some scenarios it is desirable to provide a login and/or hotelling
   different profiles based upon these parameters.  For example, feature
   property X in a profile may work differently on two versions of the
   same user agent.  The user agent may be pre-provisioned
   with  This gives the user's AOR or provided as information on a SIM PDS the ability to compensate for or flash key.
   These are only examples and not an exhaustive list
   take advantage of sources for the
   user AOR.

7.13.3.  Local Network URIs differences.  In the following ABNF defining
   the syntax, EQUAL and quoted-string are defined in [RFC3261].

   Vendor       =  "vendor" EQUAL quoted-string
   Model        =  "model" EQUAL quoted-string
   Version      =  "version" EQUAL quoted-string

6.2.3.  network-user

   The URI "network-user" parameter MUST be set when subscribing for the "local-network" type profile "local-
   network" profiles if it is based upon known, unless the
   identity of Client is provisioned to
   preserve privacy within the local network.  When subscribing  This allows the Client to
   indicate a user who may have special privileges in the local network
   profile,
   that impact the user part contents of the SUBSCRIBE request URI SHOULD NOT "local-network" profile.  It MAY also
   be
   provided.  The From field user part of provided in a subscription for a "device" profile.  In such cases
   the SUBSCRIBE request SHOULD
   be Client is requesting the same device ID used PDS to recognize the indicated user as
   the default user part of for itself.

   The Notifier SHOULD authenticate the device profile
   SUBSCRIBE request URI defined in Section 7.13.1.  The host and port
   part of the request URI and From field is the local network name/
   domain.  The discovery of subscriber to verify the local network name or domain is
   discussed
   resource identifier in Section 8.1.  The user agent may provide the user's AOR
   as the value to the "network-user" event header parameter.  This is
   useful parameter, if the profile
   provided is specific to the user has (for example, granting policies or
   privileges in the local network beyond those of the a default user.  When "network-user" user).  If the value of the
   "profile-type" parameter is provided not "device" or "local-network", the profile
   delivery server SHOULD authenticate
   "network-user" parameter has no defined meaning and is ignored.  If
   the user before providing "network-user" parameter is provided in the
   profile if additional privileges are granted.  Example URI: sip:
   example.com

      The local network profile SUBSCRIBE request URI does not have a
      user part so that request, it
   MUST be present in the URI is distinct between NOTIFY request as well.  In the "local" following
   ABNF, EQUAL, LDQUOT, RDQUOT and
      "device" URIs when addr-spec are defined in [RFC3261].

   Network-User =  "network-user" EQUAL LDQUOT addr-spec RDQUOT

6.2.4.  effective-by parameter

   The "effective-by" parameter in the domain is Event header of the same for NOTIFY
   request specifies the two.  This
      provides a means maximum number of routing seconds before the user agent
   must attempt to make the appropriate new profile delivery
      server in domains where they are distinct servers. effective.  The From field
      uses the device ID "effective-by"
   parameter MAY be provided in the user part NOTIFY request for any of the local network request
      URI so
   Profile Types.  A value of 0 (zero) indicates that every device in the network has a unique and constant
      From field.  Even though every device may get the same or similar
      local network profiles, subscribing
   user agent must attempt to make the uniqueness of profiles effective immediately
   (despite possible service interruptions).  This gives the From field provides
      an important capability.  Having unique From fields allows PDS the
      management of
   power to control when the local network profile is effective.  This may be
   important to track resolve an emergency problem or disable a user agents present in
      the network and consequently also manage resources such as
      bandwidth and port allocation.

8.  Profile Delivery Framework Details agent
   immediately.  The following describes how different functional steps of the profile
   delivery framework work.  Also described here "effective-by" parameter is how the event
   package defined ignored in this document provides all messages
   other than the enrollment and
   notification functions within NOTIFY request.  In the framework.

8.1.  Discovery following ABNF, EQUAL and
   DIGIT are defined in [RFC3261].

   Effective-By =  "effective-by" EQUAL 1*DIGIT

6.2.5.  Summary of Subscription URI event parameters

   The discovery approach varies depending upon following are example Event headers which profile type URI
   is may occur in SUBSCRIBE
   requests.  These examples are not intended to be discovered. complete SUBSCRIBE
   requests.

   Event: ua-profile;profile-type=device;
          vendor="vendor.example.com";model="Z100";version="1.2.3"

   Event: ua-profile;profile-type="user";
          vendor="premier.example.com";model="trs8000";version="5.5"

   The order of discovery is important in the
   bootstrapping situation as the user agent following are example Event headers which may occur in NOTIFY
   requests.  These example headers are not have any
   information provisioned.  The local network profile should be
   discovered first as it may contain key information such as how to
   traverse a NAT/firewall to get intended to outside services (e.g. the user's
   profile delivery server).  The device profile URI should be
   discovered next. complete
   SUBSCRIBE requests.

   Event: ua-profile;effective-by=0

   Event: ua-profile;effective-by=3600

   The device profile may contain following table shows the default user's
   AOR or firmware/software information that should be updated first
   before proceeding with use of Event header parameters in
   SUBSCRIBE requests for the discovery process.  The three Profile Types:

   profile-type || device | user profile
   subscription URI | local-network
   =============================================
   vendor       ||   m    |  m   |        m
   model        ||   m    |  m   |        m
   version      ||   m    |  m   |        m
   network-user ||   s    |      |        s
   effective-by ||        |      |

   m - mandatory
   s - SHOULD be provided
   o - optional

   Non-specified means that the parameter has no meaning and should be discovered last.
   ignored.

   The URIs are formed
   differently for each of the profile types.  This is to support following table shows the
   delegation use of Event header parameters in
   NOTIFY requests for the profile management to potentially three different
   entities.  However all three profile types may be provided by the
   same entity.  As the Profile Types:

   profile-type || device | user agent has | local-network
   =============================================
   vendor       ||        |      |
   model        ||        |      |
   version      ||        |      |
   network-user ||   s    |      |        s
   effective-by ||   o    |  o   |        o

6.3.  SUBSCRIBE Bodies

   This package defines no way use of knowing whether the
   profiles are provide by one or more different profile delivery
   servers ahead of time, it must subscribe to all three profile types
   in separate SUBSCRIBE requests request body.  If
   present, it MUST be ignored.

   Future enhancements to get the profiles.

8.1.1.  Discovery of Local Network URI

   The "discovered" host framework may specify a use for the "local-network"
   SUBSCRIBE request body (for example,, mechanisms using etags to
   minimize Profile Notifications to Clients with current profile
   versions).

6.4.  Subscription Duration

   The duration of a subscription
   URI is specific to SIP deployments and no
   specific recommendation is made by this Event Package.  If absent, a
   value of 86400 seconds is RECOMMENDED since the local IP network domain for presence (or absence)
   of a Client subscription is not time critical to the user agent, either
   provisioned as part regular
   functioning of the device's static network configuration or
   discovered via DHCP [RFC2131](option 15 [RFC2132]).  The local
   network PDS.

   It is to be noted that a one-time fetch of a profile subscription URI SHOULD not can be remembered if
   accomplished by setting the user
   agent moves from one local network 'Expires' parameter to another other. a value of Zero,
   as specified in [RFC3265].

6.5.  NOTIFY Bodies

   The user agent
   should perform framework specifying the local network discovery Event Package allows for the NOTIFY body
   to construct contain the network profile subscription request URI every time it starts up data or network
   connectivity is regained.

      For example: a pointer to the profile data using
   content direction.  The user agent requested framework does not define any profile data
   and received the local
      domain name delegates specification of utilized MIME types Profile Data
   Frameworks.  For profile data delivered via DHCP: airport.example.net.  If content indirection, the device ID is:
      MAC:00DF1E004CD0,
   following apply:

   o  the local network profile SUBSCRIBE request Content-ID MIME header, as described in [RFC4483] MUST be used
      for each Profile document URI
      would look like: sip:MAC%3a00DF1E004CD0@airport.example.net.  The
      user agent should send this request using
   o  at a minimum, the normal SIP locating
      mechanisms defined in [RFC3263]. "http:" and "https:" URI schemes MUST be
      supported; other URI schemas MAY be supported based on the Profile
      Data Frameworks (examples include FTP [RFC0959], TFTP
      [RFC3617],HTTP [RFC2616], HTTPS [RFC2818], LDAP [RFC3377], XCAP
      [I-D.ietf-simple-xcap], XCAP-DIFF [I-D.ietf-simple-xcap-diff])

   The Event NOTIFY body SHOULD include a MIME type specified in the 'Accept'
   header would look like of the following SUBSCRIBE.  Further, if the user agent decided to provide
      sip:alice@example.com as Accept header of the user's AOR.  (Alice may have a prior
      arrangement with
   SUBSCRIBE included the local network operator giving her special
      privileges.):

   Event: ua-profile;profile-type=local-network;
      network-user="sip:alice@example.com"

8.1.2.  Discovery of Device URI

   The discovery function MIME type message/external-body (indicating
   support for content indirection) the content indirection SHOULD be
   used in the NOTIFY body for providing the profiles.  If none are
   specified, the Profile Data frameworks are responsible for, and MUST
   specify, the MIME type to be assumed.

6.6.  Notifier Processing of SUBSCRIBE Requests

   A successful SUBSCRIBE request results in a NOTIFY with either
   profile contents or a pointer to it (via Content Indirection).  If
   the NOTIFY is needed expected to bootstrap user agents contain profile contents or the Notifier is
   unsure, the SUBSCRIBE SHOULD be either authenticated or transmitted
   over an integrity protected SIP communication channels.  Exceptions
   to authenticating such SUBSCRIBEs include cases where the
   point identity of knowing where
   the Subscriber is unknown and the Notifier is configured to enroll with accept
   such requests.

   The Notifier MAY also authenticate SUBSCRIBE messages even if the
   NOTIFY is expected to only contain a pointer to profile delivery server. data.
   Securing data sent via Content Indirection is covered in Section 7.13.1 describes how 9.

   If the Profile Type indicated in the "profile-type" Event header
   parameter is unavailable or the Notifier is configured not to form provide
   it, the user part of Notifier SHOULD return a 404 response to the device
   profile SUBSCRIBE request URI used for enrollment.  However the
   bootstrapping problem for
   request.  If the specific user agent (out of the box) or Client is what to
   use for unknown, the host and port in Notifier MAY
   either accept or reject the device URI.  Due to subscription.

   When the wide
   variation of environments in which Event header "profile-type" is "device" and the enrolling user agent may
   reside (e.g. behind residential router, enterprise LAN, WLAN hotspot,
   ISP, dialup modem) and
   has provided the limited control that user's AOR in the administrator of "network-user" parameter, the
   profile delivery server (e.g. enterprise, service provider) may
   have over that environment, no single discovery mechanism works
   everywhere.

   Therefore a number of mechanisms should be tried in MAY set or change the specified
   order: SIP DHCP option [RFC3361], SIP DNS SRV [RFC3263], DNS A record
   and manual.  The default user agent may be pre-provisioned associated
   with the host and
   port (e.g. service providers may pre-provision a device before
   sending it to a subscriber, provide a SIM or flash key, etc.) Client indicated in
   which case this discovery mechanism is not needed.  Before performing the discovery steps, Subscription request.  However, the
   Notifier SHOULD authenticate the user agent should provide indicated before making such a means to skip
   change.

6.7.  Notifier Generation of NOTIFY Requests

   As specified in [RFC3265], the discovery stage and manually enter Notifier MUST always send a NOTIFY
   request upon accepting a subscription.  If the device URI host Client or User is
   unknown and port.
   In addition, the user agent should allow the user Notifier choose to accept the subscription, the
   Notifier MAY either respond with profile data (for example, default
   profile data) or reject provide no profile information (i.e. no body or
   content indirection).

   If the discovered host and port URI in case an alternative to the discovered
   host and port is desired.

   1.  The first discovery mechanism for the device SUBSCRIBE request
       URI Section 7.13.1 is to use the host a known identity and port of the outbound
       proxy discovered by the SIP DHCP option 120 [RFC3361].  If the
       SIP DHCP option
   requested profile information is not provided available (i.e. as specified in the DHCP response or if the
       SUBSCRIBE request to
   profile-type parameter of the ua-profile event receives no response or
       a failure response other than for authentication, Event header), the next
       discovery mechanism should be tried.

          For example: Consider Notifier SHOULD send
   a dedicated hardware device NOTIFY with a
          single user agent having profile data.  Profile data MAY be sent as profile
   contents or via Content Indirection (if the MAC address: abc123efd456.  The
          user agent sends a DHCP request including content indirection MIME
   type was included in the request Accept header).  To allow for Content
   Indirection, the
          DHCP option for SIP: 120 (see [RFC3361]).  If the DHCP
          response includes an answer for option 120, then Subscriber MUST support the DNS name "http:" or IP address included is used in the host part of "https:" URI
   schemas.  If the device
          URI.  For this example let's assume: example.com.  The device Subscriber wishes to support alternative URI would look like: sip:MAC%3aABC123EFD456@example.com.  The
          user agent should send this request using schemas
   it MUST be indicated in the normal SIP
          locating mechanisms "schemes" Contact header field parameter
   as defined in [RFC3263]. [RFC4483].  If the response
          fails then, subscriber does not specify the next discovery mechanism is tried.

   2.  The local IP network domain for URI
   scheme, the user agent, Notifier may use either configured "http:" or discovered via DHCP option 15, should "https:".

   The Notifier MAY specify when the new profiles must be used with made effective
   by the
       technique in [RFC3263] to obtain Subscriber by specifying a host and port to use maximum time in seconds (zero or
   more) in the
       SUBSCRIBE URI. "effective-by" event header parameter.

   If no SIP response or a SIP failure response
       other than for authorization is received for the SUBSCRIBE
       request to the ua-profile event, the next discovery mechanism
       should be tried.

          For example: The user agent requested and was received over an integrity protected SIP
   communications channel, the local
          domain name (option 15 [RFC2132]) in the DHCP response:
          boston.example.com.  The device URI would look like:
          sip:MAC%3aABC123EFD456@boston.example.com.  The user agent
          should Notifier SHOULD send the NOTIFY over the
   same channel.

6.8.  Subscriber Processing of NOTIFY Requests

   A Subscriber to this request using event package MUST adhere to the normal SIP locating
          mechanisms defined NOTIFY request
   processing behavior specified in [RFC3263]. [RFC3265].  If the response fails then, Notifier
   indicated an effective time (using the next discovery mechanism is tried.

   3.  The fully qualified host name constructed by concatenating
       "sipuaconfig" and "effective-by" Event Header
   parameter), it SHOULD attempt to make the local IP network domain (as provided via
       DHCP option 15 or provisioned) should be tried next using profiles effective within
   the
       technique specified time.  Exceptions include deployments that prohibit
   such behavior in [RFC3263] to obtain a host and port to use certain cases (for example, emergency sessions are
   in the
       SUBSCRIBE URI.  If no SIP response or a SIP failure response
       other than for authorization is received for the SUBSCRIBE
       request to the ua-profile event, the next discovery mechanism
       should progress).  When profile data cannot be tried.

          For example: The user agent requested and received the local
          domain name via DHCP as in applied within the above example:
          boston.example.com.  The device URI would look like:
          sip:MAC%3aABC123EFD456@sipuaconfig.boston.example.com.  The
          user agent should send
   recommended timeframe and this request using the normal SIP
          locating mechanisms affects Client behavior, any actions
   to be taken SHOULD be defined in [RFC3263].  If by the response
          fails then, profile data definitions.  By
   default, the next discovery mechanism Subscriber is tried.

   4.  If all other discovery techniques fail, a manual means for the
       user RECOMMENDED to enter make the host profiles effective
   as soon as possible.

   The Subscriber MUST always support "http:" or "https:" and port used be
   prepared to construct the SUBSCRIBE
       request accept NOTIFY messages with those URI schemas.The
   subscriber MUST also be provided by the user agent.

   Two approaches prepared to the manual discovery process are suggested.  In the
   first approach using SIP, the user agent provides receive a means for
   entering the subscription host and port information for the NOTIFY request
   URI along with no
   body.  The subscriber MUST NOT reject the user id and password to NOTIFY request with no
   body.  The subscription dialog MUST NOT be used for authentication terminated by a NOTIFY
   with no body.

6.9.  Handling of Forked Requests

   This Event package allows the creation of only one dialog as a result
   of an initial SUBSCRIBE request.  With this approach the user agent begins
   with request as described in section 4.4.9 of
   [RFC3265].  It does not support the enrollment process followed by creation of multiple
   subscriptions using forked SUBSCRIBE requests.

6.10.  Rate of Notifications

   The rate of notifications for the change notification and
   profile retrieval steps.

   An alternative profiles in this framework is
   deployment specific, but expected to be infrequent.  Hence, the manual discovery using SIP, is Event
   Package specification does not specify a throttling or minimum period
   between NOTIFY requests

6.11.  State Agents

   State agents are not applicable to start this Event Package.

7.  Examples

   This section provides examples along with sample SIP message bodies
   relevant to this framework.  Both the retrieve process.  The user agent provides examples are derived from a means
   snapshot of entering a
   HTTPS URI along with Section 4.1, specifically the user id and password to be used request for
   authentication of the retrieval Device
   Profile.  The examples are purely informative and in case of
   conflicts with the profile.  The retrieved device framework or protocols used for illustration, the
   latter should be deemed normative.

7.1.  Example 1: Client requesting profile may contain

   This example illustrates the properties for detailed message flows between the SUBSCRIBE request URI
   Client and
   credentials to enroll the SIP Service Provider's network for requesting and get change notification of
   retrieving the profile changes.
   This approach bootstraps (the flow uses the process in Device Profile as an
   example).

   The following are assumed for this example:

   o  Client is assumed to have established local network connectivity;
      NAT and Firewall considerations are assumed to have been addressed
      by the SIP Service Provider
   o  examples are a different step in snapshot only and do not illustrate all the
   cycle, but uses
      interactions between the same profile framework.  When Client and the device starts Service Provider's network
      (and none between the entities in the SIP Service Provider's
      network)
   o  All SIP communication with retrieval of the profile SIP Service Provider happens via HTTPS (instead of a
      SIP SUBSCRIBE Proxy
   o  HTTP is assumed to be the event package), the device MUST provide the Event header in
   the HTTPS request using the same format Profile Data method used (any suitable
      alternative can be used as described for the
   SUBSCRIBE request (see Section 7.2) .  The Event header well)
   o  TLS is necessary assumed to determine which profile is requested as well as be the protocol for providing
   specific information about securing the device.

   This document defines a new HTTP request header "Event". Profile
      Retrieval (any other suitable protocol can be employed);
      authentication and security requirements are not addressed

   The syntax flow diagram and an explanation of the messages follow.

                                      +----------------------+
    +--------+                        | SIP Service Provider |
    | Client |                        |                      |
    |(SIP UA)|                        |  SIP     PDS   HTTP Event header is  |
    +--------+                        | PROXY         Server |
                                      |                      |
                                      +----------------------+
         |                                |       |      |
         |                                |       |      |
         |          SUBSCRIBE             |       |      |
   (SReq)|--------device profile--------->|       |      |
         |                                |------>|      |
         |                                |200 OK |      |
         |            200 OK              |<------|      |
   (SRes)|<-------------------------------|       |      |
         |                                |       |      |
         |                                | NOTIFY|      |
         |    NOTIFY (Content Indirection)|<------|      |
   (NTFY)|<-------------------------------|       |      |
         |            200 OK              |       |      |
   (NRes)|------------------------------->|200 OK |      |
         |                                |------>|      |
         |                                               |
         |                                               |
         |                                               |
         |<<<<<<<<<<<<<  TLS establishment  >>>>>>>>>>>>>|
         |                                               |
         |                HTTP Request                   |
   (XReq)|---------------------------------------------->|
         |                                               |
         |                HTTP Response                  |
   (XRes)|<----------------------------------------------|
         |                                               |

   (SReq)

      the same as Client transmits a request for the 'device' profile using the
      SIP SUBSCRIBE utilizing the Event header defined Package specified in this document.  The purpose
      framework.

      *    Note: Some of the HTTP Event header, just like
   the SIP Event header is fields (for example, Event, via) are
           continued on a separate line due to define the content format constraints of
           this document
   SUBSCRIBE sip:MAC%3a000000000000@sip.example.net SIP/2.0
   Event: ua-profile;profile-type=device;vendor="vendor.example.net";
    model="Z100";version="1.2.3";network-user="sip:user@sip.example.net"
   From: sip:MAC%3A000000000000@sip.example.net;tag=1234
   To: sip:MAC%3A000000000000@sip.example.net
   Call-ID: 3573853342923422@10.1.1.44
   CSeq: 2131 SUBSCRIBE
   Contact: sip:MAC%3A000000000000@sip.example.net
   Via: SIP/2.0/TCP 10.1.1.41;
     branch=z9hG4bK6d6d35b6e2a203104d97211a3d18f57a
   Accept: message/external-body, application/x-z100-device-profile
   Content-Length: 0

   (SRes)

      the state
   information to be retrieved.  In particular, the state information SUBSCRIBE request is received by a SIP Proxy in the device, user or local Service
      Provider's network profile for which transmits it to the device. PDS.  The SIP
   Event header parameters for this event package ("profile-type",
   "vendor", "model", "version") are also manditory for PDS accepts
      the HTTP Event
   header as they are used to provide information as to what profile
   type is requested along response and responds with information about a 200 OK
      *    Note: The Client and the device which SIP proxy may
   impact have established a
           secure communications channel (for example, TLS)

   (NTFY)

      subsequently, the contents PDS transmits a SIP NOTIFY message indicating
      the profile location
      *  Note: Some of the profile.

   Once a user agent has been successfully discovered, enrolled and
   received fields (for example, content-type) are
         continued on a separate line due to format constraints of this
         document
   NOTIFY response sip:MAC%3A000000000000@10.1.1.44 SIP/2.0
   Event: ua-profile;effective-by=3600
   From: sip:MAC%3A000000000000@sip.example.net;tag=abca
   To: sip:MAC%3A000000000000@sip.example.net;tag=1231
   Call-ID: 3573853342923422@10.1.1.44
   CSeq: 322 NOTIFY
   Via: SIP/2.0/UDP 192.168.0.3;
     branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d0
   MIME-Version: 1.0
   Content-Type: message/external-body; access-type="URL";
                 expiration="Mon, 01 Jan 2010 09:00:00 UTC";
                 URL="http://sip.example.net/z100-000000000000.html";
                 size=9999
                 hash=10AB568E91245681AC1B

   Content-Type: application/x-z100-device-profile
   Content-ID: <39EHF78SA@sip.example.net>
   .
   .
   .

   (NRes)

      Client accepts the NOTIFY message and responds with profile data or URI(s), a 200 OK

   (XReq)

      once the user
   agent should cache (i.e. store persistently) necessary secure communications channel is established,
      the device profile
   SUBSCRIBE Client sends an HTTP request URI (rather than reconstructing it as described in
   the discovery process every time the device is restarted) to avoid
   having to rediscover the profile delivery HTTP server again indicated in
      the future.
   Caching of the device URI is necessary when NOTIFY

   (XRes)

      the user agent is likely
   to move HTTP server responds to different local network domains as the local network may
   not be the provider for request via a HTTP response
      containing the device's profile. profile contents

7.2.  Example 2: Client obtaining change notification

   The user agent should
   not cache following example illustrates the device URI until it receives case where a NOTIFY with profile data
   or URI(s).  The reason for this User (X) is that
   simultaneously accessing services via two different Clients (for
   example, Multimedia Soft Clients on a profile delivery server may
   send 202 responses to SUBSCRIBE requests PC and PDA) and NOTIFY responses to
   unknown user agent (see Section 7.6) with no profile data or URIs.
   Until the profile delivery server has sent a NOTIFY request with
   profile data or URI(s), it has not agreed access to provide profiles.

      To illustrate why the user agent should not cache the device
      profile SUBSCRIBE URI until profile data or URI(s) are provided in
      the NOTIFY, consider the following example: a user agent running
      on a laptop plugged into a visited LAN in which a foreign profile
      delivery server is discovered.  The profile delivery server never
      provides profile URIs in the NOTIFY request as it is not
      provisioned
   User Interface (UI) that allows for changes to accept the user agent. User profile.

   The user then takes the
      laptop to their enterprise LAN.  In following are assumed for this example, the user agent
      cached the SUBSCRIBE URI from the visited LAN which did not
      provide profiles.  When the UA is subsequently placed in example:

   o  The Clients (A & B) obtain the
      enterprise LAN which is provisioned to provide necessary profiles to from the
      user agent, same
      SIP Service Provider
   o  The SIP Service Provider also provides a User Interface (UI) that
      allows the user agent would not attempt User to discover change preferences that impact the
      profile delivery server.

8.1.3.  Discovery of User URI

   The user's AOR may be pre-provisioned or provided via SIM or flash
   key, etc.  The device profile may define a default user and AOR.  If
   provided in the device profile

   The flow diagram and a pre-provisioned user AOR is not
   provided, the default user's AOR is used to subscribe to the "user"
   profile.  If not provided through the above two approaches, the AOR
   to be used for the "user" subscription URI, is "discovered" manually
   by prompting an explanation of the user. messages follow.
   o  Note: The URI obtained in the discovery steps
   described above for the "user" profile subscription is stored
   persistently in the device until explicitly reset or updated by the
   user or profile.

8.2.  Enrollment with Profile Server

   Enrollment is accomplished by subscribing to the event package
   described in Section 7.  The enrollment process is useful to the
   profile delivery server as it makes the server aware example only shows retrieval of user agents
   to which User X's profile, but it
      may deliver profiles.  These include user agents that the
   profile delivery server is provisioned to provide profiles to, those
   present to which the server may provide profiles in the future, and
   those that the server can automatically provide default profiles.  It
   is an implementation choice request and business policy as to whether the
   profile delivery server provides retrieve other profiles to user agents that it is
   not explicitly provisioned to do so.  However the profile delivery
   server SHOULD accept (with 2xx response) SUBSCRIBE requests from any
   user agent as explained in Section 7.5.

8.3.  Notification of Profile Changes

   The NOTIFY request in the ua-profile event package serves two
   purposes.  First it provides the user agent with a means to obtain
   the profile data directly or via URI(s) (for example, local-
      network, Client).

               -----           -----
              |User |_________| UI* | * = User Interface
              |  X  |         |     |
               -----           -----
             /       \
            /         \
           /           \              +----------------------+
    +--------+      +--------+        | SIP Service Provider |
    | Client |      | Client |        |                      |
    |    A   |      |    B   |        |  SIP     PDS   HTTP  |
    +--------+      +--------+        | PROXY         Server |
                                      +----------------------+
         |                                |       |      |
         |                                |       |      |
   (A-EX)|<=Enrolls for desired profiles without
   requiring the end user to manually enter them.  It also provides the
   means User X's profile=>|<=====>|      |
         |                                |       |      |
         |                                               |
   (A-RX)|<===Retrieves User X's profile================>|
         |                                               |
         |               |                |       |      |
         |               |  Enrolls for the profile delivery server to notify the user agent that
   the content of the profiles has changed and should be made effective.
   Optionally the differential changes may be obtained by notification
   by including the content-type: "application/xcap-diff+xml" defined in
   [I-D.ietf-simple-xcap-diff] in the Accept header of the SUBSCRIBE
   request.

8.4.  Retrieval of Profile Data

   The user agent retrieves its needed profile(s) directly or via the
   URI(s) provided in the NOTIFY request as specified in Section 7.5.
   The profile delivery server SHOULD secure the content of the profiles
   using one of the techniques described in Section 10.  The user agent
   SHOULD make the new profiles effective in the timeframe described in
   Section 7.2.

   The contents of the profiles SHOULD be cached (i.e. stored
   persistently) by the user agent.  The cache should be used if the
   user agent is unable to successfully SUBSCRIBE or receive the NOTIFY
   providing the most recent profile.  The cached profile should be
   replaced each time a profile is received in a NOTIFY or retrieved via
   content indirection.  This it to avoid the situation where the
   content delivery server being not available, leaves the user agent
   non-functional.  The user agent should verify that it has the latest
   profile content using the "hash" parameter defined in [I-D.ietf-sip-
   content-indirect-mech].

8.5.  Upload of Profile Changes

   The user agent or other service MAY push changes up to the profile
   delivery server using the technique appropriate to the profile's URI
   scheme (e.g.  HTTP PUT method, FTP put command).  The technique for
   pushing incremental or atomic changes MUST be described by the
   specific profile data framework.  A means for pushing changes up into
   the profile delivery server for XCAP is defined in [I-D.ietf-simple-
   xcap].

9.  IANA Considerations

   There are several IANA considerations associated with this
   specification.

9.1.  SIP Event Package

   This specification registers a new event package as defined in
   [RFC3265].  The following information required for this registration:

      Package Name: ua-profile
      Package or Template-Package: This is a package
      Published Document: RFC XXXX (Note to RFC Editor: Please fill in
      XXXX with the RFC number of this specification).
      Person to Contact: Daniel Petrie dan.ietf AT SIPez DOT com
      New event header parameters: profile-type, vendor, model, version,
      effective-by, network-user
      The profile-type parameter has predefined values.  The other new
      event header parameters do not.
   The following table illustrates the additions to the IANA SIP Header
   Field Parameters and Parameter Values: (Note to RFC Editor: Please
   fill in XXXX with the RFC number of this specification)

                                                  Predefined
   Header Field                  Parameter Name     Values     Reference
   ----------------------------  ---------------   ---------   ---------
   Event                         profile-type      Yes         [RFCXXXX]
   Event                         vendor            No          [RFCXXXX]
   Event                         model             No          [RFCXXXX]
   Event                         version           No          [RFCXXXX]
   Event                         effective-by      No          [RFCXXXX]
   Event                         network-user      No          [RFCXXXX]

9.2.  New HTTP Event Header

   This document defines a new permanent HTTP request header field:
   Event

      Header field name: Event
      Applicable protocol: http
      Status: standard
      Author/Change controller: IETF
      Specification document(s): [RFCXXXX] (Note to RFC Editor: Please
      fill in XXXX with the RFC number of this specification).

10.  Security Considerations

   Profiles may contain sensitive data such as user credentials and
   personal information.  The protection of this data depends upon how
   the data is delivered.  Some profiles may be safe to deliver without
   the need to protect the content.  For example in some environments
   the local network profile may contain the list of codecs that are
   acceptable for use in the network and information on NAT traversal
   such as a STUN server to use.  As the information in this example
   local network profile does not contain passwords or sensitive
   information it may be acceptable to provide it without authentication
   or confidentiality (encryption).  We refer to these as non-
   confidential profiles.  Non-confidential profiles require message
   integrity and profile server authentication, as described in
   Section 10.3.  However any profiles that contain personal
   information, passwords or credentials (confidential profiles) require
   mutual authentication, confidentiality, and message integrity, and
   must follow the guidance provided in the next two subsections.
   Profile specifications that define schemas MUST identify if they
   contain confidential data to indicate which of the security
   approaches described here should be used.

   The profile data is delivered in either the NOTIFY request or via the
   URI scheme indicated in the content indirection in the NOTIFY
   request.  The security approach is different for these two delivery
   mechanisms.

   Subscribers implementing this specification MUST implement either
   HTTP or HTTPS.  Subscribers also MUST implement the hash verification
   scheme described in SIP content indirection [I-D.ietf-sip-content-
   indirect-mech].  SIP profile delivery servers MUST implement both
   HTTP and HTTPS, and SHOULD implement a SIP Authentication Service as
   described in the SIP Identity mechanism [I-D.ietf-sip-identity].  All
   SIP entities are already required to implement SIP Digest
   authentication [RFC3261].

10.1.  Confidential Profile Content in NOTIFY Request

   When the profile data is delivered directly in the NOTIFY request,
   the SUBSCRIBE request MUST be authenticated using the SIP Digest
   authentication mechanism.  As the profile content is delivered in the
   resulting NOTIFY request to the subscription, authenticating the
   SUBSCRIBE is the only way to prevent unauthorized access to the
   profile data.  To provide message integrity and confidentiality over
   the profile data, a direct TLS connection MUST be established for the
   SUBSCRIBE request.  The device SHOULD authenticate the server via the
   TLS connection, which also provides a means of verifying (as
   described in [RFC3261]) that a direct TLS connection was used (e.g.
   The device may prompt the user to verify the SubjectAltName in the
   server's certificate.).  The server may challenge the device for its
   certificate, when establishing the TLS connection, to obtain the
   public key to use to S/MIME encode the NOTIFY request body containing
   the profile data.  Because the device verified that it has a direct
   TLS connection by verifying the server's certificate and the server
   verified the identity of the device using Digest Authentication, the
   server can assume the certificate provided by the device is
   authenticated.  The use of S/MIME in the NOTIFY request does not
   relieve the need to authenticate the SUBSCRIBE request using SIP
   Digest authentication.  In this scenario S/MIME only provides message
   integrity and confidentiality of the content of the profile.  If
   S/MIME is not used for the profile data in the NOTIFY request, the
   notifier MUST use the same direct TLS connection established by the
   device for the SUBSCRIBE request to send the notification.  In this
   scenario the use of a user-specific ID and secret for Digest
   Authentication can be used to establish an association between the
   user ID and the device ID provided in the device profile SUBSCRIBE
   request.

10.2.  Confidential Profile Content via Content Indirection

   When the profile data is delivered via content indirection,
   authentication, integrity, confidentiality are all provided in the   |       |      |
         |         (B-EX)|<== User X's ==>|<=====>|      |
         |               |    profile indirection retrieval scheme.  When content indirection is
   used, the SUBSCRIBE request does not need to be authenticated.  There
   is a TLS certificate approach     |       |      |
         |               |                |       |      |
         |               |                               |
         |         (B-RX)|<= Retrieves User X's profile=>|
         |                                               |
         |                       |                       |
         |                 (HPut)|---------------------->|
         |                       |                       |
         |                 (HRes)|<----------------------|
         |                                               |
         |                                |       |      |
         |                                | NOTIFY|      |
         |            NOTIFY              |<------|      |
   (A-NT)|<-------------------------------|       |      |
         |            200 OK              |       |      |
   (A-RS)|------------------------------->|200 OK |      |
         |                                |------>|      |
         |                                               |
         |               |                | NOTIFY|      |
         |               |    NOTIFY      |<------|      |
         |         (B-NT)|<---------------|       |      |
         |               |    200 OK      |       |      |
         |         (B-RS)|--------------->|200 OK |      |
         |               |                |------>|      |
         |                                               |
         |                                               |
   (A-RX)|<===Retrieves User X's profile================>|
         |                                               |
         |               |                               |
         |               |                               |
         |         (B-RX)|<= Retrieves User X's profile=>|
         |               |                               |

   (A-EX)  Client A discovers, enrolls and a Digest Authentication approach
   which may be used to provide the required security.  The profile
   delivery server MUST support both of these methods.  The device MUST
   support the Digest Authentication method to provide minimal
   interoperability.

   For the TLS certificate approach, the device requests the profile
   using HTTPS.  To provide authentication, the server challenges the
   device for its certificate.  The server obtains the user part of the
   SIP URI in the Subject Alternative Name field of the device's
   certificate.  The user part of the SIP URI in the device's
   certificate is used as the device ID to authenticate if the device is
   authorized notification related
      to retrieve the specified profile.  The device
   certificates chain of authorities MUST also be verified.  This
   approach for providing security requires that the device ID User X's profile
   (A-RX)  Client A retrieves User X's profile
   (B-EX)  Client B discovers, enrolls and
   associated user are provisioned for authentication as part of obtains notification related
      to User X's profile
   (B-RX)  Client B retrieves User X's profile
   (HPut)  Changes affected by the
   content indirection retrieval.

   For User via the Digest Authentication approach, HTTPS SHOULD be used User Interface (UI) are
      uploaded to
   provide confidentiality of the profile data. HTTP Digest
   Authentication [RFC2617] MUST be used to authenticate Server
      *  Note: The UI itself can act as a Client and authorize
   the device subscribe to retrieve the User
         X's profile.  The shared secret used in the
   Digest Authentication  This is provided through out of band means to the
   device or user of not the device.  The same credentials used for SIP
   Digest authentication (e.g. authentication of SIP SUBSCRIBE and
   REGISTER requests) are used case in the HTTPS request.  Other URI schemes
   may be used, but example shown.
   (HRes)  Changes are not defined in this document.  A non-replayable
   authentication mechanism such as Digest authentication MUST be used
   for the content indirection URI scheme which provides accepted by the profile
   data (e.g.  LDAP, HTTP and HTTPS all support Digest authentication).
   URI schemes which provide no authentication or only clear-text
   authentication SHOULD NOT be used for profile delivery as they are
   vulnerable to replay attacks (e.g.  TFTP does not provide
   authentication).

      Without server
   (A-NT)  PDS transmits a suitable authentication mechanism, the content
      indirection profile delivery URI scheme is susceptible NOTIFY message to replay
      attacks.  Even if Client A indicating the profile
      changed profile.  A sample message is symmetrically encrypted, if it
      can be retrieved through a replay attack, the encrypted profile
      can be used for offline attacks to crack the encryption key.

   The profile delivery scheme MUST use channel security such as TLS
   (e.g.  HTTPS) to protect the content from being snooped in transport
   to the user agent.  Mutual authentication using shown below:
         Note: Some of the client and server
   certificates MAY be used fields (for example, Via) are continued on a
         separate line due to verify the authenticity format constraints of this document
   NOTIFY sip:userX@10.1.1.44 SIP/2.0
   Event: ua-profile;effective-by=3600
   From: sip:userX@sip.example.net;tag=abcd
   To: sip:userX@sip.example.net.net;tag=1234
   Call-ID: 3573853342923422@10.1.1.44
   CSeq: 322 NOTIFY
   Via: SIP/2.0/UDP 192.168.0.3;
     branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d1
   MIME-Version: 1.0
   Content-Type: message/external-body; access-type="URL";
                 expiration="Mon, 01 Jan 2010 09:00:00 UTC";
                 URL="http://www.example.com/user-x-profile.html";
                 size=9999
                 hash=123456789AAABBBCCCDD
   .
   .
   .

   (A-RS)  Client A accepts the user or
   device identity NOTIFY and the profile delivery server identity.  The user
   agent SHOULD provide sends a mechanism for the user 200 OK
   (B-NT)  PDS transmits a NOTIFY message to approve the
   SUBSCRIBE server identity or provision Client B indicating the acceptable server identity
   through out
      changed profile.  A sample message is shown below:
         Note: Some of band means.

10.3.  Integrity protection for non-confidential profiles

   Even for non-confidential profiles, the subscriber MUST verify the
   authenticity fields (for example, Via) are continued on a
         separate line due to format constraints of this document

   NOTIFY sip:userX@10.1.1.43 SIP/2.0
   Event: ua-profile;effective-by=3600
   From: sip:userX@sip.example.net;tag=abce
   To: sip:userX@sip.example.net.net;tag=1235
   Call-ID: 3573853342923422@10.1.1.43
   CSeq: 322 NOTIFY
   Via: SIP/2.0/UDP 192.168.0.3;
     branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d2
   MIME-Version: 1.0
   Content-Type: message/external-body; access-type="URL";
                 expiration="Mon, 01 Jan 2010 09:00:00 UTC";
                 URL="http://www.example.com/user-x-profile.html";
                 size=9999
                 hash=123456789AAABBBCCCDD
   .
   .
   .

   (B-RS)  Client B accepts the profile delivery server, NOTIFY and MUST verify that sends a 200 OK
   (A-RX)  Client A retrieves the
   integrity of updated profile pertaining to User X
   (B-RX)  Client B retrieves the updated profile data pertaining to User X

8.  IANA Considerations

   There are two IANA considerations associated with this document, SIP
   Event Package and content indirection URI, if one is
   provided.  To meet these requirements HTTP header.  These are outlined in the SIP messaging the NOTIFY
   request MUST use a this section.

8.1.  SIP Identity header [I-D.ietf-sip-identity], or
   S/MIME.  If content is provided via redirection, the content
   indirection "hash" parameter MUST be included unless the profile data
   is delivered via Event Package

   This specification registers a protocol which natively provides authentication
   and message integrity, such new event package as HTTP or LDAP protected by TLS.  The
   content retrieved via the content indirection URI MUST be integrity
   checked using the "hash" parameter.

   For example, Alice subscribes to the local domain profile defined in
   [RFC3265].  The following information required for
   paris.example.com.  She receives a NOTIFY request which uses content
   indirection, including this registration:

      Package Name: ua-profile
      Package or Template-Package: This is a "hash" parameter.  Alice uses package
      Published Document: RFC XXXX (Note to RFC Editor: Please fill in
      XXXX with the Identity RFC number of this specification).
      Persons to Contact: Daniel Petrie dan.ietf AT SIPez DOT com,
      sumanth@cablelabs.com
      New event header from parameters: profile-type, vendor, model, version,
      effective-by, network-user (the profile-type parameter has
      predefined values.  The new event header parameters do not)
   The following table illustrates the NOTIFY additions to verify that the request came from
   paris.example.com and that the body was not modified.  Then she
   fetches the content at the provided URI IANA SIP Header
   Field Parameters and verifies that the hash
   she calculates from the profile matches the hash provided Parameter Values: (Note to RFC Editor: Please
   fill in the SIP
   signaling.

10.4.  Initial Enrollment Using a Manufacturer's Certificate

   A UA XXXX with a manufacturer certificate can use this certificate for
   initial enrollment into the configuration framework.  In order to
   safely deploy this scenario, the profile delivery server MUST
   maintain a list RFC number of enrolled devices and this specification)

                                                  Predefined
   Header Field                  Parameter Name     Values     Reference
   ----------------------------  ---------------   ---------   ---------
   Event                         profile-type      Yes         [RFCXXXX]
   Event                         vendor            No          [RFCXXXX]
   Event                         model             No          [RFCXXXX]
   Event                         version           No          [RFCXXXX]
   Event                         effective-by      No          [RFCXXXX]
   Event                         network-user      No          [RFCXXXX]

8.2.  New HTTP Event Header

   This document defines a separate list new permanent HTTP request header field:
   Event.
      Header field name: Event
      Applicable protocol: http
      Status: standard
      Author/Change controller: IETF
      Specification document(s): [RFCXXXX] (Note to RFC Editor: Please
      fill in XXXX with the RFC number of devices
   which it expects this specification).

9.  Security Considerations

   The framework specified in this document allows Service Providers to enroll.

   When the device sends a subscription request
   propagate profile data to the notifier, the
   notifier extracts the device-id from the user part of the Request URI
   and checks if the device Clients.  This is expected accomplished by requiring
   deployed Clients to enroll.  If implement the device framework.  The framework
   (explained in Section 5) specifies a Profile Life Cycle that allows
   Clients to request and obtain profile data.  The Profile Life Cycle
   is
   expected, the notifier provides enabled using an https: URL to Event Package (defined in Section 6) as per
   [RFC3265].  Thus, the subscriber primary components requiring security
   considerations are: Event Package, Profile Life Cycle and
   uses Profile
   Data.  The considerations, requirements and recommendations are
   presented in the SIP Identity mechanism following sub-sections.

9.1.  Event Package

   The Event Package usage MUST adhere to protect the integrity security considerations
   and requirements (access control, Notifier privacy mechanism, Denial-
   of-Service attacks, replay attacks, and Man-in-the Middle attacks)
   specified in Section 5 of [RFC3265].  Specifically for the Event
   Package defined in this URL.
   This URL framework, this sub-section hightlights
   additional considerations and security requirements.

   The Notifier MUST contain enough information that the profile content
   server can correlate a authenticate any SUBSCRIBE request to this URL with the device-id that
   was in the subscription.

   The subscriber then establishes a TLS connection known
   identity.  It MUST NOT accept any SUBSCRIBE requests that fail an
   authentication challenge.  Refer to the profile
   content server [I-D.ietf-sip-identity] and performs ordinary
   [RFC3261] for RECOMMENDED SIP authentication of the server
   certificate.  During the TLS handshake, the profile content server
   requests the certificate of the subscriber.  The subscriber provides
   its device certificate.  Typically this certificate is created by the
   manufacturer of the device.  If no client certificate is provided, methods.

   Unless configured otherwise, the profile content server Notifier SHOULD return a 403 Forbidden response.

   Next the profile content server checks the client certificate
   according NOT respond to the following steps:
   1.  The client certificate MUST be valid, and MUST
   SUBSCRIBEs without an identity that can be rooted in authenticated.  Exceptions
   include deployments catering to unknown Clients (for example, for
   self-subscription) or for troubleshooting (for example, credentials
   misplaced by a
       certificate authority that the administrator of the user).  Refer to Section 9.3 for Profile Data
   considerations in such cases.

   The Notifier MUST transmit NOTIFY messages with sensitive profile
       content server trusts
   data over an authenticated, integrity protected channel.  Refer to assert a valid "enrollment identity",
   Section 9.3 for example a MAC address, serial number, or device-id.
   2.  The information on profile data classification.  It
   SHOULD transmit Content Indirection information (without profile
   data) over an integrity-protected channel, unless configured
   otherwise (for example, if the Service Provider is catering to
   unknown Clients).  For data provided via content server indirection,
   Subscribers MUST verify that implement the device-id
       provided hash verification scheme described in
   [RFC4483].

   Subscribers with the https: URL corresponds ability to the subject or
       subjectAltName of the client certificate, in an implementation
       specific way.  For authenticate a PDS (for example, the profile content server could
       extract the MAC address from the device-id
   Service Provider Certificates, mutual shared secrets) MUST employ
   such mechanisms prior to retrieving data.  This framework RECOMMENDS
   that Service Providers consider providing this ability to deployed
   Clients.

9.2.  Profile Life Cycle

   Profile Discovery involves various protocols such as DHCP and the certificate DNS
   that may provide unauthenticated information.  Thus, successful
   Profile Enrollment and compare them.  How device certificates subsequent Profile Notification with an
   authenticated PDS (for example, via mutual authentication) are arranged is not
       standardized at
   required to prevent threats such as impersonation or Denial of
   Service.  Given the time nature of this writing, these mechanisms and is outside to prevent service
   disruption due to such threats, the
       scope specification recommends caching
   of this document.
   3. retrieved profiles (see Section 5.4) by the Clients.  It also
   provides for multiple Profile Discovery mechanisms (based on Profile
   Types) which can minimally aid in thwarting security threats from
   individual mechanisms (for example, impersonated DNS).

   The profile content server SHOULD verify specification strongly RECOMMENDS that solutions implementing the issuer of
   Framework provide the
       certificate is expected and authorized Clients with the ability to assert recognize, mutually
   authenticate and establish integrity protected SIP communication
   channels (for example, mutual TLS using certificates).  Clients
   without such an enrollment
       identity for this type of device.  In other words, the ability SHOULD report changes to sensitive profile
       content server should not allow acme.example
   data (refer to Profile Data) using suitable mechanisms (for example,
   management reporting).  Further, Clients with access to assert an
       enrollment identity for credentials
   (even if obtained via a device manufactured by rival company
       widgets.example.
   4.  The profile content server User Interface) MUST verify that the device referred respond to by
   authentication challenges.

   Profile Enrollment and Profile Notification are done via the device-id is not already enrolled.
   5.  The profile content server MUST verify that Event
   Package definition and the device referred
       to by security requirements have been presented
   in Section 9.1.  Profile Retrieval and Profile Change Upload are
   accomplished using Profile Data Frameworks and are addressed in
   Section 9.3.

9.3.  Profile Data

   Profile data provided using any of the device-id Profile Types is expected to enroll at the current time.
       Typically, an administrator would configure a time-window of
       hours
   happen via suitable Profile Data Framework (such as XCAP) or days during which a new device can enroll.

   If the profile content server successfully performs all these steps,
   it provides an initial device profile to the subscriber in the body
   of the HTTP response.  This initial device profile MUST contain new
   credentials suitable
   protocol (such as HTTP).  Data defined using such frameworks may be
   sensitive (for example, credentials for Digest authentication) that
   the subscriber can use for subsequent authentication.  Integrity and
   confidentiality user credentials) or non-sensitive (for
   example, list of the new DNS servers).

   If a profile is contains sensitive data, it MUST be provided since over a
   mutual-authenticated, integrity protected channel.  Even if the response data
   is
   sent non-sensitive, it SHOULD still be provided over a TLS secure channel.  If one of
   Exceptions include cases where deployments cater to unknown Clients
   or for troubleshooting.

   For profile data delivered within the verification steps above
   fails, framework (i.e. data is
   provided in the profile content server sends a 403 Forbidden response.

   Entities other than NOTIFY), the requirements specified in Section 9.1.

   When the profile data is delivered via content server do not accept
   manufacturer device certificates to secure ordinary communications,
   such as SIP TLS or SIP S/MIME.

11. indirection,
   authentication, integrity, confidentiality MUST be provided by the
   Profile Data Frameworks containing the retrieval mechanisms.
   Further, a non-replayable authentication mechanism (for example,
   Digest authentication) MUST be used.

10.  Acknowledgements

   Many thanks to those who contributed and commented on the many
   iterations of this document.  Detailed input was comments were provided by the
   following individuals: Jonathan Rosenberg from Cisco, Henning
   Schulzrinne from Columbia University, Cullen Jennings from Cisco,
   Rohan Mahy from Plantronics, Rich Schaaf from Pingtel, Volker Hilt
   from Bell Labs, Adam Roach of Estacado Systems, Hisham Khartabil from
   Telio, Henry Sinnreich from MCI, Martin Dolly from AT&T Labs, John Elwell from Siemens, Elliot Eichen Dolly from AT&T Labs, John
   Elwell from Siemens, Elliot Eichen and Robert Liao from Verizon, Dale
   Worley from Pingtel, Francois Audet from Nortel, Roni Even from
   Polycom, Jason Fischl from Counterpath, Josh Littlefield from Cisco,
   Nhut Nguyen from Samsung.

   The editor would like to extend a special thanks to the experts who
   contributed to the restructuring and revisions as proposed by the
   SIPPING WG, specifically Keith Drage from Lucent (restructuring
   proposal), Peter Blatherwick from Mitel (who also contributed to the
   Overview and Introduction sections), Josh Littlefield from Cisco
   (examples and diagram suggestions), Alvin Jiang of Engin, Martin
   Dolly from AT&T, and Jason Fischl from Counterpath.  Additionally,
   sincere appreciation is extended to the chairs (Mary Barnes from
   Nortel and Gonzalo Camarillo from Ericsson) and the Area Directors
   (Cullen Jennings from Cisco and Jon Peterson and Cisco) for
   facilitating discussions, and for reviews and contributions.

11.  Open Items

   [[Editor's note: This is being used a place holder only and will be
   removed once the items listed are addressed]]

   The following comments are considered to be open (i.e. not addressed)
   in this version of the I-D
   o  Replace 'Service Provider' with a term better representative of
      its definition
   o  Analyze potential unformity in the formation of the Subscription
      URI across Profile Types.  If not, provide a bried explanation of
      the analysis
   o  Analyze the current SHOULD v/s MUST requirements for the Profile
      Framework to obtain consensus and facilitate interoperability
   o  Present an analysis of the Local Network Profile discovery methods
      in DNS-less environments
   o  Check on potentially referencing RFC4122 instead of OUTBOUND
   o  Security Considerations requires further review

12.  Change History

   [[RFC Editor: Please remove this entire section upon publication as
   an RFC.]]

12.1.  Changes from draft-ietf-sipping-config-framework-09.txt

   Following the ad-hoc SIPPING WG discussions at IETF#67 and as per the
   email from Gonzalo Camarillo dated 12/07/2006, Sumanth was appointed
   as the new editor.  This sub-section highlights the changes made by
   the editor (as per expert recommendations from the SIPPING WG folks
   interested in this effort) and the author.

   Changes incorporated by the editor:
   o  Document was restructured based on a) Keith's recommendations in
      the email dated 11/09/2006 and responses (Peter, Sumanth, Josh) b)
      subsequent discussions by the ad-hoc group consisting of the
      editor, the author, expert contributors (Peter Blatherwick, Josh
      Littlefield, Alvin Jiang, Jason Fischl, Martin Dolly, Cullen
      Jennings) and Robert Liao from Verizon, Dale Worley from Pingtel, Francois
   Audet from Nortel, Roni Even the co-chairs .  Further changes follow.
   o  Use cases were made high-level with detailed examples added later
      on
   o  Several sections were modified as part of the restructuring (for
      example, Overview, Introduction, Framework Requirements, Security
      Sections)
   o  General editorial updates were made

   Changes incorporated by the author:

   o  Incorporated numerous edits and corrections from Polycom, Jason Fischl CableLabs review.
   o  Used better ascii art picture of overview from
   Counterpath.

12.  Change History

   [[RFC Editor: Please remove this entire section upon publication as
   an RFC.]]

12.1. Josh Littlefield
   o  Fixed the normative text for network-user so that it is now
      consistant: MAY provide for device profile, MUST provide for
      local-network profile.

12.2.  Changes from draft-ietf-sipping-config-framework-08.txt

      The request Request URI for profile-type=localnet now SHOULD not have a
      user part to make routing easier.  The From field SHOULD now
      contain the device id so that device tracking can still be done.
      Described the concept of profile-type as a filter and added
      normative text requiring 404 for profile types not provided.
      Moved "application" profile type to
      draft-ietf-sipping-xcap-config-01.  The "application" value for
      the profile-type parameter will also be used as a requirement that
      XCAP be supported.
      Fixed text on certificate validation.
      Added new HTTP header: Event to IANA section and clean up the IANA
      section.
      Added diagram for service provider Service Provider use case schenario.
      Added clarification for HTTP Event header.
      Added clarification of subscriber handling of NOTIFY with no body.

12.2.

12.3.  Changes from draft-ietf-sipping-config-framework-07.txt

      Made XCAP informative reference.  Removed "document" and "auid"
      event header parameters, and Usage of XCAP section to be put in
      separate supplementary draft.
      Fixed ABNF for network-user to be addr-spec only (not name-addr)
      and to be quoted as well.
      Synchronized with XCAP path terminology.  Removed XCAP path
      definition as it is already defined in XCAP.
      User agent instance ID is now defined in output (not GRUU).
      Clarified the rational for the network-user parameter.
      Added text to suggest URIs for To and From fields.
      Clarified use of network-user parameter.
      Allow the use of the auid and document parameters per request by
      the OMA.

12.3.

12.4.  Changes from draft-ietf-sipping-config-framework-06.txt

      Restructured the introduction and overview section to be more
      consistent with other Internet-Drafts.
      Added additional clarification for the Digest Authentication and
      Certificate based authentication cases in the security section.
      Added two use case scenarios with cross referencing to better
      illustrate how the framework works.  Added better cross
      referencing in the overview section to help readers find where
      concepts and functionality is defined in the document.

      Clarified the section on the use of XCAP.  Changed the Event
      parameter "App-Id" to "auid".  Made "auid" mutually exclusive to
      "document". "auid" is now only used with XCAP.
      Local network subscription URI changed to <device-id>@
      <local-network> (was anonymous@<local-network>).  Having a
      different request Request URI for each device allows the network
      management to track user agents and potentially manage bandwidth,
      port allocation, etc.
      Changed event package name from sip-profile to ua-profile per
      discussion on the list and last IETF meeting.
      Changed "local" profile type token to "local-network" per
      discussion on the list and last IETF meeting.
      Simplified "Vendor", "Model", "Version" event header parameters to
      allow only quoted string values (previously allowed token as
      well).
      Clarified use of the term cache.
      Added references for ABNF constructs.
      Numerous editorial changes.  Thanks Dale!

12.4.

12.5.  Changes from draft-ietf-sipping-config-framework-05.txt

      Made HTTP and HTTPS profile transport schemes mandatory in the
      profile delivery server.  The subscribing device must implement
      HTTP or HTTPS as the profile transport scheme.
      Rewrote the security considerations section.
      Divided references into Normative and Informative.
      Minor edits throughout.

12.5.

12.6.  Changes from draft-ietf-sipping-config-framework-04.txt

      Clarified usage of instance-id
      Specify which event header parameters are mandatory or optional
      and in which messages.
      Included complete list of event header parameters in parameter
      overview and IANA sections.
      Removed TFTP reference as protocol for profile transport.
      Added examples for discovery.
      Added ABNF for all event header parameters.
      Changed profile-name parameter back to profile-type.  This was
      changed to profile-name in 02 when the parameter could contain
      either a token or a path.  Now that the path is contained in the
      separate parameter: "document", profile-type make more sense as
      the parameter name.
      Fixed some statements that should have and should not have been
      normative.
      Added the ability for the user agent to request that the default
      user associated with the device be set/changed using the "network-
      user" parameter.

      A bunch of editorial nits and fixes.

12.6.

12.7.  Changes from draft-ietf-sipping-config-framework-03.txt

   Incorporated changes to better support the requirements for the use
   of this event package with XCAP and SIMPLE so that we can have one
   package (i.e. simple-xcap-diff now defines a content type not a
   package).  Added an additional profile type: "application".  Added
   document and app-id Event header parameters in support of the
   application profile.  Define a loose high level data model or
   relationship between the four profile types.  Tried to edit and fix
   the confusing and ambiguous sections related to URI formation and
   discovery for the different profile types.  Better describe the
   importance of uniqueness for the instance id which is used in the
   user part of the device URI.

12.7.

12.8.  Changes from draft-ietf-sipping-config-framework-02.txt

   Added the concept of the local network as a source of profile data.
   There are now three separate logical sources for profile data: user,
   device and local network.  Each of these requires a separate
   subscription to obtain.

12.8.

12.9.  Changes from draft-ietf-sipping-config-framework-01.txt

   Changed the name of the profile-type event parameter to profile-name.
   Also allow the profile-name parameter to be either a token or an
   explicit URI.

   Allow content indirection to be optional.  Clarified the use of the
   Accept header to indicate how the profile is to be delivered.

   Added some content to the Iana section.

12.9.

12.10.  Changes from draft-ietf-sipping-config-framework-00.txt

   This version of the document was entirely restructured and re-written
   from the previous version as it had been micro edited too much.

   All of the aspects of defining the event package are now organized in
   one section and is believed to be complete and up to date with
   [RFC3265].

   The URI used to subscribe to the event package is now either the user
   or device address or record.

   The user agent information (vendor, model, MAC and serial number) are
   now provided as event header parameters.

   Added a mechanism to force profile changes to be make effective by
   the user agent in a specified maximum period of time.

   Changed the name of the event package from sip-config to ua-profile

   Three high level security approaches are now specified.

12.10.

12.11.  Changes from draft-petrie-sipping-config-framework-00.txt

   Changed name to reflect SIPPING work group item

   Synchronized with changes to SIP DHCP [RFC3361], SIP [RFC3261] and
   [RFC3263], SIP Events [RFC3265] and content indirection [I-D.ietf-
   sip-content-indirect-mech] [RFC4483]

   Moved the device identity parameters from the From field parameters
   to User-Agent header parameters.

   Many thanks to Rich Schaaf of Pingtel, Cullen Jennings of Cisco and
   Adam Roach of Estacado Systems for the great comments and input.

12.11.

12.12.  Changes from draft-petrie-sip-config-framework-01.txt

   Changed the name as this belongs in the SIPPING work group.

   Minor edits

12.12.

12.13.  Changes from draft-petrie-sip-config-framework-00.txt

   Split the enrollment into a single SUBSCRIBE dialog for each profile.
   The 00 draft sent a single SUBSCRIBE listing all of the desired.
   These have been split so that each enrollment can be routed
   differently.  As there is a concept of device specific and user
   specific profiles, these may also be managed on separate servers.
   For instance in a nomadic situation the device might get its profile
   data from a local server which knows the LAN specific profile data.
   At the same time the user specific profiles might come from the
   user's home environment profile delivery server.

   Removed the Config-Expires header as it is largely superfluous with
   the SUBSCRIBE Expires header.

   Eliminated some of the complexity in the discovery mechanism.

   Suggest caching information discovered about a profile delivery
   server to avoid an avalanche problem when a whole building full of
   devices powers up.

   Added the User-Profile From header field parameter so that the device
   can request a user specific profile for a user that is different from
   the device's default user.

13.  References

13.1.  Normative References

   [I-D.ietf-sip-content-indirect-mech]
              Burger, E., "A Mechanism for Content Indirection in
              Session Initiation Protocol (SIP)  Messages",
              draft-ietf-sip-content-indirect-mech-05 (work in
              progress), October 2004.

   [I-D.ietf-sip-identity]
              Peterson, J. and C. Jennings, "Enhancements for
              Authenticated Identity Management in the Session
              Initiation  Protocol (SIP)", draft-ietf-sip-identity-06
              (work in progress), October 2005.

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

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

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

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

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

   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263,
              June 2002.

   [RFC3265]  Roach, A., "Session Initiation Protocol (SIP)-Specific
              Event Notification", RFC 3265, June 2002.

   [RFC3361]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCP-for-IPv4) Option for Session Initiation Protocol
              (SIP) Servers", RFC 3361, August 2002.

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122,
              July 2005.

   [RFC4483]  Burger, E., "A Mechanism for Content Indirection in
              Session Initiation Protocol (SIP) Messages", RFC 4483,
              May 2006.

13.2.  Informative References

   [I-D.ietf-simple-xcap]
              Rosenberg, J., "The Extensible Markup Language (XML)
              Configuration Access Protocol (XCAP)",
              draft-ietf-simple-xcap-11
              draft-ietf-simple-xcap-12 (work in progress), May
              October 2006.

   [I-D.ietf-simple-xcap-diff]
              Rosenberg, J., "An Extensible Markup Language (XML)
              Document Format for Indicating A Change  in XML
              Configuration Access Protocol (XCAP) Resources",
              draft-ietf-simple-xcap-diff-03 (work in progress),
              October 2006.

   [I-D.ietf-sip-outbound]
              Jennings, C. and R. Mahy, "Managing Client Initiated
              Connections in the Session Initiation Protocol  (SIP)",
              draft-ietf-sip-outbound-04 (work in progress), June 2006.

   [I-D.ietf-sipping-ua-prof-framewk-reqs]
              Petrie, D. and C. Jennings, "Requirements for SIP User
              Agent Profile Delivery Framework",
              draft-ietf-sipping-ua-prof-framewk-reqs-00 (work in
              progress), March 2003.

   [I-D.petrie-sipping-profile-datasets]
              Petrie, D., "A Schema and Guidelines for Defining Session
              Initiation Protocol User Agent  Profile Data Sets",
              draft-petrie-sipping-profile-datasets-03 (work in
              progress), October 2005.

   [I-D.sinnreich-sipdev-req]
              Sinnreich, H., "SIP Telephony Device Requirements and
              Configuration", draft-sinnreich-sipdev-req-08 Resources",
              draft-ietf-simple-xcap-diff-04 (work in progress),
              October 2005.

   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982. 2006.

   [RFC0959]  Postel, J. and J. Reynolds, "File Transfer Protocol",
              STD 9, RFC 959, October 1985.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

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

   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

   [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
              Protocol (v3): Technical Specification", RFC 3377,
              September 2002.

   [W3C.REC-xml-names11-20040204]
              Hollander, D., Tobin, R., Bray, T.,

   [RFC3617]  Lear, E., "Uniform Resource Identifier (URI) Scheme and A. Layman,
              "Namespaces in XML 1.1", World Wide Web Consortium
              FirstEdition REC-xml-names11-20040204, February 2004,
              <http://www.w3.org/TR/2004/REC-xml-names11-20040204>.

Author's Address
              Applicability Statement for the Trivial File Transfer
              Protocol (TFTP)", RFC 3617, October 2003.

Authors' Addresses

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

   Phone: "+1 617 273 4000
   USA

   Email: dan.ietf AT SIPez DOT com
   URI:   http://www.SIPez.com/
   Sumanth Channabasappa (Editor)
   CableLabs
   858 Coal Creek Circle
   Louisville, Co  80027
   USA

   Email: sumanth@cablelabs.com
   URI:   http://www.cablelabs.com/

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

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

Intellectual Property 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 (2006).  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. IETF
   Administrative Support Activity (IASA).