Re: If not JSON, what then ?

--------
In message <12ED69B4-C924-475E-9432-B8FEB4B9DF80@mnot.net>, 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 ??"
 
>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.

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

>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

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

PS: I had expected you to ask if was trying to sabotage your Key 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, 2 August 2016 12:02:24 UTC