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/
