Movatterモバイル変換


[0]ホーム

URL:


Search RFCs

Advanced Search

RFC Editor

RFC Errata


Errata Search

 
Source of RFC 
Summary Table Full Records

Found 2 records.

Status:Held for Document Update (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: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Frederic G. Marand
Date Reported: 2022-10-24
Held for Document Update by: Andy Newton
Date Held: 2025-11-02

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-2007Or: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 toimpose restrictions on field ordering the governingBCP47 has as illegal for extension subtagcanonicalization. The subtags are limited to 8characters, and any subfields of a subtag must use aDIGIT or ALPHA that is not a valid subfield characteras separator, not DASH as specified, to maintain aparticular subfield order.

It should say:

Not correctable, must be reformulated and resubmittedas 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



IABIANAIETFIRTFISEISOCIETF Trust
ReportsPrivacy StatementSite MapContact Us

Advanced Search

[8]ページ先頭

©2009-2026 Movatter.jp