Re: [EAI] [IETF] Content Issues [

John C Klensin <john-ietf@jck.com> Sun, 16 October 2016 16:56 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 A1BDF128E18 for <ima@ietfa.amsl.com>; Sun, 16 Oct 2016 09:56:02 -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 ZtOtGKL_yu6q for <ima@ietfa.amsl.com>; Sun, 16 Oct 2016 09:56:01 -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 DEACE126CD8 for <ima@ietf.org>; Sun, 16 Oct 2016 09:56:00 -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 1bvoj2-000Ivu-Em; Sun, 16 Oct 2016 12:55:52 -0400
Date: Sun, 16 Oct 2016 12:55:47 -0400
From: John C Klensin <john-ietf@jck.com>
To: ned+ima@mrochek.com, Shawn Steele <Shawn.Steele@microsoft.com>
Message-ID: <7A96FE61E454C7448DE804AE@JcK-HP5.jck.com>
In-Reply-To: <01Q668S03W0W00Q5OH@mauve.mrochek.com>
References: <MWHPR03MB281341141A1CE0C0895F58A482D10@MWHPR03MB2813.namprd03.prod.outlook.com> <01Q668S03W0W00Q5OH@mauve.mrochek.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/eDM7Ki6amAUi0ec-cprsELqUee4>
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 16:56:02 -0000

--On Sunday, October 16, 2016 6:48 AM -0700 ned+ima@mrochek.com
wrote:

>... 
> You're missing the point. If I send to an IETF list from an
> EAI address, the message I send is going to be an EAI message.
> Given the way EAI works, that message is only going to reach
> the (currently small) subset of list participants for whom the
> path to their eyeballs is EAI-capable at every step along the
> way.
> 
> The effect of this is to essentially to create a EAI-capable
> subset of any discussion. That breaks accontability, as John
> notes. But perhaps more important is the fact that it also
> breaks the entire open model.
> 
>> I'd vote for "eat our own dogfood"
> 
> Like it or not, that's not possible at this point. Perhaps
> that will change at some point in the future when the
> penetration of EAI has increased, but until it does the best
> we could offer is to allow EAI addresses to receive the list
> but not post to the list. And I don't think that's of
> sufficient utility  to bother implementing.
> 
> 				Ned


Ned,

Yes, exactly.  Even for the "receive but don't post" case, it is
worth remembering that just including a cc to a non-ASCII
address on a message, even if the sender and list addresses are
all-ASCII, or having non-ASCII in the headers when all addresses
are in ASCII, is sufficient to prevent many members of the
community from receiving the message.  I haven't thought through
the implications of IMAP-accessible archives of messages that
require SMTPUTF8 capabilities, but I don't think that would be
pleasant either.

FWIW, in the IETF context, those who are concerned about not
being able to use non-ASCII addresses because the local parts
cannot properly represent their personal names should probably
be pushing much harder on more substantive issues like why the
IETF does not allow list postings in their preferred languages
and provide (and insist on) real-time parallel translation at
meetings for all of the languages  whose users might be present.
Those are important, substantive, issues and not resolving them
prevents the community to be as diverse and open as it might
otherwise be.  Mailbox names are just identifiers.  I'd probably
feel differently if we had no provision for what were
historically often called "personal name phrases".  But those
arrangements have existed ever since we discovered that being
able to associate personal names with serially-assigned account
identifiers was useful (e.g., knowing me as "M3418" was never
helpful and was hard on transparency).  The required
functionality goes back to at least RFC 822 (and IIR earlier)
and has been possible with encoded words (which are widely
supported) since MIME was introduced 24 years ago.

   john