- From: Phil Archer <phil@philarcher.org>
- Date: Wed, 10 Dec 2008 10:46:09 +0000
- To: Mark Nottingham <mnot@mnot.net>
- 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>
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. > > >> 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. 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/
Received on Wednesday, 10 December 2008 10:46:58 UTC