RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Reported (1)

RFC 6497, "BCP 47 Extension T - Transformed Content", February 2012

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

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
Area Assignment: art

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.

Report New Errata



Advanced Search