- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Thu, 13 Oct 2016 07:23:17 +0300 (EEST)
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP working group mailing list <ietf-http-wg@w3.org>
- CC: Martin Thomson <martin.thomson@gmail.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>
> No, the plan is for all future RFC's from this WG to stay inside
> the lines drawn up by this draft (except of course when 'bis-ing
> existing headers).
>
> That gives us a limited universe of header syntax from which to
> pursue the stretch goals.
>
> >But the draft describes how to encode header fields in a new syntax
> >that is distinctly different to existing header fields, and therefore
> >definitively incompatible.
>
> No, it describes how to define *new* header fields, so that they
> will not be incompatible with the structure of existing header fields.
3. HTTP/1 serialization of HTTP header Common Structure
https://tools.ietf.org/html/draft-kamp-httpbis-structure-00#section-3
| h1_common-structure-header =
| ( field-name ":" OWS ">" h1_common_structure "<" )
| # Self-identifying HTTP headers
| ( field-name ":" OWS h1_common_structure ) /
| # legacy HTTP headers on white-list, see {{iana}}
So *new* header fields are form
new-field: >value<
where syntax of value is h1_common_structure.
> But if this draft goes forward, the WG essentially promises "This
> is the last header field parser/serializer we ever ask you to write,
> and you can already use it for these 19 headers".
And you can autodetect that syntax from new header fields because > and < -characters.
This was idea, right?
/ Kari Hurtta
Received on Thursday, 13 October 2016 04:23:48 UTC