W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: draft-kamp-httpbis-structure-00 comments

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>
Message-Id: <20161013042318.8C70F166C2@welho-filter4.welho.com>
> 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

This archive was generated by hypermail 2.3.1 : Thursday, 13 October 2016 04:23:53 UTC