idnits 2.17.1 draft-ietf-sipping-config-framework-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2551. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2557. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 2482 has weird spacing: '... Change in XM...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The following requirements are presented: * the PNC MUST authenticate the identity of the user (if set to anything other than the default) for local-network profile requests that result in user-specific profile data containing sensitive information; for authentication, unless other mechanisms are employed, SIP Digest is used. If the authentication fails, the PNC MUST not include any user-specific information in the local-network profile * the PNC MAY NOT authenticate requests for the local-network profile that do not result in any user-specific sensitive data (irrespective of the value of the From field) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * the PNC MUST include the SIP Identity header as defined in [RFC4474] within profile notifications sent in response to local-network profile enrollment, unless an integrity-protected channel exists (for example, using S/MIME) * a device receiving profile notifications for local-network profiles MUST verify the SIP Identity header, unless transmitted over a previously established authenticated, integrity-protected channel. If the header verification fails, the device MUST not use the provided profile and treat it as a local-network profile enrollment failure and take measures such as enrollment retries == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the AOR presented in device profile enrollment is known by the PNC, the following requirements are presented: * the PNC MUST authenticate the AOR presented for enrollment using SIP Digest authentication, unless a previously established mutually authenticated channel exists (for example, using TLS). If the authentication fails, the PNC MUST not provide the requested device-specific profile. In such a scenario, the PNC MAY still provide a generic device profile for minimal services (for example, emergency calls in a telephony deployment, see [I-D.ietf-ecrit-phonebcp]) * if the profile data is provided in the enrollment notificaiton, the PNC MUST transmit it over an integrity-protected, confidential communications channel such as TLS == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the AOR presented in device profile enrollment is not known by the PNC, the following requirements are presented: * the PNC MUST not provide any sensitive information in the profile data * the device MUST transmit the request over an integrity-protected SIP communications channel. If none exists, the device MUST establish a TLS connection with the PNC and verify the PNC's certificate. If the PNC authentication fails or a secure communications channel cannot be established, the device MUST treat it as a device profile enrollment failure and take measures such as retry enrollment == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The user profile is expected to contain data specific to the user identity (AOR) being presented in the request. This identity is expected to be known in the network and associated with credentials. Thus, the following requirements are presented: * the device MUST transmit the request over an integrity-protected SIP communications channel. If none exists, the device MUST establish a TLS connection with the PNC and verify the PNC's certificate. If the PNC authentication fails or a secure communications channel cannot be established, the device MUST treat this as a user profile enrollment failure and take measures such as retry enrollment * the PNC MUST authenticate the AOR presented for enrollment using SIP Digest authentication, unless a previously established mutually authenticated channel exists (for example, using TLS). If the user authentication fails, the PNC MUST not provide the requested user-specific information. It MAY provide minimal profile information (such as connection to a customer support webpage) * if the profile data is provided in the enrollment notificaiton, the PNC MUST transmit it over an integrity-protected, confidential communications channel such as TLS == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: device profile * a PCC MUST authenticate a profile content retrieval request if the AOR presented is known. If the authentication fails, the PCC MUST not provide device-specific information. In such a scenario, the PCC MAY still provide a generic device profile for minimal services (for example, emergency calls in a telephony deployment, see [I-D.ietf-ecrit-phonebcp]) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: user profile * a PCC MUST authenticate a profile content retrieval request. If the user authentication fails, the PNC MUST not provide the requested user-specific information. It MAY provide minimal profile information (such as connection to a customer support webpage) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 11.3. Changes from draft-ietf-sipping-config-framework-08.txt The Request URI for profile-type=localnet now SHOULD not have a user part to make routing easier. The From field SHOULD now contain the device id so that device tracking can still be done. Described the concept of profile-type as a filter and added normative text requiring 404 for profile types not provided. Moved "application" profile type to draft-ietf-sipping-xcap-config-01. The "application" value for the profile-type parameter will also be used as a requirement that XCAP be supported. Fixed text on certificate validation. Added new HTTP header: Event to IANA section and clean up the IANA section. Added diagram for Service Provider use case schenario. Added clarification for HTTP Event header. Added clarification of subscriber handling of NOTIFY with no body. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2007) is 6263 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1837, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3268 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-00 == Outdated reference: A later version (-14) exists of draft-ietf-simple-xcap-diff-04 -- Obsolete informational reference (is this intentional?): RFC 2141 (Obsoleted by RFC 8141) Summary: 8 errors (**), 0 flaws (~~), 13 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING D. Petrie 3 Internet-Draft SIPez LLC. 4 Intended status: Standards Track S. Channabasappa, Ed. 5 Expires: September 4, 2007 CableLabs 6 March 3, 2007 8 A Framework for Session Initiation Protocol User Agent Profile Delivery 9 draft-ietf-sipping-config-framework-11 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 4, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document defines a framework to enable configuration of Session 43 Initiation Protocol (SIP) User Agents in SIP deployments. The 44 framework provides a means to deliver profile data that User Agents 45 need to be functional, automatically and with minimal (preferably 46 none) User and Administrative intervention. The framework describes 47 how SIP User Agents can discover sources, request profiles and 48 receive notifications related to profile modifications. As part of 49 this framework, a new SIP event package is defined for notification 50 of profile changes. The framework provides for multiple data 51 retrieval options, without requiring or defining retrieval protocols. 52 The framework does not include specification of the profile data 53 within its scope. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Data Model and Profile Types . . . . . . . . . . . . . . 9 62 3.3. Profile Life Cycle . . . . . . . . . . . . . . . . . . . 9 63 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.1. Simple Deployment Scenario . . . . . . . . . . . . . . . 10 65 4.2. Devices supporting multiple users from different 66 Service Providers . . . . . . . . . . . . . . . . . . . . 12 67 5. Profile Delivery Framework . . . . . . . . . . . . . . . . . . 14 68 5.1. Profile Enrollment . . . . . . . . . . . . . . . . . . . 17 69 5.1.1. Creation of Enrollment Subscription . . . . . . . . . 17 70 5.1.2. Profile Enrollment Request Transmission . . . . . . . 24 71 5.1.3. Profile Enrollment Notification . . . . . . . . . . . 24 72 5.2. Profile Content Retrieval . . . . . . . . . . . . . . . . 25 73 5.3. Profile Change Operation . . . . . . . . . . . . . . . . 25 74 5.4. Profile Change Notification . . . . . . . . . . . . . . . 25 75 5.5. Additional Considerations . . . . . . . . . . . . . . . . 25 76 5.5.1. Manual retrieval of the Device Profile . . . . . . . . 26 77 5.5.2. Device Types . . . . . . . . . . . . . . . . . . . . . 26 78 5.5.3. Profile Data . . . . . . . . . . . . . . . . . . . . . 27 79 5.5.4. Profile Data Frameworks . . . . . . . . . . . . . . . 27 80 5.5.5. Additional Profile Types . . . . . . . . . . . . . . . 28 81 5.5.6. Deployment considerations . . . . . . . . . . . . . . 28 82 6. Event Package Definition . . . . . . . . . . . . . . . . . . . 28 83 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . 29 84 6.2. Event Package Parameters . . . . . . . . . . . . . . . . 29 85 6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . 32 86 6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 33 87 6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 33 88 6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 33 89 6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . 34 90 6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . 35 91 6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 35 92 6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 35 93 6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . 35 94 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 95 7.1. Example 1: Device requesting profile . . . . . . . . . . 36 96 7.2. Example 2: Device obtaining change notification . . . . . 39 97 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 98 8.1. SIP Event Package . . . . . . . . . . . . . . . . . . . . 43 99 8.2. New HTTP Event Header . . . . . . . . . . . . . . . . . . 43 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 44 101 9.1. Profile Enrollment and Change Notification . . . . . . . 47 102 9.2. Profile Content Retrieval . . . . . . . . . . . . . . . . 49 103 9.3. Profile Change Operation . . . . . . . . . . . . . . . . 50 104 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 105 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 51 106 11.1. Changes from 107 draft-ietf-sipping-config-framework-10.txt . . . . . . . 51 108 11.2. Changes from 109 draft-ietf-sipping-config-framework-09.txt . . . . . . . 52 110 11.3. Changes from 111 draft-ietf-sipping-config-framework-08.txt . . . . . . . 52 112 11.4. Changes from 113 draft-ietf-sipping-config-framework-07.txt . . . . . . . 53 114 11.5. Changes from 115 draft-ietf-sipping-config-framework-06.txt . . . . . . . 53 116 11.6. Changes from 117 draft-ietf-sipping-config-framework-05.txt . . . . . . . 54 118 11.7. Changes from 119 draft-ietf-sipping-config-framework-04.txt . . . . . . . 54 120 11.8. Changes from 121 draft-ietf-sipping-config-framework-03.txt . . . . . . . 54 122 11.9. Changes from 123 draft-ietf-sipping-config-framework-02.txt . . . . . . . 55 124 11.10. Changes from 125 draft-ietf-sipping-config-framework-01.txt . . . . . . . 55 126 11.11. Changes from 127 draft-ietf-sipping-config-framework-00.txt . . . . . . . 55 128 11.12. Changes from 129 draft-petrie-sipping-config-framework-00.txt . . . . . . 56 130 11.13. Changes from draft-petrie-sip-config-framework-01.txt . . 56 131 11.14. Changes from draft-petrie-sip-config-framework-00.txt . . 56 132 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 133 12.1. Normative References . . . . . . . . . . . . . . . . . . 57 134 12.2. Informative References . . . . . . . . . . . . . . . . . 58 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 136 Intellectual Property and Copyright Statements . . . . . . . . . . 60 138 1. Introduction 140 SIP User Agents require configuration data to function properly. 141 Examples include network, device and user specific information. 142 Ideally, this configuration process should be automatic and require 143 minimal or no user intervention. 145 Many deployments of SIP User Agents require dynamic configuration and 146 cannot rely on pre-configuration. This framework provides a standard 147 means of providing dynamic configuration which simplifies deployments 148 containing SIP User Agents from multiple vendors. 150 This framework also addresses modifications to profiles and the 151 corresponding change notifications to the SIP User Agents using a new 152 event package. However, the framework does not define the content or 153 format of the actual profile data, leaving that to future 154 standardization activities. 156 2. Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [RFC2119]. 162 This document also reuses the SIP terminology defined in [RFC3261] 163 and [RFC3265], and specifies the usage of the following terms. 165 Device: software or hardware entity containing one or more SIP user 166 agents. It may also contain entities such as a DHCP client. 168 Device Provider: the entity responsible for managing a given device 170 Local Network Provider: the entity that controls the local network 171 to which a given device is connected 173 SIP Service Provider: the entity providing SIP services to users. 174 This can refer to private enterprises or public entities. 176 Profile: configuration data set specific to an entity (for example, 177 user, device, local network or other). 179 Profile Type: a particular category of Profile data (for example, 180 User, Device, Local Network or other). 182 Profile Delivery Server (PDS): the source of a Profile, it is the 183 logical collection of the Profile Notification Component (PNC) and 184 the Profile Content Component(PCC). 186 Profile Notification Component (PNC): the logical component of a 187 Profile Delivery Server that is responsible for enrolling devices 188 and providing profile notifications. 190 Profile Content Component (PCC): the logical component of a Profile 191 Delivery Server that is responsible for storing, providing access 192 to, and accepting profile content. 194 3. Overview 196 This section provides an overview of the configuration framework. It 197 introduces the reference model and explains key concepts such as the 198 Profile Life Cycle and the Profile Types. It is meant to serve as a 199 reference section for the document, rather than providing a specific 200 logical flow of material, as it may be necessary to revisit these 201 sections for a complete understanding of this document. The detailed 202 framework for the profile delivery, presented in Section 5, is based 203 on the concepts introduced in this section. 205 3.1. Reference Model 207 The design of the framework was the result of a careful analysis to 208 identify the configuration needs of a wide range of SIP deployments. 209 As such, the reference model provides for a great deal of 210 flexibility, while breaking down the interactions to their basic 211 forms which can be reused in many different scenarios. 213 In its simplest form, the reference model for the framework defines 214 the interactions between the Profile Delivery Server(PDS) and the 215 device. The device needs the profile data to effectively function in 216 the network. The PDS is responsible for responding to device 217 requests and providing the profile data. The set of interactions 218 between these entities is referred to as the Profile Life Cycle. 220 This reference model is illustrated in the diagram below. 222 +-------------------------+ 223 +--------+ Interactions | Profile Delivery Server | 224 | Device |<==========================>| +---+ +---+ | 225 +--------+ (Profile Life Cycle) | |PNC| |PCC| | 226 | +---+ +---+ | 227 +-------------------------+ 229 PNC = Profile Notification Component 230 PCC = Profile Content Component 232 Framework Reference Model 234 The PDS is subdivided into two logical components: 235 o Profile Notification Component (PNC), responsible for enrolling 236 devices in Profile event subscriptions and providing Profile 237 change notifications; 238 o Profile Content Component (PCC), responsible for storing, 239 providing access to, and accepting modifications related to 240 profile content. 242 SIP deployments vary considerably. For the sake of simplicity, two 243 deployment scenarios representing either end of the SIP deployment 244 spectrum are presented. 246 In the simplest scenario, a device connects through a network that is 247 controlled by a single provider who provides the local-network, 248 manages the devices, and offers services to the users. The Provider 249 propogates profile data to the device that contains all the necessary 250 information to obtain services in the network (including information 251 related to the local-network and the users). This is illustrated in 252 the following diagram. 254 -------------- 255 / Local-network, \ 256 | Device & Service | 257 \ Provider / 258 ---------------- 259 | 260 | 261 -------- 262 | Device | 263 -------- 264 | 265 | 266 ---- 267 |User| 268 ---- 270 Simple System Level Model 272 There are also deployments where the device can connect via a local 273 network that is not controlled by the SIP Service Provider, for 274 example, devices that connect via available public WiFi hotspots. In 275 such cases, Local Network Providers may wish to provide local network 276 information such as bandwidth constraints to the devices. 278 Devices may also be controlled by Device Providers that are 279 independent of the SIP Service Provider who provides user services, 280 for example, kiosks that allow users to access services anywhere. In 281 such cases the profile data may have to be obtained from different 282 profile sources: local network provider, device provider and SIP 283 service provider. This is indicated in the following diagram. 285 -------- 286 / SIP \ 287 | Service | -> Provides 'user' profile 288 | Provider | data (e.g., services 289 \ / configuration) 290 -------- -------- 291 | / \ 292 | | Device | -> Provides 'device' profile 293 | | Provider | data (e.g., device specifics) 294 | \ / 295 | --------- 296 | / 297 | / ------- 298 | / / Local \ 299 | / | Network | 300 | | | Provider | -> Provides 'local-network' profile 301 | | \ / data (e.g., bandwidth) 302 | | ------- 303 | | / 304 | | / 305 | | | 306 =================== 307 ( Local Network ) 308 =================== 309 | 310 | 311 -------- 312 | Device | -> Needs the 'local-network' 313 -------- and 'device' profile 314 / \ 315 / \ 316 ------ ------ 317 |User A| |User B| -> Users need 'user' profiles 318 ------ ------ 320 General System Level Model 322 As illustrated, the simplest deployments present a single profile 323 source whereas others may present multiple profile sources. To be 324 effective, a configuration framework needs to address various 325 deployment scenarios. To address a vast majority of deployments this 326 framework specifies three distinct profiles, each of which can be 327 obtained from a different provider, and a profile life cycle common 328 to any profile type. 330 The understanding is that deployments in general will support the 331 defined profile types. However, the framework allows for flexibility 332 in specialized cases. The devices are required to support all the 333 three profile types, unless configured otherwise (at a minimum they 334 need to support the device profile). The deployments are required to 335 support the device profile, and user profiles for known users. In 336 the presence of multiple profiles, a retrieval order is specified for 337 the devices. Additional profiles may also be specified outside the 338 scope of this document, but are expected to follow the same profile 339 life cycle. 341 3.2. Data Model and Profile Types 343 This framework specifies the following three profiles. Additional 344 extended profiles may also be defined. 346 Local Network Profile: contains configuration data related to the 347 local network to which a device is directly connected. It is 348 expected to be provided by the Local Network Provider. 350 Device Profile: cContains configuration data related to a specific 351 device, provided by the Device Provider. 353 User Profile: contains configuration data related to a specific 354 User, as required to reflect that user's preferences and the 355 particular services subscribed to. It is expected to be provided 356 by the SIP Service Provider providing services. 358 3.3. Profile Life Cycle 360 Automated profile delivery requires proactive behavior on the part of 361 a device. It also requires one or more PDSs which provide the 362 profile data. The set of communications that results in profile 363 delivery is characterized by the profile life cycle. Each profile is 364 propogated using the profile life cycle. 366 The life cycle is initiated when the device enrolls for profile data. 367 Enrollment either results in profile data or in information 368 referencing content indirection. In the case of content indirection, 369 the provided retrieval procedures are used to retrieve the profile. 370 Additionally, the profile life cycle allows for profile change 371 operations by authorized entities. If a profile change operation is 372 successful, it results in profile change notifications to all 373 enrolled devices. 375 The specific functional steps are as follows: 377 Profile Enrollment: the process by which a device requests, and if 378 successful, enrolls with a PDS capable of providing a profile. A 379 successful enrollment is indicated by a notification containing 380 the profile information (contents or content indirection 381 information). Depending on the request, this could also result in 382 a subscription to notification of profile changes. 384 Profile Content Retrieval: the process by which a device retrieves 385 profile contents, if the profile enrollment resulted in content 386 indirection information. 388 Profile Change Notification: the process by which a device is 389 notified of any changes to an enrolled profile. This may provide 390 the device with modified profile data or content indirection 391 information. 393 Profile Change Operation: The process by which an authorized entity 394 - such as a configuration management server or a device - pushes a 395 profile change to the PDS. 397 4. Use Cases 399 This section provides a small - non-comprehensive - set of 400 representative use cases to further illustrate how this Framework can 401 be utilized in SIP deployments. The first use case is simplistic in 402 nature, where as the second is relatively complex. The use cases 403 illustrate the effectiveness of the framework in either scenario. 405 For Security Considerations please refer to Section 9. 407 4.1. Simple Deployment Scenario 409 Description: Consider a deployment scenario (for example, a small 410 private enterprise) where a single entity enables the local network, 411 manages deployed devices and provides SIP services. The devices 412 never connect outside the local network and are each pre-configured 413 with a single user. 415 The following assumptions apply: 416 o The device profile data contains all the information necessary 417 for the device to participate in the local network and obtain 418 services 419 o The device is pre-configured to only request the device profile 420 o The enrollment notification contains the profile data (profile 421 content retrieval is not required) 423 The following diagram illustrates this use case and highlights the 424 communications relevant to the framework specified in this document. 426 +----------------------+ 427 +--------+ | Local Network, Device| 428 | Device | |& SIP Service Provider| 429 |(SIP UA)| | | 430 +--------+ | DHCP PDS | 431 +----------------------+ 432 | | | 433 (A) |<============== DHCP =============>| | 434 | | 435 | | 436 | | 437 (B) |<=========== Profile Enrollment ============>| 438 | | Profile data 439 | | is modified 440 | | via "Profile 441 | | Change Operation" 442 | | 443 (C) |<============ Profile Change ================| 444 | Notification | 445 | | 446 | | 448 The following is an explanation of the interactions in the diagram. 449 (A) Upon initialization, the device obtains IP configuration 450 parameters using DHCP 452 (B) The device performs Profile Enrollment for the device profile; 453 the device profile data is contained in the enrollment 454 notification 455 (C) Due to a modification of the device profile, a Profile Change 456 Notification is sent across to the device, along with the 457 modified profile 459 4.2. Devices supporting multiple users from different Service Providers 461 Description: Consider a single device (for example, Kiosk at an 462 airport) that allows for multiple users to obtain services from a 463 list of pre-configured SIP Service Providers. 465 The following assumptions apply: 466 o Provider A is the Device and Local Network Provider for the 467 device, and the SIP Service Provider for user A; Provider B is 468 the SIP Service Provider for user B 469 o Profile enrollment always results in content indirection 470 information requiring profile content retrieval 472 The following diagram illustrates the use case and highlights the 473 communications relevant to the framework specified in this document. 475 User User 476 A B +----------------------+ +----------------------+ 477 +--------+ | Provider | | Provider | 478 | Device | | A | | B | 479 |(SIP UA)| | | | | 480 +--------+ | DHCP PROXY PDS | | PROXY PDS | 481 +----------------------+ +----------------------+ 482 | | | | | | 483 (A) |<====DHCP====>| | | | | 484 | | | | | 485 | | | | | 486 | Profile Enrollment | | | | 487 (B) ||<====>| | | 488 | 489 | <> 490 | 491 | 492 | Profile Enrollment | | | | 493 (C) |<== device profile ==> |<====>| | | 494 | 495 | <> 496 | 497 . 498 . 499 . 500 [[User A obtains services]] 502 | Profile Enrollment | | | | 503 (D) |<= user profile (A) => |<====>| | | 504 | | | | | 505 | 506 | <> 507 . 508 . 509 . 510 . 511 [[User B obtains services]] 513 | 514 | Profile Enrollment | | 515 (E) |<=========== user profile (B) ==========>|<=========>| 516 | | | 517 | <> 518 | 520 The following is an explanation of the interactions in the diagram. 521 (A) Upon initialization, the device obtains IP configuration 522 parameters using DHCP. This also provides the local domain 523 information to help with local-network profile enrollment 524 (B) The device requests profile enrollment for the local network 525 profile. It receives an enrollment notification containing 526 content indirection information from Provider A's PDS. The 527 device retrieves the profile (this contains useful information 528 such as firewall port restrictions and available bandwidth) 529 (C) The device then requests profile enrollment for the device 530 profile. It receives an enrollment notification resulting in 531 device profile content retrieval. The device initializes the 532 User interface for services. 533 (D) User A with a pre-existing subscription with Provider A attempts 534 communication via the user Interface. The device uses the user 535 supplied information (including any credential information) and 536 requests profile enrollment for user A's profile. Successful 537 enrollment and profile content retrieval results in services for 538 user A. 539 (E) At a different point in time, user B with a pre-existing 540 subscription with Provider B attempts communication via the user 541 Interface. It enrolls and retreives user B's profile and this 542 results in services for user B. 544 5. Profile Delivery Framework 546 This section details the framework requirements. The Profile Life 547 Cycle (introduced in Section 3), is examined in further detail, with 548 requirements that apply to the device and the PDS. Unless explicitly 549 enhanced or indicated by an implementing specification, the device 550 and the PDS MUST follow the Profile Life Cycle requirements stated in 551 this section for all supported profile types. 553 A high-level representation of the framework is shown in the 554 following state diagram. Each of the specified profile types is 555 retrieved individually, in the specified order (see below), until all 556 needed Profiles have been received. 558 --------------- 559 / Device \ 560 \ Initialization/ 561 --------------- 562 | 563 | Completes IP initialization; 564 | Initializes SIP stack 565 | 566 V 567 -------------- 568 ________\ / All profiles?\ 569 | / \ retrieved? / 570 | -------------- 571 | | 572 | | NO; attempt 573 | | Profile Request 574 | | in specified order 575 | | 576 | V 577 | ------------ 578 ___________/ Profile \ 579 \ Life Cycle / 580 ------------ 582 Framework state diagram 584 The Profile Life Cycle, for each profile, is illustrated in the 585 diagram below. 587 ------------- { Device enrolls 588 / Profile \ ...{ and obtains 589 \ Enrollment / { enrollment 590 ------------- { notification 591 | 592 | 593 SUCCESS 594 | 595 | 596 ...PDS... V ...DEVICE... 597 __________________________________ 598 | | 599 | | 600 Active | 601 Subscription? | 602 (i.e, not a one | 603 time fetch) | 604 | | 605 | YES | 606 | | 607 V V 608 -------------- 609 / Profile Change \ __________________\ Content 610 \ Notification / / Indirection? 611 -------------- | 612 ^ | 613 | | YES 614 | SUCCESS | 615 | V 616 -------------- ---------------- 617 / Profile Change\ / Profile Content \ 618 \ Operation / \ Retrieval / 619 --------------- ----------------- 621 The Profile Life Cycle is initiated when the device transmits an 622 enrollment request for a specific profile. If this is accepted, it 623 results in an enrollment notification that contains the profile data 624 or profile content indirection information. Unless the enrollment 625 request indicates a one-time profile request, it also results in 626 enrollment for profile change notifications. If the profile is 627 modified at any point in time, the profile change notification is 628 transmitted to the device. Notifications due to profile enrollment 629 or change operation may result in content indirection in which case 630 the device uses profile content retrieval to obtain the profile data. 632 The Profile Life Cycle is the same for all the profile types, but 633 there are different requirements in each step based on the profile 634 types. This framework defines three profile types and an order that 635 MUST be followed by the device in requesting them (when it retrieves 636 two or more of the defined profile types), as follows: 638 o local-network 639 o device 640 o user 642 The sub-sections that follow specify the Profile Life Cycle details, 643 with specific requirements based on each profile type. 645 5.1. Profile Enrollment 647 The first step to obtaining a profile is PDS Enrollment. This is 648 initiated by the device and involves: 650 o creating a profile enrollment subscription 651 o transmitting a profile enrollment request 652 o receiving a profile enrollment notification 654 The processes are interlinked and retries encompass all three phases. 655 For example, if the enrollment request does not result in a profile 656 enrollment notification, the device is required to retry alternate 657 profile enrollment subscription creation options. Only when all the 658 enrollment subscription creation options are exhausted does the 659 device assume that the profile enrollment has failed. The processes 660 themselves are illustrated in the following sub-sections. 662 5.1.1. Creation of Enrollment Subscription 664 Each profile type requires its own subscription and based on the 665 entity requesting it, presents certain unique requirements (for 666 example, the device identifier is provided for the device profile 667 type where as the user identifier is provided for the user profile 668 type). Further, the profile types are aimed at different PDSs and 669 hence are identified differently (for example, the local-network is 670 identified by the local domain name where as the Service Provider is 671 identified based on the Service Provider's domain name). Some of 672 this information can be obtained in multiple ways (such as local 673 domain information that can be configured statically or dynamically) 674 and the device may have to try different information sources to 675 obtain the required information (for example, dynamic configuration 676 can override statically configured information). Based on these 677 considerations, the framework defines different rules for obtaining 678 and presenting the information for each profile type. Additionally, 679 when more than one information source is possible for the 680 information, it is presented as well. This is highlighted in the 681 following sub-sections. 683 5.1.1.1. SIP SUBSCRIBE for the Local-Network profile type 685 Before attempting to create a SIP SUBSCRIBE requesting the local- 686 network profile, the device MUST have established local network 687 connectivity. It MUST also have knowledge of the local network 688 domain either via static configuration or dynamic discovery via 689 DHCPv4 ([RFC2131]) or DHCPv6 ([RFC3315]). The following requirements 690 apply: 691 o the user part of the Request URI MUST NOT be provided. The host 692 and port part of the Request URI MUST be set to the concatenation 693 of "sipuaconfig" and the local network domain 694 o a user AOR, if known to the device MUST be used to populate the 695 "From" field, unless privacy requirements prohibit its use (this 696 is useful if the user has privileges in the local network beyond 697 those of the default user) 698 o if a user AOR is not known, the user portion of the "From" field 699 MUST be set to "anonymous"; the host and port portion of the 700 Request URI MUST be set to the concatenation of "sipuaconfig" and 701 the local network domain 702 o the "device-id" event header parameter MUST be set to the device 703 identifier that the device will use to request the device profile 705 For example: If the device requested and received the local domain 706 name via DHCP to be: airport.example.net, then the Local-Network 707 Profile SUBSCRIBE Request URI would look like: 709 sip:sipuaconfig.airport.example.net 711 The Event header would look like the following if the device decided 712 to provide MAC%3a00DF1E004CD0@airport.example.net as the device 713 identifier. (Alice may have a prior arrangement with the local 714 network operator giving her special privileges.) 716 Event: ua-profile;profile-type=local-network; 717 device-id="sip:MAC%3a00DF1E004CD0@airport.example.net" 719 The local-network profile SUBSCRIBE Request URI does not have a user 720 part so that the URI is distinct between the "local" and "device" 721 URIs when the domain is the same for the two. This provides a means 722 of routing to the appropriate PDS in domains where they are distinct 723 servers. 725 The From field is populated with the user AOR, if available. This 726 allows the local network provider to propagate user-specific profile 727 data, if available. The "device-id" event header parameter is set to 728 the device identifier. Even though every device may get the same (or 729 similar) Local-Network Profile, the uniqueness of the "device-id" 730 event header provides an important capability. Having unique From 731 fields allows the management of the local network to track devices 732 present in the network and consequently also manage resources such as 733 bandwidth and port allocation. 735 5.1.1.2. SIP SUBSCRIBE for the Device Profile Type 737 The device profile type allows the Service Provider managing a device 738 to provide device-specific configuration information. To enable 739 this, the Request URI needs to identify the device and the PDS domain 740 within which it is recognizable. Accordingly, this Framework 741 presents the following requirements for the formation of a 742 Subscription Request URI to request the "device" profile type 744 o the user portion of the Request URI MUST be set to a unique device 745 Identifier 746 o the host and port portion of the Request URI MUST be set to the 747 PDS domain 749 The following sub-sections explain identification of - and the 750 requirements related to - the device Identifier and the PDS domain 751 discovery. 753 5.1.1.2.1. Device Identifier 755 The device profile could be specific to each device in a SIP 756 deployment (for example, vendor/model) or shared across device types 757 (for example, based on services and service tiers). Further, the 758 same device might be provided different configuration profiles based 759 on deployment models. Device Identifiers play a significant role in 760 ensuring delivery of the correct profile and hence need to be unique 761 within a PDS domain to support the various deployment models. 763 This Framework requires that device Identifiers MUST be unique and 764 persistent over the lifetime of a device. Device Identifier 765 representations auto-generated by devices SHOULD be based on MAC 766 address or UUID ([RFC4122]) based representations. A device may use 767 alternate device identifiers (for example, SIP URIs) obtained via 768 pre-configuration or dynamic configuration (for example, device 769 profile). 771 If a MAC address is used, the following requirements apply: 772 o the device identifier MUST be formatted as the characters "MAC:" 773 followed by a twelve digit hexadecimal upper case representation 774 of the MAC address to form a proper URN ([RFC2141]). The MAC 775 address representation MUST NOT include visual separators such as 776 colons and whitespaces. The representation is denoted using the 777 following ABNF syntax 779 mac-ident = MAC ":" 12UHEX 780 MAC = %x4d.41.43 ; MAC in caps 781 UHEX = DIGIT / %x41-46 ; uppercase A-F 783 o the MAC address MUST only be used to represent a single device. 784 It MUST NOT be used if more than one device can potentially use 785 the same MAC Address (for example, multiple software entities on a 786 single platform). In such cases, the UUID representation SHOULD 787 be used 789 If a UUID is used, the following requirements MUST apply: 790 o the same approach to defining a user agent Instance ID as 791 [RFC4122] MUST be used 792 o when the URN is used as the user part of the URI, it MUST be URL 793 escaped 794 The colon (":") is not a legal character (without being 795 escaped) in the user part of an addr-spec ([RFC4122]). 796 For example the instance ID: 797 urn:uuid:f81d4fae-7ced-11d0-a765-00a0c91e6bf6@example.com 798 would be escaped to look as follows in a URI: 799 sip:urn%3auuid%3af81d4fae-7ced-11d0-a765-00a0c91e6bf6@ 800 example.com 801 The ABNF for the UUID representation is provided in [RFC4122] 803 5.1.1.2.2. PDS Domain Discovery 805 A device needs to identify the PDS domain to form the host and port 806 part of the Request URI. Ideally, this information should be 807 obtained via a single method. However, support for various 808 deployment models implies multiple device environments (for example, 809 residential routers, enterprise LANs, WLAN hotspots and dialup modem) 810 and presents hurdles to specifying a single method (for example, if a 811 device is always in the SIP Service Provider's network one could use 812 DHCP). To accommodate multiple deployment scenarios, the framework 813 specified in this document presents multiple approaches. 815 Devices MUST follow the procedures specified below in the order 816 presented, unless exceptions are made by device manufacturers or 817 Device Providers who may provide an option for the user to choose the 818 order (to suit specific deployment models, for example). 820 1. Service Provider pre-configuration 822 The device MAY be pre-configured with information that can be 823 utilized to identify the host and port of the Request URI. The 824 information can be provided - as examples - when the device is 825 manufactured, by using Service Provider entities (flash card, SIM 826 card) or via a Service Provider specific method (for example, 827 information or methods that lead to self subscription). If the 828 device is specified to utilize this approach, it MUST attempt to 829 do so before trying other methods. The details of how this is 830 accomplished are beyond the scope of this document. 832 2. IP Configuration 834 If pre-configuration is not an option, or not available, IP 835 configuration MUST be utilized to try and obtain information that 836 can help with identification of the host and port for the Request 837 URI. The framework defines the following methods within this 838 procedure to accomplish this. device MUST follow the methods 839 defined, in the order specified, i.e. if the first option cannot 840 be accomplished or results in a failure, then next method is 841 tried. Failure of a specific method is indicated when the device 842 cannot successfully complete Profile Enrollment. 844 2a. DHCP option for SIP server: 846 Devices that support DHCP MUST attempt to obtain the host and 847 port of the outbound proxy during the DHCP process, using the 848 DHCP option for SIP servers defined in [RFC3361] or [RFC3319] 849 (for IPv4 and IPv6 respectively), and use these as the host and 850 port part of the request URI. 852 For example, a MAC based device identifier with a DHCP SIP 853 servers option indicating example.com, the Request URI would be 854 constructed as sip:MAC%3aABC123EFD456@example.com 856 2b. Local IP Network Domain: 858 - devices that support DHCP MUST attempt to obtain the local IP 859 network domain during the DHCP process, using DHCP option 15 860 and use these as the host and port part of the request URI 861 using the technique specificed in [RFC3263] 862 + For example, a MAC based devices identifier with a DHCP 863 option 15 indicating local.example.com, the Request URI 864 would be constructed as 865 sip:MAC%3aABC123EFD456@local.example.com 867 - If the local IP network domain is available (previous 868 method), but the usage of the local IP Network domain results 869 in a failure, the device MUST use the local IP network domain, 870 prefixing it using the label "sipuaconfig." 872 + For example, a MAC based device Identifier with a DHCP 873 option 15 indicating local.example.com, the Request URI 874 would be constructed as 875 sip:MAC%3aABC123EFD456@sipuaconfig.local.example.com 877 3. Manual 879 If pre-configuration and IP Configuration are not options or 880 result in failures, the device SHOULD provide a means for the user 881 to present information that may help with the retrieval process. 882 Exceptions to this requirement MAY include devices with no user 883 interface appropriate for such entry. 885 This framework provides the following alternatives which can be 886 considered individually or together, in any order. 888 Device Provider PDS information: The user SHOULD be allowed to 889 present the host and port information which can help with the 890 creation of the Subscription URI to locate a PDS capable of 891 providing the profile. 893 Device Provider Configuration Server information The user MAY be 894 allowed to present information pertaining to a configuration 895 server that provides the device profile, not using a PDS as 896 defined in this framework. This framework specifies one such 897 possible process in Section 5.5.1. 899 5.1.1.3. SIP SUBSCRIBE for the User Profile Type 901 The user profile allows the responsible SIP Service Provider to 902 provide user-specific configuration. This is based on the user's 903 identity that is usually known in the network (for example, 904 associated with a subscription). Similar to the profiles provided to 905 devices, the content and propagation of user Profiles may partake 906 differently, based on deployment scenarios (for example, users 907 belonging to the same subscription might - or might not - be provided 908 the same profile). However, each user is uniquely identified in a 909 SIP Service Provider's network using an Address Of Record (AOR). 910 Devices implementing this framework MUST use the user's AOR to 911 populate the Request URI. 913 A device MAY obtain the user's AOR using various methods such as pre- 914 configuration, via the device profile or dynamically via a user 915 Interface. 917 5.1.1.4. Caching of SIP Subscription URIs 919 Creation of Subscription URIs is vital for successful Profile 920 Enrollment. Unlike the user Profile - Local-Network and device 921 profiles are expected to be requested based on discovered information 922 (for example, domain name discovered via DHCP). These profile types 923 have different goals and hence, caching of the Subscription URI 924 should be carefully considered. 926 The Local-Network profile type is aimed at obtaining information from 927 the local network. The local network can change across device 928 initializations (for example, user moves the device from a home 929 network to a workplace LAN). Thus, the device SHOULD NOT remember 930 local-network profile subscription URIs across initializations. The 931 device SHOULD re-create the Subscription URI every time it moves to a 932 new network or gets re-initialized. Exceptions may be cases where 933 the device can unambiguously determine changes to the local network. 935 The device profile type is aimed at obtaining information from the 936 SIP Service Provider managing the device. Once established, the 937 Service Provider does not change often (an example of an exception 938 would be the re-use of devices across Service Providers). However, 939 if the discovery process is used, the device can only be sure of 940 having reached the Service Provider upon successful Profile 941 Enrollment and Profile Notification. Thus, the device SHOULD cache 942 the Subscription URI for the device profile. When cached, the device 943 should use the cached Subscription URI upon a reset. Exceptions 944 include cases where the device identifier has changed (for example, 945 new network card with a new MAC address), Service Provider 946 information has changed (for example, user initiates change) or the 947 device cannot obtain its profile using the Subscription URI. 949 Devices SHOULD NOT cache the Subscription URI for the device 950 profile type until successful Profile Notification. The reason 951 for this is that a PDS may send 202 responses to SUBSCRIBE 952 requests and NOTIFY responses to unknown devices (see Section 6.6) 953 with no profile data or URIs. Thus, successful Profile 954 Notification is the only sure way to know that the Subscription 955 URI is valid. 957 5.1.2. Profile Enrollment Request Transmission 959 A device requesting a profile type specified in this document - and 960 is successful in forming a Subscription URI - MUST enroll using the 961 event package defined, and as specified, in this framework (see 962 Section 6) . The following requirements apply: 964 o the device MUST cater to the Event Package requirements specified 965 in Section 6.2 (for example, indicate the profile type being 966 requested in the profile-type parameter) 967 o the device MUST use the Subscription URI pertaining to the profile 968 type being requested, as specified in Section 5.1 970 The SIP infrastructure receiving such requests is expected to relay 971 and process profile enrollment requests. When a Profile Enrollment 972 request is received by a PDS, it SHOULD accept and respond to any 973 profile requests. Exceptions are when Service Provider policy 974 prevents such a response (for example, requesting entity is unknown). 976 Successful Profile Enrollment involves the following 977 o Acceptance of the SUBSCRIBE request by a PDS (indicated via a 200 978 response) 979 o Receipt of an initial Profile Notification within the timeouts as 980 specified in [RFC3265] 982 A device SHOULD follow suitable BackOff and Retry mechanisms if a 983 successful Profile Enrollment does not happen within the expected 984 period. 986 5.1.3. Profile Enrollment Notification 988 Successful Profile Enrollment is indicated by an enrollment 989 notification. This provides either a) the profile contents b) 990 content indirection information. If content indirection information 991 is provided, the device retrieves the profile using Profile Content 992 Retrieval. If the profile contents are provided, the following 993 requirements hold good: 995 o the device MUST make the new profiles effective within the 996 specified timeframe, as described in Section 6.2 997 o the device SHOULD cache (i.e. store persistently) the contents of 998 retrieved profiles, until overridden by subsequent Profile Change 999 Notifications (this avoids situations where a PDS is unavailable, 1000 leaving the device without required configuration) 1002 Failure to receive the initial NOTIFY following a successful 1003 enrollment MUST be treated the same as a failed enrollment. In such 1004 a scenario, the device MUST retry using alternate methods for 1005 creation of the enrollment subscription and transmit an enrollment 1006 request. If all the enrollment subscription creation have been 1007 exhausted, the device MUST treat it as a failure to obtain the 1008 profile and take appropriate measures. 1010 For NOTIFY content please refer to Section 6.5. 1012 5.2. Profile Content Retrieval 1014 Upon successful Profile Enrollment, the device can retrieve the 1015 documents pertaining to the requested profile directly or via the 1016 URI(s) provided in the NOTIFY request as specified in Section 6.5. 1017 Profile Content Retrieval protocols and frameworks are out of scope 1018 for this specification. 1020 5.3. Profile Change Operation 1022 Configuration Profiles can change over time. Modifications can be 1023 initiated by various entities (for example, via the device, back- 1024 office components and end-user web interfaces for configuration 1025 servers) and for various reasons (such as, change in user 1026 preferences, modifications to services, enterprise-imposed common 1027 features or restrictions). This framework allows for such changes to 1028 be communicated to the PDS, using the term Profile Change Operation. 1030 Any changes to a Profile as a result of Profile Change Operation MUST 1031 result in a Profile Notification to all enrolled devices for that 1032 Profile, if any. 1034 Definition of specific mechanisms for Profile Change Operation are 1035 out of scope of this document. 1037 5.4. Profile Change Notification 1039 Whenever a profile is changed, a PDS compliant with this framework 1040 MUST NOTIFY all the devices currently subscribed to the profile under 1041 consideration. This process is termed Profile Change Notification. 1043 For NOTIFY content please refer to Section 6.5. 1045 5.5. Additional Considerations 1047 This section provides a special case for retrieval of the device 1048 profile and highlights considerations and requirements on external 1049 entities such as Profile Data Frameworks. 1051 5.5.1. Manual retrieval of the Device Profile 1053 At a minimum, a device requires the device profile to be able to 1054 function effectively. However, the methods specified in this 1055 document may fail to provide a device with a profile. To illustrate 1056 with an example, consider the case of a device that finds itself 1057 behind a local network which does not provide information about DNS 1058 servers in the network (for example, misconfigured home network). In 1059 such cases, it would be beneficial to employ an alternative means to 1060 obtain the profile information (for example, resolvable DNS Servers 1061 could be part of the device profile). While this specification 1062 recommends that such a method be made available, it also specifies 1063 one such option using HTTP that is described in this sub-section. 1064 devices expected to encounter scenarios where propogation of the 1065 device profile can be hindered may employ the specified - or any 1066 alternative - process. 1068 The method being described involves the device to utilize a HTTPS URI 1069 (and any required credentials) based on either pre-configuration or 1070 manual entry by the user (in cases where such an interface is 1071 possible). This can lead to the retrieval of the device profile 1072 which may contain the properties for the SUBSCRIBE Request URI and 1073 credentials for Profile Enrollment and Profile Notification. This 1074 approach bootstraps the process in a different step in the cycle, but 1075 uses the same framework. 1077 Further, this document defines a new HTTP request header "Event". 1078 The syntax of the HTTP Event header is the same as the SIP Event 1079 header defined in this document. Similar to the SIP Event header the 1080 purpose of the HTTP Event header is to define the content of the 1081 state information to be retrieved. In particular, the state 1082 information is the device, user or local-network profile for the 1083 device. The SIP Event header parameters for this event package 1084 ("profile-type", "vendor", "model", "version") are also mandatory for 1085 the HTTP Event header as they are used to provide information as to 1086 what profile type is requested along with information about the 1087 device which may impact the contents of the profile. When the device 1088 starts with retrieval of the profile via HTTPS (instead of a SIP 1089 SUBSCRIBE to the event package), the device MUST provide the Event 1090 header defined. 1092 5.5.2. Device Types 1094 The examples in this framework tend to associate devices with 1095 entities that are accessible to end-users. However, this is not 1096 necessarily the only type of device that can utilize the specified 1097 Framework. devices can be entities such as user Interfaces (that 1098 allow for device Configuration), entities in the network that do not 1099 directly communicate with any users (for example, Service Provider 1100 deployed gateways) or elements in the Service Provider's network (for 1101 example, SIP servers). 1103 5.5.3. Profile Data 1105 This framework does not specify the contents for any profile type. 1106 Follow-on standardization activities can address profile contents. 1107 However, it makes the following assumptions and recommendations: 1109 o When the device receives multiple profiles, the contents of each 1110 profile type will only contain data relevant to the entity it 1111 represents. As an example, consider a device that obtains all the 1112 defined profiles. Information pertaining to the local network is 1113 contained in the 'local-network' profile and not the'user' 1114 profile. This does not preclude relevant data about a different 1115 entity from being included in a profile type, for example, the 1116 'device' profile type may contain information about the users 1117 allowed to access services via the device. A profile may also 1118 contain starting information to obtain subsequent Profiles 1119 o Data overlap SHOULD be avoided across profile types, unless 1120 necessary. If data overlap is present, prioritization of the data 1121 is left to data definitions. As an example, the device profile 1122 may contain the list of codecs to be used by the device and the 1123 user Profile (for a user on the device) may contain the codecs 1124 preferred by the user. Thus, the same data (usable codecs) is 1125 present in two profiles. However, the data definitions may 1126 indicate that to function effectively, any codec chosen for 1127 communication needs to be present in both the profiles. 1129 5.5.4. Profile Data Frameworks 1131 This framework specified in this document does not address profile 1132 data representation, storage or retrieval protocols. It assumes that 1133 the PDS has a PCC based on existing or other Profile Data Frameworks, 1134 for example, XCAP ([I-D.ietf-simple-xcap]). 1136 While it does not impose vast constraints on any such framework, it 1137 does allow for the propagation of profile content to PDS 1138 (specifically the PCC). Thus, Profile Data or Retrieval frameworks 1139 used in conjunction with this framework MAY consider techniques for 1140 propagating incremental, atomic changes to the PDS. For example, a 1141 means for propagating changes to a PDS is defined in XCAP 1142 ([I-D.ietf-simple-xcap]). 1144 5.5.5. Additional Profile Types 1146 This document specifies three profile types: local-network, device 1147 and user. However, there may be use cases for additional profile 1148 types. For example, profile types for application specific profile 1149 data. Definition of such additional profile types is not prohibited, 1150 but considered out of scope for this document. 1152 5.5.6. Deployment considerations 1154 The framework defined in this document was designed to address 1155 various deployment considerations, some of which are highlighted 1156 below. 1158 Provider relationships: 1159 o The local network provider and the SIP service provider can often 1160 be different entities, with no administrative or business 1161 relationship with each other; 1162 o There may be multiple SIP service providers involved, one for each 1163 service that a user subscribes to (telephony service, instant 1164 messaging, etc.); this Framework does not specify explicit 1165 behavior in such a scenario, but it does not prohibit its usage 1166 either 1167 o Each user accessing services via the same device may subscribe to 1168 different sets of services, from different Service Providers; 1170 User-device relationship: 1171 o The relationship between devices and users can be many-to-many 1172 (for example, a particular device may allow for many users to 1173 obtain subscription services through it, and individual users may 1174 have access to multiple devices); 1175 o Each user may have different preferences for use of services, and 1176 presentation of those services in the device user interface; 1177 o Each user may have different personal information applicable to 1178 use of the device, either as related to particular services, or 1179 independent of them. 1181 6. Event Package Definition 1183 The framework specified in this document proposes and specifies a new 1184 SIP Event Package as allowed by [RFC3265]. The purpose is to allow 1185 for devices to subscribe to specific profile types with PDSs and for 1186 the PDSs to notify the devices with - or pointers to - profile data. 1188 The requirements specified in [RFC3265] apply to this package. The 1189 following sub-sections specify the Event Package description and the 1190 associated requirements. The framework requirements are defined in 1191 Section 5. 1193 6.1. Event Package Name 1195 The name of this package is "ua-profile". This value appears in the 1196 Event header field present in SUBSCRIBE and NOTIFY requests for this 1197 package as defined in [RFC3265]. 1199 6.2. Event Package Parameters 1201 This package defines the following new parameters for the event 1202 header: 1203 "profile-type", "vendor", "model", "version", "effective-by", 1204 "device-id" and "network-user". 1205 The following rules apply: 1206 o All the new parameters, with the exception of the "effective-by" 1207 parameter MUST only be used in SUBSCRIBE requests and ignored if 1208 they appear in NOTIFY requests 1209 o The "effective-by" parameter is for use in NOTIFY requests only 1210 and MUST be ignored if it appears in SUBSCRIBE requests 1211 The semantics of these new parameters are specified in the following 1212 sub-sections. 1214 6.2.1. profile-type 1216 The "profile-type" parameter is used to indicate the token name of 1217 the profile type the user agent wishes to obtain data or URIs for and 1218 to be notified of subsequent changes. This document defines three 1219 logical types of profiles and their token names. They are as 1220 follows: 1222 local-network Specifying "local-network" type profile indicates the 1223 desire for profile data (URI when content indirection is used) 1224 specific to the local network. 1225 device Specifying "device" type profile(s) indicates the desire for 1226 the profile data (URI when content indirection is used) and change 1227 notification of the contents of the profile that is specific to 1228 the device or user agent. 1229 user Specifying "user" type profile indicates the desire for the 1230 profile data (URI when content indirection is used) and change 1231 notification of the profile content for the user. 1232 The "profile-type" is identified is identified in the Event header 1233 parameter: profile-type. A separate SUBSCRIBE dialog is used for 1234 each profile type. The profile type associated with the dialog can 1235 then be used to infer which profile type changed and is contained in 1236 the NOTIFY or content indirection URI. The Accept header of the 1237 SUBSCRIBE request MUST include the MIME types for all profile content 1238 types for which the subscribing user agent wishes to retrieve 1239 profiles or receive change notifications. 1241 In the following syntax definition using ABNF, EQUAL and token are 1242 defined in [RFC3261]. It is to be noted that additional profile 1243 types may be defined in subsequent documents. 1245 Profile-type = "profile-type" EQUAL profile-value 1246 profile-value = profile-types / token 1247 profile-types = "device" / "user" / "local-network" 1249 The "device", "user" or "local-network" token in the profile-type 1250 parameter may represent a class or set of profile properties. 1251 Follow-on standards defining specific profile contents may find it 1252 desirable to define additional tokens for the profile-type parameter. 1253 Also additional content types may be defined along with the profile 1254 formats that can be used in the Accept header of the SUBSCRIBE to 1255 filter or indicate what data sets of the profile are desired. 1257 6.2.2. vendor, model and version 1259 The "vendor", "model" and "version" parameter values are tokens 1260 specified by the implementer of the user agent. These parameters 1261 MUST be provided in the SUBSCRIBE request for all profile types. The 1262 implementer SHOULD use their DNS domain name (for example, 1263 example.com) as the value of the "vendor" parameter so that it is 1264 known to be unique. These parameters are useful to the PDS to affect 1265 the profiles provided. In some scenarios it is desirable to provide 1266 different profiles based upon these parameters. For example, feature 1267 property X in a profile may work differently on two versions of the 1268 same user agent. This gives the PDS the ability to compensate for or 1269 take advantage of the differences. In the following ABNF defining 1270 the syntax, EQUAL and quoted-string are defined in [RFC3261]. 1272 Vendor = "vendor" EQUAL quoted-string 1273 Model = "model" EQUAL quoted-string 1274 Version = "version" EQUAL quoted-string 1276 6.2.3. device-id 1278 The "device-id" parameter MUST be set when subscribing for "local- 1279 network" profiles. This identifies the device requesting the local- 1280 network profile. 1282 If the value of the "profile-type" parameter is not "local-network", 1283 the "device-id" parameter has no defined meaning and is ignored. In 1284 the following ABNF, EQUAL, LDQUOT, RDQUOT and addr-spec are defined 1285 in [RFC3261]. 1287 Device-Id = "device-id" EQUAL LDQUOT addr-spec RDQUOT 1289 6.2.4. network-user 1291 The "network-user" parameter MAY be provided in a subscription for a 1292 "device" profile. In such cases the device is requesting the PDS to 1293 recognize the indicated user as the default user for itself. 1295 If the value of the "profile-type" parameter is not "device", the 1296 "network-user" parameter has no defined meaning and is ignored. If 1297 the "network-user" parameter is provided in the SUBSCRIBE request, it 1298 MUST be present in the NOTIFY request as well. In the following 1299 ABNF, EQUAL, LDQUOT, RDQUOT and addr-spec are defined in [RFC3261]. 1301 Network-User = "network-user" EQUAL LDQUOT addr-spec RDQUOT 1303 6.2.5. effective-by parameter 1305 The "effective-by" parameter in the Event header of the NOTIFY 1306 request specifies the maximum number of seconds before the user agent 1307 must attempt to make the new profile effective. The "effective-by" 1308 parameter MAY be provided in the NOTIFY request for any of the 1309 profile types. A value of 0 (zero) indicates that the subscribing 1310 user agent must attempt to make the profiles effective immediately 1311 (despite possible service interruptions). This gives the PDS the 1312 power to control when the profile is effective. This may be 1313 important to resolve an emergency problem or disable a user agent 1314 immediately. The "effective-by" parameter is ignored in all messages 1315 other than the NOTIFY request. In the following ABNF, EQUAL and 1316 DIGIT are defined in [RFC3261]. 1318 Effective-By = "effective-by" EQUAL 1*DIGIT 1320 6.2.6. Summary of event parameters 1322 The following are example Event headers which may occur in SUBSCRIBE 1323 requests. These examples are not intended to be complete SUBSCRIBE 1324 requests. 1326 Event: ua-profile;profile-type=device; 1327 vendor="vendor.example.com";model="Z100";version="1.2.3" 1329 Event: ua-profile;profile-type="user"; 1330 vendor="premier.example.com";model="trs8000";version="5.5" 1332 The following are example Event headers which may occur in NOTIFY 1333 requests. These example headers are not intended to be complete 1334 SUBSCRIBE requests. 1336 Event: ua-profile;effective-by=0 1338 Event: ua-profile;effective-by=3600 1340 The following table shows the use of Event header parameters in 1341 SUBSCRIBE requests for the three profile types: 1343 profile-type || device | user | local-network 1344 ============================================= 1345 vendor || m | m | m 1346 model || m | m | m 1347 version || m | m | m 1348 device-id || | | m 1349 network-user || o | | 1350 effective-by || | | 1352 m - mandatory 1353 s - SHOULD be provided 1354 o - optional 1356 Non-specified means that the parameter has no meaning and should be 1357 ignored. 1359 The following table shows the use of Event header parameters in 1360 NOTIFY requests for the three profile types: 1362 profile-type || device | user | local-network 1363 ============================================= 1364 vendor || | | 1365 model || | | 1366 version || | | 1367 device-id || | | o 1368 network-user || o | | 1369 effective-by || o | o | o 1371 6.3. SUBSCRIBE Bodies 1373 This package defines no use of the SUBSCRIBE request body. If 1374 present, it MUST be ignored. 1376 Future enhancements to the framework may specify a use for the 1377 SUBSCRIBE request body (for example,, mechanisms using etags to 1378 minimize Profile Notifications to devices with current profile 1379 versions). 1381 6.4. Subscription Duration 1383 The duration of a subscription is specific to SIP deployments and no 1384 specific recommendation is made by this Event Package. If absent, a 1385 value of 86400 seconds is RECOMMENDED since the presence (or absence) 1386 of a device subscription is not time critical to the regular 1387 functioning of the PDS. 1389 It is to be noted that a one-time fetch of a profile can be 1390 accomplished by setting the 'Expires' parameter to a value of Zero, 1391 as specified in [RFC3265]. 1393 6.5. NOTIFY Bodies 1395 The framework specifying the Event Package allows for the NOTIFY body 1396 to contain the profile data or a pointer to the profile data using 1397 content indirection. The framework does not define any profile data 1398 and delegates specification of utilized MIME types Profile Data 1399 Frameworks. For profile data delivered via content indirection, the 1400 following apply: 1402 o the Content-ID MIME header, as described in [RFC4483] MUST be used 1403 for each Profile document URI 1404 o at a minimum, the "http:" and "https:" URI schemes MUST be 1405 supported; other URI schemas MAY be supported based on the Profile 1406 Data Frameworks (examples include FTP [RFC0959], HTTP [RFC2616], 1407 HTTPS [RFC2818], LDAP [RFC4510], XCAP [I-D.ietf-simple-xcap], 1408 XCAP-DIFF [I-D.ietf-simple-xcap-diff]) 1410 The NOTIFY body SHOULD include a MIME type specified in the 'Accept' 1411 header of the SUBSCRIBE. Further, if the Accept header of the 1412 SUBSCRIBE included the MIME type message/external-body (indicating 1413 support for content indirection) the content indirection SHOULD be 1414 used in the NOTIFY body for providing the profiles. If none are 1415 specified, the Profile Data frameworks are responsible for, and MUST 1416 specify, the MIME type to be assumed. 1418 6.6. Notifier Processing of SUBSCRIBE Requests 1420 A successful SUBSCRIBE request results in a NOTIFY with either 1421 profile contents or a pointer to it (via Content Indirection). If 1422 the NOTIFY is expected to contain profile contents or the Notifier is 1423 unsure, the SUBSCRIBE SHOULD be either authenticated or transmitted 1424 over an integrity protected SIP communication channels. Exceptions 1425 to authenticating such SUBSCRIBEs include cases where the identity of 1426 the Subscriber is unknown and the Notifier is configured to accept 1427 such requests. 1429 The Notifier MAY also authenticate SUBSCRIBE messages even if the 1430 NOTIFY is expected to only contain a pointer to profile data. 1431 Securing data sent via Content Indirection is covered in Section 9. 1433 If the profile type indicated in the "profile-type" Event header 1434 parameter is unavailable or the Notifier is configured not to provide 1435 it, the Notifier SHOULD return a 404 response to the SUBSCRIBE 1436 request. If the specific user or device is unknown, the Notifier MAY 1437 either accept or reject the subscription. 1439 When the Event header "profile-type" is "device" and the user agent 1440 has provided the user's AOR in the "network-user" parameter, the 1441 profile delivery server MAY set or change the default user associated 1442 with the device indicated in the Subscription request. However, the 1443 Notifier SHOULD authenticate the user indicated before making such a 1444 change. 1446 6.7. Notifier Generation of NOTIFY Requests 1448 As specified in [RFC3265], the Notifier MUST always send a NOTIFY 1449 request upon accepting a subscription. If the device or user is 1450 unknown and the Notifier choose to accept the subscription, the 1451 Notifier MAY either respond with profile data (for example, default 1452 profile data) or provide no profile information (i.e. no body or 1453 content indirection). 1455 If the URI in the SUBSCRIBE request is a known identity and the 1456 requested profile information is available (i.e. as specified in the 1457 profile-type parameter of the Event header), the Notifier SHOULD send 1458 a NOTIFY with profile data. Profile data MAY be sent as profile 1459 contents or via Content Indirection (if the content indirection MIME 1460 type was included in the Accept header). To allow for Content 1461 Indirection, the Subscriber MUST support the "http:" or "https:" URI 1462 schemas. If the Subscriber wishes to support alternative URI schemas 1463 it MUST be indicated in the "schemes" Contact header field parameter 1464 as defined in [RFC4483]. If the subscriber does not specify the URI 1465 scheme, the Notifier may use either "http:" or "https:". 1467 The Notifier MAY specify when the new profiles must be made effective 1468 by the Subscriber by specifying a maximum time in seconds (zero or 1469 more) in the "effective-by" event header parameter. 1471 If the SUBSCRIBE was received over an integrity protected SIP 1472 communications channel, the Notifier SHOULD send the NOTIFY over the 1473 same channel. 1475 6.8. Subscriber Processing of NOTIFY Requests 1477 A Subscriber to this event package MUST adhere to the NOTIFY request 1478 processing behavior specified in [RFC3265]. If the Notifier 1479 indicated an effective time (using the "effective-by" Event Header 1480 parameter), it SHOULD attempt to make the profiles effective within 1481 the specified time. Exceptions include deployments that prohibit 1482 such behavior in certain cases (for example, emergency sessions are 1483 in progress). When profile data cannot be applied within the 1484 recommended timeframe and this affects device behavior, any actions 1485 to be taken SHOULD be defined by the profile data definitions. By 1486 default, the Subscriber is RECOMMENDED to make the profiles effective 1487 as soon as possible. 1489 The Subscriber MUST always support "http:" or "https:" and be 1490 prepared to accept NOTIFY messages with those URI schemas.The 1491 subscriber MUST also be prepared to receive a NOTIFY request with no 1492 body. The subscriber MUST NOT reject the NOTIFY request with no 1493 body. The subscription dialog MUST NOT be terminated by a NOTIFY 1494 with no body. 1496 6.9. Handling of Forked Requests 1498 This Event package allows the creation of only one dialog as a result 1499 of an initial SUBSCRIBE request as described in section 4.4.9 of 1500 [RFC3265]. It does not support the creation of multiple 1501 subscriptions using forked SUBSCRIBE requests. 1503 6.10. Rate of Notifications 1505 The rate of notifications for the profiles in this framework is 1506 deployment specific, but expected to be infrequent. Hence, the Event 1507 Package specification does not specify a throttling or minimum period 1508 between NOTIFY requests 1510 6.11. State Agents 1512 State agents are not applicable to this Event Package. 1514 7. Examples 1516 This section provides examples along with sample SIP message bodies 1517 relevant to this framework. Both the examples are derived from a 1518 snapshot of Section 4.1, specifically the request for the device 1519 profile. The examples are purely informative and in case of 1520 conflicts with the framework or protocols used for illustration, the 1521 latter should be deemed normative. 1523 7.1. Example 1: Device requesting profile 1525 This example illustrates the detailed message flows between the 1526 device and the SIP Service Provider's network for requesting and 1527 retrieving the profile (the flow uses the device profile as an 1528 example). 1530 The following are assumed for this example: 1532 o Device is assumed to have established local network connectivity; 1533 NAT and Firewall considerations are assumed to have been addressed 1534 by the SIP Service Provider 1535 o examples are a snapshot only and do not illustrate all the 1536 interactions between the device and the Service Provider's network 1537 (and none between the entities in the SIP Service Provider's 1538 network) 1539 o All SIP communication with the SIP Service Provider happens via a 1540 SIP Proxy 1541 o HTTP is assumed to be the Profile Data method used (any suitable 1542 alternative can be used as well) 1543 o TLS is assumed to be the protocol for securing the Profile Content 1544 Retrieval (any other suitable protocol can be employed); 1545 authentication and security requirements are not addressed 1547 The flow diagram and an explanation of the messages follow. 1549 +----------------------+ 1550 +--------+ | SIP Service Provider | 1551 | Device | | | 1552 |(SIP UA)| | SIP PDS HTTP | 1553 +--------+ | PROXY Server | 1554 | | 1555 +----------------------+ 1556 | | | | 1557 | | | | 1558 | SUBSCRIBE | | | 1559 (SReq)|--------device profile--------->| | | 1560 | |------>| | 1561 | |200 OK | | 1562 | 200 OK |<------| | 1563 (SRes)|<-------------------------------| | | 1564 | | | | 1565 | | NOTIFY| | 1566 | NOTIFY (Content Indirection)|<------| | 1567 (NTFY)|<-------------------------------| | | 1568 | 200 OK | | | 1569 (NRes)|------------------------------->|200 OK | | 1570 | |------>| | 1571 | | 1572 | | 1573 | | 1574 |<<<<<<<<<<<<< TLS establishment >>>>>>>>>>>>>| 1575 | | 1576 | HTTP Request | 1577 (XReq)|---------------------------------------------->| 1578 | | 1579 | HTTP Response | 1580 (XRes)|<----------------------------------------------| 1581 | | 1583 (SReq) 1585 the device transmits a request for the 'device' profile using the 1586 SIP SUBSCRIBE utilizing the Event Package specified in this 1587 framework. 1589 * Note: Some of the header fields (for example, Event, via) are 1590 continued on a separate line due to format constraints of 1591 this document 1593 SUBSCRIBE sip:MAC%3a000000000000@sip.example.net SIP/2.0 1594 Event: ua-profile;profile-type=device;vendor="vendor.example.net"; 1595 model="Z100";version="1.2.3";network-user="sip:user@sip.example.net" 1596 From: sip:MAC%3A000000000000@sip.example.net;tag=1234 1597 To: sip:MAC%3A000000000000@sip.example.net 1598 Call-ID: 3573853342923422@192.0.2.44 1599 CSeq: 2131 SUBSCRIBE 1600 Contact: sip:MAC%3A000000000000@sip.example.net 1601 Via: SIP/2.0/TCP 192.0.2.41; 1602 branch=z9hG4bK6d6d35b6e2a203104d97211a3d18f57a 1603 Accept: message/external-body, application/x-z100-device-profile 1604 Content-Length: 0 1606 (SRes) 1608 the SUBSCRIBE request is received by a SIP Proxy in the Service 1609 Provider's network which transmits it to the PDS. The PDS accepts 1610 the response and responds with a 200 OK 1611 * Note: The device and the SIP proxy may have established a 1612 secure communications channel (for example, TLS) 1614 (NTFY) 1616 subsequently, the PDS transmits a SIP NOTIFY message indicating 1617 the profile location 1618 * Note: Some of the fields (for example, content-type) are 1619 continued on a separate line due to format constraints of this 1620 document 1622 NOTIFY sip:MAC%3A000000000000@192.0.2.44 SIP/2.0 1623 Event: ua-profile;effective-by=3600 1624 From: sip:MAC%3A000000000000@sip.example.net;tag=abca 1625 To: sip:MAC%3A000000000000@sip.example.net;tag=1231 1626 Call-ID: 3573853342923422@192.0.2.44 1627 CSeq: 322 NOTIFY 1628 Via: SIP/2.0/UDP 192.0.2.3; 1629 branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d0 1630 MIME-Version: 1.0 1631 Content-Type: message/external-body; access-type="URL"; 1632 expiration="Mon, 01 Jan 2010 09:00:00 UTC"; 1633 URL="http://sip.example.net/z100-000000000000.html"; 1634 size=9999; 1635 hash=10AB568E91245681AC1B 1637 Content-Type: application/x-z100-device-profile 1638 Content-ID: <39EHF78SA@sip.example.net> 1639 . 1640 . 1641 . 1643 (NRes) 1645 Device accepts the NOTIFY message and responds with a 200 OK 1647 (XReq) 1649 once the necessary secure communications channel is established, 1650 the device sends an HTTP request to the HTTP server indicated in 1651 the NOTIFY 1653 (XRes) 1655 the HTTP server responds to the request via a HTTP response 1656 containing the profile contents 1658 7.2. Example 2: Device obtaining change notification 1660 The following example illustrates the case where a user (X) is 1661 simultaneously accessing services via two different devices (for 1662 example, Multimedia entities on a PC and PDA) and has access to a 1663 user Interface (UI) that allows for changes to the user profile. 1665 The following are assumed for this example: 1667 o The devices (A & B) obtain the necessary profiles from the same 1668 SIP Service Provider 1669 o The SIP Service Provider also provides a user Interface (UI) that 1670 allows the user to change preferences that impact the user profile 1672 The flow diagram and an explanation of the messages follow. 1673 o Note: The example only shows retrieval of user X's profile, but it 1674 may request and retrieve other profiles (for example, local- 1675 network, Device). 1677 ----- ----- 1678 |User |_________| UI* | * = User Interface 1679 | X | | | 1680 ----- ----- 1681 / \ 1682 / \ 1683 / \ +----------------------+ 1684 +--------+ +--------+ | SIP Service Provider | 1685 | Device | | Device | | | 1686 | A | | B | | SIP PDS HTTP | 1687 +--------+ +--------+ | PROXY Server | 1688 +----------------------+ 1689 | | | | 1690 | | | | 1691 (A-EX)|<=Enrolls for User X's profile=>|<=====>| | 1692 | | | | 1693 | | 1694 (A-RX)|<===Retrieves User X's profile================>| 1695 | | 1696 | | | | | 1697 | | Enrolls for | | | 1698 | (B-EX)|<== User X's ==>|<=====>| | 1699 | | profile | | | 1700 | | | | | 1701 | | | 1702 | (B-RX)|<= Retrieves User X's profile=>| 1703 | | 1704 | | | 1705 | (HPut)|---------------------->| 1706 | | | 1707 | (HRes)|<----------------------| 1708 | | 1709 | | | | 1710 | | NOTIFY| | 1711 | NOTIFY |<------| | 1713 (A-NT)|<-------------------------------| | | 1714 | 200 OK | | | 1715 (A-RS)|------------------------------->|200 OK | | 1716 | |------>| | 1717 | | 1718 | | | NOTIFY| | 1719 | | NOTIFY |<------| | 1720 | (B-NT)|<---------------| | | 1721 | | 200 OK | | | 1722 | (B-RS)|--------------->|200 OK | | 1723 | | |------>| | 1724 | | 1725 | | 1726 (A-RX)|<===Retrieves User X's profile================>| 1727 | | 1728 | | | 1729 | | | 1730 | (B-RX)|<= Retrieves User X's profile=>| 1731 | | | 1733 (A-EX) Device A discovers, enrolls and obtains notification related 1734 to user X's profile 1735 (A-RX) Device A retrieves user X's profile 1736 (B-EX) Device B discovers, enrolls and obtains notification related 1737 to user X's profile 1738 (B-RX) Device B retrieves user X's profile 1739 (HPut) Changes affected by the user via the user Interface (UI) are 1740 uploaded to the HTTP Server 1741 * Note: The UI itself can act as a device and subscribe to user 1742 X's profile. This is not the case in the example shown. 1743 (HRes) Changes are accepted by the HTTP server 1744 (A-NT) PDS transmits a NOTIFY message to device A indicating the 1745 changed profile. A sample message is shown below: 1746 Note: Some of the fields (for example, Via) are continued on a 1747 separate line due to format constraints of this document 1749 NOTIFY sip:userX@192.0.2.44 SIP/2.0 1750 Event: ua-profile;effective-by=3600 1751 From: sip:userX@sip.example.net;tag=abcd 1752 To: sip:userX@sip.example.net.net;tag=1234 1753 Call-ID: 3573853342923422@192.0.2.44 1754 CSeq: 322 NOTIFY 1755 Via: SIP/2.0/UDP 192.0.2.3; 1756 branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d1 1757 MIME-Version: 1.0 1758 Content-Type: message/external-body; access-type="URL"; 1759 expiration="Mon, 01 Jan 2010 09:00:00 UTC"; 1760 URL="http://www.example.com/user-x-profile.html"; 1761 size=9999; 1762 hash=123456789AAABBBCCCDD 1763 . 1764 . 1765 . 1767 (A-RS) Device A accepts the NOTIFY and sends a 200 OK 1768 (B-NT) PDS transmits a NOTIFY message to device B indicating the 1769 changed profile. A sample message is shown below: 1770 Note: Some of the fields (for example, Via) are continued on a 1771 separate line due to format constraints of this document 1773 NOTIFY sip:userX@192.0.2.43 SIP/2.0 1774 Event: ua-profile;effective-by=3600 1775 From: sip:userX@sip.example.net;tag=abce 1776 To: sip:userX@sip.example.net.net;tag=1235 1777 Call-ID: 3573853342923422@192.0.2.43 1778 CSeq: 322 NOTIFY 1779 Via: SIP/2.0/UDP 192.0.2.3; 1780 branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d2 1781 MIME-Version: 1.0 1782 Content-Type: message/external-body; access-type="URL"; 1783 expiration="Mon, 01 Jan 2010 09:00:00 UTC"; 1784 URL="http://www.example.com/user-x-profile.html"; 1785 size=9999; 1786 hash=123456789AAABBBCCCDD 1787 . 1788 . 1789 . 1791 (B-RS) Device B accepts the NOTIFY and sends a 200 OK 1792 (A-RX) Device A retrieves the updated profile pertaining to user X 1793 (B-RX) Device B retrieves the updated profile pertaining to user X 1795 8. IANA Considerations 1797 There are two IANA considerations associated with this document, SIP 1798 Event Package and HTTP header. These are outlined in this section. 1800 8.1. SIP Event Package 1802 This specification registers a new event package as defined in 1803 [RFC3265]. The following information required for this registration: 1805 Package Name: ua-profile 1806 Package or Template-Package: This is a package 1807 Published Document: RFC XXXX (Note to RFC Editor: Please fill in 1808 XXXX with the RFC number of this specification). 1809 Persons to Contact: Daniel Petrie dan.ietf AT SIPez DOT com, 1810 sumanth@cablelabs.com 1811 New event header parameters: profile-type, vendor, model, version, 1812 effective-by, device-id, network-user (the profile-type parameter 1813 has predefined values. The new event header parameters do not) 1814 The following table illustrates the additions to the IANA SIP Header 1815 Field Parameters and Parameter Values: (Note to RFC Editor: Please 1816 fill in XXXX with the RFC number of this specification) 1818 Predefined 1819 Header Field Parameter Name Values Reference 1820 ---------------------------- --------------- --------- --------- 1821 Event profile-type Yes [RFCXXXX] 1822 Event vendor No [RFCXXXX] 1823 Event model No [RFCXXXX] 1824 Event version No [RFCXXXX] 1825 Event effective-by No [RFCXXXX] 1826 Event device-id No [RFCXXXX] 1827 Event network-user No [RFCXXXX] 1829 8.2. New HTTP Event Header 1831 This document defines a new permanent HTTP request header field: 1832 Event. 1833 Header field name: Event 1834 Applicable protocol: http 1835 Status: standard 1836 Author/Change controller: IETF 1837 Specification document(s): [RFCXXXX] (Note to RFC Editor: Please 1838 fill in XXXX with the RFC number of this specification). 1840 9. Security Considerations 1842 The framework specified in this document allows for the propagation 1843 of device profile data (Section 5.5.3). To accomplish this, it 1844 specifies a Profile Life Cycle (Section 3.3) and an Event Package 1845 (Section 6). 1847 The Profile Life Cycle consists of three distinct communication 1848 channels: Profile Enrollment and Change Notification, Profile Content 1849 Retrieval, and Profile Change Operation. 1851 +------+ +-----+ 1852 | | | | 1853 |Device| | PNC | 1854 | | | | 1855 +------+ +-----+ 1856 | | 1857 | Profile Enrollment | 1858 |---------------------->| 1859 | | 1860 | Profile Notification | (initial 1861 |<----------------------| or upon 1862 | | a change) 1864 +------+ +-----+ 1865 | | | | 1866 |Device| | PCC | 1867 | | | | 1868 +------+ +-----+ 1869 | | 1870 | Profile Request | (When content 1871 |---------------------->| indirection 1872 | | is used) 1873 | Profile Response | 1874 |<----------------------| 1875 | | 1877 +------------+ +-----+ 1878 | Authorized | | PCC | 1879 | Entity | | | 1880 +------------+ +-----+ 1881 | | 1882 | | 1883 | Profile Change Request | 1884 |---------------------------------->| 1885 | | 1886 | Profile Change Response | 1887 |<----------------------------------| 1888 | | 1890 PNC = Profile Notification Component 1891 PCC = Profile Content Component 1892 Framework Reference Model 1894 Profile enrollment and change notification allows a device to 1895 transmit a request for a specific profile - relayed directly, or via 1896 one or more SIP proxies - to a PNC. If the PNC accepts the profile 1897 request, it transmits a Profile Notification that contains either: 1898 profile data or content indirection information. The profile data 1899 can contain information specific to an entity (such as the device or 1900 a user) and may contain sensitive information (such as service 1901 credentials). Compromise of such data can lead to threats such as 1902 impersonation attacks (establishing rogue sessions), theft of service 1903 (if services are obtainable), and zombie attacks. Even if the 1904 profile data is provided using content indirection, PCC information 1905 within the notification can lead to threats such as denial of service 1906 attacks (rogue devices bombard the PCC with requests for a specific 1907 profile) and attempts to modify erroneous data onto the PCC (since 1908 the location and format may be known). It is also important for the 1909 device to ensure the authenticity of the PNC since impersonation of 1910 the Service Provider can lead to Denial of Service, Man-in-the-Middle 1911 attacks, etc. 1913 Profile Content retrieval allows a device to retrieve profile data 1914 from a PCC. This communication is accomplished using one of many 1915 profile delivery protocols or frameworks, but is considered to be out 1916 of scope within this document. However, since the profile data 1917 returned is subject to the same considerations as that sent via 1918 profile notification, the same threats exist. 1920 Profile Change Operation allows an authorized entity to modify 1921 profiles stored on a PCC. The specific entities are based on Service 1922 Provider's policy and can include trusted network elements and 1923 devices alike. The profile information stored on a PCC can contain 1924 information that directs device and user behavior, services offered 1925 and may contain sensitive information such as credentials. Thus, 1926 allowing entities that are not trusted to perform profile 1927 modifications presents threats such as denial-of-service, 1928 manipulation of service, impersonation (for example, redirection to 1929 rogue networks) and man-in-the-middle attacks. 1931 The framework specified in this document accomplishes the propagation 1932 of profile data by utilizing the specified "ua-profile" event package 1933 which is based on [RFC3265]. Thus, its usage is expected to comply 1934 with the security considerations and requirements (access control, 1935 Notifier privacy mechanism, Denial-of-Service attacks, replay 1936 attacks, and Man-in-the Middle attacks) specified in Section 5 of 1937 [RFC3265]. The remainder of this section presents the specific 1938 security requirements for the framework. 1940 9.1. Profile Enrollment and Change Notification 1942 This framework specifies, and allows for the propagation of, three 1943 profile types: local-network, device and user. Enrollment and change 1944 notification are expected to be accomplished over integrity-protected 1945 SIP communication channels and following requirements are presented: 1947 o devices and PNCs complying with this framework MUST implement TLS 1948 as specified in [RFC3268], including support for both mutual and 1949 one-way authentication (server-side) 1951 o devices and PNCs complying with this framework MUST implement the 1952 SIP Digest authentication scheme as specified in [RFC3261] 1954 o a PNC capable of propagating device and user profiles MUST contain 1955 a X.509 certificate. This certificate MUST contain the PNC's 1956 Fully Qualified Domain Name in the 'SubjectAltName', establishing 1957 the PNC as a host in the Service Provider's domain 1959 o a PNC capable of propagating local-network profiles or 1960 unauthenticated device profiles MUST support the use of the SIP 1961 Identity header as defined in [RFC4474] for inclusion in profile 1962 notifications 1964 Each profile type serves a different purpose, and is provided under 1965 different circumstances and thus presents slightly different 1966 requirements for authentication and protection of communication. 1968 local-network profile 1970 The local-network profile is provided by the local network and 1971 usually contains non-sensitive data that is shared among all 1972 participants in a local network. However, the framework also 1973 allows for the presentation of the user's AOR, if known, for 1974 possible privileged user data. This may, or may not, result in 1975 user-specific information. 1977 The following requirements are presented: 1978 * the PNC MUST authenticate the identity of the user (if set to 1979 anything other than the default) for local-network profile 1980 requests that result in user-specific profile data containing 1981 sensitive information; for authentication, unless other 1982 mechanisms are employed, SIP Digest is used. If the 1983 authentication fails, the PNC MUST not include any user- 1984 specific information in the local-network profile 1985 * the PNC MAY NOT authenticate requests for the local-network 1986 profile that do not result in any user-specific sensitive data 1987 (irrespective of the value of the From field) 1989 * the PNC MUST include the SIP Identity header as defined in 1990 [RFC4474] within profile notifications sent in response to 1991 local-network profile enrollment, unless an integrity-protected 1992 channel exists (for example, using S/MIME) 1993 * a device receiving profile notifications for local-network 1994 profiles MUST verify the SIP Identity header, unless 1995 transmitted over a previously established authenticated, 1996 integrity-protected channel. If the header verification fails, 1997 the device MUST not use the provided profile and treat it as a 1998 local-network profile enrollment failure and take measures such 1999 as enrollment retries 2001 device profile 2003 The device profile is expected to contain data specific to the 2004 device identity (AOR) being presented in the request. The 2005 presented identity may be auto-generated (for example, based on 2006 its hardware identity as allowed in section Section 5.1.1.2.1) or 2007 obtained via configuration. This identity and associated 2008 credentials have the following considerations: 2009 * credentials can be provided via out-of-band mechanisms such as 2010 pre-configuration or user interface 2011 * credentials may not be present, but obtained via the initial 2012 device profile, if allowed by the Service Provider 2013 * device may use the user's AOR and associated credentials for 2014 obtaining the device profile 2016 If the AOR presented in device profile enrollment is known by the 2017 PNC, the following requirements are presented: 2018 * the PNC MUST authenticate the AOR presented for enrollment 2019 using SIP Digest authentication, unless a previously 2020 established mutually authenticated channel exists (for example, 2021 using TLS). If the authentication fails, the PNC MUST not 2022 provide the requested device-specific profile. In such a 2023 scenario, the PNC MAY still provide a generic device profile 2024 for minimal services (for example, emergency calls in a 2025 telephony deployment, see [I-D.ietf-ecrit-phonebcp]) 2026 * if the profile data is provided in the enrollment notificaiton, 2027 the PNC MUST transmit it over an integrity-protected, 2028 confidential communications channel such as TLS 2030 If the AOR presented in device profile enrollment is not known by 2031 the PNC, the following requirements are presented: 2032 * the PNC MUST not provide any sensitive information in the 2033 profile data 2034 * the device MUST transmit the request over an integrity- 2035 protected SIP communications channel. If none exists, the 2036 device MUST establish a TLS connection with the PNC and verify 2037 the PNC's certificate. If the PNC authentication fails or a 2038 secure communications channel cannot be established, the device 2039 MUST treat it as a device profile enrollment failure and take 2040 measures such as retry enrollment 2042 user profile 2044 The user profile is expected to contain data specific to the user 2045 identity (AOR) being presented in the request. This identity is 2046 expected to be known in the network and associated with 2047 credentials. Thus, the following requirements are presented: 2048 * the device MUST transmit the request over an integrity- 2049 protected SIP communications channel. If none exists, the 2050 device MUST establish a TLS connection with the PNC and verify 2051 the PNC's certificate. If the PNC authentication fails or a 2052 secure communications channel cannot be established, the device 2053 MUST treat this as a user profile enrollment failure and take 2054 measures such as retry enrollment 2055 * the PNC MUST authenticate the AOR presented for enrollment 2056 using SIP Digest authentication, unless a previously 2057 established mutually authenticated channel exists (for example, 2058 using TLS). If the user authentication fails, the PNC MUST not 2059 provide the requested user-specific information. It MAY 2060 provide minimal profile information (such as connection to a 2061 customer support webpage) 2062 * if the profile data is provided in the enrollment notificaiton, 2063 the PNC MUST transmit it over an integrity-protected, 2064 confidential communications channel such as TLS 2066 9.2. Profile Content Retrieval 2068 This framework does not mandate specific profile delivery frameworks, 2069 but presents security requirements for profile content retrieval 2070 using content indirection. Given the nature of the profiles, the 2071 requirements are as follows: 2072 o devices and PCCs compliant with this framework MUST implement HTTP 2073 Digest authentication as specified in [RFC2617]; this is used 2074 whenever an authentication challenge is initiated using HTTP based 2075 protocols specified for interoperability 2076 o a PCC complying with this framework MUST implement HTTPS 2077 [RFC2818]; this is used when there are no existing integrity- 2078 protected communication channels 2079 o a PCC complying with this framework MUST contain a X.509 2080 certificate. This certificate MUST contain the PNC's Fully 2081 Qualified Domain Name in the 'SubjectAltName', establishing the 2082 PNC as a host in the Service Provider's domain 2084 The following general requirement applies to all profile types: 2085 o a device MUST request profile content retrieval over an integrity 2086 protected channel such as HTTPS. If one does not exist or cannot 2087 be established, then the device MUST treat this as a profile 2088 content retrieval failure and take measures such as profile 2089 content retrieval retries or in the case of retry exhaustion, try 2090 enrollment 2092 The following profile-specific usage requirements are presented 2094 local-network profile 2096 * a PCC MUST challenge a profile content retrieval request if the 2097 profile data contains user-specific information; this challenge 2098 is against a user's AOR, known by the PCC and the device 2099 * a PCC MAY challenge a profile content retrieval request even if 2100 the profile data contains user-specific information; this 2101 challenge is against a user's AOR, if provided 2103 device profile 2104 * a PCC MUST authenticate a profile content retrieval request if 2105 the AOR presented is known. If the authentication fails, the 2106 PCC MUST not provide device-specific information. In such a 2107 scenario, the PCC MAY still provide a generic device profile 2108 for minimal services (for example, emergency calls in a 2109 telephony deployment, see [I-D.ietf-ecrit-phonebcp]) 2111 user profile 2112 * a PCC MUST authenticate a profile content retrieval request. 2113 If the user authentication fails, the PNC MUST not provide the 2114 requested user-specific information. It MAY provide minimal 2115 profile information (such as connection to a customer support 2116 webpage) 2118 9.3. Profile Change Operation 2120 Changes to profiles will only be made by authorized entities and 2121 requires mutual authentication. The following requirements are 2122 presented: 2123 o a PCC complying with this framework MUST contain a X.509 2124 certificate. This certificate MUST contain the PNC's Fully 2125 Qualified Domain Name in the 'SubjectAltName', establishing the 2126 PNC as a host in the Service Provider's domain. This may be the 2127 same, or different, from the certificate used for profile content 2128 retrieval 2129 o an entity that is allowed to make updates MUST contain a AOR that 2130 is known to the network and the requirements for making changes 2131 are the same as that for user profile content retrieval, with the 2132 authorized entity playing the role of a user 2134 10. Acknowledgements 2136 Many thanks to those who contributed and commented on the many 2137 iterations of this document. Detailed comments were provided by the 2138 following individuals: Jonathan Rosenberg from Cisco, Henning 2139 Schulzrinne from Columbia University, Cullen Jennings from Cisco, 2140 Rohan Mahy from Plantronics, Rich Schaaf from Pingtel, Volker Hilt 2141 from Bell Labs, Adam Roach of Estacado Systems, Hisham Khartabil from 2142 Telio, Henry Sinnreich from MCI, Martin Dolly from AT&T Labs, John 2143 Elwell from Siemens, Elliot Eichen and Robert Liao from Verizon, Dale 2144 Worley from Pingtel, Francois Audet from Nortel, Roni Even from 2145 Polycom, Jason Fischl from Counterpath, Josh Littlefield from Cisco, 2146 Nhut Nguyen from Samsung. 2148 The editor would like to extend a special thanks to the experts who 2149 contributed to the restructuring and revisions as proposed by the 2150 SIPPING WG, specifically Keith Drage from Lucent (restructuring 2151 proposal), Peter Blatherwick from Mitel (who also contributed to the 2152 Overview and Introduction sections), Josh Littlefield from Cisco 2153 (examples and diagram suggestions), Alvin Jiang of Engin, Martin 2154 Dolly from AT&T, Jason Fischl from Counterpath, Donald Lukacs from 2155 Telcordia and Eugene Nechamkin from Broadcom. Additionally, sincere 2156 appreciation is extended to the chairs (Mary Barnes from Nortel and 2157 Gonzalo Camarillo from Ericsson) and the Area Directors (Cullen 2158 Jennings from Cisco and Jon Peterson and Cisco) for facilitating 2159 discussions, and for reviews and contributions. 2161 11. Change History 2163 [[RFC Editor: Please remove this entire section upon publication as 2164 an RFC.]] 2166 11.1. Changes from draft-ietf-sipping-config-framework-10.txt 2168 The following are the changes that have been incorporated into this 2169 I-D, resulting from the design team discussions based on Working 2170 Group feedback. 2171 o Modified the "From" header of the local network profile to reflect 2172 the user's AOR, if any; delegated the device identifier to a new 2173 event header termed "device-id"; removed use for 'network-user' 2174 within the local-network profile; if there are objections to this, 2175 please educate us! 2177 o Added text to indicate DHCPv4 or DHCPv6 to accomodate IPv4 and 2178 IPv6 environments 2179 o Replaced generic 'Service Provider' with terms to better represent 2180 scenarios 2181 o Analyzed the current SHOULD v/s MUST requirements for the Profile 2182 Framework and made modifications 2183 o Referenced RFC4122 instead of OUTBOUND 2184 o Simplified the introductory sections to better illustrate 2185 potential deployment possibilities; indicated the minimum profile 2186 supported to be 'device' 2187 o Revamped the security considerations sections 2189 11.2. Changes from draft-ietf-sipping-config-framework-09.txt 2191 Following the ad-hoc SIPPING WG discussions at IETF#67 and as per the 2192 email from Gonzalo Camarillo dated 12/07/2006, Sumanth was appointed 2193 as the new editor. This sub-section highlights the changes made by 2194 the editor (as per expert recommendations from the SIPPING WG folks 2195 interested in this effort) and the author. 2197 Changes incorporated by the editor: 2198 o Document was restructured based on a) Keith's recommendations in 2199 the email dated 11/09/2006 and responses (Peter, Sumanth, Josh) b) 2200 subsequent discussions by the ad-hoc group consisting of the 2201 editor, the author, expert contributors (Peter Blatherwick, Josh 2202 Littlefield, Alvin Jiang, Jason Fischl, Martin Dolly, Cullen 2203 Jennings) and the co-chairs . Further changes follow. 2204 o Use cases were made high-level with detailed examples added later 2205 on 2206 o Several sections were modified as part of the restructuring (for 2207 example, Overview, Introduction, Framework Requirements, Security 2208 Sections) 2209 o General editorial updates were made 2211 Changes incorporated by the author: 2213 o Incorporated numerous edits and corrections from CableLabs review. 2214 o Used better ascii art picture of overview from Josh Littlefield 2215 o Fixed the normative text for network-user so that it is now 2216 consistant: MAY provide for device profile, MUST provide for 2217 local-network profile. 2219 11.3. Changes from draft-ietf-sipping-config-framework-08.txt 2220 The Request URI for profile-type=localnet now SHOULD not have a 2221 user part to make routing easier. The From field SHOULD now 2222 contain the device id so that device tracking can still be done. 2223 Described the concept of profile-type as a filter and added 2224 normative text requiring 404 for profile types not provided. 2225 Moved "application" profile type to 2226 draft-ietf-sipping-xcap-config-01. The "application" value for 2227 the profile-type parameter will also be used as a requirement that 2228 XCAP be supported. 2229 Fixed text on certificate validation. 2230 Added new HTTP header: Event to IANA section and clean up the IANA 2231 section. 2232 Added diagram for Service Provider use case schenario. 2233 Added clarification for HTTP Event header. 2234 Added clarification of subscriber handling of NOTIFY with no body. 2236 11.4. Changes from draft-ietf-sipping-config-framework-07.txt 2238 Made XCAP informative reference. Removed "document" and "auid" 2239 event header parameters, and Usage of XCAP section to be put in 2240 separate supplementary draft. 2241 Fixed ABNF for device-id to be addr-spec only (not name-addr) and 2242 to be quoted as well. 2243 Synchronized with XCAP path terminology. Removed XCAP path 2244 definition as it is already defined in XCAP. 2245 User agent instance ID is now defined in output (not GRUU). 2246 Clarified the rational for the device-id parameter. 2247 Added text to suggest URIs for To and From fields. 2248 Clarified use of device-id parameter. 2249 Allow the use of the auid and document parameters per request by 2250 the OMA. 2252 11.5. Changes from draft-ietf-sipping-config-framework-06.txt 2254 Restructured the introduction and overview section to be more 2255 consistent with other Internet-Drafts. 2256 Added additional clarification for the Digest Authentication and 2257 Certificate based authentication cases in the security section. 2258 Added two use case scenarios with cross referencing to better 2259 illustrate how the framework works. Added better cross 2260 referencing in the overview section to help readers find where 2261 concepts and functionality is defined in the document. 2262 Clarified the section on the use of XCAP. Changed the Event 2263 parameter "App-Id" to "auid". Made "auid" mutually exclusive to 2264 "document". "auid" is now only used with XCAP. 2265 Local network subscription URI changed to @ 2266 (was anonymous@). Having a 2267 different Request URI for each device allows the network 2268 management to track user agents and potentially manage bandwidth, 2269 port allocation, etc. 2270 Changed event package name from sip-profile to ua-profile per 2271 discussion on the list and last IETF meeting. 2272 Changed "local" profile type token to "local-network" per 2273 discussion on the list and last IETF meeting. 2274 Simplified "Vendor", "Model", "Version" event header parameters to 2275 allow only quoted string values (previously allowed token as 2276 well). 2277 Clarified use of the term cache. 2278 Added references for ABNF constructs. 2279 Numerous editorial changes. Thanks Dale! 2281 11.6. Changes from draft-ietf-sipping-config-framework-05.txt 2283 Made HTTP and HTTPS profile transport schemes mandatory in the 2284 profile delivery server. The subscribing device must implement 2285 HTTP or HTTPS as the profile transport scheme. 2286 Rewrote the security considerations section. 2287 Divided references into Normative and Informative. 2288 Minor edits throughout. 2290 11.7. Changes from draft-ietf-sipping-config-framework-04.txt 2292 Clarified usage of instance-id 2293 Specify which event header parameters are mandatory or optional 2294 and in which messages. 2295 Included complete list of event header parameters in parameter 2296 overview and IANA sections. 2297 Removed TFTP reference as protocol for profile transport. 2298 Added examples for discovery. 2299 Added ABNF for all event header parameters. 2300 Changed profile-name parameter back to profile-type. This was 2301 changed to profile-name in 02 when the parameter could contain 2302 either a token or a path. Now that the path is contained in the 2303 separate parameter: "document", profile-type make more sense as 2304 the parameter name. 2305 Fixed some statements that should have and should not have been 2306 normative. 2307 Added the ability for the user agent to request that the default 2308 user associated with the device be set/changed using the 2309 "device-id" parameter. 2310 A bunch of editorial nits and fixes. 2312 11.8. Changes from draft-ietf-sipping-config-framework-03.txt 2314 Incorporated changes to better support the requirements for the use 2315 of this event package with XCAP and SIMPLE so that we can have one 2316 package (i.e. simple-xcap-diff now defines a content type not a 2317 package). Added an additional profile type: "application". Added 2318 document and app-id Event header parameters in support of the 2319 application profile. Define a loose high level data model or 2320 relationship between the four profile types. Tried to edit and fix 2321 the confusing and ambiguous sections related to URI formation and 2322 discovery for the different profile types. Better describe the 2323 importance of uniqueness for the instance id which is used in the 2324 user part of the device URI. 2326 11.9. Changes from draft-ietf-sipping-config-framework-02.txt 2328 Added the concept of the local network as a source of profile data. 2329 There are now three separate logical sources for profile data: user, 2330 device and local network. Each of these requires a separate 2331 subscription to obtain. 2333 11.10. Changes from draft-ietf-sipping-config-framework-01.txt 2335 Changed the name of the profile-type event parameter to profile-name. 2336 Also allow the profile-name parameter to be either a token or an 2337 explicit URI. 2339 Allow content indirection to be optional. Clarified the use of the 2340 Accept header to indicate how the profile is to be delivered. 2342 Added some content to the Iana section. 2344 11.11. Changes from draft-ietf-sipping-config-framework-00.txt 2346 This version of the document was entirely restructured and re-written 2347 from the previous version as it had been micro edited too much. 2349 All of the aspects of defining the event package are now organized in 2350 one section and is believed to be complete and up to date with 2351 [RFC3265]. 2353 The URI used to subscribe to the event package is now either the user 2354 or device address or record. 2356 The user agent information (vendor, model, MAC and serial number) are 2357 now provided as event header parameters. 2359 Added a mechanism to force profile changes to be make effective by 2360 the user agent in a specified maximum period of time. 2362 Changed the name of the event package from sip-config to ua-profile 2363 Three high level security approaches are now specified. 2365 11.12. Changes from draft-petrie-sipping-config-framework-00.txt 2367 Changed name to reflect SIPPING work group item 2369 Synchronized with changes to SIP DHCP [RFC3361], SIP [RFC3261] and 2370 [RFC3263], SIP Events [RFC3265] and content indirection [RFC4483] 2372 Moved the device identity parameters from the From field parameters 2373 to user-agent header parameters. 2375 Many thanks to Rich Schaaf of Pingtel, Cullen Jennings of Cisco and 2376 Adam Roach of Estacado Systems for the great comments and input. 2378 11.13. Changes from draft-petrie-sip-config-framework-01.txt 2380 Changed the name as this belongs in the SIPPING work group. 2382 Minor edits 2384 11.14. Changes from draft-petrie-sip-config-framework-00.txt 2386 Split the enrollment into a single SUBSCRIBE dialog for each profile. 2387 The 00 draft sent a single SUBSCRIBE listing all of the desired. 2388 These have been split so that each enrollment can be routed 2389 differently. As there is a concept of device specific and user 2390 specific profiles, these may also be managed on separate servers. 2391 For instance in a nomadic situation the device might get its profile 2392 data from a local server which knows the LAN specific profile data. 2393 At the same time the user specific profiles might come from the 2394 user's home environment profile delivery server. 2396 Removed the Config-Expires header as it is largely superfluous with 2397 the SUBSCRIBE Expires header. 2399 Eliminated some of the complexity in the discovery mechanism. 2401 Suggest caching information discovered about a profile delivery 2402 server to avoid an avalanche problem when a whole building full of 2403 devices powers up. 2405 Added the user-profile From header field parameter so that the device 2406 can request a user specific profile for a user that is different from 2407 the device's default user. 2409 12. References 2410 12.1. Normative References 2412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2413 Requirement Levels", BCP 14, RFC 2119, March 1997. 2415 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2416 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2417 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2419 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2420 Leach, P., Luotonen, A., and L. Stewart, "HTTP 2421 Authentication: Basic and Digest Access Authentication", 2422 RFC 2617, June 1999. 2424 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2426 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2427 A., Peterson, J., Sparks, R., Handley, M., and E. 2428 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2429 June 2002. 2431 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 2432 Protocol (SIP): Locating SIP Servers", RFC 3263, 2433 June 2002. 2435 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 2436 Event Notification", RFC 3265, June 2002. 2438 [RFC3268] Chown, P., "Advanced Encryption Standard (AES) 2439 Ciphersuites for Transport Layer Security (TLS)", 2440 RFC 3268, June 2002. 2442 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 2443 and M. Carney, "Dynamic Host Configuration Protocol for 2444 IPv6 (DHCPv6)", RFC 3315, July 2003. 2446 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 2447 Protocol (DHCPv6) Options for Session Initiation Protocol 2448 (SIP) Servers", RFC 3319, July 2003. 2450 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 2451 (DHCP-for-IPv4) Option for Session Initiation Protocol 2452 (SIP) Servers", RFC 3361, August 2002. 2454 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2455 Unique IDentifier (UUID) URN Namespace", RFC 4122, 2456 July 2005. 2458 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 2459 Authenticated Identity Management in the Session 2460 Initiation Protocol (SIP)", RFC 4474, August 2006. 2462 [RFC4483] Burger, E., "A Mechanism for Content Indirection in 2463 Session Initiation Protocol (SIP) Messages", RFC 4483, 2464 May 2006. 2466 12.2. Informative References 2468 [I-D.ietf-ecrit-phonebcp] 2469 Rosen, B. and J. Polk, "Best Current Practice for 2470 Communications Services in support of Emergency Calling", 2471 draft-ietf-ecrit-phonebcp-00 (work in progress), 2472 October 2006. 2474 [I-D.ietf-simple-xcap] 2475 Rosenberg, J., "The Extensible Markup Language (XML) 2476 Configuration Access Protocol (XCAP)", 2477 draft-ietf-simple-xcap-12 (work in progress), 2478 October 2006. 2480 [I-D.ietf-simple-xcap-diff] 2481 Rosenberg, J., "An Extensible Markup Language (XML) 2482 Document Format for Indicating A Change in XML 2483 Configuration Access Protocol (XCAP) Resources", 2484 draft-ietf-simple-xcap-diff-04 (work in progress), 2485 October 2006. 2487 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 2488 STD 9, RFC 959, October 1985. 2490 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2491 RFC 2131, March 1997. 2493 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 2495 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 2496 (LDAP): Technical Specification Road Map", RFC 4510, 2497 June 2006. 2499 Authors' Addresses 2501 Daniel Petrie 2502 SIPez LLC. 2503 34 Robbins Rd 2504 Arlington, MA 02476 2505 USA 2507 Email: dan.ietf AT SIPez DOT com 2508 URI: http://www.SIPez.com/ 2510 Sumanth Channabasappa (Editor) 2511 CableLabs 2512 858 Coal Creek Circle 2513 Louisville, Co 80027 2514 USA 2516 Email: sumanth@cablelabs.com 2517 URI: http://www.cablelabs.com/ 2519 Full Copyright Statement 2521 Copyright (C) The IETF Trust (2007). 2523 This document is subject to the rights, licenses and restrictions 2524 contained in BCP 78, and except as set forth therein, the authors 2525 retain all their rights. 2527 This document and the information contained herein are provided on an 2528 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2529 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2530 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2531 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2532 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2533 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2535 Intellectual Property 2537 The IETF takes no position regarding the validity or scope of any 2538 Intellectual Property Rights or other rights that might be claimed to 2539 pertain to the implementation or use of the technology described in 2540 this document or the extent to which any license under such rights 2541 might or might not be available; nor does it represent that it has 2542 made any independent effort to identify any such rights. Information 2543 on the procedures with respect to rights in RFC documents can be 2544 found in BCP 78 and BCP 79. 2546 Copies of IPR disclosures made to the IETF Secretariat and any 2547 assurances of licenses to be made available, or the result of an 2548 attempt made to obtain a general license or permission for the use of 2549 such proprietary rights by implementers or users of this 2550 specification can be obtained from the IETF on-line IPR repository at 2551 http://www.ietf.org/ipr. 2553 The IETF invites any interested party to bring to its attention any 2554 copyrights, patents or patent applications, or other proprietary 2555 rights that may cover technology that may be required to implement 2556 this standard. Please address the information to the IETF at 2557 ietf-ipr@ietf.org. 2559 Acknowledgment 2561 Funding for the RFC Editor function is provided by the IETF 2562 Administrative Support Activity (IASA).