RFC Errata Report » RFC Editor
Search RFCs
Advanced Search
RFC Editor
The Series
Document Retrieval
Errata
FAQ
Format Change FAQ
History
Other Information
For Authors
Publication Process
Publication Queue
Style Guide
I-D Author Resources
Independent Submissions
Sponsor
RFC Errata
Found 3 records.
Status:
Verified
(1)
RFC 4647
, "Matching of Language Tags", September 2006
Source of RFC
: ltru (app)
Errata ID:
8838
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mandrusov Roman
Date Reported: 2026-03-17
Verifier Name: RFC Editor
Date Verified: 2026-03-18
Section 2.2 says:
However, wildcards outside the first position are ignored by Extended Filtering
(see Section 3.2.2).
It should say:
However, wildcards outside the first position are ignored by Extended Filtering
(see Section 3.3.2).
Notes:
The document refers to the Section 3.2.2 as a description of Extended Filtering but there is no such section. The correct section is 3.3.2.
Status:
Reported
(1)
RFC 4647
, "Matching of Language Tags", September 2006
Source of RFC
: ltru (app)
Errata ID:
8287
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Randall Edward Cotton
Date Reported: 2025-02-08
Section 3.1 says:
3. Lookup (Section 3.4) matches a language priority list consisting
of basic language ranges to sets of language tags to find the one
exact language tag that best matches the range.
It should say:
3. Lookup (Section 3.4) matches a language priority list consisting
of basic and/or extended language ranges to sets of language tags
to find the one exact language tag that best matches the range.
Notes:
The original text illustrated above states that the 'lookup' matching scheme operates using 'basic language ranges' as opposed to 'extended language ranges'. However, the description of the 'lookup' matching scheme in section 3.4, in its last two paragraphs (beginning with "In some cases,"), describes how extended language ranges are processed by the 'lookup' matching scheme. Thus, section 3.1 indicates that 'extended language ranges' are not supported by the 'lookup' matching scheme, while section 3.4 indicates the opposite and describes how they are to be supported.
This contradiction can lead to confusion for the reader and compliance ambiguity for the implementor.
Status:
Held for Document Update
(1)
RFC 4647
, "Matching of Language Tags", September 2006
Source of RFC
: ltru (app)
Errata ID:
8253
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jia Hongchao
Date Reported: 2025-01-17
Held for Document Update by: RFC Editor
Date Held: 2025-01-22
Section 2 and 2.3 says:
For example,
HTTP/1.1 [RFC2616] describes one such mechanism in its discussion of
the Accept-Language header (Section 14.4), which is used when
selecting content from servers based on the language of that content.
...
One well-known example of such a list is the
"Accept-Language" header defined in RFC 2616 [RFC2616] (see Section
14.4) and RFC 3282 [RFC3282].
It should say:
n/a
Notes:
In the HTML version, the hyperlinks for "Section 14.4” in the sentences above should go to Section 14.4 of RFC 2616.
Current:

--VERIFIER NOTES--
This is regarding the links generated in the rfc2html output, not the RFC itself (https://www.rfc-editor.org/rfc/rfc4647.txt).
Report New Errata
IAB
IANA
IETF
IRTF
ISE
ISOC
IETF Trust
Reports
Privacy Statement
Document Retrieval
Errata
Frequently Asked Questions
Future Format FAQ
History
Other Information
Publication Process
Publication Queue
Style Guide
Advanced Search