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

From: Shawn Steele <[email-masked]>
Date: Mon, 26 Oct 2009 19:26:45 +0000

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.

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.

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

-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.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 26 Oct 2009 13:03:54 -0700

On Mon, Oct 26, 2009 at 12:26 PM, Shawn Steele
<[email-masked]> wrote:
 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.

For "the 'mailto part" to be considered to have worked, the mail has
to get end to end, at least in my opinion.

The problem here is fundamentally that some part of the system has to
take what the user thinks is correct and turn into something that the
mail system can deliver.  The more pieces we allow to contain "what
the user thinks is correct" rather than "what the mail system can
deliver", the further down into the system any translation between the
two must occur.

Unless "shäwn" is a valid email address, showing that in a protocol
slot (which mailto is) seems like the wrong trade-off to me.

YMMV; offer not good in jurisdictions legislating the value of pi.

Ted

---

From: Shawn Steele <[email-masked]>
Date: Mon, 26 Oct 2009 20:07:50 +0000

Yes, end-to-end would be working, however consider if Office-That-Supports-EAI is installed on Win7, then this would've worked.  If the OS is then upgraded, users will expect it to continue working.

-Shawn

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Monday, October 26, 2009 1:04 PM
To: Shawn Steele
Cc: [email-masked]
Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-06.txt]

On Mon, Oct 26, 2009 at 12:26 PM, Shawn Steele <[email-masked]> wrote:
 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.

For "the 'mailto part" to be considered to have worked, the mail has to get end to end, at least in my opinion.

The problem here is fundamentally that some part of the system has to take what the user thinks is correct and turn into something that the mail system can deliver.  The more pieces we allow to contain "what the user thinks is correct" rather than "what the mail system can deliver", the further down into the system any translation between the two must occur.

Unless "shäwn" is a valid email address, showing that in a protocol slot (which mailto is) seems like the wrong trade-off to me.

Ted

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 27 Oct 2009 10:35:38 +0900

[cc'ed to [email-masked]]

Hello Shawn,

Many thanks for your comments.

> 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…

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…

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.

> 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 happ…

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:[email-masked]

---

From: Shawn Steele <[email-masked]>
Date: Tue, 27 Oct 2009 01:42:55 +0000

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:[email-masked]] 
Sent: Monday, October 26, 2009 6:36 PM
To: Shawn Steele
Cc: [email-masked]; [email-masked]
Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-06.txt]

Hello Shawn,

Regards,    Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 27 Oct 2009 12:56:33 +0900

[copying [email-masked]]

Hello Ted, others,

[everybody: There is a short summary at the end of this mail.]

> to get end to end, at least in my opinion.

At first sight, this seems reasonable. But it's basically the same 
difference as the difference between an http: URI/IRI that is 
*syntactically* correct and one that *actually resolves* (i.e. not 
produces a 404 or something similar).

> deliver", the further down into the system any translation between the

There are two problems with mailto:shäwn:

1) There's no At-sign
2) In particular for LHS, shäwn only works under EAI

For your everyday email user agent, both of these mean that the mail 
won't be sent.

> slot (which mailto is) seems like the wrong trade-off to me.

First, the current draft clearly says that an at-sign is needed, by 
using <addr-spec> (http://tools.ietf.org/html/rfc5322#section-3.4.1).
So mailto:shäwn is not a valid IRI even according to an updated mailto: 
spec. So to conform to the spec, we may have to try with something like
mailto:[email-masked] or so.

But the question is where this should be checked. An important principle 
that many people often forget is that IRIs/URIs are just "carriers". 
Because there are many schemes, it is completely unrealistic to expect a 
generic IRI/URI handler to check these. So checking is up to the 
application that "resolves" the mailto: IRI/URI, which is the mail user 
agent.

Now what does the average mail user agent do if you put "shäwn" into a 
To: field? I can only report about Thunderbird (Eudora version, 
3.0b1pre). It absolutely has no problem putting "shäwn" into a To: field 
(I have to admit that I actually tested with a Cc: field, but I don't 
think there would be any difference for a To: field). Thinking about it, 
that's quite understandable, it also shouldn't produce an error if I put 
"Dürst” into such a field, in particular if I continue input with " 
<[email-masked]>". The "Dürst” will result in an encoded word, 
but it would be weird to ask the user to input that encoded word, or to 
show that encoded word to the user.

[The syntax proposed in the draft, as far as I understand, excludes 
something like "name <lhs@rhs>" anyway. This is different in RFC 2368, 
which I thinks allows this, but I got told that this wasn't actually 
supported well, and RFC 2368's predecessor (RFC 1738) also didn't allow 
it. (see http://tools.ietf.org/html/rfc1738#section-3.5)]

When putting "shäwn" into a Cc: field, what happened is that when I 
tried to send the mail, there was an error message that to me suggested 
that between the mail user agent and the server, the non-7bit byte 
caused a connection abort. Not a very helpful message for a general 
user, but not an issue for the mailto: spec. I have no idea whether 
other mail user agents do better here (e.g. checking and telling the 
user that the address isn't well-formed before they actually try to send 
something).

 > to get end to end, at least in my opinion.

then that would also exclude things such as
mailto:[email-masked]
would also not be valid mailto: IRIs/URIs. I hope you agree that it 
doesn't make sense to actually send an email just to figure out whether 
a mailto: URI/IRI is valid or not. So I don't think it makes sense to 
include the existence of a mail address a precondition for the validity 
of a mailto: URI.

Also, the draft does not contain any syntax restrictions for any of the 
other fields (body, Subject:, To:, Cc:, Bcc:,...). So according to the 
draft, there has to be an at-sign before the '?', but there is no check 
for an at-sign in the "foo" part of mailto:[email-masked]?cc=foo.

So in summary:

- It's the responsibility of the resolver (in this case the mail user 
agent), not some generic IRI/URI software, to check for possible syntax 
problems in the IRI/URI.

- There's a whole series of different cases ranging from a fully 
workable example to a syntactically totally invalid example. Therefore, 
problems may be detected (or show up) sooner or later.

- IDNA-aware slots, or EAI, may be a different protocol from old-style 
SMTP without any extensions, but the former use (somewhat different) 
protocol elements nevertheless.

- If and where interoperability can be achieved with a protocol element 
that is closer to the user (i.e. an IDN, or an IRI,...), there is no 
reason to use a lower-level protocol element (e.g. xn--... or lots of 
%-escapes or a mime encoded word (maybe with %-escapes on top of that).

> YMMV; offer not good in jurisdictions legislating the value of pi.

IMHO, offer not good even in jurisdictions that leave the value of pi to 
mathematicians :-)

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 27 Oct 2009 13:00:21 +0900

Hello Shawn,

Just to double-check: would "shäwn" be a valid email address on some 
windows system? I understand that with EAI, "[email-masked]" or 
something like that would be valid, but just "shäwn" doesn't look like a 
valid email address to me even in EAI.

Regards,   Martin.

> On Mon, Oct 26, 2009 at 12:26 PM, Shawn Steele<[email-masked]>  wrote:
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima
>

---

From: Shawn Steele <[email-masked]>
Date: Tue, 27 Oct 2009 16:36:50 +0000

Sorry, I was only focusing on the local part as whatever's after @ is already an example with IDN.  So mailto:[email-masked] would be a better example.

Note that however mailto:shawn would work on a local system.  (Like an intranet, link from an internal web page to the internal maintainer of that page for example.)

-Shawn

________________________________________
From: "Martin J. Dürst" [[email-masked]]
Sent: Monday, October 26, 2009 9:00 PM
To: Shawn Steele
Cc: Ted Hardie; [email-masked]
Subject: Re: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-06.txt]

Hello Shawn,

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 28 Oct 2009 18:18:16 +0900

Hello Shawn, others,

> Note that however mailto:shawn would work on a local system.  (Like an intranet, link from an internal web page to the internal maintainer of that page for example.)

Yes, it would probably work. Of course, such local addresses are a 
problem, because some work will have to be done to change them when e.g. 
a page goes public.

It's somehow similar to file: URIs, which are also local.

Anyway, currently, the syntax of the mailto: URI/IRI requires an @, but 
in practice, mailto: URIs/IRIs without an @ may get through, of course.

Regards,   Martin.