RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Verified (5)

RFC 7940, "Representing Label Generation Rulesets Using XML", August 2016

Source of RFC: lager (art)

Errata ID: 5986
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: KIM Kyongsok
Date Reported: 2020-02-22
Verifier Name: Barry Leiba
Date Verified: 2020-02-22

Section 6.3.1 says: 

   A simple rule to match a label where all characters are members of
   some class called "preferred-codepoint":          

       <rule name="preferred-label">
           <start />
           <class by-ref="preferred-codepoint" count="1"/>
           <end />
       </rule>

It should say:

   A simple rule to match a label where all characters are members of
   some class called "preferred-codepoint":           

       <rule name="preferred-label">
           <start />
           <class by-ref="preferred-codepoint" count="1+"/>
           <end />
       </rule>

Notes:

Currently the value for count is 1, which means that the rule will match a label composed of only one char.
However, since the rule is supposed to match a label composed one or more chars, the value ofr count must be "1+" .

Errata ID: 5987
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: KIM Kyongsok
Date Reported: 2020-02-22
Verifier Name: Barry Leiba
Date Verified: 2020-02-22

Section 5.3.1 says: 

   Variant code points are specified using one of more "var" elements as
   children of a "char" element.

It should say:

   Variant code points are specified using one or more "var" elements as
   children of a "char" element.

Notes:

Based on the context, "one or more" seems correct, NOT "one of more".

Errata ID: 6102
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Bauland
Date Reported: 2020-04-14
Verifier Name: Barry Leiba
Date Verified: 2020-04-14

Section 5.4.2. says: 

Any "char", "range", or "variant" element in the "data" section may contain an OPTIONAL "comment" attribute.

It should say:

Any "char", "range", or "var" element in the "data" section may contain an OPTIONAL "comment" attribute.

Notes:

The variant element is <var> not <variant>.

Errata ID: 6105
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Bauland
Date Reported: 2020-04-14
Verifier Name: Barry Leiba
Date Verified: 2020-04-14

Section 7.2.1. says: 

A label "yy" would have the variants "xy", "yx", and "xx".  Because the variant mapping from "y" to "x" is of type "allocatable" and a mapping from "y" to "y" is not defined, the labels "xy" and "yx" trigger the "any-variant" condition on the third label.

It should say:

A label "yy" would have the variants "xy", "yx", and "xx".  Because the variant mapping from "y" to "x" is of type "allocatable" and a mapping from "y" to "y" is not defined, the labels "xy" and "yx" trigger the "any-variant" condition on the third action.

Notes:

The "third label" at the end of the sentence makes no sense in this context, instead it should read that the condition of the "third action" is triggered.

Errata ID: 6106
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Asmus Freytag
Date Reported: 2020-04-14
Verifier Name: Barry Leiba
Date Verified: 2020-04-14

Section 7.2.1 says: 

Nevertheless, they do participate in the permutation of variant
   labels for n-repertoire labels

It should say:

Nevertheless, they do participate in the permutation of variant
   labels for in-repertoire labels

Notes:

The intention is the contrast to "out-of-repertoire"; no term "n-repertoire" is defined.

Status: Reported (1)

RFC 7940, "Representing Label Generation Rulesets Using XML", August 2016

Source of RFC: lager (art)

Errata ID: 5167
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Phil Pennock
Date Reported: 2017-10-24

Section 4.3.7 says: 

   Whenever an LGR depends on character properties from a given version
   of the Unicode Standard, the version number used in creating the LGR
   MUST be listed in the form x.y.z, where x, y, and z are positive
   decimal integers (see [Unicode-Versions]).

It should say:

   Whenever an LGR depends on character properties from a given version
   of the Unicode Standard, the version number used in creating the LGR
   MUST be listed in the form x.y.z, where x, y, and z are non-negative
   decimal integers (see [Unicode-Versions]).

Notes:

A zero needs to be allowed in the version numbering, as included in the example below. Zero is neither positive nor negative. "0, 1, 2, ..." are the "non-negative decimal integers". Positive decimal integers start at 1.

Thus for "6.3.0" to be a valid example, the constraint needs to be "non-negative" rather than "positive".

Report New Errata



Advanced Search