RFC Errata
Found 5 records.
Status: Verified (2)
RFC 7622, "Extensible Messaging and Presence Protocol (XMPP): Address Format", September 2015
Source of RFC: xmpp (art)
Errata ID: 4534
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sam Whited
Date Reported: 2015-11-14
Verifier Name: Barry Leiba
Date Verified: 2019-07-02
Section 3.2.2 says:
An entity that performs enforcement in XMPP domainpart slots MUST prepare a string as described in Section 3.2.1 and MUST also apply the normalization, case-mapping, and width-mapping rules defined in [RFC5892].
It should say:
An entity that performs enforcement in XMPP domainpart slots MUST prepare a string as described in Section 3.2.1 and MUST also apply the normalization, case-mapping, and width-mapping rules defined in [RFC5895].
Notes:
RFC 5892 is just a list of codepoints; the rules to which it is referring (and that are referred to in the ABNF and other places in the document) are in RFC 5895.
Errata ID: 4560
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Saint-Andre
Date Reported: 2015-12-07
Verifier Name: Barry Leiba
Date Verified: 2015-12-12
Section 3.5 says:
| 18| <juliet@example.com/ foo> | Leading space in resourcepart |
It should say:
[nothing]
Notes:
Example 18 is wrong because a leading space is currently allowed by RFC 7622 (at least, it is not disallowed by the OpaqueString profile defined in RFC 7613). It is true that leading and trailing spaces are disallowed by the Nickname profile, but we do not reference that here. This example should be removed in any updates to RFC 7622.
Status: Held for Document Update (3)
RFC 7622, "Extensible Messaging and Presence Protocol (XMPP): Address Format", September 2015
Source of RFC: xmpp (art)
Errata ID: 5769
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Florian Schmaus
Date Reported: 2019-06-30
Held for Document Update by: Barry Leiba
Date Held: 2019-07-02
Section 3.2.1 says:
An entity that prepares a string for inclusion in an XMPP domainpart slot MUST ensure that the string consists only of Unicode code points that are allowed in NR-LDH labels or U-labels as defined in [RFC5890].
It should say:
An entity that prepares a string for inclusion in an XMPP domainpart slot MUST ensure that the string consists only of Unicode code points that are allowed in NR-LDH labels or U-labels as defined in [RFC5890], or the DNS label separator "dot" (U+002E, FULL STOP).
Notes:
The current specification forbids the inclusion of dots (".") in the domainpart, since they are not allowed in NR-LDH nor U-labels. But they should be allowed, as otherwise a DNS name could never be put into an XMPP domainpart (which is commonly done).
----- Verifier notes -----
This is correct as far as it goes, but there's more to the fix than this, so proper discussion, consensus, and document update are needed. There are, for example, other dot characters that need to be allowed as well as U+002E. The bottom line is that Florian is correct that DNS label separators need to be allowed, and the proper fix to the text is deferred to any future document update.
Errata ID: 5789
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Florian Schmaus
Date Reported: 2019-07-22
Held for Document Update by: Barry Leiba
Date Held: 2019-07-22
Section 3.2.1 says:
An entity that prepares a string for inclusion in an XMPP domainpart slot MUST ensure that the string consists only of Unicode code points that are allowed in NR-LDH labels or U-labels as defined in [RFC5890].
It should say:
An entity that prepares a string for inclusion in an XMPP domainpart slot MUST ensure that the string consists only of - code points allowed in U-labels as defined in [RFC5890] - % U+0025 PERCENT SIGN - . U+002E (FULL STOP, DNS label separator "dot") - : U+003A (COLON) - ] U+005B (LEFT SQUARE BRACKET) - [ U+005D (RIGHT SQUARE BRACKET)
Notes:
This is a follow up and update on Errata ID #5769. Besides allowing DNS label separators in the domainpart, this further allows codepoints not allowed in U-labels but required by the IP-literal rule of RFC6874, which is used by RFC7622 to allow IPv6 addresses in XMPP domainparts. As in the previous errata, this also drops the reference to NR-LDH labels, which I believe to be unnecessary.
===== Verifier Notes =====
As with the related errata report, this is held for document update because more discussion and consensus is needed. So this is on record for that discussion.
Errata ID: 4470
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2015-09-10
Held for Document Update by: Ben Campbell
Date Held: 2015-09-12
Section 3.5 says:
<king@example.com/♚>;
It should say:
<king@example.com/♚>
Notes:
Right angle bracket arrived too soon.