From: Ned Freed <Ned(_dot_)Freed(_at_)INNOSOFT(_dot_)COM>
On Mon, 10 May 1999, Ned Freed wrote:
No, the point of having different registration authorities is to allow
different rulesets to be brought to bear on different classes of media
types.
So where it the problem?...the different ruleset is the automated
registration for a definite class of documents on the provision of a DTD or
schema.
And insofar as the W3C is concerned, my understanding is that they don't
want to act as a registration authority for XML types. I haven't heard any
other organizations suggested that would be appropriate for this job.
Which is why I didn't suggest that they should act: merely that they, and
IETF, agree on someone to act as registrar. I could do it (through Academia
Sinica, for example). Because the procedure is automated, the registrar is
nominal. W3C needs to give some consent because they are the trademark
holders of XML, not because they need be principals.
And if you assume that the W3C wanted its own tree where its own rules
would apply, it would be silly to restrict it to XML. As such, you'd
likely
end up with a "w3c." facet.
No, I was not assuming that W3C wanted its own tree. That is why I did not
call the facet "w3c.".
Also, where did this requirement for orthogonality spring from?
It isn't a requirement, it is just a common sense concern. I think it is
inevitable that the IETF will use XML for some of its future work. But
such
types will be registered in the IETF tree, not an XML tree -- I can assure
you
that the idea that the IETF would be forced to use an "xml." or worse
"w3c."
tree and hence someone else would have this sort of control over the
IETF's use
of something it created is a complete anathema to many, and hence is a
100%
complete nonstarer.
You are assuming a step which I am not: that all XML must be registered
using the xml. registration tree. It would be a service made available for
convenience; if it were a new top-level MIME type, then one would expect
everyone to use it.
So what you end up with is a registration tree designed to capture all
registrations of a given type that cannot possibly get all the
registrations
it is supposed to. And that makes it fairly useless in my book.
If that was what I was proposing, I would agree with you.
All new MIME media types require writing a specification (an RFC).
No they do not. Read RFC 2048 (which as it happens I wrote).
I know you wrote it: we are indebted to you, it is a great thing. But that
is not what you wrote:
"2.1.1. IETF Tree
The IETF tree is intended for types of general interest to the
Internet Community. Registration in the IETF tree requires approval
by the IESG and publication of the media type registration as some
form of RFC."
That says that new MIME types require an RFC (from my context it should be
obvious that I am talking about MIME types in the default, IETF, tree,
because my proposal is based on MIME types in other registration trees not
requiring an RFC.)
Again, I'm not suggest a prefix that goes before the registration facet,
I'm
suggesting one that goes after it.
And I again I'm saying that RFC 2048 only allows, in its plain reading,
registration of specific media-content types. I cannot see where it allows
bulk open-ended registrations by registering a prefix.
And the media types registration process has shown that it can handle one
registration a day if need be. Moreover, such a need is unlikely to exist
since
only a subset of all the DTDs that are announced will actually need a
media
type.
I agree that now that vendors are starting to use vnd. vendor tree, things
are not grim. My point is this: it would be convenient and useful to have an
automated procedure which circumvented the need for an RFC for each MIME
type, which RFC 2048 requires (as quoted above).
Because, as far as I can construe RFC 2048, there is no scope to
bulk-declare prefixes, the only solution I could see is a registration tree.
However, it may well be, as you advise, that this would be more trouble than
it is worth. Especially because the kind of information that I am
suggesting would be needed for registration (the schema) should be available
in the document itself, as a DOCTYPE or schema or namespace declaration.
Rick Jelliffe