[Top] [All Lists]

RFC XXXX, RFC ZZZZ, and a call for concensus (Was: My greatest fear)

1991-08-26 00:55:25

I have not yet seen a reasonable justification for nested encoding, so
I propose that we vote on whether to allow it in RFC-XXXX or not.

I believe John, Stef, Ned, (Mark?), and myself are agreed on the following
statement:  nested decoding should not be required of RFC-XXXX UAs.

Unless someone violently objects, can everyone out there agree on this
statement pending the November WG meeting?


Indeed, as Ned states,

...The 822 extensions seem firm enough to me. The SMTP extensions
are the place where all the trouble lies...

the question is how to deal with RFC-ZZZZ and 821.  If RFC-ZZZZ->821
gateways are pure and ignore RFC-XXXX content-transfer-encodings, then we
land in Mark's 'silly' gateway problem.  We have two bad solutions:

A) Reopen the RFC-XXXX discussion to require a high level header indicating
    the 'highest' content-transfer-encoding and

B) Build RFC-ZZZZ->821 Gateways such that they dynamically determine
   which encoding to use by looking at the bytes.

And we have two good solutions:

1) Build RFC-ZZZZ->821 Gateways such that they understand the RFC-XXXX
   content-transfer-encodings as per Ned's latest suggestions.

2) Ignore the problem.  Allow mail encoded by a ZZZZ->821 Gateway to be
   decoded by a 821->ZZZZ Gateway, by the user, by a nested decoding
   RFC-XXXX UA, by /dev/null, or by divine intervention.

Before the debate begins (ha!), is everyone agreed that RFC-XXXX has
nothing to do with this?  Does everyone agree that either (1) or (2)
is better than (A) or (B)?

leo j mclaughlin iii

<Prev in Thread] Current Thread [Next in Thread>