idnits 2.17.1 draft-petrie-sipping-config-framework-00.txt: -(920): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(949): 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: 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: If the URL is for HTTP/HTTPS the server MUST return the changed configuration data profile in the response (assuming it was allowed). The configuration server SHOULD include an incremented sequence number in the HTTP/HTTPS response if the configuration data profile contents changed [Sip-Ua-Config-Seq header field?]. The UA SHOULD use the configuration data profile contents from the HTTP response as opposed to the data that was pushed in the request as changes may occur from other sources. The 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 (June 2001) is 8350 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 904, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 911, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 915, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 941, 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-sipping-config-framework-00.txt 5 Expires: Dec 2002 June 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 User Agent Configuration 46 Table of Contents 48 Status of this Memo................................................1 49 Abstract...........................................................1 50 1 Overview.......................................................3 51 2 Conventions used in this document..............................4 52 3 Changes from Previous Draft....................................4 53 3.1 Changes from draft-petrie-sip-config-framework-01.txt........4 54 3.2 Changes from draft-petrie-sip-config-framework-00.txt........4 55 4 Discovery......................................................5 56 4.1 DHCP Option..................................................6 57 4.2 DNS..........................................................6 58 4.3 Multicast....................................................6 59 4.4 Manually Provisioned.........................................6 60 5 Enrollment and Change Notification.............................7 61 5.1 Header Field Definitions.....................................8 62 5.1.1 Config-Allow................................................8 63 5.2 SUBSCRIBE....................................................8 64 5.2.1 Additional From Field Parameters............................9 65 5.3 NOTIFY......................................................10 66 5.3.1 NOTIFY Body Content Format.................................11 67 6 Configuration Retrieval.......................................11 68 7 Configuration Upload..........................................11 69 8 Examples......................................................12 70 8.1 Example Message Flows.......................................12 71 8.2 Example Messages............................................14 72 9 Security Considerations.......................................17 73 10 Open Issues...................................................17 74 11 References....................................................19 75 12 Author's Addresses............................................20 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 to the server 102 (Configuration Upload) 104 The content and format of the data is not defined in this document. 105 It will 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 User Agent Configuration 133 data profiles has changed. Subsequently the UA SHOULD retrieve the 134 data profile from the specified URL upon receipt of the change 135 notification. 137 Configuration Upload is the process by which a UA or other entity 138 pushes a change to a configuration data profile back up to the 139 configuration server. 141 2 Conventions used in this document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 145 this document are to be interpreted as described in RFC-2119 [1]. 147 The syntax and semantics used here extend those defined in SIP (RFC 148 2543) [6]. SIP is described in an augmented Backus-Naur form (ABNF). 149 See [6, section C] for an overview of ABNF. 151 3 Changes from Previous Draft 153 3.1 Changes from draft-petrie-sip-config-framework-01.txt 155 Changed the name as this belongs in the SIPPING work group. 157 Minor edits 159 3.2 Changes from draft-petrie-sip-config-framework-00.txt 161 Many thanks to those who contributed and commented on the previous 162 draft. Detailed comments were provided by Henning Schulzrinne from 163 Columbia U., Cullen Jennings from Cisco, Rohan Mahy from Cisco, Rich 164 Schaaf from Pingtel. 166 Split the enrollment into a single SUBSCRIBE dialog for each 167 profile. The 00 draft sent a single SUBSCRIBE listing all of the 168 desired. These have been split so that each enrollment can be 169 routed differently. As there is a concept of device specific and 170 user specific profiles, these may also be managed on separate 171 servers. For instance in a roaming situation the device might get 172 it�s configuration from a local server which knows the LAN specific 173 configuration. At the same time the user specific profiles might 174 come from the user�s home environment configuration server.' 176 Removed the Config-Expires header as it is largely superfluous with 177 the SUBSCRIBE Expires header. 179 Eliminated some of the complexity in the discovery mechanism. 181 Suggest caching information discovered about a configuration server 182 to avoid an avalanche problem when a whole building full of devices 183 powers up. 185 User Agent Configuration 187 Added the User-Profile From header field parameter so that the 188 device can a request a user specific profile for a user that is 189 different from the device�s default user. 191 4 Discovery 193 The purpose of discovery is to figure out how to address the 194 configuration server so that the device can enroll. The enrollment 195 process involves sending a SIP SUBSCRIBE. Prior to this the 196 discovery process must find the address to use in the URL for the 197 URI and To header field. The URL SHOULD use the user id: 198 sipuaconfig. From a SIP perspective the configuration server is 199 simply a user agent. By using the well known user id, this makes it 200 easy for proxy servers to be provisioned to route the enrollment 201 requests from devices to the appropriate configuration server for 202 the domain. 204 The first time a UA is plugged in it does not know the address or 205 port at which to enroll with the local configuration server. It 206 must discover this address and port. A UA SHOULD support all of the 207 listed discovery mechanisms. It MUST support at least one of them. 208 Once the UA has discovered the address and port and has successfully 209 enrolled with the configuration server, the UA SHOULD cache the 210 address and port to avoid the need to re-discover the configuration 211 server. However if enrollment, configuration retrieval or 212 configuration upload fails at any time, the UA SHOULD apply the 213 discovery and enrollment process again. This provides a means for 214 configuration server fail over and load balancing. 215 The UA SHOULD use the following mechanisms to discover the host 216 address and port at which it SHOULD enroll with the configuration 217 server. Each mechanism should be tried in the following order until 218 an address and port is provided which results in successful 219 enrollment (i.e. the server responds with a successful 2xx class 220 response): 221 - DHCP option for SIP [1] 222 - DNS A record 223 - Multicast 224 - Manual provisioning 226 The rationale for this order follows. Assuming that most UAs are 227 going to use DHCP for IP configuration anyway, using a DHCP option 228 is the least costly in terms of lookup time (i.e. no additional 229 messages are required). Hence DHCP is first. Multicast is used 230 last of the automated discovery mechanisms as it is the most 231 restricted in terms of network environments that support it. 232 Multicast is included, even though the applicable environments are 233 restricted, as it is the only mechanism that can be used without the 234 support of the local network administrator. 236 The phone administrator and the network administrator are often 237 different people and perhaps in different departments. 239 User Agent Configuration 241 The UA implementer MAY provide the user or administrator with the 242 means to change the order in which these mechanisms are tried. This 243 includes the ability to manually override the discovery process. 244 However by default without user interaction the UA SHOULD use the 245 order listed above. 247 Once discovery is successful the device SHOULD persistently cache 248 the address to avoid avalanche problems when a whole building full 249 of devices powers up at once. The characteristic of the profile may 250 dictate this behavior. For example device specific profiles may 251 need to change when the device is moved to a different location. 252 User specific profiles may be independent of the LAN, network or 253 device location. 255 4.1 DHCP Option 257 It is likely that most UAs in an environment of any significant 258 number will use DHCP for IP configuration. DHCP becomes a 259 convenient means to discover the configuration server address. In 260 the same DHCP request for basic IP configuration, the UA can add the 261 option for SIP[3] [1] to the options field. This indicates a 262 request for the default SIP proxy server address and port. For 263 example if the DHCP option for SIP returns an address of 264 sip.acme.com and a port of 5080, the following URL is constructed: 265 sip:sipuaconfig@sip.acme.com:5080. If the proxy server address and 266 port is not returned in the DHCP response or the server does not 267 respond to the enrollment request with a successful 2xx class 268 response, the next discovery mechanism is attempted. 270 4.2 DNS 272 The UA SHOULD construct a fully qualified host name using 273 �sipuaconfig� as the host and the local domain if defined. It 274 SHOULD try a DNS A record lookup on the fully qualified host name. 275 If the name resolves in DNS it should then attempt enrollment. For 276 example the URL constructed in the local domain of acme.com would 277 look like: sip:sipuaconfig@sipuaconfig.acme.com. If the server does 278 not respond to enrollment with a successful 2xx class response, the 279 next discovery mechanism is attempted. 281 4.3 Multicast 283 The enrollment request is sent to the multicast address for SIP 284 registration [6] "sip.mcast.net" (224.0.1.75). If a server does not 285 respond with a successful 2xx class response to the enrollment 286 request, the next discovery mechanism is attempted. 288 4.4 Manually Provisioned 290 The UA MAY indicate to the user (or administrator) that automatic 291 discovery has failed. The UA SHOULD allow the user or administrator 292 to manually (perhaps using some out of band method e.g. beam, smart 293 User Agent Configuration 295 card, etc.) enter the configuration server address and port to be 296 used for enrollment. 298 5 Enrollment and Change Notification 300 The enrollment and configuration change notification are paired 301 together and provided via the SIP SUBSCRIBE/NOTIFY framework [7]. 302 This document defines the profile on top of the SUBSCRIBE/NOTIFY 303 framework [7] for this purpose. 305 UA enrollment with the configuration server is accomplished via the 306 SUBSCRIBE request. A UA MUST enroll with the configuration server 307 prior to retrieving configuration data profiles. As part of the 308 enrollment the UA MUST identify itself, its configuration retrieval 309 protocol capabilities and configuration data profile requirements. 311 The configuration server may use this information to decide how to 312 allocate resources (e.g. load balancing) to support the UA for its 313 specific configuration retrieval needs. The configuration server 314 may also use the UA enrollment event as the trigger to generate a 315 new set of configuration data for the specific UA (e.g. based upon 316 provisioned defaults and configuration profile context knowledge for 317 the environment). This allows the configuration server to provide 318 configuration data for a new UA without previously provisioning the 319 specific UA on the server. 321 Each profile that the device requires is obtained via a separate 322 enrollment or SUBSCRIBE request and SIP dialog. That is for each 323 different profile a device enrolls for, a different Call-Id is used. 324 The device names the profile in the SUBSCRIBE Event header field. 325 The configuration server then delivers a URL at which the device can 326 retrieve the profile in a subsequent NOTIFY request. Changes to the 327 profile are indicated in additional NOTIFY requests sent from the 328 configuration server. 330 The SUBSCRIBE request for enrollment is sent to the address(es) 331 identified in the discovery process until the first successful 2xx 332 class response is received. As part of the binding of the 333 SUBSCRIBE/NOTIFY framework a new Event token must be named for each 334 type of profile. 336 If enrollment fails (i.e. no 2xx response to SUBSCRIBE), the UA 337 SHOULD re-discover the configuration server address and port as 338 described in section 3. 340 The following new header field is defined for use in SUBSCRIBE and 341 NOTIFY requests for the purpose of enrollment and configuration 342 change notification: 344 The keys used in the following table are: 345 R � request 346 r � response 347 m � mandatory 348 User Agent Configuration 350 o � optional 351 - - not applicable 353 Header Where SUBSCRIBE NOTIFY 354 ------ ----- --------- ------ 355 Config-Allow R m - 357 5.1 Header Field Definitions 359 5.1.1 Config-Allow 361 The Config-Allow header field is used by the UA in the enrollment 362 request (SUBSCRIBE) to list the protocols that it is capable of 363 using to retrieve configuration data. The configuration server MUST 364 adhere to the protocol capabilities of the UA when providing the URL 365 for the configuration profile in the NOTIFY request. 367 Syntax: 368 Config-Allow = "Config-Allow" ":" config-protocol 369 *(�,� config-protocol) 370 config-protocol = �tftp� | �http� | �https� | token 372 5.2 SUBSCRIBE 374 The SUBSCRIBE request is used by the UA to enroll in the 375 configuration domain of the configuration server. It uniquely 376 identifies the UA with vendor, model and serial number information. 377 The UA also MUST specify its capabilities for configuration 378 retrieval. The UA MUST include the Config-Allow header field which 379 MUST contain at least one token. The configuration server SHOULD 380 not send an error if it is temporarily not able to provide the 381 configuration data profile listed in the SUBSCRIBE request Event 382 header field. In the first time out of the box case, the SUBSCIRBE 383 dialog may be the only means of communicating with the device as it 384 does not yet have configuration. The configuration server SHOULD 385 send a 403 response to the SUBSCRIBE if is not willing to provide 386 the requested configuration profile to the device. The 387 configuration server SHOULD provide the configuration data profile 388 that it is able to or desires (see example at the end of section 389 4.3) to deliver to the UA. If the configuration server sends a 301 390 Moved Permanently response to the enrollment SUBSCRIBE, the UA 391 SHOULD cache the URL contained in the response Contact header field 392 in place of the address and port found during discovery for future 393 enrollment. 395 The device may request many configuration data profiles by 396 sending multiple SUBSCRIBE requests each in a different SIP 397 dialog. This may be useful if the device requires user 398 specific profiles for multiple users. In this case the 399 UserProfile parameter would vary for each SUBSCRIBE. 400 Alternately the device may require multiple types of profiles 401 User Agent Configuration 403 where each SUBSCRIBE would have a different Event header field 404 token. 406 The configuration server MAY use the enrollment (SUBSCRIBE request) 407 as the stimulus to generate a new instance of a configuration data 408 profile unique to the UA. Alternately the configuration server MAY 409 be provisioned ahead of time to know about new UAs and their 410 specific configuration data content (for example based upon serial 411 number, MAC address). 413 5.2.1 Additional From Field Parameters 415 When the device first starts up out of the box, it has no user or 416 local configuration. The device MUST provide a unique identity such 417 that it is possible for the configuration server to generate 418 configuration profile for the device. The following additional From 419 field parameters are defined for the purpose of identifying the UA 420 device: 422 Vendor � a token used to identify the UA vendor name 424 Model � a token used to identify the UA hardware/software model 426 Version � a token used to identify the firmware/software version 427 currently installed on the UA 429 Serial � the token used to identify the serial number for the UA 431 Mac � the token used to identify the MAC address in hex for the UA 433 From RFC 2543 bis [6] the From header field syntax is extended to 434 include: 435 from-param = tag-param | generic-param | device-param 436 device-param = vendor-parm | model-parm | version-parm | 437 serial-parm | mac-parm | user-profile-param 438 vendor-parm = �Vendor� �=� token 439 model-parm = �Model� �=� token 440 version-parm = �Version� �=� token 441 serial-parm = �Serial� �=� token 442 mac-parm = �Mac� �=� token 443 user-profile-param = �UserProfile� �=� SIP-URL 445 The Vendor, Model, Version, Serial and Mac parameters MUST be 446 provided in the From URL for the enrollment SUBSCRIBE request. Most 447 profiles will either be device or user specific. If the profile is 448 user specific and the device knows the user for which it is to 449 retrieve, the profile UserProfile MUST be provided. If the profile 450 is device specific or the device does not know whose user profile it 451 should retrieve, the device SHOULD not provide the UserProfile 452 parameter. The profile is user specific and UserProfile is not 453 present the configuration server assumes the default user for the 454 device. 456 User Agent Configuration 458 5.3 NOTIFY 460 The NOTIFY message is sent by the configuration server to convey the 461 URL at which the UA can retrieve the requested configuration data 462 profile. This occurs in two contexts: 464 Immediately following the enrollment SUBSCRIBE the configuration 465 server MUST send a NOTIFY providing the URL for the configuration 466 data profile requested by the UA in the Event header field of the 467 SUBSCRIBE request. If the configuration server is not able to 468 provide the specific configuration data profile or it does not 469 want the UA to retrieve the specific configuration profile at that 470 time, it MAY defer sending NOTIFY. Later when the configuration 471 server is able to provide the data profile or it wishes the UA to 472 retrieve the data profile, the configuration server MAY send a 473 NOTIFY request containing the URL for the configuration data 474 profile which the UA SHOULD retrieve as soon as it is safe to do 475 so. 477 If the configuration server becomes aware of a configuration 478 change that it wishes to be effective immediately on the UA, the 479 configuration server SHOULD send a NOTIFY message containing the 480 URL for the configuration data profile that the UA requested when 481 it enrolled. The configuration data profile with changed content 482 SHOULD have a sequence number larger than that of the last NOTIFY 483 request. The UA SHOULD retrieve and make effective the changed 484 configuration URL immediately upon receipt of the NOTIFY request. 485 The UA MAY choose to wait to make the changes effective (e.g. to 486 prevent the change from disrupting active calls on the UA). 488 [Do we need an option for the configuration server to tell the UA 489 that it MUST make the change immediately regardless of state? 490 Should this be the default?] 492 The UA SHOULD send a 200 response to the NOTIFY immediately upon 493 receipt and validation of the solicited request. The configuration 494 server MUST include, in the change notification NOTIFY request, the 495 configuration data profile URL. The sequence numbers associated 496 with the configuration data profile with changed content should be 497 larger than those in the previous NOTIFY. The URL listed in the 498 NOTIFY request MUST use one of the protocols the UA listed in the 499 Config-Allow header field provided during enrollment in the most 500 recent SUBSCRIBE request. The sequence number for the configuration 501 data profile URL MUST be a positive integer chosen by the 502 configuration server. The sequence number value MUST increase 503 monotonically as modifications are made to a data profile. 505 This mechanism may be used by the configuration server to provide 506 firmware updates. For example on a UA that caches or has a 507 persistent firmware image: if the server realizes (e.g. from the 508 enrollment information) the UA is running the most currently 509 available firmware version, it could defer sending the NOTIFY with 510 the URL for the firmware. However at a later time when a new 511 User Agent Configuration 513 firmware version is available the configuration server could send 514 a NOTIFY with the URL for the new firmware version, indicating the 515 UA SHOULD upgrade as soon as it is safe to do so. 517 5.3.1 NOTIFY Body Content Format 519 The NOTIFY request contains a body of Content-Type: text/plain. The 520 content is formatted according to RFC 822 [8]. It contains a header 521 field with the same name as the configuration data profile indicated 522 in the Event header. The value of the header field MUST contain a 523 URL and a sequence number as described in the syntax below. The 524 protocol of the URL MUST be one of those listed in the Config-Allow 525 header field provided by the UA in the enrollment SUBSCRIBE request. 526 The sequence number associated with the URL is intended to allow the 527 UA to decide if it has the latest content of the configuration data 528 profile without having to download and compare the contents. 530 Syntax: 531 config-profile = token �:� Seq-Param �;� Url-Param 532 Seq-Param = �Sequence� �=� 1*digit 533 Url-Param = �Url� �=� tftp-url | Http-url | Https-url 534 Tftp-url [need reference] 535 Http-Url as defined in [12, section 3.3] 536 Https-Url [need reference] 538 Example: 540 X-Acme-Special: Sequence=1234567;Url=http://www.acme.com/config.txt 542 6 Configuration Retrieval 544 The UA MUST retrieve its configuration data profile using the URL 545 specified by the configuration server in the NOTIFY request. If the 546 retrieval fails, the UA SHOULD not re-enroll until the SUBSCRIBE 547 session expires to avoid a cascade effect if the server goes down 548 temporarily. The device MAY re-try the profile retrieve of the 549 profile from the URL before the SUBSCRIBE expires. Should the re- 550 enrollment fail, the UA SHOULD re-discover the configuration server 551 as described in section 4. 553 7 Configuration Upload 555 If the UA or another entity wishes to modify a configuration data 556 profile it MAY make the change persistent on the configuration 557 server if it is authorized to do so. The configuration server 558 SHOULD support the ability to upload via the same URL the UA used to 559 retrieve the configuration data profile. For TFTP the UA does a put 560 [9]. For HTTP and HTTPS the UA does a POST with a multipart MIME 561 attachment containing any URL parameters in one part and the changed 562 configuration data profile [whole or changes only ?? define in 563 profiles ??] in another part as defined in [?]. If the UA or user 564 is not permitted to make the changes on the configuration server the 565 User Agent Configuration 567 configuration server returns an HTTP error response code of 403 568 Forbidden. If the configuration server returns a 403 the UA SHOULD 569 disallow the changes from being effective on the UA. The UA SHOULD 570 not make the changes effective until it receives a successful 571 response (e.g. for HTTP 2xx). 573 If the URL is for HTTP/HTTPS the server MUST return the changed 574 configuration data profile in the response (assuming it was 575 allowed). The configuration server SHOULD include an incremented 576 sequence number in the HTTP/HTTPS response if the configuration data 577 profile contents changed [Sip-Ua-Config-Seq header field?]. The UA 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 608 server by sending a SUBSCRIBE request for the profile type indicated 609 in the Event header. The configuration server sends back a 610 successful response. The configuration server then sends a NOTIFY 611 request with the URL for the configuration data profile that the UA 612 named in the enrollment SUBSCRIBE request. The UA sends a 200 613 response to the NOTIFY. The UA then downloads the configuration 614 data profile via the URL from the NOTIFY request. This process may 615 be repeated in parallel for each of the required profiles. The UA 616 is now 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 User Agent Configuration 622 behalf of the administrator, sends a NOTIFY (change notification) 623 request to the UA with an incremented sequence number for the 624 profile. As the sequence number has changed, the UA downloads the 625 configuration data profile from the given URL. 627 UA DHCP Server DNS Server Config. Server 629 Discovery 631 IP config. req. 632 ==============> 633 IP config. wo/ local option 634 <============== 635 DNS A record req. for sipuaconfig host in local domain 636 =============================> 637 A record IP address returned for Host 638 <============================= 640 Enrollment 642 SIP SUBSCRIBE Event: Sip-Device 643 ==================================================> 644 200 OK 645 <================================================== 646 SIP NOTIFY Event: Sip-Device w/ requested profile URL 647 <================================================== 648 200 OK 649 ==================================================> 651 Configuration retrieval 653 HTTP GET 654 ==================================================> 655 200 OK (specific profile data in body) 656 <================================================== 657 . 658 . 659 . 661 Administrative change on configuration server via user interface 662 . 663 . 664 . 666 Change Notification 668 SIP NOTIFY Event: Sip-Device w/ changed profile URL 669 <================================================== 670 200 OK 671 ==================================================> 672 HTTP GET 673 ==================================================> 674 200 OK (profile data in body) 675 User Agent Configuration 677 <================================================== 678 . 679 . 680 . 682 User changes data in a profile on the user agent 683 . 684 . 685 . 687 Configuration Upload 689 HTTP POST (changed profile attached as multipart MIME) 690 ==================================================> 691 200 OK (profile data in body, as change confirmation) 692 <================================================== 693 . 694 . 695 . 697 8.2 Example Messages 699 The following SUBSCRIBE request example is from a UA enrolling with 700 a configuration server. As this SUBSCRIBE request is for 701 configuration enrollment the Event header field contains the token 702 Config-Event. The UA tells the configuration server that it 703 supports the TFTP, HTTP, HTTPS protocols for retrieving 704 configuration data profiles in the Config-Allow header field. The 705 UA tells the configuration server that it would like the 706 configuration data profile named: sip-device in the Event header 707 field. The UA tells the configuration server that it is enrolling 708 for 86400 seconds via the Expires header field. During this period 709 of time the configuration server MUST send a change notification 710 with the URL for the configuration data profile which changed. The 711 UA has identified the specifics about itself in the From field 712 parameters: Vendor, Model, Version, Serial, Mac. In this example 713 the UserProfile parameter is not included in the From field as the 714 Sip-Device profile is device specific not user specific. 716 UA => Config. Server 718 SUBSCRIBE sip: sipuaconfig@config.localdomain.com SIP/2.0 719 To: sip:sipuaconfig@config.localdomain.com 720 From: sip:10.1.1.123;Vendor=acme;Model=model-a 721 ;Version=1.5.0.1;Serial=1234567890;Mac=000aaa1234cd 722 Call-Id: 987654321@10.1.1.123 723 Cseq: 1 SUBSCRIBE 724 Event: Sip-Device 725 Config-Allow: tftp, http, https 726 Expires: 86400 727 Content-Length: 0 728 User Agent Configuration 730 The following is an example response to the above enrollment 731 request. 733 Config. Server => UA 735 SIP/2.0 202 Accepted 736 To: sip:config.localdomain.com 737 From: sip:10.1.1.123;Vendor=acme;Model=model-a 738 ;Version=1.5.0.1;Serial=1234567890;Mac=000aaa1234cd 739 Call-Id: 987654321@10.1.1.123 740 Cseq: 1 SUBSCRIBE 741 Content-Length: 0 743 In the following example the device is requesting a user specific 744 profile Sip-User. The device specifies that it want the profile for 745 the user: sip:fredsmith@localdomain.com. 747 UA => Config. Server 749 SUBSCRIBE sip: sipuaconfig@config.localdomain.com SIP/2.0 750 To: sip:sipuaconfig@config.localdomain.com 751 From: sip:10.1.1.123;Vendor=acme;Model=model-a 752 ;Version=1.5.0.1;Serial=1234567890;Mac=000aaa1234cd 753 ;UserProfile=sip%3Afredsmith%40localdomain.com 754 Call-Id: 11111111@10.1.1.123 755 Cseq: 1 SUBSCRIBE 756 Event: Sip-Device 757 Config-Allow: tftp, http, https 758 Expires: 86400 759 Content-Length: 0 761 The following is an example response to the above enrollment 762 request. 764 Config. Server => UA 766 SIP/2.0 202 Accepted 767 To: sip:config.localdomain.com 768 From: sip:10.1.1.123;Vendor=acme;Model=model-a 769 ;Version=1.5.0.1;Serial=1234567890;Mac=000aaa1234cd 770 ;UserProfile=sip%3Afredsmith%40localdomain.com 771 Call-Id: 11111111@10.1.1.123 772 Cseq: 1 SUBSCRIBE 773 Content-Length: 0 775 The following example is the immediate NOTITY request the 776 configuration server sent to the UA following enrollment. The URL 777 in the request body is for the configuration data profile the UA 778 named in the Event header field in the above SUBSCRIBE request from 779 the UA. 781 User Agent Configuration 783 Config. Server => UA 785 NOTIFY sip:10.1.1.123 SIP/2.0 786 To: sip:10.1.1.123;Vendor=acme;Model=model-a 787 ;Version=1.5.0.1;Serial=1234567890;Mac=000aaa1234cd 788 From: sip:config.localdomain.com 789 Call-Id: 987654321@10.1.1.123 790 Cseq: 22 NOTIFY 791 Event: Sip-Device 793 Content-Type: text/plain 794 Content-Length: 79 796 Sip-Device: Sequence=1 797 ;Url=http://config.localdomain.com/device/1234567890 799 The following is an example response from the UA for the above 800 request. 802 UA => Config. Server 804 SIP/2.0 200 Ok 805 To: sip:10.1.1.123;Vendor=acme;Model=model-a 806 ;Version=1.5.0.1;Serial=1234567890;Mac=000aaa1234cd 807 From: sip:config.localdomain.com 808 Call-Id: 987654321@10.1.1.123 809 Cseq: 22 NOTIFY 810 Content-Length: 0 812 Assume at some later time, an administrator makes a change to the 813 content of the Sip-Device configuration data profile for the UA. 814 The configuration server sends a NOTIFY request to the UA for the 815 configuration change notification. This example request below 816 indicates the changed URL or content in the request body with a 817 higher sequence number. 819 Config. Server => UA 821 NOTIFY sip:10.1.1.123 SIP/2.0 822 To: sip:10.1.1.123;Vendor=acme;Model=model-a 823 ;Version=1.5.0.1;Serial=1234567890;Mac=000aaa1234cd 824 From: sip:config.localdomain.com 825 Call-Id: 987654321@10.1.1.123 826 Event: Sip-Device 827 Cseq: 23 NOTIFY 828 Content-Type: text/plain 829 Content-Length: 79 831 Sip-Device: Sequence=2 832 ;Url=http://config.localdomain.com/device/1234567890 833 User Agent Configuration 835 The following is an example response to the above request. 837 UA => Config. Server 839 SIP/2.0 200 Ok 840 To: sip:10.1.1.123;Vendor=acme;Model=model-a 841 ;Version=1.5.0.1;Serial=1234567890;Mac=000aaa1234cd 842 From: sip:config.localdomain.com 843 Call-Id: 987654321@10.1.1.123 844 Cseq: 23 NOTIFY 845 Content-Length: 0 847 9 Security Considerations 849 [This section needs to be greatly expanded and elaborated] 851 SIP basic and digest authentication [6] MAY be used for 852 SUBSCRIBE/NOTIFY messages used for enrollment and configuration 853 change notification. There is a chicken and egg problem. Since the 854 content of SUBSCRIBE/NOTIFY messages are transported in the clear, 855 the credentials that the UA uses in the SUBSCRIBE 401 challenge, or 856 that the configuration server uses in the NOTIFY 401 challenge must 857 be provisioned out of band (i.e. user or administrator manual input, 858 beamed via PDA, smart card, etc.) via a secure means. 860 Configuration data profile URLs are communicated in the clear in the 861 NOTIFY requests from the configuration server. The security risk of 862 unauthorized access of the URL content can be mitigated if the 863 configuration server and UA both support basic authentication and 864 HTTP or HTTPS. There is a chicken and egg problem here as well 865 since the content of SUBSCRIBE/NOTIFY messages are transported in 866 the clear. Accordingly,the credentials that the UA uses for the 867 HTTP/HTTPS GET/POST 401 challenge must be provisioned out of band 868 (i.e. user or administrator manual input, beamed via PDA, smart 869 card, etc.) via a secure means. 871 Using HTTPS over TLS[13] the configuration server MAY request the 872 certificate of the UA [14]. If this level of authentication is 873 desired, the UA vendor SHOULD ship the UA with a digital certificate 874 or provide a means by which this can be installed out of band. The 875 configuration server MUST be provisioned with the certificates of 876 authority allowed for each model of UA to be supported. 878 Using HTTPS the UA MAY request the certificate of the configuration 879 server. If this level of authentication is desired the UA must be 880 provisioned with the allowed certificate(s) of authority and 881 identities for the configuration server out of band (i.e. user or 882 administrator manual input, beamed via PDA, smart card, etc.) via a 883 secure means. 885 10 Open Issues 886 User Agent Configuration 888 [Do we need an option for the configuration server to tell the UA 889 that it MUST make the change immediately regardless of state? 890 Should this be the default?] 892 [Upload to configuration server configuration data profiles whole or 893 changes only ?? define in profiles ??] 895 [Security considerations section needs much elaboration] 896 User Agent Configuration 898 11 References 900 [1] R. Droms, "Dynamic host configuration protocol," Request for 901 Comments (Draft Standard) 2131, Internet Engineering Task Force, 902 Mar. 1997. 904 [2] S. Alexander and R. Droms, "DHCP options and BOOTP vendor 905 extensions," Request for Comments (Draft Standard) 2132, Internet 906 Engineering Task Force, Mar. 1997. 908 [3] G.Nair, H.Schulzrinne , �DHCP Option for SIP Servers�, 909 , IETF; Mar. 2001, Work in progress. 911 [4] S. Bradner, "Key words for use in RFCs to indicate 912 requirement levels," Request for Comments (Best Current Practice) 913 2119, Internet Engineering Task Force, Mar. 1997. 915 [5] A. Gulbrandsen, P. Vixie, and L. Esibov, �A DNS RR for 916 specifying the location of services (DNS SRV),� Request for 917 Comments 2782, Internet Engineering Task Force, Feb. 2000. 919 [6] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, 920 �SIP: session initiation protocol,� , IETF; Oct. 2001, Work in progress. 923 [7] A. Roach, �Event Notification in SIP�, , IETF; Nov. 2001, Work in progress. 926 [8] D. Crocker, �STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT 927 MESSAGES�, Request for Comments 822, Internet Engineering Task 928 Force, Aug. 1982 930 [9] K. Sollins, �THE TFTP PROTOCOL (REVISION 2)�, Request for 931 Comments 1350, Internet Engineering Task Force, Jul. 1992 933 [10] H Schulzrinne, �Configuring IP Telephony End Systems�, 934 , IETF; Dec. 2000, Work in 935 progress 937 [11] D. Petrie, �Requirements for a SIP User Agent Configuration 938 Framework�, , IETF; 939 Feb. 2001, Work in progress 941 [12] T. Berners-Lee et al, �Uniform Resource Locators (URL)�, 942 Request for Comments 1738, Internet Engineering Task Force, Dec. 943 1994 945 [13] E. Rescorla, �HTTP Over TLS�, Request for Comments 2818, 946 Internet Engineering Task Force, May 2000 947 User Agent Configuration 949 [14] T. Dierks, C. Allen, �The TLS Protocol Version 1.0�, Request 950 for Comments 2246, Internet Engineering Task Force, Jan. 1999 952 12 Author's Addresses 954 Dan Petrie 955 Pingtel Corp. 956 400 W. Cummings Park Phone: +1 781 938 5306 957 Woburn, MA USA Email: dpetrie@pingtel.com