Re: Reviving HTTP Header Linking: Some code and use-cases

On Mar 12, 2008, at 3:32 PM, Brian Smith wrote:
> Julian Reschke wrote:
>> So making this a non-specific Atom registry probably requires
>> making these relations have generic semantics.
>
> Some (most?) of them already have pretty generic semantics. But,  
> others
> don't, and if you try to make them generic, then they will stop  
> working
> for AtomPub. AtomPub requires "edit" to link to an Atom Entry, for
> example.

That doesn't matter.  If an AtomPub application is following
links in Atom content, it is reasonable to believe that such
a requirement will be true.  If an AtomPub application is
following edit links in random content, then it is acting
outside that protocol and will just ignore the "requirement".
The requirement is on AtomPub, not the meaning of rel="edit".

It is best to have one and only one registry, even if a few
relations have entirely different meanings in different contexts.
It is still valuable to know that those contexts exist.

>> RFC 4287 says that relative references
>> (<http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.7.2>)
>> must be simple names:
>>
>> "Note that use of a relative reference other than a simple
>> name is not allowed."
>
> <snip>
>
>> So it seems to me that this *is* URI resolution.
>
> Right, but only after you've verified that the document is  
> conformant to
> RFC 4287. If you aren't sure that the link relation is conformant,  
> then
> you can't use IRI resolution to verify it. Also, you have to make sure
> that whatever library you are using to do the IRI resolution actually
> supports IRIs, and not just URIs.

No, you can do anything you like with the link relation.  There
are absolutely no universal requirements on the Internet -- they
all exist within the context of a given interoperation.  Outside
of that context, data is just data.  E.g., email addresses are
not just used for sending email.

> If the link header is going to be (re-)standardized, it has to be
> specified in a new standard. It is out of scope for HTTPbis. And, RFC
> 2277 says all new IETF standards must support UTF-8, which implies  
> that
> all new IETF standards for URI processing must support IRIs.

First, HTTP header fields and methods are a flat namespace.
Link and PATCH were defined in the original HTTP specifications
and only removed to to a lack of known implementations.  They
would only be "new" if their definitions were substantially
changed, which I don't see happening.  Removing Link from 2616
was a very bad editorial decision and I don't see how putting
it back in can be seen as anything other than an editorial
correction -- it is not as if we are changing the meaning of
HTTP in the process.

Second, there is no such requirement for IRIs -- URIs are fully
capable of describing all possible IRIs (by definition) and thus
do not prevent i18n.

....Roy

Received on Wednesday, 12 March 2008 23:55:14 UTC