On 03.10.2010 19:21, Willy Tarreau wrote:
> On Sun, Oct 03, 2010 at 07:06:22PM +0200, Julian Reschke wrote:
>>> In case nobody would object, how could we move on ? Doing so involves a
>>> new header ("content-status"), so that should probably require proper
>>
>> Do we really need Content-Status?
>
> I don't know. Maybe we can deduce it from the presence of the Link
> headers. But when reading the Link header spec below :
> http://tools.ietf.org/id/draft-nottingham-http-link-header-10.txt
>
> I did not get the impression that the header is supposed to cause UAs
> to request specific user action. But maybe we could imagine that some
> specific values of the header are automatically detected by UAs and
> make them ask the user for chosing the most suitable version. I'm not
Well, rel=stylesheet already "makes" UA do something.
> certain this practice is good for the long term (eg: should browser
> present a popup when encountering unknown types). Probably that Mark
No, the browser certainly should *not* display a popup for unknown types :-)
> has some insights on the best way to use the header.
>
>>> registration. Also, I've not seen any registry for all relation-types,
>>> so we might need to define a few. Also, does a draft need to be written
>>> to advance ?
>>
>> The Link Relations registry is defined in RFC5988-to-be
>> (<http://greenbytes.de/tech/webdav/#draft-nottingham-http-link-header>).
>
> So if I understand it correctly, we refer to the types enumerated in
> RFC4287 ? Then we have 5 available types : "alternate", "related", "self",
> "enclosure", and "via". I thought that "alternate" would fit but it's
> indicated that no more than one link may be present, which limits the
> usefulness.
No no, I just was pointing out that this is the new definition of the
registry.
I would suggest that we either pick one of those listed in
http://www.iana.org/assignments/link-relations/link-relations.txt
... - "latest-version" might make sense, or define a new one.
Best regards, Julian