idnits 2.17.1 draft-frystyk-http-extensions-00.txt: -(356): 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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) 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 6 months document validity. ** 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. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 11) being 68 lines 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 193 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 85 has weird spacing: '... The propo...' == Line 265 has weird spacing: '...ncluded as...' == Line 324 has weird spacing: '...e proxy that ...' == Line 332 has weird spacing: '...sult of disca...' == Line 522 has weird spacing: '...pported proce...' == (6 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 (August 07, 1998) is 9365 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: '5' is defined on line 455, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 468, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 471, 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 1630 (ref. '2') ** Obsolete normative reference: RFC 1738 (ref. '3') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1808 (ref. '4') (Obsoleted by RFC 3986) ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '5') ** Obsolete normative reference: RFC 2068 (ref. '7') (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 2111 (ref. '8') (Obsoleted by RFC 2392) -- Possible downref: Normative reference to a draft: ref. '10' -- No information found for draft-http-pep - is the name correct? -- Possible downref: Normative reference to a draft: ref. '11' -- Possible downref: Normative reference to a draft: ref. '12' Summary: 17 errors (**), 0 flaws (~~), 14 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Mandatory H. Frystyk Nielsen, W3C 3 draft-frystyk-http-extensions-00 P. Leach, Microsoft 4 Scott Lawrence, Agranat Systems 5 Expires: February 07, 1999 Friday, August 07, 1998 7 HTTP Extension Framework 8 for 9 Mandatory and Optional Extensions 11 Status of this Document 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. Internet-Drafts are draft 17 documents valid for a maximum of six months and may be updated, 18 replaced, or obsoleted by other documents at any time. It is 19 inappropriate to use Internet-Drafts as reference material or to cite 20 them other than as "work in progress". 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. Please send comments to 29 the mailing list. This list is archived at 30 "http://lists.w3.org/Archives/Public/ietf-http-ext/". 32 The contribution of World Wide Web Consortium (W3C) staff is part of 33 the W3C HTTP Activity (see "http://www.w3.org/Protocols/Activity"). 35 Abstract 37 HTTP is used increasingly in applications that need more facilities 38 than the standard version of the protocol provides, ranging from 39 distributed authoring, collaboration, and printing, to various remote 40 procedure call mechanisms. This document proposes the use of a 41 mandatory extension mechanism designed to address the tension between 42 private agreement and public specification and to accommodate 43 extension of applications such as HTTP clients, servers, and proxies. 44 The proposal associates each extension with a URI[2], and use a few 45 new RFC 822[1] style header fields to carry the extension identifier 46 and related information between the parties involved in an extended 47 transaction. 49 Table of Contents 51 1. Introduction.....................................................2 52 2. Notational Conventions...........................................3 53 3. Extension Declarations...........................................3 54 3.1 Header Field Prefixes.........................................4 55 4. Extension Header Fields..........................................4 56 4.1 End-to-End Extensions.........................................5 57 4.2 Hop-by-Hop Extensions.........................................5 58 5. Mandatory HTTP Requests..........................................6 59 6. Mandatory HTTP Responses.........................................7 60 7. 102 Extended.....................................................7 61 8. 510 Not Extended.................................................8 62 9. Publishing an Extension..........................................8 63 10. Security Considerations.........................................9 64 11. References......................................................9 65 12. Acknowledgements...............................................10 66 13. Authors Addresses..............................................10 67 14. Summary of Protocol Interactions...............................11 68 15. Examples.......................................................11 69 15.1 Client Requests Server to use an Extension..................12 70 15.2 Server proposes the use of an Extension.....................12 72 1. Introduction 74 The mandatory proposal is designed to accommodate dynamic extension of 75 HTTP clients and servers by software components; and to address the 76 tension between private agreement and public specification. The kind 77 of extensions capable of being introduced range from: 79 o extending a single HTTP message; 80 o introducing new encodings; 81 o initiating HTTP-derived protocols for new applications; to... 82 o switching to protocols which, once initiated, run independent of 83 the original protocol stack. 85 The proposal is intended to be used as follows: 87 o Some party designs and specifies an extension; the party assigns 88 the extension an identifier, which is a URI, and makes one or 89 more representations of the extension available at that address 90 (see section 9). 91 o An HTTP client, server, or proxy that implements the Mandatory 92 extension mechanism (hereafter called an agent) declares the use 93 of the extension by referencing its URI in an extension 94 declaration in an HTTP message (see section 3). 95 o The ultimate recipient of the extension declaration which can be 96 the origin server, the user agent, or any intermediary in the 97 request/response chain can based on the extension declaration 98 deduce how to properly interpret the extended message. 100 The proposal uses features in HTTP/1.1 but is compatible with both 101 HTTP/1.0 and HTTP/1.1 applications in such a way that extended 102 applications can coexist with existing HTTP applications. 104 By providing a more robust framework for describing extensions, this 105 proposal supersedes several existing extension mechanisms like the 106 HTTP/1.1 Expect and Upgrade header fields as well as avoids existing 107 problems with non-compliant CGI scripts handling unknown HTTP methods. 109 2. Notational Conventions 111 This specification uses the same notational conventions and basic 112 parsing constructs as RFC 2068[7]. In particular the BNF constructs 113 "token", "quoted-string", "field-name", and "URI" in this document are 114 to be interpreted as described in RFC 2068[7]. 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119[9]. 120 This proposal does not rely on particular features defined in URLs [3] 121 that cannot potentially be expressed using URNs (see section 9). 122 Therefore, the more generic term URI[2] is used throughout the 123 specification. 125 3. Extension Declarations 127 An extension declaration can be used to indicate that an extension has 128 been applied to a message and possibly to reserve a part of the header 129 namespace identified by a header field prefix (see 3.1). 131 This specification does not define any ramifications of applying an 132 extension to a message nor whether two extensions can or cannot 133 logically coexist within the same message. It is strictly a framework 134 for describing which extensions have been applied and what the 135 ultimate recipient either must or may do in order to properly 136 interpret any extension declarations within that message. 138 The grammar for an extension declaration is as follows: 140 ext-decl = <"> URI <"> ";" namespace [ ext-params ] 141 ext-params = *( ext-extension ) 143 namespace = "ns" "=" header-prefix 144 header-prefix = 2*DIGIT "-" 145 ext-extension = ";" token [ "=" ( token | quoted-string ) ] 147 An extension is identified by a URI. Extension identifier URIs can be 148 either relative or absolute. Relative extension identifiers MUST 149 specify header-fields defined in an IETF RFC (see RFC 1808[4]). 150 Examples of extension declarations are 152 "Content-FooBar" 153 "New-Registered-Header" 154 "http://www.temporary.com/extension"; ns=33- 155 An extension declaration can be extended through the use of one or 156 more ext-extension parameters. Unrecognized ext-extension parameters 157 SHOULD be ignored and MUST NOT be removed by proxies when forwarding 158 the extension declaration. 160 3.1 Header Field Prefixes 162 The header-prefix are dynamically generated header field prefix 163 strings that can be used to indicate that all header fields in the 164 message matching the header-prefix value using string prefix-matching 165 are introduced by this extension instance. This allows an extension 166 instance to dynamically reserve a subspace of the header space in a 167 protocol message in order to prevent header field name clashes. 169 Linear white space (LWS) MUST NOT be used between the digits and the 170 "-". The format of the prefix using a combination of digits and the 171 dash "-" guarantees that no extension declaration can reserve the 172 whole header field name space. 174 Prefixes are primarily intended to avoid header field name conflicts 175 and to allow multiple instances of a single extension using its own 176 header fields to be applied to the same message without conflicting 177 with each other. 179 Agents SHOULD NOT reuse header-prefix values in the same message 180 unless explicitly allowed by the extension (see section 4.1 for a 181 discussion of the ultimate recipient of an extension declaration). 183 Examples of header-prefix values are 185 1234- 186 546- 187 234345653- 189 Old applications may introduce header fields independent of this 190 extension mechanism, potentially conflicting with header fields 191 introduced by the prefix mechanism. In order to minimize this risk, 192 prefixes MUST contain at least 2 digits. 194 4. Extension Header Fields 196 This proposal introduces two types of extension declaration strength: 197 mandatory and optional, and two types of extension declaration scope: 198 hop-by-hop and end-to-end (see section 4.1 and 4.2). 200 A mandatory extension declaration indicates that the ultimate 201 recipient MUST consult and adhere to the rules given by the extension 202 when processing the message or report an error (see section 5 and 8). 204 An optional extension declaration indicates that the ultimate 205 recipient of the extension MAY consult and adhere to the rules given 206 by the extension when processing the message, or ignore the extension 207 declaration completely. An agent may not be able to distinguish 208 whether the ultimate recipient does not understand an extension 209 referred to by an optional extension or simply ignores the extension 210 declaration. 212 The combination of the declaration strength and scope defines a 2x2 213 matrix which is distinguished by four new general HTTP header fields: 214 Man, Opt, C-Man, and C-Opt. (See section 4.1 and 4.2, and appendix 14 215 for a table of interactions with origin servers and proxies.) 217 The header fields are general header fields as they describe which 218 extensions actually are applied to an HTTP message. Optional 219 declarations MAY be applied to any HTTP message without any change to 220 existing HTTP semantics. Mandatory declarations MUST be applied to a 221 request message as described in section 5 and to a response message as 222 described in section 6. 224 4.1 End-to-End Extensions 226 End-to-end declarations MUST be transmitted to the ultimate recipient 227 of the declaration. The Man and the Opt general header fields are end- 228 to-end header fields and are defined as follows: 230 mandatory = "Man" ":" 1#ext-decl 231 optional = "Opt" ":" 1#ext-decl 233 For example 235 HTTP/1.1 200 OK 236 Content-Length: 421 237 Opt: "http://www.digest.org/Digest"; ns=55- 238 55-digest: "snfksjgor2tsajkt52" 239 ... 241 If a proxy is the ultimate recipient of a mandatory end-to-end 242 extension declaration then it MUST handle that extension declaration 243 as described in section 5. The proxy SHOULD remove all parts of the 244 extension declaration from the message before forwarding it. 246 4.2 Hop-by-Hop Extensions 248 Hop-by-hop extension declarations are meaningful only for a single 249 transport-level connection. The C-Man and the C-Opt general header 250 field are hop-by-hop header fields and MUST NOT be communicated by 251 proxies over further connections. The two headers have the following 252 grammar: 254 c-mandatory = "C-Man" ":" 1#ext-decl 255 c-optional = "C-Opt" ":" 1#ext-decl 256 For example 258 GET / HTTP/1.1 259 Host: some.host 260 C-Man: "http://www.digest.org/ProxyAuth"; 261 Credentials="g5gj262jdw@4df" 262 Connection: C-Man 264 In HTTP/1.1, the C-Man and the C-Opt header field MUST be protected by 265 a Connection header. That is, the header fields are to be included as 266 Connection header directives (see section [7], section 14.10). 268 An agent MUST NOT send the C-Man or the C-Opt header field to an 269 HTTP/1.0 proxy as it does not obey the HTTP/1.1 rules for parsing the 270 Connection header field (see [7]). 272 5. Mandatory HTTP Requests 274 An HTTP request is called a mandatory request if it includes at least 275 one mandatory extension declaration (using the Man or the C-Man header 276 fields). The method name of a mandatory request MUST be prefixed by 277 "M-". For example, a client might express the binding rights- 278 management constraints in an HTTP PUT request as follows: 280 M-PUT /a-resource HTTP/1.1 281 Man: "http://www.copyright.org/rights-management"; ns=43- 282 43-copyright: http://www.copyright.org/COPYRIGHT.html 283 43-contributions: http://www.copyright.org/PATCHES.html 284 Host: www.w3.org 285 Content-Length: 1203 286 Content-Type: text/html 288