RFC Errata
Found 2 records.
Status: Reported (1)
RFC 6497, "BCP 47 Extension T - Transformed Content", February 2012
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 7179
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Frederic G. Marand
Date Reported: 2022-10-24
Section 2.5.c says:
There are three dated versions of the UNGEGN transliteration
specification for Hebrew to Latin. They can be represented by
the following language tags:
+ und-Hebr-t-und-latn-m0-ungegn-1972
+ und-Hebr-t-und-latn-m0-ungegn-1977
+ und-Hebr-t-und-latn-m0-ungegn-2007
It should say:
Either:
There are three dated versions of the UNGEGN transliteration
specification for Hebrew to Latin. They can be represented by
the following language tags:
+ und-Latn-t-und-hebr-m0-ungegn-1972
+ und-Latn-t-und-hebr-m0-ungegn-1977
+ und-Latn-t-und-hebr-m0-ungegn-2007
Or:
There are three dated versions of the UNGEGN transliteration
specification for Hebrew from Latin. They can be represented by
the following language tags:
+ und-Hebr-t-und-latn-m0-ungegn-1972
+ und-Hebr-t-und-latn-m0-ungegn-1977
+ und-Hebr-t-und-latn-m0-ungegn-2007
Notes:
The examples provided in the RFC are for "undefined language using hebrew script, transliterated from undefined language using latin script, following the UNGEGN revision of 1972/1977/2007.
However the text says these examples are for Hebrew to Latin, although these examples are for Latin to Hebrew. The text should either change the example description from "for Hebrew from Latin", or swap the language tags as suggested.
Status: Rejected (1)
RFC 6497, "BCP 47 Extension T - Transformed Content", February 2012
Source of RFC: IETF - NON WORKING GROUP
Errata ID: 4362
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Ziegast
Date Reported: 2015-05-11
Rejected by: Barry Leiba
Date Rejected: 2015-05-12
Section All says:
This registration is invalid because it attempts to impose restrictions on field ordering the governing BCP47 has as illegal for extension subtag canonicalization. The subtags are limited to 8 characters, and any subfields of a subtag must use a DIGIT or ALPHA that is not a valid subfield character as separator, not DASH as specified, to maintain a particular subfield order.
It should say:
Not correctable, must be reformulated and resubmitted as new RFC.
Notes:
--VERIFIER NOTES--
BCP 47 requires that extensions have a canonical form. There is no restriction on subtag ordering in an extension imposed by BCP 47, but an extension can specify such an order (in this case it does). Subtags in this RFC are separated by DASH and the dash is not part of any subtag. Unlike the base language tag, there is interplay between subtags, but this is not the same thing as the submitter implies. There exist important implementations that depend on this.