- From: Brian Smith <brian@briansmith.org>
- Date: Tue, 29 Apr 2008 07:49:21 -0700
- To: "'Jamie Lokier'" <jamie@shareable.org>, "'Phil Archer'" <parcher@icra.org>
- Cc: "'Mark Nottingham'" <mnot@mnot.net>, "'atom-syntax Syntax'" <atom-syntax@imc.org>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
Jamie Lokier wrote:
> How about:
>
> Generic-Link: URL=value
>
> Which is required to be written in exactly that form, the URN denotes
> the relation type, and the URN is always unquoted, absolute, and in
> a canonical form.
>
> It seems to satisfy the same easy parsing and substitution
> requirements that motivate foo-Link, while providing the flexibility
> of URNs for unregistered relation types.
I agree it is seems easier to parse at first. But, you have to change it to
at least the following to support multiple "Generic-Link" headers (See [1]):
Generic-Link: #(URL=value)
And then you have to disambiguate the commas:
Generic-Link: #(<URL>=value)
And, even then, there is no mechanism for parameters, which I think it
helpful (especially the "type" parameter).
Regards,
Brian
[1] RFC 2616, Section 4.2:
"Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)].
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the
interpretation of the combined field value, and thus a proxy MUST NOT
change the order of these field values when a message is forwarded."
Received on Tuesday, 29 April 2008 14:50:06 UTC