Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard

On 31/08/2009, at 11:42 PM, Joe Gregorio wrote:

> On Sat, Aug 29, 2009 at 10:23 PM, Ian Hickson <> wrote:
> On Thu, 20 Aug 2009, Mark Nottingham wrote:
> > On 31/07/2009, at 10:20 AM, Ian Hickson wrote:
> > > Similarly, the registry should define whether or not link  
> relations
> > > are allowed at the document level (<link rel>, Link:) and at the
> > > phrasing level (<a rel>, <area rel>). Some types in HTML5 only  
> apply
> > > to one or the other.
> >
> > That's a job for HTML5 as an application of the relations, not the
> > registry.
> So every time someone adds something to the registry, we have to  
> update
> HTML5 to say whether that keyword can be used with HTML?
> I'd like to intertwine this point and the following point:
> > > I would like to request that the registration mechanism be made
> > > significantly simpler than the one described in the spec. For  
> example,
> > > a simple mechanism could be just to edit a wiki listing all the
> > > extensions.
> >
> > In the IETF, IANA is the mechanism for managing registries like  
> this.
> Regardless of who manages the registry, I would like to request that  
> the
> registration mechanism be made significantly simpler than the one
> described in the spec.
> The registration mechanism calls for creating a document, having it  
> discussed, and then
> updating the registry. While that seems like a burden, I'll turn it  
> around and point
> out that it gives current active formats the ability to review the  
> meaning
> and request verbiage be added to cover their particular format, such
> as the examples you gave above about document level and phrasing  
> level for HTML5.

Yes. It's very easy to define something as "whatever I mean, no more,  
no less," but much more useful to define it precisely -- if it's to be  
reused by others. See the current discussion around 'duplicate', for  

> Regardless, I don't believe a flat registry with one document per  
> rel type is going
> to be sufficient. There should be a mechanism within the registry to  
> specify per-media-type
> 'clarifications' for each rel type. This is particularly important  
> in the case of new
> formats that come along later, like JSON has in the past couple  
> years, that
> weren't around when a rel value was registered.

I strongly disagree; the whole point of registered relations is that  
their semantics are independent of format. While there are certainly  
format-specific considerations for each, that can be handled in the  
world of that format (whether it's in a huge, monolithic spec, or  
something more agile).

> For example, a new media-type Foo comes along in two years, wants to  
> use
> the link header and all the registered relations make sense except  
> 'up', how would
> that be noted in the registry?

It won't; A media type shouldn't say anything about headers. If it  
wants to use links internally, it should either reuse the framework in  
this draft, or (sub-optimally), define its own.

Mark Nottingham

Received on Tuesday, 1 September 2009 02:38:49 UTC