Re: [EAI] I-D Action: draft-ietf-eai-mailinglistbis-00.txt

Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com> Sun, 27 November 2011 01:12 UTC

Return-Path: <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.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 E0C4A21F8AF3 for <ima@ietfa.amsl.com>; Sat, 26 Nov 2011 17:12:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.472
X-Spam-Level:
X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7o7jBpOTLUl for <ima@ietfa.amsl.com>; Sat, 26 Nov 2011 17:12:19 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 390C221F8AF0 for <ima@ietf.org>; Sat, 26 Nov 2011 17:12:19 -0800 (PST)
Received: by wwp14 with SMTP id 14so4856763wwp.13 for <ima@ietf.org>; Sat, 26 Nov 2011 17:12:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=F2ArD6cOBjecqU16VqUetxRkJPIdbGHTf2OI6q0mq/M=; b=ao/PLuQaVePOOWUjvZABpX5i1odOCeVsXvXidSvraC4OSVCz/jTmn7JPtfKwNsXF3M jWtGj4NWlPNDAD21mBzyjzPDKak2vXv8x2vtUiCi2Dk9j4GFV7C+31/Ob9hD0ce3hJ9n CSuOadCNGjZppSrg6+HYKbEmctger8Z72ED18=
Received: by 10.180.4.102 with SMTP id j6mr40211360wij.38.1322356338122; Sat, 26 Nov 2011 17:12:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.255.70 with HTTP; Sat, 26 Nov 2011 17:11:37 -0800 (PST)
In-Reply-To: <4ED182D1.2020901@it.aoyama.ac.jp>
References: <20111126051407.96953.qmail@joyce.lan> <4ED182D1.2020901@it.aoyama.ac.jp>
From: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
Date: Sun, 27 Nov 2011 02:11:37 +0100
Message-ID: <CAHhFybqf-JdrxuCj0MuRiShUksysHLNMt6=fyXAyUcYuLf71Sg@mail.gmail.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: ima@ietf.org
Subject: Re: [EAI] I-D Action: draft-ietf-eai-mailinglistbis-00.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.12
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: <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: Sun, 27 Nov 2011 01:12:20 -0000

On 27 November 2011 01:22, "Martin J. Dürst" wrote:

>> I went back and looked at that section again.  (Excuse: it's from
>> Randy's old draft.)  The sentence in question says:

>>   Note that discussion on whether internationalized domain names
>>   should be percent-encoded or puny-coded, is ongoing; see<xref
>>   target="I-D.duerst-iri-bis" />.

> Why not just point to RFC 3986, last two paragraphs of section 3.2.2
> (http://tools.ietf.org/html/rfc3986#section-3.2.2)?

> That's an Internet Standard rather than an "ongoing discussion".

All those "<reg-name> outside of DNS" considerations in STD 66 are
IMO irrelevant for UTF8SMTPBIS addresses.  If that's correct we end
up with the last two sentences in RFC 3986 3.2.2:

| When a non-ASCII registered name represents an internationalized
| domain name intended for resolution via the DNS, the name must be
| transformed to the IDNA encoding [RFC3490] prior to name lookup.
| URI producers should provide these registered names in the IDNA
| encoding, rather than a percent-encoding, if they wish to maximize
| interoperability with legacy URI resolvers.

That is an ordinary MUST, and obviously the tool or party knowing
how it works cannot delegate "punycoding" to another tool or party
which might not know how it works.

-Frank