RFC Errata
Found 6 records.
Status: Reported (1)
RFC 6120, "Extensible Messaging and Presence Protocol (XMPP): Core", March 2011
Note: This RFC has been updated by RFC 7590, RFC 8553
Source of RFC: xmpp (rai)
Errata ID: 4228
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Georg Sauthoff
Date Reported: 2015-01-10
Section A.6. says:
<xs:element name='subject'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='thread'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:NMTOKEN'>
<xs:attribute name='parent'
type='xs:NMTOKEN'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
Saint-Andre Standards Track [Page 202]
RFC 6120 XMPP Core March 2011
<xs:element name='subject'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:NMTOKEN'>
<xs:attribute name='parent'
type='xs:NMTOKEN'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
It should say:
<xs:element name='subject'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='thread'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:NMTOKEN'>
<xs:attribute name='parent'
type='xs:NMTOKEN'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
Saint-Andre Standards Track [Page 202]
RFC 6120 XMPP Core March 2011
Notes:
The issue is that the definition of the referenced element 'subject' is duplicated.
This can be easily tested via a command like:
$ xmllint --schema XMLSchema_1.1.xsd server.xsd --noout
server.xsd:84: element element: Schemas validity error : Element '{http://www.w3.org/2001/XMLSchema}element': Duplicate key-sequence ['subject'] in key identity-constraint '{http://www.w3.org/2001/XMLSchema}element'.
server.xsd fails to validate
The corrected text contains one possible edit how to make the XSD of the server namespace valid again. Of course, another possibility would be to remove the first definition of the 'subject' element.
I've eliminated the second definition because the first one equals the one from section A.5. (Client Namespace).
Status: Held for Document Update (5)
RFC 6120, "Extensible Messaging and Presence Protocol (XMPP): Core", March 2011
Note: This RFC has been updated by RFC 7590, RFC 8553
Source of RFC: xmpp (rai)
Errata ID: 4741
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sam Whited
Date Reported: 2016-07-13
Held for Document Update by: Ben Campbell
Date Held: 2016-07-13
Section 8.2.3 says:
1. The 'id' attribute is REQUIRED for IQ stanzas.
…
3. An entity that receives a stanza of type "get" or "set" MUST
reply with an IQ respones of type "result" or "error". The
response MUST preserve the 'id' attribute of the request (or be
empty if the generated stanza did not include an 'id' attribute).
It should say:
1. The 'id' attribute is REQUIRED for IQ stanzas.
…
3. An entity that receives a stanza of type "get" or "set" MUST
reply with an IQ respones of type "result" or "error". The
response MUST preserve the 'id' attribute of the request, or
send an appropriate error if the generated stanza did not
include an 'id' attribute.
Notes:
If the received IQ had an empty ID then it was not valid per point 1 and clients and servers cannot key on the ID (eg. for key mapped lists of IQs pending receipt or dispatch of a reply). An appropriate error or other behavior should be defined if the 'id' is meant to be REQUIRED, otherwise, if point 3 is correct, then 'id' should not be REQUIRED.
Errata ID: 2855
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Toby Moncaster
Date Reported: 2011-07-06
Held for Document Update by: Robert Sparks
Section 3.2.1 says:
3. If a response is received, it will contain one or more combinations of a port and FDQN,
It should say:
3. If a response is received, it will contain one or more combinations of a port and FQDN,
Notes:
There are multiple occurrences (1 each in list items 3, 4, 5, 6 & 7). All read FDQN and should read FQDN
Errata ID: 3486
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Marco Cirillo
Date Reported: 2013-02-18
Held for Document Update by: Gonzalo Camarillo
Section 5.4.1 says:
The receiving entity then MUST send stream features to the initiating entity. If the receiving entity supports TLS, the stream features MUST include an advertisement for support of STARTTLS negotiation, i.e., a <starttls/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace.
It should say:
The receiving entity then MUST send stream features to the initiating entity. If the receiving entity offers TLS capability, the stream features MUST include an advertisement for support of STARTTLS negotiation, i.e., a <starttls/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace.
Notes:
Current text mixes up actual support of STARTTLS/TLS (which is mandated by section 5.2) with deployment/availableness of the said.
Errata ID: 3650
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Saint-Andre
Date Reported: 2013-06-12
Held for Document Update by: Richard Barnes
Date Held: 2013-06-13
Section Appendix A.2 says:
<xs:element name='bad-format' type='empty'/>
<xs:element name='bad-namespace-prefix' type='empty'/>
<xs:element name='conflict' type='empty'/>
<xs:element name='connection-timeout' type='empty'/>
<xs:element name='host-gone' type='empty'/>
<xs:element name='host-unknown' type='empty'/>
<xs:element name='improper-addressing' type='empty'/>
<xs:element name='internal-server-error' type='empty'/>
<xs:element name='invalid-from' type='empty'/>
<xs:element name='invalid-id' type='empty'/>
<xs:element name='invalid-namespace' type='empty'/>
<xs:element name='invalid-xml' type='empty'/>
<xs:element name='not-authorized' type='empty'/>
<xs:element name='not-well-formed' type='empty'/>
<xs:element name='policy-violation' type='empty'/>
<xs:element name='remote-connection-failed' type='empty'/>
<xs:element name='reset' type='empty'/>
<xs:element name='resource-constraint' type='empty'/>
<xs:element name='restricted-xml' type='empty'/>
<xs:element name='see-other-host' type='xs:string'/>
<xs:element name='system-shutdown' type='empty'/>
<xs:element name='undefined-condition' type='empty'/>
<xs:element name='unsupported-encoding' type='empty'/>
<xs:element name='unsupported-stanza-type' type='empty'/>
<xs:element name='unsupported-version' type='empty'/>
<xs:group name='streamErrorGroup'>
<xs:choice>
<xs:element ref='bad-format'/>
<xs:element ref='bad-namespace-prefix'/>
<xs:element ref='conflict'/>
<xs:element ref='connection-timeout'/>
<xs:element ref='host-gone'/>
<xs:element ref='host-unknown'/>
<xs:element ref='improper-addressing'/>
<xs:element ref='internal-server-error'/>
<xs:element ref='invalid-from'/>
<xs:element ref='invalid-id'/>
<xs:element ref='invalid-namespace'/>
<xs:element ref='invalid-xml'/>
<xs:element ref='not-authorized'/>
<xs:element ref='not-well-formed'/>
<xs:element ref='policy-violation'/>
<xs:element ref='remote-connection-failed'/>
<xs:element ref='reset'/>
<xs:element ref='resource-constraint'/>
<xs:element ref='restricted-xml'/>
<xs:element ref='see-other-host'/>
<xs:element ref='system-shutdown'/>
<xs:element ref='undefined-condition'/>
<xs:element ref='unsupported-encoding'/>
<xs:element ref='unsupported-stanza-type'/>
<xs:element ref='unsupported-version'/>
</xs:choice>
</xs:group>
It should say:
<xs:element name='bad-format' type='empty'/>
<xs:element name='bad-namespace-prefix' type='empty'/>
<xs:element name='conflict' type='empty'/>
<xs:element name='connection-timeout' type='empty'/>
<xs:element name='host-gone' type='empty'/>
<xs:element name='host-unknown' type='empty'/>
<xs:element name='improper-addressing' type='empty'/>
<xs:element name='internal-server-error' type='empty'/>
<xs:element name='invalid-from' type='empty'/>
<xs:element name='invalid-namespace' type='empty'/>
<xs:element name='invalid-xml' type='empty'/>
<xs:element name='not-authorized' type='empty'/>
<xs:element name='not-well-formed' type='empty'/>
<xs:element name='policy-violation' type='empty'/>
<xs:element name='remote-connection-failed' type='empty'/>
<xs:element name='reset' type='empty'/>
<xs:element name='resource-constraint' type='empty'/>
<xs:element name='restricted-xml' type='empty'/>
<xs:element name='see-other-host' type='xs:string'/>
<xs:element name='system-shutdown' type='empty'/>
<xs:element name='undefined-condition' type='empty'/>
<xs:element name='unsupported-encoding' type='empty'/>
<xs:element name='unsupported-feature' type='empty'/>
<xs:element name='unsupported-stanza-type' type='empty'/>
<xs:element name='unsupported-version' type='empty'/>
<xs:group name='streamErrorGroup'>
<xs:choice>
<xs:element ref='bad-format'/>
<xs:element ref='bad-namespace-prefix'/>
<xs:element ref='conflict'/>
<xs:element ref='connection-timeout'/>
<xs:element ref='host-gone'/>
<xs:element ref='host-unknown'/>
<xs:element ref='improper-addressing'/>
<xs:element ref='internal-server-error'/>
<xs:element ref='invalid-from'/>
<xs:element ref='invalid-namespace'/>
<xs:element ref='invalid-xml'/>
<xs:element ref='not-authorized'/>
<xs:element ref='not-well-formed'/>
<xs:element ref='policy-violation'/>
<xs:element ref='remote-connection-failed'/>
<xs:element ref='reset'/>
<xs:element ref='resource-constraint'/>
<xs:element ref='restricted-xml'/>
<xs:element ref='see-other-host'/>
<xs:element ref='system-shutdown'/>
<xs:element ref='undefined-condition'/>
<xs:element ref='unsupported-encoding'/>
<xs:element ref='unsupported-feature'/>
<xs:element ref='unsupported-stanza-type'/>
<xs:element ref='unsupported-version'/>
</xs:choice>
</xs:group>
Notes:
The "invalid-id" error condition was removed in the changes between RFC 3920 and RFC 6120, but mistakenly not removed from the schema. The "unsupported-feature" error condition was added in the changes between RFC 3920 and RFC 6120, but mistakenly not added to the schema.
This bug was found by Anastasia Gornostaeva.
Implementors using the schema as updated by this erratum should note that if they produce XML that includes the "unsupported-feature" element, then it might be rejected as invalid by implementations using the original schema. Likewise, if they produce XML that includes the "invalid-id" element, then it might be rejected as invalid by implementations following the revised schema.
Errata ID: 3651
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Peter Saint-Andre
Date Reported: 2013-06-12
Held for Document Update by: Richard Barnes
Section 4.9.3.19 says:
"(b) the receiving entity MAY have a policy of following redirects only if it has authenticated the receiving entity"
It should say:
"(b) the initiating entity MAY have a policy of following redirects only if it has authenticated the receiving entity"
Notes:
This bug was found by Yann Leboulanger.