ietf-822
[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)?

enjoy,
leo j mclaughlin iii
ljm(_at_)ftp(_dot_)com


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