Re: If not JSON, what then ?

[Mark Nottingham <[e-mail]>]

> On 2 Aug 2016, at 2:01 PM, Poul-Henning Kamp <[e-mail]> wrote:
> 
> --------
> In message <[e-mail]>, Mark Nottingham wri
> tes:
> 
>> A few thoughts come to mind:
>> 
>> 1) Using the first character of the field-value as a signal that the 
>> encoding is in use is interesting. I was thinking of indicating it with 
>> a suffix on the header field name (e.g., Date-J).
> 
> Yeah, that could work too, but I suspect it would be more cumbersome
> to implement, and it creates a new class of mistakes which need to
> be detected  - "Both Date and Date-J ??"

See separate discussion. 

> 
>> 2) Regardless of #1, using < as your indicator character is going to 
>> collide with the existing syntax of the Link header.
> 
> If Link is "<> blacklisted" in the IANA registry, that wouldn't be a
> problem, and all currently defined headers will need to be checked
> against some kind of white/black list, if we want them to use the
> new "common structure".
> 
> I picked <> because they were a cheap balanced pair in HPACK/huffman
> and I only found Link that might cause a false positive.
> 
> Strictly speaking, it doesn't have to be a balanced pair, it could
> even be control-characters but HPACK/huffman punish those hard.
> 
> I didn't dare pick () even though it had even shorter HPACK/huffman.
> 
> Thinking about it now, I can't recall any headers starting with a '('
> so () might be better than <> and thus avoid the special case of Link.

That might work.

> 
>> 3) I really, really wonder whether we need recursion beyond one level; 
> 
> As do I.
> 
> However, if it is recursion, the implementation cost is very low,
> and I would prefer to "deliver tools, not policy" and let people
> recurse until they hurt if they want.
> 
> I particular do not want to impose complexity limits on private
> headers, based on the simplicity of public headers, because my
> experience is that private headers are more complex.
> 
> I would prefer a simple, general model, restricted by machine
> readable schemas, rather than a complex model with built in
> limitations.

Nod.

Right now, most implementations limit header field values on length; if they start limiting on recursion as well, it would be good to have a reasonable value specified (or at least suggested).


>> 4) I agree with the sentiment that non-ascii strings in header field 
>> values are comparatively rare (since most headers are not intended for 
>> display), so while we should accommodate them, they shouldn't be the 
>> default.
> 
> That was the idea behind: \U  Make people explicitly tag UTF8

Ok.

>> 5) I like the idea of 'implicit angle brackets' to retrofit some 
>> existing headers. Depending on the parse algorithm we define, we could 
>> potentially fit a fair number of existing headers into this, although 
>> deriving the specific data types of things like parameter arguments is 
>> going to be difficult (or maybe impossible). Needs some investigation 
>> before we know whether this would be viable.
> 
> Schemas!  Have I mentioned already how smart I think schemas usable
> to build code with would be ?  :-)

So it's really "implicit angle brackets plus a reference to a retrofitted schema". OK. 

Get on another train and start working on that schema language. :)


> PS: I had expected you to ask if was trying to sabotage your Key header :-)

That's one of the reasons I complained about arbitrary recursion.

However, whatever happens here, I think we have to accept that Key will not be able to address all header fields; it's always going to be a subset. If a particular header field wants to leverage Key, it'll need to be specified within its capabilities (provided it gets traction, of course).

Cheers,


--
Mark Nottingham   https://www.mnot.net/