W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2008

Re: Feedback for draft-nottingham-http-link-header-03

From: Eran Hammer-Lahav <eran@hueniverse.com>
Date: Tue, 2 Dec 2008 18:36:40 -0700
To: Mark Nottingham <mnot@mnot.net>
CC: Julian Reschke <julian.reschke@gmx.de>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "www-talk@w3.org" <www-talk@w3.org>
Message-ID: <C55B22A8.F4A4%eran@hueniverse.com>
(adding www-talk for /site-meta comments)

A separate header is easily workable, but will require a different approach to the proposed simplified /site-meta text format. It cannot be a list of Link headers without the "Link: " prefix and still support this kind of extension.


On 12/2/08 5:31 PM, "Mark Nottingham" <mnot@mnot.net> wrote:

A separate header is by far the best way to do this.

On 02/12/2008, at 7:35 PM, Eran Hammer-Lahav wrote:

>> Well, right now there's no extension point; the target does not allow
>> templating, and a parameter can't override it (recipients will ignore
>> extension parameters they don't understand).
>> One potential solution would be to state that if a link target that
>> is
>> not a syntactically valid URI-reference is reserved for future
>> extensions (so clients ignore it for now).
> This looks like the more promising option.
>> Another one would be to use a different header, such as Link-
>> Template,
>> defined in version 00 of the draft
>> (<http://tools.ietf.org/html/draft-nottingham-http-link-header-
>> 00#section-5>).
> The problem with that is the lack of equal treatment this whole
> draft is trying to establish for Link header/element. This will also
> stand in the way of the new suggestion to simplify /site-meta to
> switch to a simple text document with Link header records (with the
> "Link: " stripped).
>> Personally, I'd like to see this move ahead without any dependency on
>> URI templates.
> I agree. There is urgent need in getting this spec finalized and the
> templates discussion is far from conclusion. But there are enough
> compelling reasons to bake into this spec support for such future
> extensions. I think the suggestion to ignore non-compliant URIs is
> the best option, and I would prefer to see it indicated in the ABNF,
> but if not, a simple clarification would suffice.

Mark Nottingham     http://www.mnot.net/
Received on Wednesday, 3 December 2008 01:37:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:47 UTC