RFC Errata
Found 5 records.
Status: Verified (2)
RFC 6068, "The 'mailto' URI Scheme", October 2010
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 7919
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Slater
Date Reported: 2024-05-01
Verifier Name: Orie Steele
Date Verified: 2024-07-17
Section 2 says:
1. A number of characters that can appear in <addr-spec> MUST be percent-encoded. These are the characters that cannot appear in a URI according to [STD66] as well as "%" (because it is used for percent-encoding) and all the characters in gen-delims except "@" and ":" (i.e., "/", "?", "#", "[", and "]"). Of the characters in sub-delims, at least the following also have to be percent- encoded: "&", ";", and "=". Care has to be taken both when encoding as well as when decoding to make sure these operations are applied only once.
It should say:
1. A number of characters that can appear in <addr-spec> MUST be percent-encoded. These are the characters that cannot appear in a URI according to [STD66] as well as "%" (because it is used for percent-encoding) and all the characters in gen-delims except "@" and ":" (i.e., "/", "?", "#", "[", and "]"). Care has to be taken both when encoding as well as when decoding to make sure these operations are applied only once.
Notes:
RFC 3986 does not require that sub-delimiters used in one component are encoded in other components. Specifically, RFC 3986 Section 2.1 (https://www.rfc-editor.org/rfc/rfc3986#section-2.1) states that a character requires encoding when it "is being used as a delimiter of, or within, the component."
According to RFC 3986, the mailto URI <mailto:Mike&family@example.org> is unambiguously the single addr-spec "Mike&family@example.org" because the path component of the mailto scheme does not use "&" as a sub-delimiter.
More comprehensively, the mailto URI <mailto:Mike&family@example.org?subject=Use%20of%20%26&body=Should%20be%20fine%20in%20addr-spec> must substitute "%26" for "&" in the value of the body header field because "&" is a query component sub-delimiter in the mailto scheme, but the query is the only component where this is required.
Errata ID: 4020
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: NARUSE, Yui
Date Reported: 2014-06-23
Verifier Name: Barry Leiba
Date Verified: 2014-07-01
Section 2. says:
2. <obs-local-part> and <NO-WS-CTL> as defined in [RFC5322] MUST NOT be used.
It should say:
2. <obs-local-part> and <obs-NO-WS-CTL> as defined in [RFC5322] MUST NOT be used.
Notes:
NO-WS-CTL doesn't exist in RFC5322; it was changed to obs-NO-WS-CTL.
A future update to "mailto" should consider other whitespace changes as well.
Status: Reported (1)
RFC 6068, "The 'mailto' URI Scheme", October 2010
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 4706
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: stream9
Date Reported: 2016-06-08
Section 2.3 says:
3. Whitespace and comments within <local-part> and <domain> MUST NOT be used. They would not have any operational semantics.
It should say:
3. Whitespace and comments within <local-part> and <domain> MUST NOT be used except quoted whitespace in <quoted-string>. They would not have any operational semantics.
Notes:
<local-part> contain <quoted-string> and <quoted-string> contains <quoted-pair> according to definition in RFC 5322.
quoted-pair = ("\" (VCHAR / WSP)) / obs-qp
As definition above, <quoted-pair> contains whitespace <WSP> which according to RFC 6068, MUST NOT be used.
But example in RFC 6068 section 6.2 contain quoted whitespace. So I guess this is an exception.
Status: Held for Document Update (1)
RFC 6068, "The 'mailto' URI Scheme", October 2010
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 3265
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Levine
Date Reported: 2012-06-23
Held for Document Update by: Barry Leiba
Section 11.1 says:
[RFC5322] Resnik, P.,
It should say:
[RFC5322] Resnick, P.,
Notes:
Pete Resnick's name spelled wrong. Oops.
Status: Rejected (1)
RFC 6068, "The 'mailto' URI Scheme", October 2010
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 3491
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Stefan Ganzer
Date Reported: 2013-02-20
Rejected by: Pete Resnick
Date Rejected: 2013-03-08
Section 2 says:
domain = dot-atom-text / "[" *dtext-no-obs "]"
It should say:
domain = dot-atom-text
Notes:
Mailto URI has a hier-part that is either path-rootless or path-empty,
with an optional query component (see the syntax from RFC 3986 below).
In the path-rootless part, only characters in the set <pchar> are allowed.
Therefore the <domain> rule violates the general URI syntax, as it uses
the characters "[" and "]", which are not in <pchar>, to delimit a domain literal.
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
path-rootless = segment-nz *( "/" segment )
segment = *pchar
segment-nz = 1*pchar
query = *( pchar / "/" / "?" )
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
--VERIFIER NOTES--
The "Corrected Text" suggested by the reporter is incorrect. There are also several things in dot-atom-text which are also not in <pchar> ("#", "/", "?", "^", "`", "{", "|", "}"), so leaving dot-atom-text in place would not address the concern of the reporter. RFC 6068's answer is to simply say that, ABNF notwithstanding, some of the characters will need to be percent-encoded:
1. A number of characters that can appear in <addr-spec> MUST be
percent-encoded. These are the characters that cannot appear in
a URI according to [STD66] as well as "%" (because it is used for
percent-encoding) and all the characters in gen-delims except "@"
and ":" (i.e., "/", "?", "#", "[", and "]"). Of the characters
in sub-delims, at least the following also have to be percent-
encoded: "&", ";", and "=". Care has to be taken both when
encoding as well as when decoding to make sure these operations
are applied only once.
Now, this may have been a bogus way to do it (because you've got an ABNF which then has to be re-encoded to agree with generic URI syntax), but it was clearly agreed to when this document was published. Something may be wrong here, but this is not appropriate for a simple erratum.