ietf-822
[Top] [All Lists]

Re: Massive Content-Type definition ideas & Gopher

1993-06-09 14:06:23
To:  ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
Subject:  Re: Massive Content-Type definition ideas & Gopher
Date:  Wed, 9 Jun 1993 14:24:15 -0500

At 10:02 AM 6/9/93 -0700, David Herron wrote (but is probably not to be
blamed for):
- Go ahead and define COMPRESSED-<encoding> encodings.

I think that lumping the compression and the encoding into one identifier
is wrong.  This *IS* a compound operation, and I would prefer that the
syntax reflect it rather than try to euphemize it away.

I'm aware that nested encodings and conversions are Not Popular, but
exactly who is this syntax intended to fool?  Either nested encoding or
conversions are not ALWAYS a bad thing, or this compression idea IS a bad
thing.

Not clear.  Nesting is a useful operation, but being able to mix-and-match
multiple encodings with multiple compression algorithms isn't necessarily so.
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.

I see three advantages to making "compressed" a first-class citizen of one
sort or another:

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.

2. It makes it possible to use compression with private encodings. 
"compressed-x-uuencode" is just another identifier.  Even if I know how to
"x-uuencode" and I know how to "compressed", it cannot occur to me that
this encoding is a "compressed" followed by an "x-uuencode".  Or if it does
occur to me, it can occur only heuristically; I get no support from the
syntax.

Private encodings require bilateral agreement.  If you're going to agree with
someone to use a particular encoding, you can compress it if you want, and
you can call it anything that begins with "x-".

3. It is Truthful and Honest and Morally Good.  :-)

I don't see anything dishonest about "base64-compressed".

Isn't it about time that there was a standard for doing return receipts, at
the very least so that I could teach my mailer to hide stuff like this?

Yep.  (But the header is the wrong place for it.)

Keith

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