One of the more common Content-Encodings I'm seeing right now is
uuencoded-compressed. Would this be Content-Encoding "BASE64"? How
does one talk about the compression? Or is it simply not a valid
encoding?
No, the encoding table specified for Base64 does not match the encoding
table which uuencode uses. The technique is extraordinarily similar,
however. It would be a Very Good thing if uuencode were included in
the standard, regardless of its warts (using trailing blanks for
instance). Specifying that the uuencode used be the version which does
a checksum for each line avoids the trailing blank problem and provides
a bit more assurance that "it worked" ...
As for compression .. It belongs in either Content-Encoding: or
Content-Type:. What you really have is a sequence of possible
encodings which can be placed on a file, as we all know. It would be
good to be able to specify a sequence of encodings which were applied
to the data. We might as well seperate the ultimate data type from the
encodings used, as the end-user is going to be mainly interested in
that and rather uninterested in what magic was performed to get it to
him/her.
Suggestion:
Content-Type := type [ ";" ver-num [ ";" 1#resource-ref ]]
[In other words, unchanged from before]
Content-Encoding := 1#content-encoding-type
content-encoding-type := "Base64" /
"UUENCODE" /
"UUENCODE-CRC" /
"HEXADECIMAL" /
"QUOTED-PRINTABLE" /
"8BIT" / "BINARY" /
"7BIT" /
"LZW-COMPRESS" /
"HUFF-COMPRESS" /
"other-COMPRESS" /
"X-"atom
Example:
Content-Type: PPM
Content-Encoding: uuencode-crc lzw-compress
I am having a hard time coming up with an example which would include
more levels of encoding. But why limit ourselves needlessly?
The Content-Encoding: likely should be a comma-seperated list. This
is to allow for richer encoding types. Repeating the example above:
Content-Type: PPM
Content-Encoding: uuencode crc, lzw-compress 12bit
David