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.

The problem appears to be that there might be a largish number of
compression algorithms one might wish to use, combined with a variety of
ways of encoding them into 8bit. That would seem to require a rather large
number of new CTEs to be registered.

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.

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.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email protected]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5