RFC 4647

Matching of Language Tags

📅 published September 2006, from ietf

RFC 4647: Matching of Language Tags 🌸

Okay bestie, this is RFC 4647: Matching of Language Tags, a Best Current Practice (it's BCP 47 in the series) 💅. It was published in September 2006 by the Network Working Group, edited by A. Phillips (Yahoo! Inc.) and M. Davis (Google). It obsoletes RFC 3066 🫶.

Status of This Memo

This document is an Internet Best Current Practice for the Internet Community. It also asks for discussion and suggestions for improvements, and distribution of the memo is unlimited ✨.

Copyright (C) The Internet Society (2006) 🔥.

Abstract

This doc describes a syntax called a "language-range" for specifying items in a user's list of language preferences 💖. It also describes different ways to compare and match those ranges to language tags 🦋. There are two kinds of matching, filtering and lookup. Filtering gives you a set of language tags that could be empty, while lookup gives you exactly one language tag 👑. Possible uses include language negotiation or content selection 🎀.

This document, together with RFC 4646, replaces RFC 3066, which had replaced RFC 1766 🧚.

Table of Contents

1. Introduction ....................................................3
2. The Language Range ..............................................3
   2.1. Basic Language Range .......................................4
   2.2. Extended Language Range ....................................4
   2.3. The Language Priority List .................................5
3. Types of Matching ...............................................6
   3.1. Choosing a Matching Scheme .................................6
   3.2. Implementation Considerations ..............................7
   3.3. Filtering ..................................................8
        3.3.1. Basic Filtering .....................................9
        3.3.2. Extended Filtering .................................10
   3.4. Lookup ....................................................12
        3.4.1. Default Values .....................................14
4. Other Considerations ...........................................15
   4.1. Choosing Language Ranges ..................................15
   4.2. Meaning of Language Tags and Ranges .......................16
   4.3. Considerations for Private-Use Subtags ....................17
   4.4. Length Considerations for Language Ranges .................17
5. Security Considerations ........................................17
6. Character Set Considerations ...................................17
7. References .....................................................18
   7.1. Normative References ......................................18
   7.2. Informative References ....................................18
Appendix A. Acknowledgements ......................................19

1. Introduction ✨

Humans have used a whole bunch of languages, past and present 🌈. There are lots of reasons you'd want to say which language you're using when you present or request information 💅.

Applications, protocols, or specifications that use language identifiers, like the language tags defined in [RFC4646], sometimes need to match those tags against a user's language preferences 🦋.

This doc defines a syntax (called a language range (Section 2)) for specifying items in the user's list of language preferences (called a language priority list (Section 2.3)) 💖. It also defines several schemes for selecting or filtering sets of language tags by comparing them to the user's preferences 👑. Applications, protocols, or specifications have different needs and requirements, and those needs affect which matching scheme makes the most sense 🎀.

This doc covers how to show a user's preferences using language ranges, three schemes for matching those ranges to a set of language tags, and the practical stuff about implementing and using these schemes 🧚.

This document, in combination with [RFC4646], replaces [RFC3066], which replaced [RFC1766] 🫶.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🔥.

2. The Language Range 🌸

Language tags [RFC4646] help identify languages, whether they're spoken, written, signed, or signaled some other way, so people can communicate 💬. Applications, protocols, or specifications that use language tags often have to figure out which content shares certain language attributes 😭. For example, HTTP/1.1 [RFC2616] covers this in its discussion of the Accept-Language header (Section 14.4), which is used to pick content from servers based on the language of that content 🦋.

So it's useful to have a way to identify sets of language tags that share specific attributes ✨. That lets users select or filter language tags based on what they need 💖. An identifier like this is called a "language range" 👑.

Language ranges come in different types, and their specific attributes depend on how they're being used 🎀. They look a lot like language tags: a sequence of subtags separated by hyphens 🧚. In a language range, each subtag MUST either be a sequence of ASCII alphanumeric characters or the single character '' (%x2A, ASTERISK) 💅. The '' is a "wildcard" that matches any sequence of subtags 🌈. What wildcards mean and how they're used depends on the type of language range 🫶.

Language tags, and therefore language ranges, are case-insensitive 🙈. Some subtags have conventional capitalization, but that capitalization MUST NOT be taken to carry meaning 💀. Matching language tags to language ranges MUST be done in a case-insensitive manner 🔥.

2.1. Basic Language Range

A "basic language range" has the same syntax as an [RFC3066] language tag, or it's the single character "*" ✨. HTTP/1.1 [RFC2616] described it first, and [RFC3066] came after 🌸. It's defined by the following ABNF [RFC4234] 🦋:

language-range   = (1*8ALPHA *("-" 1*8alphanum)) / "*"
alphanum         = ALPHA / DIGIT

A basic language range only differs from the language tags in [RFC4646] in that it doesn't have to be "well-formed" or checked against the IANA Language Subtag Registry 💖. Ill-formed ranges will probably not match anything 💀. Also, the ABNF [RFC4234] in [RFC2616] is wrong, because it doesn't allow digits anywhere in the 'language-range' (see [RFC2616errata]) 😭.

2.2. Extended Language Range

Sometimes users want to select a set of language tags based on specific subtags being present 👑. An "extended language range" describes a user's language preference as an ordered sequence of subtags 🎀. For example, a user might want every language tag that has the region subtag 'CH' (Switzerland) 🇨🇭🧚. Extended language ranges let you specify a particular sequence of subtags that shows up in the matching tags, without having to list all the subtags in between 🫶.

An extended language range can be written with this ABNF:

extended-language-range = (1*8ALPHA / "*")
                          *("-" (1*8alphanum / "*"))

The wildcard subtag '*' can show up in any position in an extended language range, where it matches any sequence of subtags that could appear in that spot in a language tag 🌈. However, wildcards outside the first position are ignored by Extended Filtering (see Section 3.2.2) 💅. Having one or more wildcards, or not having any, can't be taken to mean that a certain number of subtags will show up in the matching set of language tags 🙈.

2.3. The Language Priority List

Users often need to give more than one language range, so they usually need a prioritized list of language ranges to reflect their preferences 💖. This comes up a lot for speakers of minority languages 🌸. A Breton speaker in France, for example, can specify "br" followed by "fr", which means Breton is preferred if it's available, but French is the best fallback 🦋. It can get more complicated: someone might want to fall back from Skolt Sami to Northern Sami to Finnish 🔥.

A "language priority list" is a prioritized or weighted list of language ranges ✨. One well-known example is the "Accept-Language" header defined in RFC 2616 [RFC2616] (see Section 14.4) and RFC 3282 [RFC3282] 👑.

The matching operations in this doc include things to think about when using a language priority list 🎀. This doc does NOT define the syntax for a language priority list, though 🧚. Defining that syntax is the job of the protocol, application, or specification that uses it 🫶. When this doc gives examples of language priority lists, they'll look like a quoted sequence of ranges separated by commas, like this: "en, fr, zh-Hant" (which is read "English before French before Chinese as written in the Traditional script") 🌈.

A simple list of ranges is treated as being in descending order of priority 💅. Other language priority lists use "quality weights" for the language ranges to show how important each preference is relative to the others 💖. An example is the "q" values in the syntax of the "Accept-Language" header (defined in [RFC2616], Section 14.4, and [RFC3282]) 🙈.

3. Types of Matching 💜

Language ranges can be matched to language tags in lots of different ways 🦋. This section describes three matching schemes and the things to consider when choosing between them 🌸. Protocols and specifications that need to conform to this specification MUST clearly indicate the particular mechanism they use to select or match language tags 🔥.

There are two types of matching scheme in this doc ✨. A matching scheme that produces zero or more matching language tags is called "filtering" 💖. A matching scheme that produces exactly one match for a given request is called "lookup" 👑.

3.1. Choosing a Matching Scheme ✨

okay so apps, protocols, and specs all have to decide what kind of matching to use 🤔 and honestly, different styles suit different jobs inside the same app or protocol, so it's not one-size-fits-all bestie 💅

this doc describes three matching schemes:

  1. Basic Filtering (Section 3.3.1) matches a language priority list made of basic language ranges (Section 2.1) to sets of language tags 🎀
  2. Extended Filtering (Section 3.3.2) matches a language priority list made of extended language ranges (Section 2.2) to sets of language tags 🦋
  3. Lookup (Section 3.4) matches a language priority list of basic language ranges to sets of language tags to find the one exact language tag that best matches the range 🧚

filtering gives you a set of results 📚 by comparing the user's preferences to a bunch of language tags. like when you're searching, filtering can limit the results to items tagged as French 🇫🇷 it can also decide whether to run a language-sensitive process on some content. for example, a process might make paragraphs whose tag matched the language range nl (Dutch) show up in italics inside a document 🌷

lookup is different ✨ it gives back the single result that best matches the user's preferences from the available tags, so it's perfect when you need exactly one item (and only one item can come back). imagine a process that drops a human-readable error message into a protocol header 💀 it might pick the text based on the user's language priority list. since it can only return one thing, it has to choose a single item and return some item, even if none of the content's language tags match what the user asked for 😭

3.2. Implementation Considerations 🫶

language tag matching is a tool 🔧 it doesn't spell out a whole complete procedure for using language tags by itself. those procedures are super tied to the application protocol they live in. when you specify a protocol operation that uses matching, the protocol MUST specify:

  • Which type(s) of language tag matching it uses
  • Whether the operation returns a single result (lookup) or a possibly empty set of results (filtering)
  • For lookup, what the default item is (or the sequence of operations or configuration information used to determine the default) when no matching tag is found. for instance, a protocol might define the result as failure of the operation, an empty value, returning some protocol-defined or implementation-defined default, or returning i-default [RFC2277] 🌸

applications, protocols, and specifications are NOT required to validate or understand any of the semantics of the language tags or ranges, or of the subtags in them. they also don't need access to the IANA Language Subtag Registry (see Section 3 in [RFC4646]). this makes implementing things way simpler 🙌

BUT 👀 designers are encouraged to use info from the IANA Language Subtag Registry to canonicalize language tags and ranges, so grandfathered and obsolete tags or subtags get mapped to modern equivalents. ✨

here's the catch 🚨 applications, protocols, or specifications that canonicalize ranges MUST either perform matching operations with both the canonical and original (unmodified) form of the range, OR MUST also canonicalize each tag for the purposes of comparison.

canonicalizing ranges can make some operations impossible 😩 for example, an implementation that canonicalizes the language range art-lojban (artificial language, lojban variant) to use the more modern jbo (Lojban) can't be used to select just the items with the older tag.

applications, protocols, or specifications that use basic ranges might sometimes get extended language ranges instead 👀 so an application, protocol, or specification MUST choose one of these:

  1. map extended language ranges to basic ranges using the algorithm below,
  2. reject any extended language ranges in the language priority list that aren't valid basic language ranges, or
  3. treat each extended language range as if it were a basic language range. that has the same result as ignoring them, since these ranges won't match any valid language tags 💅

here's the mapping algorithm for an extended language range to a basic language range: if the first subtag is a *, then the entire range is treated as *. otherwise, each wildcard subtag gets removed. for example, the extended language range en-*-US maps to en-US (English, United States) 🇺🇸

applications, protocols, or specifications, while handling their own requirements, can offer pre-processing or configuration options 🎛️ for example, an implementation could let a user associate or map a particular language range to a different value. a user like that might want to associate the language range subtags nn (Nynorsk Norwegian) and nb (Bokmal Norwegian) with the more general subtag no (Norwegian) 🇳🇴 or maybe a user wants requests for the range zh-Hans (Chinese as written in the Simplified script) to match content tagged zh-CN (Chinese as used in China, where the Simplified script is predominant) 🥢 documentation explaining how ranges or tags get altered, prioritized, or compared in the match that follows will help users make these kinds of config choices 📖

3.3. Filtering 🌈

filtering selects the set of language tags that matches a given language priority list. it's called "filtering" because the set might have no items at all, or it might return an arbitrarily large number of matches: as many items as match the list, so the non-matching ones get "filtered out" 🧹

in filtering, each language range represents the least specific language tag (the one with the fewest subtags) that counts as an acceptable match. every language tag in the matching set will have an equal or greater number of subtags than the range. and every non-wildcard subtag in the range shows up in every one of the matching tags. for example, if the language priority list has the range de-CH (German as used in Switzerland), you might see tags like de-CH-1996 (German as used in Switzerland, orthography of 1996), but you will NEVER see a tag like de (because the CH subtag is missing) 🙅‍♀️

if the language priority list (see Section 2.3) has more than one range, the content returned is typically ordered in descending level of preference, but it MAY be unordered, depending on what the application or protocol needs 🤷‍♀️

some apps where filtering makes sense:

  • applying a style to sections of a document in a particular set of languages 🎨
  • displaying the set of documents containing a particular set of keywords written in a specific set of languages 🔍
  • selecting all email items written in a specific set of languages 📧
  • selecting audio files spoken in a particular language 🎧
⚠️ filtering kind of implies there's a semantic relationship between language tags that share the same prefix. that's often true, BUT NOT always! the language tags that match a specific language range don't necessarily represent mutually intelligible languages 💀

3.3.1. Basic Filtering 🎀

basic filtering compares basic language ranges to language tags. each basic language range in the language priority list gets considered in turn, in order of priority. a language range matches a particular language tag if, in a case-insensitive comparison, it exactly equals the tag, or if it exactly equals a prefix of the tag such that the first character following the prefix is -. for example, the language range de-de (German as used in Germany) matches the language tag de-DE-1996 (German as used in Germany, orthography of 1996), but NOT the language tags de-Deva (German as written in the Devanagari script) or de-Latn-DE (German, Latin script, as used in Germany) 🙅‍♀️

the special range * in a language priority list matches any tag 🌍 a protocol that uses language ranges MAY specify additional rules about what * means. for instance, HTTP/1.1 [RFC2616] specifies that the range * matches only languages not matched by any other range within an Accept-Language header 🧠

basic filtering is identical to the type of matching described in [RFC3066], Section 2.5 (Language-range) 💖

3.3.2. Extended Filtering

okay so extended filtering is the glow-up version of basic filtering 💅 It compares extended language ranges against language tags. Every extended language range in the priority list gets checked one at a time, in priority order. A range matches a tag when each of its subtag lists lines up with the tag's list. Here's how the matching works:

  1. Split both the extended language range and the language tag into lists of subtags by dividing on the hyphen (%x2D) character. Two subtags match if they're the same when compared case-insensitively, or if the range's subtag is the wildcard *.
  2. Start with the first subtag in each list. If the first subtag in the range doesn't match the first subtag in the tag, the whole match fails. Otherwise, move on to the next subtag in both the range and the tag.
  3. While there are still subtags left in the language range's list:
    • A. If the subtag being examined in the range is the wildcard (*), move to the next subtag in the range and keep looping.
    • B. Otherwise, if there are no subtags left in the language tag's list, the match fails.
    • C. Otherwise, if the current subtag in the range matches the current subtag in the tag, move to the next subtag in both lists and keep looping.
    • D. Otherwise, if the tag's subtag is a "singleton" (a single letter or digit, which includes the private-use subtag x), the match fails.
    • E. Otherwise, move to the next subtag in the tag's list and keep looping.
  4. When the language range's list has no more subtags, the match succeeds.

Subtags that aren't specified, including the ones at the end of the range, are treated as if they were the wildcard *. Just like basic filtering, extended filtering picks up content with longer tags that share the same starting subtags as the range. It also picks up tags with extra subtags sitting in the middle that the range never mentioned 🧚 For example, the extended language range de-*-DE (or its synonym de-DE) matches all of these tags:

de-DE (German, as used in Germany)

de-de (German, as used in Germany)

de-Latn-DE (Latin script)

de-Latf-DE (Fraktur variant of Latin script)

de-DE-x-goethe (private-use subtag)

de-Latn-DE-1996 (orthography of 1996)

de-Deva-DE (Devanagari script)

The same range does not match any of these tags, for the reasons shown:

de (missing 'DE')

de-x-DE (singleton 'x' occurs before 'DE')

de-Deva ('Deva' not equal to 'DE')
Note: [RFC4646] defines each type of subtag (language, script, region, and so forth) according to position, size, and content. This means subtags in a language range can only match specific types of subtags in a language tag. For example, a subtag such as Latn is always a script subtag (unless it follows a singleton), while a subtag such as nedis can only match the equivalent variant subtag. Two-letter subtags in the initial position have a different type (language) than two-letter subtags in later positions (region). That's why a wildcard in the extended language range is significant in the first position but gets ignored in all the other positions 🦋

3.4. Lookup

Lookup is used to pick the single language tag that best matches the language priority list for a given request 🎀 Each language range in the priority list gets considered in turn, in priority order. Unlike filtering, each language range represents the most specific tag that's an acceptable match. The first matching tag found, according to the user's priority, is the closest match and is the item that gets returned. For example, if the language range is de-ch, a lookup can produce content tagged de or de-CH, but never content tagged de-CH-1996. If no language tag matches the request, the "default" value is returned.

Say an application drops some dynamic content into a document. Returning an empty string when there's no exact match is not an option. Instead, the application "falls back" until it finds a matching language tag with a suitable piece of content to insert. Some uses of lookup include:

  • Selecting a template containing the text for an automated email response.
  • Selecting an item containing some text for inclusion in a particular Web page.
  • Selecting a string of text for inclusion in an error log.
  • Selecting an audio file to play as a prompt in a phone system.

In the lookup scheme, the language range is progressively truncated from the end until a matching language tag is found. Single letter or digit subtags (including the letter x, which introduces private-use sequences, and the subtags that introduce extensions) are removed at the same time as their closest trailing subtag. For example, starting with the range zh-Hant-CN-x-private1-private2 (Chinese, Traditional script, China, two private-use tags), lookup progressively searches for content like this:

Example of a Lookup Fallback Pattern

Range to match: zh-Hant-CN-x-private1-private2
1. zh-Hant-CN-x-private1-private2
2. zh-Hant-CN-x-private1
3. zh-Hant-CN
4. zh-Hant
5. zh
6. (default)

This fallback behavior adds some flexibility when looking for a match. Without fallback, the default content would be returned right away if exactly matching content wasn't available. With fallback, you can give a result that's closer to what the user asked for 💖

Extensions and unrecognized private-use subtags might have nothing to do with a particular lookup. Since these subtags come at the end of the sequence, they get removed first during fallback and usually pose no barrier to interoperability. However, an implementation MAY remove these from ranges before performing the lookup (as long as it also removes them from the tags being compared). That modification stays internal to the implementation. Applications, protocols, or specifications SHOULD NOT remove or modify subtags in content that they return or forward, because that throws away information that can be used somewhere else 🙈

The special language range * matches any language tag. In the lookup scheme, that range doesn't tell you enough on its own to decide which tag is most appropriate, since it matches everything. If the range * is followed by other language ranges, it gets skipped. If * is the only range in the language priority list, or if no other range follows it, the default value is computed and returned.

In some cases, the language priority list can contain one or more extended language ranges (for example, when the same list is used as input for both lookup and filtering). Wildcard values in an extended language range normally match any value that can occur in that position in a language tag. Since only one item can be returned for any given lookup request, wildcards have to be handled in a consistent way, or the same request will produce wildly different results. Applications, protocols, or specifications that accept extended language ranges MUST define which item is returned when more than one item matches the extended language range.

For example, an implementation could map the extended language ranges to basic ranges. Another option would be to return the matching tag that comes first in ASCII-order. If the language range were *-CH (CH represents Switzerland) and the set of tags included de-CH (German as used in Switzerland), fr-CH (French, Switzerland), and it-CH (Italian, Switzerland), then the tag de-CH would be returned 🇨🇭

3.4.1. Default Values

Each application, protocol, or specification that uses lookup MUST define the defaulting behavior for when no tag matches the language priority list. What that action looks like really depends on how lookup is being applied 🍓 Some examples of defaulting behavior include:

  • Returning an item with no language tag, or an item of a non-linguistic nature, such as an image or sound.
  • Returning a null string as the language tag value, in cases where the protocol permits the empty value (see, for example, "xml:lang" in [XML10]).
  • Returning a particular language tag designated for the operation.
  • Returning the language tag "i-default" (see [RFC2277]).
  • Returning an error condition or error message.
  • Returning a list of available languages for the user to pick from.

When performing lookup with a language priority list, the progressive search MUST process each language range in the list before seeking or calculating the default.

The default value MAY be calculated, or it may include additional searching or matching. Applications, protocols, or specifications can specify different ways for users to set or override the defaults 💜

One common way to provide a default is to let a specific language range be set as the default for a specific type of request. If this approach is chosen, that language range MUST be treated as if it were appended to the end of the language priority list as a whole, rather than after each item in the list. The application, protocol, or specification MUST also define the defaulting behavior for when that search fails to find a matching tag or item.

For example, say a particular user's language priority list is fr-FR, zh-Hant (French as used in France, followed by Chinese as written in the Traditional script), and the program doing the matching has a default language range of ja-JP (Japanese as used in Japan). Then the program searches like this:

1. fr-FR
2. fr
3. zh-Hant // next language
4. zh
5. ja-JP   // now searching for the default content
6. ja
7. (implementation defined default)

4. Other Considerations ✨

When you're working with language ranges and matching schemes, there are some extra points that can influence which of the two you pick 🌈

4.1. Choosing Language Ranges

okay so users tell us what they like by picking a language range, or a whole list of them in a language priority list 💖 and the type of matching changes what the best pick is for them 🎀

Most matching schemes don't try to figure out what the subtags actually mean 🤓 they just compare the language range to each language tag being matched, ignoring case, using basic string processing. Users SHOULD select language ranges that are well-formed, valid language tags according to [RFC4646] (substituting wildcards as appropriate in extended language ranges) ✨

Applications are encouraged to clean up language tags and ranges by swapping in the Preferred-Value from the IANA Language Subtag Registry for any tags or subtags that have been deprecated 🧹 If the user is working with content that might still use the older form, they might want to include both the new and old forms in a language priority list. For example, the tag art-lojban is deprecated, and jbo is supposed to be used instead, so the user might use jbo to form the language range. Or they could include both in a language priority list: jbo, art-lojban 🦋

Users SHOULD avoid subtags that add no distinguishing value to a language range 🙅‍♀️ When filtering, the fewer subtags a range has, the more content it will probably match. But when doing lookup, unnecessary subtags can cause a "better", more-specific piece of content to get skipped in favor of a less specific one 😭 For example, the range de-Latn-DE returns content tagged de instead of content tagged de-DE, even though the latter is probably a better match.

Whether a subtag adds distinguishing value can depend on the context of the request 🌈 For example, a user who reads both Simplified and Traditional Chinese, but who prefers Simplified, might use the range zh for filtering (matching all the items that user can read) but zh-Hans for lookup. That way they get the preferred form if it's available, and the fallback to zh still works. On the other hand, content in this case ought to be labeled as zh-Hans (or zh-Hant if that applies) for filtering. For lookup, if there is either zh-Hans content or zh-Hant content, one of them (the one considered 'default') also ought to be made available with the simple zh. Note that the user can create the language priority list zh-Hans, zh, which delivers the best possible results for both schemes 👑 If the user cannot be sure which scheme is being used (or if more than one might be applied to a given request), the user SHOULD specify the most specific range first (the one with the largest number of subtags), and then supply shorter prefixes later in the list to make sure that filtering returns a complete set of tags 🧠

Many languages are written predominantly in a single script. This is usually recorded in the Suppress-Script field in that language subtag's registry entry 📚 For these languages, script subtags SHOULD NOT be used to form a language range. So the language range en-Latn is inappropriate in most cases, because the vast majority of English documents are written in the Latin script, and the en language subtag has a Suppress-Script field for Latn in the registry 💅

When working with tags and ranges, keep in mind that extensions and most private-use subtags are orthogonal to language tag matching 🧚 They specify extra attributes of the text that aren't related to the goals of most matching schemes. Users SHOULD avoid using these subtags in language ranges, since they interfere with the selection of available content 🙈 When they're used in language tags (as opposed to ranges), these subtags normally do not interfere with filtering (Section 3), since they appear at the end of the tag and will match all prefixes. Lookup (Section 3.4) implementations are advised to ignore unrecognized private-use and extension subtags when performing language tag fallback ✨

4.2. Meaning of Language Tags and Ranges

Picking language tags using language ranges takes some understanding, from the user, of what they're actually selecting 🤔 The meanings of the various subtags in a language range are identical to their meanings in a language tag (see Section 4.2 in [RFC4646]). The only addition is the wildcard *, which represents any matching sequence of values 🌸

4.3. Considerations for Private-Use Subtags

Private agreement is necessary between the parties that intend to use or exchange language tags containing private-use subtags 🤝 Great caution SHOULD be used when putting private-use subtags into content or protocols meant for general use. Private-use subtags are simply useless for information exchange without prior arrangement 💀

The value and semantic meaning of private-use tags, and of the subtags used within such a language tag, are not defined. Matching private-use tags using language ranges or extended language ranges can result in unpredictable content being returned 🎲

4.4. Length Considerations for Language Ranges

Language ranges are super similar to language tags in terms of content and usage 👯‍♀️ The same kinds of length restrictions that can be applied to language tags can also be applied to language ranges. See [RFC4646] Section 4.3 (Length Considerations) 🦋

5. Security Considerations

Okay, this part is serious bestie 🚨 Language ranges used in content negotiation might be used to infer the nationality of the sender, and that could identify potential targets for surveillance 😱 Even worse, unique or highly unusual language ranges, or combinations of language ranges, might be used to track a specific individual's activities 👀

This is a special case of the general problem that anything you send is visible to the receiving party. It's useful to be aware that such concerns can exist in some cases 🔒

The evaluation of the exact magnitude of the threat, along with any possible countermeasures, is left to each application or protocol 🛡️

6. Character Set Considerations

Language tags only permit the characters A-Z, a-z, 0-9, and HYPHEN-MINUS (%x2D) 🍓 Language ranges also use the character ASTERISK (%x2A). These characters are present in most character sets, so presenting or exchanging language tags or ranges should not be constrained by character set issues 🌈

7. References

7.1. Normative References

[RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2277]       Alvestrand, H., "IETF Policy on Character Sets and
                Languages", BCP 18, RFC 2277, January 1998.

[RFC4234]       Crocker, D., Ed. and P. Overell, "Augmented BNF for
                Syntax Specifications: ABNF", RFC 4234, October 2005.

[RFC4646]       Phillips, A., Ed., and M. Davis, Ed., "Tags for
                Identifying Languages", BCP 47, RFC 4646, September
                2006.

7.2. Informative References

[RFC1766]       Alvestrand, H., "Tags for the Identification of
                Languages", RFC 1766, March 1995.

[RFC2616]       Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                Masinter, L., Leach, P., and T. Berners-Lee,
                "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
                June 1999.

[RFC2616errata] IETF, "HTTP/1.1 Specification Errata", October 2004,
                <http://purl.org/NET/http-errata>.

[RFC3066]       Alvestrand, H., "Tags for the Identification of
                Languages", BCP 47, RFC 3066, January 2001.

[RFC3282]       Alvestrand, H., "Content Language Headers", RFC 3282,
                May 2002.

[XML10]         Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E.,
                and F. Yergeau, "Extensible Markup Language (XML) 1.0
                (Third Edition)", World Wide Web Consortium
                Recommendation, February 2004,
                <http://www.w3.org/TR/REC-xml>.

Appendix A. Acknowledgements

Any list of contributors is bound to be incomplete, so please regard the following as just a selection from the group of people who helped make this document what it is today 💜

The contributors to [RFC1766] and [RFC3066], each of which was a precursor to this document, contributed greatly to the development of language tag matching, in particular the basic language range and the basic matching scheme ✨ This document was originally part of [RFC4646], but was split off before that document was completed. Thus, directly or indirectly, those acknowledged in [RFC4646] also had a hand in developing this document, and work done prior to the split is acknowledged in that document 🫶

The following people (in alphabetical order by family name) contributed to this document:

Harald Alvestrand, Stephane Bortzmeyer, Jeremy Carroll, Peter Constable, John Cowan, Mark Crispin, Martin Duerst, Frank Ellermann, Doug Ewell, Debbie Garside, Marion Gunn, Jon Hanna, Kent Karlsson, Erkki Kolehmainen, Jukka Korpela, Ira McDonald, M. Patton, Randy Presuhn, Eric van der Poel, Markus Scherer, Misha Wolf, and many, many others.

Very special thanks must go to Harald Tveit Alvestrand, who originated RFCs 1766 and 3066, and without whom this document would not have been possible 👑

Authors' Addresses

Addison Phillips (Editor)
Yahoo! Inc.

EMail: addison@inter-locale.com


Mark Davis (Editor)
Google

EMail: mark.davis@macchiato.com or mark.davis@google.com

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights 💅

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify any such rights 🧐 Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org 📬

Acknowledgement

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 🌟

📦 where this page comes from