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.
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