Re: [EAI] [IETF] Content Issues [

John C Klensin <john-ietf@jck.com> Sun, 16 October 2016 17:24 UTC

Return-Path: <john-ietf@jck.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 CFBE112943B for <ima@ietfa.amsl.com>; Sun, 16 Oct 2016 10:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 0dDtSAwpqwmg for <ima@ietfa.amsl.com>; Sun, 16 Oct 2016 10:24:29 -0700 (PDT)
Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DCC2126D73 for <ima@ietf.org>; Sun, 16 Oct 2016 10:24:29 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1bvpAi-000J2q-JH; Sun, 16 Oct 2016 13:24:28 -0400
Date: Sun, 16 Oct 2016 13:24:23 -0400
From: John C Klensin <john-ietf@jck.com>
To: Shawn Steele <Shawn.Steele@microsoft.com>
Message-ID: <532EC6872314DFB0CC2B5F46@JcK-HP5.jck.com>
In-Reply-To: <MWHPR03MB2813DA794DF0E1DEF36C8EC982D10@MWHPR03MB2813.namprd03.prod.outlook.com>
References: <MWHPR03MB281341141A1CE0C0895F58A482D10@MWHPR03MB2813.namprd03.prod.outlook.com> <01Q668S03W0W00Q5OH@mauve.mrochek.com> <MWHPR03MB2813DA794DF0E1DEF36C8EC982D10@MWHPR03MB2813.namprd03.prod.outlook.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ima/hbSc1dTWvE_r5edk6sdpl63hTIU>
Cc: ima@ietf.org
Subject: Re: [EAI] [IETF] Content Issues [
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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 17:24:31 -0000

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