--- 1/draft-ietf-sipping-config-framework-00.txt 2006-02-05 01:48:09.000000000 +0100 +++ 2/draft-ietf-sipping-config-framework-01.txt 2006-02-05 01:48:10.000000000 +0100 @@ -1,1035 +1,976 @@ - D. Petrie - Internet Draft Pingtel Corp. - draft-ietf-sipping-config-framework-00.txt - Expires: Aug 2003 Feb 2003 +SIPPING D. Petrie +Internet-Draft Pingtel Corp. +Expires: April 21, 2004 October 22, 2003 - A Framework for SIP User Agent Configuration + A Framework for SIP User Agent Profile 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. + 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. + 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." + 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 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. -Abstract - - This document defines the application of a set of protocols for - configuring a SIP user agent. The 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. The - objective is to define a means for automatically configuring a user - agent such that it can be functional without user or administrative - intervention. The framework for discovery, delivery, notification - and updates of user agent configuration is defined here. This - framework is also intended to ease ongoing administration, - configuration and upgrading of large scale deployments of SIP user - agents. The contents and format of the configuration 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 Configuration - -Table of Contents - - Status of this Memo................................................1 - Abstract...........................................................1 - 1 Overview.......................................................3 - 2 Conventions used in this document..............................4 - 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 - A Framework for SIP Feb. 2003 - User Agent Configuration - -1 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 agents. It is expected that UA vendors should be able to - use this configuration framework as a means of delivering their - existing proprietary configuration 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 - configuration server to deliver configuration data to UAs from - multiple vendors. Follow-on standardization activities can: 1) - define a standard format (e.g. XML or name-value pairs [8]) and 2) - specify the content (i.e. name the configuration parameters) of the - configuration data profiles. - - This document defines a framework which allows SIP user agents (UA) - to automatically: - - discover a configuration server (Discovery) - - enroll with the configuration server (Enrollment) - - retrieve configuration data (Configuration Retrieval) - - receive notification of configuration changes (Change - Notification) - - upload configuration 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 [10], [11] and - [16] explicitly excluding the requirements which pertain to - configuration data profile content and format. - - Discovery is the process by which a UA SHOULD find the address and - port at which it SHOULD enroll with the configuration 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 of the change - notification. - - Configuration Upload is the process by which a UA or other entity - pushes a change to a configuration data profile back up to the - configuration 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 [1]. - - The syntax and semantics used here extend those defined in SIP (RFC - 2543) [6]. 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 + This Internet-Draft will expire on April 21, 2004. - Changed name to reflect SIPPING work group item +Copyright Notice - Updated with changes to SIP DHCP [3], SIP [6], SIP Events [7] and - content indirection [15]. + Copyright (C) The Internet Society (2003). All Rights Reserved. - Moved the device identity parameters from the From field parameters - to User-Agent header parameters. +Abstract - Many thanks to Rich Schaaf of Pingtel, Cullen Jennings of Cisco and - Adam Roach of Dyamicsoft for the great comments and input. + This document defines the application of a set of protocols for + providing profile data to SIP user agents. The objective is to + define a means for automatically providing profile data a user agent + needs to be functional without user or administrative intervention. + The framework for discovery, delivery, notification and updates of + user agent profile 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 and upgrading of large scale deployments of SIP user + agents. The contents and format of the profile data to be defined is + outside the scope of this document. -3.2 Changes from draft-petrie-sip-config-framework-01.txt +Table of Contents - Changed the name as this belongs in the SIPPING work group. + 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1 Requirements Terminology . . . . . . . . . . . . . . . . . . 3 + 2.2 Profile Delivery Framework Terminology . . . . . . . . . . . 4 + 2.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 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 - Minor edits +1. Motivation -3.3 Changes from draft-petrie-sip-config-framework-00.txt + 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 will be able to use this + framework as a means of delivering their existing proprietary user + 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 profile delivery server for + profile data to user agents from multiple vendors. Follow-on + standardization activities can: + 1. define a standard profile content format framework (e.g. XML with + name spaces [??] or name-value pairs [RFC0822]). + 2. specify the content (i.e. name the profile data parameters, xml + schema, name spaces) of the data profiles. - 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. + One of the objectives of the framework described in this document is + 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. - 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 + 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. - Petrie Informational - Expires Aug. 2003 4 - A Framework for SIP Feb. 2003 - User Agent Configuration + 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] - user specific profiles, these may also be managed on separate - servers. For instance in a roaming situation the device might get - itÆs configuration from a local server which knows the LAN specific - configuration. At the same time the user specific profiles might - come from the userÆs home environment configuration server.' +2. Introduction - Removed the Config-Expires header as it is largely superfluous with - the SUBSCRIBE Expires header. +2.1 Requirements Terminology - Eliminated some of the complexity in the discovery mechanism. + 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]. - Suggest caching information discovered about a configuration server - to avoid an avalanche problem when a whole building full of devices - powers up. +2.2 Profile Delivery Framework Terminology - Added the User-Profile From header field parameter so that the - device can a request a user specific profile for a user that is - different from the deviceÆs default user. + profile - data set specific to a user or device. + device - SIP user 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). -4 Discovery +2.3 Overview - The purpose of discovery is to figure out how to address the - configuration server so that the device can enroll. The enrollment - process involves sending a SIP SUBSCRIBE. Prior to this the - discovery process must find the address to use in the URL for the - URI and To header field. The URL SHOULD use the user id: - sipuaconfig. From a SIP perspective the configuration server is - simply a user agent. By using the well known user id, this makes it - easy for proxy servers to be provisioned to route the enrollment - requests from devices to the appropriate configuration server for - the domain. + The profile life cycle can be described by five functional steps. + These steps are not necessarily discrete. However it is useful to + describe these steps as logically distinct. These steps are named + as follows: - The first time a UA is plugged in it does not know the address or - port at which to enroll with the local configuration server. It - must discover this address and port. A UA SHOULD support all of the - listed discovery mechanisms. It MUST support at least one of them. - Once the UA has discovered the address and port and has successfully - enrolled with the configuration server, the UA SHOULD cache the - address and port to avoid the need to re-discover the configuration - server. However if enrollment, configuration retrieval or - configuration upload fails at any time, the UA SHOULD apply the - discovery and enrollment process again. This provides a means for - configuration server fail over and load balancing. - The UA SHOULD use the following mechanisms to discover the host - address and port at which it SHOULD enroll with the configuration - server. Each mechanism should be tried in the following order until - an address and port is provided which results in successful - enrollment (i.e. the server responds with a successful 2xx class - response): - - DHCP option for SIP [3] - - DNS A record - - Multicast - - Manual provisioning + Discovery - discover a profile delivery server + Enrollment - enroll with 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 the + profile delivery server - Petrie Informational - Expires Aug. 2003 5 - A Framework for SIP Feb. 2003 - User Agent Configuration + Discovery is the process by which a UA SHOULD find the address and + port at which it SHOULD enroll with 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 SHOULD try them until one succeeds. - The rationale for this order follows. Assuming that most UAs are - going to use DHCP for IP configuration anyway, using a DHCP option - is the least costly in terms of lookup time (i.e. no additional - messages are required). Hence DHCP is first. Multicast is used - last of the automated discovery mechanisms as it is the most - restricted in terms of network environments that support it. - Multicast is included, even though the applicable environments are - restricted, as it is the only mechanism that can be used without the - support of the local network administrator. + Enrollment is the process by which a UA SHOULD make itself known to + the profile delivery server. In enrolling the UA MUST provide + identity information, name requested profile type(s) and supported + protocols for profile retrieval. It SHOULD also subscribe to a + mechanism for notification of profile changes. As a result of + enrollment, the UA receives a URL for each of the profiles that the + profile delivery server is able to provide. Each profile type (set) + requires a separate enrollment or SUBSCRIBE session. - The phone administrator and the network administrator are often - different people and perhaps in different departments. + Profile Retrieval is the process of retrieving the content for each + of the profiles the UA requested. - The UA implementer MAY provide the user or administrator with the - means to change the order in which these mechanisms are tried. This - includes the ability to manually override the discovery process. - However by default without user interaction the UA SHOULD use the - order listed above. + Profile Change Notification is the process by which the profile + delivery server notifies the UA that the content of one or more of + the profiles has changed. Subsequently the UA SHOULD retrieve the + profile from the specified URL upon receipt of the change + notification. - Once discovery is successful the device SHOULD persistently cache - the address to avoid avalanche problems when a whole building full - of devices powers up at once. The characteristic of the profile may - dictate this behavior. For example device specific profiles may - need to change when the device is moved to a different location. - User specific profiles may be independent of the LAN, network or - device location. + Profile Upload is the process by which a UA or other entity (e.g. + OSS, corporate directory or configuration management server) pushes a + change to the profile data back up to the profile delivery server. -4.1 DHCP Option + This framework defines a new SIP event package [RFC3265] to solve + enrollment and profile change notification steps. -It is likely that most UAs in an deployment of any significant size -will use DHCP for IP configuration. DHCP becomes a convenient means to -discover the configuration server address. In the same DHCP request -for basic IP configuration, the UA can add the option for SIP[3] [1] to -the options field. This indicates a request for the default SIP proxy -server address and port. For example if the DHCP option for SIP -returns an address of sip.acme.com and a port of 5080, the following -URL is constructed: sip:sipuaconfig@sip.acme.com:5080. If the proxy -server address and port is not returned in the DHCP response or the -server does not respond to the enrollment request with a successful 2xx -class response, the next discovery mechanism is attempted. + The question arises as to why SIP should be used for the profile + delivery framework. In this document SIP is used for only a small + portion of the framework. Other existing protocols are more + appropriate for transport of the profile contents (upstream and + downstream of the user agent) and are suggested in this document. + The discovery step is simply a specified order and application of + existing protocols. SIP is only needed for the enrollment and change + notification functionality of the profile delivery framework. In + many SIP environments (e.g. carrier/subscriber and multi-site + enterprise) firewall, NAT and IP addressing issues make it difficult + to get messages between the profile delivery server and the user + agent requiring the profiles. -4.2 DNS + With SIP the users and devices already are assigned globally routable + addresses. In addition the firewall and NAT problems are already + presumably solved in the environments in which SIP user agents are to + be used. Therefore SIP is the best solution 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 + notification of profile changes is best solved by SIP. - The UA SHOULD construct a fully qualified host name using - ôsipuaconfigö as the host and the local domain if defined. It - SHOULD try a DNS A record lookup on the fully qualified host name. - If the name resolves in DNS it should then attempt enrollment. For - example the URL constructed in the local domain of acme.com would - look like: sip:sipuaconfig@sipuaconfig.acme.com. If the server does - not respond to enrollment with a successful 2xx class response, the - next discovery mechanism is attempted. + It is assumed that the content delivery server MUST be either in the + public network or accessible through a DMZ. The user agents + requiring profiles may be behind firewalls and NATs and many + protocols, such as HTTP, may be used for profile content retrieval + without special consideration in the firewalls and NATs. - Petrie Informational - Expires Aug. 2003 6 - A Framework for SIP Feb. 2003 - User Agent Configuration + A conscious separation of user and device profiles is made in this + document. This is useful to provide features such as hoteling as + well as securing or restricting user agent functionality. By + maintaining this separation, a user may walk up to someone else's + user agent and direct that user agent to get their profile data. In + doing so the user agent can replace the previous user's profile data + while still keeping the devices profile data that may be necessary + for core functionality and communication described in this document. -4.3 Multicast +3. Profile Change Event Notification Package - The enrollment request is sent to the multicast address for SIP - registration [6] "sip.mcast.net" (224.0.1.75). If a server does not - respond with a successful 2xx class response to the enrollment - request, the next discovery mechanism is attempted. + 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 provide the + location of the profile(s) via content indirection + [I-D.ietf-sip-content-indirect-mech]. -4.4 Manually Provisioned +3.1 Event Package Name - The UA MAY indicate to the user (or administrator) that automatic - discovery has failed. The UA SHOULD allow the user or administrator - to manually (perhaps using some out of band method e.g. beam, smart - card, etc.) enter the configuration server address and port to be - used for enrollment. + The name of this package is "sip-profile". This value appears in the + Event header field present in SUBSCRIBE and NOTIFY requests for this + package as defined in [RFC3265]. -5 Enrollment and Change Notification +3.2 Event Package Parameters - The enrollment and configuration change notification are paired - together and provided via the SIP SUBSCRIBE/NOTIFY framework [7]. - This document defines the profile on top of the SUBSCRIBE/NOTIFY - framework [7] for this purpose. + This package defines the following new parameters for the event + header: profile-type, vendor, model, version, effective-by. The + effective-by parameter is for use in NOTIFY requests only. The + others are for use in the SUBSCRIBE request, but may be used in + NOTIFY requests as well. - UA enrollment with the configuration server is accomplished via the - SUBSCRIBE request. A UA MUST enroll with the configuration server - prior to retrieving configuration data profiles. As part of the - enrollment the UA MUST identify itself, its configuration retrieval - protocol capabilities and configuration data profile requirements. + The profile-type parameter is used to indicate the profile type the + user agent wishes to obtain URLs for and be notified of change. This + parameter allows the URL semantics to be opaque to the subscribing + user agent as all it needs to know is the token value for this + parameter. This document defines two type categories of profiles. + The contents or format of the profiles is outside the scope of this + document. The two types of profiles define here are "user" and + "device". Specifying device type profile(s) indicates the desire for + the URL(s) and change notification of all profiles that are specific + to the device or user agent. Specifying user type profile(s) + indicates the desire for the URL(s) and change notification of all + profile(s) that are specific to the user. The user or device is + identified in the URI of the SUBSCRIBE request. The Accept header of + the SUBSCRIBE request MUST include the MIME types for all profile + content types that the subscribing user agent wishes to retrieve + profiles or receive change notifications. - The configuration server may use this information to decide how to - allocate resources (e.g. load balancing) to support the UA for its - specific configuration retrieval needs. The configuration server - may also use the UA enrollment event as the trigger to generate a - new set of configuration data for the specific UA (e.g. based upon - provisioned defaults and configuration profile context knowledge for - the environment). This allows the configuration server to provide - configuration data for a new UA without previously provisioning the - specific UA on the server. + The user or device token 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 be desirable to define + additional tokens for the profile-type header. This is to allow a + user agent to subscribe to that specific profile as opposed to the + entire class or set of user or device profiles. - Each profile that the device requires is obtained via a separate - enrollment or SUBSCRIBE request and SIP dialog. That is for each - different profile a device enrolls for, a different Call-Id is used. - The device names the profile MIME type in the SUBSCRIBE Accept - header field. The configuration server then delivers a URL (through - content indirection [15]) at which the device can retrieve the - profile in a subsequent NOTIFY request. Changes to the profile are - indicated in additional NOTIFY requests sent from the configuration - server. + The rational for the separation of user and device type profiles is + provided in section Section 2.3. It should be noted that either type + may indicate that zero or more URLs are provided in the NOTIFY + request. As discussed, a default user may be assigned to a device. + In this scenario the profile delivery server may provide the URL(s) + in the NOTIFY request for the default user when subscribing to the + device profile type. Effectively the device profile type becomes a + superset 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 user. This provides + the ability to support a hoteling function where a user may "login" + to any user agent and have it use a users profile(s). - The SUBSCRIBE request for enrollment is sent to the address(es) - identified in the discovery process until the first successful 2xx - class response is received. As part of the binding of the - SUBSCRIBE/NOTIFY framework a new MIME type must be named for each + The vendor, model and version parameters are tokens specified by the + vendor of the user agent. These parameters are useful to the profile + delivery server to effect the profiles provided. In some scenarios + it is desirable 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 profile + deliver server the ability to compensate for or take advantage of the + differences. - Petrie Informational - Expires Aug. 2003 7 - A Framework for SIP Feb. 2003 - User Agent Configuration + The "effective-by" parameter in the Event header of the NOTIFY + specifies the maximum number of seconds before the user agent MUST + make the new profile effective. A value of 0 (zero) indicates that + the user agent MUST make the profiles effective immediately (despite + possible service interruptions). This gives the profile delivery + server the power to control when the profile is effective. This may + be important to resolve an emergency problem or disable a user agent + immediately. - type of profile. The profile(s) MIME type(s) MUST be included in - the SUBSCRIBE Accept header field. + SUBSCRIBE request example: + Event: sip-profile;profile-type=device; + vendor=acme;model=Z100;version=1.2.3 - [Is it ok to allow a single SUBSCRIBE to request multiple profile - types in (e.g. for each MIME subtype application/sip-ua-user-profile - and application/sip-ua-device-profile)?] + NOTIFY request examples: + Event:sip-profile;effective-by=0 - If enrollment fails (i.e. no 2xx response to SUBSCRIBE), the UA - SHOULD re-discover the configuration server address and port as - described in section 3. + Event:sip-profile;effective-by=3600 -5.1 SUBSCRIBE +3.3 SUBSCRIBE Bodies - The SUBSCRIBE request is used by the UA to enroll in the - configuration domain of the configuration server. It uniquely - identifies the UA with vendor, model and serial number information. - The UA also MUST specify its capabilities for configuration - retrieval. The UA MUST indicate support for content indirection by - including the MIME type message/external-body in the SUBSCRIBE - Accept header field per [15]. + This package defines no new use of the SUBSCRIBE request body. - The configuration server SHOULD not send an error if it is - temporarily not able to provide the configuration data profile - listed in the SUBSCRIBE request Event header field. In the first - time out of the box case, the SUBSCRIBE dialog may be the only means - of communicating with the device as it does not yet have - configuration. The configuration server SHOULD send a 403 response - to the SUBSCRIBE if is not willing to provide the requested - configuration profile to the device. The configuration server - SHOULD provide the configuration data profile to the UA via content - indirection. If the configuration server sends a 301 Moved - Permanently response to the enrollment SUBSCRIBE, the UA SHOULD - cache the URL contained in the response Contact header field in - place of the address and port found during discovery for future - enrollment. +3.4 Subscription Duration - The device may request many configuration data profiles by - sending multiple SUBSCRIBE requests each in a different SIP - dialog. This may be useful if the device requires user - specific profiles for multiple users. In this case the - UserProfile parameter would vary for each SUBSCRIBE. - Alternately the device may require multiple types of profiles - where each SUBSCRIBE would have a different MIME type in the - Accept header field. + As profiles are generally static with infrequent changes, it is + recommended that default subscription duration be 86400 seconds (one + day). - The configuration server MAY use the enrollment (SUBSCRIBE request) - as the stimulus to generate a new instance of a configuration data - profile unique to the UA. Alternately the configuration server MAY - be provisioned ahead of time to know about new UAs and their - specific configuration data content (for example based upon serial - number, MAC address). +3.5 NOTIFY Bodies - Petrie Informational - Expires Aug. 2003 8 - A Framework for SIP Feb. 2003 - User Agent Configuration + The size of profile content is likely 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 NOTIFY body MUST use content indirection + [I-D.ietf-sip-content-indirect-mech] for providing the profiles. - The user agent forms the From field in the SUBSCRIBE in one of two - ways depending upon the type of profile that it is enrolling to. If - the user agent is enrolling to a device specific profile, the from - addr-spec is formed as: sip:@. If the - user agent is enrolling to a user specific profile the addr-spec is - formed as the users address of record. In this way the identity for - which the profile is desired is always specified in the From field. + The profile delivery server MUST include the Content-ID defined in + [I-D.ietf-sip-content-indirect-mech] for each profile URL. This is + to avoid unnecessary download of the profiles. Some user agents are + not able to make a profile effective without rebooting or restarting. + Rebooting is probably something to be avoided on a user agent + performing services such as telephony. In this way the Content-ID + allows the user agent to avoid unnecessary interruption of service as + well. The Content-Type MUST be specified for each URL. -5.1.1 Additional User Agent Field Parameters + Initially it is expected that most user agent vendors will use a + proprietary content type for the 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 content is to use + XML with name spaces [??] to segment the data into sets that the + user agent implementer may choose to support based upon desired + feature set. The specification of the content is out of the scope + of this document. - When the device first starts up out of the box, it has no user or - local configuration. The device MUST provide a unique identity such - that it is possible for the configuration server to generate - configuration profile for the device. The user agent MUST include - the User-Agent header in the SUBSCRIBE request. The following - additional User-Agent field parameters are defined for the purpose - of identifying the UA device: + Likewise the URL scheme used in the content indirection is outside + the scope of this document. This document is agnostic to the URL + schemes as the profile content may dictate what is required. 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. - Vendor û a token used to identify the UA vendor name +3.6 Notifier processing of SUBSCRIBE requests - Model û a token used to identify the UA hardware/software model + The general rules for processing SUBSCRIBE requests [RFC3265] apply + to this package. The notifier does not need to authenticate the + subscription as the profile content is not transported in the + SUBSCRIBE or NOTIFY transaction messages. Only URLs are transported + in the NOTIFY request which may be secured using the techniques in + section Section 6. - Version û a token used to identify the firmware/software version - currently installed on the UA + The behavior of the profile delivery server 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 + 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 automatically generated. The + design of this framework intentionally provides the flexibility of + implementation from simple/cheap to complex/expensive. - Serial û the token used to identify the serial number for the UA + If the user or device is not known to the profile delivery server, + the implementer MAY accept the subscription or reject it. It is + recommended that the implementer accept the subscription. It is + useful for the profile delivery server to maintain the subscription + as an administrator may add the user or device to the system, + defining the profile contents. This allow the profile delivery + server to immediately send a NOTIFY request with the profile URLs. + If the profile delivery server does 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 administrator are at different sites. - Note: on some hardware such as PCs and servers, there may be - multiple instances of a user agent installed. In these - scenarios only the serial number can be used to uniquely - distinguish instances. +3.7 Notifier generation of NOTIFY requests - Mac û the token used to identify the MAC address in hex for the UA + As in [RFC3265], the profile delivery server 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, the implementer has two choices. A NOTIFY MAY be + sent with no body or content indirection containing the profile + 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 user agent (e.g. a phone user agent with data to + call help desk and emergency services.). This is an implementation + and business policy decision. - From RFC 3261 [6] the User-Agent header field syntax is extended to: - User-Agent = "User-Agent" HCOLON product *( SEMI config-params ) + A user or device known and fully provisioned on the profile delivery + server SHOULD send a NOTIFY with content indirection containing URLs + for all of the profiles associated with the user or device (i.e. + which ever specified in the profile-type parameter). The device may + be associated with a default user. The URL(s) for this default user + profiles MAY be included with the URL(s) of the device if the profile + type specified is device. - 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 + A user agent can provide Hoteling by collecting a user’s AOR and + credentials needed to SUBSCRIBE and retrieve the user profiles from + the URL(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 user to login to enable + functionality beyond the default user’s restricted functionality. - Example: - User-Agent: model-a/1.5.0.1;vendor=acme + The profile delivery server MAY specify when the new profiles MUST be + made effective by the user agent. By default the user agent makes + the profiles effective as soon as it thinks that it is non-obtrusive. - The Vendor, Model, Version, Serial and Mac parameters MUST be - provided in the User-Agent header field for the enrollment SUBSCRIBE + However the profile delivery server MAY specify a maximum time in + seconds (zero or more), in the effective-by event header parameter, + by which the user agent MUST make the new profiles effective. - Petrie Informational - Expires Aug. 2003 9 - A Framework for SIP Feb. 2003 - User Agent Configuration +3.8 Subscriber processing of NOTIFY requests - request. Most profiles will either be device or user specific. All - config-params MUST be specified even when enrolling for user - profiles as the device characteristics may impact the content that - the profile server provides. + The user agent subscribing to this event package MUST adhere to the + NOTIFY request processing behavior specified in [RFC3265]. The user + agent MUST make the profiles effective as specified in the NOTIFY + request (see section Section 3.7). The user agent SHOULD use one of + the techniques specified in section [RFC3265] to securely retrieve + the profiles. -5.2 NOTIFY +3.9 Handling of forked requests - The NOTIFY message is sent by the configuration server to convey the - URL at which the UA can retrieve the requested configuration data - profile. This occurs in two contexts: + This event package allows the creation of only one dialog as a result + of an initial SUBSCRIBE request. The techniques to achieve this are + described in section 4.4.9 of [RFC3265]. - Immediately following the enrollment SUBSCRIBE the configuration - server MUST send a NOTIFY providing the URL for the configuration - data profile requested by the UA in the Event header field of the - SUBSCRIBE request. If the configuration server is not able to - provide the specific configuration data profile or it does not - want the UA to retrieve the specific configuration profile at that - time, it MAY defer sending NOTIFY. Later when the configuration - server is able to provide the data profile or it wishes the UA to - retrieve the data profile, the configuration server MAY send a - NOTIFY request containing the URL for the configuration data - profile which the UA SHOULD retrieve and make effective as soon as - it is safe to do so (e.g. when there are no active INVITE - dialogs). +3.10 Rate of notifications - If the configuration server becomes aware of a configuration - change that it wishes to be effective immediately on the UA, the - configuration server SHOULD send a NOTIFY message containing the - URL for the configuration data profile that the UA requested when - it enrolled. The configuration data profile with changed content - SHOULD have a different Content-ID entity header than that of the - last NOTIFY request. The UA SHOULD retrieve and make effective - the changed configuration URL immediately upon receipt of the - NOTIFY request. The UA MAY choose to wait to make the changes - effective (e.g. to prevent the change from disrupting active calls - on the UA). + 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. - [Do we need an option for the configuration server to tell the UA - that it MUST make the change immediately regardless of state? - Should this be the default?] +3.11 State Agents - The UA SHOULD send a 200 response to the NOTIFY immediately upon - receipt and validation of the solicited request. The configuration - server MUST include, in the change notification NOTIFY request, the - configuration data profile URL. The Content-ID entity header - associated with the configuration data profile with changed content - should be different than that of the previous NOTIFY. - This mechanism may be used by the configuration server to provide - firmware updates. For example on a UA that caches or has a - persistent firmware image: if the server realizes (e.g. from the - enrollment information) the UA is running the most currently - available firmware version, it could defer sending the NOTIFY with - the URL for the firmware. However at a later time when a new + State agents are not applicable to this event package. - Petrie Informational - Expires Aug. 2003 10 - A Framework for SIP Feb. 2003 - User Agent Configuration +3.12 Examples - firmware version is available the configuration server could send - a NOTIFY with the URL for the new firmware version, indicating the - UA SHOULD upgrade as soon as it is safe to do so. + SUBSCRIBE sip:00df1e004cd0@example.com SIP/2.0 + Event: sip-profile;profile-type=device;vendor=acme; + model=Z100;version=1.2.3 + From: sip:00df1e004cd0@acme.com;tag=1234 + To: sip:00df1e004cd0@acme.com;tag=abcd + Call-ID: 3573853342923422@10.1.1.44 + CSeq: 2131 SUBSCRIBE + Contact: sip:00df1e004cd0@10.1.1.44 + Content-Length: 0 -5.2.1 NOTIFY Body Content Format + NOTIFY sip:00df1e004cd0@10.1.1.44 SIP/2.0 + Event: sip-profile;effective-by=3600 + From: sip:00df1e004cd0@acme.com;tag=abcd + To: sip:00df1e004cd0@acme.com;tag=1234 + Call-ID: 3573853342923422@10.1.1.44 + CSeq: 321 NOTIFY + MIME-Version: 1.0 + Content-Type: multipart/mixed; boundary=boundary42 + Content-Length: ... -The NOTIFY request MUST contain a single part body with content -indirection [15]. 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 specifying the URL at which to retrieve the -profile. The body MUST contain a Content-Type entity header with the -MIME type of the profile as the value. The body MUST also contain a -Content-ID entity header which SHOULD change to a new unique value each -time the content of the URL changes. The Content-ID entity header -associated with the URL is intended to allow the UA to decide if it has -the latest content of the configuration data profile without having to -download and compare the contents. + --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 - Example: + Content-Type: application/z100-user-profile + Content-ID: <69ADF2E92@example.com> - NOTIFY sip:00df1e004cd0@acme.com SIP/2.0 - From: sip:sipuaconfig@sipuaconfig.acme.com;tag=1234 - To: sip:00df1e004cd0@acme.com;tag=abcd - Call-ID: 3573853342923422@10.1.1.123 - CSeq: 2131 INVITE + --boundary42 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: <1000957853@acme.com> + access-type="URL"; + expiration="Mon, 24 June 2002 09:00:00 GMT"; + URL="http://www.example.com/devices/ff00000036c5"; + size=1234 -6 Configuration Retrieval + Content-Type: application/z100-device-profile + Content-ID: <39EHF78SA@example.com> - The UA MUST retrieve its configuration data profile using the URL - specified by the configuration server in the NOTIFY request. If the - retrieval fails, the UA SHOULD not re-enroll until the SUBSCRIBE - session expires to avoid a cascade effect if the server goes down - temporarily. The device MAY re-try the profile retrieve of the - profile from the URL before the SUBSCRIBE expires. Should the re- - enrollment fail, the UA SHOULD re-discover the configuration server - as described in section 4. + --boundary42-- -7 Configuration Upload +3.13 Use of URIs to Retrieve State - If the UA or another entity wishes to modify a configuration data - profile it MAY make the change persistent on the configuration - server if it is authorized to do so. The configuration server - SHOULD support the ability to accept uploads via the same URL the UA - used to retrieve the configuration data profile. For HTTP and HTTPS - the UA does a POST with a multipart MIME attachment containing any - URL parameters in one part and the changed configuration data + The profile type specified determines what goes in the user part of + the SUBSRIBE URI. If the profile type requested is "device", the + user part is an identity that MUST be unique across all user agents + from all 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 agents supporting only a single user + at a time this is most easily accomplished using its MAC address. + Software based user agents running on general purpose hardware may + also be able to use the MAC address for identity. However in + situations where multiple instance of user agents are running on the + same hardware it may be necessary to use a another scheme, such as + using a unique serial number for the software. - Petrie Informational - Expires Aug. 2003 11 - A Framework for SIP Feb. 2003 - User Agent Configuration + If the profile type request is "user" the URI in the SUBSCRIBE + request is the address of record for the user. This allows the user + to specify (e.g. login) to the user agent by simply entering their + known identity. - profile [whole or changes only ?? define in profiles ??] in another - part as defined in [?]. If the UA or user is not permitted to make - the changes on the configuration server the configuration server - returns an HTTP error response code of 403 Forbidden. If the - configuration server returns a 403 the UA SHOULD disallow the - changes from being effective on the UA. The UA SHOULD not make the - changes effective until it receives a successful response (e.g. for - HTTP 2xx). +4. Profile Delivery Framework Details - If the URL is for HTTP/HTTPS the server MUST return the changed - configuration data profile in the response (assuming it was - allowed). The UA SHOULD use the configuration data profile contents - from the HTTP response as opposed to the data that was pushed in the - request as changes may occur from other sources. The server SHOULD - include a Content-ID header in the HTTP/HTTPS response. The - configuration server SHOULD send out a NOTIFY for this change, using - the same Content-ID entity header value as in the HTTP/HTTPS - response. This allows the UA to know that it already has the current - contents of the configuration data profile and SHOULD not download - that configuration data profile (i.e. it is safe to ignore the - NOTIFY as the Content-ID is the same). + The following describes how different functional steps of the profile + delivery framework work. Also described here is how the event + package defined in this document provides the enrollment and + notification functions within the framework. - [Alteratively the Content-ID could be put in the content as opposed - to the HTTP/HTTPS response] +4.1 Discovery of Subscription URI - [TBD û in 403 case restrict and provide feedback as to what - specifically is not allowed to be modified by the UA or user] + The discovery function is needed to bootstrap user agents to the + point of knowing where to enroll with the profile delivery server. + Section Section 3.13 describes how to form the URI used to sent the + SUBSCRIBE request for enrollment. However the bootstrapping problem + for the user agent (out of the box) is what to use for the host and + port in the URI. Due to the wide variation of environments in which + the enrolling user agent may reside (e.g. behind residential router, + enterprise LAN, ISP, dialup modem) and the limited control that the + administrator of 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 the specified order: SIP DHCP option [RFC3361], SIP DNS + SRV [RFC3263], DNS A record and manual. -8 Examples + 1. The first discovery mechanizm that SHOULD be tried is to + construct the SUBSCRIBE URI as described in Section 3.13 using + the host and port of out bound proxy discovered by the SIP DHCP + option as described in [RFC3361]. If the SIP DHCP option is not + provided in the DHCP response, no SIP response or a SIP failure + response other than for authorization is received for the + SUBSCRIBE request to the sip-profile event, the next discovery + mechanism SHOULD be tried. + 2. The local IP network domain for the user agent, either configured + or discovered via DHCP, should be used with the technique in + [RFC3263] to obtain a host and port to use 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 + sip-profile event, the next discovery mechanism SHOULD be tried. + 3. The fully qualified host name constructed using the host name + "sipuaconfig" and concatenated with the local IP network domain + should be tried next using the technique in [RFC3263] to obtain a + host and port to use 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 sip-profile event, the next + discovery mechanism SHOULD be tried. + 4. If all other discovery techniques fail, the user agent MUST + provide a manual means for the user to enter the host and port + used to construct the SUBSCRIBE URI. - Below is an example high level message flow for a new UA discovering - and using configuration data from a configuration server. Following - the high level message flows are some specific SIP messages - illustrating SUBSCRIBE and NOTIFY messages from enrollment and - configuration change notification. + Once a user agent has successfully discovered, enrolled, received a + NOTIFY response with profile URL(s), the user agent SHOULD cache the + SUBCRIBE URI to avoid having to rediscover the profile delivery + server again in the future. The user agent SHOULD NOT cache the + SUBSCRIBE URI until it receives a NOTIFY with profile URL(s). The + reason for this is that a profile delivery server may send 202 + responses to SUBSCRIBE requests and NOTIFY responses to unknown user + agent (see section Section 3.6) with no URLs. Until the profile + delivery server has sent a NOTIFY request with profile URL(s), it has + not agreed to provide profiles. -8.1 Example Message Flows + To illustrate why the user agent should not cache the SUBSCRIBE + URI until profile URL(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 + URLs in the NOTIFY request as it is not provisioned to accept the + user agent. The user then takes the laptop to their enterprise + LAN. If the user agent cached the SUBSCRIBE 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 profiles to the user agent.. - The following high level message flows illustrate the configuration - process of discovery, enrollment, configuration retrieval and change - notification with associated configuration retrieval. The UA uses - DHCP with the SIP [3] option requesting the configuration server - address and port. The DHCP server does not provide the - configuration server address or port. The UA then does a DNS lookup - for the configuration service within the local domain. It gets a - response from the DNS server for the configuration serverÆs fully - qualified host name. The UA then enrolls with the configuration - server by sending a SUBSCRIBE request for the profile type indicated - in the Event header. The configuration server sends back a - successful response. The configuration server then sends a NOTIFY - request with the URL for the configuration data profile that the UA - named in the enrollment SUBSCRIBE request. The UA sends a 200 - response to the NOTIFY. The UA then downloads the configuration +4.2 Enrollment with Profile Server - Petrie Informational - Expires Aug. 2003 12 - A Framework for SIP Feb. 2003 - User Agent Configuration + Enrollment is accomplished by subscribing to the event package + described in section Section 3. The enrollment process is useful to + the profile delivery server as it makes the server aware of user + agent to which it may delivery profiles (those user agents the + profile delivery server is provisioned to provide profiles to; those + present that the server may be provide profiles in the future; and + those that the server can automatically provide default profiles). + It is an implementation choice and business policy as to whether the + profile delivery server provides profiles to user agents that it is + not provisioned to do so. However the profile server SHOULD accept + (with 2xx response) SUBSCRIBE requests from any user agent. - data profile via the URL from the NOTIFY request. This process may - be repeated in parallel for each of the required profiles. The UA - is now configured as prescribed. +4.3 Notification of Profile Changes - Later ... an administrator makes a change to the configuration for - the UA on the configuration server. The configuration server on - behalf of the administrator, sends a 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 - data profile from the given URL. + The NOTIFY request in the sip-profile event package server two + purposes. First it provides the user agent with a means to obtain + the URL(s) for desired profiles without requiring the end user to + manually enter them. It also provides the means for the profile + delivery server to notify the user agent that the content of the + profiles have changed and should be made effective. - UA DHCP Server DNS Server Config. Server +4.4 Retrieval of Profile Data - Discovery + The user agent retrieves it's needed profile(s) via the URL(s) + provide in the NOTIFY request as specified in section Section 3.5. + The profile delivery server SHOULD secure the content of the profiles + using one of the techniques described in Section 6. The user agent + SHOULD make the new profiles effective in the timeframe described in + section Section 3.2. - IP config. req. - ==============> - IP config. wo/ local option - <============== - DNS A record req. for sipuaconfig host in local domain - =============================> - A record IP address returned for Host - <============================= + The contents of the profiles SHOULD be cached by the user agent. + This it to avoid the situation where the content delivery server is + not available, leaving the user agent non-functional. - Enrollment +4.5 Upload of Profile Changes - SIP SUBSCRIBE Event: sip-config - ==================================================> - 200 OK - <================================================== - SIP NOTIFY Event: sip-config w/ requested profile URL - <================================================== - 200 OK - ==================================================> + The user agent or other service MAY push changes up to the profile + delivery server using the technique appropriate to the profile's URL + 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. - Configuration retrieval +5. IANA Considerations - HTTP GET - ==================================================> - 200 OK (specific profile data in body) - <================================================== - . - . - . + [TBD] - Administrative change on configuration server via user interface - . - . - . +6. Security Considerations - Petrie Informational - Expires Aug. 2003 13 - A Framework for SIP Feb. 2003 - User Agent Configuration + Profiles may contain sensitive data such as user credentials. The + protection of this data is accomplished via the profile retrieval + function. This simplifies the security solution as the SIP event + package does not need to authenticate, authorize or protect the + contents of the SIP messages. Effectively the profile delivery + server will provide profile URL(s) to any one. The URLs themselves + are protected via authentication, authorization and snooping. Three + options for secure retrieval of profiles are follow: - Change Notification +6.1 Symmetric Encryption of Profile Data - SIP NOTIFY Event: sip-config w/ changed profile URL - <================================================== - 200 OK - ==================================================> - HTTP GET - ==================================================> - 200 OK (profile data in body) - <================================================== - . - . - . + One security technique is to encrypted the profiles on the content + delivery server using the AES symmetric encryption algorithm using a + key formed by a MD5 hash of the following: username ":" password. + The encrypted profiles are delivered by the content delivery server + via the URLs provided in the NOTIFY requests. Using this technique + the profile delivery server does not need to provide authentication + or authorization for the retrieval 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 + the simplest security technique as it does not require any public key + infrastructure or TLS implementation on the user agent (which often + has limited resources). - User changes data in a profile on the user agent - . - . - . +6.2 Client Certificate Authentication with HTTPS - Configuration Upload + In another technique the content delivery server authenticates the + user or user agent by requesting the client's certificate in the TLS + connection established as described by the profile URL. The content + delivery server authorizes the profile retrieval using the + certificate identity and business policy choices provide by the + server implementer. The profile data is obscured from snooping using + the encryption mechanisms provide by the TLS connect. This has 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 certificates to be in place + before enabling profile delivery. - HTTP POST (changed profile attached as multipart MIME) - ==================================================> - 200 OK (profile data in body, as change confirmation) - <================================================== - . - . - . +6.3 HTTPS Authentication -8.2 Example Messages + Alternatively the authentication mechanizms described in [RFC2617] + are used. The content delivery server authorizes the profile + retrieval using the certificate identity and business policy choices + provide by the server implementer. The profile data is obscure from + snooping using the encryption mechanisms provide by the TLS connect. + This also requires the overhead of a TLS implementation on the user + agent. - Petrie Informational - Expires Aug. 2003 14 - A Framework for SIP Feb. 2003 - User Agent Configuration + For all of these techniques the user agent should take care in how it + stores or caches the profiles to avoid theft. It is recommended that + a symmetric encryption technique such as that described in section + Section 6.1 be used. This also requires the overhead of a TLS + implementation on the user agent. - The following SUBSCRIBE request example is from a UA enrolling with - a configuration server. As this SUBSCRIBE request is for - configuration enrollment the Event header field contains the token - sip-config. The UA tells the configuration server that it would - like the configuration data profile of type: sip-ua-device-config in - the Accept header field. The UA tells the configuration server that - it is enrolling for 86400 seconds via the Expires header field. - During this period of time the configuration server MUST send a - change notification with the URL for the configuration data profile - 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 as the sip-config profile is device - specific not user specific. +7. Differences from Simple XCAP Package - UA => Config. Server + The author of this document had an action item from the July 2003 + IETF SIPPING WG meeting to consider resolving the differences of the + sip-profile and simple XCAP package [I-D.ietf-simple-xcap-package]. + It is the author's opinion that XCAP [I-D.rosenberg-simple-xcap] can + be supported by the framework and event package defined in this + document as it is simply a URL using the HTTP or HTTPS scheme. The + following lists the differences between the event packaged defined in + this document vs. the one defined in [I-D.ietf-simple-xcap-package]. - SUBSCRIBE sip: sipuaconfig@config.localdomain.com SIP/2.0 - To: sip:sipuaconfig@sipuaconfig.localdomain.com - From: sip:000aaa1234cd@localdomain.com;tag=aslkjhd - User-Agent: acme-model-a/1.5.0.1;Serial=1234567890;Mac=000aaa1234cd - Call-Id: 987654321@10.1.1.123 - Cseq: 1 SUBSCRIBE -Event: sip-config - Expires: 86400 - Content-Length: 0 - Accept: message/external-body application/sip-ua-device-config + The simple XCAP package requires that the relative path be known and + specified by the user agent when subscribing for change notification. + The event package in this document requires a token be known and + specified when subscribing. The advantage of the latter is that + bootstrapping is easier and well defined. It also leaves the freedom + of specifying the entire path of the profile URL up to the profile + delivery server. - The following is an example response to the above enrollment - request. + The event package defined in this document allows multiple URLs to be + provided in the NOTIFY request body as a result of a single token + specified in the SUBSCRIBE event parameter: profile-type. This + allows the profile delivery server to provide sets of profiles that + the user agent may not have enough information to specify in the + SUBSCRIBE URI (e.g. at boot strapping time the user agent may not + know the user's identity, but the profile delivery server may know + the default user for the device's identity) or the doc-component of + the simple XCAP package. - Config. Server => UA + The simple XCAP package provides profile data changes or deltas in + the body of the NOTIFY request. This is a desirable feature, but + approach in the simple XCAP package has a few disadvantages: - SIP/2.0 202 Accepted - To: sip:sipuaconfig@sipuaconfig.localdomain.com;tag=owiu1234 - From: sip:000aaa1234cd@localdomain.com;tag=aslkjhd - Call-Id: 987654321@10.1.1.123 - Cseq: 1 SUBSCRIBE - Content-Length: 0 + o SIP signaling requires authentication, authorization and + encryption (SIPS) to protect the profiles where the event package + in this document does not. SIPS may require more resources than + are available on many user agents. + o The content of a profile change may be large, causing + fragmentation and problems or constraints when using UDP. - Petrie Informational - Expires Aug. 2003 15 - A Framework for SIP Feb. 2003 - User Agent Configuration + The feature of providing profile data changes or deltas can be + provided in the package proposed in this document by providing two + URLs in the NOTIFY request for each profile (i.e. a URL for the + complete profile and another for the changes). - In the following example the device is requesting a user specific - profile Sip-User. The device specifies that it want the profile for - the user: sip:fredsmith@localdomain.com. + All other functional differences between + draft-ietf-sipping-config-framework-00 and + draft-ietf-simple-xcap-package-00 are believed to be resolved in this + version of this document. - UA => Config. Server +8. Open Issues - SUBSCRIBE sip: sipuaconfig@sipuaconfig.localdomain.com SIP/2.0 - To: sip:sipuaconfig@sipuaconfig.localdomain.com - From: sip:fredsmith@localdomain.com;tag=klhfkjncd - User-Agent: acme-model-a/1.5.0.1;Serial=1234567890;Mac=000aaa1234cd - Call-Id: 11111111@10.1.1.123 - Cseq: 1 SUBSCRIBE - Event: sip-config - Expires: 86400 - Content-Length: 0 - Accept: message/external-body application/sip-ua-user-config +9. Change History - The following is an example response to the above enrollment - request. +9.1 Changes from draft-ietf-sipping-config-framework-00.txt - Config. Server => UA + This version of the document was entirely restructured and re-written + from the previous version as it had been micro edited too much. - SIP/2.0 202 Accepted - To: sip:sipuaconfig@sipuaconfig.localdomain.com;tag=oqieu983 - From: sip:fredsmith@localdomain.com;tag=klhfkjncd - Call-Id: 11111111@10.1.1.123 - Cseq: 1 SUBSCRIBE - Content-Length: 0 + 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 following example is the immediate NOTITY request the - configuration server sent to the UA above enrollment. The URL in - the request body is for the configuration data profile the UA named - in the Event header field in the above SUBSCRIBE request from the - UA. + The URI used to subscribe to the event package is now either the user + or device address or record. - Config. Server => UA + The user agent information (vendor, model, MAC and serial number) are + now provided as event header parameters. - NOTIFY sip:10.1.1.123 SIP/2.0 - To: sip:sipuaconfig@sipuaconfig.localdomain.com;tag=owiu1234 - From: sip:000aaa1234cd@localdomain.com;tag=aslkjhd - Call-Id: 987654321@10.1.1.123 - 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: ... + Added a mechanism to force profile changes to be make effective by + the user agent in a specified maximum period of time. - Content-Type: application/sip-ua-device-config - Content-ID: 000aaa1234cd-3254@localdomain.com + Changed the name of the event package from sip-config to sip-profile - Petrie Informational - Expires Aug. 2003 16 - A Framework for SIP Feb. 2003 - User Agent Configuration + Three high level securityapproaches are now specified. - The following is an example response from the UA for the above - request. +9.2 Changes from draft-petrie-sipping-config-framework-00.txt - UA => Config. Server + Changed name to reflect SIPPING work group item - SIP/2.0 200 Ok - To: sip:sipuaconfig@sipuaconfig.localdomain.com;tag=owiu1234 - From: sip:000aaa1234cd@localdomain.com;tag=aslkjhd - Call-Id: 987654321@10.1.1.123 - Cseq: 22 NOTIFY - Content-Length: 0 + Synchronized with changes to SIP DHCP [RFC3361], SIP [RFC3261] and + [RFC3263], SIP Events [RFC3265] and content indirection + [I-D.ietf-sip-content-indirect-mech] - Assume at some later time, an administrator makes a change to the - content of the sip-config configuration data profile for the UA. - The configuration server sends a NOTIFY request to the UA for the - configuration change notification. This example request below - indicates the changed URL or content in the request body with a - higher sequence number. + Moved the device identity parameters from the From field parameters + to User-Agent header parameters. - Config. Server => UA + Many thanks to Rich Schaaf of Pingtel, Cullen Jennings of Cisco and + Adam Roach of Dyamicsoft for the great comments and input. - NOTIFY sip:10.1.1.123 SIP/2.0 - To: sip:sipuaconfig@sipuaconfig.localdomain.com;tag=owiu1234 - From: sip:000aaa1234cd@localdomain.com;tag=aslkjhd - Call-Id: 987654321@10.1.1.123 - 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: ... +9.3 Changes from draft-petrie-sip-config-framework-01.txt - Content-Type: application/sip-ua-device-config - Content-ID: 000aaa1234cd-3255@localdomain.com + Changed the name as this belongs in the SIPPING work group. - The following is an example response to the above request. + Minor edits - UA => Config. Server +9.4 Changes from draft-petrie-sip-config-framework-00.txt - SIP/2.0 200 Ok - To: sip:sipuaconfig@sipuaconfig.localdomain.com;tag=owiu1234 - From: sip:000aaa1234cd@localdomain.com;tag=aslkjhd - Call-Id: 987654321@10.1.1.123 - Cseq: 23 NOTIFY - Content-Length: 0 + 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. -9 Security Considerations + 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 - [This section needs to be greatly expanded and elaborated] + user specific profiles, these may also be managed on separate + servers. For instance in a roaming situation the device might get + it's 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. - SIP basic and digest authentication [6] MAY be used for - SUBSCRIBE/NOTIFY messages used for enrollment and configuration - change notification. There is a chicken and egg problem. Since the + Removed the Config-Expires header as it is largely superfluous with + the SUBSCRIBE Expires header. - Petrie Informational - Expires Aug. 2003 17 - A Framework for SIP Feb. 2003 - User Agent Configuration + Eliminated some of the complexity in the discovery mechanism. - 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. + Suggest caching information discovered about a profile delivery + server to avoid an avalanche problem when a whole building full of + devices powers up. - Configuration data profile URLs are communicated in the clear in the - NOTIFY requests from the configuration server. The security risk of - unauthorized access of the URL content can be mitigated if the - configuration server and UA both support basic authentication and - HTTP or HTTPS. There is a chicken and egg problem here as well - since the content of SUBSCRIBE/NOTIFY messages are transported in - the clear. Accordingly,the credentials that the UA uses for the - HTTP/HTTPS GET/POST 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. + Added the User-Profile From header field parameter so that the device + can a request a user specific profile for a user that is different + from the device's default user. - Using HTTPS over TLS[13] the configuration server MAY request the - certificate of the UA [14]. If this level of authentication is - desired, the UA vendor SHOULD ship the UA with a digital certificate - or provide a means by which this can be installed out of band. The - configuration server MUST be provisioned with the certificates of - authority allowed for each model of UA to be supported. +References - Using HTTPS the UA MAY request the certificate of the configuration - server. If this level of authentication is desired the UA must be - provisioned with the allowed certificate(s) of authority and - identities for the configuration server out of band (i.e. user or - administrator manual input, beamed via PDA, smart card, etc.) via a - secure means. + [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. -10 Open Issues + [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. - [Do we need an option for the configuration server to tell the UA - that it MUST make the change immediately regardless of state? - Should this be the default?] + [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. - [Upload to configuration server configuration data profiles whole or - changes only ?? define in profiles ??] + [I-D.rosenberg-simple-xcap] + Rosenberg, J., "The Extensible Markup Language (XML) + Configuration Access Protocol (XCAP)", + draft-rosenberg-simple-xcap-00 (work in progress), May + 2003. - [Security considerations section needs much elaboration] + [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. - Petrie Informational - Expires Aug. 2003 18 - A Framework for SIP Feb. 2003 - User Agent Configuration + [RFC0822] Crocker, D., "Standard for the format of ARPA Internet + text messages", STD 11, RFC 822, August 1982. -11 References + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. - [1] R. Droms, "Dynamic host configuration protocol," Request for - Comments (Draft Standard) 2131, Internet Engineering Task Force, - Mar. 1997. + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC + 2131, March 1997. - [2] S. Alexander and R. Droms, "DHCP options and BOOTP vendor - extensions," Request for Comments (Draft Standard) 2132, Internet - Engineering Task Force, Mar. 1997. + [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, March 1997. - [3] H.Schulzrinne , ôDynamic Host Configuration Protocol (DHCP- - for-IPv4)ö, Request for Comments (Draft Standard) 3361, Internet - Engineering Task Force, Aug. 2002. + [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. + and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, + January 1999. - [4] S. Bradner, "Key words for use in RFCs to indicate - requirement levels," Request for Comments (Best Current Practice) - 2119, Internet Engineering Task Force, Mar. 1997. + [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. - [5] A. Gulbrandsen, P. Vixie, and L. Esibov, ôA DNS RR for - specifying the location of services (DNS SRV),ö Request for - Comments 2782, Internet Engineering Task Force, Feb. 2000. + [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. - [6] Rosenberg, et. al., ôSIP: session initiation protocol,ö - Request for Comments 3261, Internet Engineering Task Force, June - 2002 + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. - [7] A. Roach, ôEvent Notification in SIPö, Request for Comments - 3265, Internet Engineering Task Force, June 2002 + [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. - [8] D. Crocker, ôSTANDARD FOR THE FORMAT OF ARPA INTERNET TEXT - MESSAGESö, Request for Comments 822, Internet Engineering Task - Force, Aug. 1982 + [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation + Protocol (SIP): Locating SIP Servers", RFC 3263, June + 2002. - [9] K. Sollins, ôTHE TFTP PROTOCOL (REVISION 2)ö, Request for - Comments 1350, Internet Engineering Task Force, Jul. 1992 + [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific + Event Notification", RFC 3265, June 2002. - [10] H Schulzrinne, ôConfiguring IP Telephony End Systemsö, - , IETF; Dec. 2000, Work in - progress + [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol + (DHCP-for-IPv4) Option for Session Initiation Protocol + (SIP) Servers", RFC 3361, August 2002. - [11] D. Petrie, ôRequirements for a SIP User Agent Configuration - Frameworkö, , IETF; - Feb. 2003, Work in progress + [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access + Protocol (v3): Technical Specification", RFC 3377, + September 2002. - [12] T. Berners-Lee et al, ôUniform Resource Locators (URL)ö, - Request for Comments 1738, Internet Engineering Task Force, Dec. - 1994 + [RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and + Applicability Statement for the Trivial File Transfer + Protocol (TFTP)", RFC 3617, October 2003. - [13] E. Rescorla, ôHTTP Over TLSö, Request for Comments 2818, - Internet Engineering Task Force, May 2000 +Author's Address - Petrie Informational - Expires Aug. 2003 19 - A Framework for SIP Feb. 2003 - User Agent Configuration + Daniel Petrie + Pingtel Corp. + 400 W. Cummings Park + Suite 2200 + Woburn, MA 01801 + US - [14] T. Dierks, C. Allen, ôThe TLS Protocol Version 1.0ö, Request - for Comments 2246, Internet Engineering Task Force, Jan. 1999 + Phone: "Dan Petrie (+1 781 970 0111)" + EMail: dpetrie@pingtel.com + URI: http://www.pingtel.com/ - [15] S. Olson ôA Mechanism for Content Indirection in Session - Initiation Protocol (SIP) Messagesö, , IETF; Nov. 2002, Work in progress +Appendix A. Acknowledgments - [16] H. Sinnreich, ôSIP Telephony Device Requirements, - Configuration and Dataö, , - IETF; Nov. 2002, Work in progress +Intellectual Property Statement - [10] H Schulzrinne, ôConfiguring IP Telephony End Systemsö, - , IETF; Dec. 2000, Work in - progress + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification can + be obtained from the IETF Secretariat. - [11] D. Petrie, ôRequirements for a SIP User Agent Configuration - Frameworkö, , IETF; - Feb. 2001, Work in progress + 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 required to practice + this standard. Please address the information to the IETF Executive + Director. - [12] T. Berners-Lee et al, ôUniform Resource Locators (URL)ö, - Request for Comments 1738, Internet Engineering Task Force, Dec. - 1994 + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. - [13] E. Rescorla, ôHTTP Over TLSö, Request for Comments 2818, - Internet Engineering Task Force, May 2000 +Full Copyright Statement - [14] T. Dierks, C. Allen, ôThe TLS Protocol Version 1.0ö, Request - for Comments 2246, Internet Engineering Task Force, Jan. 1999 + Copyright (C) The Internet Society (2003). All Rights Reserved. - [15] S. Olson ôA Mechanism for Content Indirection in Session - Initiation Protocol (SIP) Messagesö, , IETF; Nov. 2002, Work in progress + This document and translations of it may be copied and furnished to + others, 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 in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. -12 Author's Address + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. - Dan Petrie - Pingtel Corp. - 400 W. Cummings Park Phone: +1 781 938 5306 - Woburn, MA USA Email: dpetrie@pingtel.com + 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. - Petrie Informational - Expires Aug. 2003 20 +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society.