In <01LQ2KJ1KAXY00004T(_at_)mauve(_dot_)mrochek(_dot_)com>
ned+ietf-822(_at_)mrochek(_dot_)com 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: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk 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