On 16/09/2009, at 7:46 PM, Sam Johnston wrote:
On Wed, Sep 16, 2009 at 3:21 AM, Mark Nottingham <[email protected]>
wrote:
On 11/09/2009, at 11:17 PM, Sam Johnston wrote:
One nitpick about the process is that it seems a request can be
denied with a suggestion for another relation (for example we might
prefer to use something like "push" or "notif[y|ier|ication|
ications" rather than "hub" for this one) but then that would
require restarting the process where it should proceed to
registration immediately if the change is accepted by the applicant.
Yes, but is the overhead really that onerous?
Perhaps not, and there could well be some delay in acceptance if
committees are involved. My worry is that if we don't streamline our
processes as much as possible (see Ian's suggestion about IANA
maintaining a RelExtensions style wiki) then people will do as they
please anyway - see rel="hub", rev="canonical", etc.
Interesting examples; the "hub" people are actively engaging
(finally), and I've already talked to some of the "canonical" folks
about doing an I-D once the Link draft is an RFC.
Would it be possible then to support multiple references so that
people can see at a glance that a given relation is implemented as
described in multiple formats (rather than just the first format
that happened to register it)? May well not be worth the maintenance
effort.
How about adding a new field for references to more information about
how a relation is used in a particular context (scoped by context
media type)?
E.g.,
References regarding use in specific contexts:
text/html: [HTML5]
application/atom+xml: [RFC4287]
One concern here is that there are going to be questions about
authority; while it's fine for the HTML5 crowd to dictate what happens
when you see a particular relation in an HTML context, what happens
when someone comes along and defines a spec for a media type they
don't own? We'd need some additional guidance about amending
registrations, I think, which is doable, but it'll make things more
complex.
What do people think about this generally? Ian, would this help you at
all?
We'd still need a generic 'reference' field for the defining document
of the relation itself, but in some cases the current references would
change to be context references; e.g.,
Relation Name: chapter
Description: Refers to a chapter in a collection of
resources.
Reference: [this specification]
References regarding use in specific contexts:
text/html: [W3C.REC-html401-19991224]
--
Mark Nottingham http://www.mnot.net/