Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01

John C Klensin <klensin@jck.com> Mon, 12 July 2010 08:38 UTC

Return-Path: <klensin@jck.com>
X-Original-To: ima@core3.amsl.com
Delivered-To: ima@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825313A6A6C for <ima@core3.amsl.com>; Mon, 12 Jul 2010 01:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPJRRnkPHJVk for <ima@core3.amsl.com>; Mon, 12 Jul 2010 01:38:38 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 540473A680E for <ima@ietf.org>; Mon, 12 Jul 2010 01:38:38 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OYEXE-0001qp-UC; Mon, 12 Jul 2010 04:38:45 -0400
Date: Mon, 12 Jul 2010 04:38:44 -0400
From: John C Klensin <klensin@jck.com>
To: Shawn Steele <Shawn.Steele@microsoft.com>, ima@ietf.org
Message-ID: <FCA41AD1F0296F7ADB9AF84B@PST.JCK.COM>
In-Reply-To: <E14011F8737B524BB564B05FF748464A0DA552C0@TK5EX14MBXC141.redmond.corp.microsoft.com>
References: <E14011F8737B524BB564B05FF748464A0DA552C0@TK5EX14MBXC141.redmond.corp.microsoft.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
Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Mon, 12 Jul 2010 08:38:39 -0000

Shawn,


--On Monday, July 12, 2010 06:08 +0000 Shawn Steele
<Shawn.Steele@microsoft.com> wrote:

>> The second sentence is not very clear. Is the following what
>> is meant?
> 
>>    In this case, the client will not be able to transmit any
>>    messages which contain non-ASCII characters in the
>>    local-part of any email addresses. If the non-ASCII
>>    characters are confined only to the domain portion of the
>>    address, such a client will be able to transmit messages
>>    if it uses [RFC3490] or [RFC5890] ToAscii() to encode the
>>    domain portions of these addresses.

I can't even find the above text in 4952bis-01.  To what are you
referring?

> They may have ASCII aliases (eg: transliterations) available,
> so I think that's a tad too restrictive.

And I don't understand this comment.  If an ASCII alias is
substituted for the non-ASCII local part, then the message
proposed to be transmitted no longer contains a non-ASCII local
part.  Either the local-part in the _message the client is going
to transmit_ is all-ASCII or it isn't.  If it isn't, the above
is true.  If it is all-ASCII, the above is irrelevant.  

If you are suggesting that two messages are somehow the same
because one uses ASCII aliases for addresses found in the other,
I think that takes us directly into the mess of having to assert
an externally-verifiable identity binding between the two
addresses.  Only the delivery MTA or the destination user can
know that, and they aren't obligated to tell (even on VRFY).

>    In this case, the client will not be able to transmit any
> messages    which contain non-ASCII characters in the
> local-part of any email    addresses. If the client has an
> ASCII only address available, such    as an alias, or by
> applying [RFC3490bis] ToAscii to the domain    portion of the
> address, then it may be able to send the mail in    ASCII as
> per [RFC2821].

That statement would be true, but a lot less helpful than I
think you want, if the last part of it read something like
"...then it may be able to send a similar, transformed, message
in ASCII as..."

   best,
      john