Re: [EAI] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?)

Shawn Steele <Shawn.Steele@microsoft.com> Mon, 24 January 2011 02:53 UTC

Return-Path: <Shawn.Steele@microsoft.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 E40163A6A1C for <ima@core3.amsl.com>; Sun, 23 Jan 2011 18:53:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.461
X-Spam-Level:
X-Spam-Status: No, score=-10.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 35Uc4kVWmZ2n for <ima@core3.amsl.com>; Sun, 23 Jan 2011 18:53:26 -0800 (PST)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 68EC13A6A22 for <ima@ietf.org>; Sun, 23 Jan 2011 18:53:26 -0800 (PST)
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 23 Jan 2011 18:56:13 -0800
Received: from TK5EX14MBXC139.redmond.corp.microsoft.com ([169.254.7.191]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0255.003; Sun, 23 Jan 2011 18:56:13 -0800
From: Shawn Steele <Shawn.Steele@microsoft.com>
To: John C Klensin <klensin@jck.com>, "ima@ietf.org" <ima@ietf.org>
Thread-Topic: [EAI] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?)
Thread-Index: AQHLuuyEEuWyiH/110y72nEFzZFe0pPfbll2
Date: Mon, 24 Jan 2011 02:56:13 +0000
Message-ID: <E14011F8737B524BB564B05FF748464A11C428A2@TK5EX14MBXC139.redmond.corp.microsoft.com>
References: <8244D38A28FB919303079D4E@PST.JCK.COM>
In-Reply-To: <8244D38A28FB919303079D4E@PST.JCK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.123.12]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [EAI] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?)
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, 24 Jan 2011 02:53:28 -0000

Yes, it's legal for the existing RFCs, however the existing RFCs don't allow the use of MAIL FROM UTF8SMTP.  Presumably it could be a requirement that if you're using the EAI RFC, then punycode could be illegal.

At the very least u-labels should be a SHOULD.

-Shawn

 
http://blogs.msdn.com/shawnste


________________________________________
From: John C Klensin [klensin@jck.com]
Sent: Sunday, January 23, 2011 2:58 AM
To: Shawn Steele; ima@ietf.org
Subject: Re: [EAI] Proposal for Alternate ABNF (was: Consensus Issue #6: current metalanguage model acceptable?)

--On Saturday, January 22, 2011 22:54 +0000 Shawn Steele
<Shawn.Steele@microsoft.com> wrote:

>> I can live with this approach.  If it is adopted, I'll help
>> sort out the domain name part.
>
> As mentioned, IMO, the domain part should "just" say UTF-8 as
> well, though it's fair to point out the dependencies on
> existing RFCs that define DNS.  DNS is a bit trickier than the
> other headers because we explicitly want to disallow the
> punycode I think, and require UTF-8 U-Labels instead.

Shawn,

I know that you want to "disallow" punycode.  In a perfect
world, I would too, and that is part of what
draft-iab-idn-encoding is about.  But, realistically, while we
can try to discourage its use, banning it is just impractical
given that A-labels conform to the RFC 1035 "preferred syntax",
the syntax requirements of RFCs 5321 and 5322, and even the
rather careful rules in RFC 5892 about what does and does not
need to be checked on lookup.

    john