relation registry (was: bug in default base URI in "HTTP Header Linking"?)

Julian Reschke wrote on the HTTP list:
 
>> If the relationship is a relative URI, its base URI MUST be considered
>> to be "http://www.iana.org/assignments/link-relations.html#",
>>  -- http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt
 
>> Is that really what you meant?
>> ...
 
> Know issue, see also 
> <http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0543.html>.

Oops, I forgot Mark's draft, sorry.  Background, the MIME subtype
for OpenSearch is still unregistered, and after whining about it
for some months and I finally arrived at the conclusion that this
is a case of <URL:http://en.wikipedia.org/wiki/Template:Sofixit>.

While at it I saw that atom:link rel="search" is also not yet
registered, and that IANA missed the base IRI fine print in
<http://tools.ietf.org/html/rfc4287#section-4.2.7>.  Telling IANA
how to fix this is simple, but it makes no sense to fix it twice.

IOW, are you sure that you want <ifragment>s for the relations ?
IMO the RFC 4287 <ipath> approach is clearer, it just needs to
be implemented.  Here's what I've written in the OpenSearch I-D:

| 3.  IANA Considerations
|
| IANA is asked to create one URL for each registered atom:link
| relation below <http://www.iana.org/assignments/relation/> as
| specified in [RFC4287] section 4.2.7.2.  All existing atom:link
| relation templates should get the corresponding URLs, e.g.,
| "current" at <http://www.iana.org/assignments/relation/current>.
|
| For the remaining registered atom:link relations without template
| the corresponding URLs should redirect to the atom:link relation
| registry, e.g., for "alternate" the URL
| <http://www.iana.org/assignments/relation/alternate> can be
| redirected to the atom:link relation registry.  For consistency
| the URL <http://www.iana.org/assignments/relation/> should be
| used for the atom:link registry.
|
| 3.1.  atom:link rel="search"
|
| Below you find the [RFC4287] registration template for the
| atom:link "search" relation under
| <http://www.iana.org/assignments/relation/>:
[...]

Most points TBD, the opensearch-00 draft is just a skeleton, and
it's perfectly irrelevant *where* the relation registry is fixed,
as long as it's a.s.a.p. and also clear *how* it has to be fixed.

Use <ifragment> as in Mark's draft, or <ipath> as in RFC 4287 ?

How many months do you expect until Mark's draft is ready for a
"PubReq" ?  If it's roughly this year the OpenSearch draft could
simply use Mark's I-D as normative reference (instead of 4287),
and skip the convoluted "relation registry" cleanup business...

 Frank

Received on Thursday, 19 June 2008 21:32:50 UTC