Re: If not JSON, what then ?

In message <>, Mark Nottingham wri

>Stepping back, I think we're talking about a set of rules something like 

>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 ?

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, 2 August 2016 13:09:44 UTC