On Wed, 07 Jun 1995 09:35:12 +0200 you said:
I like your solution - it specifies a nice, clean algorithm to implement in
gateways, and leaves the burden of possibly recursively encoded message/foo
types where it belongs - in UAs that want to deal with newly defined types.
I'd be interested in a little more talk about this "burden" since I'm not
familiar with the "nested encoding rule" Ned referenced - if it applies at
all to message/rfc822.
How can a gateway (e.g. to a LAN mail system) which doesn't have a "user" to
provide advise, systematically deal with nested encodings?
For example, we currently attempt to parse nested message/rfc822 so that we
can give the cc:Mail user back his/her original attachments when a message
bounces (obviously parsing error reports is risky business, so we have a
If we send out a message with 8bit or binary C-T-E body parts (I use the term
with great trepidation ;-) which at some later point traverses a 8-to-7 bit
gateway, and at a later point bounces back to the sending system, is it
possible/likely that we would be faced with the need to do an outer level
decode of the body of the error report before we could even see the
Also, in Ned's earlier two-step proposal:
(1) Is it message/rfc822? If it is, check to see if its encoded
using quoted-printable or base64 and if so, flag it as an error.
Otherwise handle message/rfc822 recursively.
(2) Is it encoded as 7bit, quoted-printable, or base64? Stop if it
is, and if it isn't flag it as an error.
rule #2 doesn't make sense to me. Apparently it applies to all *other*
type/subtypes? Otherwise I don't understand the dual QP and base64 references
in the two rules.
Brent Stilley, Oklahoma State University, 113 Math Sciences, Stillwater, 74078