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

On 10/12/2008, at 9:46 PM, Phil Archer wrote:

>
>
> Mark Nottingham wrote:
>> 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.
>
> Yes, I agree that the RFC 5226 'Specification Required' idea fits  
> here. I just have a slight niggle, I forget the name now but there  
> was a new body set up a few months back that had the appearance of  
> trying to do at least some of the W3C work but without the overhead  
> that the Consortium is perceived to require, and there's the case of  
> the WAP forum that became OMA - would that have always been a  
> recognised body or did that become such after it became OMA and so  
> on. It's a bit grey that's all.

It is a bit grey, perhaps necessarily. However, worst case, if *any*  
group of people wants to get something registered, they could do this  
with an Informational RFC, which is a well-understood and relatively  
brief process.


>>> 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?
>
> You misunderstand me. I'm the last person to propose a wiki as the  
> authoritative central registry (for all the reasons you give). And I  
> think I misunderstood you too. You're saying that rel types would be  
> added to the IANA registry /automatically/ iff they met the  
> Specification Required rule? Then I agree completely.

Yes.


> What I was concerned about was that the different documents with  
> change control under different organisations would *be* the  
> registry, in which case one would need a handy guide to where those  
> documents were - and a wiki could do that. But the IANA registry is  
> the best way and if that's to happen then I'll shut up.
>
>
>
>> 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/
>
> -- 
> Phil Archer
> w. http://philarcher.org/


--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 10 December 2008 10:51:36 UTC