Re: parsing mailto URIs into compose forms

Hello Mike,

I'm working on an new edition of draft-duerst-mailto-bis.

At 15:09 07/02/13, Shadow2531 wrote:
>
>I recently saw <http://blogs.msdn.com/ie/archive/2007/02/12/International-Mailto-URIs-in-IE7.aspx>,
>which referenced
><http://blogs.msdn.com/ie/archive/2007/02/12/International-Mailto-URIs-in-IE7.aspx>.
>
>I've been keeping notes at
><http://shadow2531.com/opera/testcases/mailto/rfc2368-1.html> on how
>mailto clients do or should parse mailto URIs into compose forms.
>
>The main issues seem to be with the handling of duplicate hnames,
>which is inconsistent across clients.  Some clients only use the last
>duplicate. Some only use the first.  Some join their values with a
>delim.

I think the best thing to do is to recommend against duplicate
hnames. That will be supported consistently by the widest range
of user agents.

I have added the following text to my internal draft:

There is some variation between user agents on how multiple identical "hname"s and their "hvalue"s are handled. For muliple identical "hname"s, some user agents may only use the first "hname"/"hvalue" pair, others may only use the last such pair, and others may combine such pairs by simple concatenation, or may combine them in a way appropriate for the corresponding header field, or may create a header field for each "hname"/"hvalue" pair. Creators of mailto URIs SHOULD avoid multiple identical "hname"s for best interoperability.

Any comments welcome.


>Mozilla's Thunderbird and Opera's M2  for example handle duplicate
>hnames using certain rules. Current bugs in each client aside, those
>rules are very close to the ones described at
><http://shadow2531.com/opera/testcases/mailto/rfc2368-1.html>.
>
>RFC2368 and RFC2822, don't describe how parsing of mailto URIs should
>work in this case, so it appears that M2 and Thunderbird follow some
>unwritten (but quite popular and expected) rules. (The way Thunderbird
>handles multiple body and subject hnames is requested and demanded
>quite often at <http://my.opera.com/>. It is also my opinion that
>*most* of how Thunderbird handles mailto URIs is perfect and I would
>like M2 and other clients to fix any bugs to be in sync.)

Why do you think that the way Thunderbird handles these is
'perfect'? What's perfect about it? Why do users demand it?
I have difficulties understanding e.g. what's so bad about
   mailto:abc@example.com?cc=def@example.com,ghi@example.com
and why
   mailto:abc@example.com?cc=def@example.com&cc=ghi@example.com
is so much more desirable. But maybe you can explain?


>There's also the case with form submissions. Forms in current browsers
>submit spaces as +, but mailto clients (non-http ones) don't decode +
>to a space.

They can't decode + to a space, because a + may just be a +.
As discussed in private, form submission in browsers has to
be fixed to use %20 instead of + for a space for the mailto:
URI.

[Personal rant: it could use %20 for all other URI schemes,
too, the + is an ugly one-off special case.]

>There's also the case of whether user input should be literal or escaped.

User input where?

>There's also the case of right-clicking on a link and choosing "copy
>email addres". Should it copy just one address or all TO addresses?

That's a user agent feature. We shouldn't standardize that,
user agents should do whatever they think works best for their
users. Some might even have two options, such as "copy main email
address" and "copy all email addresses".

>Although this stuff is UI-specific, the correct behavior needs to
>documented and specified.

Some of it, yes. But some of it can be just browser-specific,
without any harm to protocol interoperability.

Regards,    Martin.

>RFC2368 (the new one linked above) or some other document should
>describe what to do exactly. It could be described in a
>non-ui-specific way, but something is needed so all clients can follow
>the rules if the so choose.
>
>How should these issues be addressed?
>
>I'm happy to discuss specific rules from
><http://shadow2531.com/opera/testcases/mailto/rfc2368-1.html> if
>you're interested.
>
>Thanks
>
>-- 
>Mike
>
>


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp

Received on Thursday, 3 January 2008 09:39:41 UTC