Decoding of URIs is described in RFC3986, but see ECMAScript's decodeURIComponent for decoding hvalues.
When a mailto client is passed a mailto URI, the client creates a compose form and uses the information from the URI to fill in the TO, CC, BCC, SUBJECT and BODY fields. This document serves as a companion to RFC2368.
In your mailto client's compose form, you should get the following results. [9]
To:
Cc:
Bcc:
Subject:
The client accomplishes this by parsing the mailto URI according to certain rules, which are described below.
Parsing a mailto URI into a compose form.
CC: Join all non-empty [4] CC hvalues with %2C%20 and decode.
BCC: Join all non-empty BCC hvalues with %2C%20 and decode. [7]
TO: Join all non-empty TO hvalues with %2C%20 and decode.
SUBJECT: Decode the last SUBJECT hvalue.
BODY: Join the first non-empty [1] BODY hvalue and all BODY hvalues after that with %0D%0A and decode.
Mailto URIs are parsed left to right.
Addresses should appear in the fields in the same order they appear in the URI.
Matching of hnames is case-insensitive.
If user input for the TO, CC and BCC fields requires properly-escaped values, after decoding, all " and \ characters in the values must remain. The values must not be deescaped to remove these characters. If user input for the fields is literal, outside quotes and the \ before each escaped character would be removed. [2]
Because forms with action="mailto:" submit spaces as + instead of %20, all + characters in hvalues should be converted to %20 before decoding. [3]
Copying data
The rules above must also be followed when a UA parses a mailto URI to generate a TO, BCC, CC, SUBJECT or BODY value that will later be inserted into the corresponding field of a mail client compose form.
An example of this is right-clicking on a mailto link and selecting "Copy e-mail address". [6]
Notes & Issues
Should empty BODY hvalues that appear before the first non-empty BODY hvalue really be ignored? Thunderbird does it, but...
For literal user input, should the exact process of removing escape characters and outside quotes in TO, CC and BCC values be described? M2 and most other clients (including webmails) require properly-escaped values, but Thunderbird allows both. However, Thunderbird deescapes TO and CC address differently (probably due to bugs).
Empty TO, CC and BCC hvalues should probably be ignored. It doesn't make sense to keep them. Thunderbird for example ignores them, but M2 does not.
Thunderbird is an example of a client that has a compose form where each address is in its own field. Should it be described how to split the addresses into separate fields? Address are separated by a comma and a space, so it's probably obvious, but some specifics maybe?
M2 and Thunderbird are only focused on because they have more complete mailto parsing support than others. Most of the parsing support specified here has never been added by other clients.
In Thunderbird, each address is in its own field instead of a comma-separated list in one field.