draft-ietf-httpbis-header-structure-09.txt   draft-ietf-httpbis-header-structure-10.txt 
HTTP M. Nottingham HTTP M. Nottingham
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track P-H. Kamp Intended status: Standards Track P-H. Kamp
Expires: June 4, 2019 The Varnish Cache Project Expires: October 19, 2019 The Varnish Cache Project
December 1, 2018 April 17, 2019
Structured Headers for HTTP Structured Headers for HTTP
draft-ietf-httpbis-header-structure-09 draft-ietf-httpbis-header-structure-10
Abstract Abstract
This document describes a set of data types and algorithms associated This document describes a set of data types and algorithms associated
with them that are intended to make it easier and safer to define and with them that are intended to make it easier and safer to define and
handle HTTP header fields. It is intended for use by new handle HTTP header fields. It is intended for use by new
specifications of HTTP header fields as well as revisions of existing specifications of HTTP header fields as well as revisions of existing
header field specifications when doing so does not cause header field specifications when doing so does not cause
interoperability issues. interoperability issues.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 4, 2019. This Internet-Draft will expire on October 19, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 49 skipping to change at page 2, line 49
3.6. Integers . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Integers . . . . . . . . . . . . . . . . . . . . . . . . 9
3.7. Floats . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.7. Floats . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.8. Strings . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.8. Strings . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.9. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.9. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.10. Byte Sequences . . . . . . . . . . . . . . . . . . . . . 11 3.10. Byte Sequences . . . . . . . . . . . . . . . . . . . . . 11
3.11. Booleans . . . . . . . . . . . . . . . . . . . . . . . . 11 3.11. Booleans . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Structured Headers in HTTP/1 . . . . . . . . . . . . . . . . 12 4. Structured Headers in HTTP/1 . . . . . . . . . . . . . . . . 12
4.1. Serialising Structured Headers into HTTP/1 . . . . . . . 12 4.1. Serialising Structured Headers into HTTP/1 . . . . . . . 12
4.2. Parsing HTTP/1 Header Fields into Structured Headers . . 18 4.2. Parsing HTTP/1 Header Fields into Structured Headers . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Normative References . . . . . . . . . . . . . . . . . . 28 7.1. Normative References . . . . . . . . . . . . . . . . . . 28
7.2. Informative References . . . . . . . . . . . . . . . . . 28 7.2. Informative References . . . . . . . . . . . . . . . . . 29
7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 29 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 30
Appendix B. Frequently Asked Questions . . . . . . . . . . . . . 29 Appendix B. Frequently Asked Questions . . . . . . . . . . . . . 30
B.1. Why not JSON? . . . . . . . . . . . . . . . . . . . . . . 30 B.1. Why not JSON? . . . . . . . . . . . . . . . . . . . . . . 30
B.2. Structured Headers don't "fit" my data. . . . . . . . . . 30 B.2. Structured Headers don't "fit" my data. . . . . . . . . . 30
B.3. What should generic Structured Headers implementations B.3. What should generic Structured Headers implementations
expose? . . . . . . . . . . . . . . . . . . . . . . . . . 31 expose? . . . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . 31 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . 31
C.1. Since draft-ietf-httpbis-header-structure-08 . . . . . . 31 C.1. Since draft-ietf-httpbis-header-structure-09 . . . . . . 31
C.2. Since draft-ietf-httpbis-header-structure-07 . . . . . . 32 C.2. Since draft-ietf-httpbis-header-structure-08 . . . . . . 32
C.3. Since draft-ietf-httpbis-header-structure-06 . . . . . . 32 C.3. Since draft-ietf-httpbis-header-structure-07 . . . . . . 32
C.4. Since draft-ietf-httpbis-header-structure-05 . . . . . . 32 C.4. Since draft-ietf-httpbis-header-structure-06 . . . . . . 33
C.5. Since draft-ietf-httpbis-header-structure-04 . . . . . . 33 C.5. Since draft-ietf-httpbis-header-structure-05 . . . . . . 33
C.6. Since draft-ietf-httpbis-header-structure-03 . . . . . . 33 C.6. Since draft-ietf-httpbis-header-structure-04 . . . . . . 33
C.7. Since draft-ietf-httpbis-header-structure-02 . . . . . . 33 C.7. Since draft-ietf-httpbis-header-structure-03 . . . . . . 33
C.8. Since draft-ietf-httpbis-header-structure-01 . . . . . . 33 C.8. Since draft-ietf-httpbis-header-structure-02 . . . . . . 33
C.9. Since draft-ietf-httpbis-header-structure-00 . . . . . . 33 C.9. Since draft-ietf-httpbis-header-structure-01 . . . . . . 34
C.10. Since draft-ietf-httpbis-header-structure-00 . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
Specifying the syntax of new HTTP header fields is an onerous task; Specifying the syntax of new HTTP header fields is an onerous task;
even with the guidance in [RFC7231], Section 8.3.1, there are many even with the guidance in [RFC7231], Section 8.3.1, there are many
decisions - and pitfalls - for a prospective HTTP header field decisions - and pitfalls - for a prospective HTTP header field
author. author.
Once a header field is defined, bespoke parsers and serialisers often Once a header field is defined, bespoke parsers and serialisers often
skipping to change at page 8, line 39 skipping to change at page 8, line 39
Example-StrListListHeader: "foo";"bar", "baz", "bat"; "one" Example-StrListListHeader: "foo";"bar", "baz", "bat"; "one"
Header specifications can constrain the types of individual inner- Header specifications can constrain the types of individual inner-
list values if necessary. list values if necessary.
Parsers MUST support lists of lists containing at least 1024 members, Parsers MUST support lists of lists containing at least 1024 members,
and inner-lists containing at least 256 members. and inner-lists containing at least 256 members.
3.4. Parameterised Lists 3.4. Parameterised Lists
Parameterised Lists are arrays of parameterised identifier with one Parameterised Lists are arrays of parameterised identifiers, with one
or more members. or more members.
A parameterised identifier is a token (Section 3.9}) with an optional A parameterised identifier is a primary identifier (a Section 3.9})
set of parameters, each parameter having a textual name and an with associated parameters, an ordered map of key-value pairs where
optional value that is an item (Section 3.5). Ordering between the keys are short, textual strings and the values are items
parameters is not significant, and duplicate parameters MUST cause (Section 3.5). There can be zero or more parameters, and keys are
parsing to fail. required to be unique.
The ABNF for parameterised lists in HTTP/1 headers is: The ABNF for parameterised lists in HTTP/1 headers is:
sh-param-list = param-item *( OWS "," OWS param-item ) sh-param-list = param-item *( OWS "," OWS param-item )
param-item = primary-id *parameter param-item = primary-id *parameter
primary-id = sh-token primary-id = sh-token
parameter = OWS ";" OWS param-name [ "=" param-value ] parameter = OWS ";" OWS param-name [ "=" param-value ]
param-name = key param-name = key
param-value = sh-item param-value = sh-item
skipping to change at page 9, line 25 skipping to change at page 9, line 25
Example-ParamListHeader: abc_123;a=1;b=2; cdef_456, ghi;q="9";r="w" Example-ParamListHeader: abc_123;a=1;b=2; cdef_456, ghi;q="9";r="w"
Parsers MUST support parameterised lists containing at least 1024 Parsers MUST support parameterised lists containing at least 1024
members, support members with at least 256 parameters, and support members, support members with at least 256 parameters, and support
parameter keys with at least 64 characters. parameter keys with at least 64 characters.
3.5. Items 3.5. Items
An item is can be a integer (Section 3.6), float (Section 3.7), An item is can be a integer (Section 3.6), float (Section 3.7),
string (Section 3.8), token (Section 3.9}), byte sequence string (Section 3.8), token (Section 3.9), byte sequence
(Section 3.10), or Boolean (Section 3.11). (Section 3.10), or Boolean (Section 3.11).
The ABNF for items in HTTP/1 headers is: The ABNF for items in HTTP/1 headers is:
sh-item = sh-integer / sh-float / sh-string / sh-token / sh-binary sh-item = sh-integer / sh-float / sh-string / sh-token / sh-binary
/ sh-boolean / sh-boolean
3.6. Integers 3.6. Integers
Integers have a range of -9,223,372,036,854,775,808 to Integers have a range of -999,999,999,999,999 to 999,999,999,999,999
9,223,372,036,854,775,807 inclusive (i.e., a 64-bit signed integer). inclusive (i.e., up to fifteen digits, signed).
The ABNF for integers in HTTP/1 headers is: The ABNF for integers in HTTP/1 headers is:
sh-integer = ["-"] 1*19DIGIT sh-integer = ["-"] 1*15DIGIT
For example: For example:
Example-IntegerHeader: 42 Example-IntegerHeader: 42
3.7. Floats 3.7. Floats
Floats are integers with a fractional part, that can be stored as Floats are integers with a fractional part, that can be stored as
IEEE 754 double precision numbers (binary64) ([IEEE754]). IEEE 754 double precision numbers (binary64) ([IEEE754]).
skipping to change at page 11, line 22 skipping to change at page 11, line 22
Tokens are short textual words; their abstract model is identical to Tokens are short textual words; their abstract model is identical to
their expression in the textual HTTP serialisation. their expression in the textual HTTP serialisation.
The ABNF for tokens in HTTP/1 headers is: The ABNF for tokens in HTTP/1 headers is:
sh-token = ALPHA *( ALPHA / DIGIT / "_" / "-" / "." / ":" / "%" / "*" / "/" ) sh-token = ALPHA *( ALPHA / DIGIT / "_" / "-" / "." / ":" / "%" / "*" / "/" )
Parsers MUST support tokens with at least 512 characters. Parsers MUST support tokens with at least 512 characters.
Note that a Structured Header token is not the same as the "token"
ABNF rule defined in [RFC7230].
3.10. Byte Sequences 3.10. Byte Sequences
Byte sequences can be conveyed in Structured Headers. Byte sequences can be conveyed in Structured Headers.
The ABNF for a byte sequence in HTTP/1 headers is: The ABNF for a byte sequence in HTTP/1 headers is:
sh-binary = "*" *(base64) "*" sh-binary = "*" *(base64) "*"
base64 = ALPHA / DIGIT / "+" / "/" / "=" base64 = ALPHA / DIGIT / "+" / "/" / "="
In HTTP/1 headers, a byte sequence is delimited with asterisks and In HTTP/1 headers, a byte sequence is delimited with asterisks and
skipping to change at page 11, line 46 skipping to change at page 11, line 49
Parsers MUST support byte sequences with at least 16384 octets after Parsers MUST support byte sequences with at least 16384 octets after
decoding. decoding.
3.11. Booleans 3.11. Booleans
Boolean values can be conveyed in Structured Headers. Boolean values can be conveyed in Structured Headers.
The ABNF for a Boolean in HTTP/1 headers is: The ABNF for a Boolean in HTTP/1 headers is:
sh-boolean = "?" boolean sh-boolean = "?" boolean
boolean = %54 / %46 ; capital "T" or "F" boolean = "0" / "1"
In HTTP/1 headers, a byte sequence is indicated with a leading "?" In HTTP/1 headers, a boolean is indicated with a leading "?"
character. For example: character. For example:
Example-BoolHdr: ?T Example-BoolHdr: ?1
4. Structured Headers in HTTP/1 4. Structured Headers in HTTP/1
This section defines how to serialise and parse Structured Headers in This section defines how to serialise and parse Structured Headers in
HTTP/1 textual header fields, and protocols compatible with them HTTP/1 textual header fields, and protocols compatible with them
(e.g., in HTTP/2 [RFC7540] before HPACK [RFC7541] is applied). (e.g., in HTTP/2 [RFC7540] before HPACK [RFC7541] is applied).
4.1. Serialising Structured Headers into HTTP/1 4.1. Serialising Structured Headers into HTTP/1
Given a structured defined in this specification: Given a structured defined in this specification:
skipping to change at page 15, line 49 skipping to change at page 15, line 51
6. If input_item is a byte sequence, return the result of applying 6. If input_item is a byte sequence, return the result of applying
Serialising a Byte Sequence (Section 4.1.10) to input_item. Serialising a Byte Sequence (Section 4.1.10) to input_item.
7. Otherwise, fail serialisation. 7. Otherwise, fail serialisation.
4.1.6. Serialising an Integer 4.1.6. Serialising an Integer
Given an integer as input_integer: Given an integer as input_integer:
1. If input_integer is not an integer in the range of 1. If input_integer is not an integer in the range of
-9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 -999,999,999,999,999 to 999,999,999,999,999 inclusive, fail
inclusive, fail serialisation. serialisation.
2. Let output be an empty string. 2. Let output be an empty string.
3. If input_integer is less than (but not equal to) 0, append "-" to 3. If input_integer is less than (but not equal to) 0, append "-" to
output. output.
4. Append input_integer's numeric value represented in base 10 using 4. Append input_integer's numeric value represented in base 10 using
only decimal digits to output. only decimal digits to output.
5. Return output. 5. Return output.
skipping to change at page 18, line 9 skipping to change at page 18, line 15
4.1.11. Serialising a Boolean 4.1.11. Serialising a Boolean
Given a Boolean as input_boolean: Given a Boolean as input_boolean:
1. If input_boolean is not a boolean, fail serialisation. 1. If input_boolean is not a boolean, fail serialisation.
2. Let output be an empty string. 2. Let output be an empty string.
3. Append "?" to output. 3. Append "?" to output.
4. If input_boolean is true, append "T" to output. 4. If input_boolean is true, append "1" to output.
5. If input_boolean is false, append "F" to output. 5. If input_boolean is false, append "0" to output.
6. Return output. 6. Return output.
4.2. Parsing HTTP/1 Header Fields into Structured Headers 4.2. Parsing HTTP/1 Header Fields into Structured Headers
When a receiving implementation parses textual HTTP header fields When a receiving implementation parses textual HTTP header fields
(e.g., in HTTP/1 or HTTP/2) that are known to be Structured Headers, (e.g., in HTTP/1 or HTTP/2) that are known to be Structured Headers,
it is important that care be taken, as there are a number of edge it is important that care be taken, as there are a number of edge
cases that can cause interoperability or even security problems. cases that can cause interoperability or even security problems.
This section specifies the algorithm for doing so. This section specifies the algorithm for doing so.
skipping to change at page 22, line 45 skipping to change at page 22, line 49
4.2.6. Parsing a Parameterised Identifier from Text 4.2.6. Parsing a Parameterised Identifier from Text
Given an ASCII string input_string, return an token with an unordered Given an ASCII string input_string, return an token with an unordered
map of parameters. input_string is modified to remove the parsed map of parameters. input_string is modified to remove the parsed
value. value.
1. Let primary_identifier be the result of Parsing a Token from Text 1. Let primary_identifier be the result of Parsing a Token from Text
(Section 4.2.10) from input_string. (Section 4.2.10) from input_string.
2. Let parameters be an empty, unordered map. 2. Let parameters be an empty, ordered map.
3. In a loop: 3. In a loop:
1. Discard any leading OWS from input_string. 1. Discard any leading OWS from input_string.
2. If the first character of input_string is not ";", exit the 2. If the first character of input_string is not ";", exit the
loop. loop.
3. Consume a ";" character from the beginning of input_string. 3. Consume a ";" character from the beginning of input_string.
skipping to change at page 24, line 39 skipping to change at page 24, line 44
1. Let char be the result of removing the first character of 1. Let char be the result of removing the first character of
input_string. input_string.
2. If char is a DIGIT, append it to input_number. 2. If char is a DIGIT, append it to input_number.
3. Else, if type is "integer" and char is ".", append char to 3. Else, if type is "integer" and char is ".", append char to
input_number and set type to "float". input_number and set type to "float".
4. Otherwise, prepend char to input_string, and exit the loop. 4. Otherwise, prepend char to input_string, and exit the loop.
5. If type is "integer" and input_number contains more than 19 5. If type is "integer" and input_number contains more than 15
characters, fail parsing. characters, fail parsing.
6. If type is "float" and input_number contains more than 16 6. If type is "float" and input_number contains more than 16
characters, fail parsing. characters, fail parsing.
8. If type is "integer": 8. If type is "integer":
1. Parse input_number as an integer and let output_number be 1. Parse input_number as an integer and let output_number be
the product of the result and sign. the product of the result and sign.
skipping to change at page 27, line 34 skipping to change at page 27, line 39
4.2.12. Parsing a Boolean from Text 4.2.12. Parsing a Boolean from Text
Given an ASCII string input_string, return a Boolean. input_string is Given an ASCII string input_string, return a Boolean. input_string is
modified to remove the parsed value. modified to remove the parsed value.
1. If the first character of input_string is not "?", fail parsing. 1. If the first character of input_string is not "?", fail parsing.
2. Discard the first character of input_string. 2. Discard the first character of input_string.
3. If the first character of input_string case-sensitively matches 3. If the first character of input_string matches "1", discard the
"T", discard the first character, and return true. first character, and return true.
4. If the first character of input_string case-sensitively matches 4. If the first character of input_string matches "0", discard the
"F", discard the first character, and return false. first character, and return false.
5. No value has matched; fail parsing. 5. No value has matched; fail parsing.
5. IANA Considerations 5. IANA Considerations
This draft has no actions for IANA. This draft has no actions for IANA.
6. Security Considerations 6. Security Considerations
The size of most types defined by Structured Headers is not limited; The size of most types defined by Structured Headers is not limited;
skipping to change at page 31, line 33 skipping to change at page 31, line 38
A generic implementation should expose the top-level parse A generic implementation should expose the top-level parse
(Section 4.2) and serialise (Section 4.1) functions. They need not (Section 4.2) and serialise (Section 4.1) functions. They need not
be functions; for example, it could be implemented as an object, with be functions; for example, it could be implemented as an object, with
methods for each of the different top-level types. methods for each of the different top-level types.
For interoperability, it's important that generic implementations be For interoperability, it's important that generic implementations be
complete and follow the algorithms closely; see Section 1.1. To aid complete and follow the algorithms closely; see Section 1.1. To aid
this, a common test suite is being maintained by the community; see this, a common test suite is being maintained by the community; see
https://github.com/httpwg/structured-header-tests [7]. https://github.com/httpwg/structured-header-tests [7].
Implementers should note that dictionaries and parameters are order-
preserving maps. Some headers may not convey meaning in the ordering
of these data types, but it should still be exposed so that
applications which need to use it will have it available.
Appendix C. Changes Appendix C. Changes
_RFC Editor: Please remove this section before publication._ _RFC Editor: Please remove this section before publication._
C.1. Since draft-ietf-httpbis-header-structure-08 C.1. Since draft-ietf-httpbis-header-structure-09
o Changed Boolean from T/F to 1/0 (#784).
o Parameters are now ordered maps (#765).
o Clamp integers to 15 digits (#737).
C.2. Since draft-ietf-httpbis-header-structure-08
o Disallow whitespace before items properly (#703). o Disallow whitespace before items properly (#703).
o Created "key" for use in dictionaries and parameters, rather than o Created "key" for use in dictionaries and parameters, rather than
relying on identifier (#702). Identifiers have a separate minimum relying on identifier (#702). Identifiers have a separate minimum
supported size. supported size.
o Expanded the range of special characters allowed in identifier to o Expanded the range of special characters allowed in identifier to
include all of ALPHA, ".", ":", and "%" (#702). include all of ALPHA, ".", ":", and "%" (#702).
skipping to change at page 32, line 14 skipping to change at page 32, line 31
o Gave better names for referring specs to use in Parameterised o Gave better names for referring specs to use in Parameterised
Lists (#720). Lists (#720).
o Added Lists of Lists (#721). o Added Lists of Lists (#721).
o Rename Identifier to Token (#725). o Rename Identifier to Token (#725).
o Add implementation guidance (#727). o Add implementation guidance (#727).
C.2. Since draft-ietf-httpbis-header-structure-07 C.3. Since draft-ietf-httpbis-header-structure-07
o Make Dictionaries ordered mappings (#659). o Make Dictionaries ordered mappings (#659).
o Changed "binary content" to "byte sequence" to align with Infra o Changed "binary content" to "byte sequence" to align with Infra
specification (#671). specification (#671).
o Changed "mapping" to "map" for #671. o Changed "mapping" to "map" for #671.
o Don't fail if byte sequences aren't "=" padded (#658). o Don't fail if byte sequences aren't "=" padded (#658).
o Add Booleans (#683). o Add Booleans (#683).
o Allow identifiers in items again (#629). o Allow identifiers in items again (#629).
o Disallowed whitespace before items (#703). o Disallowed whitespace before items (#703).
o Explain the consequences of splitting a string across multiple o Explain the consequences of splitting a string across multiple
headers (#686). headers (#686).
C.3. Since draft-ietf-httpbis-header-structure-06 C.4. Since draft-ietf-httpbis-header-structure-06
o Add a FAQ. o Add a FAQ.
o Allow non-zero pad bits. o Allow non-zero pad bits.
o Explicitly check for integers that violate constraints. o Explicitly check for integers that violate constraints.
C.4. Since draft-ietf-httpbis-header-structure-05 C.5. Since draft-ietf-httpbis-header-structure-05
o Reorganise specification to separate parsing out. o Reorganise specification to separate parsing out.
o Allow referencing specs to use ABNF. o Allow referencing specs to use ABNF.
o Define serialisation algorithms. o Define serialisation algorithms.
o Refine relationship between ABNF, parsing and serialisation o Refine relationship between ABNF, parsing and serialisation
algorithms. algorithms.
C.5. Since draft-ietf-httpbis-header-structure-04 C.6. Since draft-ietf-httpbis-header-structure-04
o Remove identifiers from item. o Remove identifiers from item.
o Remove most limits on sizes. o Remove most limits on sizes.
o Refine number parsing. o Refine number parsing.
C.6. Since draft-ietf-httpbis-header-structure-03 C.7. Since draft-ietf-httpbis-header-structure-03
o Strengthen language around failure handling. o Strengthen language around failure handling.
C.7. Since draft-ietf-httpbis-header-structure-02 C.8. Since draft-ietf-httpbis-header-structure-02
o Split Numbers into Integers and Floats. o Split Numbers into Integers and Floats.
o Define number parsing. o Define number parsing.
o Tighten up binary parsing and give it an explicit end delimiter. o Tighten up binary parsing and give it an explicit end delimiter.
o Clarify that mappings are unordered. o Clarify that mappings are unordered.
o Allow zero-length strings. o Allow zero-length strings.
o Improve string parsing algorithm. o Improve string parsing algorithm.
o Improve limits in algorithms. o Improve limits in algorithms.
o Require parsers to combine header fields before processing. o Require parsers to combine header fields before processing.
o Throw an error on trailing garbage. o Throw an error on trailing garbage.
C.8. Since draft-ietf-httpbis-header-structure-01 C.9. Since draft-ietf-httpbis-header-structure-01
o Replaced with draft-nottingham-structured-headers. o Replaced with draft-nottingham-structured-headers.
C.9. Since draft-ietf-httpbis-header-structure-00 C.10. Since draft-ietf-httpbis-header-structure-00
o Added signed 64bit integer type. o Added signed 64bit integer type.
o Drop UTF8, and settle on BCP137 ::EmbeddedUnicodeChar for h1- o Drop UTF8, and settle on BCP137 ::EmbeddedUnicodeChar for h1-
unicode-string. unicode-string.
o Change h1_blob delimiter to ":" since "'" is valid t_char o Change h1_blob delimiter to ":" since "'" is valid t_char
Authors' Addresses Authors' Addresses
 End of changes. 34 change blocks. 
50 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/