Re: [EAI] [IETF] Content Issues [

[John C Klensin <[e-mail]>]

--On Sunday, October 16, 2016 3:39 PM +0000 Shawn Steele
<[e-mail]> wrote:

> I suppose it might depend on how it is configured?  I suppose
> the on-behalf-of or whatever could be tricky, but it is
> already munging the message.  So maybe it could just ignore
> the sender info?
> 
> Certainly there isn't anything blocking the digest version?

As long as the digest version does not contain non-ASCII
headers.  Remembering that the EAI specs encourage getting rid
of encoded words in favor of Unicode in UTF-8 in the headers,
the digesting mechanism would have to be able to translate
non-ASCII header information back.  That is certainly feasible
but I'm not sure it ought to be our highest priority.  

The tools needed to do could be part of another issue that
affects broad deployment of SMTPUTF8 address and header
material.  Ned can check me on this, but I think our assumption
when MIME was being developed was that, when a message was being
forwarded and had non-trivial structure or a charset parameter
different from that of the person/MUA doing the forwarding, the
norm, perhaps the norm for most forwarded messages, would be
encapsulation of the original message.  As things have worked
out, sometimes we do that and sometime we just include the
forwarded message inline (I can't guess which approach is in the
majority).  If I have an fully-SMTPUTF8-capable environment,
receive a message that requires non-ASCII header and address
handling, and want to forward that message to a colleagues whose
systems are less capable, I'm going to have to either fully
encapsulate the original message and any relevant header
material or I have a downgrading problem.  That problem is
closely related to the issues discussed in RFC 6857 and 6858,
but the POP and IMAP cases can assume some level of cooperation
and choice about client-server pairs and configuration.  The
forwarding case generally cannot.

Harish and Nalini, many of these issues were discussed at length
(on the list, in meetings (IETF and the workshops), and in the
halls) during and after the development of the EAI specs.
Except for some asides in RFC 6530 and elsewhere, the material
has not been written down.  As I think about this discussion, I
think a great first step in what you are trying to accomplish
would be to try to simply draw this material together into an
Informational document that discusses barriers and impediments
to deployment.  It seems to me that your current draft goes
several steps beyond that and toward best practices.  In that
context, some of my complaints and quibbling about technical
details are premature and a result of there not being an
adequate foundation.

best,
   john