Found 3 records.

Status: Verified (3)

RFC 3920, "Extensible Messaging and Presence Protocol (XMPP): Core", October 2004

Note: This RFC has been obsoleted by RFC 6120

Note: This RFC has been updated by RFC 6122

Errata ID: 704
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Saint-Andre
Date Reported: 2004-12-08

Section 6.6 says:

It has been brought to my attention that in Section 6.6 of RFC 3920, the 
protocol snippet in Step 11 is as follows:
 
    <stream:stream
        xmlns='jabber:client'
        xmlns:stream='http://etherx.jabber.org/streams'
        from='example.com'
        id='s2s_345'
        version='1.0'>
    <stream:features/>
 
Because this is a server-to-server example, the xmlns for that stream 
header should instead be 'jabber:server'.
 

It should say:

[see above]

Notes:

from pending

Errata ID: 212
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Saint-Andre
Date Reported: 2004-11-05

In Appendix C.1, add the following three lines directly after the opening <xs:schema> tag:

  <xs:import namespace='jabber:client'/>
  <xs:import namespace='jabber:server'/>
  <xs:import namespace='jabber:server:dialback'/>

Errata ID: 1406
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2008-04-08
Verifier Name: Alexey Melnikov
Date Verified: 2009-07-06

Section 6.5 says:

The following example shows the data flow for a client authenticating
with a server using SASL, normally after successful TLS negotiation
(note: the alternate steps shown below are provided to illustrate the
protocol for failure cases; they are not exhaustive and would not
necessarily be triggered by the data sent in the example).

It should say:

The following example shows the data flow for a client authenticating
with a server using SASL, normally after successful TLS negotiation
(note: the alternate steps shown below are provided to illustrate the
protocol for failure cases; they are not exhaustive and would not
necessarily be triggered by the data sent in the example).

The digests (response and rspauth) in steps 6 and 7 of the examples
in this and the next section merely show the format, the values don't
correspond to the input values for any known password. 

Notes:

response=d388dad90d4bbd760a152321f2143af7 and
rspauth=ea40f60335c427b5527b84dbabcdfffd are the digest
values for the first example in RFC 2831 chapter 4.

Report New Errata