Re: gzip/deflate compression/encoding

> In <[email protected]> [email protected] writes:

> >Repeating for the Nth time: Media types are supposed to be used to identify
> >types of media, not general compression schemes or other stuff. Section 2.2.1
> >of RFC 2048 is very clear about this, and this requirement remains unchanged in
> >section 4.1 of draft-freed-media-type-reg-04.txt. As such, any attempt to
> >register such a media type will be immediately rejected.

> >If you want to play around with general compression schemes and MIME in a
> >standards-compliant way, nothing prevents you from using x-gzip or whatever
> >as a CTE.

> I don't want to play around with x-gzip. I am trying to see what options
> are available within the present MIME setup.

There's only one: Define one or more new CTEs.

> The problem appears to be that there might be a largish number of
> compression algorithms one might wish to use,

"Might wish" != "really need"
 
> combined with a variety of ways of encoding them into 8bit.

There is certainly no reason for there to be more than one of these.

> That would seem to require a rather large
> number of new CTEs to be registered.

Doesn't follow.

> One would like to be able to write

>    Content-Transfer-Encoding: base64; compression=gzip

> but that is incompatible with the present syntax, and it is doubtful it
> could be introduced as an extension without upping the MIME-Version
> number.

Correct.

> Essentially, we have three bits of information to convey:

> The CTE
> The compression algorithm
> The media-type of the uncompressed object.

> I tried to squash two of those into the Content-Type. If that is not to be
> allowed, then please suggest another method. A new Content-Compression
> header seems the only other alternative.

That's also a nonstarter for reasons previously given.

The only option is to define one or more new CTEs. Period.

				Ned