W3C home > Mailing lists > Public > uri@w3.org > March 2009

draft-duerst-mailto-bis-05: Detailed review of '@' and '+'

From: Michael A. Puls II <shadow2531@gmail.com>
Date: Tue, 10 Mar 2009 22:42:04 -0400
To: uri@w3.org
Message-ID: <op.uqlwgcvq1ejg13@sandra-svwliu01>
In an http URI, if I want to put '@' and '+' in an hfvalue, I need to percent-encode them like this:

Now, in a mailto URI, which is of the form:


, I would expect to do the same like this for example:


However, <http://tools.ietf.org/html/draft-duerst-mailto-bis-05> greatly confuses me as to whether '@' and '+' need to be percent-encoded in hfvalues or not. It talks about '@' (and indirectly about '+') not needing to be percent-encoded in an addr-spec. However, it doesn't say for sure what happens to '@' and '+' in an addr-spec once you put the addr-spec in an hfvalue. It defers to the URI spec though, which says that '@' and '+' must be percent-encoded to %40 and %2B. But, that seems to contradict the mailto *uri* examples in the mailto spec, which leave '@' and '+' unencoded.

However, my interpretation is that, before you put an addr-spec in an hfvalue, you have to percent-encode (like ECMAScript's encodeURIComponent) the whole addr-spec first. So, for example, if I wanted the string "1+2@example.com" to end up in the To, Cc, Bcc, Body and Subject fields, I'd produce:




(Given that the spec says mailto:to_hfvalue and mailto:?to=hfvalue are equivalent)

Then, the client would percent-decode (like ECMAScript's decodeURIComponent) each of the hfvalues to "1+2@example.com" and put it in each of the compose/header fields.

However, the examples in the spec seem to keep the '@' in the addr-specs in raw form even after putting them in a URI like:


That doesn't seem correct. It does kind of seem correct for the part between 'mailto:' and '?', given that the ABNF says [ addr-spec *("%2C" addr-spec ) ] instead of to_hfvalue or something (and that it's before '?' which would make it like the raw '@' in the username:password part in an http URI). But, it doesn't seem correct at all for the cc hfvalue.

But, if the part between 'mailto:' and '?' is not an hfvalue at all and is just a raw, comma-separated addr-spec list where certain characters like ',' and ' ' need to be percent-encoded, then I guess that would explain things partially. However, if that's true, then it would mean that mailto:value is NOT equivalent to 'mailto:?to=value' in the sense of how they are percent-encoded, which would contradict the spec saying that they are equivalent.

This then would have me believe that

would be correct as only the second value is really an hfvalue.

However, it has been suggested to me that '@' and '+' do not need to be percent-encoded in [to], or in any hfvalue if the hfvalue is known to hold addr-specs, but they do need to be percent-encoded in all other hfvalues. However, this doesn't seem correct as how would you know if the hfvalue was properly encoded for arbitrary hfvalues like "mailto:?zipzambam=" where you wouldn't know?

It seems to me that:


should be equivalent to:


for how the values are percent-encoded.

Or, is the spec just saying that in a mailto URI, '@' and '+" are not reserved for anything, so they can|should|must appear in raw form throughout the mailto URI whether they're in [to] or an hfname or hfvalue?

Yet, I'm just not sure what the spec is saying. Could *many* people clear this up? And, before you answer, please ask yourself if you're sure (given the text in the spec).

In addtion, I'll also ask the question in a different way. Given the following 2 functions, what does the spec say?

Does it say:

Use the first function for producing the [to] value and the second function for producing hfnames and hfvalues?

Or, does it say to use the second function to produce all values?

Or, does it say to use the first function to produce all values?

Or, does it say to use the first function for all values that are known to contain addr-specs and the second function for the rest?

function encodeToComponent(to) {
    try {
        return encodeURIComponent(to).replace(/\r\n|r|\n/g, "\r\n").replace(/(%40)|(%2B)/gi, function(match, at, plus) {
            if (at) return "@";
            if (plus) return "+";
    } catch(e) {
        return "percent-encode%20error";

function encodeHfnameOrHfvalueComponent(value) {
    try {
        return encodeURIComponent(value.replace(/\r\n|r|\n/g, "\r\n"));
    } catch (e) {
        return "percent-encode%20error";
var test = "1+2@example.com";


Received on Wednesday, 11 March 2009 02:42:44 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:52 UTC