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

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 <at> it.aoyama.ac.jp
> _______________________________________________
> IMA mailing list
> IMA <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ima