Search RFCs

RFC Editor

Found 7 records.

Status:Verified (6)

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

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:8409
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Bernard
Date Reported: 2025-05-07
Verifier Name: Andy Newton
Date Verified: 2025-05-07

Section 6.4.3. says:

       <char cp="30FB" when="japanese-in-label"/>       <rule name="japanese-in-label">           <union>               <class property="sc:Hani"/>               <class property="sc:Kata"/>               <class property="sc:Hira"/>           </union>       </rule>

It should say:

       <char cp="30FB" when="japanese-in-label"/>       <rule name="japanese-in-label">           <union>               <class property="sc:Hani"/>               <class property="sc:Kana"/>               <class property="sc:Hira"/>           </union>       </rule>

Notes:

ISO 15924 code for Katakana is Kana, not Kata

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

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