ietf-xml-mime
[Top] [All Lists]

Re: Negotiated Content Delivery: Maxmimizing Information

1999-05-11 01:16:54

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.

Then I fail to see the point of adding the tree. Nearly equivalent rules would
have apply to it, the same procedures, and it doesn't serve to distinguish XML
usage.

Unless you can explain why you think the present registration procedure isn't
working for XML I fail to see the point of having a new one that isn't going to
be able to be materially different from the old.

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.

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.)

No, it says that types in the IETF tree have to be backed up with an RFC, and
it is NOT obvious or even correct that you're talking about the IETF tree only
here. You were responding to my proposal, and my proposal was in no way limited
to the IETF tree.

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.

I'm sorry, but this is nonsensical in that I'm not talking about registration
in the IETF tree.

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).

The problem is it won't work. The rules for these things require substantive
review. You cannot avoid this review and automate the process by setting up a
new registration tree; there would be tremendous objection to attempting to
circumvent the review process.

It took years of wrangling to get the vnd. and prs. trees approved and the
rules for registration in them lightened to the point where people would use
them, and to this day there are plenty of people who don't think we did the
right thing when we did this. Every single time I approve one of these things I
think about whether or not I'm making an egregious blunder that is going to
wreck the whole process.

It is my assessment that a proposal which lifts even more of the review
requirements, especially when there doesn't solve any current problem, is going
to be a total nonstarter.

And believe me, it isn't because I love reviewing the things that I say this.

                                Ned

<Prev in Thread] Current Thread [Next in Thread>