Re: Other work items

[Julian Reschke <[e-mail]>]

On 2014-06-14 10:35, Matthew Kerwin wrote:
> On 14 June 2014 17:01, Julian Reschke <[e-mail]
> <mailto:[e-mail]>>wrote:
>
>     On 2014-06-13 23:50, Matthew Kerwin wrote:
>
>
>         On 14 June 2014 05:00, Mark Nottingham <[e-mail]
>         <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>
>              On 12 Jun 2014, at 4:55 pm, Julian Reschke
>         <[e-mail] <mailto:[e-mail]>
>              <mailto:[e-mail]
>         <mailto:[e-mail]>>__> wrote:
>
>               > - addressing the C-E/Range Request issue
>
>              That needs a draft and a serious amount of discussion
>         on-list first;
>              two hours in a room in Toronto are not going to move it
>              significantly forward if we don’t have those first.
>
>              Is anyone writing a draft here?
>
>
>         I'm thinking about it, but I'm not​​ sure what approach to take.
>         I have the start of a h2 extension-based
>         draft here, but that's only the tip of the iceberg.
>
>
>     As this is a HTTP/1.1 problem as well, the right solution IMHO is
>     define a new range unit (bytes-before-content-coding).
>
>
> Not really -- HTTP/1.1 has transfer encoding, which is applied after
> ranges (it also has the advantage(?) of compressing the range metadata,

But it's not used. What's easier: deploying a new range unit, or getting 
TE: gzip deployed?

> eliminating the cost of all those duplicate 'Content-Type' headers). A
> before-content-coding range request doesn't really make sense,

Why not? Do you think it wouldn't work? Please be a bit more concrete.

> especially if you're not applying C-E dynamically (assuming the server
> has an unencoded representation handy, assuming that encoding the range
> is somehow equivalent to encoding the whole, etc.).
>
> I think the C-E/Range request issue is unique to HTTP/2, except that
> nobody seems to have implemented T-E in HTTP/1.1.

See.

>               > - common header field syntax (JSON?)
>
>              This is VERY speculative (although I have thought about it
>         too). I-D?
>
>
>         Or perhaps revisiting draft-snell-httpbis-bohe.
>
>
>     Again, this was about HTTP in general.
>
>
> I see.  In that case, why not XML?  ;)

I'm one of those people left who actually prefer XML to JSON in many 
cases. However I believe this isn't one of these cases.

Best regards, Julian