[EAI] NFC/NFD (Re: Test - driven schedule (Re: Rechartering))

Harald Alvestrand <harald@alvestrand.no> Fri, 24 July 2009 07:29 UTC

Return-Path: <harald@alvestrand.no>
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 D83A33A6CAE for <ima@core3.amsl.com>; Fri, 24 Jul 2009 00:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 9ZEfHzSh4r-n for <ima@core3.amsl.com>; Fri, 24 Jul 2009 00:29:39 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id E84643A6AE1 for <ima@ietf.org>; Fri, 24 Jul 2009 00:29:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E0D3439E725; Fri, 24 Jul 2009 09:23:01 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvQB5JYdvijb; Fri, 24 Jul 2009 09:22:57 +0200 (CEST)
Received: from [10.17.102.176] (0x5da76f3e.cpe.ge-1-1-0-1109.bynqu1.customer.tele.dk [93.167.111.62]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 200C039E1DD; Fri, 24 Jul 2009 09:22:57 +0200 (CEST)
Message-ID: <4A696140.4090902@alvestrand.no>
Date: Fri, 24 Jul 2009 09:22:40 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: Shawn Steele <Shawn.Steele@microsoft.com>
References: <mailman.13830.1247508102.4936.ima@ietf.org> <CAD7705D4A93814F97D3EF00790AF0B315FA6650@tk5ex14mbxc105.redmond.corp.microsoft.com> <4A5BABF8.4080900@isode.com> <CAD7705D4A93814F97D3EF00790AF0B315FA6AAF@tk5ex14mbxc105.redmond.corp.microsoft.com> <4A60AA0B.4000106@alvestrand.no> <CAD7705D4A93814F97D3EF00790AF0B315FCA179@TK5EX14MBXC104.redmond.corp.microsoft.com> , <EA9664FBEBEB7127550C3D30@[192.168.1.110]> <CAD7705D4A93814F97D3EF00790AF0B315FCB1CA@TK5EX14MBXC104.redmond.corp.microsoft.com> , <F2BC6EC973C4D97B22FB5FE1@p3.int.jck.com> <CAD7705D4A93814F97D3EF00790AF0B315FDE04F@tk5ex14mbxc105.redmond.corp.microsoft.com> <448328271.18687@cnnic.cn> <448338030.08886@cnnic.cn>, <021001ca0b70$4bf6ab20$236ff1da@whatisfuture>, <8BC1BBA8349DC191FB83819F@JcK-eee9.example.com> <CAD7705D4A93814F97D3EF00790AF0B315FDF9E5@tk5ex14mbxc105.redmond.corp.microsoft.com>
In-Reply-To: <CAD7705D4A93814F97D3EF00790AF0B315FDF9E5@tk5ex14mbxc105.redmond.corp.microsoft.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "ima@ietf.org" <ima@ietf.org>
Subject: [EAI] NFC/NFD (Re: Test - driven schedule (Re: Rechartering))
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: Fri, 24 Jul 2009 07:29:39 -0000

Shawn Steele wrote:
>> That suggests that we should _at least_ recommend normalization
>> in the SMTP server (much as 5321 recommends case-insensitive
>> matching) and that we should think about requiring it.  But,
>> again, data would help.
>>     
>
> I think that's fairly irrelevent.  It won't break the RFCs for the rest of the system.  It'd only break servers that registered both NFC and NFD (or similar variations) of names.  Then they'd pretty much deserve to be broken :)
>   
The more dangerous brokenness is the business card data entry situation, 
where people enter an address from a business card and get a "no such 
mailbox" response, without there being any visual difference between the 
two strings.

Requiring normalization at the server (without placing a requirement on 
what one normalizes to) would at least remove this class of issue.
>
> -Shawn
>
>