Re: Comments on draft-duerst-mailto-bis-04.txt, please

Michael A. Puls II wrote:
> Browsers *may* show %40 as @ to the user in their status bar for a
> mailto link, but when it's passed to a mail client, the %40 will be
> left in tact (unless the browser decides to unencode the %40 before
> passing since rfc2368 doesn't say @ is reserved).

RFC 2368 may be silent, but RFC 3986/STD 66 says "@" is reserved. Scheme specs 
can't override thatt, but they can say whether the reserved characters have a 
reserved purpose (usually as a component delimiter) in that scheme. Martin's 
Internet-Draft implies that it does have a reserved purpose, as a separator 
between the addr-spec subcomponents. Therefore "%40" and "@" aren't 
interchangable.

What a browser displays and whether & how it passes the address to an email 
client isn't relevant. The point is just that AFAIK, when mailto URI 
processors, be they browsers or mailers or combinations thereof, encounter 
mailto:user%40example.org, they behave exactly the same as if it were written 
mailto:user@example.org.

If there weren't so much advice out there saying it's a good idea to obfuscate 
email addresses by percent-encoding the heck out of them, I wouldn't care as 
much that the I-D says nothing about scheme-based equivalence for such URIs. 

> So, I think @ in a mailto URI should be reserved and should be encoded
> as %40.

Hm, no. I'm pretty sure 'reserved' means it falls into the class of characters 
STD66 defines as 'reserved', and "@" does that already. As a member of that 
class, it can only be percent-encoded if it's being used for a purpose other 
than what it's reserved for, if it has a special purpose (which in a mailto 
URI it implicitly does!). Otherwise -- that is, if it's being used for its 
special purpose -- it has to be a literal "@". So it would not be proper to 
say the addr-spec subcomponent-separating "@" ever SHOULD be encoded as "%40".  
I just want there to be some acknowledgment of what happens when it is encoded 
that way by mistake.

Received on Thursday, 31 January 2008 02:46:19 UTC