idnits 2.17.1 draft-ietf-http-options-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 3 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 67: '...ative A: proxies MUST NOT modify Allow...' RFC 2119 keyword, line 68: '...ative B: proxies MUST modify Allow/Pub...' RFC 2119 keyword, line 152: '...roxy on the request chain MUST forward...' RFC 2119 keyword, line 168: '...nse is an error, the response MUST NOT...' RFC 2119 keyword, line 175: '... OPTIONS request MAY include Complianc...' (37 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (26 August 1997) is 9739 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 77 looks like a reference -- Missing reference section? '1' on line 90 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group J. Mogul, DECWRL, 3 Internet-Draft J. Cohen, Netscape, 4 Expires: 28 February 1998 S. Lawrence, Agranat Systems 5 26 August 1997 7 Specification of HTTP/1.1 OPTIONS messages 9 draft-ietf-http-options-02.txt 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft. Internet-Drafts are 14 working documents of the Internet Engineering Task Force 15 (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by 21 other documents at any time. It is inappropriate to use 22 Internet-Drafts as reference material or to cite them other 23 than as "work in progress." 25 To learn the current status of any Internet-Draft, please 26 check the "1id-abstracts.txt" listing contained in the 27 Internet-Drafts Shadow Directories on ftp.is.co.za 28 (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific 29 Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US 30 West Coast). 32 Distribution of this document is unlimited. Please send 33 comments to the HTTP working group at 34 . Discussions of the working 35 group are archived at 36 . General 37 discussions about HTTP and the applications which use HTTP 38 should take place on the mailing list. 40 ABSTRACT 42 RFC2068 defined a new OPTIONS method for HTTP/1.1. The 43 purpose of OPTIONS is to allow a 'client to determine the 44 options and/or requirements associated with a resource, or 45 the capabilities of a server, without implying a resource 46 action or initiating a resource retrieval.' However, 47 RFC2068 did not defined a specific syntax for using OPTIONS 48 to make such a determination. This proposal clarifies the 49 original specification of OPTIONS, adds several new HTTP 50 message headers to provide syntactic support for OPTIONS, 51 and establishes new IANA registries to avoid namespace 52 conflicts. 54 Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 56 TABLE OF CONTENTS 58 1 Introduction 2 59 2 Outline of proposed solution 2 60 3 Proposed solution 3 61 3.1 Changes to section 5.1.2, Request-URI 3 62 3.2 Changes to section 9.2, OPTIONS 4 63 3.3 Changes to section 14.31, Max-Forwards 6 64 3.4 The Compliance header 6 65 3.5 The Non-Compliance header 9 66 3.6 Changes to sections 14.7 and 14.35, Allow and Public 10 67 3.6.1 Alternative A: proxies MUST NOT modify Allow/Public 11 68 3.6.2 Alternative B: proxies MUST modify Allow/Public 12 69 3.7 Examples 12 70 4 Security Considerations 13 71 5 Acknowledgements 13 72 6 References 13 73 7 Authors' addresses 14 75 1 Introduction 77 Section 9.2 of RFC2068 [2] defines an OPTIONS method, to allow a 78 "client to determine the options and/or requirements associated with 79 a resource, or the capabilities of a server, without implying a 80 resource action or initiating a resource retrieval." For example, a 81 client may wish to determine if a particular HTTP method is supported 82 by a server, or for a specific resource. Or, a client may wish to 83 determine if a server supports the use of a particular HTTP 84 request-header. 86 The description of OPTIONS in RFC2068 has left some implementors 87 confused about what is required, and does not provide a specific 88 syntax for determining support for specific options or extensions. 89 While some of this might be obviated in the future by the Protocol 90 Extension Protocol (PEP) [1], there exists an immediate need to 91 define a simple and well-specified OPTIONS mechanism for HTTP/1.1. 93 2 Outline of proposed solution 95 - The intended recipient of an OPTIONS request may be any 96 server (including proxies) along the request path. RFC2068 97 supported this by requiring a transformation of the 98 request-URI for a set of methods (actually, only for 99 OPTIONS); in the current proposal, one can either use the 100 Host header to address a specific server or proxy, or the 101 Max-Forwards header to address the Nth server on a path. 103 - As in RFC2068, the URI '*' refers to the server, 104 independent of any specific resource. Any other URI refers 105 to the resource normally identified by that URI. 107 Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 109 - The descriptions of the Allow and Public headers, and of 110 the OPTIONS method, are made consistent in their 111 requirements for proxy editing of OPTIONS responses. (In 112 RFC2068, these sections were contradictory). 114 - A (new) Compliance header is proposed, which allows a 115 client to specify exactly what options it is asking about, 116 and which allows a server to specify exactly what subset of 117 those options are supported. 119 Discussion question: it might make more sense to use two 120 different header names, one for requests and one for 121 responses, to clarify that in a request, the client 122 is asking the server about its supported options, and 123 in a response, the server is stating its supported 124 options. 126 - The Compliance header allows several namespaces for 127 options; the set of namespaces is under IANA control. One 128 namespace is that of IETF-issued RFCs; this allows a more 129 specific definition of compliance than is available using 130 protocol version numbers. While various interpretations 131 can and do exist about the specific meaning of a protocol 132 version number (such as "HTTP/1.1"), the meaning of an RFC 133 is both well-defined and (more important) immutable. 135 - A (new) Non-Compliance header is proposed, allowing a proxy 136 processing an OPTIONS response to indicate its 137 non-compliance with one or more options, and without 138 requiring the proxy to edit the rest of the response (which 139 would result in loss of information). 141 3 Proposed solution 143 Here we propose specific changes to RFC2068. 145 3.1 Changes to section 5.1.2, Request-URI 146 Remove this: 148 Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 150 If a proxy receives a request without any path in the Request-URI 151 and the method specified is capable of supporting the asterisk form 152 of request, then the last proxy on the request chain MUST forward 153 the request with "*" as the final Request-URI. For example, the 154 request 156 OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1 158 would be forwarded by the proxy as 160 OPTIONS * HTTP/1.1 161 Host: www.ics.uci.edu:8001 163 after connecting to port 8001 of host "www.ics.uci.edu". 165 3.2 Changes to section 9.2, OPTIONS 166 Replace: 168 Unless the server's response is an error, the response MUST NOT 169 include entity information other than what can be considered as 170 communication options (e.g., Allow is appropriate, but Content-Type 171 is not). Responses to this method are not cachable. 173 with: 175 An OPTIONS request MAY include Compliance headers (see section 176 14.ZZZ) that indicate the set of options the sender wants 177 information about. 179 Responses to OPTIONS are not cachable, unless caching is explicitly 180 allowed by the server that first sent the OPTIONS reply (see section 181 13.4). 183 Replace: 185 If the Request-URI is an asterisk ("*"), the OPTIONS request is 186 intended to apply to the server as a whole. A 200 response SHOULD 187 include any header fields which indicate optional features 188 implemented by the server (e.g., Public), including any extensions 189 not defined by this specification, in addition to any applicable 190 general or response-header fields. As described in section 5.1.2, an 191 "OPTIONS *" request can be applied through a proxy by specifying the 192 destination server in the Request-URI without any path information. 194 with: 196 Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 198 If the Request-URI is an asterisk ("*"), the OPTIONS request is 199 intended to apply to the server as a whole. A 200 response SHOULD 200 include a Public header field (see section 14.35). If the request 201 includes a Compliance header field, a 200 response SHOULD include a 202 Compliance header field, indicating the subset of the requested 203 Compliance options supported by the server as a whole. The response 204 SHOULD include any other applicable general or response-header 205 fields. 207 If an OPTIONS request includes a Host header (see section 14.23), 208 this is the intended destination of the OPTIONS method. 209 Proxy servers MUST forward such a message until it reaches 210 the specified host. If the specified host has more than 211 one `virtual server', the OPTIONS request applies to the 212 specified virtual server. 214 Note: An OPTIONS request may also include a Max-Forwards header, 215 as described in section 14.31. This allows the sender to select 216 the Nth proxy on a path, without knowing its hostname. 218 Replace: 220 If the Request-URI is not an asterisk, the OPTIONS request applies 221 only to the options that are available when communicating with that 222 resource. A 200 response SHOULD include any header fields which 223 indicate optional features implemented by the server and applicable 224 to that resource (e.g., Allow), including any extensions not defined 225 by this specification, in addition to any applicable general or 226 response-header fields. If the OPTIONS request passes through a 227 proxy, the proxy MUST edit the response to exclude those options 228 which apply to a proxy's capabilities and which are known to be 229 unavailable through that proxy. 231 with: 233 Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 235 If the Request-URI is not an asterisk, the OPTIONS request applies 236 only to the options that are available when communicating with that 237 resource. A 200 response SHOULD include an Allow header field (see 238 section 14.7). If the request includes a Compliance header field, a 239 200 response SHOULD include a Compliance header field, indicating 240 the subset of the requested Compliance options supported by the 241 server as a whole. If the subset is empty, the response SHOULD 242 include a Compliance header with an empty field-value. The response 243 SHOULD include any other applicable general or response-header 244 fields. 246 Note: if an OPTION request contains a Compliance header, and the 247 response does not, the response may have been generated by 248 RFC2068-compliant implementation, which would not support 249 Compliance. In this case, it is not possible to infer that the 250 sender fails to support all of the options listed in the 251 Compliance header of the request. 253 If the OPTIONS request passes through a 254 proxy, the proxy SHOULD add a Non-Compliance header field (see 255 section 14.QQQ) to the response, to list those options that apply to 256 a proxy's capabilities and that are known to be unavailable through 257 that proxy. 259 3.3 Changes to section 14.31, Max-Forwards 260 Replace: 262 Each proxy or gateway recipient of a TRACE request containing a Max- 263 Forwards header field SHOULD check and update its value prior to 264 forwarding the request. 266 with: 268 Each proxy or gateway recipient of a TRACE or OPTIONS request 269 containing a Max-Forwards header field SHOULD check and update its 270 value prior to forwarding the request. 272 3.4 The Compliance header 273 Insert in section 14, as a new subsection titled ``14.ZZZ 274 Compliance'' 276 Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 278 The Compliance general header field lists a set of options 279 that may or may not be supported by a server. In a request 280 message, this header lists the set of options that a client 281 wishes to know about. In a response message, this header 282 lists the subset of the requested options that the server 283 complies with. 285 A compliance header MAY appear on any message, but is 286 normally used with the OPTIONS request (see section 9.2). 288 Compliance = "Compliance" ":" ("*" | #(compliance-option)) 290 compliance-option = compliance-namespace "=" 291 option-item [ option-params ] 293 compliance-namespace = token 295 option-item = token | quoted-string 296 | rfc-option-item | hdr-option-item 298 option-params = 1*( ";" option-param) 300 option-param = "cond" | "uncond" | token | quoted-string 302 A Compliance header field with the field-value of "*" MAY 303 be used in a request, to ask about all options complied 304 with by the recipient. This field-value MUST NOT be used 305 in a response. 307 When the Compliance header is present in a response, it takes 308 priority over an Allow header or a Public header in the same 309 response. 311 Tokens used for compliance-namespace, option-item, and 312 option-param values are case-insensitive. 314 The compliance-namespace is used to select from one of several 315 namespaces for compliance options. The option-item is used 316 to specify one or more options within a namespace. 318 Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 320 The Internet Assigned Numbers Authority (IANA) acts as a registry 321 for compliance-namespace tokens. Initially, the registry contains 322 the following tokens: 324 "RFC" Compliance is with an RFC, specified by an RFC number. 325 For example, "rfc=1945". 327 rfc-option-item = "RFC" "=" RFC-number 328 RFC-number = 1*DIGIT 330 Leading zeroes are permitted and ignored in 331 RFC-number (i.e., comparisons are numeric). 333 "HDR" Compliance is with a named HTTP header. For example, 334 "HDR=Authorization". There is no IANA registry for 335 HTTP header names, but to avoid potential namespace 336 confusion, only those HTTP headers listed in an 337 IETF standards-track document should be used in 338 this namespace. 340 hdr-option-item = "HDR" "=" field-name 342 An implementation SHOULD NOT send option-param values other 343 than "cond" or "uncond" with an rfc-option-item or a 344 hdr-option-item. 346 The option-param is used to provide additional parameters. 347 Unconditional compliance with a compliance-option is indicated 348 using the "uncond" option-param; for example, "rfc=1945;uncond". 349 Conditional compliance is indicated using the "cond" option-param; 350 for example, "HDR=Authorization;uncond". Additional option-param 351 values might be defined as part of another specification. 353 For the purposes of this header field, an implementation that 354 satisfies all the MUST and all the SHOULD requirements for its 355 protocols is defined as "unconditionally compliant"; one that 356 satisfies all the MUST requirements but not all the SHOULD 357 requirements for its protocols is defined as "conditionally 358 compliant." See also RFC2119 for a discussion of the terms MUST 359 and SHOULD. 361 Examples: 363 Compliance: rfc=2068;uncond 364 Compliance: rfc=1945;uncond, rfc=2068;cond 365 Compliance: rfc=2068, hdr=SetCookie2 367 Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 369 Note: when a resource is implemented using a subprogram 370 outside the control of the server itself (such as a CGI 371 application), and the server cannot ensure that this 372 implementation of the resource will comply with a requested 373 option, the server's Compliance response-header for the 374 resource ought not to assert compliance with the option. 375 That is, in case of uncertainty, it is better to imply 376 non-compliance when the implementation might comply, than 377 to claim compliance when the implementation might not comply. 379 3.5 The Non-Compliance header 380 Insert in section 14, as a new subsection titled ``14.QQQ 381 Non-Compliance'' 383 A proxy server SHOULD add this response-header to a response 384 containing a Compliance header if the proxy does not implement one 385 or more of the options described in the Compliance header. 387 Non-Compliance = "Non-Compliance" ":" 1#non-compliance-option 389 proxy-host = host [ ":" port ] 391 non-compliance-option = compliance-option "@" proxy-host 393 Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 395 A non-compliance-option listed in a Non-Compliance response-header 396 field indicates that the proxy server named by the proxy-host value 397 does not support the listed compliance-option. The set of 398 non-compliance options SHOULD be a subset of the compliance-options 399 listed in a Compliance header field of the forwarded message. 401 Note: because the proxy-host value is not authenticated, 402 this is only for advisory purposes (e.g., for debugging). 404 If the compliance-option in a non-compliance-option includes one or 405 more option-param(s) (see section 14.ZZZ), then the proxy server's 406 non-compliance is limited to the scope of the option-param(s). If 407 the compliance-option does not include an option-param, then the 408 proxy server is asserting non-compliance with the option in 409 general. 411 For example, a response with: 413 Compliance: rfc=9999;uncond 414 Non-Compliance: rfc=9999;uncond@proxy.foo.net 416 states that proxy.foo.net is not unconditionally compliant with 417 RFC9999, but does not imply that proxy.foo.net is not 418 conditionally compliant with RFC9999. If the proxy is not even 419 conditionally compliant with RFC9999, it should instead send 421 Compliance: rfc=9999;uncond 422 Non-Compliance: rfc=9999@proxy.foo.net 424 when forwarding the response. 426 A proxy MUST NOT delete a Non-Compliance header that it has 427 received from another server. 429 3.6 Changes to sections 14.7 and 14.35, Allow and Public 430 The problem we address here is that RFC2068's specifications for the 431 Allow and Public headers are inconsistent as to whether a proxy 432 "MUST" or "MUST NOT" edit them. We believe that they should be 433 consistent. Given that, there are arguments for either alternative: 435 - Requiring proxies to edit these headers provides the 436 ultimate client with a simple way to determine if a method 437 is allowed along the entire path to the origin server. 439 - However, requiring proxies not to edit these headers allows 440 a client to find out about the capabilities of the origin 441 server, since (as RFC2068 says about the Allow header) "the 442 user agent may have other means of communicating with the 443 origin server." 445 The second alternative seems more robust. Although we do not 447 Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 449 currently have an efficient mechanism for finding out if a method is 450 supported along the entire path, presumbly any request using an 451 unsupported method would immediately be rejected. However, we list 452 both alternatives in the hope that further discussion will lead to a 453 more satisfying solution. 455 Note: one possibility, not yet explored in detail, is that the 456 compliance-namespace could be extended to include a "METH" 457 token, allowing the Compliance header (and hence the 458 Non-Compliance header) to completely replace the Allow and 459 Public headers. E.g., the client could send 461 Compliance: METH=* 463 to which the origin server might respond 465 Compliance: METH=GET,METH=PUT,METH=HEAD 467 If this passes through a proxy that bans (e.g.) PUT, the proxy 468 could forward the response as 470 Compliance: METH=GET,METH=PUT,METH=HEAD 471 Non-Compliance: METH=PUT@roproxy.net 473 3.6.1 Alternative A: proxies MUST NOT modify Allow/Public 474 In section 14.35 (Public), replace 476 This header field applies only to the server directly connected to 477 the client (i.e., the nearest neighbor in a chain of connections). 478 If the response passes through a proxy, the proxy MUST either remove 479 the Public header field or replace it with one applicable to its own 480 capabilities. 482 with: 484 A proxy MUST NOT modify the Public header field even if it does not 485 understand all the methods specified, since the user agent might 486 have other means of communicating with the origin server. 488 Also, in section 14.7 (Allow), replace 490 A proxy MUST NOT modify the Allow header field even if it does not 491 understand all the methods specified, since the user agent MAY have 492 other means of communicating with the origin server. 494 with: 496 A proxy MUST NOT modify the Allow header field even if it does not 497 understand all the methods specified, since the user agent might 498 have other means of communicating with the origin server. 500 (removes an incorrect use of the term "MAY"). 502 Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 504 3.6.2 Alternative B: proxies MUST modify Allow/Public 505 In section 14.7 (Allow), replace 507 A proxy MUST NOT modify the Allow header field even if it does not 508 understand all the methods specified, since the user agent MAY have 509 other means of communicating with the origin server. 511 with: 513 A proxy MUST remove methods from an Allow header field if it 514 does not support the use of those methods for the resource 515 identified by the Request-URI. 517 and in section 14.35 (Public), replace this paragraph: 519 This header field applies only to the server directly connected to 520 the client (i.e., the nearest neighbor in a chain of connections). 521 If the response passes through a proxy, the proxy MUST either remove 522 the Public header field or replace it with one applicable to its own 523 capabilities. 525 with: 527 A proxy MUST remove methods from a Public header field if it 528 does not support the use of those methods. 530 3.7 Examples 532 To list all extensions supported by proxy "proxy4.example.com" 534 Client sends: 535 OPTIONS * HTTP/1.1 536 Host: proxy4.example.com 537 Compliance: * 539 proxy4.example.com responds: 540 HTTP/1.1 200 OK 541 Date: Tue, 22 Jul 1997 20:21:51 GMT 542 Server: SuperProxy/1.0 543 Public: OPTIONS, GET, HEAD, PUT, POST, TRACE 544 Compliance: rfc=1543, rfc=2068, hdr=set-proxy 545 Compliance: hdr=wonder-bar-http-widget-set 546 Content-Length: 0 548 Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 550 Probing for a feature which is not supported by 551 "proxy4.example.com" 553 Client sends: 554 OPTIONS * HTTP/1.1 555 Host: proxy4.example.com 556 Compliance: HDR=TimeTravel 558 proxy4.example.com responds: 559 HTTP/1.1 200 OK 560 Date: Tue, 22 Jul 1997 20:21:52 GMT 561 Server: SuperProxy/1.0 562 Public: OPTIONS, GET, HEAD, PUT, POST, TRACE 563 Compliance: 564 Content-Length: 0 566 4 Security Considerations 568 Because the proxy-host value in a Non-Compliance header is not 569 authenticated, in theory, a malicious proxy along the path could 570 insert a Non-Compliance header with the name of some other proxy, 571 perhaps one not even involved in the response. However, because the 572 proxy-host value is used only for advisory purposes (e.g., for 573 debugging), there does not appear to be a serious security problem 574 with this lack of authentication. 576 Besides, any proxy along the request/response path for an HTTP 577 interaction is able to perform far more disruptive (and far less 578 easily detected) modifications of the messages it forwards; this 579 proposal does not change that. 581 5 Acknowledgements 583 We would like to thank Roy Fielding, Jim Gettys, Paul Leach, Larry 584 Masinter, Henrik Frystyk Nielsen, Ross Patterson, and Jim Whitehead 585 for help in constructing this proposal. 587 6 References 589 1. D. Connolly, R. Khare, H. Frystyk Nielsen. PEP - an Extension 590 Mechanism for HTTP. Internet Draft draft-ietf-http-pep-04, HTTP 591 Working Group, July, 1997. This is a work in progress. 593 2. Roy T. Fielding, Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk 594 Nielsen, and Tim Berners-Lee. Hypertext Transfer Protocol -- 595 HTTP/1.1. RFC 2068, HTTP Working Group, January, 1997. 597 Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58 599 7 Authors' addresses 601 Jeffrey C. Mogul 602 Western Research Laboratory 603 Digital Equipment Corporation 604 250 University Avenue 605 Palo Alto, California, 94305, USA 606 Email: mogul@wrl.dec.com 608 Josh Cohen 609 Netscape Communications Corporation 610 501 E. Middlefield Rd 611 Mountain View, CA 94043 612 Phone (415) 937-4157 613 EMail: josh@netscape.com 615 Scott Lawrence 616 Agranat Systems, Inc. 617 1345 Main St. 618 Waltham, MA 02154 619 Phone: +1-617-893-7868 620 Fax: +1-617-893-5740 621 Email: lawrence@agranat.com