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

[Ian Clelland <[e-mail]>]

Sorry I'm late to the discussion here; I had previously been looking at
using JFV to design a new application-layer header for declaring feature
policies for HTML documents, and I'm now looking at CS in the same light.

The semantics of the header probably aren't important here; what is
important is that I'm encoding a whitelist of URLs, and associating each
list with a string.

With JFV, I'd declare a policy with a header value like this:

{"feature1": ["http://origin1","http://origin2"]], "feature2": ["
http://origin3", "http://origin4"], "feature3": []}

With CS, I'm not seeing an elegant way to express the same idea; the lack
of a general way to express a sequence of values in particular makes
representing such a whitelist awkward.


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<

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

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

Is this the best I'd be able to do? 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. Maybe the best thing to do is to put the
JSON string into an h1_unicode_string and leave it there.

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. Without that (though maybe even with it,) I
just can't see using the CS syntax for this application.


Regards,
Ian Clelland
<[e-mail]>