Re: Negotiated Content Delivery: Maxmimizing Information

[Ned Freed <Ned.Freed@xxxxxxxxxxxx>]

> 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