Re: '#' in mailto URIs

On Wed, 14 Oct 2009 13:31:09 -0400, Larry Masinter <masinter@adobe.com>  
wrote:

> This is some very old mail. The current mailto: draft doesn't contain
> anything about fragment identifiers. Should it?
> The text that I might put in (if we think we need some) is:
> >>>>
> Note that this specification, like any URI scheme specification, does
> not define syntax or meaning of a fragment identifier, because these
> depend on the media type of the retrieved resource. In the currently
> known usage scenarios, a 'mailto' URI does not serve to retreive a
> resource with a media type. Therefore, fragment identifiers are
> meaningless, SHOULD NOT be used on 'mailto' URIs, and SHOULD be ignored
> upon resolution.
>  >>>>

Actually, I think we should just look at how clients handle # in mailto  
URIs.

1. msimn.exe /mailurl:mailto:?body=before#after
2. opera.exe mailto:?body=before#after
3. opera.exe page.html (where page has <a  
href="mailto:?body=before#after">click me</a>)
4. sylpheed.exe --compose mailto:?body=before#after
5. thunderbird31.exe mailto:?body=before#after

All those mail clients (except for the #2 situation where Opera's address  
field's URI parser splits up the URI into its pieces and Opera's mail code  
doesn't recompose the URI right (forgets the fragid part) before parsing)  
emit "before#after" in the body field of the compose window instead of  
just "before". That says that for mailto, # should just be treated  
literally as a non-reserved character like a-zA-Z0-9 etc. is.

(Note that IE's address field can do what Opera does for #2 too before it  
passes the URI to the mail client.)

So, I'd rather just say that for mailto URIs, # is just another character  
and any client that doesn't follow that notion should be fixed.

However, if others are not fine with that, in addition to the proposed  
text quoted above, it should be said 'why' you should not use # in mailto  
URIs. The reason of course would be that whether the # gets treated as  
part of a header field value or whether the URI gets chopped off at the  
first # depends on the client and situation. It should also be explicitly  
mentioned that if you need a # to be part of a header field value, you  
should use %23 instead.

So, although I'm fine with the proposed text, it could be improved to  
mention (more like I do) 'why' you *currently at least* should not use #  
in mailto URIs.

Also, fwiw, the mention of 'media type', or the lack of, in the presence  
of 'mailto' seems odd.

Ultimately though, what I need from specs is a definitive answer as to  
what should happen when there's a # in a mailto URI. Even if # is invalid  
in a mailto URI, I need to know what to do so I can file bugs for clients  
and make things interoperable. There should be no ambiguity on how to  
*handle* # in a mailto URI. I need that explicitly spelled out in a spec  
so that vendors will be willing to fix it. And, the less changes vendors  
have to make to their code, the better.

So, to recap, here are 2 questions that must be answered:

1. If I enter mailto:?body=before#after in my browser's address field (or  
click on an HTML link of the same), must "mailto:?body=before#after" or  
"mailto:?body=before" be passed to the mail client?

2. If a mail client receives mailto:?body=before#after , must it ignore  
the first # and everything after it where only "before" shows up in the  
body field or must the body hfvalue be "before#after"?

-- 
Michael

Received on Thursday, 15 October 2009 02:43:54 UTC