ietf-822
[Top] [All Lists]

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

1991-08-26 02:23:38
I believe John, Stef, Ned, (Mark?), and myself are agreed on the following
statement:  nested decoding should not be required of RFC-XXXX UAs.
   I believe that I'm in agreement with this, but...
   -- I'm not sure what it means unless we figure out a way to prevent 
anything (including gateways) from ever creating one of these. I have
argued, I think with some agreement, that such a bad cannot be expected 
to work.
   -- I understand what options a UA which does not support this has in 
handling it.  Regardless of what behavior I would prefer, can it 
recognize this case without having the ability to decode and reject the 
message?  Or is it impossible to recognize the case such that the 
multiply-encoded thing always gets dumped on the user?
  Now, as I understand it, Ned's (pragmatic and reasonable) position is 
that the UA must recognize the nested encoding case because there is no 
way to prevent it from arising.  And, because users really want 
intelligable mail delivery, rather than technical excuses, once the 
situation is recognized, the nested encoding just has to be decoded.  
  That makes a statement that a "UA is not required to support nested 
encodings" useless in practice.
  Maybe I'm completely confused, but I think that is a lot of what has 
been driving this discussion.

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)?

With two qualifications, yes.
  Qualification 1: There are alternatives other than 1 and 2, including 
the "designated converter" plan that Stef and I floated some months ago. 
Used in combination with Ned's proposal or some near-variant (which is, 
I think, what we "don't convert" types have been advocating all the way 
along), it eliminates both the imposition of serious encoding complexity
on an MTA that "merely" wants to pass 8bit traffic through *and* the UA
complexity of nested encoding.
  Qualification 2: The more one says "this is an MTA problem", the more 
reasonable it becomes to say "transport encodings are an envelope 
problem and not a header one".  That *does* have something to do with 
RFC-XXXX.
   --john

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