Subject: Re: [EAI] Gen-ART review of draft-ietf-eai-frmwrk-4952bis-07

From: Shawn Steele <[email-masked]>
Date: Tue, 14 Sep 2010 19:52:46 +0000

> > [3] Section 10.1 seems problematic.  The open issue is that the draft declines to say anything definitive about how to deal with existing ("running code" use of the backspace character).  I suggest adding a discussion of making the backspace character an exception to the prohibition of Unicode C0 controls for transition purposes.

> The technique of backspace character is not in practice at least in Unicode IMHO.  And this would create lots of issues on mail delivery and other areas.  Since EAI mail is new and allow UTF-8 only, I would recommend not to encourage this practice further.

I strongly concur, backspaces in UTF-8 address aren't good.  There's nothing here that disallows legacy use of that character (that would be the old RFCs), but any new UTF-8 email addresses should not use backspace.

> NFKC could maps out some characters that could be part of a person's name.  

Mapping is non-trivial.  For example, a Turkish admin may want to match different forms of I/i.  (Turkish - i).  IMO NFKC is ok for matching, but bad for the actual address as it may lose information as mentioned.

I've heard several requests for recommended mapping practices, however I think that's (still) out of scope for this WG.  If someone wanted to make a stab at document, that might be interesting, but IDNA proved that is very difficult at best.  I think the current RFCs practice of leaving mapping decisions to the server is appropriate.

NFC is worth mentioning because there pretty much be some canonicalization of NFC/NFD forms since the server has no clue whether the client IME leans toward NFC or NFD or some mixture.  Any server not doing some normalization for matching is likely to have unexpected results.  (No reason the server couldn't use NFD or NFKC or even UTS#46 rules if the server thought it was appropriate for their desired matching behavior though.  That doesn't impact these RFCs however, since the mapping behavior, if any, is entirely left up to the server.).

> New:

>   Because RFC 5321 (and its predecessor, RFC 2821) prohibit
>   the use of this character in ASCII mailbox names and it is
>   even more problematic (for canonicalization and
>   normalization reasons) in non-ASCII strings, backspace MUST
>   NOT appear in UTF8MSTPbis mailbox names.

I'm happy with that, though it seems a bit odd to pick on a single character and I'd rather not start evaluating each character 1 by 1.

-Shawn

---

From: John C Klensin <[email-masked]>
Date: Tue, 14 Sep 2010 16:07:56 -0400

--On Tuesday, September 14, 2010 19:52 +0000 Shawn Steele
<[email-masked]> wrote:

> I'm happy with that, though it seems a bit odd to pick on a
> single character and I'd rather not start evaluating each
> character 1 by 1.

Actually 5321 doesn't say "no backspaces".  It says "no C0
controls".  So there is no single character evaluation issue :-)

    john

---

From: Shawn Steele <[email-masked]>
Date: Tue, 14 Sep 2010 20:35:24 +0000

The proposed text explicitly called out backspaces though.  No C0 controls is fine by me.

-Shawn

-----Original Message-----
From: John C Klensin [mailto:[email-masked]] 
Sent: Tuesday, September 14, 2010 1:08 PM
To: Shawn Steele; [email-masked]
Subject: Re: [EAI] Gen-ART review of draft-ietf-eai-frmwrk-4952bis-07

--On Tuesday, September 14, 2010 19:52 +0000 Shawn Steele <[email-masked]> wrote:

> I'm happy with that, though it seems a bit odd to pick on a single 
> character and I'd rather not start evaluating each character 1 by 1.

Actually 5321 doesn't say "no backspaces".  It says "no C0 controls".  So there is no single character evaluation issue :-)

    john

---

From: John C Klensin <[email-masked]>
Date: Tue, 14 Sep 2010 16:39:20 -0400

> C0 controls is fine by me.

Indeed, the proposed text did because that is what appeared in
the comment and because backspaces turn out to be especially
problematic in an i18n context (white space is also pretty bad,
of course).  But, to the extent to which we are referring back
to 5321, it doesn't all out backspaces (or tabs, etc.): it
simply says that one MUST NOT have C0 controls in addresses (in
not those words).

    john