RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 11 records.

Status: Verified (6)

RFC 7991, "The "xml2rfc" Version 3 Vocabulary", December 2016

Source of RFC: IAB

Errata ID: 5052
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Henrik Levkowetz
Date Reported: 2017-06-25
Verifier Name: Robert Sparks
Date Verified: 2018-02-09

Section B.1 says:

<x:include href="file://home/chris/ietf/drafts/commontext.xml"/>

It should say:

<xi:include href="file://home/chris/ietf/drafts/commontext.xml"/>

Notes:

Section B.1. talks about using XInclude for inclusion of external materials, instead of using entity references or processing instructions to include materials. It shows an example namespace declaration:

xmlns:xi="http://www.w3.org/2001/XInclude"

and then continues with various examples using <xi:include/>, except that in one case, an 'i" has been dropped from the "xi:", giving <x:include...>.

Errata ID: 5618
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Kent Watsen
Date Reported: 2019-01-31
Verifier Name: Mirja Kühlewnd (IAB/RSAB chair)
Date Verified: 2024-03-14

Section 2.5.6 says:

It is an error to have both a "src" attribute and content in the
<artwork> element.

Notes:

This sentence needs to be removed because the second paragraph in Section 2.5 says that the "textual content acts as a fallback" for the "src" attribute.

Errata ID: 5887
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Rolf van Kleef
Date Reported: 2019-10-30
Verifier Name: Mirja Kühlewnd (IAB/RSAB chair)
Date Verified: 2024-03-14

Section Appendix C says:

xref =
  element xref {
    attribute xml:base { text }?,
    attribute xml:lang { text }?,
    attribute target { xsd:IDREF },
    [ a:defaultValue = "false" ]
    attribute pageno { "true" | "false" }?,
    [ a:defaultValue = "default" ]
    attribute format { "default" | "title" | "counter" | "none" }?,
    attribute derivedContent { text }?,
    text
  }

It should say:

xref =
  element xref {
    attribute xml:base { text }?,
    attribute xml:lang { text }?,
    attribute target { xsd:IDREF },
    [ a:defaultValue = "false" ]
    attribute pageno { "true" | "false" }?,
    [ a:defaultValue = "default" ]
    attribute format { "default" | "title" | "counter" | "none" }?,
    attribute derivedContent { text }?,
    attribute relative { text }?,
    attribute section { text }?,
    [ a:defaultValue = "of" ]
    attribute sectionFormat { "of" | "comma" | "parens" | "bare" }?,
    text
  }

Notes:

In section 1.3.2: New Attributes for Existing Elements, the attributes 'relative', 'section', and 'sectionFormat' are added to the xref element. This is, however, not reflected in appendix C.

This same mistake is reflected in appendix D.

Errata ID: 6387
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Julian Reschke
Date Reported: 2021-01-18
Verifier Name: Mirja Kühlewiind (IAB Chair)
Date Verified: 2021-02-04

Section 2.48 says:

   When rendered, source code is always shown in a monospace font.  When
   <sourcecode> is a child of <figure> or <section>, it provides full
   control of horizontal whitespace and line breaks.  When formatted, it
   is indented relative to the left margin of the enclosing element.  It
   is thus useful for source code and formal languages (such as ABNF
   [RFC5234] or the RNC notation used in this document).  (When
   <sourcecode> is a child of other elements, it flows with the text
   that surrounds it.)  Tab characters (U+0009) inside of this element
   are prohibited.

It should say:

   When rendered, source code is always shown in a monospace font. 
   Furthermore, it provides full
   control of horizontal whitespace and line breaks.
   Tab characters (U+0009) inside of this element
   are prohibited.

Notes:

The text hints at uses of <sourcecode> as inline element, but the grammar does not allow any such use.

Errata ID: 6424
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: John Levine
Date Reported: 2021-02-09
Verifier Name: Mirja Kühlewind (IAB Chair)
Date Verified: 2021-03-05

Section 2.6 says:

   o  <list> elements (Section 3.4)

Notes:

The <list> element should be removed in 2.6. as it is deprecated and only occurs under <t>.

Errata ID: 5914
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Jeffrey Yasskin
Date Reported: 2019-11-19

Section A.3 says:

The consensus attribute can be used to supply this information.  The
   acceptable values are "true" (the default) and "false"; "yes" and
   "no" from v2 are deprecated.

It should say:

The consensus attribute can be used to supply this information.  The
   acceptable values are "true" and "false" (the default); "yes" and
   "no" from v2 are deprecated.

Notes:

Section 2.45.2. "consensus" Attribute says,

>>>>>>
Affects the generated boilerplate. Note that the values of "no" and
"yes" are deprecated and are replaced by "false" (the default) and
"true".

See [RFC7841] for more information.

Allowed values:

o "no"

o "yes"

o "false" (default)

o "true"
<<<<<<

Which is the opposite default from what A.3 currently claims. These should be consistent.

Status: Reported (1)

RFC 7991, "The "xml2rfc" Version 3 Vocabulary", December 2016

Source of RFC: IAB

Errata ID: 6574
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Julian Reschke
Date Reported: 2021-05-06

Section 5 says:

   Using escaping:
   <sourcecode>
      allowed-chars = "." | "," | "&amp;" | "&lt;" | "&gt;" | "|"
   </sourcecode>

It should say:

   Using escaping:
   <sourcecode>
      allowed-chars = "." | "," | "&amp;" | "&lt;" | ">" | "|"
   </sourcecode>

Notes:

The example suggests that ">" needs to be escaped in absence of CDATA. This is not correct. This is a problem, as the intent of this section is to actually describe escaping *precisely*.

Status: Held for Document Update (3)

RFC 7991, "The "xml2rfc" Version 3 Vocabulary", December 2016

Source of RFC: IAB

Errata ID: 4906
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Julian Reschke
Date Reported: 2017-01-15
Held for Document Update by: Robert Sparks
Date Held: 2018-02-09

Section Appendix C says:

   artwork =
     element artwork {
       attribute xml:base { text }?,
       attribute xml:lang { text }?,
       attribute anchor { xsd:ID }?,
       attribute pn { text }?,
       attribute xml:space { text }?,
       [ a:defaultValue = "" ] attribute name { text }?,
       [ a:defaultValue = "" ] attribute type { text }?,
       attribute src { text }?,
       [ a:defaultValue = "left" ]
       attribute align { "left" | "center" | "right" }?,
       [ a:defaultValue = "" ] attribute alt { text }?,
       [ a:defaultValue = "" ] attribute width { text }?,
       [ a:defaultValue = "" ] attribute height { text }?,
       attribute originalSrc { text }?,
       (text* | svg)
     }
   # https://www.rfc-editor.org/materials/format/SVG-1.2-RFC.rnc

It should say:

   artwork =
     element artwork {
       attribute xml:base { text }?,
       attribute xml:lang { text }?,
       attribute anchor { xsd:ID }?,
       attribute pn { text }?,
       attribute xml:space { text }?,
       [ a:defaultValue = "" ] attribute name { text }?,
       [ a:defaultValue = "" ] attribute type { text }?,
       attribute src { text }?,
       [ a:defaultValue = "left" ]
       attribute align { "left" | "center" | "right" }?,
       [ a:defaultValue = "" ] attribute alt { text }?,
       [ a:defaultValue = "" ] attribute width { text }?,
       [ a:defaultValue = "" ] attribute height { text }?,
       attribute originalSrc { text }?,
       (text* | svg)
     }

   include "https://www.rfc-editor.org/materials/format/SVG-1.2-RFC.rnc"

Notes:

Without actually including the SVG RNC grammar, *this* grammar is incomplete.

(Note that when this is applied, Appendix D, if still present, would need to be adjusted as well)

Errata ID: 4904
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Julian Reschke
Date Reported: 2017-01-15
Held for Document Update by: Robert Sparks
Date Held: 2018-02-09

Section 2.25.2 says:

   Deprecated.  If the goal is to provide a single URI for a reference,
   use the "target" attribute in <reference> instead.

Notes:

This text doesn't make any sense, as the purpose for "alt" is something entirely different. The reason why it really was deprecated will have to be included here.

Errata ID: 4905
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Julian Reschke
Date Reported: 2017-01-15
Held for Document Update by: Robert Sparks
Date Held: 2018-02-09

Section 9.1 says:

   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/bcp14>.

It should say:

   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              March 1997,
              <http://www.rfc-editor.org/info/bcp14>.

Notes:

BCP14 (as opposed to RFC 2119) doesn't have a DOI, thus it shouldn't be listed here.

Status: Rejected (1)

RFC 7991, "The "xml2rfc" Version 3 Vocabulary", December 2016

Source of RFC: IAB

Errata ID: 5781
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: John Klensin
Date Reported: 2019-07-14
Rejected by: Mirja Kühlewind (RSAB chair)
Date Rejected: 2024-03-13

Section Hdr & Abstra says:

Header: Obsoletes: 7749

And, in the Abstract: 

This document obsoletes the v2 grammar described in RFC 7749.

It should say:

Header: remove the "Obsoletes" line

Abstract: 

This new version of the syntax is expected to supersede the v2 grammar
described in RFC 7749 and has started to do so.

Notes:

The norm in the IETF is that is one document obsoletes another, we treat the obsoleted document as dead and no longer to be referenced. But xml2rfc v2 is very much not obsolete and won't be obsolete until v3 is fully deployed, I-Ds are __no longer__ being prepared and passed to the submission tool in v2, and the RFC Editor stops accepting v2 files when a document is transferred to them from a Stream manager.

We should accurately describe the status of documents, not anticipate the future, especially while the most common practice _in the IETF_ is still to use the prior version and its syntax.
--VERIFIER NOTES--
An RFC can obsolete another RFC without moving the RFC to historic. This is also what is done for newer versions of certain protocols like e.g. TLS.

Report New Errata



Advanced Search