Re: [EAI] punctuation and number (NFC/NFD)

IMO this set MUST normalize first, punctuation and number: dot,  
underscore, plus, minus, number, and any other punctuation characters  
allowed in email now. Some normalization may be solved by internal  
mapping, alias, etc.  I'm concerned that punctuation marks are not  
(especially characters with special meaning in email format).

It sounds like I'm spelling NFKC/D, I'm not.  I want to focus on  
punctuation mark normalization in regard to email address only.  It  
can be special rule to apply first before other normalization, no  
punctuation mark allowed beyond ASCII set, NF-something for the whole  
email address (if it addressed the punctuation mark concern).

Joseph

On 27-Jul-09, at 10:00 AM, Harald Alvestrand wrote:

> Arnt Gulbrandsen wrote:
>> John C Klensin writes:
>>> --On Friday, July 24, 2009 09:22 +0200 Harald Alvestrand
>>> <harald@alvestrand.no> wrote:
>>>> 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.
>>>
>>> Exactly.
>>
>> I wonder if that's a bit of a fallacy... anyone who expects humans  
>> to read and reenter 42-69 differently from 42‒69 has a problem.  
>> IMO that's a perfectly natural mistake, it involves a character  
>> often used in today's email addresses, and I've never heard anyone  
>> use this particular example before so I doubt it would be  
>> implemented quickly.
> and in this case, NFC wouldn't help either....
>>
>> Alternative proposal: Extend VRFY to optionally return a fuzzily  
>> correctified version of an email address. If VRFY is disabled or  
>> doesn't return an address, correction isn't available for that  
>> address. I think this is better because it permits the fuzzy  
>> fuzziness to be invoked when the address is entered into e.g. an  
>> address database, instead of when a message is transmitted. As a  
>> bonus it's 99% independent of EAI.
> Fuzzy matching is a very interesting subject, and I'd argue that  
> it's 100% orthogonal to EAI - I still remember the mail I got as a  
> new postmaster after a new fuzzy-match algorithm had rerouted a  
> misspelling of one man's wife's mail to his mailbox - "how did the  
> system know we are married?".
>
> I'd like to punt this issue to the Single Global Directory, but  
> that's just reducing it to a previously unsolved problem.....
>
>                     Harald
>
>
>
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www.ietf.org/mailman/listinfo/ima