idnits 2.17.1 draft-nottingham-web-proxy-desc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 14, 2014) is 3481 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) == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-14 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft 4 Intended status: Standards Track October 14, 2014 5 Expires: April 17, 2015 7 The Web Proxy Description Format 8 draft-nottingham-web-proxy-desc-01 10 Abstract 12 This specification defines a simple means of configuring Web proxies, 13 and places additional requirements upon them in order to promote 14 improved interoperability, security, and error handling. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 17, 2015. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 52 2. WPD Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. The Web Proxy Description (WPD) Format . . . . . . . . . . . 5 54 3.1. name . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.2. desc . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.3. moreInfo . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.4. proxies . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.4.1. host . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.4.2. port . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3.4.3. clientNetworks . . . . . . . . . . . . . . . . . . . 7 61 3.5. forReferers . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.6. alwaysDirect . . . . . . . . . . . . . . . . . . . . . . 8 63 3.7. failDirect . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.8. exclusive . . . . . . . . . . . . . . . . . . . . . . . . 9 65 3.9. privateMode . . . . . . . . . . . . . . . . . . . . . . . 9 66 4. Discovering WPD Files . . . . . . . . . . . . . . . . . . . . 9 67 4.1. The web-proxy-desc well-known URI . . . . . . . . . . . . 10 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 8.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Appendix A. User Experience for WPDs . . . . . . . . . . . . . . 12 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 Web proxies can be configured in a variety of ways, but existing 80 approaches suffer from security, usability and interoperability 81 issues. 83 This specification defines: 85 o A simple format for describing a Web proxy ("WPD"; see Section 3) 86 to facilitate configuration, and to allow proxies to be 87 represented to users in a consistent way, and 89 o A way to discover the proxy description using a well-known URL 90 (Section 4), so that direct configuration of a proxy is as simple 91 as entering a hostname, and 93 o A set of additional requirements for proxies described in this 94 fashion, as well as requirements for User Agents connecting to 95 them, designed to improve security, usability and 96 interoperability. See Section 2. 98 It can be used in a variety of ways, but is designed to meet the 99 following goals: 101 o Users should always be aware of a configured proxy and be able to 102 confidently identify it, and 104 o Configuring a proxy should be a deliberate act, but simple to do 105 for non-technical users, and 107 o Proxies should always respect the wishes of the end user and Web 108 site, and 110 o Proxies should never reduce or compromise the security of 111 connections, and improve it where possible, and 113 o Proxies should be able to reliably communicate with their end 114 users regarding their policies and problems that are encountered. 116 Furthermore, it is designed to be useful in the following cases: 118 o An end user wants to use a proxy network that provides improved 119 performance, by re-compressing responses to http:// resources. 121 o An end user wants to use a proxy network that provides improved 122 privacy, by routing requests through any number of intermediaries. 124 o An end user is required to use a proxy to access Internet 125 resources by their network (e.g., a school, workplace or prison). 127 o A network wants to offer enhanced access to selected Web sites, 128 through interposition of a proxy. 130 Importantly, this specification does not address the automatic 131 discovery of proxy configuration for a given network, because proxy 132 configuration is a security-sensitive action, and ought never be 133 performed without explicit user or administrator action. 135 It is expected that the mechanisms described could be implemented by 136 a single program (e.g., a Web browser), or through an Operating 137 System facility. 139 1.1. Notational Conventions 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 2. WPD Proxies 147 This specification defines a particular kind of HTTP proxy (as per 148 [RFC7230] Section 2.3) known as a "WPD proxy" that has additional 149 requirements placed upon it, as well as upon those using it. 151 WPD Proxies MUST support HTTP/2 [I-D.ietf-httpbis-http2] over TLS for 152 connections from clients. Clients MUST use HTTP/2 over TLS to 153 connect to a WPD proxy; if one cannot be established, the client MUST 154 consider that proxy "failed." 156 WPD Proxies MUST support forwarding requests with the "http" scheme 157 [RFC7230], and SHOULD support the CONNECT method, as specified in 158 [I-D.ietf-httpbis-http2] Section 8.3. 160 [RFC7230] Section 5.7.2 requires proxies to honour the semantic of 161 the "no-transform" cache-control directive, and append the 214 162 (Transformation Applied) warn-code to other messages that have been 163 transformed; WPD proxies MUST honour these requirements. 165 When connecting to a WPD proxy, clients MUST validate the proxy 166 hostname as per [RFC2818] Section 3.1. If the proxy presents an 167 invalid certificate, that proxy MUST be considered "failed" and not 168 used (until a valid certificate is presented). 170 User agents MUST use a CONNECT tunnel when retrieving URLs with the 171 "https" scheme through WPD proxies. 173 When user agents encounter 5xx responses to a CONNECT request from a 174 WPD proxy, they MUST present the response to the end user, but MUST 175 NOT present or process it as a response to the eventual request to be 176 made through the tunnel (i.e., it has an unidentified payload, as per 177 [RFC7231] Section 3.1.4.1). 179 NOTE: Many user agents refuse to show an error response to a CONNECT 180 to the user, in order to deal with the issues brought to light by 181 [bad-proxy]. While effective in dealing with those attacks, doing so 182 effectively disallows communication between the proxy and the end 183 user; this requirement is designed to re-open that channel. 185 If a WPD proxy becomes unresponsive, clients SHOULD consider it 186 failed and attempt to use another proxy (if available) or inform the 187 end user (if not available). Clients SHOULD regularly attempt to re- 188 establish contact with failed WPD proxies (e.g., every minute). 190 Requests for the "localhost" [RFC6761] and "local" [RFC6762] top- 191 level domains MUST NOT be routed through a WPD proxy. 193 Likewise, requests to the Loopback address blocks (127.0.0.0/8 and 194 ::1/128) and the Link Local block (169.254.0.0/16 and fe80::/10) MUST 195 NOT be routed through a WPD proxy; see [RFC6890]. Note that clients 196 are not required to perform a reverse lookup on hostnames to conform 197 to this requirement. 199 3. The Web Proxy Description (WPD) Format 201 WPD is a JSON [RFC7159] format that describes a Web proxy to 202 potential clients. Its root is an object containing WPD-specific 203 object members. For example: 205 { 206 "name": "ExampleCorp Web Proxy", 207 "desc": "ExampleCorp's Proxy Gateway for Web access. Note that 208 all traffic through this proxy is logged, and may be 209 filtered for content.", 210 "moreInfo": "https://inside.example.com/proxy/", 211 "proxies": [ 212 { 213 "host": "proxy.example.com", 214 "port": 8080, 215 "clientNetworks": ["192.0.2.0/24"] 216 }, 217 { 218 "host": "proxy1.example.com", 219 "port": 8080, 220 "clientNetworks": ["192.0.2.0/24"] 221 } 222 ], 223 "alwaysDirect": ["example.com", "192.0.2.0/24"], 224 "failDirect": False 225 } 227 When configuring a proxy through WPD, a user agent SHOULD present the 228 relevant information contained within (i.e., the 'name', 'desc' and 229 'moreInfo' members, the latter as a link) to the end user. User 230 agents SHOULD also make this information available to the end user 231 whenever the WPD is in use. 233 The remainder of this section defines the content of the WPD object 234 members. Unrecognized members SHOULD be ignored. 236 3.1. name 238 A string containing a short, memorable name for the proxy; typically 239 64 characters or less. This member MUST be present for the WPD to be 240 considered valid. 242 3.2. desc 244 A string containing a textual description of the proxy's function(s); 245 typically 256 characters or less. This member MUST be present for 246 the WPD to be considered valid. 248 3.3. moreInfo 250 A string containing a URL [RFC3986] that leads to more information 251 about the proxy, its operation, who operates it, etc. The URL MUST 252 have a scheme of "https" [RFC7230], and MUST be able to respond with 253 an HTML [W3C.CR-html5-20140731] representation. This member MUST be 254 present for the WPD to be considered valid. 256 3.4. proxies 258 An array containing one or more proxy objects; each proxy object 259 represents a HTTP proxy endpoint that can be used when this WPD is 260 configured. See Section 2 for requirements specific to these 261 proxies, as well as those clients connecting to them. 263 Proxy objects' members are defined by the following subsections; 264 unrecognized members SHOULD be ignored. 266 The ordering of proxy objects within the proxies array is not 267 significant; clients MAY choose any proxy they wish (as long as the 268 specific requirement so the proxy object are met), and MAY use more 269 than one at a time. 271 NOTE: the array of proxy objects is functionally similar to, but not 272 as expressive as, the commonly-used "proxy.pac" format. While it 273 would be expedient for WPD to just reference a proxy.pac, feedback so 274 far is that proxy.pac has a number of deficiencies, and 275 interoperability is poor. Therefore, this document specifies the 276 proxy object instead, in order to gather feedback on an alternative 277 approach. 279 3.4.1. host 281 A string containing the host (as per [RFC3986], section 3.2.2) of the 282 proxy. This member MUST be present. 284 3.4.2. port 286 A number representing the port that the proxy is listening on. This 287 member MUST be present, and MUST be an integer. 289 3.4.3. clientNetworks 291 An array containing strings; each string contains a classless prefix 292 (see [RFC4632]) which the proxy can be used within. Clients MUST NOT 293 attempt to use the proxy if their IP address is not within one of the 294 stated ranges. 296 This member is optional. 298 For example, if the value of clientNetworks is 300 [ "192.168.1.0/32", "192.168.2.0/24" ] 302 then the only clients that could use the proxy would have IP 303 addresses in the ranges 192.168.1.0 to 192.168.1.3 and 192.168.2.0 to 304 192.168.2.255. 306 Note that by their nature private networks (as specified in 307 [RFC1918]) are not unique, and therefore there may be false 308 positives. As such, clients SHOULD NOT automatically configure a WPD 309 based upon clientNetworks when the IP address is in these ranges, 310 although they MAY notify the user of a WPD's possible applicability, 311 and SHOULD use additional information to correlate a WPD to its 312 proper network. For example, the MAC address of the network's 313 gateway (as discovered by ARP [RFC0826]) can be used to disambiguate 314 multiple instances of the same network. 316 3.5. forReferers 318 An array containing strings; each string is a host (as per [RFC3986] 319 Section 3.2.2). 321 When forReferers is present, Clients MUST use the WPD's proxies to 322 access these hosts, hostnames that have the host as a root, and for 323 traffic generated by that content. They MUST NOT be used for other 324 traffic. 326 This member is optional. 328 For example, if the value of forReferers is 330 [ "friendface.example.com" ] 331 then requests to "friendface.example.com", 332 "www.friendface.example.com", "app.friendface.example.com" etc. would 333 use the associated proxies; likewise, if processing a response from 334 one of these hosts generated further requests to "images.example.net" 335 and "scripts.example.org", they would also use the proxies. 337 Note that alwaysDirect takes precedence over forReferers. 339 TODO: tighten up what "processing" means here; the intent is to omit 340 a href 342 3.6. alwaysDirect 344 An array containing strings; each string is one of: 346 o a host (as per [RFC3986] Section 3.2.2), 348 o a classless prefix [RFC4632]. 350 o the string "CONNECT". 352 Clients MUST NOT use the WPD's proxies to access nominated hosts and 353 hostnames that have the a nominated host as its root. Likewise, 354 clients MUST NOT use the WPD's proxies to access bare IP addresses 355 that fall within the classless prefix. 357 If the string "CONNECT" (case-sensitive) appears in alwaysDirect, it 358 indicates that requests that require establishment of a tunnel (e.g., 359 for "https" URLs) MUST NOT use the WPD's proxies, but instead ought 360 to be made directly to the origin (i.e., without a tunnel). 362 Note that when a "bare" IP address or classless prefix is used in 363 alwaysDirect, clients are not required to perform a reverse lookup on 364 hostnames; these forms are only intended for accessing URLs that use 365 the IP-literal or IPv4address forms. 367 This member is optional. 369 For example, if the value of alwaysDirect is: 371 [ "example.com", "192.168.5/24" ] 373 then requests to "example.com", "www.example.com", "foo.example.com" 374 etc would not use any proxy. Likewise, requests whose URL authority 375 were bare IP addresses in the range 192.168.5.0 to 192.168.5.255 376 would not use any proxy. 378 3.7. failDirect 380 A boolean indicating whether the client should attempt to directly 381 access the origin server if all applicable proxies are unavailable. 383 When False, clients MUST NOT attempt to directly access the origin 384 server when no proxy is available, but instead SHOULD inform the user 385 that the proxy is unavailable. 387 When True, clients MAY do so. If failDirect is not present, clients 388 MAY default to this behavior. 390 3.8. exclusive 392 A boolean indicating whether the client is required to route all 393 network traffic through the proxy. 395 When True, clients MUST NOT initiate network traffic to any host 396 except a valid WPD (once its identity and location are established), 397 and MUST NOT allow network traffic from any host except valid WPDs. 398 This includes all traffic from and to the client, no matter how it is 399 generated or handled (e.g., browser "plug-ins"). 401 This directive is designed to accommodate privacy-enhancing proxies; 402 therefore, clients that cannot reasonably assure conformance to the 403 requirements in this section MUST NOT allow a WPD with this flag set 404 to be configured. 406 3.9. privateMode 408 A boolean indicating whether the client should be configured in 409 "private mode" when this WPD is active. 411 When True, clients SHOULD configure "private mode" browsing. 413 4. Discovering WPD Files 415 To facilitate easy configuration of WPD proxies, this specification 416 defines a well-known URI [RFC5785]. Doing so allows a proxy's 417 description to be found with a simple hostname; e.g., 418 "proxy.example.net" or even just "example.net". 420 Clients MUST NOT use the DHCP "WPAD" mechanism to discover WPDs. 422 4.1. The web-proxy-desc well-known URI 424 The "web-proxy-desc" well-known URI allows discovery of a Web Proxy 425 Description (Section 3). 427 This well-known URI is only valid when used with the "https" URI 428 Scheme [RFC7230]; it MUST NOT be used with "http" URIs. In other 429 words, WPD discovery is always protected by TLS [RFC5246]. 431 The description found at this location is considered valid for its 432 freshness lifetime, as defined in [RFC7234] Section 4.2. Once stale, 433 clients SHOULD refresh it and apply any changes. 435 If the WPD is not retrievable (e.g., a 404 response status), invalid 436 (as per JSON [RFC7159] or the requirements in Section 3), or its 437 certificate is not valid for the host (as per [RFC2818] Section 3.1), 438 the client MUST NOT use the WPD, and if a user agent, SHOULD inform 439 the end user. 441 The well-known URI MAY use proactive content negotiation ([RFC7231] 442 Section 3.4.1) to select an appropriate language for the response 443 representation. Therefore, clients SHOULD send an Accept-Language 444 request header field ([RFC7231] Section 5.3.5) when they wish to 445 advertise their configured language. 447 The registration template is: 449 o URI suffix: web-proxy-desc 451 o Change controller: IETF 453 o Specification document(s): [this document] 455 o Related information: only to be used with 'https' scheme 457 5. IANA Considerations 459 This specification registers a new well-known URI, as per [RFC5785]. 460 See Section 4.1 for the template. 462 6. Security Considerations 464 If a user can be convinced to configure a WPD hostname as their 465 proxy, that host can observe all unencrypted traffic by the client. 466 As such, WPD configuration interfaces ought only allow configuration 467 of proxies once their identity is validated (as required), and the 468 user ought to be given access to all relevant information about the 469 WPD proxy (i.e., 'name', 'desc' and 'moreInfo', the latter as a 470 link). Furthermore, WPD proxies ought only be configured as the 471 result of an intentional act, not as a side effect of normal Web 472 browsing. 474 7. Acknowledgements 476 Thanks to Patrick McManus for his feedback and suggestions. 478 8. References 480 8.1. Normative References 482 [I-D.ietf-httpbis-http2] 483 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 484 Protocol version 2", draft-ietf-httpbis-http2-14 (work in 485 progress), July 2014. 487 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 488 E. Lear, "Address Allocation for Private Internets", BCP 489 5, RFC 1918, February 1996. 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, March 1997. 494 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 496 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 497 Resource Identifier (URI): Generic Syntax", STD 66, RFC 498 3986, January 2005. 500 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 501 (CIDR): The Internet Address Assignment and Aggregation 502 Plan", BCP 122, RFC 4632, August 2006. 504 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 505 RFC 6761, February 2013. 507 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 508 February 2013. 510 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 511 "Special-Purpose IP Address Registries", BCP 153, RFC 512 6890, April 2013. 514 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 515 Interchange Format", RFC 7159, March 2014. 517 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 518 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 519 2014. 521 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 522 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 523 2014. 525 [W3C.CR-html5-20140731] 526 Berjon, R., Faulkner, S., Leithead, T., Navara, E., 527 O'Connor, E., and S. Pfeiffer, "HTML5", World Wide 528 Web Consortium CR CR-html5-20140731, July 2014, 529 . 531 8.2. Informative References 533 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 534 converting network protocol addresses to 48.bit Ethernet 535 address for transmission on Ethernet hardware", STD 37, 536 RFC 826, November 1982. 538 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 539 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 541 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 542 Uniform Resource Identifiers (URIs)", RFC 5785, April 543 2010. 545 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 546 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 548 [bad-proxy] 549 Chen, S., Mao, Z., Wang, Y., and M. Zhang, "Pretty-Bad- 550 Proxy: An Overlooked Adversary in Browsers' HTTPS 551 Deployments", January 2009, . 554 Appendix A. User Experience for WPDs 556 There are a variety of ways to present proxy configuration to users 557 and administrators, so this specification does not constrain how this 558 is done. That said, guidance for the common case (visual Web 559 browsers) can be helpful in assuring consistent user experience. 561 One of the core principles of this specification is that WPDs need to 562 be explicitly configured, either by the end user or an administrator 563 on their behalf. This is because using a proxy is a security- 564 sensitive operation; if an attacker can automatically configure a 565 proxy, or convince a user to do so as part of accessing a site, they 566 can gain access to the user's traffic, even when the user leaves the 567 attacking network. 569 Therefore, a user agent might allow configuration by entering a 570 hostname (e.g., "example.net"), whereupon it retrieves the WPD, 571 validates its certificate and contents, and present its information 572 to the end user for confirmation. 574 Once a WPD is confirmed, a user agent might "remember" it for future 575 use; e.g., by allowing quick configuration through a drop-down menu. 576 When a WPD nominates clientNetworks and the client does not have a 577 suitable IP address, the drop-down might make that option 578 unavailable. 580 It is envisioned that only a single WPD ought be configured at a 581 time; combining WPDs leads to ambiguity regarding precedence and 582 therefore user confusion. 584 When a WPD is active, its ought be visible to the end user, to remind 585 them of its presence, and to offer more information about the 586 configured proxy. 588 Author's Address 590 Mark Nottingham 592 Email: mnot@mnot.net 593 URI: http://www.mnot.net/