Re: [EAI] 5336bis
Shawn Steele <Shawn.Steele@microsoft.com> Sat, 25 December 2010 04:36 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 87DC13A6899 for <ima@core3.amsl.com>; Fri, 24 Dec 2010 20:36:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.559
X-Spam-Level:
X-Spam-Status: No, score=-9.559 tagged_above=-999 required=5 tests=[AWL=-0.626, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_FWDLOOK=1.666]
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 SWr4QY3AvTjr for <ima@core3.amsl.com>; Fri, 24 Dec 2010 20:36:58 -0800 (PST)
Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 4719C3A6879 for <ima@ietf.org>; Fri, 24 Dec 2010 20:36:58 -0800 (PST)
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 24 Dec 2010 20:39:02 -0800
Received: from TK5EX14MBXC137.redmond.corp.microsoft.com ([169.254.5.174]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.01.0255.003; Fri, 24 Dec 2010 20:39:01 -0800
From: Shawn Steele <Shawn.Steele@microsoft.com>
To: John C Klensin <klensin@jck.com>, "ima@ietf.org" <ima@ietf.org>, Alexey Melnikov <alexey.melnikov@isode.com>
Thread-Topic: [EAI] 5336bis
Thread-Index: AQHLo+szLpydMbQZU02+vAPbytL9FJOwkoHO
Date: Sat, 25 Dec 2010 04:39:01 +0000
Message-ID: <E14011F8737B524BB564B05FF748464A11B40E87@TK5EX14MBXC137.redmond.corp.microsoft.com>
References: <E14011F8737B524BB564B05FF748464A10C65AD6@TK5EX14MBXC133.redmond.corp.microsoft.com>, <5B92D222E006F894AE0307EC@PST.JCK.COM>
In-Reply-To: <5B92D222E006F894AE0307EC@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] 5336bis
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: Sat, 25 Dec 2010 04:36:59 -0000
Thanks, I hadn't seen a reply yet. I understand, but this is the kind of "leaking" that makes IDN horrible to interoperate with. Sure, the tools may not be Unicode aware, but they also may not be Punycode aware, meaning that someone has to figure out how to translate it. IMO the headers are EAI, so these should only happen on an EAI aware system, in which case the tools should be updated :) Eg: something could be broken no matter what, so I'd prefer it was broken in a forward-looking way, then at least when the tools got fixed they wouldn't always have to have the punycode hack. And this doesn't help much for other data in the header, or local parts. -Shawn http://blogs.msdn.com/shawnste ________________________________________ From: John C Klensin [klensin@jck.com] Sent: Friday, December 24, 2010 8:21 PM To: Shawn Steele; ima@ietf.org; Alexey Melnikov Subject: Re: [EAI] 5336bis Shawn, It isn't clear to me that anyone ever responded to this comment. If they have, I apologize for the duplication. If not... --On Friday, December 03, 2010 21:04 +0000 Shawn Steele <Shawn.Steele@microsoft.com> wrote: >... > In 3.6.3 I don't get why received fields have to use > A-labels at all? I assume I missed a discussion? It would > seem to me that the end-points are all EAI aware, so it's > unclear to me why A-labels are necessary anywhere. >... Claudio pointed out in his review of 5336bis that there there are whole array of databases and tools surrounding the email environment. His particular concerns were to warn about logs and the like, but the issue is more general: neither tools nor people should ever actually need to look at a Trace ("Received") field unless something has gone wrong or is suspected of having gone wrong. Those tools (or people) may not be EAI-aware, may not have fonts appropriate to display of arbitrary Unicode strings, may not be able to read such strings (even to iterate the characters) even if they can display them, etc. There is very little advantage in internationalizing those fields and, if we were to require it, the net effect would either be less stable operation or delays in deploying EAI as more infrastructure and training are required to be put in place. The A-label requirement does require that a MTA that uses a universal "name resolution" API (the problem discussed in draft-iab-idn-encoding) perform a U-label to A-label conversion, but the main issue in draft-iab-idn-encoding really doesn't apply here: think of the requirement as applying to Received: from ... with smtp ... or with any of the other "with" keywords specified in 5336bis or the IANA registry. "with smtp" is pretty much defined in 5321 as running over TCP. If one had Received: from ... with Proprietary-Email-Transport-XYZ ... then one would be far enough outside of the combination of 5321 and 5336bis that, if a name (domain or otherwise) is expressed in UTF-8 (or UTF-16 for that matter), the implementation would not be significantly more outside the specs. best, john
- [EAI] 5336bis Shawn Steele
- Re: [EAI] 5336bis Shawn Steele
- Re: [EAI] 5336bis Jiankang YAO
- Re: [EAI] 5336bis Shawn Steele
- Re: [EAI] 5336bis John C Klensin
- Re: [EAI] 5336bis Shawn Steele
- Re: [EAI] 5336bis John C Klensin