[EAI] (Re: EAI WG status and rechartering) -- mailto bis

Joseph Yee <jyee@ca.afilias.info> Thu, 26 November 2009 16:48 UTC

Return-Path: <jyee@ca.afilias.info>
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 A59A33A68D0 for <ima@core3.amsl.com>; Thu, 26 Nov 2009 08:48:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.965
X-Spam-Level:
X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 UO5RelZlUCtb for <ima@core3.amsl.com>; Thu, 26 Nov 2009 08:48:17 -0800 (PST)
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id D77B33A686E for <ima@ietf.org>; Thu, 26 Nov 2009 08:48:16 -0800 (PST)
Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from <jyee@ca.afilias.info>) id 1NDhVn-0008IZ-5c; Thu, 26 Nov 2009 16:48:07 +0000
Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <jyee@ca.afilias.info>) id 1NDhVn-0004Up-4x; Thu, 26 Nov 2009 16:48:07 +0000
From: Joseph Yee <jyee@ca.afilias.info>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
In-Reply-To: <4B0A570F.30900@it.aoyama.ac.jp>
References: <4B06DB11.1080602@isode.com> <4B0A570F.30900@it.aoyama.ac.jp>
Message-Id: <F3717143-8208-43EA-A8EC-8215784752BA@ca.afilias.info>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 26 Nov 2009 11:48:06 -0500
X-Mailer: Apple Mail (2.936)
Cc: "ima@ietf.org" <ima@ietf.org>, Larry Masinter <masinter@adobe.com>
Subject: [EAI] (Re: EAI WG status and rechartering) -- mailto bis
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: Thu, 26 Nov 2009 16:48:18 -0000

Hi Martin,

I read the latest mailto-bis (07).  Section 2.4 and 2.5 are great.

In the paragraph right after section 2.5, it mentions the pct-encoding  
for <hfname> and <hfvalue>.  My own interpretation had it sounds like  
allowing <hfname> to be pct-encoded.  Since current and proposed  
message header definition do not allow non ASCII characters, wouldn't  
that be easier to limit <hfname> to ASCII only?  That would make  
<hfname> be case insensitive easier to manage too.  I noticed that  
section 4 would stop non ASCII in <hfname>, but wonder if it's good to  
restrict it in mailto IRI.

Regards,
Joseph

On 23-Nov-09, at 4:34 AM, Martin J. Dürst wrote:

> Hello Alexey,
>
>
> On 2009/11/21 3:08, Alexey Melnikov wrote:
>
>> If the WG has enough energy to recharter, I would also like to ask  
>> the
>> WG to take mailto: URI scheme update (draft-duerst-mailto-bis) as an
>> additional deliverable.
>
> I'm not sure this makes sense, for two reasons:
>
> - While draft-duerst-mailto-bis is very much about  
> internationalization
>  (it allows non-ASCII characters in things such as Subject and body,
>   which the current RFC doesn't), it isn't actually about EAI
>
> - The draft has already been out for quite a long time, it doesn't  
> seem
>  to make sense to wait for other EAI drafts to complete and then the
>  WG to recharter to move on.
>
> That said, it would be possible (I'd even say appropriate) for a  
> rechartered WG to take up the job of either further updating what  
> might by that time be the RFC resulting from draft-duerst-mailto-bis  
> (essentially continuing what was http://tools.ietf.org/html/draft-ietf-eai-mailto-01) 
> , or of creating a new URI/IRI scheme for EAI mail addresses. [I'd  
> be glad to volunteer as an editor in either case.]
>
> Also, it's never too late for anybody in this WG to have a look at  
> draft-duerst-mailto-bis (currently at http://tools.ietf.org/html/draft-duerst-mailto-bis-07) 
> . Any kinds of reviews are appropriate, but with respect to WG  
> matters, I'd want in particular to point out the following two items  
> (not EAI per se, but definitely related) in Section 2, "Syntax of a  
> 'mailto' URI":
>
>   4.  Percent-encoding can be used in the <domain> part of an <addr-
>       spec>, in order to denote an internationalized domain name.  The
>       considerations for <reg-name> in [STD66] apply.  In particular,
>       non-ASCII characters MUST first be encoded according to UTF-8
>       [STD63], and then each octet of the corresponding UTF-8 sequence
>       MUST be percent-encoded to be represented as URI characters.   
> URI
>       producing applications MUST NOT use percent-encoding in domain
>       names unless it is used to represent a UTF-8 character sequence.
>       When the internationalized domain name is used to compose a
>       message, the name MUST be transformed to the IDNA encoding where
>       appropriate [RFC3490].  URI producers SHOULD provide these  
> domain
>       names in the IDNA encoding, rather than percent-encoded, if they
>       wish to maximize interoperability with legacy 'mailto' URI
>       interpreters.
>
>   5.  Percent-encoding of non-ASCII octets in the <local-part> of an
>       <addr-spec> is reserved for the internationalization of the
>       <local-part>.  Non-ASCII characters MUST first be encoded
>       according to UTF-8 [STD63], and then each octet of the
>       corresponding UTF-8 sequence MUST be percent-encoded to be
>       represented as URI characters.  Any other percent-encoding of
>       non-ASCII characters is prohibited.  When a <local-part>
>       containing non-ASCII characters will be used to compose a
>       message, the <local-part> MUST be transformed to conform to
>       whatever encoding may be defined in a future specification for
>       the internationalization of email addresses.
>
>
> Regards,   Martin.
>
> -- 
> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
> #-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www.ietf.org/mailman/listinfo/ima