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

From: Ian Clelland <[email-masked]>
Date: Thu, 22 Dec 2016 11:17:03 -0500

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
<[email-masked]>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 22 Dec 2016 18:38:57 +0000

--------
In message <[email-masked]>
, Ian Clelland writes:

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

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

That's how I would do it as well.

>grammar, as URLs can't be used as identifiers)

Correct.

>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.
 
>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
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 23 Dec 2016 18:39:41 +0100

> That's how I would do it as well.

Using identical parameter names sounds like a bad idea; I'm not aware of 
any header field that currently uses this format, and it also seems to 
contradict the "dictionary" data model.

Why not:

  feature1; o="http://origin1 http://origin2", feature2; 
o="http://origin3 http://origin4", feature3

?

 > ...

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 23 Dec 2016 13:16:24 -0500

> On 23 Dec. 2016, at 12:39 pm, Julian Reschke <[email-masked]> wrote:
> 
> Using identical parameter names sounds like a bad idea; I'm not aware of any header field that currently uses this format, and it also seems to contradict the "dictionary" data model.

Link allows it, and IIRC some link relations take advantage of that (although I can't think of their names ATM).

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

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 24 Dec 2016 10:25:02 +1300

> Link allows it, and IIRC some link relations take advantage of that (although I can't think of their names ATM).

AFAICS for most of the headers that will benefit from generic syntax
parsing instead of custom parsers the desirable behavour is to normalize
foo;o=X;o=y down to just foo;o=y to prevent foo;o=X vs foo;o=y
interpretation differences by various recipients and nasty values being
smuggled through middleware.

If we can avoid having parameter name duplication, that would be a good
step towards uniform handling of these smuggling protections.

Amos

---

From: Julian Reschke <[email-masked]>
Date: Sat, 24 Dec 2016 08:07:34 +0100

> Link allows it, and IIRC some link relations take advantage of that (although I can't think of their names ATM).

<https://greenbytes.de/tech/webdav/rfc5988.html#rfc.section.5.3>:

"The relation type of a link is conveyed in the "rel" parameter's value. 
The "rel" parameter MUST NOT appear more than once in a given 
link-value; occurrences after the first MUST be ignored by parsers."

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 24 Dec 2016 07:43:17 +0000

--------
In message <[email-masked]>, Amos Jeffries 

>step towards uniform handling of these smuggling protections.

I have deliberately not written that dictionaries cannot have duplication,
but smuggling prevention is a good reason to require that.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 24 Dec 2016 13:18:16 -0500

> On 24 Dec 2016, at 2:07 am, Julian Reschke <[email-masked]> wrote:
> 
> "The relation type of a link is conveyed in the "rel" parameter's value. The "rel" parameter MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by parsers."

That's a specific target attribute; generally, it's looser:

> Target attributes are a set of key/value pairs that describe the link or its target; for example, a media type hint. This specification does not attempt to coordinate their names or use, but does provide common target attributes for use in the Link HTTP header.

<http://httpwg.org/specs/rfc5988.html#links>