Re: Comments on draft-farrell-decade-ni-06

"Martin J. Dürst" <> Tue, 12 June 2012 10:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0685221F8557 for <>; Tue, 12 Jun 2012 03:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.648
X-Spam-Status: No, score=-99.648 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xUKRDUjGf+ds for <>; Tue, 12 Jun 2012 03:56:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 34FB321F851C for <>; Tue, 12 Jun 2012 03:56:58 -0700 (PDT)
Received: from ([]) by (secret/secret) with SMTP id q5CAuv9Q021421 for <>; Tue, 12 Jun 2012 19:56:57 +0900
Received: from (unknown []) by with smtp id 05ee_e0ee_5430c37a_b47d_11e1_a138_001d096c566a; Tue, 12 Jun 2012 19:56:56 +0900
Received: from [IPv6:::1] ([]:39493) by with [XMail 1.22 ESMTP Server] id <S15D1710> for <> from <>; Tue, 12 Jun 2012 19:57:01 +0900
Message-ID: <>
Date: Tue, 12 Jun 2012 19:56:53 +0900
From: "\"Martin J. Dürst\"" <>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Stephen Farrell <>
Subject: Re: Comments on draft-farrell-decade-ni-06
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: Bjoern Hoehrmann <>,
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jun 2012 10:56:59 -0000

Hello Stephen,

On 2012/06/09 22:24, Stephen Farrell wrote:
> Hi Björn,
> On 06/08/2012 03:16 AM, Bjoern Hoehrmann wrote:
>> I think the requirement in RFC 4395 section 2.6 applies here, there are
>> text fields in 'ni' and 'nih' addresses, so there needs to be some dis-
>> cussion about I18N and IRI issues, or a statement that there are none,
>> or something along those lines. What if I want a non-ASCII host name in
>> them, for instance?
> So what's reasonable here?
> We're inheriting some definitions (authority, unreserved&
> pct-encoded) from 3986 and I'd not like to break that, nor
> would I like something that doesn't work with most libraries.
> Any suggestions?

I shouldn't have missed I18N and IRI issues in my apps review.

For IDNs in the authority part, you are essentially safe because RFC 
3986 says exactly how to handle this (%-encoding based on UTF-8; 
alternatively punycode (A-Labels), for which library suppor may be 
better than for the former). You don't have to say anything about this, 
but you can say something if you think it's useful for implementers and 
if it's limited to a non-normative pointer (to the last paragraph of

For the query part, you should put in the following text (or an equivalent):

For compatibility with IRIs, non-ASCII characters in the query part MUST 
be encoded as UTF-8, and the resulting octets MUST be %-encoded (see

My understanding is that there's no danger for getting non-ASCII 
characters in the path part, and that fragments are separate anyway.

Regards,   Martin.