Re: draft-ietf-httpbis-header-structure-00 for general structured data

["Poul-Henning Kamp" <[e-mail]>]

--------
In message <[e-mail]>
, Ian Clelland writes:

>With JFV, I'd declare a policy with a header value like this:
>
>{"feature1": ["http://origin1","http://origin2"]], "feature2": ["http://origin3", "http://origin4"], "feature3": []}

>Trying my best to shoehorn this structure into CS, I do notice that nothing
>in the grammar or the text says that duplicate identifiers in an
><h1_element> aren't allowed, so I suppose I could write something like this:
>
>  >feature1;o="http://origin1";o="http://origin2",feature2;o="http://origin3";o="http://origin4",feature3<

That's how I would do it as well.

>(The o= is semantically meaningless here, but appears to be required by the
>grammar, as URLs can't be used as identifiers)

Correct.

>It's possible, if a bit awkward, to read this as a dictionary of lists,
>where 'feature3' maps to an empty list.

Correct.

>Is this the best I'd be able to do? 

I think so.

>With the current proposed grammar, maybe it's just not possible
>(or not an intended use) to put arbitrary structure data into a
>CS header.

Provided we leave the recursion in there, it is.  If we take
the recursion out, it won't be.

>Maybe the best thing to do is to put the JSON string
>into an h1_unicode_string and leave it there.

If your use-case is a case of needing private end-to-end movement of
data, you should do whatever works best for you, even JSON-in-a-string.

If your use-case is going to end its days as an I-D which will have
many implementations, there will (hopefully!) be a benefit from
shoe-horning it into header-structure, so people can reuse code.
 
>On the other hand, even without allowing full recursion, it would be useful
>to define an alternate production for <h1_value> that allowed a sequence of
>other <h1_values> in its place.

Just because full recursion is not possible, doesn't mean you _have_ to
use _all_ of it :-)

I have wondered if URLs should be able to act as identifiers but
there was no prior art for it in the RFC723x series of documents,
and it makes the h1-derserialization somewhat nasty.

With that you could do:

  >feature1;"http://origin1";"http://origin2",feature2;"http://origin3";"http://origin4",feature3<

But that is a relatively intrusive change to the I-D for a relatively
small improvement for you...

Poul-Henning

PS: I just spotted that values in dictionaries are optional in the
H1-serialization but not in the base common structure, fixed now.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[e-mail]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.