W3C home > Mailing lists > Public > public-html@w3.org > December 2008

Re: link relationship registration [was: New Version Notification for draft-nottingham-http-link-header-03]

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 10 Dec 2008 21:28:26 +1100
Cc: Dan Connolly <connolly@w3.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Atom Syntax <atom-syntax@imc.org>, www-tag@w3.org, HTML WG <public-html@w3.org>
Message-Id: <32192FF3-3588-4F64-BB4A-2DD9A8577E01@mnot.net>
To: Phil Archer <phil@philarcher.org>

On 10/12/2008, at 8:55 PM, Phil Archer wrote:
> Mark Nottingham wrote:
>> How about:
>>        <t>New relation types MUST correspond to a formal  
>> publication by a
>>           recognized standards body. In the case of registration  
>> for the IETF
>>           itself, the registration proposal MUST be published as an  
>> Standards-track RFC.</t>
>> Note that unlike media types, this does NOT require IESG approval  
>> for relation types from outside the IETF; rather, just a 'formal  
>> publication', which AIUI corresponds to the REC track in the W3C  
>> (but not Notes), OASIS standard, etc.
>> Feedback appreciated.
> I see what you're trying to do here, and, as someone with a rel type  
> registration request pending with IANA, I can only sympathise.  
> However, I see two problems:
> 1. Your proposed text entails the definition of a 'recognised  
> standards body' - that alone could cause controversy. Any list of  
> such bodies written today could well be out of date by this time  
> next year.

AIUI it's up to the IESG at time time of request; there doesn't need  
to be a list as such.

That said, it's starting to seem like the Specification Required  
approach mentioned by Julian might be a better fit.

> 2. I understand that the Web works by keeping things distributed  
> rather than centralised, but in this case, there would still be a  
> need for some sort of central 'list of registered relationship  
> types' to avoid two working groups in different standards bodies  
> coming up with new definitions for existing rel types. Now, to go  
> back to an older idea, /that/ could be a wiki - a simple table  
> giving the rel type, the description and the relevant formal  
> publication. But for this to work, the wiki would probably need to  
> be cited in the I-D/RFC and we're back to who is going to host that?

That would entail all sorts of process problems from the IETF, which  
already has a well-recognised body to handle this, IANA. It's a real  
challenge to get a URI into an IETF spec, much less a Wiki page. How  
will you prevent people from changing or deleting existing entries?  
Who will monitor it for abuse?

Beyond that, a wiki is in effect a first-come, first-served mechanism  
to avoid conflicts, and allowing URIs already serves that function;  
i.e., they already assure that two WGs won't define the same relation.  
The point of a central registry is to converge upon well-understood,  
well-defined and agreed upon link types that are of common value and  
can be reused.

The free-for-all that a wiki entails will result in (insert evil  
company here) grabbing a "common" name first and defining it in their  
interest, without consultation with the rest of the community;  
interoperability problems as people don't document their relation  
types well, or think about how they'll be used; and so on. Having a  
registry with some bar for entry is designed to encourage good design,  
interoperability, and grow the commons; it's not just there to avoid  
conflicts and be a pain in the posterior to impatient developers.

Despite how it seems sometimes.

> Phil.
>> On 02/12/2008, at 7:10 AM, Dan Connolly wrote:
>>> On Mon, 2008-12-01 at 12:11 +1100, Mark Nottingham wrote:
>>> [...]
>>>> I'm particularly interested in feedback regarding registration
>>>> requirements, as I think that's the biggest remaining sticking  
>>>> point.
>>>> Note that it was previously "IESG Approval"; I've changed it to  
>>>> "IETF
>>>> Review" (nee "IETF Consensus") so that a document is required.  
>>>> Also, I
>>>> believe this still accommodates other standards orgs (like the W3C)
>>>> using their processes to publish documents that register entries,  
>>>> just
>>>> as with media types.
>>> That would surprise me; while there is a significant overlap in the
>>> communities, the IETF does not, in general, accept consensus
>>> in the W3C community in place of consensus in its own community.
>>> The media type registration spec phrases it this way:
>>> 3.1.  Standards Tree
>>>  The standards tree is intended for types of general interest to the
>>>  Internet community.  Registrations in the standards tree MUST be
>>>  approved by the IESG and MUST correspond to a formal publication  
>>> by a
>>>  recognized standards body.  In the case of registration for the  
>>> IETF
>>>  itself ...
>>> -- http://tools.ietf.org/rfcmarkup?doc=4288#page-4
>>> -- 
>>> Dan Connolly, W3C http://www.w3.org/People/Connolly/
>>> gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
>> -- 
>> Mark Nottingham     http://www.mnot.net/
> -- 
> Phil Archer
> w. http://philarcher.org/

Mark Nottingham     http://www.mnot.net/
Received on Wednesday, 10 December 2008 10:29:10 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:40 UTC