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

--------
In message <CABkgnnUD3BXPLKCjSJdWPxwdE89vh4a+UA--19VxMwQXQ64_Rg@mail.gmail.com>
, Martin Thomson writes:

>I've spent a bit of time thinking about this, and that there is
>probably something here, but I'm not sure what it is.

Reading through your comments, it is obvious that I have not been
able to articulate what I want this draft to do.

>1. Desired end-state
>
>Though it is not stated, there are many potential properties we might
>want to obtain by making this sort of change:
> - more consistent representation of header fields
> - easier to specify new, compatible header fields
> - more capable header fields (more resolution on dates, for instance)
> - more efficient parsing and processing code
> - smaller header field representations
> - (there are probably some other goals too)

Yes, that's a pretty good list.

But those are the "stretch goals", things which this draft tries to enable.

>Any draft also needs to describe when an implementation might use
>whatever tools the draft describes. 

My draft is not aimed at implementations but at RFC writers, such
as yourself, so that for instance your encryption draft does not
take us further away from the stretch goals.

>The draft should at least acknowledge incentive to deploy.  In order
>for it to be attractive to both clients and servers to support this,
>they need to see some tangible benefits.

With or without this draft, you can write a serializer and parser
for common structure, put it in your code, use it for 19 headers,
and nobody but you would know, because it is 100% compatible.

That's probably not worth it for anybody.

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".

That might be a good incentive.

>2. Getting from here to there
>
>Presumably the plan is to find some place that a new encoding can be
>used and use the encoding there.

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.

>That probably means you will need a way to learn on a
>per-header-field basis whether the common form is supported.
>[...] but NeckoFace:>n< probably isn't going to
>be something you can use from the outset.

Why not ?

To any code which hasn't heard about my draft and common structure 
">n<" is just a string to parse, just like any other string containing
a http header.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Tuesday, 11 October 2016 06:52:18 UTC