ietf-822
[Top] [All Lists]

Re: transfer-encodings on subtypes of "message"

1995-06-07 09:41:05
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
fallback).

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
message/rfc822?

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