[Top] [All Lists]

Re: Massive Content-Type definition ideas & Gopher

1993-06-09 14:26:56
At  5:05 PM 6/9/93 -0400, Keith Moore wrote:
1. It reduces the number of names that need to be registered and handled.

And increases the number of lists that need to be registered and handled.

No, it adds a single keyword.  It could even be an on/off content-type

And there's no point to changing the current MIME syntax just to add one or
two compression algorithms.  It's not necessary, and not worth the effort.

You haven't changed the syntax for metamail-like systems that use tables of
filters.  But you HAVE changed the syntax for systems that don't have
pipes.  I *will* have to deal specially with each and every one of your new
encodings, in code.  Except that I have no tools to parse this information,
since you're hiding two pieces of info in one, and not providing any
special characters to delimit them.

Promise me that ALL encodings with the compression scheme WILL begin with
"compressed-" and be followed by some other encoding type, and that NO
encoding types will be registered with an initial "compressed-" prefix
unless they follow this rule, and I will consider that you have made a
decision I dislike but can live with.  It's a mongrel name-space, but at
least it is parseable.

Without such language, there is no reason someone could not register an
encoding of "compressed-fubar" that did NOT use the standard compression
scheme.  Nor any reason someone could not register an encoding of
"squeezed-foobar" that DID use the compression scheme.

"The IANA would never do that," is not an answer that makes me happy.  I
would like it to be spelled out.  Unwritten law is sometimes forgotten.

Steve Dorner, Qualcomm Inc.
Oldthinkers unbellyfeel IngSoc.

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