idnits 2.17.1 draft-frystyk-http-extensions-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == 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: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 443 has weird spacing: '...se when fulfi...' == Line 628 has weird spacing: '...pported proc...' == Line 631 has weird spacing: '...pported proc...' == Line 633 has weird spacing: '...cessing proce...' == Line 643 has weird spacing: '...pported exte...' == (3 more instances...) -- 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 (Mar 15, 1999) is 9167 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: '1' is defined on line 555, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 557, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (ref. '1') (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '2') ** Obsolete normative reference: RFC 2068 (ref. '5') (Obsoleted by RFC 2616) ** Downref: Normative reference to an Informational RFC: RFC 2324 (ref. '7') ** Obsolete normative reference: RFC 2396 (ref. '8') (Obsoleted by RFC 3986) -- No information found for draft-http-pep - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT HTTP Extensions H. Frystyk Nielsen, W3C 3 draft-frystyk-http-extensions-03 P. Leach, Microsoft 4 Scott Lawrence, Agranat Systems 5 Expires: Sep 15, 1999 Mon, Mar 15, 1999 7 HTTP Extension Framework 9 Status of this Document 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 24 Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 26 General information about this document is linked from 27 "http://www.w3.org/Protocols/HTTP/ietf-http-ext/". Send comments to 28 the mailing list. This list is archived at 29 "http://lists.w3.org/Archives/Public/ietf-http-ext/". 31 Abstract 33 A wide range of applications have proposed various extensions of the 34 HTTP protocol. Current efforts span an enormous range, including 35 distributed authoring, collaboration, printing, and remote procedure 36 call mechanisms. These HTTP extensions are not coordinated, since 37 there has been no standard framework for defining extensions and thus, 38 separation of concerns. This document describes a generic extension 39 mechanism for HTTP, which is designed to address the tension between 40 private agreement and public specification and to accommodate 41 extension of applications using HTTP clients, servers, and proxies. 42 The proposal associates each extension with a globally unique 43 identifier, and uses HTTP header fields to carry the extension 44 identifier and related information between the parties involved in the 45 extended communication. 47 Table of Contents 48 1. Introduction ...............................................2 49 2. Notational Conventions .....................................3 50 3. Extension Declarations .....................................3 51 3.1 Header Field Prefixes ...................................4 52 4. Extension Header Fields ....................................6 53 4.1 End-to-End Extensions ...................................6 54 4.2 Hop-by-Hop Extensions ...................................7 55 4.3 Extension Response Header Fields ........................7 56 5. Mandatory HTTP Requests ....................................8 57 5.1 Fulfilling a Mandatory Request ..........................9 58 6. Mandatory HTTP Responses ..................................10 59 7. 510 Not Extended ..........................................11 60 8. Publishing an Extension ...................................11 61 9. Caching Considerations ....................................12 62 10. Security Considerations ...................................13 63 11. References ................................................13 64 12. Acknowledgements ..........................................13 65 13. Authors Addresses .........................................14 66 14. Summary of Protocol Interactions ..........................14 67 15. Examples ..................................................15 68 15.1 User Agent to Origin Server ............................15 69 15.2 User Agent to Origin Server via HTTP/1.1 Proxy .........16 70 15.3 User Agent to Origin Server via HTTP/1.0 Proxy .........17 72 1. Introduction 74 This proposal is designed to address the tension between private 75 agreement and public specification; and to accommodate dynamic 76 extension of HTTP clients and servers by software components. The kind 77 of extensions capable of being introduced range from: 79 o extending a single HTTP message; 81 o introducing new encodings; 83 o initiating HTTP-derived protocols for new applications; to... 85 o switching to protocols which, once initiated, run independent of 86 the original protocol stack. 88 The proposal is intended to be used as follows: 90 o Some party designs and specifies an extension; the party assigns 91 the extension a globally unique URI, and makes one or more 92 representations of the extension available at that address (see 93 section 8). 95 o An HTTP client or server that implements this extension mechanism 96 (hereafter called an agent) declares the use of the extension by 97 referencing its URI in an extension declaration in an HTTP 98 message (see section 3). 100 o The HTTP application which the extension declaration is intended 101 for (hereafter called the ultimate recipient) can deduce how to 102 properly interpret the extended message based on the extension 103 declaration. 105 The proposal uses features in HTTP/1.1 but is compatible with HTTP/1.0 106 applications in such a way that extended applications can coexist with 107 existing HTTP applications. Applications implementing this proposal 108 MUST be based on HTTP/1.1 (or later versions of HTTP). 110 2. Notational Conventions 112 This specification uses the same notational conventions and basic 113 parsing constructs as RFC 2068 [5]. In particular the BNF constructs 114 "token", "quoted-string", "Request-Line", "field-name", and 115 "absoluteURI" in this document are to be interpreted as described in 116 RFC 2068 [5]. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [6]. 122 This proposal does not rely on particular features defined in URLs [8] 123 that cannot potentially be expressed using URNs (see section 8). 124 Therefore, the more generic term URI [8] is used throughout the 125 specification. 127 3. Extension Declarations 129 An extension declaration can be used to indicate that an extension has 130 been applied to a message and possibly to reserve a part of the header 131 namespace identified by a header field prefix (see 3.1). This section 132 defines the extension declaration itself; section 4 defines a set of 133 header fields using the extension declaration. 135 This specification does not define any ramifications of applying an 136 extension to a message nor whether two extensions can or cannot 137 logically coexist within the same message. It is simply a framework 138 for describing which extensions have been applied and what the 139 ultimate recipient either must or may do in order to properly 140 interpret any extension declarations within that message. 142 The grammar for an extension declaration is as follows: 144 ext-decl = <"> ( absoluteURI | field-name ) <"> 145 [ namespace ] [ decl-extensions ] 147 namespace = ";" "ns" "=" header-prefix 148 header-prefix = 2*DIGIT 150 decl-extensions = *( decl-ext ) 151 decl-ext = ";" token [ "=" ( token | quoted-string ) ] 153 An extension is identified by an absolute, globally unique URI or a 154 field-name. A field-name MUST specify a header field uniquely defined 155 in an IETF Standards Track RFC [3]. A URI can unambiguously be 156 distinguished from a field-name by the presence of a colon (":"). 158 The support for header field names as extension identifiers provides a 159 transition strategy from decentralized extensions to extensions 160 defined by IETF Standards Track RFCs until a mapping between the 161 globally unique URI space and features defined in IETF Standards Track 162 RFCs has been defined according to the guidelines described in section 163 8. 165 Examples of extension declarations are 167 "http://www.company.com/extension"; ns=11 168 "Range" 170 An agent MAY use the decl-extensions mechanism to include optional 171 extension declaration parameters but cannot assume these parameters to 172 be recognized by the recipient. An agent MUST NOT use decl-extensions 173 to pass extension instance data, which MAY be passed using header 174 field prefix values (see section 3.1). Unrecognized decl-ext 175 parameters SHOULD be ignored and MUST NOT be removed by proxies when 176 forwarding the extension declaration. 178 3.1 Header Field Prefixes 180 The header-prefix is a dynamically generated string. All header fields 181 in the message that match this string, using string prefix-matching, 182 belong to that extension declaration. Header field prefixes allow an 183 extension declaration to dynamically reserve a subspace of the header 184 space in a protocol message in order to prevent header field name 185 clashes and to allow multiple declarations using the same extension to 186 be applied to the same message without conflicting. 188 Header fields using a header-prefix are of the form: 190 prefixed-header = prefix-match field-name 191 prefix-match = header-prefix "-" 193 Linear white space (LWS) MUST NOT be used between the header-prefix 194 and the dash ("-") or between the prefix-match and the field-name. The 195 string prefix matching algorithm is applied to the prefix-match 196 string. 198 The format of the prefix using a combination of digits and the dash 199 ("-") guarantees that no extension declaration can reserve the whole 200 header field name space. The header-prefix mechanism was preferred 201 over other solutions for exchanging extension instance parameters 202 because it is header based and therefore allows for easy integration 203 of new extensions with existing HTTP features. 205 Agents MUST NOT reuse header-prefix values in the same message unless 206 explicitly allowed by the extension (see section 4.1 for a discussion 207 of the ultimate recipient of an extension declaration). 209 Clients SHOULD be as consistent as possible when generating header- 210 prefix values as this facilitates use of the Vary header field in 211 responses that vary as a function of the request extension 212 declaration(s) (see [5], section 13.6). 214 Servers including prefixed-header header fields in a Vary header field 215 value MUST also include the corresponding extension declaration field- 216 name as part of that value. For example, if a response depends on the 217 value of the 16-use-transform header field defined by an optional 218 extension declaration in the request, the Vary header field in the 219 response could look like this: 221 Vary: Opt, 16-use-transform 223 Note, that header-prefix consistency is no substitute for including an 224 extension declaration in the message: header fields with header-prefix 225 values not defined by an extension declaration in the same message are 226 not defined by this specification. 228 Examples of header-prefix values are 229 12 230 15 231 23 233 Old applications may introduce header fields independent of this 234 extension mechanism, potentially conflicting with header fields 235 introduced by the prefix mechanism. In order to minimize this risk, 236 prefixes MUST contain at least 2 digits. 238 4. Extension Header Fields 240 This proposal introduces two types of extension declaration strength: 241 mandatory and optional, and two types of extension declaration scope: 242 hop-by-hop and end-to-end (see section 4.1 and 4.2). 244 A mandatory extension declaration indicates that the ultimate 245 recipient MUST consult and adhere to the rules given by the extension 246 when processing the message or reporting an error (see section 5 and 247 7). 249 An optional extension declaration indicates that the ultimate 250 recipient of the extension MAY consult and adhere to the rules given 251 by the extension when processing the message, or ignore the extension 252 declaration completely. An agent may not be able to distinguish 253 whether the ultimate recipient does not understand an extension 254 referred to by an optional extension or simply ignores the extension 255 declaration. 257 The combination of the declaration strength and scope defines a 2x2 258 matrix which is distinguished by four new general HTTP header fields: 259 Man, Opt, C-Man, and C-Opt. (See sections 4.1 and 4.2; also see 260 appendix 14, which has a table of interactions with origin servers and 261 proxies.) 263 The header fields are general header fields as they describe which 264 extensions actually are applied to an HTTP message. Optional 265 declarations MAY be applied to any HTTP message if appropriate (see 266 section 5 for how to apply mandatory extension declarations to 267 requests and section 6 for how to apply them to responses). 269 4.1 End-to-End Extensions 271 End-to-end declarations MUST be transmitted to the ultimate recipient 272 of the declaration. The Man and the Opt general header fields are end- 273 to-end header fields and are defined as follows: 275 mandatory = "Man" ":" 1#ext-decl 276 optional = "Opt" ":" 1#ext-decl 278 For example 280 HTTP/1.1 200 OK 281 Content-Length: 421 282 Opt: "http://www.digest.org/Digest"; ns=15 283 15-digest: "snfksjgor2tsajkt52" 284 ... 286 The ultimate recipient of a mandatory end-to-end extension declaration 287 MUST handle that extension declaration as described in section 5 and 288 6. 290 4.2 Hop-by-Hop Extensions 292 Hop-by-hop extension declarations are meaningful only for a single 293 HTTP connection. In HTTP/1.1, C-Man, C-Opt, and all header fields with 294 matching header-prefix values defined by C-Man and C-Opt MUST be 295 protected by a Connection header field. That is, these header fields 296 are to be included as Connection header field directives (see [5], 297 section 14.10). The two header fields have the following grammar: 299 c-mandatory = "C-Man" ":" 1#ext-decl 300 c-optional = "C-Opt" ":" 1#ext-decl 302 For example 304 M-GET / HTTP/1.1 305 Host: some.host 306 C-Man: "http://www.digest.org/ProxyAuth"; ns=14 307 14-Credentials="g5gj262jdw@4df" 308 Connection: C-Man, 14-Credentials 310 The ultimate recipient of a mandatory hop-by-hop extension declaration 311 MUST handle that extension declaration as described in section 5 and 312 6. 314 4.3 Extension Response Header Fields 316 Two extension response header fields are used to indicate that a 317 request containing mandatory extension declarations has been fulfilled 318 by the ultimate recipient as described in section 5.1. The extension 319 response header fields are exclusively intended to serve as extension 320 acknowledgements, and can not carry any other information. 322 The Ext header field is used to indicate that all end-to-end mandatory 323 extension declarations in the request were fulfilled: 325 ext = "Ext" ":" 327 The C-Ext response header field is used to indicate that all hop-by- 328 hop mandatory extension declarations in the request were fulfilled. 330 c-ext = "C-Ext" ":" 332 In HTTP/1.1, the C-Ext header fields MUST be protected by a Connection 333 header (see [5], section 14.10). 335 The Ext and the C-Ext header fields are not mutually exclusive; they 336 can both occur within the same message as described in section 5.1. 338 5. Mandatory HTTP Requests 340 An HTTP request is called a mandatory request if it includes at least 341 one mandatory extension declaration (using the Man or the C-Man header 342 fields). The method name of a mandatory request MUST be prefixed by 343 "M-". For example, a client might express the binding rights- 344 management constraints in an HTTP PUT request as follows: 346 M-PUT /a-resource HTTP/1.1 347 Man: "http://www.copyright.org/rights-management"; ns=16 348 16-copyright: http://www.copyright.org/COPYRIGHT.html 349 16-contributions: http://www.copyright.org/PATCHES.html 350 Host: www.w3.org 351 Content-Length: 1203 352 Content-Type: text/html 354