idnits 2.17.1 draft-ietf-sipping-config-framework-10.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 2370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2394. 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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 2316 has weird spacing: '... Change in XM...' == 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: 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 2007) is 6250 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 1880, 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 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) == 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) -- Obsolete informational reference (is this intentional?): RFC 3377 (Obsoleted by RFC 4510) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 9 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 2, 2007 CableLabs 6 March 2007 8 A Framework for Session Initiation Protocol User Agent Profile Delivery 9 draft-ietf-sipping-config-framework-10 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 2, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 6 61 3.2. Profile Life Cycle . . . . . . . . . . . . . . . . . . . 9 62 3.3. Data Model and Profile Types . . . . . . . . . . . . . . 10 63 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.1. Client with different Data and SIP Service Providers . . 11 65 4.2. Clients supporting multiple users from different 66 Service Providers . . . . . . . . . . . . . . . . . . . . 13 67 5. Profile Delivery Framework . . . . . . . . . . . . . . . . . . 15 68 5.1. Profile Discovery . . . . . . . . . . . . . . . . . . . . 18 69 5.1.1. SIP SUBSCRIBE for the Local-Network Profile Type . . . 19 70 5.1.2. SIP SUBSCRIBE for the Device Profile Type . . . . . . 20 71 5.1.3. SIP SUBSCRIBE for the User Profile Type . . . . . . . 24 72 5.1.4. Caching of SIP Subscription URIs . . . . . . . . . . . 24 73 5.2. Profile Enrollment . . . . . . . . . . . . . . . . . . . 25 74 5.3. Profile Notification . . . . . . . . . . . . . . . . . . 26 75 5.4. Profile Retrieval . . . . . . . . . . . . . . . . . . . . 26 76 5.5. Profile Change Upload . . . . . . . . . . . . . . . . . . 26 77 5.6. Additional Considerations . . . . . . . . . . . . . . . . 27 78 5.6.1. Manual retrieval of the Device Profile . . . . . . . . 27 79 5.6.2. Client Types . . . . . . . . . . . . . . . . . . . . . 28 80 5.6.3. Profile Data . . . . . . . . . . . . . . . . . . . . . 28 81 5.6.4. Profile Data Frameworks . . . . . . . . . . . . . . . 28 82 5.6.5. Additional Profile Types . . . . . . . . . . . . . . . 29 83 6. Event Package Definition . . . . . . . . . . . . . . . . . . . 29 84 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . 29 85 6.2. Event Package Parameters . . . . . . . . . . . . . . . . 29 86 6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . 33 87 6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 33 88 6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 34 89 6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 34 90 6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . 35 91 6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . 35 92 6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 36 93 6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 36 94 6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . 36 95 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 96 7.1. Example 1: Client requesting profile . . . . . . . . . . 36 97 7.2. Example 2: Client obtaining change notification . . . . . 40 98 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 99 8.1. SIP Event Package . . . . . . . . . . . . . . . . . . . . 44 100 8.2. New HTTP Event Header . . . . . . . . . . . . . . . . . . 44 101 9. Security Considerations . . . . . . . . . . . . . . . . . . . 45 102 9.1. Event Package . . . . . . . . . . . . . . . . . . . . . . 45 103 9.2. Profile Life Cycle . . . . . . . . . . . . . . . . . . . 46 104 9.3. Profile Data . . . . . . . . . . . . . . . . . . . . . . 46 105 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47 106 11. Open Items . . . . . . . . . . . . . . . . . . . . . . . . . . 47 107 12. Change History . . . . . . . . . . . . . . . . . . . . . . . . 48 108 12.1. Changes from 109 draft-ietf-sipping-config-framework-09.txt . . . . . . . 48 110 12.2. Changes from 111 draft-ietf-sipping-config-framework-08.txt . . . . . . . 49 112 12.3. Changes from 113 draft-ietf-sipping-config-framework-07.txt . . . . . . . 49 114 12.4. Changes from 115 draft-ietf-sipping-config-framework-06.txt . . . . . . . 49 116 12.5. Changes from 117 draft-ietf-sipping-config-framework-05.txt . . . . . . . 50 118 12.6. Changes from 119 draft-ietf-sipping-config-framework-04.txt . . . . . . . 50 120 12.7. Changes from 121 draft-ietf-sipping-config-framework-03.txt . . . . . . . 51 122 12.8. Changes from 123 draft-ietf-sipping-config-framework-02.txt . . . . . . . 51 124 12.9. Changes from 125 draft-ietf-sipping-config-framework-01.txt . . . . . . . 51 126 12.10. Changes from 127 draft-ietf-sipping-config-framework-00.txt . . . . . . . 51 128 12.11. Changes from 129 draft-petrie-sipping-config-framework-00.txt . . . . . . 52 130 12.12. Changes from draft-petrie-sip-config-framework-01.txt . . 52 131 12.13. Changes from draft-petrie-sip-config-framework-00.txt . . 52 132 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 133 13.1. Normative References . . . . . . . . . . . . . . . . . . 53 134 13.2. Informative References . . . . . . . . . . . . . . . . . 54 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 136 Intellectual Property and Copyright Statements . . . . . . . . . . 56 138 1. Introduction 140 SIP User Agents require configuration data to function properly. 141 Examples include network, Client 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 In addition, this document introduces and utilizes the following 163 terms: 165 Client: software or hardware entity containing one or more SIP user 166 agents. 168 Device: the terms 'Client' and 'Device' are used interchangeably 169 within this framework. 171 Service Provider: a logical entity providing one or more services. 172 This can refer to private enterprises or public entities. 174 Profile: configuration data set specific to an entity (for example, 175 user, device, local network or other). 177 Profile Type: a particular category of Profile data (for example, 178 User, Device, Local Network or other). 180 Profile Delivery Server (PDS): the source of a Profile, it is the 181 logical collection of the Profile Notification Component (PNC) and 182 the Profile Content Component(PCC). 184 Profile Notification Component (PNC): the logical component of a 185 Profile Delivery Server that is responsible for enrolling Clients 186 and providing profile notifications. 188 Profile Content Component (PCC): the logical component of a Profile 189 Delivery Server that is responsible for storing, providing and 190 accepting profile content. 192 Profile Discovery: discovery of a Profile Delivery Server (PDS) by 193 the Client. 195 Profile Enrollment: process of enrolling with one or more Profile 196 Delivery Server(s) by a Client. 198 Profile Notification: notification of a requested or changed profile 199 by the PDS. 201 Profile Retrieval: retrieval of Profile data from a PDS by a Client. 203 Profile Change Upload: upload of profile data changes to one or more 204 PDSs by authorized entities such as a Client 206 Notifier: as defined in [RFC3265] the SIP user agent server which 207 processes SUBSCRIBE requests for events and sends NOTIFY requests 208 with profile data or URIs (Uniform Resource Identifiers) that 209 point to the data. 211 Instance ID: text identifier globally unique across all Clients. 213 3. Overview 215 This section provides an overview of the configuration framework. It 216 introduces the reference model and explains key concepts such as the 217 Profile Life Cycle and the Profile types. The framework is presented 218 in Section 5. 220 3.1. Reference Model 222 The design of the framework was the result of a careful analysis to 223 identify the configuration needs of a wide range of SIP deployments. 224 As such, the reference model provides for a great deal of 225 flexibility, while breaking down the interactions to their basic 226 forms which can be reused in many different scenarios. 228 In its simplest form, the reference model for the framework defines 229 the interactions between the Profile Delivery Server(PDS) and the 230 Client. The Client is a SIP UA which needs the profile data to 231 effectively function in the network. The PDS is responsible for 232 responding to Client requests and providing the profile data. The 233 set of interactions between these entities is referred to as the 234 Profile Life Cycle. This reference model is illustrated in the 235 diagram below. 237 +-------------------------+ 238 +---------+ Interactions | Profile Delivery Server | 239 | Client |<==========================>| +---+ +---+ | 240 | (SIP UA)| (Profile Life Cycle) | |PNC| |PCC| | 241 +---------+ | +---+ +---+ | 242 +-------------------------+ 244 PNC = Profile Notification Component 245 PCC = Profile Content Component 247 Framework Reference Model 249 The PDS is subdivided into two logical components: 250 o Profile Notification Component (PNC), responsible for enrolling 251 Clients in Profile event subscriptions and providing Profile 252 change notifications; 253 o Profile Content Component (PCC), responsible for storing, 254 providing access to, and accepting updates related to profile 255 content. 257 SIP deployments vary considerably. To be effective, the 258 configuration framework needs to consider a comprehensive set of 259 scenarios that is representative of most deployments. The figure 260 below provides a system level view of the device, user and Service 261 Provider relationships that may be involved. 263 -------- 264 / \ 265 | Service | 266 | Provider | - > Provides 'Client'(e.g. allowed Users) 267 \ Y / & 'User'(such as Services) profile 268 -------- 269 | ----- 270 | / Local \ 271 | | Network | 272 | | Provider| - > Provides 'Local Network' profile 273 | \ Z / data (e.g. STUN Server Address) 274 | ----- 275 | / 276 | / 277 =============== 278 ( Local Network ) 279 =============== 280 | 281 | 282 | 283 --------- 284 | Client X| - > Needs the 'Client' profile (from Y) 285 --------- & 'local network' profile (from Z) 286 / \ 287 / \ 288 ------ ------ 289 |User A| |User B| - > Users need 'User' profile (from Y) 290 ------ ------ 291 Framework System Level Model 293 Based on the system level model, the following considerations are 294 relevant. 296 Client connectivity: 297 o Clients can connect either directly to a Service Provider or via 298 other local networks (for example, home network, Public Wi-Fi 299 Hotspots, enterprise managed LAN, etc.); 300 o Local networks through which Clients connect may wish to provide 301 their own configuration information particular to that specific 302 network (for example, STUN server information, local Proxy, etc.) 303 which is independent of the Service Provider (who provides 304 services) or the particular User. 306 Service provider relationships: 307 o The local network provider (the network the Client connects to) 308 and the Service Provider (that hosts the actual voice or other 309 services) can often be different entities, with no administrative 310 or business relationship to each other; 311 o There may be multiple different Service Providers involved, one 312 for each service type a User subscribes to (telephony service, 313 instant messaging, etc); this Framework does not specify explicit 314 behavior in such a scenario, but it does not prohibit its usage 315 either 316 o Each User accessing services via a Client may subscribe to 317 different sets of services, from different Service Providers; 319 User-Client relationship: 320 o The relationship between Clients and Users can be many-to-many 321 (for example, a particular UA instance may allow for many Users to 322 obtain subscription services through it, and individual Users may 323 have access to multiple different UA devices); 324 o Each User may have different preferences for use of services, and 325 presentation of those services in the Client user interface; 326 o Each User may have different personal information applicable to 327 use of the Client device, either as related to particular 328 services, or independent of them. 330 The observations above show a need for a clear distinction between 331 different Profile Types, based on the source and purpose of the 332 configuration data contained, and a need for these profiles to be 333 manageable by different PDSs. Accordingly, the framework identifies 334 the following minimal Profile Types. 336 Local-Network Profile: refers to profile data as provided by the 337 Local Network to which a Client is directly connected; 339 Device Profile: refers to profile data provided by the Service 340 Provider or other entity which is specific to the particular 341 Client; 343 User Profile: refers to profile data provided by the Service 344 Provider or other entity which is specific to the particular User. 346 The definition of additional Profile Types and their usage is 347 allowed, but is outside the scope of this document. 349 The remainder of this section provides more information on the two 350 vital components of the framework: Profile Life Cycle and Profile 351 Types. 353 3.2. Profile Life Cycle 355 Automated Profile delivery to Clients requires proactive behavior on 356 the part of a Client. It also requires one or more PDSs which 357 provide the profile data. Profile Delivery is usually initiated when 358 the Client discovers PDSs and requests profile data. The profile 359 data can be modified by the Client (for example, by a User) and 360 subsequently uploaded to the PDS. Alternatively, the profile data 361 can be modified by an authorized entity such as an administrative or 362 user interface and the Client is notified through an event 363 notification. 365 The specific functional steps involved in these interactions, 366 collectively termed Profile Life Cycle, are as follows: 368 Profile Discovery: The process by which a Client finds PDS(s) 369 capable of providing the Profiles it requires. This Framework 370 defines multiple Profile Types which may be served by one or more 371 PDSs. 373 Profile Enrollment: The process by which a Client makes itself known 374 to a PDS. While enrolling, the Client provides identity 375 information and requested Profile Type(s) for profile retrieval. 376 It also subscribes for notification of profile changes. As a 377 result of enrollment, the Client receives profile information 378 (contents or content indirection information). Each Profile Type 379 requires a separate enrollment or SUBSCRIBE session. 381 Profile Notification: The process by which the PDS notifies the 382 Client that either requested Profile contents are available, or 383 the content of one or more of the Profiles has changed. If the 384 content is provided indirectly, the Client may retrieve the 385 profile from the specified URI upon receipt of the change 386 notification. 388 Profile Retrieval: The process of retrieving the content for each of 389 the Profiles requested by the Client. 391 Profile Change Upload: The process by which a Client or other entity 392 (for example, configuration management server) pushes a change to 393 Profile data to the PDS. 395 3.3. Data Model and Profile Types 397 As outlined previously, this framework defines three specific Profile 398 Types. Additional extended profiles may also be defined. The 399 Profile Types specified in this framework are: 401 Local Network Profile: Contains configuration data related to the 402 Local Network to which a Client is directly connected, as required 403 for the Client to operate effectively in that network. It is 404 expected to be provided by a PDS in the Local Network (or proxied 405 in some way). 407 Device Profile: Contains configuration data related to a specific 408 Client, required for operation in the Service Provider's 409 environment. It is expected to be provided by the Service 410 Provider responsible for configuring the Client. 412 User Profile: Contains configuration data related to the specific 413 User, as required to reflect that User's preferences and the 414 particular services subscribed to. It is expected to be provided 415 by Service Provider(s) responsible for maintaining the User's 416 configuration data. 418 To function effectively, the Client should obtain all of the 419 necessary Profiles. Since each profile may potentially be served by 420 a different source and the Client has no way of ascertaining that in 421 advance, the framework requires the Client to discover the PDS 422 sources independently and request the corresponding Profiles from 423 each individually. 425 4. Use Cases 427 This section provides a small - non-comprehensive - set of 428 representative use cases to further illustrate how this Framework can 429 be utilized in SIP deployments. 431 For Security Considerations please refer to Section 9. 433 4.1. Client with different Data and SIP Service Providers 435 Description: Consider a user who obtains data (broadband) and SIP 436 Services from two different Service Providers. For example, a user 437 obtaining SIP services from a SIP Service Provider, via data 438 connectivity provided through a WiFi hotspot or hotel network. 440 The following assumptions apply: 441 o For the sake of simplicity, the Client is assumed to be pre- 442 configured with a) the domain name of the SIP Service Provider, 443 b) the ability to generate a Client identifier (such as, based 444 on MAC address) that can be used to request the device profile, 445 and b) a user identity which can be used to request the user 446 profile 447 o The Client is pre-configured to request local-network, Client 448 and user profiles - in that order - to obtain information 449 related to the local-network, itself and the pre-configured user 450 o The profile data provided upon request are based on data models 451 that are comprehenisble by the Client, i.e. the Client 452 understands the data models used for the creation of the profile 453 data 455 The following diagram illustrates this use case and highlights the 456 communications relevant to the framework specified in this document. 458 +-----------------+ +----------------------+ 459 +--------+ | Data Service | | SIP Service Provider | 460 | Client | | Provider | | | 461 |(SIP UA)| | | | SIP PDS PDS | 462 +--------+ | DHCP PDS | | PROXY (Client) (User)| 463 +-----------------+ +----------------------+ 464 | | | | | | 465 (A) |<==== DHCP ===>| | | | | 466 | | | | | 467 | | | | | 468 | SUBSCRIBE/NOTIFY | | | | 469 (B) |<=== local-network ===>| | | | 470 | profile 471 | 472 | <> 473 | 474 | SUBSCRIBE/NOTIFY | | | 475 (C) |<========= device profile ========>|<=====>| | 476 | | | | 477 | <> 478 | 479 | 480 | SUBSCRIBE/NOTIFY | | 481 (D) |<========== user profile ========>|<============>| 482 | | | 483 | <> 484 | 486 The following is an explanation of the interactions in the diagram. 487 (A) Upon initialization, the Client obtains IP parameters (IP 488 address, DNS) using DHCP (as an example) 489 (B) The Client proceeds to request the 'local-network' Profile Type. 490 The PDS in the local network responds, allowing the Client to 491 retrieve the local-network profile 492 (C) The Client then proceeds to request the 'device' Profile Type 493 using the pre-configured SIP Service Provider's domain name. 494 This request is received by a SIP Proxy in the SIP Service 495 Provider's network. The request is then proxied to a relevant 496 PDS within its network. The PDS responds to the request and 497 provides profile retrieval information. The Client retrieves 498 the Device Profile (this can contain information such as 499 enabling or disabling usage, based on the subscription status) 501 (D) The Client then proceeds to request the 'User' Profile Type for 502 the pre-configured User. This message is proxied to the same or 503 different PDS (diagram assumes the latter) which responds with 504 the profile retrieval information. The Client retrieves the 505 User profile (this can contain information such as service 506 profiles to be retrieved, based on the subscription). The 507 Client then starts providing services. 509 4.2. Clients supporting multiple users from different Service Providers 511 Description: Consider a single Client (for example, Kiosk at an 512 airport) that allows for multiple users to obtain services from a 513 list of pre-configured SIP Service Providers. 515 The following assumptions apply: 516 o The Client is provided and managed by SIP Service Provider A. It 517 is not pre-configured with any User Identities, but offers an 518 interactive User Interface to enter Service Provider and User 519 information 520 o SIP Service Provider A provides the local network connectivity, 521 'local-network' and 'device' profiles for the Client. The 522 Service Provider also provides 'user' profiles for existing 523 subscribers 524 o SIP Service Provider B provides SIP services and has pre- 525 existing agreements with SIP Service Provider A. This Service 526 Provider also provides 'user' profiles for existing subscribers 528 The following diagram illustrates the use case and highlights the 529 communications relevant to the framework specified in this document. 531 User User 532 A B +----------------------+ +----------------------+ 533 +--------+ | SIP Service Provider | | SIP Service Provider | 534 | Client | | A | | B | 535 |(SIP UA)| | | | | 536 +--------+ | DHCP PROXY PDS | | PROXY PDS | 537 +----------------------+ +----------------------+ 538 | | | | | | 539 (A) |<====DHCP====>| | | | | 540 | | | | | 541 | | | | | 542 | SUBSCRIBE/NOTIFY | | | | 543 (B) ||<====>| | | 544 | 545 | <> 546 | 547 | 548 | SUBSCRIBE/NOTIFY | | | | 549 (C) |<== device profile ==> |<====>| | | 550 | 551 | <> 552 | 553 . 554 . 555 . 556 [[User A attempts services]] 558 | SUBSCRIBE/NOTIFY | | | | 559 (D) |<= user profile (A) => |<====>| | | 560 | | | | | 561 | 562 | <> 563 . 564 . 565 . 566 . 567 [[User B attempts services]] 569 | 570 | SUBSCRIBE/NOTIFY | | 571 (E) |<=========== user profile (B) ==========>|<=========>| 572 | | | 573 | <> 574 | 576 The following is an explanation of the interactions in the diagram. 577 (A) Upon initialization, the Client obtains IP parameters (IP 578 address, DNS) using DHCP 579 (B) Once local IP connectivity is established and the SIP stack 580 initialized, the Client proceeds to request the 'local-network' 581 Profile Type. It receives a response from the PDS in Service 582 Provider A's network (the local network). The Client retrieves 583 the profile (this may contain useful information such as 584 firewall port restrictions, available bandwidth etc) 585 (C) The Client then proceeds to request the 'device' Profile Type. 586 It receives a response containing the profile retrieval from the 587 PDS in Service Provider A's network. The Client retrieves the 588 data provided in the Client Profile (this may provide data 589 regarding Users such as the list of SIP Service Providers the 590 Client can communicate with). The Client initializes the User 591 interface for services. 592 (D) User A with a pre-existing subscription with Service Provider A 593 attempts communication via the User Interface. This results in 594 a prompt - and responses - for identification and 595 authentication. The Client uses the provided information and 596 communicates with Service Provider A. Once authenticated and 597 authorized, it proceeds to request the 'User' Profile Type. The 598 PDS responds with the profile retrieval information. The Client 599 provides services to User A. 600 (E) At a different point in time, User B with a pre-existing 601 subscription with Service Provider B attempts communication via 602 the User Interface. This results in a prompt - and responses - 603 for identification and authentication. Since Service Provider B 604 is in the list of approved Service Provider, the Client uses the 605 provided information and communicates with Service Provider B. 606 Once authenticated and authorized, it proceeds to request the 607 'User' Profile Type. The PDS responds with the profile 608 retrieval information. The Client provides services to User B. 610 It is to be noted that this Client may allow for exclusive or 611 simultaneous access to both Users. 613 5. Profile Delivery Framework 615 This section details the framework requirements. The Profile Life 616 Cycle (introduced in Section 3), is examined in further detail, with 617 requirements that apply to the Client and the PDS. Unless explicitly 618 enhanced or indicated by an implementing specification, the Client 619 and the PDS MUST follow the Profile Life Cycle requirements stated in 620 this section for all supported Profile Types. 622 A high-level representation of the framework is shown in the 623 following state diagram. Each of the specified Profile Types is 624 retrieved individually, in the specified order (see below), until all 625 needed Profiles have been received. For each retrieved Profile, the 626 Client then awaits any Change Notifications 628 --------------- 629 / Client \ 630 \ Initialization/ 631 --------------- 632 | 633 | Completes IP initialization; 634 | Initializes SIP stack 635 | 636 V 637 -------------- YES --------------- 638 ________\ / All profiles?\_____\ | Await Change | 639 | / \ retrieved? / / | Notifications | 640 | -------------- --------------- 641 | | 642 | | NO; attempt 643 | | Profile Request 644 | | in specified order 645 | | 646 | V 647 | ------------ 648 ___________/ Profile \ 649 \ Life Cycle / 650 ------------ 652 Framework state diagram 654 The Profile Life Cycle, within each Profile Type, is illustrated 655 further as in the state diagram below. 657 ------------- All methods -------- 658 ________\ / Profile \ ............\ / Error \ 659 | / \ Discovery / exhausted / \Handling/ 660 | ------------- -------- 661 | | 662 | | 663 | Try | Send request 664 | alternate | for Profile 665 | method(s) | Enrollment 666 | | 667 | | 668 | V 669 | FAILURE ------------ 670 |__________/ Profile \ 671 ^ \ Enrollment / 672 ^ ------------ 673 | | 674 | FAILURE | 675 | | 676 | | 677 | V 678 | Timeout ------------- 679 _________ / Profile \ 680 \ Notification/ 681 ------------- 682 | 683 | 684 |SUCCESS 685 | 686 V 687 ------- Failure --------- 688 / Profile \ _________\ / Error \ 689 \Retrieval/ / \ Handling/ 690 ------- --------- 691 . 692 . If allowed 693 . by Profile Retrieval 694 ------ . Framework 695 (Client) -- V 696 ------ \ ------------- 697 /Profile Change\ 698 \ Upload / 699 ---------- / ------------- 700 {Authorized}-- 701 { Entity } 702 ---------- 704 The Profile Life Cycle is initiated when the Client starts the 705 'Profile Discovery' process for a particular Profile Type. Discovery 706 leads to transmission of a request for 'Profile Enrollment'. 707 Successful enrollment leads to 'Profile Notification'. Successful 708 initial notification results in 'Profile Retrieval' (either as data 709 within the notification or using content indirection). 'Profile 710 Change Upload' can be initiated by any authorized entity (examples 711 include Clients and administrative interfaces). 713 'Profile Discovery' and 'Profile Enrollment' are closely coupled. 714 Failure to enroll (for example, no response is received for the 715 SUBSCRIBE) results in alternate 'Profile Discovery' methods until 716 success is achieved or all the methods are exhausted (resulting in 717 error handling). Simiarly, the initial 'Profile Notification' is 718 closely coupled to enrollment. Failure to receive the initial 719 notification also results in alternate discovery methods. 721 'Profile Retrieval' is accomplished using the contents of the Profile 722 Notification. This can either contain the profile data or a content 723 indirection method to achieve it. 725 The Profile Life Cycle is the same for all the Profile Types, but 726 there are different requirements in each step based on the Profile 727 Types. This framework defines three Profile Types and an order that 728 MUST be followed by the Client in requesting them (when it retrieves 729 two or more of the defined Profile Types), as follows: 731 o local-network 732 o device 733 o user 735 The sub-sections that follow specify the Profile Life Cycle details, 736 with specific requirements based on each Profile Type. 738 5.1. Profile Discovery 740 The first step to obtaining a profile is PDS Discovery. This is 741 accomplished by creating a profile subscription using the Event 742 Package described in Section 6, and preparing for Profile Enrollment. 744 Each Profile Type requires its own subscription and based on the 745 entity requesting it, presents certain unique requirements (for 746 example, the Client identifier is provided for the Device Profile 747 Type where as the User identifier is provided for the User Profile 748 Type). Further, the Profile Types are aimed at different PDSs and 749 hence are identified differently (for example, the local-network is 750 identified by the local domain name where as the Service Provider is 751 identified based on the Service Provider's domain name). Some of 752 this information can be obtained in multiple ways (such as local 753 domain information that can be configured statically or dynamically) 754 and the Client may have to try different information sources to 755 obtain the required information (for example, dynamic configuration 756 can override statically configured information). Based on these 757 considerations, the framework defines different rules for obtaining 758 and presenting the information for each Profile Type. Additionally, 759 when more than one information source is possible for the 760 information, it is presented as well. This is highlighted in the 761 following sub-sections. 763 5.1.1. SIP SUBSCRIBE for the Local-Network Profile Type 765 Before attempting to create a SIP SUBSCRIBE requesting the Local- 766 Network Profile, the Client MUST have established local network 767 connectivity. It MUST also have knowledge of the local network 768 domain either via static configuration or dynamic discovery (using 769 DHCP [RFC2131], option 15 [RFC2132]). The following requirements 770 apply: 771 o the user part of the Request URI MUST NOT be provided. The host 772 and port part of the Request URI MUST be set to the local network 773 domain 774 o the user part of the "From" field MUST be the Identifier that the 775 Client will use to request the 'device' Profile Type 776 o the host and port part of the "From" field MUST be set to the 777 local network domain 778 o a user AOR, if known to the Client MUST be provided in the 779 "network-user" event header parameter, unless privacy requirements 780 prohibit its use (this is useful if the user has privileges in the 781 local network beyond those of the default user) 783 For example: If the Client requested and received the local domain 784 name via DHCP to be: airport.example.net, then the Local-Network 785 Profile SUBSCRIBE Request URI would look like: 787 sip:airport.example.net 789 The Event header would look like the following if the Client decided 790 to provide sip:alice@example.com as the user's AOR. (Alice may have 791 a prior arrangement with the local network operator giving her 792 special privileges.): 794 Event: ua-profile;profile-type=local-network; 795 network-user="sip:alice@example.com" 797 The Local-Network Profile SUBSCRIBE Request URI does not have a user 798 part so that the URI is distinct between the "local" and "device" 799 URIs when the domain is the same for the two. This provides a means 800 of routing to the appropriate PDS in domains where they are distinct 801 servers. The From field uses the device ID in the user part of the 802 local network Request URI so that every device in the network has a 803 unique and constant From field. Even though every client may get the 804 same (or similar) Local-Network Profile, the uniqueness of the From 805 field provides an important capability. Having unique From fields 806 allows the management of the local network to track user agents 807 present in the network and consequently also manage resources such as 808 bandwidth and port allocation. 810 For example: If the Client requested and received the local domain 811 name via DHCP to be: airport.example.net and the device ID is: MAC: 812 00DF1E004CD0, the From field would contain: 814 sip:MAC%3a00DF1E004CD0@airport.example.net 816 5.1.2. SIP SUBSCRIBE for the Device Profile Type 818 The Device Profile Type allows the Service Provider managing a Client 819 to provide Client-specific configuration information. To enable 820 this, the Request URI needs to identify the Client and the PDS domain 821 within which it is recognizable. Accordingly, this Framework 822 presents the following requirements for the formation of a 823 Subscription Request URI to request the "device" Profile Type 825 o the user portion of the Request URI MUST be set to a unique Client 826 Identifier 827 o the host and port portion of the Request URI MUST be set to the 828 PDS domain 830 The following sub-sections explain identification of - and the 831 requirements related to - the Client Identifier and the PDS domain 832 discovery. 834 5.1.2.1. Client Identifier 836 The Client profile could be specific to each Client in a SIP 837 deployment (for example, vendor/model) or shared across Client types 838 (for example, based on services and service tiers). Further, the 839 same Client might be provided different configuration profiles based 840 on deployment models. Client Identifiers play a significant role in 841 ensuring delivery of the correct profile and hence need to be unique 842 within a PDS domain to support the various deployment models. 844 This Framework requires that Client Identifiers MUST be unique and 845 persistent over the lifetime of a Client. Client Identifier 846 representations auto-generated by Clients SHOULD be based on MAC 847 address or UUID ([RFC4122]) based representations. A Client may use 848 alternate Client identifiers (for example, SIP URIs) obtained via 849 pre-configuration or dynamic configuration (for example, Client 850 profile). 852 If a MAC address is used, the following requirements apply: 853 o the Client identifier MUST be formatted as the characters "MAC:" 854 followed by a twelve digit hexadecimal upper case representation 855 of the MAC address to form a proper URN ([RFC2141]). The MAC 856 address representation MUST NOT include visual separators such as 857 colons and whitespaces. The representation is denoted using the 858 following ABNF syntax 860 mac-ident = MAC ":" 12UHEX 861 MAC = %x4d.41.43 ; MAC in caps 862 UHEX = DIGIT / %x41-46 ; uppercase A-F 864 o the MAC address MUST only be used to represent a single Client. 865 It MUST NOT be used if more than one Client can potentially use 866 the same MAC Address (for example, multiple software Clients on a 867 single platform). In such cases, the UUID representation SHOULD 868 be used 870 If a UUID is used, the following requirements MUST apply: 871 o the same approach to defining a user agent Instance ID as 872 [RFC4122] MUST be used 873 o when the URN is used as the user part of the URI, it MUST be URL 874 escaped 875 The colon (":") is not a legal character (without being 876 escaped) in the user part of an addr-spec ([RFC4122]). 877 For example the instance ID: 878 urn:uuid:f81d4fae-7ced-11d0-a765-00a0c91e6bf6@example.com 879 would be escaped to look as follows in a URI: 880 sip:urn%3auuid%3af81d4fae-7ced-11d0-a765-00a0c91e6bf6@ 881 example.com 882 The ABNF for the UUID representation is provided in [RFC4122] 884 5.1.2.2. PDS Domain Discovery 886 A Client needs to identify the PDS domain to form the host and port 887 part of the Request URI. Ideally, this information should be 888 obtained via a single method. However, support for various 889 deployment models implies multiple Client environments (for example, 890 residential routers, enterprise LANs, WLAN hotspots, dialup modem 891 etc) and presents hurdles to specifying a single method (for example, 892 if a Client is always in the SIP Service Provider's network one could 893 use DHCP). To accommodate multiple deployment scenarios, the 894 framework specified in this document presents multiple approaches. 896 Clients MUST follow the procedures specified below in the order 897 presented, unless exceptions are made by Client manufacturers or 898 Service Providers who may provide an option for the user to choose 899 the order (to suit specific deployment models, for example). 901 1. Service Provider pre-configuration 903 The Client MAY be pre-configured with information that can be 904 utilized to identify the host and port of the Request URI. The 905 information can be provided - as examples - when the Client is 906 manufactured, by using Service Provider entities (flash card, SIM 907 card) or via a Service Provider specific method (for example, 908 information or methods that lead to self subscription). If the 909 Client is specified to utilize this approach, it MUST attempt to 910 do so before trying other methods. The details of how this is 911 accomplished are beyond the scope of this document. 913 2. IP Configuration 915 If pre-configuration is not an option, or not available, IP 916 configuration MUST be utilized to try and obtain information that 917 can help with identification of the host and port for the Request 918 URI. The framework defines the following methods within this 919 procedure to accomplish this. Clients MUST follow the methods 920 defined, in the order specified, i.e. if the first option cannot 921 be accomplished or results in a failure, then next method is 922 tried. Failure of a specific method is indicated when the Client 923 cannot successfully complete Profile Enrollment. 925 2a. DHCP option 120: 927 Clients that support DHCP MUST attempt to obtain the host and 928 port of the outbound proxy during the DHCP process, using the 929 SIP DHCP option 120 [RFC3361] and use these as the host and 930 port part of the request URI. 932 For example, a MAC based Client Identifier with a DHCP option 933 120 indicating example.com, the Request URI would be 934 constructed as sip:MAC%3aABC123EFD456@example.com 936 2b. Local IP Network Domain: 938 - Clients that support DHCP MUST attempt to obtain the local IP 939 network domain during the DHCP process, using DHCP option 15 940 and use these as the host and port part of the request URI 941 using the technique specificed in [RFC3263] 943 + For example, a MAC based Client Identifier with a DHCP 944 option 15 indicating local.example.com, the Request URI 945 would be constructed as 946 sip:MAC%3aABC123EFD456@local.example.com 948 - If the local IP network domain is available (previous 949 method), but the usage of the local IP Network domain results 950 in a failure, the Client MUST use the local IP network domain, 951 prefixing it using the label "sipuaconfig." 953 + For example, a MAC based Client Identifier with a DHCP 954 option 15 indicating local.example.com, the Request URI 955 would be constructed as 956 sip:MAC%3aABC123EFD456@sipuaconfig.local.example.com 958 3. Manual 960 If pre-configuration and IP Configuration are not options or 961 result in failures, the Client SHOULD provide a means for the user 962 to present information that may help with the retrieval process. 963 Exceptions to this requirement MAY include Clients with no user 964 interface appropriate for such entry. 966 This framework provides the following alternatives which can be 967 considered individually or together, in any order. 969 Service Provider PDS information: The user SHOULD be allowed to 970 present the host and port information which can help with the 971 creation of the Subscription URI to locate a PDS capable of 972 providing the profile. 974 Service Provider Configuration Server information The user MAY be 975 allowed to present information pertaining to a configuration 976 server that provides the Device Profile, not using a PDS as 977 defined in this framework. This framework specifies one such 978 possible process in Section 5.6.1. 980 5.1.3. SIP SUBSCRIBE for the User Profile Type 982 The User Profile allows the responsible SIP Service Provider to 983 provide user-specific configuration. This is based on the User's 984 Identity that is usually known in the network (for example, 985 associated with a subscription). Similar to the profiles provided to 986 Clients, the content and propagation of User Profiles may partake 987 differently, based on deployment scenarios (for example, users 988 belonging to the same subscription might - or might not - be provided 989 the same profile). However, each User is uniquely identified in a 990 SIP Service Provider's network using an Address Of Record (AOR). 991 Clients implementing this framework MUST use the User's AOR to 992 populate the Request URI. 994 A Client MAY obtain the User's AOR using various methods such as pre- 995 configuration, via the Device Profile or dynamically via a User 996 Interface. 998 5.1.4. Caching of SIP Subscription URIs 1000 Creation of Subscription URIs is vital for successful Profile 1001 Enrollment, required for Profile Notification and ultimately Profile 1002 Retrieval. Further - unlike the User Profile - Local-Network and 1003 Device Profiles are expected to be requested based on discovered 1004 information (for example, domain name discovered via DHCP). These 1005 Profile Types have different goals and hence, caching of the 1006 Subscription URI should be carefully considered. 1008 The Local-Network Profile Type is aimed at obtaining information from 1009 the local network. The local network can change across Client 1010 initializations (for example, User moves the Client from a home 1011 network to a workplace LAN). Thus, the Client SHOULD NOT remember 1012 local-network profile subscription URIs across initializations. The 1013 Client SHOULD re-create the Subscription URI every time it moves to a 1014 new network or gets re-initialized. Exceptions may be cases where 1015 the Client can unambiguously determine changes to the local network. 1017 The Device Profile Type is aimed at obtaining information from the 1018 SIP Service Provider managing the Client. Once established, the 1019 Service Provider does not change often (an example of an exception 1020 would be the re-use of Clients across Service Providers). However, 1021 if the discovery process is used, the Client can only be sure of 1022 having reached the Service Provider upon successful Profile 1023 Enrollment and Profile Notification. Thus, the Client SHOULD cache 1024 the Subscription URI for the Device Profile. When cached, the Client 1025 should use the cached Subscription URI upon a reset. Exceptions 1026 include cases where the Client identifier has changed (for example, 1027 new network card with a new MAC address), Service Provider 1028 information has changed (for example, user initiates change) or the 1029 Client cannot obtain its profile using the Subscription URI. 1031 Clients SHOULD NOT cache the Subscription URI for the Device 1032 Profile Type until successful Profile Notification. The reason 1033 for this is that a PDS may send 202 responses to SUBSCRIBE 1034 requests and NOTIFY responses to unknown Clients (see Section 6.6) 1035 with no profile data or URIs. Thus, successful Profile 1036 Notification is the only sure way to know that the Subscription 1037 URI is valid. 1039 5.2. Profile Enrollment 1041 Clients implementing the framework specified in this document are 1042 required to perform Profile Enrollment prior to Profile Retrieval 1043 (the only exception is noted in Section 5.6.1). Enrollment for a 1044 specific profile happens once the specific Subscription URI is formed 1045 and is accomplished using the Event Package specified. 1047 Thus, a Client requesting a Profile Type specified in this document - 1048 and is successful in forming a Subscription URI - MUST enroll using 1049 the event package defined, and as specified, in this framework (see 1050 Section 6) . The following requirements apply: 1052 o the Client MUST cater to the Event Package requirements specified 1053 in Section 6.2 (for example, indicate the Profile Type being 1054 requested in the profile-type parameter) 1055 o the Client MUST use the Subscription URI pertaining to the Profile 1056 Type being requested, as specified in Section 5.1 1058 The SIP infrastructure receiving such requests is expected to relay 1059 and process profile enrollment requests. When a Profile Enrollment 1060 request is received by a PDS, it SHOULD accept and respond to any 1061 profile requests. Exceptions are when Service Provider policy 1062 prevents such a response (for example, requesting entity is unknown). 1064 Successful Profile Enrollment involves the following 1065 o Acceptance of the SUBSCRIBE request by a PDS (indicated via a 200 1066 response) 1067 o Receipt of an initial Profile Notification within the timeouts as 1068 specified in [RFC3265] 1069 A Client SHOULD follow suitable BackOff and Retry mechanisms if a 1070 successful Profile Enrollment does not happen within the expected 1071 period. 1073 5.3. Profile Notification 1075 Successful Profile Enrollment leads to Profile Notification. This 1076 serves two purposes a) initial profile content following successful 1077 Profile Enrollment and b) notification to the Client of modifications 1078 to profile content. Failure to receive the initial NOTIFY following 1079 a successful enrollment MUST be treated the same as a failed 1080 enrollment. Whenever a profile is changed, the PDS MUST NOTIFY all 1081 Clients currently subscribed to the changed profile. 1083 For NOTIFY content please refer to Section 6.5. 1085 5.4. Profile Retrieval 1087 Upon successful Profile Enrollment and Profile Notification, the 1088 Client can retrieve the documents pertaining to the requested profile 1089 directly or via the URI(s) provided in the NOTIFY request as 1090 specified in Section 6.5. 1092 The following requirements hold good: 1094 o the PDS SHOULD secure the content of the profiles using one of the 1095 techniques described in Section 9 1096 o the Client MUST make the new profiles effective within the 1097 specified timeframe, as described in Section 6.2 1098 o if content indirection is used, the Client SHOULD verify that it 1099 has the latest profile content using the "hash" parameter defined 1100 in [RFC4483] 1101 o the Client SHOULD cache (i.e. store persistently) the contents of 1102 retrieved profiles, until overridden by subsequent Profile 1103 Notifications (this avoids situations where a PDS is unavailable, 1104 leaving the Client without required configuration) 1106 5.5. Profile Change Upload 1108 Configuration Profiles can change over time. This can be initiated 1109 by various entities (for example, via the Client, back-office 1110 components, end-user web interfaces into configuration servers, etc) 1111 and for various reasons (such as, change in user preferences, 1112 modifications to services, enterprise-imposed common features or 1113 restrictions). This framework allows for such changes to be 1114 communicated to the PDS, using the term Profile Change Upload. 1116 Any changes to a Profile as a result of Profile Change Upload MUST 1117 result in a Profile Notification to all enrolled clients for that 1118 Profile, if any. 1120 Definition of specific mechanisms for Profile Change Upload are out 1121 of scope of this document. 1123 5.6. Additional Considerations 1125 This section provides a special case for retrieval of the Device 1126 Profile and highlights considerations and requirements on external 1127 entities such as Profile Data Frameworks. 1129 5.6.1. Manual retrieval of the Device Profile 1131 At a minimum, a Client requires the Device Profile to be able to 1132 function effectively. However, the methods specified in this 1133 document many fail to provide a Client with a profile. To illustrate 1134 with an example, consider the case of a Client that finds itself 1135 behind a local network which does not provide information about DNS 1136 servers in the network (for example, misconfigured home network). In 1137 such cases, it would be beneficial to employ an alternative means to 1138 obtain the profile information (for example, resolvable DNS Servers 1139 could be part of the Client profile). While this specification 1140 recommends that such a method be made available, it also specifies 1141 one such option using HTTP that is described in this sub-section. 1142 Clients expected to encounter scenarios where Client profile 1143 retrieval can be hindered may employ the specified - or any 1144 alternative - process. 1146 The method being described involves the Client to utilize a HTTPS URI 1147 (and any required credentials) based on either pre-configuration or 1148 manual entry by the User (in cases where such an interface is 1149 possible). This can lead to the retrieval of the Device Profile 1150 which may contain the properties for the SUBSCRIBE Request URI and 1151 credentials for Profile Enrollment and Profile Notification. This 1152 approach bootstraps the process in a different step in the cycle, but 1153 uses the same framework. 1155 Further, this document defines a new HTTP request header "Event". 1156 The syntax of the HTTP Event header is the same as the SIP Event 1157 header defined in this document. Similar to the SIP Event header the 1158 purpose of the HTTP Event header is to define the content of the 1159 state information to be retrieved. In particular, the state 1160 information is the Device, User or Local-Network Profile for the 1161 Client. The SIP Event header parameters for this event package 1162 ("profile-type", "vendor", "model", "version") are also mandatory for 1163 the HTTP Event header as they are used to provide information as to 1164 what profile type is requested along with information about the 1165 device which may impact the contents of the profile.When the Client 1166 starts with retrieval of the profile via HTTPS (instead of a SIP 1167 SUBSCRIBE to the event package), the device MUST provide the Event 1168 header defined. 1170 5.6.2. Client Types 1172 The examples in this framework tend to associate Clients with 1173 entities that are accessible to end-users. However, this is not 1174 necessarily the only type of Client that can utilize the specified 1175 Framework. Clients can be entities such as User Interfaces (that 1176 allow for Client Configuration), entities in the network that do not 1177 directly communicate with any Users (for example, Service Provider 1178 deployed gateways) or elements in the Service Provider's network (for 1179 example, SIP servers). 1181 5.6.3. Profile Data 1183 This framework does not specify the contents for any Profile Type. 1184 Follow-on standardization activities can address profile contents. 1185 However, it makes the following assumptions and recommendations: 1187 o When the Client receives multiple profiles, the contents of each 1188 Profile Type will only contain data relevant to the entity it 1189 represents. As an example, consider a Client that obtains all the 1190 defined profiles. Information pertaining to the local network is 1191 contained in the 'local-network' profile and not the'user' 1192 profile. This does not preclude relevant data about a different 1193 entity from being included in a Profile Type, for example, the 1194 'device' Profile Type may contain information about the Users 1195 allowed to access services via the Client. A profile may also 1196 contain starting information to obtain subsequent Profiles 1197 o Data overlap SHOULD be avoided across Profile Types, unless 1198 necessary. If data overlap is present, prioritization of the data 1199 is left to data definitions. As an example, the Device Profile 1200 may contain the list of codecs to be used by the Client and the 1201 User Profile (for a User on the Client) may contain the codecs 1202 preferred by the User. Thus, the same data (usable codecs) is 1203 present in two profiles. However, the data definitions may 1204 indicate that to function effectively, any codec chosen for 1205 communication needs to be present in both the profiles. 1207 5.6.4. Profile Data Frameworks 1209 This framework specified in this document does not address profile 1210 data representation, storage or retrieval protocols. It assumes that 1211 the PDS has a PCC based on existing or other Profile Data Frameworks, 1212 for example, XCAP ([I-D.ietf-simple-xcap]). 1214 While it does not impose vast constraints on any such framework, it 1215 does allow for the propagation of profile content to PDS 1216 (specifically the PCC). Thus, Profile Data or Retrieval frameworks 1217 used in conjunction with this framework MAY consider techniques for 1218 propagating incremental, atomic changes to the PDS. For example, a 1219 means for propagating changes to a PDS is defined in XCAP 1220 ([I-D.ietf-simple-xcap]). 1222 5.6.5. Additional Profile Types 1224 This document specifies three profile types: local-network, device 1225 and user. However, there may be use cases for additional profile 1226 types. For example, Profile Types for application specific profile 1227 data. Definition of such additional Profile Types is not prohibited, 1228 but considered out of scope for this document. 1230 6. Event Package Definition 1232 The framework specified in this document proposes and specifies a new 1233 SIP Event Package as allowed by [RFC3265]. The purpose is to allow 1234 for Clients to subscribe to specific Profile Types with PDSs and for 1235 the PDSs to notify the Clients with - or pointers to - profile data. 1237 The requirements specified in [RFC3265] apply to this package. The 1238 following sub-sections specify the Event Package description and the 1239 associated requirements. The framework requirements are defined in 1240 Section 5. 1242 6.1. Event Package Name 1244 The name of this package is "ua-profile". This value appears in the 1245 Event header field present in SUBSCRIBE and NOTIFY requests for this 1246 package as defined in [RFC3265]. 1248 6.2. Event Package Parameters 1250 This package defines the following new parameters for the event 1251 header: 1252 "profile-type", "vendor", "model", "version", "effective-by" and 1253 "network-user". 1254 The following rules apply: 1255 o All the new parameters, with the exception of the "effective-by" 1256 parameter MUST only be used in SUBSCRIBE requests and ignored if 1257 they appear in NOTIFY requests 1259 o The "effective-by" parameter is for use in NOTIFY requests only 1260 and MUST be ignored if it appears in SUBSCRIBE requests 1261 The semantics of these new parameters are specified in the following 1262 sub-sections. 1264 6.2.1. profile-type 1266 The "profile-type" parameter is used to indicate the token name of 1267 the Profile Type the user agent wishes to obtain data or URIs for and 1268 to be notified of subsequent changes. This document defines three 1269 logical types of profiles and their token names. They are as 1270 follows: 1272 local-network Specifying "local-network" type profile indicates the 1273 desire for profile data (URI when content indirection is used) 1274 specific to the local network. 1275 device Specifying "device" type profile(s) indicates the desire for 1276 the profile data (URI when content indirection is used) and change 1277 notification of the contents of the profile that is specific to 1278 the device or user agent. 1279 user Specifying "user" type profile indicates the desire for the 1280 profile data (URI when content indirection is used) and change 1281 notification of the profile content for the user. 1282 The "profile-type" is identified is identified in the Event header 1283 parameter: profile-type. A separate SUBSCRIBE dialog is used for 1284 each Profile Type. The Profile Type associated with the dialog can 1285 then be used to infer which Profile Type changed and is contained in 1286 the NOTIFY or content indirection URI. The Accept header of the 1287 SUBSCRIBE request MUST include the MIME types for all profile content 1288 types for which the subscribing user agent wishes to retrieve 1289 profiles or receive change notifications. 1291 In the following syntax definition using ABNF, EQUAL and token are 1292 defined in [RFC3261]. It is to be noted that additional Profile 1293 Types may be defined in subsequent documents. 1295 Profile-type = "profile-type" EQUAL profile-value 1296 profile-value = profile-types / token 1297 profile-types = "device" / "user" / "local-network" 1299 The "device", "user" or "local-network" token in the profile-type 1300 parameter may represent a class or set of profile properties. 1301 Follow-on standards defining specific profile contents may find it 1302 desirable to define additional tokens for the profile-type parameter. 1303 Also additional content types may be defined along with the profile 1304 formats that can be used in the Accept header of the SUBSCRIBE to 1305 filter or indicate what data sets of the profile are desired. 1307 6.2.2. vendor, model and version 1309 The "vendor", "model" and "version" parameter values are tokens 1310 specified by the implementer of the user agent. These parameters 1311 MUST be provided in the SUBSCRIBE request for all Profile Types. The 1312 implementer SHOULD use their DNS domain name (for example, 1313 example.com) as the value of the "vendor" parameter so that it is 1314 known to be unique. These parameters are useful to the PDS to affect 1315 the profiles provided. In some scenarios it is desirable to provide 1316 different profiles based upon these parameters. For example, feature 1317 property X in a profile may work differently on two versions of the 1318 same user agent. This gives the PDS the ability to compensate for or 1319 take advantage of the differences. In the following ABNF defining 1320 the syntax, EQUAL and quoted-string are defined in [RFC3261]. 1322 Vendor = "vendor" EQUAL quoted-string 1323 Model = "model" EQUAL quoted-string 1324 Version = "version" EQUAL quoted-string 1326 6.2.3. network-user 1328 The "network-user" parameter MUST be set when subscribing for "local- 1329 network" profiles if it is known, unless the Client is provisioned to 1330 preserve privacy within the local network. This allows the Client to 1331 indicate a user who may have special privileges in the local network 1332 that impact the contents of the "local-network" profile. It MAY also 1333 be provided in a subscription for a "device" profile. In such cases 1334 the Client is requesting the PDS to recognize the indicated user as 1335 the default user for itself. 1337 The Notifier SHOULD authenticate the subscriber to verify the 1338 resource identifier in the "network-user" parameter, if the profile 1339 provided is specific to the user (for example, granting policies or 1340 privileges beyond those of a default user). If the value of the 1341 "profile-type" parameter is not "device" or "local-network", the 1342 "network-user" parameter has no defined meaning and is ignored. If 1343 the "network-user" parameter is provided in the SUBSCRIBE request, it 1344 MUST be present in the NOTIFY request as well. In the following 1345 ABNF, EQUAL, LDQUOT, RDQUOT and addr-spec are defined in [RFC3261]. 1347 Network-User = "network-user" EQUAL LDQUOT addr-spec RDQUOT 1349 6.2.4. effective-by parameter 1351 The "effective-by" parameter in the Event header of the NOTIFY 1352 request specifies the maximum number of seconds before the user agent 1353 must attempt to make the new profile effective. The "effective-by" 1354 parameter MAY be provided in the NOTIFY request for any of the 1355 Profile Types. A value of 0 (zero) indicates that the subscribing 1356 user agent must attempt to make the profiles effective immediately 1357 (despite possible service interruptions). This gives the PDS the 1358 power to control when the profile is effective. This may be 1359 important to resolve an emergency problem or disable a user agent 1360 immediately. The "effective-by" parameter is ignored in all messages 1361 other than the NOTIFY request. In the following ABNF, EQUAL and 1362 DIGIT are defined in [RFC3261]. 1364 Effective-By = "effective-by" EQUAL 1*DIGIT 1366 6.2.5. Summary of event parameters 1368 The following are example Event headers which may occur in SUBSCRIBE 1369 requests. These examples are not intended to be complete SUBSCRIBE 1370 requests. 1372 Event: ua-profile;profile-type=device; 1373 vendor="vendor.example.com";model="Z100";version="1.2.3" 1375 Event: ua-profile;profile-type="user"; 1376 vendor="premier.example.com";model="trs8000";version="5.5" 1378 The following are example Event headers which may occur in NOTIFY 1379 requests. These example headers are not intended to be complete 1380 SUBSCRIBE requests. 1382 Event: ua-profile;effective-by=0 1384 Event: ua-profile;effective-by=3600 1386 The following table shows the use of Event header parameters in 1387 SUBSCRIBE requests for the three Profile Types: 1389 profile-type || device | user | local-network 1390 ============================================= 1391 vendor || m | m | m 1392 model || m | m | m 1393 version || m | m | m 1394 network-user || s | | s 1395 effective-by || | | 1397 m - mandatory 1398 s - SHOULD be provided 1399 o - optional 1401 Non-specified means that the parameter has no meaning and should be 1402 ignored. 1404 The following table shows the use of Event header parameters in 1405 NOTIFY requests for the three Profile Types: 1407 profile-type || device | user | local-network 1408 ============================================= 1409 vendor || | | 1410 model || | | 1411 version || | | 1412 network-user || s | | s 1413 effective-by || o | o | o 1415 6.3. SUBSCRIBE Bodies 1417 This package defines no use of the SUBSCRIBE request body. If 1418 present, it MUST be ignored. 1420 Future enhancements to the framework may specify a use for the 1421 SUBSCRIBE request body (for example,, mechanisms using etags to 1422 minimize Profile Notifications to Clients with current profile 1423 versions). 1425 6.4. Subscription Duration 1427 The duration of a subscription is specific to SIP deployments and no 1428 specific recommendation is made by this Event Package. If absent, a 1429 value of 86400 seconds is RECOMMENDED since the presence (or absence) 1430 of a Client subscription is not time critical to the regular 1431 functioning of the PDS. 1433 It is to be noted that a one-time fetch of a profile can be 1434 accomplished by setting the 'Expires' parameter to a value of Zero, 1435 as specified in [RFC3265]. 1437 6.5. NOTIFY Bodies 1439 The framework specifying the Event Package allows for the NOTIFY body 1440 to contain the profile data or a pointer to the profile data using 1441 content direction. The framework does not define any profile data 1442 and delegates specification of utilized MIME types Profile Data 1443 Frameworks. For profile data delivered via content indirection, the 1444 following apply: 1446 o the Content-ID MIME header, as described in [RFC4483] MUST be used 1447 for each Profile document URI 1448 o at a minimum, the "http:" and "https:" URI schemes MUST be 1449 supported; other URI schemas MAY be supported based on the Profile 1450 Data Frameworks (examples include FTP [RFC0959], TFTP 1451 [RFC3617],HTTP [RFC2616], HTTPS [RFC2818], LDAP [RFC3377], XCAP 1452 [I-D.ietf-simple-xcap], XCAP-DIFF [I-D.ietf-simple-xcap-diff]) 1454 The NOTIFY body SHOULD include a MIME type specified in the 'Accept' 1455 header of the SUBSCRIBE. Further, if the Accept header of the 1456 SUBSCRIBE included the MIME type message/external-body (indicating 1457 support for content indirection) the content indirection SHOULD be 1458 used in the NOTIFY body for providing the profiles. If none are 1459 specified, the Profile Data frameworks are responsible for, and MUST 1460 specify, the MIME type to be assumed. 1462 6.6. Notifier Processing of SUBSCRIBE Requests 1464 A successful SUBSCRIBE request results in a NOTIFY with either 1465 profile contents or a pointer to it (via Content Indirection). If 1466 the NOTIFY is expected to contain profile contents or the Notifier is 1467 unsure, the SUBSCRIBE SHOULD be either authenticated or transmitted 1468 over an integrity protected SIP communication channels. Exceptions 1469 to authenticating such SUBSCRIBEs include cases where the identity of 1470 the Subscriber is unknown and the Notifier is configured to accept 1471 such requests. 1473 The Notifier MAY also authenticate SUBSCRIBE messages even if the 1474 NOTIFY is expected to only contain a pointer to profile data. 1475 Securing data sent via Content Indirection is covered in Section 9. 1477 If the Profile Type indicated in the "profile-type" Event header 1478 parameter is unavailable or the Notifier is configured not to provide 1479 it, the Notifier SHOULD return a 404 response to the SUBSCRIBE 1480 request. If the specific user or Client is unknown, the Notifier MAY 1481 either accept or reject the subscription. 1483 When the Event header "profile-type" is "device" and the user agent 1484 has provided the user's AOR in the "network-user" parameter, the 1485 profile delivery server MAY set or change the default user associated 1486 with the Client indicated in the Subscription request. However, the 1487 Notifier SHOULD authenticate the user indicated before making such a 1488 change. 1490 6.7. Notifier Generation of NOTIFY Requests 1492 As specified in [RFC3265], the Notifier MUST always send a NOTIFY 1493 request upon accepting a subscription. If the Client or User is 1494 unknown and the Notifier choose to accept the subscription, the 1495 Notifier MAY either respond with profile data (for example, default 1496 profile data) or provide no profile information (i.e. no body or 1497 content indirection). 1499 If the URI in the SUBSCRIBE request is a known identity and the 1500 requested profile information is available (i.e. as specified in the 1501 profile-type parameter of the Event header), the Notifier SHOULD send 1502 a NOTIFY with profile data. Profile data MAY be sent as profile 1503 contents or via Content Indirection (if the content indirection MIME 1504 type was included in the Accept header). To allow for Content 1505 Indirection, the Subscriber MUST support the "http:" or "https:" URI 1506 schemas. If the Subscriber wishes to support alternative URI schemas 1507 it MUST be indicated in the "schemes" Contact header field parameter 1508 as defined in [RFC4483]. If the subscriber does not specify the URI 1509 scheme, the Notifier may use either "http:" or "https:". 1511 The Notifier MAY specify when the new profiles must be made effective 1512 by the Subscriber by specifying a maximum time in seconds (zero or 1513 more) in the "effective-by" event header parameter. 1515 If the SUBSCRIBE was received over an integrity protected SIP 1516 communications channel, the Notifier SHOULD send the NOTIFY over the 1517 same channel. 1519 6.8. Subscriber Processing of NOTIFY Requests 1521 A Subscriber to this event package MUST adhere to the NOTIFY request 1522 processing behavior specified in [RFC3265]. If the Notifier 1523 indicated an effective time (using the "effective-by" Event Header 1524 parameter), it SHOULD attempt to make the profiles effective within 1525 the specified time. Exceptions include deployments that prohibit 1526 such behavior in certain cases (for example, emergency sessions are 1527 in progress). When profile data cannot be applied within the 1528 recommended timeframe and this affects Client behavior, any actions 1529 to be taken SHOULD be defined by the profile data definitions. By 1530 default, the Subscriber is RECOMMENDED to make the profiles effective 1531 as soon as possible. 1533 The Subscriber MUST always support "http:" or "https:" and be 1534 prepared to accept NOTIFY messages with those URI schemas.The 1535 subscriber MUST also be prepared to receive a NOTIFY request with no 1536 body. The subscriber MUST NOT reject the NOTIFY request with no 1537 body. The subscription dialog MUST NOT be terminated by a NOTIFY 1538 with no body. 1540 6.9. Handling of Forked Requests 1542 This Event package allows the creation of only one dialog as a result 1543 of an initial SUBSCRIBE request as described in section 4.4.9 of 1544 [RFC3265]. It does not support the creation of multiple 1545 subscriptions using forked SUBSCRIBE requests. 1547 6.10. Rate of Notifications 1549 The rate of notifications for the profiles in this framework is 1550 deployment specific, but expected to be infrequent. Hence, the Event 1551 Package specification does not specify a throttling or minimum period 1552 between NOTIFY requests 1554 6.11. State Agents 1556 State agents are not applicable to this Event Package. 1558 7. Examples 1560 This section provides examples along with sample SIP message bodies 1561 relevant to this framework. Both the examples are derived from a 1562 snapshot of Section 4.1, specifically the request for the Device 1563 Profile. The examples are purely informative and in case of 1564 conflicts with the framework or protocols used for illustration, the 1565 latter should be deemed normative. 1567 7.1. Example 1: Client requesting profile 1569 This example illustrates the detailed message flows between the 1570 Client and the SIP Service Provider's network for requesting and 1571 retrieving the profile (the flow uses the Device Profile as an 1572 example). 1574 The following are assumed for this example: 1576 o Client is assumed to have established local network connectivity; 1577 NAT and Firewall considerations are assumed to have been addressed 1578 by the SIP Service Provider 1579 o examples are a snapshot only and do not illustrate all the 1580 interactions between the Client and the Service Provider's network 1581 (and none between the entities in the SIP Service Provider's 1582 network) 1583 o All SIP communication with the SIP Service Provider happens via a 1584 SIP Proxy 1585 o HTTP is assumed to be the Profile Data method used (any suitable 1586 alternative can be used as well) 1587 o TLS is assumed to be the protocol for securing the Profile 1588 Retrieval (any other suitable protocol can be employed); 1589 authentication and security requirements are not addressed 1591 The flow diagram and an explanation of the messages follow. 1593 +----------------------+ 1594 +--------+ | SIP Service Provider | 1595 | Client | | | 1596 |(SIP UA)| | SIP PDS HTTP | 1597 +--------+ | PROXY Server | 1598 | | 1599 +----------------------+ 1600 | | | | 1601 | | | | 1602 | SUBSCRIBE | | | 1603 (SReq)|--------device profile--------->| | | 1604 | |------>| | 1605 | |200 OK | | 1606 | 200 OK |<------| | 1607 (SRes)|<-------------------------------| | | 1608 | | | | 1609 | | NOTIFY| | 1610 | NOTIFY (Content Indirection)|<------| | 1611 (NTFY)|<-------------------------------| | | 1612 | 200 OK | | | 1613 (NRes)|------------------------------->|200 OK | | 1614 | |------>| | 1615 | | 1616 | | 1617 | | 1618 |<<<<<<<<<<<<< TLS establishment >>>>>>>>>>>>>| 1619 | | 1620 | HTTP Request | 1621 (XReq)|---------------------------------------------->| 1622 | | 1623 | HTTP Response | 1624 (XRes)|<----------------------------------------------| 1625 | | 1627 (SReq) 1629 the Client transmits a request for the 'device' profile using the 1630 SIP SUBSCRIBE utilizing the Event Package specified in this 1631 framework. 1633 * Note: Some of the header fields (for example, Event, via) are 1634 continued on a separate line due to format constraints of 1635 this document 1637 SUBSCRIBE sip:MAC%3a000000000000@sip.example.net SIP/2.0 1638 Event: ua-profile;profile-type=device;vendor="vendor.example.net"; 1639 model="Z100";version="1.2.3";network-user="sip:user@sip.example.net" 1640 From: sip:MAC%3A000000000000@sip.example.net;tag=1234 1641 To: sip:MAC%3A000000000000@sip.example.net 1642 Call-ID: 3573853342923422@10.1.1.44 1643 CSeq: 2131 SUBSCRIBE 1644 Contact: sip:MAC%3A000000000000@sip.example.net 1645 Via: SIP/2.0/TCP 10.1.1.41; 1646 branch=z9hG4bK6d6d35b6e2a203104d97211a3d18f57a 1647 Accept: message/external-body, application/x-z100-device-profile 1648 Content-Length: 0 1650 (SRes) 1652 the SUBSCRIBE request is received by a SIP Proxy in the Service 1653 Provider's network which transmits it to the PDS. The PDS accepts 1654 the response and responds with a 200 OK 1655 * Note: The Client and the SIP proxy may have established a 1656 secure communications channel (for example, TLS) 1658 (NTFY) 1660 subsequently, the PDS transmits a SIP NOTIFY message indicating 1661 the profile location 1662 * Note: Some of the fields (for example, content-type) are 1663 continued on a separate line due to format constraints of this 1664 document 1666 NOTIFY sip:MAC%3A000000000000@10.1.1.44 SIP/2.0 1667 Event: ua-profile;effective-by=3600 1668 From: sip:MAC%3A000000000000@sip.example.net;tag=abca 1669 To: sip:MAC%3A000000000000@sip.example.net;tag=1231 1670 Call-ID: 3573853342923422@10.1.1.44 1671 CSeq: 322 NOTIFY 1672 Via: SIP/2.0/UDP 192.168.0.3; 1673 branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d0 1674 MIME-Version: 1.0 1675 Content-Type: message/external-body; access-type="URL"; 1676 expiration="Mon, 01 Jan 2010 09:00:00 UTC"; 1677 URL="http://sip.example.net/z100-000000000000.html"; 1678 size=9999 1679 hash=10AB568E91245681AC1B 1681 Content-Type: application/x-z100-device-profile 1682 Content-ID: <39EHF78SA@sip.example.net> 1683 . 1684 . 1685 . 1687 (NRes) 1689 Client accepts the NOTIFY message and responds with a 200 OK 1691 (XReq) 1693 once the necessary secure communications channel is established, 1694 the Client sends an HTTP request to the HTTP server indicated in 1695 the NOTIFY 1697 (XRes) 1699 the HTTP server responds to the request via a HTTP response 1700 containing the profile contents 1702 7.2. Example 2: Client obtaining change notification 1704 The following example illustrates the case where a User (X) is 1705 simultaneously accessing services via two different Clients (for 1706 example, Multimedia Soft Clients on a PC and PDA) and has access to a 1707 User Interface (UI) that allows for changes to the User profile. 1709 The following are assumed for this example: 1711 o The Clients (A & B) obtain the necessary profiles from the same 1712 SIP Service Provider 1713 o The SIP Service Provider also provides a User Interface (UI) that 1714 allows the User to change preferences that impact the User profile 1716 The flow diagram and an explanation of the messages follow. 1717 o Note: The example only shows retrieval of User X's profile, but it 1718 may request and retrieve other profiles (for example, local- 1719 network, Client). 1721 ----- ----- 1722 |User |_________| UI* | * = User Interface 1723 | X | | | 1724 ----- ----- 1725 / \ 1726 / \ 1727 / \ +----------------------+ 1728 +--------+ +--------+ | SIP Service Provider | 1729 | Client | | Client | | | 1730 | A | | B | | SIP PDS HTTP | 1731 +--------+ +--------+ | PROXY Server | 1732 +----------------------+ 1733 | | | | 1734 | | | | 1735 (A-EX)|<=Enrolls for User X's profile=>|<=====>| | 1736 | | | | 1737 | | 1738 (A-RX)|<===Retrieves User X's profile================>| 1739 | | 1740 | | | | | 1741 | | Enrolls for | | | 1742 | (B-EX)|<== User X's ==>|<=====>| | 1743 | | profile | | | 1744 | | | | | 1745 | | | 1746 | (B-RX)|<= Retrieves User X's profile=>| 1747 | | 1748 | | | 1749 | (HPut)|---------------------->| 1750 | | | 1751 | (HRes)|<----------------------| 1752 | | 1753 | | | | 1754 | | NOTIFY| | 1755 | NOTIFY |<------| | 1757 (A-NT)|<-------------------------------| | | 1758 | 200 OK | | | 1759 (A-RS)|------------------------------->|200 OK | | 1760 | |------>| | 1761 | | 1762 | | | NOTIFY| | 1763 | | NOTIFY |<------| | 1764 | (B-NT)|<---------------| | | 1765 | | 200 OK | | | 1766 | (B-RS)|--------------->|200 OK | | 1767 | | |------>| | 1768 | | 1769 | | 1770 (A-RX)|<===Retrieves User X's profile================>| 1771 | | 1772 | | | 1773 | | | 1774 | (B-RX)|<= Retrieves User X's profile=>| 1775 | | | 1777 (A-EX) Client A discovers, enrolls and obtains notification related 1778 to User X's profile 1779 (A-RX) Client A retrieves User X's profile 1780 (B-EX) Client B discovers, enrolls and obtains notification related 1781 to User X's profile 1782 (B-RX) Client B retrieves User X's profile 1783 (HPut) Changes affected by the User via the User Interface (UI) are 1784 uploaded to the HTTP Server 1785 * Note: The UI itself can act as a Client and subscribe to User 1786 X's profile. This is not the case in the example shown. 1787 (HRes) Changes are accepted by the HTTP server 1788 (A-NT) PDS transmits a NOTIFY message to Client A indicating the 1789 changed profile. A sample message is shown below: 1790 Note: Some of the fields (for example, Via) are continued on a 1791 separate line due to format constraints of this document 1793 NOTIFY sip:userX@10.1.1.44 SIP/2.0 1794 Event: ua-profile;effective-by=3600 1795 From: sip:userX@sip.example.net;tag=abcd 1796 To: sip:userX@sip.example.net.net;tag=1234 1797 Call-ID: 3573853342923422@10.1.1.44 1798 CSeq: 322 NOTIFY 1799 Via: SIP/2.0/UDP 192.168.0.3; 1800 branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d1 1801 MIME-Version: 1.0 1802 Content-Type: message/external-body; access-type="URL"; 1803 expiration="Mon, 01 Jan 2010 09:00:00 UTC"; 1804 URL="http://www.example.com/user-x-profile.html"; 1805 size=9999 1806 hash=123456789AAABBBCCCDD 1807 . 1808 . 1809 . 1811 (A-RS) Client A accepts the NOTIFY and sends a 200 OK 1812 (B-NT) PDS transmits a NOTIFY message to Client B indicating the 1813 changed profile. A sample message is shown below: 1814 Note: Some of the fields (for example, Via) are continued on a 1815 separate line due to format constraints of this document 1817 NOTIFY sip:userX@10.1.1.43 SIP/2.0 1818 Event: ua-profile;effective-by=3600 1819 From: sip:userX@sip.example.net;tag=abce 1820 To: sip:userX@sip.example.net.net;tag=1235 1821 Call-ID: 3573853342923422@10.1.1.43 1822 CSeq: 322 NOTIFY 1823 Via: SIP/2.0/UDP 192.168.0.3; 1824 branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d2 1825 MIME-Version: 1.0 1826 Content-Type: message/external-body; access-type="URL"; 1827 expiration="Mon, 01 Jan 2010 09:00:00 UTC"; 1828 URL="http://www.example.com/user-x-profile.html"; 1829 size=9999 1830 hash=123456789AAABBBCCCDD 1831 . 1832 . 1833 . 1835 (B-RS) Client B accepts the NOTIFY and sends a 200 OK 1836 (A-RX) Client A retrieves the updated profile pertaining to User X 1837 (B-RX) Client B retrieves the updated profile pertaining to User X 1839 8. IANA Considerations 1841 There are two IANA considerations associated with this document, SIP 1842 Event Package and HTTP header. These are outlined in this section. 1844 8.1. SIP Event Package 1846 This specification registers a new event package as defined in 1847 [RFC3265]. The following information required for this registration: 1849 Package Name: ua-profile 1850 Package or Template-Package: This is a package 1851 Published Document: RFC XXXX (Note to RFC Editor: Please fill in 1852 XXXX with the RFC number of this specification). 1853 Persons to Contact: Daniel Petrie dan.ietf AT SIPez DOT com, 1854 sumanth@cablelabs.com 1855 New event header parameters: profile-type, vendor, model, version, 1856 effective-by, network-user (the profile-type parameter has 1857 predefined values. The new event header parameters do not) 1858 The following table illustrates the additions to the IANA SIP Header 1859 Field Parameters and Parameter Values: (Note to RFC Editor: Please 1860 fill in XXXX with the RFC number of this specification) 1862 Predefined 1863 Header Field Parameter Name Values Reference 1864 ---------------------------- --------------- --------- --------- 1865 Event profile-type Yes [RFCXXXX] 1866 Event vendor No [RFCXXXX] 1867 Event model No [RFCXXXX] 1868 Event version No [RFCXXXX] 1869 Event effective-by No [RFCXXXX] 1870 Event network-user No [RFCXXXX] 1872 8.2. New HTTP Event Header 1874 This document defines a new permanent HTTP request header field: 1875 Event. 1876 Header field name: Event 1877 Applicable protocol: http 1878 Status: standard 1879 Author/Change controller: IETF 1880 Specification document(s): [RFCXXXX] (Note to RFC Editor: Please 1881 fill in XXXX with the RFC number of this specification). 1883 9. Security Considerations 1885 The framework specified in this document allows Service Providers to 1886 propagate profile data to Clients. This is accomplished by requiring 1887 deployed Clients to implement the framework. The framework 1888 (explained in Section 5) specifies a Profile Life Cycle that allows 1889 Clients to request and obtain profile data. The Profile Life Cycle 1890 is enabled using an Event Package (defined in Section 6) as per 1891 [RFC3265]. Thus, the primary components requiring security 1892 considerations are: Event Package, Profile Life Cycle and Profile 1893 Data. The considerations, requirements and recommendations are 1894 presented in the following sub-sections. 1896 9.1. Event Package 1898 The Event Package usage MUST adhere to the security considerations 1899 and requirements (access control, Notifier privacy mechanism, Denial- 1900 of-Service attacks, replay attacks, and Man-in-the Middle attacks) 1901 specified in Section 5 of [RFC3265]. Specifically for the Event 1902 Package defined in this framework, this sub-section hightlights 1903 additional considerations and security requirements. 1905 The Notifier MUST authenticate any SUBSCRIBE request with a known 1906 identity. It MUST NOT accept any SUBSCRIBE requests that fail an 1907 authentication challenge. Refer to [I-D.ietf-sip-identity] and 1908 [RFC3261] for RECOMMENDED SIP authentication methods. 1910 Unless configured otherwise, the Notifier SHOULD NOT respond to 1911 SUBSCRIBEs without an identity that can be authenticated. Exceptions 1912 include deployments catering to unknown Clients (for example, for 1913 self-subscription) or for troubleshooting (for example, credentials 1914 misplaced by a user). Refer to Section 9.3 for Profile Data 1915 considerations in such cases. 1917 The Notifier MUST transmit NOTIFY messages with sensitive profile 1918 data over an authenticated, integrity protected channel. Refer to 1919 Section 9.3 for information on profile data classification. It 1920 SHOULD transmit Content Indirection information (without profile 1921 data) over an integrity-protected channel, unless configured 1922 otherwise (for example, if the Service Provider is catering to 1923 unknown Clients). For data provided via content indirection, 1924 Subscribers MUST implement the hash verification scheme described in 1925 [RFC4483]. 1927 Subscribers with the ability to authenticate a PDS (for example, 1928 Service Provider Certificates, mutual shared secrets) MUST employ 1929 such mechanisms prior to retrieving data. This framework RECOMMENDS 1930 that Service Providers consider providing this ability to deployed 1931 Clients. 1933 9.2. Profile Life Cycle 1935 Profile Discovery involves various protocols such as DHCP and DNS 1936 that may provide unauthenticated information. Thus, successful 1937 Profile Enrollment and subsequent Profile Notification with an 1938 authenticated PDS (for example, via mutual authentication) are 1939 required to prevent threats such as impersonation or Denial of 1940 Service. Given the nature of these mechanisms and to prevent service 1941 disruption due to such threats, the specification recommends caching 1942 of retrieved profiles (see Section 5.4) by the Clients. It also 1943 provides for multiple Profile Discovery mechanisms (based on Profile 1944 Types) which can minimally aid in thwarting security threats from 1945 individual mechanisms (for example, impersonated DNS). 1947 The specification strongly RECOMMENDS that solutions implementing the 1948 Framework provide the Clients with the ability to recognize, mutually 1949 authenticate and establish integrity protected SIP communication 1950 channels (for example, mutual TLS using certificates). Clients 1951 without such an ability SHOULD report changes to sensitive profile 1952 data (refer to Profile Data) using suitable mechanisms (for example, 1953 management reporting). Further, Clients with access to credentials 1954 (even if obtained via a User Interface) MUST respond to 1955 authentication challenges. 1957 Profile Enrollment and Profile Notification are done via the Event 1958 Package definition and the security requirements have been presented 1959 in Section 9.1. Profile Retrieval and Profile Change Upload are 1960 accomplished using Profile Data Frameworks and are addressed in 1961 Section 9.3. 1963 9.3. Profile Data 1965 Profile data provided using any of the Profile Types is expected to 1966 happen via suitable Profile Data Framework (such as XCAP) or suitable 1967 protocol (such as HTTP). Data defined using such frameworks may be 1968 sensitive (for example, user credentials) or non-sensitive (for 1969 example, list of DNS servers). 1971 If a profile contains sensitive data, it MUST be provided over a 1972 mutual-authenticated, integrity protected channel. Even if the data 1973 is non-sensitive, it SHOULD still be provided over a secure channel. 1974 Exceptions include cases where deployments cater to unknown Clients 1975 or for troubleshooting. 1977 For profile data delivered within the framework (i.e. data is 1978 provided in the NOTIFY), the requirements specified in Section 9.1. 1980 When the profile data is delivered via content indirection, 1981 authentication, integrity, confidentiality MUST be provided by the 1982 Profile Data Frameworks containing the retrieval mechanisms. 1983 Further, a non-replayable authentication mechanism (for example, 1984 Digest authentication) MUST be used. 1986 10. Acknowledgements 1988 Many thanks to those who contributed and commented on the many 1989 iterations of this document. Detailed comments were provided by the 1990 following individuals: Jonathan Rosenberg from Cisco, Henning 1991 Schulzrinne from Columbia University, Cullen Jennings from Cisco, 1992 Rohan Mahy from Plantronics, Rich Schaaf from Pingtel, Volker Hilt 1993 from Bell Labs, Adam Roach of Estacado Systems, Hisham Khartabil from 1994 Telio, Henry Sinnreich from MCI, Martin Dolly from AT&T Labs, John 1995 Elwell from Siemens, Elliot Eichen and Robert Liao from Verizon, Dale 1996 Worley from Pingtel, Francois Audet from Nortel, Roni Even from 1997 Polycom, Jason Fischl from Counterpath, Josh Littlefield from Cisco, 1998 Nhut Nguyen from Samsung. 2000 The editor would like to extend a special thanks to the experts who 2001 contributed to the restructuring and revisions as proposed by the 2002 SIPPING WG, specifically Keith Drage from Lucent (restructuring 2003 proposal), Peter Blatherwick from Mitel (who also contributed to the 2004 Overview and Introduction sections), Josh Littlefield from Cisco 2005 (examples and diagram suggestions), Alvin Jiang of Engin, Martin 2006 Dolly from AT&T, and Jason Fischl from Counterpath. Additionally, 2007 sincere appreciation is extended to the chairs (Mary Barnes from 2008 Nortel and Gonzalo Camarillo from Ericsson) and the Area Directors 2009 (Cullen Jennings from Cisco and Jon Peterson and Cisco) for 2010 facilitating discussions, and for reviews and contributions. 2012 11. Open Items 2014 [[Editor's note: This is being used a place holder only and will be 2015 removed once the items listed are addressed]] 2017 The following comments are considered to be open (i.e. not addressed) 2018 in this version of the I-D 2019 o Replace 'Service Provider' with a term better representative of 2020 its definition 2021 o Analyze potential unformity in the formation of the Subscription 2022 URI across Profile Types. If not, provide a bried explanation of 2023 the analysis 2024 o Analyze the current SHOULD v/s MUST requirements for the Profile 2025 Framework to obtain consensus and facilitate interoperability 2026 o Present an analysis of the Local Network Profile discovery methods 2027 in DNS-less environments 2028 o Check on potentially referencing RFC4122 instead of OUTBOUND 2029 o Security Considerations requires further review 2031 12. Change History 2033 [[RFC Editor: Please remove this entire section upon publication as 2034 an RFC.]] 2036 12.1. Changes from draft-ietf-sipping-config-framework-09.txt 2038 Following the ad-hoc SIPPING WG discussions at IETF#67 and as per the 2039 email from Gonzalo Camarillo dated 12/07/2006, Sumanth was appointed 2040 as the new editor. This sub-section highlights the changes made by 2041 the editor (as per expert recommendations from the SIPPING WG folks 2042 interested in this effort) and the author. 2044 Changes incorporated by the editor: 2045 o Document was restructured based on a) Keith's recommendations in 2046 the email dated 11/09/2006 and responses (Peter, Sumanth, Josh) b) 2047 subsequent discussions by the ad-hoc group consisting of the 2048 editor, the author, expert contributors (Peter Blatherwick, Josh 2049 Littlefield, Alvin Jiang, Jason Fischl, Martin Dolly, Cullen 2050 Jennings) and the co-chairs . Further changes follow. 2051 o Use cases were made high-level with detailed examples added later 2052 on 2053 o Several sections were modified as part of the restructuring (for 2054 example, Overview, Introduction, Framework Requirements, Security 2055 Sections) 2056 o General editorial updates were made 2058 Changes incorporated by the author: 2060 o Incorporated numerous edits and corrections from CableLabs review. 2061 o Used better ascii art picture of overview from Josh Littlefield 2062 o Fixed the normative text for network-user so that it is now 2063 consistant: MAY provide for device profile, MUST provide for 2064 local-network profile. 2066 12.2. Changes from draft-ietf-sipping-config-framework-08.txt 2068 The Request URI for profile-type=localnet now SHOULD not have a 2069 user part to make routing easier. The From field SHOULD now 2070 contain the device id so that device tracking can still be done. 2071 Described the concept of profile-type as a filter and added 2072 normative text requiring 404 for profile types not provided. 2073 Moved "application" profile type to 2074 draft-ietf-sipping-xcap-config-01. The "application" value for 2075 the profile-type parameter will also be used as a requirement that 2076 XCAP be supported. 2077 Fixed text on certificate validation. 2078 Added new HTTP header: Event to IANA section and clean up the IANA 2079 section. 2080 Added diagram for Service Provider use case schenario. 2081 Added clarification for HTTP Event header. 2082 Added clarification of subscriber handling of NOTIFY with no body. 2084 12.3. Changes from draft-ietf-sipping-config-framework-07.txt 2086 Made XCAP informative reference. Removed "document" and "auid" 2087 event header parameters, and Usage of XCAP section to be put in 2088 separate supplementary draft. 2089 Fixed ABNF for network-user to be addr-spec only (not name-addr) 2090 and to be quoted as well. 2091 Synchronized with XCAP path terminology. Removed XCAP path 2092 definition as it is already defined in XCAP. 2093 User agent instance ID is now defined in output (not GRUU). 2094 Clarified the rational for the network-user parameter. 2095 Added text to suggest URIs for To and From fields. 2096 Clarified use of network-user parameter. 2097 Allow the use of the auid and document parameters per request by 2098 the OMA. 2100 12.4. Changes from draft-ietf-sipping-config-framework-06.txt 2102 Restructured the introduction and overview section to be more 2103 consistent with other Internet-Drafts. 2104 Added additional clarification for the Digest Authentication and 2105 Certificate based authentication cases in the security section. 2106 Added two use case scenarios with cross referencing to better 2107 illustrate how the framework works. Added better cross 2108 referencing in the overview section to help readers find where 2109 concepts and functionality is defined in the document. 2111 Clarified the section on the use of XCAP. Changed the Event 2112 parameter "App-Id" to "auid". Made "auid" mutually exclusive to 2113 "document". "auid" is now only used with XCAP. 2114 Local network subscription URI changed to @ 2115 (was anonymous@). Having a 2116 different Request URI for each device allows the network 2117 management to track user agents and potentially manage bandwidth, 2118 port allocation, etc. 2119 Changed event package name from sip-profile to ua-profile per 2120 discussion on the list and last IETF meeting. 2121 Changed "local" profile type token to "local-network" per 2122 discussion on the list and last IETF meeting. 2123 Simplified "Vendor", "Model", "Version" event header parameters to 2124 allow only quoted string values (previously allowed token as 2125 well). 2126 Clarified use of the term cache. 2127 Added references for ABNF constructs. 2128 Numerous editorial changes. Thanks Dale! 2130 12.5. Changes from draft-ietf-sipping-config-framework-05.txt 2132 Made HTTP and HTTPS profile transport schemes mandatory in the 2133 profile delivery server. The subscribing device must implement 2134 HTTP or HTTPS as the profile transport scheme. 2135 Rewrote the security considerations section. 2136 Divided references into Normative and Informative. 2137 Minor edits throughout. 2139 12.6. Changes from draft-ietf-sipping-config-framework-04.txt 2141 Clarified usage of instance-id 2142 Specify which event header parameters are mandatory or optional 2143 and in which messages. 2144 Included complete list of event header parameters in parameter 2145 overview and IANA sections. 2146 Removed TFTP reference as protocol for profile transport. 2147 Added examples for discovery. 2148 Added ABNF for all event header parameters. 2149 Changed profile-name parameter back to profile-type. This was 2150 changed to profile-name in 02 when the parameter could contain 2151 either a token or a path. Now that the path is contained in the 2152 separate parameter: "document", profile-type make more sense as 2153 the parameter name. 2154 Fixed some statements that should have and should not have been 2155 normative. 2156 Added the ability for the user agent to request that the default 2157 user associated with the device be set/changed using the "network- 2158 user" parameter. 2160 A bunch of editorial nits and fixes. 2162 12.7. Changes from draft-ietf-sipping-config-framework-03.txt 2164 Incorporated changes to better support the requirements for the use 2165 of this event package with XCAP and SIMPLE so that we can have one 2166 package (i.e. simple-xcap-diff now defines a content type not a 2167 package). Added an additional profile type: "application". Added 2168 document and app-id Event header parameters in support of the 2169 application profile. Define a loose high level data model or 2170 relationship between the four profile types. Tried to edit and fix 2171 the confusing and ambiguous sections related to URI formation and 2172 discovery for the different profile types. Better describe the 2173 importance of uniqueness for the instance id which is used in the 2174 user part of the device URI. 2176 12.8. Changes from draft-ietf-sipping-config-framework-02.txt 2178 Added the concept of the local network as a source of profile data. 2179 There are now three separate logical sources for profile data: user, 2180 device and local network. Each of these requires a separate 2181 subscription to obtain. 2183 12.9. Changes from draft-ietf-sipping-config-framework-01.txt 2185 Changed the name of the profile-type event parameter to profile-name. 2186 Also allow the profile-name parameter to be either a token or an 2187 explicit URI. 2189 Allow content indirection to be optional. Clarified the use of the 2190 Accept header to indicate how the profile is to be delivered. 2192 Added some content to the Iana section. 2194 12.10. Changes from draft-ietf-sipping-config-framework-00.txt 2196 This version of the document was entirely restructured and re-written 2197 from the previous version as it had been micro edited too much. 2199 All of the aspects of defining the event package are now organized in 2200 one section and is believed to be complete and up to date with 2201 [RFC3265]. 2203 The URI used to subscribe to the event package is now either the user 2204 or device address or record. 2206 The user agent information (vendor, model, MAC and serial number) are 2207 now provided as event header parameters. 2209 Added a mechanism to force profile changes to be make effective by 2210 the user agent in a specified maximum period of time. 2212 Changed the name of the event package from sip-config to ua-profile 2214 Three high level security approaches are now specified. 2216 12.11. Changes from draft-petrie-sipping-config-framework-00.txt 2218 Changed name to reflect SIPPING work group item 2220 Synchronized with changes to SIP DHCP [RFC3361], SIP [RFC3261] and 2221 [RFC3263], SIP Events [RFC3265] and content indirection [RFC4483] 2223 Moved the device identity parameters from the From field parameters 2224 to User-Agent header parameters. 2226 Many thanks to Rich Schaaf of Pingtel, Cullen Jennings of Cisco and 2227 Adam Roach of Estacado Systems for the great comments and input. 2229 12.12. Changes from draft-petrie-sip-config-framework-01.txt 2231 Changed the name as this belongs in the SIPPING work group. 2233 Minor edits 2235 12.13. Changes from draft-petrie-sip-config-framework-00.txt 2237 Split the enrollment into a single SUBSCRIBE dialog for each profile. 2238 The 00 draft sent a single SUBSCRIBE listing all of the desired. 2239 These have been split so that each enrollment can be routed 2240 differently. As there is a concept of device specific and user 2241 specific profiles, these may also be managed on separate servers. 2242 For instance in a nomadic situation the device might get its profile 2243 data from a local server which knows the LAN specific profile data. 2244 At the same time the user specific profiles might come from the 2245 user's home environment profile delivery server. 2247 Removed the Config-Expires header as it is largely superfluous with 2248 the SUBSCRIBE Expires header. 2250 Eliminated some of the complexity in the discovery mechanism. 2252 Suggest caching information discovered about a profile delivery 2253 server to avoid an avalanche problem when a whole building full of 2254 devices powers up. 2256 Added the User-Profile From header field parameter so that the device 2257 can request a user specific profile for a user that is different from 2258 the device's default user. 2260 13. References 2262 13.1. Normative References 2264 [I-D.ietf-sip-identity] 2265 Peterson, J. and C. Jennings, "Enhancements for 2266 Authenticated Identity Management in the Session 2267 Initiation Protocol (SIP)", draft-ietf-sip-identity-06 2268 (work in progress), October 2005. 2270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2271 Requirement Levels", BCP 14, RFC 2119, March 1997. 2273 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 2274 Extensions", RFC 2132, March 1997. 2276 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2277 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2278 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2280 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2282 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2283 A., Peterson, J., Sparks, R., Handley, M., and E. 2284 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2285 June 2002. 2287 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 2288 Protocol (SIP): Locating SIP Servers", RFC 3263, 2289 June 2002. 2291 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 2292 Event Notification", RFC 3265, June 2002. 2294 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 2295 (DHCP-for-IPv4) Option for Session Initiation Protocol 2296 (SIP) Servers", RFC 3361, August 2002. 2298 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2299 Unique IDentifier (UUID) URN Namespace", RFC 4122, 2300 July 2005. 2302 [RFC4483] Burger, E., "A Mechanism for Content Indirection in 2303 Session Initiation Protocol (SIP) Messages", RFC 4483, 2304 May 2006. 2306 13.2. Informative References 2308 [I-D.ietf-simple-xcap] 2309 Rosenberg, J., "The Extensible Markup Language (XML) 2310 Configuration Access Protocol (XCAP)", 2311 draft-ietf-simple-xcap-12 (work in progress), 2312 October 2006. 2314 [I-D.ietf-simple-xcap-diff] 2315 Rosenberg, J., "An Extensible Markup Language (XML) 2316 Document Format for Indicating A Change in XML 2317 Configuration Access Protocol (XCAP) Resources", 2318 draft-ietf-simple-xcap-diff-04 (work in progress), 2319 October 2006. 2321 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 2322 STD 9, RFC 959, October 1985. 2324 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2325 RFC 2131, March 1997. 2327 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 2329 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 2330 Protocol (v3): Technical Specification", RFC 3377, 2331 September 2002. 2333 [RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and 2334 Applicability Statement for the Trivial File Transfer 2335 Protocol (TFTP)", RFC 3617, October 2003. 2337 Authors' Addresses 2339 Daniel Petrie 2340 SIPez LLC. 2341 34 Robbins Rd 2342 Arlington, MA 02476 2343 USA 2345 Email: dan.ietf AT SIPez DOT com 2346 URI: http://www.SIPez.com/ 2347 Sumanth Channabasappa (Editor) 2348 CableLabs 2349 858 Coal Creek Circle 2350 Louisville, Co 80027 2351 USA 2353 Email: sumanth@cablelabs.com 2354 URI: http://www.cablelabs.com/ 2356 Full Copyright Statement 2358 Copyright (C) The IETF Trust (2007). 2360 This document is subject to the rights, licenses and restrictions 2361 contained in BCP 78, and except as set forth therein, the authors 2362 retain all their rights. 2364 This document and the information contained herein are provided on an 2365 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2366 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2367 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2368 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2369 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2370 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2372 Intellectual Property 2374 The IETF takes no position regarding the validity or scope of any 2375 Intellectual Property Rights or other rights that might be claimed to 2376 pertain to the implementation or use of the technology described in 2377 this document or the extent to which any license under such rights 2378 might or might not be available; nor does it represent that it has 2379 made any independent effort to identify any such rights. Information 2380 on the procedures with respect to rights in RFC documents can be 2381 found in BCP 78 and BCP 79. 2383 Copies of IPR disclosures made to the IETF Secretariat and any 2384 assurances of licenses to be made available, or the result of an 2385 attempt made to obtain a general license or permission for the use of 2386 such proprietary rights by implementers or users of this 2387 specification can be obtained from the IETF on-line IPR repository at 2388 http://www.ietf.org/ipr. 2390 The IETF invites any interested party to bring to its attention any 2391 copyrights, patents or patent applications, or other proprietary 2392 rights that may cover technology that may be required to implement 2393 this standard. Please address the information to the IETF at 2394 ietf-ipr@ietf.org. 2396 Acknowledgment 2398 Funding for the RFC Editor function is provided by the IETF 2399 Administrative Support Activity (IASA).