Found 2 records.

Status: Verified (2)

RFC 7622, "Extensible Messaging and Presence Protocol (XMPP): Address Format", September 2015

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.

Report New Errata