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

<nalini.elkins@insidethestack.com> Sun, 16 October 2016 20:01 UTC

Return-Path: <nalini.elkins@insidethestack.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0451279EB for <ima@ietfa.amsl.com>; Sun, 16 Oct 2016 13:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfImVyaCcp-p for <ima@ietfa.amsl.com>; Sun, 16 Oct 2016 13:01:32 -0700 (PDT)
Received: from nm20-vm0.bullet.mail.ne1.yahoo.com (nm20-vm0.bullet.mail.ne1.yahoo.com [98.138.91.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C281293EB for <ima@ietf.org>; Sun, 16 Oct 2016 13:01:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476648092; bh=iC3VsSzihoDP8n9tuoAKB/X67V2TPiXYZwdPJbXprAc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=XX7Za8DdY13zW2W/Fh5Kg5dhV1lNgNRACr3eB2KEXEyJcDi9Ze2AUS1yk34NPYnMz96yzMpZUHANec7f8cjzg6oQI6bVf/+7kagCw/pyCFoE3CBBmyyudg66Pealyde6Sw4axp7D3JpGzGv9IjKzPc1GNT7Tizx1fStx/L+7TlrYO6L74hGb+RUfdnzM6VtRhUgC4Q2tbXJDmZ2Sr804M063j6Llgd17vRI5dmVjj+GFLqCj6Ld81Q0/MX0FdOKjMpFQA0x8fkVJyMO41eRau8j75Y7wDhx9KgJ06yFatKFPBWXlklnFXbRL3/pTZVqlQMRCvh1/Qy9Yd/FV0NjBPg==
Received: from [98.138.100.103] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 16 Oct 2016 20:01:32 -0000
Received: from [98.138.226.160] by tm102.bullet.mail.ne1.yahoo.com with NNFMP; 16 Oct 2016 20:01:31 -0000
Received: from [127.0.0.1] by omp1061.mail.ne1.yahoo.com with NNFMP; 16 Oct 2016 20:01:31 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 961017.33381.bm@omp1061.mail.ne1.yahoo.com
X-YMail-OSG: ZQhHMp0VM1nhUorAnfBdqX6YjwJgVkozHYg.Nc67LKcjvQJZonLmg7vpK6lh9.H lcByIv4unxD6TXfx6SGTkjsci7JjlIewntwA7Fx1XL5_T6QuH3nHqx1A0M3ZY9D0VyJ1X2VH8l3h v2nOfmSnRaDTN75huUWReGj2dM_RYHMmsnFqtxNrcQj5Xux3qt21RwWoswhzePyBzTUKZHlh29u2 mZBUZyKuxkW4Tywov9QAZStK76AH8POa9azNmAsMsMYFWZxfcMzmvssx2PbVyHkOjY3BcDiBGIam O3.AnyQeBzrn4lsKNRL0H9nD_52bH5yuPDcVCgx1TflrRud3i7uli1kUWiPT2UUQaaCMJluPwSQb dxsaSTk3L0n8YO6veOlyeKuA7FNzQcFnrBE3yHnzbq.tL.Lb7DGCunz4Li_AoTtankOxMsDtNDwL T6D3yzlIYvqx0Oie2P01u8qpY8wflpQv7kqhMXYWVeaIFRgCCCx_DiPXZJ4QTVz2IMsBGRPX1fYt e_EEssrgXFrvsHmqM55wRfJXZE4moO0aulbt.RQkJJ6JULWLofRs-
Received: from jws200081.mail.ne1.yahoo.com by sendmailws158.mail.ne1.yahoo.com; Sun, 16 Oct 2016 20:01:31 +0000; 1476648091.578
Date: Sun, 16 Oct 2016 20:01:30 +0000 (UTC)
From: <nalini.elkins@insidethestack.com>
To: John C Klensin <john-ietf@jck.com>, Shawn Steele <Shawn.Steele@microsoft.com>
Message-ID: <783239201.731221.1476648090891@mail.yahoo.com>
In-Reply-To: <532EC6872314DFB0CC2B5F46@JcK-HP5.jck.com>
References: <MWHPR03MB281341141A1CE0C0895F58A482D10@MWHPR03MB2813.namprd03.prod.outlook.com> <01Q668S03W0W00Q5OH@mauve.mrochek.com> <MWHPR03MB2813DA794DF0E1DEF36C8EC982D10@MWHPR03MB2813.namprd03.prod.outlook.com> <532EC6872314DFB0CC2B5F46@JcK-HP5.jck.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ima/8tiFGX5-cUdeHNHHxfamlddsgoQ>
Cc: Harish Chowdhary <harish@nixi.in>, "ima@ietf.org" <ima@ietf.org>
Subject: [EAI] [IETF] Barriers to Deployment [ was: Content Issues]
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: nalini.elkins@insidethestack.com
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ima/>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Oct 2016 20:01:34 -0000

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
(831) 659-8360



________________________________
From: John C Klensin <john-ietf@jck.com>;
To: Shawn Steele <Shawn.Steele@microsoft.com>; 
Cc: ima@ietf.org
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
<Shawn.Steele@microsoft.com>; 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
IMA@ietf.org
https://www.ietf.org/mailman/listinfo/ima