So far, this working group has been considering encodings to be
defined as a set of (in some ways) "parallel" attributes. For
example, an object is:
encoded-in-Base64 AND checksummed AND it's-fax-in-TIFF-format
However, an object is actually a "serial" encoding which converts it
from a concept (like "noise in the air") to a mailable body part
(lines of text). For example:
it's-a-fax WHICH-WE encoded-in-TIFF-format WHICH-WE
added-a-checksum-to WHICH-WE encoded-in-Base64
Suppose we define the encoding description as a set of encoding
elements which form a statement of the algorithm(s) used in the
encoding process, and, IN THE ORDER NEEDED TO DECODE the object.
The above might be described, for example (and the syntax is only an
idea):
base64 | crc-16 | tiff | fax
Similarly,
uuencode | lzw | tar
defines an "tar" file which has been compressed and then uuencoded.
Mail user programs can now mix and match elements as appropriate to
the data and recipients.
As pointed out above, checksums can be encoding elements. So, possibly
can characterset.
iso-8859/3 | text
defines a text body part (where text is defined to be UTF/10646) which
has been encoded into 8859/3
Encryption can also an encoding element, although I suspect that while
uuencode | des-56 | text
would be OK
uuencode | des-56 | lzw | crc-32 | tiff | fax
is giving away too much information and that you probably want to
uuencode | des-56 | message
and put the rest in the encoding in the encrypted message.
David