idnits 2.17.1 draft-ietf-sipping-config-framework-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 294 has weird spacing: '...ely the devic...' == Line 830 has weird spacing: '... Events for t...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 14, 2004) is 7367 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) == Unused Reference: 'RFC2131' is defined on line 865, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 868, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 871, but no explicit reference was found in the text == Unused Reference: 'RFC2617' is defined on line 878, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-simple-xcap-package-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-simple-xcap-package' == Outdated reference: A later version (-05) exists of draft-ietf-sip-content-indirect-mech-03 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-sipping-ua-prof-framewk-reqs' -- Possible downref: Normative reference to a draft: ref. 'I-D.rosenberg-simple-xcap' == Outdated reference: A later version (-08) exists of draft-sinnreich-sipdev-req-03 ** Downref: Normative reference to an Informational draft: draft-sinnreich-sipdev-req (ref. 'I-D.sinnreich-sipdev-req') ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3377 (Obsoleted by RFC 4510) ** Downref: Normative reference to an Informational RFC: RFC 3617 Summary: 11 errors (**), 0 flaws (~~), 13 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING D. Petrie 3 Internet-Draft Pingtel Corp. 4 Expires: August 14, 2004 February 14, 2004 6 A Framework for SIP User Agent Profile Delivery 7 draft-ietf-sipping-config-framework-02.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on August 14, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This document defines the application of a set of protocols for 38 providing profile data to SIP user agents. The objective is to 39 define a means for automatically providing profile data a user agent 40 needs to be functional without user or administrative intervention. 41 The framework for discovery, delivery, notification and updates of 42 user agent profile data is defined here. As part of this framework a 43 new SIP event package is defined here for the notification of profile 44 changes. This framework is also intended to ease on going 45 administration and upgrading of large scale deployments of SIP user 46 agents. The contents and format of the profile data to be defined is 47 outside the scope of this document. 49 Table of Contents 51 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1 Requirements Terminology . . . . . . . . . . . . . . . . . . 3 54 2.2 Profile Delivery Framework Terminology . . . . . . . . . . . 4 55 2.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Profile Change Event Notification Package . . . . . . . . . 6 57 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . . 6 58 3.2 Event Package Parameters . . . . . . . . . . . . . . . . . . 6 59 3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . 8 60 3.4 Subscription Duration . . . . . . . . . . . . . . . . . . . 8 61 3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.6 Notifier processing of SUBSCRIBE requests . . . . . . . . . 9 63 3.7 Notifier generation of NOTIFY requests . . . . . . . . . . . 9 64 3.8 Subscriber processing of NOTIFY requests . . . . . . . . . . 10 65 3.9 Handling of forked requests . . . . . . . . . . . . . . . . 10 66 3.10 Rate of notifications . . . . . . . . . . . . . . . . . . . 11 67 3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . . 11 68 3.12 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 3.13 Use of URIs to Retrieve State . . . . . . . . . . . . . . . 12 70 4. Profile Delivery Framework Details . . . . . . . . . . . . . 12 71 4.1 Discovery of Subscription URI . . . . . . . . . . . . . . . 12 72 4.2 Enrollment with Profile Server . . . . . . . . . . . . . . . 14 73 4.3 Notification of Profile Changes . . . . . . . . . . . . . . 14 74 4.4 Retrieval of Profile Data . . . . . . . . . . . . . . . . . 14 75 4.5 Upload of Profile Changes . . . . . . . . . . . . . . . . . 15 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 77 5.1 SIP Event Package . . . . . . . . . . . . . . . . . . . . . 15 78 6. Security Considerations . . . . . . . . . . . . . . . . . . 15 79 6.1 Symmetric Encryption of Profile Data . . . . . . . . . . . . 15 80 7. Differences from Simple XCAP Package . . . . . . . . . . . . 16 81 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 16 82 9. Change History . . . . . . . . . . . . . . . . . . . . . . . 16 83 9.1 Changes from draft-ietf-sipping-config-framework-01.txt . . 17 84 9.2 Changes from draft-ietf-sipping-config-framework-00.txt . . 17 85 9.3 Changes from draft-petrie-sipping-config-framework-00.txt . 17 86 9.4 Changes from draft-petrie-sip-config-framework-01.txt . . . 18 87 9.5 Changes from draft-petrie-sip-config-framework-00.txt . . . 18 88 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . 20 90 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20 91 Intellectual Property and Copyright Statements . . . . . . . 21 93 1. Motivation 95 Today all SIP user agent vendors use proprietary means of delivering 96 user or device profiles to the user agent. The profile delivery 97 framework defined in this document is intended to enable a first 98 phase migration to a standard means of providing profiles to SIP user 99 agents. It is expected that UA vendors will be able to use this 100 framework as a means of delivering their existing proprietary user 101 and device data profiles (i.e. using their existing proprietary 102 binary or text formats). This in itself is a tremendous advantage in 103 that a SIP environment can use a single profile delivery server for 104 profile data to user agents from multiple vendors. Follow-on 105 standardization activities can: 106 1. define a standard profile content format framework (e.g. XML with 107 name spaces [??] or name-value pairs [RFC0822]). 108 2. specify the content (i.e. name the profile data parameters, xml 109 schema, name spaces) of the data profiles. 111 One of the objectives of the framework described in this document is 112 to provide a start up experience similar to that of users of an 113 analog telephone. When you plug in an analog telephone it just works 114 (assuming the line is live and the switch has been provisioned). 115 There is no end user configuration required to make analog phone work 116 (at least in a basic sense). So the objective here is to be able to 117 take a new SIP user agent out of the box, plug it in (or install the 118 software) and have it get its profiles without human intervention 119 (other than security measures). This is necessary for cost effective 120 deployment of large numbers of user agents. 122 Another objective is to provide a scalable means for on going 123 administration of profiles. Administrators and users are likely to 124 want to make changes to user and device profiles. 126 Additional requirements for the framework defined in this document 127 are described in: [I-D.ietf-sipping-ua-prof-framewk-reqs], 128 [I-D.sinnreich-sipdev-req] 130 2. Introduction 132 2.1 Requirements Terminology 134 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 135 "MAY" that appear in this document are to be interpreted as described 136 in RFC 2119[RFC2119]. 138 2.2 Profile Delivery Framework Terminology 140 profile - data set specific to a user or device. 141 device - SIP user agent, either software or hardware appliance. 142 profile content server - The server that provides the content of the 143 profiles using the protocol specified by the URL scheme. 144 notifier - The SIP user agent server which processes SUBSCRIBE 145 requests for events and sends NOTIFY requests with profile data or 146 URI(s) point to the data. 147 profile delivery server - The logical collection of the SIP notifier 148 and the server which provides the contents of the profile URI(s). 150 2.3 Overview 152 The profile life cycle can be described by five functional steps. 153 These steps are not necessarily discrete. However it is useful to 154 describe these steps as logically distinct. These steps are named 155 as follows: 157 Discovery - discover a profile delivery server 158 Enrollment - enroll with the profile delivery server 159 Profile Retrieval - retrieve profile data 160 Profile Change Notification - receive notification of profile changes 161 Profile Change Upload - upload profile data changes back to the 162 profile delivery server 164 Discovery is the process by which a UA SHOULD find the address and 165 port at which it SHOULD enroll with the profile delivery server. As 166 there is no single discovery mechanism which will work in all network 167 environments, a number of discovery mechanisms are defined with a 168 prescribed order in which the UA SHOULD try them until one succeeds. 170 Enrollment is the process by which a UA SHOULD make itself known to 171 the profile delivery server. In enrolling the UA MUST provide 172 identity information, name requested profile type(s) and supported 173 protocols for profile retrieval. It SHOULD also subscribe to a 174 mechanism for notification of profile changes. As a result of 175 enrollment, the UA receives the data or the URI for each of the 176 profiles that the profile delivery server is able to provide. Each 177 profile type (set) requires a separate enrollment or SUBSCRIBE 178 session. 180 Profile Retrieval is the process of retrieving the content for each 181 of the profiles the UA requested. 183 Profile Change Notification is the process by which the profile 184 delivery server notifies the UA that the content of one or more of 185 the profiles has changed. If the content is provided indirectly the 186 UA SHOULD retrieve the profile from the specified URI upon receipt of 187 the change notification. 189 Profile Upload is the process by which a UA or other entity (e.g. 190 OSS, corporate directory or configuration management server) pushes a 191 change to the profile data back up to the profile delivery server. 193 This framework defines a new SIP event package [RFC3265] to solve 194 enrollment and profile change notification steps. 196 The question arises as to why SIP should be used for the profile 197 delivery framework. In this document SIP is used for only a small 198 portion of the framework. Other existing protocols are more 199 appropriate for transport of the profile contents (upstream and 200 downstream of the user agent) and are suggested in this document. 201 The discovery step is simply a specified order and application of 202 existing protocols. SIP is only needed for the enrollment and change 203 notification functionality of the profile delivery framework. In 204 many SIP environments (e.g. carrier/subscriber and multi-site 205 enterprise) firewall, NAT and IP addressing issues make it difficult 206 to get messages between the profile delivery server and the user 207 agent requiring the profiles. 209 With SIP the users and devices already are assigned globally routable 210 addresses. In addition the firewall and NAT problems are already 211 presumably solved in the environments in which SIP user agents are to 212 be used. Therefore SIP is the best solution for allowing the user 213 agent to enroll with the profile delivery server which may require 214 traversal of multiple firewalls and NATs. For the same reason the 215 notification of profile changes is best solved by SIP. 217 It is assumed that the content delivery server MUST be either in the 218 public network or accessible through a DMZ. The user agents 219 requiring profiles may be behind firewalls and NATs and many 220 protocols, such as HTTP, may be used for profile content retrieval 221 without special consideration in the firewalls and NATs. 223 A conscious separation of user and device profiles is made in this 224 document. This is useful to provide features such as hoteling as 225 well as securing or restricting user agent functionality. By 226 maintaining this separation, a user may walk up to someone else's 227 user agent and direct that user agent to get their profile data. In 228 doing so the user agent can replace the previous user's profile data 229 while still keeping the devices profile data that may be necessary 230 for core functionality and communication described in this document. 232 3. Profile Change Event Notification Package 234 This section defines a new SIP event package [RFC3265]. The purpose 235 of this event package is to send to subscribers notification of 236 content changes to the profile(s) of interest and to provide the 237 location of the profile(s) via content indirection 238 [I-D.ietf-sip-content-indirect-mech] or directly in the body of the 239 NOTIFY. If the profile is large enough to cause packet fragmentation 240 over the transport protocol, the profile SHOULD use content 241 indirection. The user agent SHOULD specify the profile delivery 242 means and format via the MIME type in the Accepts header. 244 3.1 Event Package Name 246 The name of this package is "sip-profile". This value appears in the 247 Event header field present in SUBSCRIBE and NOTIFY requests for this 248 package as defined in [RFC3265]. 250 3.2 Event Package Parameters 252 This package defines the following new parameters for the event 253 header: profile-name, vendor, model, version, effective-by. The 254 effective-by parameter is for use in NOTIFY requests only. The 255 others are for use in the SUBSCRIBE request, but may be used in 256 NOTIFY requests as well. 258 The profile-name parameter is used to indicate the token name of the 259 profile type the user agent wishes to obtain URIs for or to 260 explicitly specify the URI to which it is to be notified of change. 261 Using a token in this parameter allows the URL semantics to be opaque 262 to the subscribing user agent. All it needs to know is the token 263 value for this parameter. However in some cases the user agent may 264 know the URI of the profile and only wishes to know about changes to 265 the profile. The user agent MAY supply the URI for the profile as 266 the value of the profile-name parameter. This document defines two 267 type categories of profiles and their token names. The contents or 268 format of the profiles is outside the scope of this document. The 269 two types of profiles define here are "user" and "device". 270 Specifying device type profile(s) indicates the desire for the URI(s) 271 and change notification of all profiles that are specific to the 272 device or user agent. Specifying user type profile(s) indicates the 273 desire for the URI(s) and change notification of all profile(s) that 274 are specific to the user. The user or device is identified in the 275 URI of the SUBSCRIBE request. The Accept header of the SUBSCRIBE 276 request MUST include the MIME types for all profile content types 277 that the subscribing user agent wishes to retrieve profiles or 278 receive change notifications. 280 The user or device token in the profile-name parameter may 281 represent a class or set of profiles as opposed to a single 282 profile. As standards are defined for specific profile contents 283 related to the user or device, it may be desirable to define 284 additional tokens for the profile-name header. This is to allow a 285 user agent to subscribe to that specific profile as opposed to the 286 entire class or set of user or device profiles. 288 The rational for the separation of user and device type profiles is 289 provided in section Section 2.3. It should be noted that either type 290 may indicate that zero or more URIs are provided in the NOTIFY 291 request. As discussed, a default user may be assigned to a device. 292 In this scenario the profile delivery server may provide the URI(s) 293 in the NOTIFY request for the default user when subscribing to the 294 device profile type. Effectively the device profile type becomes a 295 superset of the user profile type subscription. The user type is 296 still useful in this scenario to allow the user agent to obtain 297 profile data or URIs for a user other than the default user. This 298 provides the ability to support a hoteling function where a user may 299 "login" to any user agent and have it use a users profile(s). 301 The vendor, model and version parameters are tokens specified by the 302 vendor of the user agent. These parameters are useful to the profile 303 delivery server to effect the profiles provided. In some scenarios 304 it is desirable to provide different profiles based upon these 305 parameters. For example feature parameter X in a profile may work 306 differently on two versions of user agent. This gives the profile 307 deliver server the ability to compensate for or take advantage of the 308 differences. 310 The "effective-by" parameter in the Event header of the NOTIFY 311 specifies the maximum number of seconds before the user agent MUST 312 make the new profile effective. A value of 0 (zero) indicates that 313 the user agent MUST make the profiles effective immediately (despite 314 possible service interruptions). This gives the profile delivery 315 server the power to control when the profile is effective. This may 316 be important to resolve an emergency problem or disable a user agent 317 immediately. 319 SUBSCRIBE request example: 320 Event: sip-profile;profile-name=device; 321 vendor=acme;model=Z100;version=1.2.3 323 Event: sip-profile;profile-name= 324 "http://example.com/services/user-profiles/users/freds.xml"; 325 vendor=premier;model=trs8000;version=5.5 327 NOTIFY request examples: 328 Event:sip-profile;effective-by=0 330 Event:sip-profile;effective-by=3600 332 3.3 SUBSCRIBE Bodies 334 This package defines no new use of the SUBSCRIBE request body. 336 3.4 Subscription Duration 338 As profiles are generally static with infrequent changes, it is 339 recommended that default subscription duration be 86400 seconds (one 340 day). 342 3.5 NOTIFY Bodies 344 The size of profile content is likely to be hundreds to several 345 thousand bytes in size. Frequently even with very modest sized SDP 346 bodies, SIP messages get fragmented causing problems for many user 347 agents. For this reason the NOTIFY body MUST use content indirection 348 [I-D.ietf-sip-content-indirect-mech] for providing the profiles if 349 the Accept header of the SUBSCRIBE included the MIME type: message/ 350 external-body indicating support for content indirection. 352 When delivering profiles via content indirection the profile delivery 353 server MUST include the Content-ID defined in 354 [I-D.ietf-sip-content-indirect-mech] for each profile URL. This is 355 to avoid unnecessary download of the profiles. Some user agents are 356 not able to make a profile effective without rebooting or restarting. 357 Rebooting is probably something to be avoided on a user agent 358 performing services such as telephony. In this way the Content-ID 359 allows the user agent to avoid unnecessary interruption of service as 360 well. The Content-Type MUST be specified for each URI. 362 Initially it is expected that most user agent vendors will use a 363 proprietary content type for the profiles retrieved from the 364 URIs(s). It is hoped that over time a standard content type will 365 be specified that will be adopted by vendors of user agents. One 366 direction that appears to be promising for this content is to use 367 XML with name spaces [??] to segment the data into sets that the 368 user agent implementer may choose to support based upon desired 369 feature set. The specification of the content is out of the scope 370 of this document. 372 Likewise the URL scheme used in the content indirection is outside 373 the scope of this document. This document is agnostic to the URL 374 schemes as the profile content may dictate what is required. It is 375 expected that TFTP [RFC3617], FTP [??], HTTP [RFC2616], HTTPS 376 [RFC2818], LDAP [RFC3377], XCAP [I-D.rosenberg-simple-xcap] and other 377 URL schemes are supported by this package and framework. 379 3.6 Notifier processing of SUBSCRIBE requests 381 The general rules for processing SUBSCRIBE requests [RFC3265] apply 382 to this package. The notifier does not need to authenticate the 383 subscription as the profile content is not transported in the 384 SUBSCRIBE or NOTIFY transaction messages. Only URLs are transported 385 in the NOTIFY request which may be secured using the techniques in 386 section Section 6. 388 The behavior of the profile delivery server is left to the 389 implementer. The profile delivery server may be as simple as a SIP 390 SUBSCRIBE UAS and NOTIFY UAC front end to a simple HTTP server 391 delivering static files that are hand edited. At the other extreme 392 the profile delivery server can be part of a configuration management 393 system that integrates with a corporate directory and IT system or 394 carrier OSS, where the profiles are automatically generated. The 395 design of this framework intentionally provides the flexibility of 396 implementation from simple/cheap to complex/expensive. 398 If the user or device is not known to the profile delivery server, 399 the implementer MAY accept the subscription or reject it. It is 400 recommended that the implementer accept the subscription. It is 401 useful for the profile delivery server to maintain the subscription 402 as an administrator may add the user or device to the system, 403 defining the profile contents. This allows the profile delivery 404 server to immediately send a NOTIFY request with the profile URIs. 405 If the profile delivery server does not accept the subscription from 406 an unknown user or device, the administer or user must manually 407 provoke the user agent to reSUBSCRIBE. This may be difficult if the 408 user agent and administrator are at different sites. 410 3.7 Notifier generation of NOTIFY requests 412 As in [RFC3265], the profile delivery server MUST always send a 413 NOTIFY request upon accepting a subscription. If the device or user 414 is unknown to the profile delivery server and it chooses to accept 415 the subscription, the implementer has two choices. A NOTIFY MAY be 416 sent with no body or content indirection containing the profile 417 URI(s). Alternatively a NOTIFY MAY be sent with URI(s) pointing to a 418 default data set. Typically this data set allows for only limited 419 functionality of the user agent (e.g. a phone user agent with data to 420 call help desk and emergency services.). This is an implementation 421 and business policy decision. 423 A user or device known and fully provisioned on the profile delivery 424 server SHOULD send a NOTIFY with profile data or content indirection 425 containing URIs for all of the profiles associated with the user or 426 device (i.e. which ever specified in the profile-name parameter). 427 The device may be associated with a default user. The URI(s) for 428 this default user profiles MAY be included with the URI(s) of the 429 device if the profile type specified is device. 431 A user agent can provide Hoteling by collecting a user�s AOR and 432 credentials needed to SUBSCRIBE and retrieve the user profiles from 433 the URI(s). Hoteling functionality is achieved by subscribing to the 434 AOR and specifying the "user" profile type. This same mechanism can 435 be used to secure a user agent, requiring a user to login to enable 436 functionality beyond the default user�s restricted functionality. 438 The profile delivery server MAY specify when the new profiles MUST be 439 made effective by the user agent. By default the user agent makes 440 the profiles effective as soon as it thinks that it is non-obtrusive. 441 However the profile delivery server MAY specify a maximum time in 442 seconds (zero or more), in the effective-by event header parameter, 443 by which the user agent MUST make the new profiles effective. 445 3.8 Subscriber processing of NOTIFY requests 447 The user agent subscribing to this event package MUST adhere to the 448 NOTIFY request processing behavior specified in [RFC3265]. The user 449 agent MUST make the profiles effective as specified in the NOTIFY 450 request (see section Section 3.7). The user agent SHOULD use one of 451 the techniques specified in section [RFC3265] to securely retrieve 452 the profiles. 454 3.9 Handling of forked requests 456 This event package allows the creation of only one dialog as a result 457 of an initial SUBSCRIBE request. The techniques to achieve this are 458 described in section 4.4.9 of [RFC3265]. 460 3.10 Rate of notifications 462 It is anticipated that the rate of change for user and device 463 profiles will be very infrequent (i.e. days or weeks apart). For 464 this reason no throttling or minimum period between NOTIFY requests 465 is specified for this package. 467 3.11 State Agents 469 State agents are not applicable to this event package. 471 3.12 Examples 473 SUBSCRIBE sip:00df1e004cd0@example.com SIP/2.0 474 Event: sip-profile;profile-name=device;vendor=acme; 475 model=Z100;version=1.2.3 476 From: sip:00df1e004cd0@acme.com;tag=1234 477 To: sip:00df1e004cd0@acme.com;tag=abcd 478 Call-ID: 3573853342923422@10.1.1.44 479 CSeq: 2131 SUBSCRIBE 480 Contact: sip:00df1e004cd0@10.1.1.44 481 Content-Length: 0 483 NOTIFY sip:00df1e004cd0@10.1.1.44 SIP/2.0 484 Event: sip-profile;effective-by=3600 485 From: sip:00df1e004cd0@acme.com;tag=abcd 486 To: sip:00df1e004cd0@acme.com;tag=1234 487 Call-ID: 3573853342923422@10.1.1.44 488 CSeq: 321 NOTIFY 489 MIME-Version: 1.0 490 Content-Type: multipart/mixed; boundary=boundary42 491 Content-Length: ... 493 --boundary42 494 Content-Type: message/external-body; 495 access-type="URL"; 496 expiration="Mon, 24 June 2002 09:00:00 GMT"; 497 URL="http://www.example.com/devices/fsmith"; 498 size=2222 500 Content-Type: application/z100-user-profile 501 Content-ID: <69ADF2E92@example.com> 503 --boundary42 504 Content-Type: message/external-body; 505 access-type="URL"; 506 expiration="Mon, 24 June 2002 09:00:00 GMT"; 507 URL="http://www.example.com/devices/ff00000036c5"; 508 size=1234 510 Content-Type: application/z100-device-profile 511 Content-ID: <39EHF78SA@example.com> 513 --boundary42-- 515 3.13 Use of URIs to Retrieve State 517 The profile type specified determines what goes in the user part of 518 the SUBSRIBE URI. If the profile type requested is "device", the 519 user part of the URI is an identity that MUST be unique across all 520 user agents from all vendors. This identity must be static over time 521 so that the profile delivery server can keep a specific device and 522 its identity associated with its profiles. For Ethernet hardware 523 type user agents supporting only a single user at a time this is most 524 easily accomplished using its MAC address. Software based user 525 agents running on general purpose hardware may also be able to use 526 the MAC address for identity. However in situations where multiple 527 instances of user agents are running on the same hardware it may be 528 necessary to use a another scheme, such as using a unique serial 529 number for each software user agent instance. 530 For example a device having a MAC address of 00df1e004cd0 might 531 subscribe to the device profile URI: 532 sip:00df1e004cd0@sipuaconfig.example.com. When subscribing to a 533 user profile for user Fred S. the user agent would subscribe to 534 the URI: sip:freds@sipuaconfig.example.com 536 If the profile type request is "user" the URI in the SUBSCRIBE 537 request is the address of record for the user. This allows the user 538 to specify (e.g. login) to the user agent by simply entering their 539 known identity. 541 4. Profile Delivery Framework Details 543 The following describes how different functional steps of the profile 544 delivery framework work. Also described here is how the event 545 package defined in this document provides the enrollment and 546 notification functions within the framework. 548 4.1 Discovery of Subscription URI 550 The discovery function is needed to bootstrap user agents to the 551 point of knowing where to enroll with the profile delivery server. 553 Section Section 3.13 describes how to form the URI used to sent the 554 SUBSCRIBE request for enrollment. However the bootstrapping problem 555 for the user agent (out of the box) is what to use for the host and 556 port in the URI. Due to the wide variation of environments in which 557 the enrolling user agent may reside (e.g. behind residential router, 558 enterprise LAN, ISP, dialup modem) and the limited control that the 559 administrator of the profile delivery server (e.g. enterprise, 560 service provider) may have over that environment, no single discovery 561 mechanism works everywhere. Therefore a number of mechanisms SHOULD 562 be tried in the specified order: SIP DHCP option [RFC3361], SIP DNS 563 SRV [RFC3263], DNS A record and manual. 565 1. The first discovery mechanism that SHOULD be tried is to 566 construct the SUBSCRIBE URI as described in Section 3.13 using 567 the host and port of out bound proxy discovered by the SIP DHCP 568 option as described in [RFC3361]. If the SIP DHCP option is not 569 provided in the DHCP response, no SIP response or a SIP failure 570 response other than for authorization is received for the 571 SUBSCRIBE request to the sip-profile event, the next discovery 572 mechanism SHOULD be tried. 573 2. The local IP network domain for the user agent, either configured 574 or discovered via DHCP, should be used with the technique in 575 [RFC3263] to obtain a host and port to use in the SUBSCRIBE URI. 576 If no SIP response or a SIP failure response other than for 577 authorization is received for the SUBSCRIBE request to the 578 sip-profile event, the next discovery mechanism SHOULD be tried. 579 3. The fully qualified host name constructed using the host name 580 "sipuaconfig" and concatenated with the local IP network domain 581 should be tried next using the technique in [RFC3263] to obtain a 582 host and port to use in the SUBSCRIBE URI. If no SIP response or 583 a SIP failure response other than for authorization is received 584 for the SUBSCRIBE request to the sip-profile event, the next 585 discovery mechanism SHOULD be tried. 586 4. If all other discovery techniques fail, the user agent MUST 587 provide a manual means for the user to enter the host and port 588 used to construct the SUBSCRIBE URI. 590 Once a user agent has successfully discovered, enrolled, received a 591 NOTIFY response with profile data or URI(s), the user agent SHOULD 592 cache the SUBCRIBE URI to avoid having to rediscover the profile 593 delivery server again in the future. The user agent SHOULD NOT cache 594 the SUBSCRIBE URI until it receives a NOTIFY with profile data or 595 URI(s). The reason for this is that a profile delivery server may 596 send 202 responses to SUBSCRIBE requests and NOTIFY responses to 597 unknown user agent (see section Section 3.6) with no URIs. Until the 598 profile delivery server has sent a NOTIFY request with profile data 599 or URI(s), it has not agreed to provide profiles. 601 To illustrate why the user agent should not cache the SUBSCRIBE 602 URI until profile URI(s) are provided in the NOTIFY, consider the 603 following example: a user agent running on a laptop plugged into 604 a visited LAN in which a foreign profile delivery server is 605 discovered. The profile delivery server never provides profile 606 URIs in the NOTIFY request as it is not provisioned to accept the 607 user agent. The user then takes the laptop to their enterprise 608 LAN. If the user agent cached the SUBSCRIBE URI from the visited 609 LAN (which did not provide profiles), the user agent would not 610 attempt to discover the profile delivery server in the enterprise 611 LAN which is provisioned to provide profiles to the user agent.. 613 4.2 Enrollment with Profile Server 615 Enrollment is accomplished by subscribing to the event package 616 described in section Section 3. The enrollment process is useful to 617 the profile delivery server as it makes the server aware of user 618 agent to which it may delivery profiles (those user agents the 619 profile delivery server is provisioned to provide profiles to; those 620 present that the server may be provide profiles in the future; and 621 those that the server can automatically provide default profiles). 622 It is an implementation choice and business policy as to whether the 623 profile delivery server provides profiles to user agents that it is 624 not provisioned to do so. However the profile server SHOULD accept 625 (with 2xx response) SUBSCRIBE requests from any user agent. 627 4.3 Notification of Profile Changes 629 The NOTIFY request in the sip-profile event package serves two 630 purposes. First it provides the user agent with a means to obtain 631 the profile data or URI(s) for desired profiles without requiring the 632 end user to manually enter them. It also provides the means for the 633 profile delivery server to notify the user agent that the content of 634 the profiles have changed and should be made effective. 636 4.4 Retrieval of Profile Data 638 The user agent retrieves it's needed profile(s) via the URI(s) 639 provide in the NOTIFY request as specified in section Section 3.5. 640 The profile delivery server SHOULD secure the content of the profiles 641 using one of the techniques described in Section 6. The user agent 642 SHOULD make the new profiles effective in the timeframe described in 643 section Section 3.2. 645 The contents of the profiles SHOULD be cached by the user agent. 646 This it to avoid the situation where the content delivery server is 647 not available, leaving the user agent non-functional. 649 4.5 Upload of Profile Changes 651 The user agent or other service MAY push changes up to the profile 652 delivery server using the technique appropriate to the profile's URL 653 scheme (e.g. HTTP PUT method, FTP put command). The technique for 654 pushing incremental or atomic changes MUST be described by the 655 specific profile data framework. 657 5. IANA Considerations 659 There are several IANA considerations associated with this 660 specification. 662 5.1 SIP Event Package 664 This specification registers a new event package as defined in 665 [RFC3265]. The following information required for this registration: 666 Package Name: sip-profile 667 Package or Template-Package: This is a package 668 Published Document: RFC XXXX (Note to RFC Editor: Please fill in 669 XXXX with the RFC number of this specification). 670 Person to Contact: Daniel Petrie dpetrie@pingtel.com 671 New event header parameters: profile-name, vendor, model, version, 672 effective-by 674 6. Security Considerations 676 Profiles may contain sensitive data such as user credentials. The 677 protection of this data depends upon how the data is delivered. If 678 the data is delivered in the NOTIFY body, SIP authentication MUST be 679 used for SUBSRIPTION and SIPS and/or S/MIME MAY be use to encrypt the 680 data. If the data is provided via content indirection, SIP 681 authentication is not necessary for the SUBSCRIBE request. With 682 content indirection the data is protected via the authentication, 683 authorization and encryption mechanisms provided by the profile URL 684 scheme. Use of the URL scheme security mechanisms via content 685 indirection simplifies the security solution as the SIP event package 686 does not need to authenticate, authorize or protect the contents of 687 the SIP messages. Effectively the profile delivery server will 688 provide profile URI(s) to anyone. The URLs themselves are protected 689 via authentication, authorization and snooping (e.g. via HTTPS). 691 6.1 Symmetric Encryption of Profile Data 693 If the URL scheme used for content indirection does not provide a an 694 authentication, authorization or encryption, a technique to provide 695 this is to encrypted the profiles on the content delivery server 696 using a symmetric encryption algorithm using a shared key. The 697 encrypted profiles are delivered by the content delivery server via 698 the URIs provided in the NOTIFY requests. Using this technique the 699 profile delivery server does not need to provide authentication or 700 authorization for the retrieval as the profiles are obscured. The 701 user agent must obtain the username and password from the user or 702 other out of band means to generate the key and decrypt the profiles. 704 7. Differences from Simple XCAP Package 706 The author of this document had an action item from the July 2003 707 IETF SIPPING WG meeting to consider resolving the differences of the 708 sip-profile and simple XCAP package [I-D.ietf-simple-xcap-package]. 709 It is the author's opinion that XCAP [I-D.rosenberg-simple-xcap] can 710 be supported by the framework and event package defined in this 711 document and that this package provides a superset of the 712 functionality in the XCAP package. The following lists the 713 differences between the event packaged defined in this document vs. 714 the one defined in [I-D.ietf-simple-xcap-package]. 716 The simple XCAP package requires that the relative path be known and 717 specified by the user agent when subscribing for change notification. 718 The event package in this document requires a token or complete URI 719 be known and specified when subscribing. The advantage of the token 720 is that bootstrapping is easier and well defined. It also leaves the 721 freedom of specifying and changing the entire path of the profile URL 722 up to the profile delivery server. 724 The event package defined in this document allows multiple URIs to be 725 provided in the NOTIFY request body as a result of a single token 726 specified in the SUBSCRIBE event parameter: profile-name. This 727 allows the profile delivery server to provide sets of profiles that 728 the user agent may not have enough information to specify in the 729 SUBSCRIBE URI (e.g. at boot strapping time the user agent may not 730 know the user's identity, but the profile delivery server may know 731 the default user for the device's identity) or the doc-component of 732 the simple XCAP package. 734 All other functional differences between 735 draft-ietf-sipping-config-framework-00 and 736 draft-ietf-simple-xcap-package-00 are believed to be resolved in this 737 version of this document. 739 8. Open Issues 741 9. Change History 742 9.1 Changes from draft-ietf-sipping-config-framework-01.txt 744 Changed the name of the profile-type event parameter to profile-name. 745 Also allow the profile-name parameter to be either a token or or an 746 explicit URI. 748 Allow content indirection to be optional. Clarified the use of the 749 Accept header to indicate how the profile is to be delivered. 751 Added some content to the Iana section. 753 9.2 Changes from draft-ietf-sipping-config-framework-00.txt 755 This version of the document was entirely restructured and re-written 756 from the previous version as it had been micro edited too much. 758 All of the aspects of defining the event package are now organized in 759 one section and is believed to be complete and up to date with 760 [RFC3265]. 762 The URI used to subscribe to the event package is now either the user 763 or device address or record. 765 The user agent information (vendor, model, MAC and serial number) are 766 now provided as event header parameters. 768 Added a mechanism to force profile changes to be make effective by 769 the user agent in a specified maximum period of time. 771 Changed the name of the event package from sip-config to sip-profile 773 Three high level securityapproaches are now specified. 775 9.3 Changes from draft-petrie-sipping-config-framework-00.txt 777 Changed name to reflect SIPPING work group item 779 Synchronized with changes to SIP DHCP [RFC3361], SIP [RFC3261] and 780 [RFC3263], SIP Events [RFC3265] and content indirection 781 [I-D.ietf-sip-content-indirect-mech] 783 Moved the device identity parameters from the From field parameters 784 to User-Agent header parameters. 786 Many thanks to Rich Schaaf of Pingtel, Cullen Jennings of Cisco and 787 Adam Roach of Dyamicsoft for the great comments and input. 789 9.4 Changes from draft-petrie-sip-config-framework-01.txt 791 Changed the name as this belongs in the SIPPING work group. 793 Minor edits 795 9.5 Changes from draft-petrie-sip-config-framework-00.txt 797 Many thanks to those who contributed and commented on the previous 798 draft. Detailed comments were provided by Jonathan Rosenberg from 799 Dynamicsoft, Henning Schulzrinne from Columbia U., Cullen Jennings 800 from Cisco, Rohan Mahy from Cisco, Rich Schaaf from Pingtel. 802 Split the enrollment into a single SUBSCRIBE dialog for each profile. 803 The 00 draft sent a single SUBSCRIBE listing all of the desired. 804 These have been split so that each enrollment can be routed 805 differently. As there is a concept of device specific and 807 user specific profiles, these may also be managed on separate 808 servers. For instance in a roaming situation the device might get 809 it's profile data from a local server which knows the LAN specific 810 profile data. At the same time the user specific profiles might come 811 from the user's home environment profile delivery server. 813 Removed the Config-Expires header as it is largely superfluous with 814 the SUBSCRIBE Expires header. 816 Eliminated some of the complexity in the discovery mechanism. 818 Suggest caching information discovered about a profile delivery 819 server to avoid an avalanche problem when a whole building full of 820 devices powers up. 822 Added the User-Profile From header field parameter so that the device 823 can a request a user specific profile for a user that is different 824 from the device's default user. 826 References 828 [I-D.ietf-simple-xcap-package] 829 Rosenberg, J., "A Session Initiation Protocol (SIP) Event 830 Package for Modification Events for the Extensible Markup 831 Language (XML) Configuration Access Protocol (XCAP) 832 Managed Documents", draft-ietf-simple-xcap-package-00 833 (work in progress), June 2003. 835 [I-D.ietf-sip-content-indirect-mech] 836 Olson, S., "A Mechanism for Content Indirection in Session 837 Initiation Protocol (SIP) Messages", 838 draft-ietf-sip-content-indirect-mech-03 (work in 839 progress), June 2003. 841 [I-D.ietf-sipping-ua-prof-framewk-reqs] 842 Petrie, D. and C. Jennings, "Requirements for SIP User 843 Agent Profile Delivery Framework", 844 draft-ietf-sipping-ua-prof-framewk-reqs-00 (work in 845 progress), March 2003. 847 [I-D.rosenberg-simple-xcap] 848 Rosenberg, J., "The Extensible Markup Language (XML) 849 Configuration Access Protocol (XCAP)", 850 draft-rosenberg-simple-xcap-00 (work in progress), May 851 2003. 853 [I-D.sinnreich-sipdev-req] 854 Butcher, I., Lass, S., Petrie, D., Sinnreich, H. and C. 855 Stredicke, "SIP Telephony Device Requirements, 856 Configuration and Data", draft-sinnreich-sipdev-req-03 857 (work in progress), February 2004. 859 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 860 text messages", STD 11, RFC 822, August 1982. 862 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 863 Requirement Levels", BCP 14, RFC 2119, March 1997. 865 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 866 2131, March 1997. 868 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 869 Extensions", RFC 2132, March 1997. 871 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 872 RFC 2246, January 1999. 874 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 875 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 876 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 878 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 879 Leach, P., Luotonen, A. and L. Stewart, "HTTP 880 Authentication: Basic and Digest Access Authentication", 881 RFC 2617, June 1999. 883 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 885 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 886 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 887 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 889 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 890 Protocol (SIP): Locating SIP Servers", RFC 3263, June 891 2002. 893 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 894 Event Notification", RFC 3265, June 2002. 896 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 897 (DHCP-for-IPv4) Option for Session Initiation Protocol 898 (SIP) Servers", RFC 3361, August 2002. 900 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 901 Protocol (v3): Technical Specification", RFC 3377, 902 September 2002. 904 [RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and 905 Applicability Statement for the Trivial File Transfer 906 Protocol (TFTP)", RFC 3617, October 2003. 908 Author's Address 910 Daniel Petrie 911 Pingtel Corp. 912 400 W. Cummings Park 913 Suite 2200 914 Woburn, MA 01801 915 US 917 Phone: "Dan Petrie (+1 781 938 5306)" 918 EMail: dpetrie@pingtel.com 919 URI: http://www.pingtel.com/ 921 Appendix A. Acknowledgments 922 Intellectual Property Statement 924 The IETF takes no position regarding the validity or scope of any 925 intellectual property or other rights that might be claimed to 926 pertain to the implementation or use of the technology described in 927 this document or the extent to which any license under such rights 928 might or might not be available; neither does it represent that it 929 has made any effort to identify any such rights. Information on the 930 IETF's procedures with respect to rights in standards-track and 931 standards-related documentation can be found in BCP-11. Copies of 932 claims of rights made available for publication and any assurances of 933 licenses to be made available, or the result of an attempt made to 934 obtain a general license or permission for the use of such 935 proprietary rights by implementors or users of this specification can 936 be obtained from the IETF Secretariat. 938 The IETF invites any interested party to bring to its attention any 939 copyrights, patents or patent applications, or other proprietary 940 rights which may cover technology that may be required to practice 941 this standard. Please address the information to the IETF Executive 942 Director. 944 The IETF has been notified of intellectual property rights claimed in 945 regard to some or all of the specification contained in this 946 document. For more information consult the online list of claimed 947 rights. 949 Full Copyright Statement 951 Copyright (C) The Internet Society (2004). All Rights Reserved. 953 This document and translations of it may be copied and furnished to 954 others, and derivative works that comment on or otherwise explain it 955 or assist in its implementation may be prepared, copied, published 956 and distributed, in whole or in part, without restriction of any 957 kind, provided that the above copyright notice and this paragraph are 958 included on all such copies and derivative works. However, this 959 document itself may not be modified in any way, such as by removing 960 the copyright notice or references to the Internet Society or other 961 Internet organizations, except as needed for the purpose of 962 developing Internet standards in which case the procedures for 963 copyrights defined in the Internet Standards process must be 964 followed, or as required to translate it into languages other than 965 English. 967 The limited permissions granted above are perpetual and will not be 968 revoked by the Internet Society or its successors or assignees. 970 This document and the information contained herein is provided on an 971 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 972 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 973 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 974 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 975 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 977 Acknowledgment 979 Funding for the RFC Editor function is currently provided by the 980 Internet Society.