idnits 2.17.1 draft-petrie-sip-config-framework-01.txt: -(929): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(959): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 39 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 SUBSCRIBE request is used by the UA to enroll in the configuration domain of the configuration server. It uniquely identifies the UA with vendor, model and serial number information. The UA also MUST specify its capabilities for configuration retrieval. The UA MUST include the Config-Allow header field which MUST contain at least one token. The configuration server SHOULD not send an error if it is temporarily not able to provide the configuration data profile listed in the SUBSCRIBE request Event header field. In the first time out of the box case, the SUBSCIRBE dialog may be the only means of communicating with the device as it does not yet have configuration. The configuration server SHOULD send a 403 response to the SUBSCRIBE if is not willing to provide the requested configuration profile to the device. The configuration server SHOULD provide the configuration data profile that it is able to or desires (see example at the end of section 4.3) to deliver to the UA. If the configuration server sends a 301 Moved Permanently response to the enrollment SUBSCRIBE, the UA SHOULD cache the URL contained in the response Contact header field in place of the address and port found during discovery for future enrollment. == 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 Vendor, Model, Version, Serial and Mac parameters MUST be provided in the From URL for the enrollment SUBSCRIBE request. Most profiles will either be device or user specific. If the profile is user specific and the device knows the user for which it is to retrieve, the profile UserProfile MUST be provided. If the profile is device specific or the device does not know whose user profile it should retrieve, the device SHOULD not provide the UserProfile parameter. The profile is user specific and UserProfile is not present the configuration server assumes the default user for the device. == 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 UA MUST retrieve its configuration data profile using the URL specified by the configuration server in the NOTIFY request. If the retrieval fails, the UA SHOULD not re-enroll until the SUBSCRIBE session expires to avoid a cascade effect if the server goes down temporarily. The device MAY re-try the profile retrieve of the profile from the URL before the SUBSCRIBE expires. Should the re-enrollment fail, the UA SHOULD re-discover the configuration server as described in section 4. == 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: If the UA or another entity wishes to modify a configuration data profile it MAY make the change persistent on the configuration server if it is authorized to do so. The configuration server SHOULD support the ability to upload via the same URL the UA used to retrieve the configuration data profile. For TFTP the UA does a put [9]. For HTTP and HTTPS the UA does a POST with a multipart MIME attachment containing any URL parameters in one part and the changed configuration data profile [whole or changes only ?? define in profiles ??] in another part as defined in [?]. If the UA or user is not permitted to make the changes on the configuration server the configuration server returns an HTTP error response code of 403 Forbidden. If the configuration server returns a 403 the UA SHOULD disallow the changes from being effective on the UA. The UA SHOULD not make the changes effective until it receives a successful response (e.g. for HTTP 2xx). == 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: SHOULD use the configuration data profile contents from the HTTP response as opposed to the data that was pushed in the request as changes may occur from other sources. The configuration server SHOULD send out a NOTIFY for this change, using the same sequence number in the configuration data profile URL parameter. This allows the UA to know that it already has the current contents of the configuration data profile and SHOULD not download that configuration data profile. [TBD � in 403 case restrict and provide feedback as to what specifically is not allowed to be modified by the UA or user] -- 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 (November 2001) is 8199 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: '2' is defined on line 913, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 920, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 924, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 950, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2543 (ref. '6') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 822 (ref. '8') (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 1738 (ref. '12') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 2818 (ref. '13') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2246 (ref. '14') (Obsoleted by RFC 4346) Summary: 8 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 D. Petrie 3 Internet Draft Pingtel Corp. 4 draft-petrie-sip-config-framework-01.txt 5 Expires: May 2002 November 2001 7 A Framework for SIP User Agent Configuration 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with 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 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://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 Abstract 31 This document defines the application of a set of protocols for 32 configuring a SIP user agent. The SIP user agent must discover how 33 and from where to retrieve its initial configuration and be notified 34 of changes and updates which impact its configuration. The 35 objective is to define a means for automatically configuring a user 36 agent such that it can be functional without user or administrative 37 intervention. The framework for discovery, delivery, notification 38 and updates of user agent configuration is defined here. This 39 framework is also intended to ease ongoing administration, 40 configuration and upgrading of large scale deployments of SIP user 41 agents. The contents and format of the configuration data to be 42 defined is outside the scope of this document. 44 A Framework for SIP November 2001 45 User Agent Configuration 47 Table of Contents 49 Status of this Memo................................................1 50 Abstract...........................................................1 51 1 Overview.......................................................3 52 2 Conventions used in this document..............................4 53 3 Changes from Previous Draft....................................4 54 4 Discovery......................................................4 55 4.1 DHCP Option..................................................6 56 4.2 DNS..........................................................6 57 4.3 Multicast....................................................6 58 4.4 Manually Provisioned.........................................6 59 5 Enrollment and Change Notification.............................6 60 5.1 Header Field Definitions.....................................7 61 5.1.1 Config-Allow................................................7 62 5.2 SUBSCRIBE....................................................8 63 5.2.1 Additional From Field Parameters............................8 64 5.3 NOTIFY.......................................................9 65 5.3.1 NOTIFY Body Content Format.................................10 66 6 Configuration Retrieval.......................................11 67 7 Configuration Upload..........................................11 68 8 Examples......................................................12 69 8.1 Example Message Flows.......................................12 70 8.2 Example Messages............................................14 71 9 Security Considerations.......................................17 72 10 Open Issues...................................................18 73 11 References....................................................19 74 12 Author's Addresses............................................20 75 A Framework for SIP November 2001 76 User Agent Configuration 78 1 Overview 80 Today all SIP UA vendors use proprietary means of delivering 81 configuration to the UA. This configuration framework is intended 82 to enable a first phase migration to a standard means of configuring 83 SIP user agents. It is expected that UA vendors should be able to 84 use this configuration framework as a means of delivering their 85 existing proprietary configuration data profiles (i.e. using their 86 existing proprietary binary or text formats). This in itself is a 87 tremendous advantage in that a SIP environment can use a single 88 configuration server to deliver configuration data to UAs from 89 multiple vendors. Follow-on standardization activities can: 1) 90 define a standard format (e.g. XML or name-value pairs [8]) and 2) 91 specify the content (i.e. name the configuration parameters) of the 92 configuration data profiles. 94 This document defines a framework which allows SIP user agents (UA) 95 to automatically: 96 - discover a configuration server (Discovery) 97 - enroll with the configuration server (Enrollment) 98 - retrieve configuration data (Configuration Retrieval) 99 - receive notification of configuration changes (Change 100 Notification) 101 - upload configuration data changes back up to the server 102 (Configuration Upload) 104 The content and format of the data is not defined in this document. 105 It is to be defined in configuration data profile(s) in other 106 document(s). The goal of this framework is to satisfy the 107 requirements defined in [10] and [11] excluding the requirements 108 which pertain to configuration data profile content and format. 110 Discovery is the process by which a UA SHOULD find the address and 111 port at which it SHOULD enroll with the configuration server. As 112 there is no single discovery mechanism which will work in all 113 network environments, a number of discovery mechanisms are defined 114 with a prescribed order in which the UA SHOULD try them until one 115 succeeds. 117 Enrollment is the process by which a UA SHOULD make itself known to 118 the configuration server. In enrolling the UA MUST provide identity 119 information, name requested configuration data profile and supported 120 protocols for configuration retrieval. It SHOULD also SUBSCRIBE to 121 a mechanism for notification of configuration changes. As a result 122 of enrollment the UA receives a URL for each of the configuration 123 data profiles that the configuration server is able to provide. 124 Each profile requires a separate enrollment or SUBSCRIBE session. 126 Configuration Retrieval is the process of retrieving the content for 127 each of the configuration data profiles the UA requested. 129 Change Notification is the process by which the configuration server 130 notifies the UA that the content of one or more of the configuration 131 A Framework for SIP November 2001 132 User Agent Configuration 134 data profiles has changed. Subsequently the UA SHOULD retrieve the 135 data profile from the specified URL upon receipt of the change 136 notification. 138 Configuration Upload is the process by which a UA or other entity 139 pushes a change to a configuration data profile back up to the 140 configuration server. 142 2 Conventions used in this document 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 146 this document are to be interpreted as described in RFC-2119 [1]. 148 The syntax and semantics used here extend those defined in SIP (RFC 149 2543) [6]. SIP is described in an augmented Backus-Naur form (ABNF). 150 See [6, section C] for an overview of ABNF. 152 3 Changes from Previous Draft 154 Many thanks to those who contributed and commented on the previous 155 draft. Detailed comments were provided by Henning Schulzrinne from 156 Columbia U., Cullen Jennings from Cisco, Rohan Mahy from Cisco. 158 Split the enrollment into a single SUBSCRIBE dialog for each 159 profile. The 00 draft sent a single SUBSCRIBE for listing all of 160 the desired. These have been split so that each enrollment can be 161 routed differently. As there is a concept of device specific and 162 user specific profiles, these may also be managed on separate 163 servers. For instance in a roaming situation the device might get 164 it�s configuration from a local server which knows the LAN specific 165 configuration. At the same time the user specific profiles might 166 come from the user�s home environment configuration server.' 168 Removed the Config-Expires header as it is largely superfluous with 169 the SUBSCRIBE Expires header. 171 Eliminated some of the discovery nonsense. 173 Suggest caching of discovered configuration server to avoid 174 avalanche problem when a whole building full of devices powers up. 176 Added the User-Profile From header field parameter so that the 177 device can indicate the request for a user specific profile 178 different than the device�s default user. 180 4 Discovery 182 The purpose of discovery is to figure out how to address the 183 configuration server so that the device can enroll. The enrollment 184 process involves sending a SIP SUBSCRIBE. Prior to this the 185 discovery process must find the address to use in the URL for the 186 URI and To header field. The URL SHOULD use the user id: 188 A Framework for SIP November 2001 189 User Agent Configuration 191 sipuaconfig. From a SIP perspective the configuration server is 192 simply a user agent. By using a well known user id, this makes it 193 easy for proxy servers to be provisioned to route the enrollment 194 requests from devices to the appropriate configuration server for 195 the domain. 197 The first time a UA is plugged in it does not know the address or 198 port at which to enroll with the local configuration server. It 199 must discover this address and port. A UA SHOULD support all of the 200 listed discovery mechanisms. It MUST support at least one of them. 201 Once the UA has discovered the address and port and has successfully 202 enrolled with the configuration server, the UA SHOULD cache the 203 address and port to avoid the need to re-discover the configuration 204 server. However if enrollment, configuration retrieval or 205 configuration upload fails at any time, the UA SHOULD apply the 206 discovery and enrollment process again. This provides a means for 207 configuration server fail over and load balancing. 208 The UA SHOULD use the following mechanisms to discover the host 209 address and port at which it SHOULD enroll with the configuration 210 server. Each mechanism should be tried in the following order until 211 an address and port is provided which results in successful 212 enrollment (i.e. the server responds with a successful 2xx class 213 response): 214 - DHCP option for SIP [1] 215 - DNS A record 216 - Multicast 217 - Manual provisioning 219 The rationale for this order follows. Assuming that most UAs are 220 going to use DHCP for IP configuration anyway, using a DHCP option 221 is the least costly in terms of lookup time (i.e. no additional 222 messages are required). Hence DHCP is first. Multicast is used 223 last of the automated discovery mechanisms as it is the most 224 restricted in terms of network environments that support it. 225 Multicast is included, even though the applicable environments are 226 restricted, as it is the only mechanism that can be used without the 227 support of the local network administrator. 229 The phone administrator and the network administrator are often 230 different people and perhaps in different departments. 232 The UA implementer MAY provide the user or administrator with the 233 means to change the order in which these mechanisms are tried. This 234 includes the ability to manually override the discovery process. 235 However by default without user interaction it SHOULD use the order 236 listed above. 238 Once discovery is successful the device SHOULD persistently cache 239 the address to avoid avalanche problems when a whole building full 240 of devices powers up at once. The characteristic of the profile may 241 dictate this behavior. For example device specific profiles may 242 need to change when the device is moved to a different location. 244 A Framework for SIP November 2001 245 User Agent Configuration 247 User specific profiles may be independent of the LAN, network or 248 device location. 250 4.1 DHCP Option 252 It is likely that most UAs in an environment of any significant 253 number will use DHCP for IP configuration. DHCP becomes a 254 convenient means to discover the configuration server address. In 255 the same DHCP request for basic IP configuration, the UA can add the 256 option for SIP[3] [1] to the options field. This indicates a 257 request for the default SIP proxy server address and port. For 258 example if the DHCP option for SIP returns an address of 259 sip.acme.com and a port of 5080, the following URL is constructed: 260 sip:sipuaconfig@sip.acme.com:5080. If the proxy server address and 261 port is not returned in the DHCP response or the server does not 262 respond to the enrollment request with a successful 2xx class 263 response, the next discovery mechanism is attempted. 265 4.2 DNS 267 The UA SHOULD construct a fully qualified host name using 268 �sipuaconfig� as the host and the local domain if defined. It 269 SHOULD try a DNS A record lookup on the fully qualified host name. 270 If the name resolves in DNS it should then attempt enrollment. For 271 example the URL constructed in the local domain of acme.com would 272 look like: sip:sipuaconfig@sipuaconfig.acme.com. If the server does 273 not respond to enrollment with a successful 2xx class response, the 274 next discovery mechanism is attempted. 276 4.3 Multicast 278 The enrollment request is sent to the multicast address for SIP 279 registration [6] "sip.mcast.net" (224.0.1.75). If a server does not 280 respond with a successful 2xx class response to the enrollment 281 request, the next discovery mechanism is attempted. 283 4.4 Manually Provisioned 285 The UA MAY indicate to the user (or administrator) that automatic 286 discovery has failed. The UA SHOULD allow the user or administrator 287 to manually (perhaps using some other out of band means e.g. beam, 288 smart card, etc.) enter the configuration server address and port to 289 be used for enrollment. 291 5 Enrollment and Change Notification 293 The enrollment and configuration change notification are paired 294 together and provided via the SIP SUBSCRIBE/NOTIFY framework [7]. 295 This document defines the profile on top of the SUBSCRIBE/NOTIFY 296 framework [7] for this purpose. 298 UA enrollment with the configuration server is accomplished via the 299 SUBSCRIBE request. A UA MUST enroll with the configuration server 300 A Framework for SIP November 2001 301 User Agent Configuration 303 prior to retrieving configuration data profiles. As part of the 304 enrollment the UA MUST identify itself, its configuration retrieval 305 protocol capabilities and configuration data profile requirements. 307 The configuration server may use this information to decide how to 308 allocate resources (e.g. load balancing) to support the UA for its 309 specific configuration retrieval needs. The configuration server 310 may also use the UA enrollment event as the trigger to generate a 311 new set of configuration data for the specific UA (e.g. based upon 312 provisioned defaults and configuration profile context knowledge for 313 the environment). This would allow the configuration server to 314 provide configuration data for a new UA without previously 315 provisioning the specific UA on the server. 317 Each profile that the device requires is obtained via a separate 318 enrollment or SUBSCRIBE request and SIP dialog. That is for each 319 different profile a device enrolls for, a different Call-Id is used. 320 The device names the profile in the SUBSCRIBE Event header field. 321 The configuration server then delivers a URL at which the device and 322 retrieve the profile in a subsequent NOTIFY request. Changes to the 323 profile are indicated in additional NOTIFY requests sent from the 324 configuration server. 326 The SUBSCRIBE request for enrollment is sent to the address(es) 327 identified in the discovery process until the first successful 2xx 328 class response is received. As part of the binding of the 329 SUBSCRIBE/NOTIFY framework a new Event token must be named for each 330 type of profile. 332 If enrollment fails (i.e. no 2xx response to SUBSCRIBE), the UA 333 SHOULD re-discover the configuration server address and port as 334 described in section 3. 336 The following new header field is defined for use in SUBSCRIBE and 337 NOTIFY requests for the purpose of enrollment and configuration 338 change notification: 340 The keys used the following table: 341 R � request 342 r � response 343 m � mandatory 344 o � optional 345 - - not applicable 347 Header Where SUBSCRIBE NOTIFY 348 ------ ----- --------- ------ 349 Config-Allow R m - 351 5.1 Header Field Definitions 353 5.1.1 Config-Allow 354 A Framework for SIP November 2001 355 User Agent Configuration 357 The Config-Allow header field is used by the UA in the enrollment 358 request (SUBSCRIBE) to list the protocols that it is capable of 359 using to retrieve configuration data. The configuration server MUST 360 adhere to the protocol capabilities of the UA when providing the URL 361 for the configuration profile in the NOTIFY request. 363 Syntax: 364 Config-Allow = "Config-Allow" ":" config-protocol 365 *(�,� config-protocol) 366 config-protocol = �tftp� | �http� | �https� | token 368 5.2 SUBSCRIBE 370 The SUBSCRIBE request is used by the UA to enroll in the 371 configuration domain of the configuration server. It uniquely 372 identifies the UA with vendor, model and serial number information. 373 The UA also MUST specify its capabilities for configuration 374 retrieval. The UA MUST include the Config-Allow header field which 375 MUST contain at least one token. The configuration server SHOULD 376 not send an error if it is temporarily not able to provide the 377 configuration data profile listed in the SUBSCRIBE request Event 378 header field. In the first time out of the box case, the SUBSCIRBE 379 dialog may be the only means of communicating with the device as it 380 does not yet have configuration. The configuration server SHOULD 381 send a 403 response to the SUBSCRIBE if is not willing to provide 382 the requested configuration profile to the device. The 383 configuration server SHOULD provide the configuration data profile 384 that it is able to or desires (see example at the end of section 385 4.3) to deliver to the UA. If the configuration server sends a 301 386 Moved Permanently response to the enrollment SUBSCRIBE, the UA 387 SHOULD cache the URL contained in the response Contact header field 388 in place of the address and port found during discovery for future 389 enrollment. 391 The device may request many configuration data profiles by 392 sending multiple SUBSCRIBE requests each in a different SIP 393 dialog. This may be useful if the device requires user 394 specific profiles for multiple users. In this case the 395 UserProfile parameter would vary for each SUBSCRIBE. 396 Alternatively the device may require multiple types of profiles 397 where each SUBSCRIBE would have a different Event header field 398 token. 400 The configuration server MAY use the enrollment (SUBSCRIBE request) 401 as the stimulus to generate a new instance of a configuration data 402 profile unique to the UA. Alternately the configuration server MAY 403 be provisioned ahead of time to know about new UAs and their 404 specific configuration data content (for example based upon serial 405 number, MAC address). 407 5.2.1 Additional From Field Parameters 408 A Framework for SIP November 2001 409 User Agent Configuration 411 When the device first starts up out of the box, it has no user or 412 local configuration. The device MUST to provide a unique identity 413 such that it is possible for the configuration server to generate 414 configuration profiled for the device. The following additional 415 From field parameters are defined for the purpose of identifying the 416 UA device: 418 Vendor � a token used to identify the UA vendor name 420 Model � a token used to identify the UA hardware/software model 422 Version � a token used to identify the firmware/software version 423 currently installed on the UA 425 Serial � the token used to identify the serial number for the UA 427 Mac � the token used to identify the MAC address in hex for the UA 429 From RFC 2543 bis [6] the From header field syntax is extended to 430 include: 431 from-param = tag-param | generic-param | device-param 432 device-param = vendor-parm | model-parm | version-parm | 433 serial-parm | mac-parm | user-profile-param 434 vendor-parm = �Vendor� �=� token 435 model-parm = �Model� �=� token 436 version-parm = �Version� �=� token 437 serial-parm = �Serial� �=� token 438 mac-parm = �Mac� �=� token 439 user-profile-param = �UserProfile� �=� SIP-URL 441 The Vendor, Model, Version, Serial and Mac parameters MUST be 442 provided in the From URL for the enrollment SUBSCRIBE request. Most 443 profiles will either be device or user specific. If the profile is 444 user specific and the device knows the user for which it is to 445 retrieve, the profile UserProfile MUST be provided. If the profile 446 is device specific or the device does not know whose user profile it 447 should retrieve, the device SHOULD not provide the UserProfile 448 parameter. The profile is user specific and UserProfile is not 449 present the configuration server assumes the default user for the 450 device. 452 5.3 NOTIFY 454 The NOTIFY message is sent by the configuration server to convey the 455 URL at which the UA can retrieve the requested configuration data 456 profile. This occurs in two contexts: 458 Immediately following the enrollment SUBSCRIBE the configuration 459 server MUST send a NOTIFY providing the URL for the configuration 460 data profile requested by the UA in the Event header field of the 461 SUBSCRIBE request. If the configuration server is not able to 462 provide the specific configuration data profile or it does not 463 want the UA to retrieve the specific configuration profile at that 464 A Framework for SIP November 2001 465 User Agent Configuration 467 point in time, it MAY defer sending NOTIFY. At a later time when 468 the configuration server is able to provide the data profile or it 469 wishes the UA to retrieve the data profile at that point in time, 470 the configuration server MAY send a NOTIFY request containing the 471 URL for the configuration data profile which the UA SHOULD 472 retrieve as soon as it is safe to do so. 474 If the configuration server becomes aware of a configuration 475 change that it wishes to be effective immediately on the UA, the 476 configuration server SHOULD send a NOTIFY message containing the 477 URL for the configuration data profile that the UA requested when 478 it enrolled. The configuration data profile with changed content 479 SHOULD have sequence number larger than that of the last NOTIFY 480 request. The UA SHOULD retrieve and make effective the changed 481 configuration URL immediately upon receipt of the NOTIFY request. 482 The UA MAY choose to wait to make the changes effective (e.g. to 483 prevent the change from disrupting active calls on the UA). 485 [Do we need an option for the configuration server to tell the UA 486 that it MUST make the change immediately regardless of state? 487 Should this be the default?] 489 The UA SHOULD send a 200 response to the NOTIFY immediately upon 490 receipt and validation of the solicited request. The configuration 491 server MUST include, in the change notification NOTIFY request, the 492 configuration data profile URL. The sequence numbers associated 493 with the configuration data profile with changed content should be 494 larger than those in the previous NOTIFY. The URL listed in the 495 NOTIFY request MUST use one of the protocols the UA listed in the 496 Config-Allow header field provided during enrollment in the most 497 recent SUBSCRIBE request. The sequence number for the configuration 498 data profile URL MUST be positive integers chosen by the 499 configuration server. The sequence number value MUST increase 500 monotonically as modifications are made to a data profile. 502 This mechanism may be used by the configuration server to provide 503 firmware updates. For example on a UA that caches or has a 504 persistent firmware image: if the server realizes (e.g. from the 505 enrollment information) the UA is running the most currently 506 available firmware version, it could defer sending the NOTIFY with 507 the URL for the firmware. However at a later point in time when a 508 new firmware version was available the configuration server could 509 send a NOTIFY with the URL for the new firmware version, 510 indicating the UA SHOULD upgrade as soon as it is safe to do so. 512 5.3.1 NOTIFY Body Content Format 514 The NOTIFY request contains a body of Content-Type: text/plain. The 515 content is formatted according to RFC 822 [8]. It contains a header 516 field with the same name as the configuration data profile as 517 indicated in the Event header. The value of the header field MUST 518 contain a URL and a sequence number as described in the syntax 519 below. The protocol of the URL MUST be one of those listed in the 520 A Framework for SIP November 2001 521 User Agent Configuration 523 Config-Allow header field provided by the UA in the enrollment 524 SUBSCRIBE request. The sequence number associated with the URL is 525 intended to allow the UA to decide if it has the latest content of 526 the configuration data profile without having to download and 527 compare the contents. 529 Syntax: 530 config-profile = token �:� Seq-Param �;� Url-Param 531 Seq-Param = �Sequence� �=� 1*digit 532 Url-Param = �Url� �=� tftp-url | Http-url | Https-url 533 Tftp-url [need reference] 534 Http-Url as defined in [12, section 3.3] 535 Https-Url [need reference] 537 Example: 539 X-Acme-Special: Sequence=1234567;Url=http://www.acme.com/config.txt 541 6 Configuration Retrieval 543 The UA MUST retrieve its configuration data profile using the URL 544 specified by the configuration server in the NOTIFY request. If the 545 retrieval fails, the UA SHOULD not re-enroll until the SUBSCRIBE 546 session expires to avoid a cascade effect if the server goes down 547 temporarily. The device MAY re-try the profile retrieve of the 548 profile from the URL before the SUBSCRIBE expires. Should the re- 549 enrollment fail, the UA SHOULD re-discover the configuration server 550 as described in section 4. 552 7 Configuration Upload 554 If the UA or another entity wishes to modify a configuration data 555 profile it MAY make the change persistent on the configuration 556 server if it is authorized to do so. The configuration server 557 SHOULD support the ability to upload via the same URL the UA used to 558 retrieve the configuration data profile. For TFTP the UA does a put 559 [9]. For HTTP and HTTPS the UA does a POST with a multipart MIME 560 attachment containing any URL parameters in one part and the changed 561 configuration data profile [whole or changes only ?? define in 562 profiles ??] in another part as defined in [?]. If the UA or user 563 is not permitted to make the changes on the configuration server the 564 configuration server returns an HTTP error response code of 403 565 Forbidden. If the configuration server returns a 403 the UA SHOULD 566 disallow the changes from being effective on the UA. The UA SHOULD 567 not make the changes effective until it receives a successful 568 response (e.g. for HTTP 2xx). 570 If the URL is for HTTP/HTTPS the server MUST return the changed 571 configuration data profile in the response (assuming it was 572 allowed). The configuration server SHOULD include an incremented 573 sequence number in the HTTP/HTTPS response if the configuration data 574 profile contents changed [Sip-Ua-Config-Seq header field?]. The UA 575 A Framework for SIP November 2001 576 User Agent Configuration 578 SHOULD use the configuration data profile contents from the HTTP 579 response as opposed to the data that was pushed in the request as 580 changes may occur from other sources. The configuration server 581 SHOULD send out a NOTIFY for this change, using the same sequence 582 number in the configuration data profile URL parameter. This allows 583 the UA to know that it already has the current contents of the 584 configuration data profile and SHOULD not download that 585 configuration data profile. 586 [TBD � in 403 case restrict and provide feedback as to what 587 specifically is not allowed to be modified by the UA or user] 589 8 Examples 591 Below is an example high level message flow for a new UA discovering 592 and using configuration data from a configuration server. Following 593 the high level message flows are some specific SIP messages 594 illustrating SUBSCRIBE and NOTIFY messages from enrollment and 595 configuration change notification. 597 8.1 Example Message Flows 599 The following high level message flows illustrate the configuration 600 process of discovery, enrollment, configuration retrieval and change 601 notification with associated configuration retrieval. The UA uses 602 DHCP with the local option requesting the configuration server 603 address and port. The DHCP server does not provide the 604 configuration server address or port. The UA then does a DNS lookup 605 for the configuration service within the local domain. It gets a 606 response from the DNS server for the configuration server fully 607 qualified host name. The UA then enrolls with the configuration by 608 sending a SUBSCRIBE request for the profile type indicated in the 609 Event header. The configuration server sends back a successful 610 response. The configuration server then sends a NOTIFY request with 611 the URL for the configuration data profile that the UA named in the 612 enrollment SUBSCRIBE request. The UA sends a 200 response to the 613 NOTIFY. The UA then downloads the configuration data profile via 614 the URL from the NOTIFY request. This process may be repeated in 615 parallel for each of the required profiles. The UA is now 616 configured as prescribed. 618 Later ... an administrator makes a change to the configuration for 619 the UA on the configuration server. The configuration server on 620 behalf of the administrator, sends a NOTIFY (change notification) 621 request to the UA with an incremented sequence number for the 622 profile. As the sequence number has changed, the UA downloads the 623 configuration data profile from the given URL. 625 UA DHCP Server DNS Server Config. Server 627 Discovery 629 IP config. req. 630 ==============> 631 A Framework for SIP November 2001 632 User Agent Configuration 634 IP config. wo/ local option 635 <============== 636 DNS A record req. for sipuaconfig host in local domain 637 =============================> 638 A record IP address returned for Host 639 <============================= 641 Enrollment 643 SIP SUBSCRIBE Event: Sip-Device 644 ==================================================> 645 200 OK 646 <================================================== 647 SIP NOTIFY Event: Sip-Device w/ requested profile URL 648 <================================================== 649 200 OK 650 ==================================================> 652 Configuration retrieval 654 HTTP GET 655 ==================================================> 656 200 OK (specific profile data in body) 657 <================================================== 658 . 659 . 660 . 662 Administrative change on configuration server via user interface 663 . 664 . 665 . 667 Change Notification 669 SIP NOTIFY Event: Sip-Device w/ changed profile URL 670 <================================================== 671 200 OK 672 ==================================================> 673 HTTP GET 674 ==================================================> 675 200 OK (profile data in body) 676 <================================================== 677 . 678 . 679 . 681 User changes data in a profile on the user agent 682 . 683 . 684 . 686 Configuration Upload 687 A Framework for SIP November 2001 688 User Agent Configuration 690 HTTP POST (changed profile attached as multipart MIME) 691 ==================================================> 692 200 OK (profile data in body, as change confirmation) 693 <================================================== 694 . 695 . 696 . 698 8.2 Example Messages 700 The following SUBSCRIBE request example is from a UA enrolling with 701 a configuration server. As this SUBSCRIBE request is for 702 configuration enrollment the Event header field contains the token 703 Config-Event. The UA tells the configuration server that it 704 supports the TFTP, HTTP, HTTPS protocols for retrieving 705 configuration data profiles in the Config-Allow header field. The 706 UA tells the configuration server that it would like the 707 configuration data profile named: sip-device in the Event header 708 field. The UA tells the configuration server that it is enrolling 709 for 86400 seconds via the Expires header field. During this period 710 of time the configuration server MUST send a change notification 711 with the URL for the configuration data profile which changed. The 712 UA has identified the specifics about itself in the From field 713 parameters: Vendor, Model, Version, Serial, Mac. In this example 714 the UserProfile parameter is not included in the From field as the 715 Sip-Device profile is device specific not user specific. 717 UA => Config. Server 719 SUBSCRIBE sip: sipuaconfig@config.localdomain.com SIP/2.0 720 To: sip:sipuaconfig@config.localdomain.com 721 From: sip:10.1.1.123;Vendor=acme;Model=model-a 722 ;Version=1.5.0.1;Serial=1234567890;Mac=000aaa1234cd 723 Call-Id: 987654321@10.1.1.123 724 Cseq: 1 SUBSCRIBE 725 Event: Sip-Device 726 Config-Allow: tftp, http, https 727 Expires: 86400 728 Content-Length: 0 730 The following is an example response to the above enrollment 731 request. 733 A Framework for SIP November 2001 734 User Agent Configuration 736 Config. Server => UA 738 SIP/2.0 202 Accepted 739 To: sip:config.localdomain.com 740 From: sip:10.1.1.123;Vendor=acme;Model=model-a 741 ;Version=1.5.0.1;Serial=1234567890;Mac=000aaa1234cd 742 Call-Id: 987654321@10.1.1.123 743 Cseq: 1 SUBSCRIBE 744 Content-Length: 0 746 In the following example the device is requesting a user specific 747 profile Sip-User. The device specifies that it want the profile for 748 the user: sip:fredsmith@localdomain.com. 750 UA => Config. Server 752 SUBSCRIBE sip: sipuaconfig@config.localdomain.com SIP/2.0 753 To: sip:sipuaconfig@config.localdomain.com 754 From: sip:10.1.1.123;Vendor=acme;Model=model-a 755 ;Version=1.5.0.1;Serial=1234567890;Mac=000aaa1234cd 756 ;UserProfile=sip%3Afredsmith%40localdomain.com 757 Call-Id: 11111111@10.1.1.123 758 Cseq: 1 SUBSCRIBE 759 Event: Sip-Device 760 Config-Allow: tftp, http, https 761 Expires: 86400 762 Content-Length: 0 764 The following is an example response to the above enrollment 765 request. 767 Config. Server => UA 769 SIP/2.0 202 Accepted 770 To: sip:config.localdomain.com 771 From: sip:10.1.1.123;Vendor=acme;Model=model-a 772 ;Version=1.5.0.1;Serial=1234567890;Mac=000aaa1234cd 773 ;UserProfile=sip%3Afredsmith%40localdomain.com 774 Call-Id: 11111111@10.1.1.123 775 Cseq: 1 SUBSCRIBE 776 Content-Length: 0 778 The following example is the immediate NOTITY request the 779 configuration server sent to the UA following enrollment. The URL 780 in the request body is for the configuration data profile the UA 781 named in the Event header field in the above SUBSCRIBE request from 782 the UA. 784 A Framework for SIP November 2001 785 User Agent Configuration 787 Config. Server => UA 789 NOTIFY sip:10.1.1.123 SIP/2.0 790 To: sip:10.1.1.123;Vendor=acme;Model=model-a 791 ;Version=1.5.0.1;Serial=1234567890;Mac=000aaa1234cd 792 From: sip:config.localdomain.com 793 Call-Id: 987654321@10.1.1.123 794 Cseq: 22 NOTIFY 795 Event: Sip-Device 797 Content-Type: text/plain 798 Content-Length: 79 800 Sip-Device: Sequence=1 801 ;Url=http://config.localdomain.com/device/1234567890 803 The following is an example response from the UA for the above 804 request. 806 UA => Config. Server 808 SIP/2.0 200 Ok 809 To: sip:10.1.1.123;Vendor=acme;Model=model-a 810 ;Version=1.5.0.1;Serial=1234567890;Mac=000aaa1234cd 811 From: sip:config.localdomain.com 812 Call-Id: 987654321@10.1.1.123 813 Cseq: 22 NOTIFY 814 Content-Length: 0 816 Assuming at some later point in time, an administrator makes a 817 change to the content of the Sip-Device configuration data profile 818 for the UA. The configuration server sends a NOTIFY request to the 819 UA for the configuration change notification. This example request 820 below indicates the changed URL or content in the request body with 821 a higher sequence number. 823 Config. Server => UA 825 NOTIFY sip:10.1.1.123 SIP/2.0 826 To: sip:10.1.1.123;Vendor=acme;Model=model-a 827 ;Version=1.5.0.1;Serial=1234567890;Mac=000aaa1234cd 828 From: sip:config.localdomain.com 829 Call-Id: 987654321@10.1.1.123 830 Event: Sip-Device 831 Cseq: 23 NOTIFY 832 Content-Type: text/plain 833 Content-Length: 79 835 Sip-Device: Sequence=2 836 ;Url=http://config.localdomain.com/device/1234567890 837 A Framework for SIP November 2001 838 User Agent Configuration 840 The following is an example response to the above request. 842 UA => Config. Server 844 SIP/2.0 200 Ok 845 To: sip:10.1.1.123;Vendor=acme;Model=model-a 846 ;Version=1.5.0.1;Serial=1234567890;Mac=000aaa1234cd 847 From: sip:config.localdomain.com 848 Call-Id: 987654321@10.1.1.123 849 Cseq: 23 NOTIFY 850 Content-Length: 0 852 9 Security Considerations 854 [This section needs to be greatly expanded and elaborated] 856 SIP basic and digest authentication [6] MAY be used for 857 SUBSCRIBE/NOTIFY messages used for enrollment and configuration 858 change notification. As there is a chicken and egg problem as well 859 and the content of SUBSCRIBE/NOTIFY messages are transported in the 860 clear, the credentials that the UA uses in the SUBSCRIBE 401 861 challenge, or that the configuration server uses in the NOTIFY 401 862 challenge must be provisioned out of band (i.e. user or 863 administrator manual input, beamed via PDA, smart card, etc.) via a 864 secure means. 866 Configuration data profile URLs are communicated in the clear in the 867 NOTIFY requests from the configuration server. The security risk of 868 unauthorized access of the URL content can be mitigated if the 869 configuration server and UA both support basic authentication and 870 HTTP or HTTPS. There is a chicken and egg problem here as well 871 since the content of SUBSCRIBE/NOTIFY messages are transported in 872 the clear. Accordingly,the credentials that the UA uses for the 873 HTTP/HTTPS GET/POST 401 challenge must be provisioned out of band 874 (i.e. user or administrator manual input, beamed via PDA, smart 875 card, etc.) via a secure means. 877 Using HTTPS over TLS[13] the configuration server MAY request the 878 certificate of the UA [14]. If this level of authentication is 879 desired, the UA vendor SHOULD ship the UA with a digital certificate 880 or provide a means by which this can be installed out of band. The 881 configuration server MUST be provisioned with the certificates of 882 authority allowed for each model of UA to be supported. 884 Using HTTPS the UA MAY request the certificate of the configuration 885 server. If this level of authentication is desired the UA must be 886 provisioned with the allowed certificate(s) of authority and 887 identities for the configuration server out of band (i.e. user or 888 administrator manual input, beamed via PDA, smart card, etc.) via a 889 secure means. 891 A Framework for SIP November 2001 892 User Agent Configuration 894 10 Open Issues 896 [Do we need an option for the configuration server to tell the UA 897 that it MUST make the change immediately regardless of state? 898 Should this be the default?] 900 [Upload to configuration server configuration data profiles whole or 901 changes only ?? define in profiles ??] 903 [Security considerations section needs much elaboration] 904 A Framework for SIP November 2001 905 User Agent Configuration 907 11 References 909 [1] R. Droms, "Dynamic host configuration protocol," Request for 910 Comments (Draft Standard) 2131, Internet Engineering Task Force, 911 Mar. 1997. 913 [2] S. Alexander and R. Droms, "DHCP options and BOOTP vendor 914 extensions," Request for Comments (Draft Standard) 2132, Internet 915 Engineering Task Force, Mar. 1997. 917 [3] G.Nair, H.Schulzrinne , �DHCP Option for SIP Servers�, 918 , IETF; Mar. 2001, Work in progress. 920 [4] S. Bradner, "Key words for use in RFCs to indicate 921 requirement levels," Request for Comments (Best Current Practice) 922 2119, Internet Engineering Task Force, Mar. 1997. 924 [5] A. Gulbrandsen, P. Vixie, and L. Esibov, �A DNS RR for 925 specifying the location of services (DNS SRV),� Request for 926 Comments 2782, Internet Engineering Task Force, Feb. 2000. 928 [6] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, 929 �SIP: session initiation protocol,� , IETF; Oct. 2001, Work in progress. 932 [7] A. Roach, �Event Notification in SIP�, , IETF; Nov. 2001, Work in progress. 935 [8] D. Crocker, �STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT 936 MESSAGES�, Request for Comments 822, Internet Engineering Task 937 Force, Aug. 1982 939 [9] K. Sollins, �THE TFTP PROTOCOL (REVISION 2)�, Request for 940 Comments 1350, Internet Engineering Task Force, Jul. 1992 942 [10] H Schulzrinne, �Configuring IP Telephony End Systems�, 943 , IETF; Dec. 2000, Work in 944 progress 946 [11] D. Petrie, �Requirements for a SIP User Agent Configuration 947 Framework�, , IETF; 948 Feb. 2001, Work in progress 950 [12] T. Berners-Lee et al, �Uniform Resource Locators (URL)�, 951 Request for Comments 1738, Internet Engineering Task Force, Dec. 952 1994 954 [13] E. Rescorla, �HTTP Over TLS�, Request for Comments 2818, 955 Internet Engineering Task Force, May 2000 956 A Framework for SIP November 2001 957 User Agent Configuration 959 [14] T. Dierks, C. Allen, �The TLS Protocol Version 1.0�, Request 960 for Comments 2246, Internet Engineering Task Force, Jan. 1999 962 12 Author's Addresses 964 Dan Petrie 965 Pingtel Corp. 966 400 W. Cummings Park Phone: +1 781 938 5306 967 Woburn, MA USA Email: dpetrie@pingtel.com