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

> On 24 Dec 2016, at 2:07 am, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> On 2016-12-23 19:16, Mark Nottingham wrote:
>> 
>>> On 23 Dec. 2016, at 12:39 pm, Julian Reschke <julian.reschke@gmx.de> wrote:
>>> 
>>> On 2016-12-22 19:38, Poul-Henning Kamp wrote:
>>>> --------
>>>> In message <CAK_TSXLJcDkUCpn5f79DBtnGjjPLtb1fEv_-Akfg4cPbboFVvg@mail.gmail.com>
>>>> , 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.
>>> 
>>> 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).
> 
> <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."

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>


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

Received on Saturday, 24 December 2016 18:18:42 UTC