Re: If not JSON, what then ?

On Tue, Aug 02, 2016 at 03:08:37PM +0200, Mark Nottingham wrote:
> 
> > On 2 Aug 2016, at 3:06 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> > 
> > --------
> > In message <ECE83331-ACDD-42E7-B99C-3E4E4C66DD13@mnot.net>, Mark Nottingham wri
> > tes:
> > 
> >> Stepping back, I think we're talking about a set of rules something like 
> >> this;
> > 
> >> A. For a newly defined header field that explicitly uses the new format, 
> >>  send it in the new format
> >> B. For existing header fields, if their expression in the new format is 
> >>  defined:
> >> 1. If you have evidence that your peer can accept the new header 
> >>    format, send them in the new format
> >> 2. Otherwise, send them in the original format.
> >> C. All other fields are always sent in the original, HTTP/1 format.
> > 
> > Yes, something like that.
> > 
> > However, this is digging deep into the extreme far end of the ideas
> > I presented, and it seems rather too speculative to dig much further.
> > 
> > I am far more interested in hearing what people think about the
> > important part of the write-up:  Deriving and generalizing a
> > common header structure from existing HTTP1 header syntaxes ?
> 
> I think that's the way to go, and that using it for *newly defined* headers
> is a good enough use case.

Same here.

> If we can pause discussion of porting existing headers to the new format for
> the time being, it may help.

Very likely but we all know it's very tempting at the same time. They
also serve as good examples of what we may need in the future.

Willy

Received on Tuesday, 2 August 2016 13:13:52 UTC