[Top] [All Lists]

RE: Re[2]: yet another way to indicate related MIME body parts

1993-10-28 21:27:29
Let's see. For each header-set header, you have to register a type, right?
Where's the huge overhead involved in registering a subtype of multipart at
the same time? I see no overhead here at all!
I'm sorry, but this is nothing short of a complete red herring.

I don't understand such trivialization of concern for administrative
overhead.  We are already experiencing problems and questions about
Mime content-type administration; I would think that an effort to
greatly reduce one portion of consumption would meet with some warmth,
rather than such heat.
I've tried very hard to figure out what prompted you to say this, but I must
confess that the reasoning here still appears completely specious to me.

First of all, I am aware of no "administrative overhead" problem that needs to
be solved. (I note in passing that once again the supposed benefits of the
header-set proposal have shifted. There's isn't a single, solitary word about
registration overhead in the current draft.)

We have a real need to get the right things registered in a timely fashion. The
delay here is in deciding what the right things are, how they are
parameterized, and how they are canonicalized. Once these issues are settled
registration has always been, and continues to be, a snap. The registration
process is simple -- it getting things into a state where the registration
process can be used that's hard. (I might also add that this whole header-set
debate is to blame for much of the delay in this area. No smiley appears here
because I'm completely serious about this.)

You seem to be saying that registering a subtype under multipart in parallel
with a subtype under application adds an unreasonable amount of overhead. I
cannot imagine *any* competently run registration process where this would be
the case. (It certainly does not seem to apply to the IANA process, which seems
to be capable of dealing with multitudinous MIME object registrations quite
nicely. See RFC1340 for incontestable proof of this.)

And of course there's what happens after the registration process is complete:
deployment. You have heard from at least three MIME implementors that the
unparameterized header-set scheme is an implementation nightmare.

I see the process as follows:

(1) Produce a specification by:
    (a) Determining that a need exists.
    (b) Define canonical form(s).
    (c) Define parameters.
    (d) Name things.
(2) Registration.
(3) Implementation.
(4) Deployment.

Let's see. (1) is quite difficult in many cases and can take months or years.
(2) is a triviality -- send it to IANA and they put it in right subtype
directories and add it to the registry document. (I cannot imagine an elapsed
time of any more than 30 minutes for the entire operation.) (3) is very
dependent on the specification and can range from adding a viewer and a line to
a mailcap file to completely rewriting lots of code. (4) is largely outside our

So, in attempting to optimize this 4-step process you have picked the single
most efficient step, a step which is unnoticeable compared to any of the
others. In attempting to (at best) halve the time spent in this unnoticeable
step you appear to be willing to sacrifice both expeditious implementation and
timely production of specifications. The phrase "penny-wise and dollar-foolish"
comes to mind...

You may see this as trivialization of concern for administrative overhead.
Fine. I prefer to see it as what it really is: Calling a spade a spade.


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