SIPPING D. Petrie
Internet DraftInternet-Draft Pingtel Corp. draft-ietf-sipping-config-framework-00.txtExpires: Aug 2003 FebApril 21, 2004 October 22, 2003 A Framework for SIP User Agent ConfigurationProfile Delivery draft-ietf-sipping-config-framework-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts.Internet-Drafts. 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.txthttp:// 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 21, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines the application of a set of protocols for configuring a SIP user agent. Theproviding profile data to SIP user agent must discover how and from where to retrieve its initial configuration and be notified of changes and updates which impact its configuration.agents. The objective is to define a means for automatically configuringproviding profile data a user agent such that it canneeds to be functional without user or administrative intervention. The framework for discovery, delivery, notification and updates of user agent configurationprofile data is defined here. As part of this framework a new SIP event package is defined here for the notification of profile changes. This framework is also intended to ease ongoing administration, configurationadministration and upgrading of large scale deployments of SIP user agents. The contents and format of the configurationprofile data to be defined is outside the scope of this document. Petrie Informational - Expires Aug 2003 1 A Framework for SIP Feb. 2003 User Agent ConfigurationTable of Contents Status of this Memo................................................1 Abstract...........................................................1 1 Overview.......................................................3 2 Conventions used in this document..............................41. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 Changes from Previous Draft....................................4 3.1 Changes from draft-petrie-sipping-config-framework-00.txt....4 3.2 Changes from draft-petrie-sip-config-framework-01.txt........4 3.3 Changes from draft-petrie-sip-config-framework-00.txt........4 4 Discovery......................................................5 4.1 DHCP Option..................................................6 4.2 DNS..........................................................6 4.3 Multicast....................................................7 4.4 Manually Provisioned.........................................7 5 Enrollment and Change Notification.............................7 5.1 SUBSCRIBE....................................................8 5.1.1 Additional User Agent Field Parameters......................9 5.2 NOTIFY......................................................10 5.2.1 NOTIFY Body Content Format.................................11 6 Configuration Retrieval.......................................11 7 Configuration Upload..........................................11 8 Examples......................................................12 8.1 Example Message Flows.......................................12 8.2 Example Messages............................................14 9 Security Considerations.......................................17 10 Open Issues...................................................18 11 References....................................................19 12 Author's Address..............................................20 Petrie Informational - Expires Aug. 2003 2 A2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Requirements Terminology . . . . . . . . . . . . . . . . . . 3 2.2 Profile Delivery Framework for SIP Feb. 2003 User Agent Configuration 1Terminology . . . . . . . . . . . 4 2.3 Overview Today all SIP UA vendors use proprietary means of delivering configuration to the UA. This configuration framework is intended to enable a first phase migration to a standard means of configuring SIP user. . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Profile Change Event Notification Package . . . . . . . . . 5 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . . 6 3.2 Event Package Parameters . . . . . . . . . . . . . . . . . . 6 3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . 7 3.4 Subscription Duration . . . . . . . . . . . . . . . . . . . 7 3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 8 3.6 Notifier processing of SUBSCRIBE requests . . . . . . . . . 8 3.7 Notifier generation of NOTIFY requests . . . . . . . . . . . 9 3.8 Subscriber processing of NOTIFY requests . . . . . . . . . . 10 3.9 Handling of forked requests . . . . . . . . . . . . . . . . 10 3.10 Rate of notifications . . . . . . . . . . . . . . . . . . . 10 3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . . 10 3.12 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.13 Use of URIs to Retrieve State . . . . . . . . . . . . . . . 11 4. Profile Delivery Framework Details . . . . . . . . . . . . . 12 4.1 Discovery of Subscription URI . . . . . . . . . . . . . . . 12 4.2 Enrollment with Profile Server . . . . . . . . . . . . . . . 13 4.3 Notification of Profile Changes . . . . . . . . . . . . . . 13 4.4 Retrieval of Profile Data . . . . . . . . . . . . . . . . . 14 4.5 Upload of Profile Changes . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . 14 6.1 Symmetric Encryption of Profile Data . . . . . . . . . . . . 14 6.2 Client Certificate Authentication with HTTPS . . . . . . . . 15 6.3 HTTPS Authentication . . . . . . . . . . . . . . . . . . . . 15 7. Differences from Simple XCAP Package . . . . . . . . . . . . 15 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Change History . . . . . . . . . . . . . . . . . . . . . . . 16 9.1 Changes from draft-ietf-sipping-config-framework-00.txt . . 16 9.2 Changes from draft-petrie-sipping-config-framework-00.txt . 17 9.3 Changes from draft-petrie-sip-config-framework-01.txt . . . 17 9.4 Changes from draft-petrie-sip-config-framework-00.txt . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . 20 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . 21 1. Motivation Today all SIP user agent vendors use proprietary means of delivering user or device profiles to the user agent. The profile delivery framework defined in 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 vendors shouldwill be able to use this configurationframework as a means of delivering their existing proprietary configurationuser and device data profiles (i.e. using their existing proprietary binary or text formats). This in itself is a tremendous advantage in that a SIP environment can use a single configurationprofile delivery server to deliver configurationfor profile data to UAsuser agents from multiple vendors. Follow-on standardization activities can: 1)1. define a standard profile content format framework (e.g. XML with name spaces [??] or name-value pairs ) and 2)[RFC0822]). 2. specify the content (i.e. name the configuration parameters)profile data parameters, xml schema, name spaces) of the configurationdata profiles. ThisOne of the objectives of the framework described in this document definesis to provide a start up experience similar to that of users of an analog telephone. When you plug in an analog telephone it just works (assuming the line is live and the switch has been provisioned). There is no end user configuration required to make analog phone work (at least in a basic sense). So the objective here is to be able to take a new SIP user agent out of the box, plug it in (or install the software) and have it get its profiles without human intervention (other than security measures). This is necessary for cost effective deployment of large numbers of user agents. Another objective is to provide a scalable means for on going administration of profiles. Administrators and users are likely to want to make changes to user and device profiles. Additional requirements for the framework which allowsdefined in this document are described in: [I-D.ietf-sipping-ua-prof-framewk-reqs], [I-D.sinnreich-sipdev-req] 2. Introduction 2.1 Requirements Terminology Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in RFC 2119[RFC2119]. 2.2 Profile Delivery Framework Terminology profile - data set specific to a user or device. device - SIP user agents (UA)agent, either software or hardware appliance. profile content server - The server that provides the content of the profiles using the protocol specified by the URL scheme. notifier - The SIP user agent server which processes SUBSCRIBE requests for events and sends NOTIFY requests with profile URL(s). profile delivery server - The logical collection of the SIP notifier and the server which provides the contents of the profile URL(s). 2.3 Overview The profile life cycle can be described by five functional steps. These steps are not necessarily discrete. However it is useful to automatically:describe these steps as logically distinct. These steps are named as follows: Discovery - discover a configurationprofile delivery server (Discovery)Enrollment - enroll with the configurationprofile delivery server (Enrollment)Profile Retrieval - retrieve configurationprofile data (Configuration Retrieval)Profile Change Notification - receive notification of configurationprofile changes (Change Notification)Profile Change Upload - upload configurationprofile data changes back to the server (Configuration Upload) The content and format of the data is not defined in this document. It will be defined in configuration data profile(s) in other document(s). The goal of this framework is to satisfy the requirements for configuration delivery defined in ,  and  explicitly excluding the requirements which pertain to configuration dataprofile content and format.delivery server Discovery is the process by which a UA SHOULD find the address and port at which it SHOULD enroll with the configurationprofile 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 SHOULD try them until one succeeds. Enrollment is the process by which a UA SHOULD make itself known to the configuration server. In enrolling the UA MUST provide identity information, name requested configuration data profile and supported protocols for configuration retrieval. It SHOULD also SUBSCRIBE to a mechanism for notification of configuration changes. As a result of enrollment, the UA receives a URL for each of the configuration data profiles that the configuration server is able to provide. Each profile requires a separate enrollment or SUBSCRIBE session. Configuration Retrieval is the process of retrieving the content for each of the configuration data profiles the UA requested. Petrie Informational - Expires Aug. 2003 3 A Framework for SIP Feb. 2003 User Agent Configuration Change Notification is the process by which the configuration server notifies the UA that the content of one or more of the configuration data profiles has changed. Subsequently the UA SHOULD retrieve the data profile from the specified URL upon receipt ofare defined with a prescribed order in which the change notification. Configuration UploadUA SHOULD try them until one succeeds. Enrollment is the process by which a UA or other entity pushes a change to a configuration data profile back upSHOULD make itself known to the configurationprofile delivery server. 2 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 . The syntax and semantics used here extend those defined in SIP (RFC 2543) . SIP is described in an augmented Backus-Naur form (ABNF). See [6, section C] for an overview of ABNF. 3 Changes from Previous Draft 3.1 Changes from draft-petrie-sipping-config-framework-00.txt Changed name to reflect SIPPING work group item Updated with changes to SIP DHCP , SIP , SIP Events  and content indirection . MovedIn enrolling the deviceUA MUST provide identity parameters from the From field parameters to User-Agent header parameters. Many thanks to Rich Schaaf of Pingtel, Cullen Jennings of Ciscoinformation, name requested profile type(s) and Adam Roach of Dyamicsoftsupported protocols for the great comments and input. 3.2 Changes from draft-petrie-sip-config-framework-01.txt Changed the name as this belongs in the SIPPING work group. Minor edits 3.3 Changes from draft-petrie-sip-config-framework-00.txt Many thanksprofile retrieval. It SHOULD also subscribe to those who contributed and commented on the previous draft. Detailed comments were provided by Henning Schulzrinne from Columbia U., Cullen Jennings from Cisco, Rohan Mahy from Cisco, Rich Schaaf from Pingtel. Splita mechanism for notification of profile changes. As a result of enrollment, the enrollment intoUA receives a single SUBSCRIBE dialogURL for each profile. The 00 draft sentof the profiles that the profile delivery server is able to provide. Each profile type (set) requires a singleseparate enrollment or SUBSCRIBE listing allsession. Profile Retrieval is the process of retrieving the desired. These have been split so thatcontent for each enrollment can be routed differently. As there is a conceptof device specific and Petrie Informational - Expires Aug. 2003 4 A Framework for SIP Feb. 2003 User Agent Configuration user specific profiles, these may also be managed on separate servers. For instance in a roaming situationthe device might get itĂs configuration from a local serverprofiles the UA requested. Profile Change Notification is the process by which knowsthe LAN specific configuration. Atprofile delivery server notifies the same timeUA that the content of one or more of the user specificprofiles might come fromhas changed. Subsequently the userĂs home environment configuration server.' RemovedUA SHOULD retrieve the Config-Expires header as it is largely superfluous withprofile from the SUBSCRIBE Expires header. Eliminated somespecified URL upon receipt of the complexity inchange notification. Profile Upload is the discovery mechanism. Suggest caching information discovered aboutprocess by which a UA or other entity (e.g. OSS, corporate directory or configuration server to avoid an avalanche problem whenmanagement server) pushes a whole building full of devices powers up. Addedchange to the User-Profile From header field parameter so thatprofile data back up to the device can a requestprofile delivery server. This framework defines a user specificnew SIP event package [RFC3265] to solve enrollment and profile change notification steps. The question arises as to why SIP should be used for a user thatthe profile delivery framework. In this document SIP is different fromused for only a small portion of the deviceĂs default user. 4 Discovery The purposeframework. Other existing protocols are more appropriate for transport of discovery is to figure out how to addressthe configuration server so thatprofile contents (upstream and downstream of the device can enroll.user agent) and are suggested in this document. The enrollment process involves sendingdiscovery step is simply a specified order and application of existing protocols. SIP SUBSCRIBE. Prior to thisis only needed for the discovery process must findenrollment and change notification functionality of the addressprofile delivery framework. In many SIP environments (e.g. carrier/subscriber and multi-site enterprise) firewall, NAT and IP addressing issues make it difficult to use in the URL forget messages between the URIprofile delivery server and To header field. The URL SHOULD usethe user id: sipuaconfig. From aagent requiring the profiles. With SIP perspectivethe configuration server is simply a user agent. By usingusers and devices already are assigned globally routable addresses. In addition the well knownfirewall and NAT problems are already presumably solved in the environments in which SIP user id, this makes it easy for proxy serversagents are to be provisioned to route the enrollment requests from devices toused. Therefore SIP is the appropriate configuration serverbest solution for allowing the domain. The first time a UA is plugged in it does not know the address or port at whichuser agent to enroll with the local configuration server. It must discover this address and port. A UA SHOULD support allprofile delivery server which may require traversal of multiple firewalls and NATs. For the listed discovery mechanisms. It MUST support at least onesame reason the notification of them. Onceprofile changes is best solved by SIP. It is assumed that the UA has discoveredcontent delivery server MUST be either in the addresspublic network or accessible through a DMZ. The user agents requiring profiles may be behind firewalls and portNATs and has successfully enrolled with the configuration server, the UA SHOULD cachemany protocols, such as HTTP, may be used for profile content retrieval without special consideration in the addressfirewalls and portNATs. A conscious separation of user and device profiles is made in this document. This is useful to avoid the needprovide features such as hoteling as well as securing or restricting user agent functionality. By maintaining this separation, a user may walk up to re-discoversomeone else's user agent and direct that user agent to get their profile data. In doing so the configuration server. However if enrollment, configuration retrieval or configuration upload fails at any time,user agent can replace the UA SHOULD applyprevious user's profile data while still keeping the discoverydevices profile data that may be necessary for core functionality and enrollment process again.communication described in this document. 3. Profile Change Event Notification Package This providessection defines a means for configuration server fail over and load balancing.new SIP event package [RFC3265]. The UA SHOULD use the following mechanismspurpose of this event package is to send to subscribers notification of content changes to discoverthe host addressprofile(s) of interest and port at which it SHOULD enroll withto provide the configuration server. Each mechanism should be tried inlocation of the following order until an address and portprofile(s) via content indirection [I-D.ietf-sip-content-indirect-mech]. 3.1 Event Package Name The name of this package is provided which results"sip-profile". This value appears in successful enrollment (i.e.the server responds with a successful 2xx class response): - DHCP optionEvent header field present in SUBSCRIBE and NOTIFY requests for SIP  - DNS A record - Multicast - Manual provisioning Petrie Informational - Expires Aug. 2003 5 A Frameworkthis package as defined in [RFC3265]. 3.2 Event Package Parameters This package defines the following new parameters for SIP Feb. 2003 User Agent Configurationthe event header: profile-type, vendor, model, version, effective-by. The rationaleeffective-by parameter is for this order follows. Assuming that most UAs are going touse DHCPin NOTIFY requests only. The others are for IP configuration anyway, using a DHCP option isuse in the least costlySUBSCRIBE request, but may be used in terms of lookup time (i.e. no additional messages are required). Hence DHCP is first. MulticastNOTIFY requests as well. The profile-type parameter is used last ofto indicate the automated discovery mechanisms as it isprofile type the most restricted in termsuser agent wishes to obtain URLs for and be notified of network environments that support it. Multicast is included, even thoughchange. This parameter allows the applicable environments are restricted,URL semantics to be opaque to the subscribing user agent as all it needs to know is the only mechanism that can be used without the supporttoken value for this parameter. This document defines two type categories of the local network administrator.profiles. The phone administrator andcontents or format of the network administratorprofiles is outside the scope of this document. The two types of profiles define here are often different people"user" and perhaps in different departments. The UA implementer MAY provide"device". Specifying device type profile(s) indicates the user or administrator withdesire for the means toURL(s) and change the order in which these mechanismsnotification of all profiles that are tried. This includes the abilityspecific to manually overridethe discovery process. However by default withoutdevice or user agent. Specifying user interactiontype profile(s) indicates the UA SHOULD usedesire for the order listed above. Once discovery is successfulURL(s) and change notification of all profile(s) that are specific to the user. The user or device SHOULD persistently cacheis identified in the address to avoid avalanche problems when a whole building fullURI of devices powers up at once.the SUBSCRIBE request. The characteristicAccept header of the SUBSCRIBE request MUST include the MIME types for all profile may dictate this behavior. For examplecontent types that the subscribing user agent wishes to retrieve profiles or receive change notifications. The user or device specifictoken in the profile-type parameter may represent a class or set of profiles as opposed to a single profile. As standards are defined for specific profile contents related to the user or device, it may needbe desirable to change whendefine additional tokens for the deviceprofile-type header. This is movedto allow a different location. Useruser agent to subscribe to that specific profiles may be independent ofprofile as opposed to the LAN, networkentire class or set of user or device location. 4.1 DHCP Option Itprofiles. The rational for the separation of user and device type profiles is likelyprovided in section Section 2.3. It should be noted that most UAseither type may indicate that zero or more URLs are provided in an deployment of any significant size will use DHCP for IP configuration. DHCP becomesthe NOTIFY request. As discussed, a convenient meansdefault user may be assigned to discovera device. In this scenario the configurationprofile delivery server address. Inmay provide the same DHCPURL(s) in the NOTIFY request for basic IP configuration, the UA can addthe option for SIP default user when subscribing to the options field. This indicatesdevice profile type. Effectively the device profile type becomes a requestsuperset of the user profile type subscription. The user type is still useful in this scenario to allow the user agent to obtain profile URLs for a user other than the default SIP proxy server address and port. For example ifuser. This provides the DHCP option for SIP returns an address of sip.acme.comability to support a hoteling function where a user may "login" to any user agent and have it use a portusers profile(s). The vendor, model and version parameters are tokens specified by the vendor of 5080,the following URL is constructed: sip:email@example.com:5080. Ifuser agent. These parameters are useful to the proxyprofile delivery server address and portto effect the profiles provided. In some scenarios it is not returneddesirable to provide different profiles based upon these parameters. For example feature parameter X in a profile may work differently on two versions of user agent. This gives the DHCP response or theprofile deliver server does not respond tothe enrollment request with a successful 2xx class response,ability to compensate for or take advantage of the next discovery mechanism is attempted. 4.2 DNSdifferences. The UA SHOULD construct a fully qualified host name using ˘sipuaconfig÷ as"effective-by" parameter in the Event header of the NOTIFY specifies the maximum number of seconds before the host anduser agent MUST make the local domain if defined. It SHOULD try a DNSnew profile effective. A record lookup onvalue of 0 (zero) indicates that the fully qualified host name. Ifuser agent MUST make the name resolves in DNS it should then attempt enrollment. For exampleprofiles effective immediately (despite possible service interruptions). This gives the URL constructed inprofile delivery server the local domain of acme.com would look like: sip:firstname.lastname@example.org. Ifpower to control when the server does not respondprofile is effective. This may be important to enrollment withresolve an emergency problem or disable a successful 2xx class response,user agent immediately. SUBSCRIBE request example: Event: sip-profile;profile-type=device; vendor=acme;model=Z100;version=1.2.3 NOTIFY request examples: Event:sip-profile;effective-by=0 Event:sip-profile;effective-by=3600 3.3 SUBSCRIBE Bodies This package defines no new use of the next discovery mechanismSUBSCRIBE request body. 3.4 Subscription Duration As profiles are generally static with infrequent changes, it is attempted. Petrie Informational - Expires Aug. 2003 6 A Framework for SIP Feb. 2003 User Agent Configuration 4.3 Multicastrecommended that default subscription duration be 86400 seconds (one day). 3.5 NOTIFY Bodies The enrollment requestsize of profile content is sentlikely to be hundreds to several thousand bytes in size. Frequently even with very modest sized SDP bodies, SIP messages get fragmented causing problems for many user agents. For this reason the multicast addressNOTIFY body MUST use content indirection [I-D.ietf-sip-content-indirect-mech] for SIP registration  "sip.mcast.net" (18.104.22.168). If a server does not respond with a successful 2xx class response toproviding the enrollment request,profiles. The profile delivery server MUST include the next discovery mechanismContent-ID defined in [I-D.ietf-sip-content-indirect-mech] for each profile URL. This is attempted. 4.4 Manually Provisioned The UA MAY indicateto avoid unnecessary download of the profiles. Some user (or administrator) that automatic discovery has failed. The UA SHOULD allow the user or administratoragents are not able to manually (perhaps using some out of band method e.g. beam, smart card, etc.) enter the configuration server address and portmake a profile effective without rebooting or restarting. Rebooting is probably something to be used for enrollment. 5 Enrollment and Change Notification The enrollment and configuration change notification are paired together and provided viaavoided on a user agent performing services such as telephony. In this way the SIP SUBSCRIBE/NOTIFY framework . This document definesContent-ID allows the profile on topuser agent to avoid unnecessary interruption of service as well. The Content-Type MUST be specified for each URL. Initially it is expected that most user agent vendors will use a proprietary content type for the SUBSCRIBE/NOTIFY framework profiles retrieved from the URLs(s). It is hoped that over time a standard content type will be specified that will be adopted by vendors of user agents. One direction that appears to be promising for this purpose. UA enrollment with the configuration servercontent is accomplished via the SUBSCRIBE request. A UA MUST enrollto use XML with the configuration server priorname spaces [??] to retrieving configuration data profiles. As part of the enrollmentsegment the UA MUST identify itself, its configuration retrieval protocol capabilities and configurationdata profile requirements. The configuration serverinto sets that the user agent implementer may use this information to decide how to allocate resources (e.g. load balancing)choose to support the UA for its specific configuration retrieval needs.based upon desired feature set. The configuration server may also usespecification of the UA enrollment event ascontent is out of the trigger to generate a new setscope of configuration data forthis document. Likewise the specific UA (e.g. based upon provisioned defaults and configuration profile context knowledge forURL scheme used in the environment). This allowscontent indirection is outside the configuration serverscope of this document. This document is agnostic to provide configuration data for a new UA without previously provisioningthe specific UA onURL schemes as the server. Eachprofile that the device requirescontent may dictate what is obtained via a separate enrollment or SUBSCRIBE request and SIP dialog. Thatrequired. It is expected that TFTP [RFC3617], FTP [??], HTTP [RFC2616], HTTPS [RFC2818], LDAP [RFC3377], XCAP [I-D.rosenberg-simple-xcap] and other URL schemes are supported by this package and framework. 3.6 Notifier processing of SUBSCRIBE requests The general rules for each different profile a device enrolls for, a different Call-Id is used.processing SUBSCRIBE requests [RFC3265] apply to this package. The device namesnotifier does not need to authenticate the subscription as the profile MIME typecontent is not transported in the SUBSCRIBE Accept header field. The configuration server then delivers a URL (through content indirection ) ator NOTIFY transaction messages. Only URLs are transported in the NOTIFY request which may be secured using the device can retrievetechniques in section Section 6. The behavior of the profile indelivery server is left to the implementer. The profile delivery server may be as simple as a subsequentSIP SUBSCRIBE UAS and NOTIFY request. ChangesUAC front end to a simple HTTP server delivering static files that are hand edited. At the other extreme the profile delivery server can be part of a configuration management system that integrates with a corporate directory and IT system or carrier OSS, where the profiles are indicated in additional NOTIFY requests sentautomatically generated. The design of this framework intentionally provides the flexibility of implementation from simple/cheap to complex/expensive. If the configuration server. The SUBSCRIBE request for enrollmentuser or device is sentnot known to the address(es) identified inprofile delivery server, the discovery process untilimplementer MAY accept the first successful 2xx class responsesubscription or reject it. It is received. As part ofrecommended that the binding ofimplementer accept the SUBSCRIBE/NOTIFY framework a new MIME type must be named for each Petrie Informational - Expires Aug. 2003 7 A Frameworksubscription. It is useful for SIP Feb. 2003 User Agent Configuration type of profile. The profile(s) MIME type(s) MUST be included inthe SUBSCRIBE Accept header field. [Is it okprofile delivery server to maintain the subscription as an administrator may add the user or device to the system, defining the profile contents. This allow a single SUBSCRIBEthe profile delivery server to immediately send a NOTIFY request multiplewith the profile types in (e.g. for each MIME subtype application/sip-ua-user-profile and application/sip-ua-device-profile)?]URLs. If enrollment fails (i.e. no 2xx response to SUBSCRIBE), the UA SHOULD re-discoverthe configurationprofile delivery server addressdoes not accept the subscription from an unknown user or device, the administer or user must manually provoke the user agent to reSUBSCRIBE. This may be difficult if the user agent and port as describedadministrator are at different sites. 3.7 Notifier generation of NOTIFY requests As in section 3. 5.1 SUBSCRIBE The SUBSCRIBE[RFC3265], the profile delivery server MUST always send a NOTIFY request is used byupon accepting a subscription. If the UAdevice or user is unknown to enroll inthe configuration domain ofprofile delivery server and it chooses to accept the configuration server. It uniquely identifiessubscription, the UAimplementer has two choices. A NOTIFY MAY be sent with vendor, model and serial number information. The UA also MUST specify its capabilities for configuration retrieval. The UA MUST indicate support forno body or content indirection by includingcontaining the MIME type message/external-body inprofile URL(s). Alternatively a NOTIFY MAY be sent with URL(s) pointing to a default data set. Typically this data set allows for only limited functionality of the SUBSCRIBE Accept header field per . The configurationuser agent (e.g. a phone user agent with data to call help desk and emergency services.). This is an implementation and business policy decision. A user or device known and fully provisioned on the profile delivery server SHOULD notsend an error if it is temporarily not able to providea NOTIFY with content indirection containing URLs for all of the configuration data profile listedprofiles associated with the user or device (i.e. which ever specified in the SUBSCRIBE request Event header field. Inprofile-type parameter). The device may be associated with a default user. The URL(s) for this default user profiles MAY be included with the first time outURL(s) of the box case,device if the profile type specified is device. A user agent can provide Hoteling by collecting a userĺs AOR and credentials needed to SUBSCRIBE dialog may beand retrieve the only means of communicating withuser profiles from the device as it does not yet have configuration. The configuration server SHOULD sendURL(s). Hoteling functionality is achieved by subscribing to the AOR and specifying the "user" profile type. This same mechanism can be used to secure a user agent, requiring a 403 response to the SUBSCRIBE if is not willinguser to provide the requested configuration profilelogin to enable functionality beyond the device.default userĺs restricted functionality. The configuration server SHOULD provide the configuration dataprofile todelivery server MAY specify when the UA via content indirection. Ifnew profiles MUST be made effective by the configuration server sends a 301 Moved Permanently response touser agent. By default the enrollment SUBSCRIBE,user agent makes the UA SHOULD cacheprofiles effective as soon as it thinks that it is non-obtrusive. However the URL containedprofile delivery server MAY specify a maximum time in the response Contact header fieldseconds (zero or more), in place ofthe address and port found during discovery for future enrollment. The device may request many configuration data profileseffective-by event header parameter, by sending multiple SUBSCRIBE requests each in a different SIP dialog. This may be useful ifwhich the device requiresuser specificagent MUST make the new profiles for multiple users. Ineffective. 3.8 Subscriber processing of NOTIFY requests The user agent subscribing to this caseevent package MUST adhere to the UserProfile parameter would vary for each SUBSCRIBE. AlternatelyNOTIFY request processing behavior specified in [RFC3265]. The user agent MUST make the device may require multiple types ofprofiles where each SUBSCRIBE would have a different MIME typeeffective as specified in the Accept header field.NOTIFY request (see section Section 3.7). The configuration server MAYuser agent SHOULD use one of the enrollment (SUBSCRIBE request) as the stimulustechniques specified in section [RFC3265] to generate a new instancesecurely retrieve the profiles. 3.9 Handling of forked requests This event package allows the creation of only one dialog as a configuration data profile uniqueresult of an initial SUBSCRIBE request. The techniques to achieve this are described in section 4.4.9 of [RFC3265]. 3.10 Rate of notifications It is anticipated that the rate of change for user and device profiles will 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. 3.11 State Agents State agents are not applicable to the UA. Alternately the configuration server MAY be provisioned aheadthis event package. 3.12 Examples SUBSCRIBE sip:email@example.com SIP/2.0 Event: sip-profile;profile-type=device;vendor=acme; model=Z100;version=1.2.3 From: sip:firstname.lastname@example.org;tag=1234 To: sip:email@example.com;tag=abcd Call-ID: firstname.lastname@example.org CSeq: 2131 SUBSCRIBE Contact: sip:email@example.com Content-Length: 0 NOTIFY sip:firstname.lastname@example.org SIP/2.0 Event: sip-profile;effective-by=3600 From: sip:email@example.com;tag=abcd To: sip:firstname.lastname@example.org;tag=1234 Call-ID: email@example.com CSeq: 321 NOTIFY 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/fsmith"; size=2222 Content-Type: application/z100-user-profile Content-ID: <69ADF2E92@example.com> --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/z100-device-profile Content-ID: <39EHF78SA@example.com> --boundary42-- 3.13 Use of timeURIs to know about new UAs and their specific configuration data content (for example based upon serial number, MAC address). Petrie Informational - Expires Aug. 2003 8 A Framework for SIP Feb. 2003 User Agent ConfigurationRetrieve State The user agent forms the From fieldprofile type specified determines what goes in the SUBSCRIBE in oneuser part of two ways depending uponthe type ofSUBSRIBE URI. If the profile that ittype requested is enrolling to. If"device", the user agentpart is enrolling to a device specific profile, thean identity that MUST be unique across all user agents from addr-spec is formed as: sip:<MAC-address>@<local-domain>. Ifall vendors. This identity must be static over time so that the profile delivery server can keep it associated with its profiles. For Ethernet hardware type user agent is enrolling toagents supporting only a single user specific profile the addr-specat a time this is formed asmost easily accomplished using its MAC address. Software based user agents running on general purpose hardware may also be able to use the usersMAC address for identity. However in situations where multiple instance of record. In this wayuser agents are running on the identitysame hardware it may be necessary to use a another scheme, such as using a unique serial number for whichthe software. If the profile type request is desired is always specified in the From field. 5.1.1 Additional User Agent Field Parameters When"user" the device first starts up out ofURI in the box, it has no user or local configuration. The device MUST provide a unique identity such that itSUBSCRIBE request is possiblethe address of record for the configuration serveruser. This allows the user to specify (e.g. login) to generate configuration profile forthe device. Theuser agent MUST include the User-Agent header in the SUBSCRIBE request.by simply entering their known identity. 4. Profile Delivery Framework Details The following additional User-Agent field parameters aredescribes how different functional steps of the profile delivery framework work. Also described here is how the event package defined forin this document provides the purpose of identifyingenrollment and notification functions within the UA device: Vendor ű a token usedframework. 4.1 Discovery of Subscription URI The discovery function is needed to identify the UA vendor name Model ű a token usedbootstrap user agents to identifythe UA hardware/software model Version ű a token usedpoint of knowing where to identify the firmware/software version currently installed onenroll with the UA Serial űprofile delivery server. Section Section 3.13 describes how to form the tokenURI used to identifysent the serial numberSUBSCRIBE request for enrollment. However the bootstrapping problem for the UA Note: on some hardware such as PCs and servers, there may be multiple instances of auser agent installed. In these scenarios only the serial number can be used to uniquely distinguish instances. Mac ű(out of the token usedbox) is what to identify the MAC address in hexuse for the UA From RFC 3261  the User-Agent header field syntax is extended to: User-Agent = "User-Agent" HCOLON product *( SEMI config-params ) config-params = serial-param / mac-param / generic-param product = vendor-model [SLASH product-version] product-version = token vendor-param = ˘Vendor÷ ˘=÷ token serial-param = ˘Serial÷ ˘=÷ token mac-param = ˘Mac÷ ˘=÷ token Example: User-Agent: model-a/22.214.171.124;vendor=acme The Vendor, Model, Version, Serialhost and Mac parameters MUST be providedport in the User-Agent header field forURI. Due to the wide variation of environments in which the enrollment SUBSCRIBE Petrie Informational - Expires Aug. 2003 9 A Framework for SIP Feb. 2003 User Agent Configuration request. Most profiles will either be device or user specific. All config-params MUST be specified even whenenrolling foruser profiles as the device characteristicsagent may impactreside (e.g. behind residential router, enterprise LAN, ISP, dialup modem) and the contentlimited control that the administrator of the profile delivery server provides. 5.2 NOTIFY(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 the specified order: SIP DHCP option [RFC3361], SIP DNS SRV [RFC3263], DNS A record and manual. 1. The NOTIFY messagefirst discovery mechanizm that SHOULD be tried is sent by the configuration serverto conveyconstruct the URL at whichSUBSCRIBE URI as described in Section 3.13 using the UA can retrievehost and port of out bound proxy discovered by the requested configuration data profile. This occursSIP DHCP option as described in two contexts: Immediately following[RFC3361]. If the enrollment SUBSCRIBESIP DHCP option is not provided in the configuration server MUST sendDHCP response, no SIP response or a NOTIFY providingSIP failure response other than for authorization is received for the URLSUBSCRIBE request to the sip-profile event, the next discovery mechanism SHOULD be tried. 2. The local IP network domain for the configuration data profile requested byuser agent, either configured or discovered via DHCP, should be used with the UAtechnique in [RFC3263] to obtain a host and port to use in the Event header field ofthe SUBSCRIBE request.URI. If the configuration serverno SIP response or a SIP failure response other than for authorization is not ablereceived for the SUBSCRIBE request to providethe specific configuration data profile or it does not wantsip-profile event, the UA to retrievenext discovery mechanism SHOULD be tried. 3. The fully qualified host name constructed using the specific configuration profile at that time, it MAY defer sending NOTIFY. Later whenhost name "sipuaconfig" and concatenated with the configuration server is ablelocal IP network domain should be tried next using the technique in [RFC3263] to provideobtain a host and port to use in the data profileSUBSCRIBE URI. If no SIP response or it wishesa SIP failure response other than for authorization is received for the UASUBSCRIBE request to retrievethe data profile,sip-profile event, the configuration server MAY send a NOTIFY request containingnext discovery mechanism SHOULD be tried. 4. If all other discovery techniques fail, the URLuser agent MUST provide a manual means for the configuration data profile whichuser to enter the UA SHOULD retrievehost and make effective as soon as it is safeport used to do so (e.g. when there are no active INVITE dialogs). Ifconstruct the configuration server becomes aware ofSUBSCRIBE URI. Once a configuration change that it wishes to be effective immediately on the UA, the configuration server SHOULD senduser agent has successfully discovered, enrolled, received a NOTIFY message containingresponse with profile URL(s), the URL foruser agent SHOULD cache the configuration data profile thatSUBCRIBE URI to avoid having to rediscover the UA requested when it enrolled. The configuration dataprofile with changed content SHOULD have a different Content-ID entity header than that ofdelivery server again in the last NOTIFY request.future. The UAuser agent SHOULD retrieve and make effective the changed configuration URL immediately upon receipt ofNOT cache the SUBSCRIBE URI until it receives a NOTIFY request.with profile URL(s). The UA MAY choose to wait to make the changes effective (e.g. to prevent the change from disrupting active calls on the UA). [Do we need an optionreason for the configurationthis is that a profile delivery server may send 202 responses to SUBSCRIBE requests and NOTIFY responses to tellunknown user agent (see section Section 3.6) with no URLs. Until the UA thatprofile delivery server has sent a NOTIFY request with profile URL(s), it MUST makehas not agreed to provide profiles. To illustrate why the change immediately regardless of state? Should this beuser agent should not cache the default?] The UA SHOULD send a 200 response toSUBSCRIBE URI until profile URL(s) are provided in the NOTIFY immediately upon receipt and validation ofNOTIFY, consider the solicited request.following example: a user agent running on a laptop plugged into a visited LAN in which a foreign profile delivery server is discovered. The configurationprofile delivery server MUST include,never provides profile URLs in the change notificationNOTIFY request,request as it is not provisioned to accept the configuration data profile URL.user agent. The Content-ID entity header associated withuser then takes the configuration data profile with changed content should be different than that oflaptop to their enterprise LAN. If the previous NOTIFY. This mechanism may be used byuser agent cached the configurationSUBSCRIBE URI from the visited LAN (which did not provide profiles), the user agent would not attempt to discover the profile delivery server in the enterprise LAN which is provisioned to provide firmware updates. For example on a UA that caches or has a persistent firmware image: ifprofiles to the server realizes (e.g. fromuser agent.. 4.2 Enrollment with Profile Server Enrollment is accomplished by subscribing to the event package described in section Section 3. The enrollment information) the UAprocess is runninguseful to the most currently available firmware version,profile delivery server as it could defer sending the NOTIFY withmakes the URL forserver aware of user agent to which it may delivery profiles (those user agents the firmware. However at a later time when a new Petrie Informational - Expires Aug. 2003 10 A Framework for SIP Feb. 2003 User Agent Configuration firmware versionprofile delivery server is availableprovisioned to provide profiles to; those present that the configurationserver could send a NOTIFY with the URL formay be provide profiles in the new firmware version, indicatingfuture; and those that the UA SHOULD upgrade as soon as itserver can automatically provide default profiles). It is safean implementation choice and business policy as to do so. 5.2.1 NOTIFY Body Content Format The NOTIFY request MUST contain a single part body with content indirection . The request MUST have a Content-Type header field with the MIME type of message/external-body. The Content-Type MUST also have a URL parameter specifyingwhether the URL at whichprofile delivery server provides profiles to retrieve the profile. The body MUST contain a Content-Type entity header withuser agents that it is not provisioned to do so. However the MIME typeprofile server SHOULD accept (with 2xx response) SUBSCRIBE requests from any user agent. 4.3 Notification of Profile Changes The NOTIFY request in the profile assip-profile event package server two purposes. First it provides the value. The body MUST also containuser agent with a Content-ID entity header which SHOULD changemeans to a new unique value each time the content ofobtain the URL changes. The Content-ID entity header associated withURL(s) for desired profiles without requiring the URL is intendedend user to allowmanually enter them. It also provides the UAmeans for the profile delivery server to decide if it hasnotify the user agent that the latestcontent of the configuration data profile without having to downloadprofiles have changed and compare the contents. Example: NOTIFY sip:firstname.lastname@example.org SIP/2.0 From: sip:email@example.com;tag=1234 To: sip:firstname.lastname@example.org;tag=abcd Call-ID: email@example.com CSeq: 2131 INVITE Content-Type: message/external-body; ACCESS-TYPE=URL; URL="https://acme.com/profiles/vendor-x/00df1e004cd0" Content-Length: ... Content-Type: application/foo-profile Content-Disposition: session Content-ID: <firstname.lastname@example.org> 6 Configurationshould be made effective. 4.4 Retrieval of Profile Data The UA MUST retrieve its configuration data profile using the URL specified byuser agent retrieves it's needed profile(s) via the configuration serverURL(s) provide in the NOTIFY request. Ifrequest as specified in section Section 3.5. The profile delivery server SHOULD secure the retrieval fails,content of the UAprofiles using one of the techniques described in Section 6. The user agent SHOULD not re-enroll untilmake the SUBSCRIBE session expires to avoid a cascade effect ifnew profiles effective in the server goes down temporarily.timeframe described in section Section 3.2. The device MAY re-try the profile retrievecontents of the profile from the URL before the SUBSCRIBE expires. Shouldprofiles SHOULD be cached by the re- enrollment fail,user agent. This it to avoid the UA SHOULD re-discoversituation where the configurationcontent delivery server as described in section 4. 7 Configuration Upload Ifis not available, leaving the UAuser agent non-functional. 4.5 Upload of Profile Changes The user agent or another entity wishes to modify a configuration data profile itother service MAY make the change persistent onpush changes up to the configurationprofile delivery server if it is authorizedusing the technique appropriate to do so.the profile's URL scheme (e.g. HTTP PUT method, FTP put command). The configuration server SHOULD supporttechnique for pushing incremental or atomic changes MUST be described by the ability to accept uploadsspecific profile data framework. 5. IANA Considerations [TBD] 6. Security Considerations Profiles may contain sensitive data such as user credentials. The protection of this data is accomplished via the same URLprofile retrieval function. This simplifies the UA usedsecurity solution as the SIP event package does not need to retrieveauthenticate, authorize or protect the configuration data profile. For HTTP and HTTPScontents of the UA does a POST with a multipart MIME attachment containingSIP messages. Effectively the profile delivery server will provide profile URL(s) to any URL parameters in one partone. The URLs themselves are protected via authentication, authorization and the changed configuration data Petrie Informational - Expires Aug. 2003 11 A Frameworksnooping. Three options for SIP Feb. 2003 User Agent Configuration profile [whole or changes only ?? define insecure retrieval of profiles ??] in another part as defined in [?]. If the UA or userare follow: 6.1 Symmetric Encryption of Profile Data One security technique is not permittedto makeencrypted the changesprofiles on the configurationcontent delivery server using the configuration server returns an HTTP error response codeAES symmetric encryption algorithm using a key formed by a MD5 hash of 403 Forbidden. Ifthe configurationfollowing: username ":" password. The encrypted profiles are delivered by the content delivery server returns a 403via the UA SHOULD disallowURLs provided in the changes from being effective onNOTIFY requests. Using this technique the UA. The UA SHOULDprofile delivery server does not make the changes effective until it receives a successful response (e.g.need to provide authentication or authorization for HTTP 2xx). Ifthe URLretrieval as the profiles are obscured. The user agent must obtain the username and password from the user to generate the key and perform AES decryption the profiles. This is for HTTP/HTTPSthe simplest security technique as it does not require any public key infrastructure or TLS implementation on the user agent (which often has limited resources). 6.2 Client Certificate Authentication with HTTPS In another technique the content delivery server MUST returnauthenticates the changed configuration data profileuser or user agent by requesting the client's certificate in the response (assuming it was allowed). The UA SHOULD useTLS connection established as described by the configuration dataprofile contents fromURL. The content delivery server authorizes the HTTP response as opposed toprofile retrieval using the data that was pushed incertificate identity and business policy choices provide by the request as changes may occur from other sources. Theserver SHOULD include a Content-ID header in the HTTP/HTTPS response.implementer. The configuration server SHOULD send out a NOTIFY for this change,profile data is obscured from snooping using the same Content-ID entity header value as inencryption mechanisms provide by the HTTP/HTTPS response.TLS connect. This allowshas nice properties of not requiring end user intervention, but has a higher administrative cost for user agent certificate management and distribution. It also requires the UAcertificates to know that it already hasbe in place before enabling profile delivery. 6.3 HTTPS Authentication Alternatively the current contents ofauthentication mechanizms described in [RFC2617] are used. The content delivery server authorizes the configuration dataprofile retrieval using the certificate identity and SHOULD not download that configuration databusiness policy choices provide by the server implementer. The profile (i.e. itdata is safe to ignoreobscure from snooping using the NOTIFY asencryption mechanisms provide by the Content-ID isTLS connect. This also requires the same). [Alterativelyoverhead of a TLS implementation on the Content-ID could be putuser agent. For all of these techniques the user agent should take care in how it stores or caches the contentprofiles to avoid theft. It is recommended that a symmetric encryption technique such as opposedthat described in section Section 6.1 be used. This also requires the overhead of a TLS implementation on the user agent. 7. Differences from Simple XCAP Package The author of this document had an action item from the July 2003 IETF SIPPING WG meeting to consider resolving the HTTP/HTTPS response] [TBD ű in 403 case restrictdifferences of the sip-profile and provide feedback as to what specificallysimple XCAP package [I-D.ietf-simple-xcap-package]. It is not allowed tothe author's opinion that XCAP [I-D.rosenberg-simple-xcap] can be modifiedsupported by the UA or user] 8 Examples Belowframework and event package defined in this document as it is an example high level message flow forsimply a new UA discovering andURL using configuration data from a configuration server. Followingthe high level message flows are some specific SIP messages illustrating SUBSCRIBE and NOTIFY messages from enrollment and configuration change notification. 8.1 Example Message FlowsHTTP or HTTPS scheme. The following high level message flows illustratelists the configuration process of discovery, enrollment, configuration retrieval and change notification with associated configuration retrieval. The UA uses DHCP withdifferences between the SIP  option requestingevent packaged defined in this document vs. the configuration server address and port.one defined in [I-D.ietf-simple-xcap-package]. The DHCP server does not providesimple XCAP package requires that the configuration server address or port.relative path be known and specified by the user agent when subscribing for change notification. The UA then doesevent package in this document requires a DNS lookup for the configuration service withintoken be known and specified when subscribing. The advantage of the local domain.latter is that bootstrapping is easier and well defined. It gets a response fromalso leaves the DNS server forfreedom of specifying the configuration serverĂs fully qualified host name. The UA then enrolls withentire path of the configuration server by sending a SUBSCRIBE request forprofile URL up to the profile type indicateddelivery server. The event package defined in this document allows multiple URLs to be provided in the Event header. The configuration server sends back a successful response. The configuration server then sends aNOTIFY request withbody as a result of a single token specified in the URL forSUBSCRIBE event parameter: profile-type. This allows the configuration dataprofile delivery server to provide sets of profiles that the UA nameduser agent may not have enough information to specify in the enrollmentSUBSCRIBE request. The UA sends a 200 response toURI (e.g. at boot strapping time the NOTIFY. The UA then downloadsuser agent may not know the configuration Petrie Informational - Expires Aug. 2003 12 A Frameworkuser's identity, but the profile delivery server may know the default user for SIP Feb. 2003 User Agent Configuration datathe device's identity) or the doc-component of the simple XCAP package. The simple XCAP package provides profile viadata changes or deltas in the URL frombody of the NOTIFY request. This process may be repeatedis a desirable feature, but approach in parallel for each ofthe required profiles. The UA is now configured as prescribed. Later ... an administrator makessimple XCAP package has a changefew disadvantages: o SIP signaling requires authentication, authorization and encryption (SIPS) to protect the configuration forprofiles where the UAevent package in this document does not. SIPS may require more resources than are available on the configuration server.many user agents. o The configuration server on behalfcontent of the administrator, sendsa NOTIFY (change notification) request to the UA with Content-ID entity header for the profile. As the Content-ID value has changed, the UA downloads the configuration dataprofile fromchange may be large, causing fragmentation and problems or constraints when using UDP. The feature of providing profile data changes or deltas can be provided in the given URL. UA DHCP Server DNS Server Config. Server Discovery IP config. req. ==============> IP config. wo/ local option <============== DNS A record req. for sipuaconfig hostpackage proposed in local domain =============================> A record IP address returned for Host <============================= Enrollment SIP SUBSCRIBE Event: sip-config ==================================================> 200 OK <================================================== SIPthis document by providing two URLs in the NOTIFY Event: sip-config w/ requestedrequest for each profile (i.e. a URL <================================================== 200 OK ==================================================> Configuration retrieval HTTP GET ==================================================> 200 OK (specific profile data in body) <================================================== . . . Administrative change on configuration server via user interface . . . Petrie Informational - Expires Aug. 2003 13 A Frameworkfor SIP Feb. 2003 User Agent Configuration Change Notification SIP NOTIFY Event: sip-config w/ changedthe complete profile URL <================================================== 200 OK ==================================================> HTTP GET ==================================================> 200 OK (profile dataand another for the changes). All other functional differences between draft-ietf-sipping-config-framework-00 and draft-ietf-simple-xcap-package-00 are believed to be resolved in body) <================================================== . . . User changes datathis version of this document. 8. Open Issues 9. Change History 9.1 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 onchanges to be make effective by the user agent . . . Configuration Upload HTTP POST (changed profile attached as multipart MIME) ==================================================> 200 OK (profile datain body, as change confirmation) <================================================== . . . 8.2 Example Messages Petrie Informational - Expires Aug. 2003 14 A Framework for SIP Feb. 2003 User Agent Configuration The following SUBSCRIBE request example is froma UA enrollingspecified maximum period of time. Changed the name of the event package from sip-config to sip-profile Three high level securityapproaches are now specified. 9.2 Changes from draft-petrie-sipping-config-framework-00.txt Changed name to reflect SIPPING work group item Synchronized with a configuration server. As this SUBSCRIBE request is for configuration enrollmentchanges to SIP DHCP [RFC3361], SIP [RFC3261] and [RFC3263], SIP Events [RFC3265] and content indirection [I-D.ietf-sip-content-indirect-mech] Moved the Event headerdevice identity parameters from the From field containsparameters to User-Agent header parameters. Many thanks to Rich Schaaf of Pingtel, Cullen Jennings of Cisco and Adam Roach of Dyamicsoft for the token sip-config. The UA tellsgreat comments and input. 9.3 Changes from draft-petrie-sip-config-framework-01.txt Changed the configuration server that it would likename as this belongs in the configuration data profileSIPPING work group. Minor edits 9.4 Changes from draft-petrie-sip-config-framework-00.txt Many thanks to those who contributed and commented on the previous draft. Detailed comments were provided by Henning Schulzrinne from Columbia U., Cullen Jennings from Cisco, Rohan Mahy from Cisco, Rich Schaaf from Pingtel. Split the enrollment into a single SUBSCRIBE dialog for each profile. The 00 draft sent a single SUBSCRIBE listing all of type: sip-ua-device-config in the Accept header field. The UA tellsthe configuration serverdesired. These have been split so that iteach enrollment can be routed differently. As there is enrolling for 86400 seconds via the Expires header field. During this perioda concept of time the configuration server MUST senddevice specific and user specific profiles, these may also be managed on separate servers. For instance in a change notification with the URL forroaming situation the configuration datadevice might get it's profile data from a local server which changed. The UA has identified the specifics about itself in the From field addr-spec and User-Agent parameters: Vendor/Model, Version, Serial, Mac. In this example the UserProfile parameter is not included in the From field asknows the sip-config profile is deviceLAN specific not user specific. UA => Config. Server SUBSCRIBE sip: email@example.com SIP/2.0 To: sip:firstname.lastname@example.org From: sip:email@example.com;tag=aslkjhd User-Agent: acme-model-a/126.96.36.199;Serial=1234567890;Mac=000aaa1234cd Call-Id: firstname.lastname@example.org Cseq: 1 SUBSCRIBE Event: sip-config Expires: 86400 Content-Length: 0 Accept: message/external-body application/sip-ua-device-config The following is an example response to the above enrollment request. Config. Server => UA SIP/2.0 202 Accepted To: sip:email@example.com;tag=owiu1234 From: sip:firstname.lastname@example.org;tag=aslkjhd Call-Id: email@example.com Cseq: 1 SUBSCRIBE Content-Length: 0 Petrie Informational - Expires Aug. 2003 15 A Framework for SIP Feb. 2003 User Agent Configuration Inprofile data. At the following examplesame time the device is requesting auser specific profile Sip-User. The device specifies that it wantprofiles might come from the user's home environment profile fordelivery server. Removed the user: sip:firstname.lastname@example.org. UA => Config. Server SUBSCRIBE sip: email@example.com SIP/2.0 To: sip:firstname.lastname@example.org From: sip:email@example.com;tag=klhfkjncd User-Agent: acme-model-a/188.8.131.52;Serial=1234567890;Mac=000aaa1234cd Call-Id: firstname.lastname@example.org Cseq: 1 SUBSCRIBE Event: sip-config Expires: 86400 Content-Length: 0 Accept: message/external-body application/sip-ua-user-config The followingConfig-Expires header as it is an example response tolargely superfluous with the above enrollment request. Config. Server => UA SIP/2.0 202 Accepted To: sip:email@example.com;tag=oqieu983 From: sip:firstname.lastname@example.org;tag=klhfkjncd Call-Id: email@example.com Cseq: 1SUBSCRIBE Content-Length: 0 The following example is the immediate NOTITY request the configuration server sent toExpires header. Eliminated some of the UA above enrollment. The URLcomplexity in the request body is for the configuration datadiscovery 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 UA named in the EventUser-Profile From header field inparameter so that the above SUBSCRIBEdevice can a request a user specific profile for a user that is different from the UA. Config. Server => UA NOTIFY sip:10.1.1.123 SIP/2.0 To: sip:firstname.lastname@example.org;tag=owiu1234 From: sip:email@example.com;tag=aslkjhd Call-Id: firstname.lastname@example.org Cseq: 22 NOTIFY Event: sip-config Content-Type: message/external-body;ACCESS-TYPE=URL; URL="http://config.localdomain.com/device/000aaa1234cd/dev-prof Content-Length: ... Content-Type: application/sip-ua-device-config Content-ID: email@example.com Petrie Informational - Expires Aug. 2003 16 A Frameworkdevice's default user. References [I-D.ietf-simple-xcap-package] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Modification Events for the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Managed Documents", draft-ietf-simple-xcap-package-00 (work in progress), June 2003. [I-D.ietf-sip-content-indirect-mech] Olson, S., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", draft-ietf-sip-content-indirect-mech-03 (work in progress), June 2003. [I-D.ietf-sipping-ua-prof-framewk-reqs] Petrie, D. and C. Jennings, "Requirements for SIP Feb. 2003User Agent Profile Delivery Framework", draft-ietf-sipping-ua-prof-framewk-reqs-00 (work in progress), March 2003. [I-D.rosenberg-simple-xcap] Rosenberg, J., "The Extensible Markup Language (XML) Configuration The following is an example response from the UAAccess Protocol (XCAP)", draft-rosenberg-simple-xcap-00 (work in progress), May 2003. [I-D.sinnreich-sipdev-req] Butcher, I., Lass, S., Petrie, D., Sinnreich, H. and C. Stredicke, "SIP Telephony Device Requirements, Configuration and Data", draft-sinnreich-sipdev-req-02 (work in progress), October 2003. [RFC0822] Crocker, D., "Standard for the above request. UA => Config. Server SIP/2.0 200 Ok To: sip:firstname.lastname@example.org;tag=owiu1234 From: sip:email@example.com;tag=aslkjhd Call-Id: firstname.lastname@example.org Cseq: 22 NOTIFY Content-Length: 0 Assume at some later time, an administrator makes a change to the contentformat of the sip-config configuration data profile for the UA. The configuration server sends a NOTIFY request to the UAARPA Internet text messages", STD 11, RFC 822, August 1982. [RFC2119] Bradner, S., "Key words for the configuration change notification. This example request below indicates the changed URL or contentuse in the request body with a higher sequence number. Config. Server => UA NOTIFY sip:10.1.1.123 SIP/2.0 To: sip:email@example.com;tag=owiu1234 From: sip:firstname.lastname@example.org;tag=aslkjhd Call-Id: email@example.com Event: sip-config Cseq: 23 NOTIFY Content-Type: message/external-body;ACCESS-TYPE=URL; URL="http://config.localdomain.com/device/000aaa1234cd/dev-prof Content-Length: ... Content-Type: application/sip-ua-device-config Content-ID: firstname.lastname@example.org The following is an example response to the above request. UA => Config. Server SIP/2.0 200 Ok To: sip:email@example.com;tag=owiu1234 From: sip:firstname.lastname@example.org;tag=aslkjhd Call-Id: email@example.com Cseq: 23 NOTIFY Content-Length: 0 9 Security Considerations [This section needsRFCs to be greatly expandedIndicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and elaborated] SIP basicT. 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 digest authentication  MAY be used for SUBSCRIBE/NOTIFY messages used for enrollmentL. 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 configuration change notification. There is a chickenE. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3263] Rosenberg, J. and egg problem. Since the Petrie Informational - Expires Aug. 2003 17 A Framework forH. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Feb. 2003 User Agent Configuration content of SUBSCRIBE/NOTIFY messages are transported in the clear, the credentials that the UA uses in the SUBSCRIBE 401 challenge, or that the configuration server uses in the NOTIFY 401 challenge must be provisioned out of band (i.e. user or administrator manual input, beamed via PDA, smart card, etc.) via a secure means.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 data profile URLs are communicated in the clear in the NOTIFY requests fromProtocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 3361, August 2002. [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002. [RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and Applicability Statement for the configuration server.Trivial File Transfer Protocol (TFTP)", RFC 3617, October 2003. Author's Address Daniel Petrie Pingtel Corp. 400 W. Cummings Park Suite 2200 Woburn, MA 01801 US Phone: "Dan Petrie (+1 781 970 0111)"<sip:firstname.lastname@example.org> EMail: email@example.com URI: http://www.pingtel.com/ Appendix A. Acknowledgments Intellectual Property Statement The security risk of unauthorized access of the URL content can be mitigated ifIETF takes no position regarding the configuration server and UA both support basic authentication and HTTPvalidity or HTTPS. There is a chicken and egg problem here as well since the contentscope of SUBSCRIBE/NOTIFY messages are transported in the clear. Accordingly,the credentialsany intellectual property or other rights that the UA uses for the HTTP/HTTPS GET/POST 401 challenge mustmight be provisioned out of band (i.e. user or administrator manual input, beamed via PDA, smart card, etc.) via a secure means. Using HTTPS over TLS the configuration server MAY requestclaimed to pertain to the certificateimplementation or use of the UA . Iftechnology described in this level of authentication is desired,document or the UA vendor SHOULD shipextent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the UAIETF's procedures with a digital certificate or provide a means by which thisrespect to rights in standards-track and standards-related documentation can be installed outfound in BCP-11. Copies of band. The configuration server MUST be provisioned with the certificatesclaims of authority allowedrights made available for each modelpublication and any assurances of UAlicenses to be supported. Using HTTPS the UA MAY requestmade available, or the certificateresult of an attempt made to obtain a general license or permission for the configuration server. If this leveluse of authentication is desiredsuch proprietary rights by implementors or users of this specification can be obtained from the UA mustIETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be provisioned withrequired to practice this standard. Please address the allowed certificate(s) of authority and identities forinformation to the configuration server outIETF Executive Director. The IETF has been notified of band (i.e. user or administrator manual input, beamed via PDA, smart card, etc.) via a secure means. 10 Open Issues [Do we need an option for the configuration serverintellectual property rights claimed in regard to tellsome or all of the UA that it MUST makespecification contained in this document. For more information consult the change immediately regardlessonline list of state? Should thisclaimed rights. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be the default?] [Uploadcopied and furnished to configuration server configuration data profilesothers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or changes only ?? definein profiles ??] [Security considerations section needs much elaboration] Petrie Informational - Expires Aug. 2003 18 A Framework for SIP Feb. 2003 User Agent Configuration 11 References  R. Droms, "Dynamic host configuration protocol," Request for Comments (Draft Standard) 2131, Internet Engineering Task Force, Mar. 1997.  S. Alexanderpart, without restriction of any kind, provided that the above copyright notice and R. Droms, "DHCP optionsthis paragraph are included on all such copies and BOOTP vendor extensions," Request for Comments (Draft Standard) 2132, Internet Engineering Task Force, Mar. 1997.  H.Schulzrinne , ˘Dynamic Host Configuration Protocol (DHCP- for-IPv4)÷, Request for Comments (Draft Standard) 3361, Internet Engineering Task Force, Aug. 2002.  S. Bradner, "Key words for usederivative works. However, this document itself may not be modified in RFCsany way, such as by removing the copyright notice or references to indicate requirement levels," Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, Mar. 1997.  A. Gulbrandsen, P. Vixie, and L. Esibov, ˘A DNS RR for specifyingthe location of services (DNS SRV),÷ Request for Comments 2782, Internet Engineering Task Force, Feb. 2000.  Rosenberg, et. al., ˘SIP: session initiation protocol,÷ Request for Comments 3261, Internet Engineering Task Force, June 2002  A. Roach, ˘Event Notification in SIP÷, Request for Comments 3265,Internet Engineering Task Force, June 2002  D. Crocker, ˘STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES÷, Request for Comments 822,Society or other Internet Engineering Task Force, Aug. 1982  K. Sollins, ˘THE TFTP PROTOCOL (REVISION 2)÷, Requestorganizations, except as needed for Comments 1350,the purpose of developing Internet Engineering Task Force, Jul. 1992  H Schulzrinne, ˘Configuring IP Telephony End Systems÷, <schulzrinne-sip-config-00.txt>, IETF; Dec. 2000, Workstandards in progress  D. Petrie, ˘Requirementswhich case the procedures for a SIP User Agent Configuration Framework÷, <draft-ietf-sip-config-framewk-reqs-00.txt>, IETF; Feb. 2003, Workcopyrights defined in progress  T. Berners-Lee et al, ˘Uniform Resource Locators (URL)÷, Request for Comments 1738, Internet Engineering Task Force, Dec. 1994  E. Rescorla, ˘HTTP Over TLS÷, Request for Comments 2818, Internet Engineering Task Force, May 2000 Petrie Informational - Expires Aug. 2003 19 A Framework for SIP Feb. 2003 User Agent Configuration  T. Dierks, C. Allen, ˘The TLS Protocol Version 1.0÷, Request for Comments 2246,the Internet Engineering Task Force, Jan. 1999  S. Olson ˘A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages÷, <draft-ietf-sip-content- indirect-mech-01>, IETF; Nov. 2002, Work in progress  H. Sinnreich, ˘SIP Telephony Device Requirements, ConfigurationStandards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and Data÷, <draft-sinnreich-sipdev-req-00.txt>, IETF; Nov. 2002, Work in progress  H Schulzrinne, ˘Configuring IP Telephony End Systems÷, <schulzrinne-sip-config-00.txt>, IETF; Dec. 2000, Work in progress  D. Petrie, ˘Requirements for a SIP User Agent Configuration Framework÷, <draft-petrie-sip-config-framewk-reqs-00.txt>, IETF; Feb. 2001, Work in progress  T. Berners-Lee et al, ˘Uniform Resource Locators (URL)÷, Request for Comments 1738, Internet Engineering Task Force, Dec. 1994  E. Rescorla, ˘HTTP Over TLS÷, Request for Comments 2818,will not be revoked by the Internet Engineering Task Force, May 2000  T. Dierks, C. Allen, ˘The TLS Protocol Version 1.0÷, RequestSociety or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for Comments 2246,the RFC Editor function is currently provided by the Internet Engineering Task Force, Jan. 1999  S. Olson ˘A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages÷, <draft-ietf-sip-content- indirect-mech-01>, IETF; Nov. 2002, Work in progress 12 Author's Address Dan Petrie Pingtel Corp. 400 W. Cummings Park Phone: +1 781 938 5306 Woburn, MA USA Email: firstname.lastname@example.org Petrie Informational - Expires Aug. 2003 20Society.