[EAI] [IETF] Barriers to Deployment [ was: Content Issues]

[<[e-mail]>]

John,

>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.


I like the idea of a "Barriers to Deployment" document very much.   

I have also been following the discussion of the subscription to email lists.   I think that joining such lists is one of the important uses of email addresses.  I was just talking this morning to one of the not-very-computer-literate older ladies in the neighborhood and she was telling me about how useful she found the neighborhood email group to be.  So, I can see that this is something many people (not just IETFers!) probably find useful.

Harish & I will put our heads together and put together some bullet points on the potential "Barriers to Deployment" draft and then come back to the list for comments on major issues to be covered.

Meanwhile, Harish is trying to get in touch with Don at the UASG group.

I will also ask some of the other people from Latin America / Africa who may be interested in this topic to join the IMA email list.

We want to schedule a Bar BoF to discuss these topics in Seoul.  I am thinking Thursday morning breakfast meeting.   Maybe people can respond to me / Harish privately to let us know if there are conflicts.   The title of the Bar BoF will be "Deployment Issues for IDN / IEA".   This way, we can start working on at least consolidating the problems.  Then, work quietly to resolve them.

Thoughts? 
Thanks,


Nalini Elkins (for Nalini & Harish)
Inside Products, Inc.
www.insidethestack.com
[phone]



________________________________
From: John C Klensin <[e-mail]>
To: Shawn Steele <[e-mail]> 
Cc: [e-mail]
Sent: Sunday, October 16, 2016 10:24 AM
Subject: Re: [EAI] [IETF] Content Issues [


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






_______________________________________________
IMA mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ima