On Mon, 10 May 1999, Ned Freed wrote:
1a) What are the costs of adding xml- as a prefix to XML-based MIME types?
(Rick Jelliffe's proposal.)
There are actually three possible proposals in this space:
(1) Add a "xml." facet and corresponding registration tree. Again, this
requires writing a specification, and it is likely to be controversial
because this doesn't meet the criteria for a new registration tree and
also isn't orthogonal to existing trees.
Why doesnt it meet the criteria for new trees? The point of a
registration tree is to accomodate registration authorities other than
the IETF/RFC mechanism: a program administered by a registrar accepted by
W3C (the copyright holders) and IETF seems to meet the criteria as far as
I read them.
No, the point of having different registration authorities is to allow
different rulesets to be brought to bear on different classes of media types.
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.
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.
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.
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.
(2) Recommend/require that the names of XML-based types have "xml-" after
the registration facet.
The RFC for MIME media types does not allow for delegation of IETF
registration tree names, which is what you seem to suggest here.
No, what said is that the prefix would appear after the registration
facet, that is, xml-, vnd.xml-, prs.vnd.xml-, and possibly w3c.xml-.
All new MIME media types require writing a specification (an RFC).
No they do not. Read RFC 2048 (which as it happens I wrote).
The only ways around this is either to rewrite the MIME media type spec,
or to add a registration tree. I don't see how it can be done inside the XML
spec, under the current procedures. If the MIME spec is rewritten to allow
the registration of a prefix (application/xml-*) and to allow people to use
that prefix without creating an RFC, we increase the likelihood for
collision: this is why we need a registration tree.
Again, I'm not suggest a prefix that goes before the registration facet, I'm
suggesting one that goes after it.
We are easily getting a DTD a day being announced, and many more being
created. There is no way they can all be vetted adequately; and they do
not need to be vetted if they use XML: it already has the RFC out. They
should be able to piggyback on top of the XML RFC, and just provide
minimal extra information.
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.
This is why I think it is more than just an issue of the inconvenience of
getting an XML registration tree up: I think other approaches will cause
more trouble.
I can assure you that this assessment is incorrect.
Ned