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/
