--- 1/draft-ietf-httpbis-retrofit-02.txt 2022-05-25 00:13:09.231682147 -0700 +++ 2/draft-ietf-httpbis-retrofit-03.txt 2022-05-25 00:13:09.267683063 -0700 @@ -1,18 +1,18 @@ Network Working Group M. Nottingham -Internet-Draft 11 May 2022 +Internet-Draft 24 May 2022 Intended status: Standards Track -Expires: 12 November 2022 +Expires: 25 November 2022 Retrofit Structured Fields for HTTP - draft-ietf-httpbis-retrofit-02 + draft-ietf-httpbis-retrofit-03 Abstract This specification nominates a selection of existing HTTP fields as having syntax that is compatible with Structured Fields, so that they can be handled as such (subject to certain caveats). To accommodate some additional fields whose syntax is not compatible, it also defines mappings of their semantics into new Structured Fields. It does not specify how to negotiate their use. @@ -39,21 +39,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 12 November 2022. + This Internet-Draft will expire on 25 November 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. 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 @@ -261,69 +261,71 @@ Table 1: Compatible Fields Note the following caveats regarding compatibility: Parameter and Dictionary keys: HTTP parameter names are case- insensitive (per Section 5.6.6 of [HTTP]), but Structured Fields require them to be all-lowercase. Although the vast majority of parameters seen in typical traffic are all-lowercase, compatibility can be improved by force-lowercasing parameters when - encountered. Likewise, many Dictionary-based fields (e.g., Cache- + parsing. Likewise, many Dictionary-based fields (e.g., Cache- Control, Expect-CT, Pragma, Prefer, Preference-Applied, Surrogate- Control) have case-insensitive keys, and compatibility can be - improved by force-lowercasing them. + improved by force-lowercasing them when parsing. Parameter delimitation: The parameters rule in HTTP (see Section 5.6.6 of [HTTP]) allows whitespace before the ";" delimiter, but Structured Fields does not. Compatibility can be - improved by allowing such whitespace. + improved by allowing such whitespace when parsing. String quoting: Section 5.6.4 of [HTTP] allows backslash-escaping most characters in quoted strings, whereas Structured Field Strings only escape "\" and DQUOTE. Compatibility can be improved - by unescaping other characters before processing as Strings. + by unescaping other characters before parsing. Token limitations: In Structured Fields, tokens are required to begin with an alphabetic character or "*", whereas HTTP tokens allow a wider range of characters. This prevents use of mapped values that begin with one of these characters. For example, media types, field names, methods, range-units, character and transfer codings that begin with a number or special character other than "*" might be valid HTTP protocol elements, but will not be able to be parsed as Structured Field Tokens. Integer limitations: Structured Fields Integers can have at most 15 digits; larger values will not be able to be represented in them. - IPv6 Literals: Fields whose values can contain IPv6 literal - addresses (such as CDN-Loop, Host, and Origin) are not compatible - when those values are parsed as Structured Fields Tokens, because - the brackets used to delimit them are not allowed in Tokens. + IPv6 Literals: Fields whose values contain IPv6 literal addresses + (such as CDN-Loop, Host, and Origin) are not able to be + represented as Structured Fields Tokens, because the brackets used + to delimit them are not allowed in Tokens. Empty Field Values: Empty and whitespace-only field values are considered errors in Structured Fields. For compatible fields, an empty field indicates that the field should be silently ignored. Alt-Svc: Some ALPN tokens (e.g., h3-Q43) do not conform to key's - syntax. Since the final version of HTTP/3 uses the h3 token, this - shouldn't be a long-term issue, although future tokens may again - violate this assumption. + syntax, and therefore cannot be represented as a Token. Since the + final version of HTTP/3 uses the h3 token, this shouldn't be a + long-term issue, although future tokens may again violate this + assumption. - Content-Length: Content-Length is defined as a List because it is - not uncommon for implementations to mistakenly send multiple - values. See Section 8.6 of [HTTP] for handling requirements. + Content-Length: Note that Content-Length is defined as a List + because it is not uncommon for implementations to mistakenly send + multiple values. See Section 8.6 of [HTTP] for handling + requirements. - Retry-After: Only the delta-seconds form of Retry-After is - supported; a Retry-After value containing a http-date will need to - be either converted into delta-seconds or represented as a raw - value. + Retry-After: Only the delta-seconds form of Retry-After can be + represented; a Retry-After value containing a http-date will need + to be converted into delta-seconds to be conveyed as a Structured + Field Value. 3. Mapped Fields Some HTTP field values have syntax that cannot be successfully parsed as Structured Fields. Instead, it is necessary to map them into a separate Structured Field with an alternative name. For example, the Date HTTP header field carries a date: Date: Sun, 06 Nov 1994 08:49:37 GMT