[EAI] mailto: escaping

Shawn Steele <Shawn.Steele@microsoft.com> Mon, 13 July 2009 22:26 UTC

Return-Path: <Shawn.Steele@microsoft.com>
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 9C34F28C71B for <ima@core3.amsl.com>; Mon, 13 Jul 2009 15:26:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.597
X-Spam-Level:
X-Spam-Status: No, score=-10.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 kp5K-J4tHnA5 for <ima@core3.amsl.com>; Mon, 13 Jul 2009 15:26:33 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 6389228C715 for <ima@ietf.org>; Mon, 13 Jul 2009 15:26:33 -0700 (PDT)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 13 Jul 2009 15:27:04 -0700
Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.241]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi; Mon, 13 Jul 2009 15:27:04 -0700
From: Shawn Steele <Shawn.Steele@microsoft.com>
To: "ima@ietf.org" <ima@ietf.org>
Thread-Topic: mailto: escaping
Thread-Index: AQHKBAkLEibt+HuKpUextgTm+s89uA==
Date: Mon, 13 Jul 2009 22:27:02 +0000
Message-ID: <CAD7705D4A93814F97D3EF00790AF0B315FA6B01@tk5ex14mbxc105.redmond.corp.microsoft.com>
References: <mailman.13830.1247508102.4936.ima@ietf.org> <CAD7705D4A93814F97D3EF00790AF0B315FA6650@tk5ex14mbxc105.redmond.corp.microsoft.com> <4A5BABF8.4080900@isode.com>
In-Reply-To: <4A5BABF8.4080900@isode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [EAI] mailto: escaping
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: Mon, 13 Jul 2009 22:26:34 -0000

I didn't see any discussion of my mailto: comments.

I think that it's good for the mailto: doc to provide escaping of the UTF-8 code points, however I also think that many clients will be quite liberal in what they allow.  (Safari & IE on Windows already seem to allow mailto:café(at)example.org and I don't see any reason to break that)

In other words in 2) I'd like to see the language:

"Applications MAY process UTF-8 encoded values in mailbox and hvalue directly even if they aren't percent-encoded."

Also it looks like hvalue SHOULD be percent encoded, but in the mailbox section it says "Percent-encoding can be used to denote non-ASCII characters" without any SHOULDs that I can see.

I'm happy for hvalue (and mailbox) to have SHOULD be percent-encoded for IRI [RFC3987] compatibility, though I note that humans typing mailto values directly aren't likely to do this.

4.1 also says "angle brackets...are mandatory", but doesn't use MUST language.  I'd like it to be SHOULD:

   Please note that if the left-hand side of the mail address contains
   non-ASCII characters, the less-than and greater-than sign (angle
   brackets, escaped as %3C and %3E) SHOULD be included.

(Why are <> necessary?)

I'd also like similar language if the angle brackets are missing

"Applications MAY process UTF-8 encoded mailbox values directly even if the RECOMMENDED angle brackets are not present"

I don't think it's realistic to expect current systems (Browsers, OS, etc.) to be more restrictive than they already are.  Specifically UTF-8 domain names tend to work fine with mailto in IDN aware systems, regardless of percent encoding or angle brackets.

Any comments this time? :)

-Shawn