Re: '#' in mailto URIs

On Fri, 16 Oct 2009 13:05:40 -0400, Martin J. Dürst  
<duerst@it.aoyama.ac.jp> wrote:

> I have added
>
>>>>>>>>>
> Note that this specification, like any URI scheme specification, does
> not define syntax or meaning of a fragment identifier, because these
> depend on the type of a retrieved representation. In the currently
> known usage scenarios, a 'mailto' URI cannot be used to retreive
> such representations. Therefore, fragment identifiers are meaningless,
> SHOULD NOT be used on 'mailto' URIs, and SHOULD be ignored upon
> resolution. The character '#' in hfvalues MUST be escaped as %23.
>>>>>>>>>
>  to my internal version.

Thanks everyone.

Here's what I'm going to take from this discussion:

Mailto parsing error handling in the mail client:

For "mailto:test#abc", "test" ends up in the To field.

For "mailto:?subject=1#2", "1" ends up in the subject field.

For "mailto:?body=before#after&subject=2", "before" ends up in the body  
field and all other fields are empty.

In short, it gets cut off at the first # before parsing.

This will make it so creators of mailto URIs don't try to use # without  
encoding it to %23 (mailto URI creators and validators can help with this  
too of course). This will pave the way for the future so that if mail  
clients want to use a fragid for something, there's no legacy/broken  
handling of # getting in the way.

Browsers/UAs passing mailto links (via clickable link or user input) to  
mail clients:

For "mailto:test#abc",  "mailto:?subject=1#2", and  
"mailto:?body=before#after&subject=2", the browser passes all of it. This  
will leave the handling up the mail client and if a mail client in the  
future does something with fragment identifiers, the older browser will  
have no problem passing all of it to the new mail client. After all, the  
UA is just supposed to say to the mail client, "Here's what I was given,  
have at it!".

-- 
Michael

Received on Saturday, 17 October 2009 04:44:43 UTC