Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-06.txt]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-06.txt]



Hmm, that makes sense then, I missed the IRI vs URI part.

In that case I'd like to suggest wording to the effect that "Applications SHOULD consider supporting IRI instead of URI for mailto."

Since this is new behavior anyway, I'm not sure how useful it is to define an upgrade to a %encoded URI form when the application might be better served by moving to an IRI instead.  Eg: what problem is this solving that IRIs wouldn't?

-Shawn

-----Original Message-----
From: "Martin J. Dürst" [mailto:duerst at it.aoyama.ac.jp] 
Sent: Monday, October 26, 2009 6:36 PM
To: Shawn Steele
Cc: ima at ietf.org; public-iri at w3.org
Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-06.txt]

[cc'ed to public-iri at w3.org]

Hello Shawn,

Many thanks for your comments.

On 2009/10/27 4:26, Shawn Steele wrote:
> Currently lots of software seem to just allow Unicode in the mailto:  (Or actually convert it based on the encoding of the web page).  I'm not going to argue whether that's "correct" or not, but it does seem to be the prevailing current practice.

Of course. These are mailto: IRIs. Nothing wrong with that, as far as I 
understand. Actually, one main point of update from RFC 2368 is to allow 
that, by allowing mailto: URIs to use UTF-8-based %-encoding.


>  From the experience with IDN where non-ASCII values are being directly encoded in http, I think it's unrealistic that all mailto: URIs will be "correctly" % escaped.  On the contrary, I think most probably won't be.

If by "not correctly escaped" you mean "not escaped", then that's just 
fine, they are IRIs. If you meant "not escaped based on UTF-8, but based 
on some other encoding", then than would be a problem.


> So I'd like the mailto-bis to allow that applications MAY recognize unescaped UTF-8 in UTF-8 documents.

It's not the mailto: URI scheme definition, but the spec for that 
application that has to say whether you can use IRIs or not. Once you 
can use IRIs, you can use unescaped UTF-8 in UTF-8 documents, unescaped 
Shift_JIS in Shift_JIS documents (being converted to UTF-8 when 
conversion to an URI is necessary), and so on.

So I don't see the need for any textual changes. If you think some 
textual changes are necessary, please send a more concrete proposal.

> -Shawn
>
> P.S: Yes, "lots" includes Microsoft software since it's easy to play with.  On my machine if I open "run", then type mailto:shäwn, then Outlook opens up with shäwn in the To: line.  Same thing happens if I stick it in an href in an HTML document.  I think I even tried it with a different browser (sorry, don't remember which one, don't have others installed at the moment).  Of course I couldn't actually send the mail, but the "mailto" part worked.

I'm not sure who at Microsoft writes the spec for the "run" command, and 
whether this spec is publicly viewable or not, but essentially it seems 
to treat input that looks like an IRI/URI as an IRI, and do the right 
encoding conversion (I assume that internally, it uses UTF-16, not 
UTF-8, or might even use some OEM encoding or whatever).

Also, while the HTML spec only allows IRI processing as error behavior, 
implementations actually allow IRIs.

So everything is fine as far as I understand.

Regards,    Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst at it.aoyama.ac.jp


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.