As per Relevance of the word registration, we have this rfc below:
Network Working Group H.
Request for Comments: 1766
Category: Standards Track March 1995
Tags for the Identification of
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This document describes a language tag for use in cases where it
desired to indicate the language used in an information object
It also defines a Content-language: header, for use in the case
one desires to indicate the language of something that has RFC-822-
like headers, like MIME body parts or Web documents, and a
parameter to the Multipart/Alternative type, to aid in the usage
the Content-Language: header
1.
There are a number of languages spoken by human beings in this world
A great number of these people would prefer to have
presented in a language that they understand
In some contexts, it is possible to have information in more than
language, or it might be possible to provide tools for assisting
the understanding of a language (like dictionaries).
A prerequisite for any such function is a means of labelling
information content with an identifier for the language in which
is written
In the tradition of solving only problems that we think
understand, this document specifies an identifier mechanism, and
possible use for it
Alvestrand [Page 1]
RFC 1766 Language Tag March 1995
2. The Language
The language tag is composed of 1 or more parts: A primary
tag and a (possibly empty) series of subtags
The syntax of this tag in RFC-822 EBNF is
Language-Tag = Primary-tag *( "-" Subtag )
Primary-tag = 1*8
Subtag = 1*8
Whitespace is not allowed within the tag
All tags are to be treated as case insensitive; there
conventions for capitalization of some of them, but these should
be taken to carry meaning
The namespace of language tags is administered by the IANA
to the rules in section 5 of this document
The following registrations are predefined
In the primary language tag
- All 2-letter tags are interpreted according to ISO
639, "Code for the representation of names of languages" [
639].
- The value "i" is reserved for IANA-defined
- The value "x" is reserved for private use. Subtags of "x
will not be registered by the IANA
- Other values cannot be assigned except by updating
standard
The reason for reserving all other tags is to be open towards
revisions of ISO 639; the use of "i" and "x" is the minimum we can
here to be able to extend the mechanism to meet our requirements
In the first subtag
- All 2-letter codes are interpreted as ISO 3166 alpha-2
country codes denoting the area in which the language
used
- Codes of 3 to 8 letters may be registered with the IANA
anyone who feels a need for it, according to the rules
Alvestrand [Page 2]
RFC 1766 Language Tag March 1995
chapter 5 of this document
The information in the subtag may for instance be
- Country identification, such as en-US (this usage
described in ISO 639)
- Dialect or variant information, such as no-nynorsk or en
- Languages not listed in ISO 639 that are not variants
any listed language, which can be registered with the i
prefix, such as i-
- Script variations, such as az-arabic and az-
In the second and subsequent subtag, any value can be registered
NOTE: The ISO 639/ISO 3166 convention is that language names
written in lower case, while country codes are written in upper case
This convention is recommended, but not enforced; the tags are
insensitive
NOTE: ISO 639 defines a registration authority for additions to
changes in the list of languages in ISO 639. This authority is
International Information Centre for Terminology (Infoterm
P.O. Box 130
A-1021
Phone: +43 1 26 75 35 Ext. 312
Fax: +43 1 216 32 72
The following codes have been added in 1989 (nothing later):
(Uigur), iu (Inuktitut, also called Eskimo), za (Zhuang), he (Hebrew
replacing iw), yi (Yiddish, replacing ji), and id (Indonesian
replacing in).
NOTE: The registration agency for ISO 3166 (country codes) is
ISO 3166 Maintenance Agency
c/o DIN Deutches Institut fuer
Burggrafenstrasse 6
Postfach 1107
D-10787
Phone: +49 30 26 01 320
Fax: +49 30 26 01 231
Alvestrand [Page 3]
RFC 1766 Language Tag March 1995
The country codes AA, QM-QZ, XA-XZ and ZZ are reserved by ISO 3166
user-assigned codes
2.1. Meaning of the language
The language tag always defines a language as spoken (or written)
human beings for communication of information to other human beings
Computer languages are explicitly excluded
There is no guaranteed relationship between languages whose
start out with the same series of subtags; especially, they are
guraranteed to be mutually comprehensible, although this
sometimes be the case
Applications should always treat language tags as a single token;
division into main tag and subtags is an administrative mechanism
not a navigation aid
The relationship between the tag and the information it relates to
defined by the standard describing the context in which it appears
So, this section can only give possible examples of its usage
- For a single information object, it should be taken as
set of languages that is required for a
comprehension of the complete object. Example: Simple text
- For an aggregation of information objects, it should be
as the set of languages used inside components of
aggregation. Examples: Document stores and libraries
- For information objects whose purpose in life is
alternatives, it should be regarded as a hint that
material inside is provided in several languages, and
one has to inspect each of the alternatives in order to
its language or languages. In this case, multiple
need not mean that one needs to be multilingual to
complete understanding of the document. Example:
multipart/alternative
- It would be possible to define (for instance) an SGML
that defines a tag for indicating that following
contained text is written in this language, such that
could write "C'est la vie"; the Norwegian
speaking user could then access a French-Norwegian
to find out what the quote meant
Alvestrand [Page 4]
RFC 1766 Language Tag March 1995
3. The Content-language
The Language header is intended for use in the case where one
to indicate the language(s) of something that has RFC-822-
headers, like MIME body parts or Web documents
The RFC-822 EBNF of the Language header is
Language-Header = "Content-Language" ":" 1#Language-
Note that the Language-Header is allowed to list several languages
a comma-separated list
Whitespace is allowed, which means also that one can
parenthesized comments anywhere in the language sequence
3.1. Examples of Content-language
NOTE: NONE of the subtags shown in this document have actually
assigned; they are used for illustration purposes only
Norwegian official document, with parallel text in both
versions of Norwegian. (Both versions are readable by
Norwegians).
Content-Type: multipart/alternative
differences=content-
Content-Language: no-nynorsk, no-
Voice recording from the London
Content-type: audio/
Content-Language: en-
Document in Sami, which does not have an ISO 639 code, and is
in several countries, but with about half the speakers in Norway
with six different, mutually incomprehensible dialects
Content-type: text/plain; charset=iso-8859-10
Content-Language: i-sami-no (North Sami
An English-French
Content-type: application/
Content-Language: en, fr (This is a dictionary
An official EC document (in a few of its official languages
Alvestrand [Page 5]
RFC 1766 Language Tag March 1995
Content-type: multipart/
Content-Language: en, fr, de, da, el,
An excerpt from Star
Content-type: video/
Content-Language: x-
4. Use of Content-Language with Multipart/
When using the Multipart/Alternative body part of MIME, it
possible to have the body parts giving the same information
in different languages. In this case, one should put a Content
Language header on each of the body parts, and a summary Content
Language header onto the Multipart/Alternative itself
4.1. The differences parameter to multipart/
As defined in RFC 1541, Multipart/Alternative only has one parameter
boundary
The common usage of Multipart/Alternative is to have more than
format of the same message (f.ex. PostScript and ASCII).
The use of language tags to differentiate between
alternatives will certainly not lead all MIME UAs to present the
sensible body part as default
Therefore, a new parameter is defined, to allow the configuration
MIME readers to handle language differences in a sensible manner
Name:
Value: One or more
Content-
Content-
Further values can be registered with IANA; it must be the name of
header for which a definition exists in a published RFC. If
present, Differences=Content-Type is assumed
The intent is that the MIME reader can look at these headers of
message component to do an intelligent choice of what to present
the user, based on knowledge about the user preferences
capabilities
(The intent of having registration with IANA of the fields used
this context is to maintain a list of usages that a mail UA
expect to see, not to reject usages.)
Alvestrand [Page 6]
RFC 1766 Language Tag March 1995
(NOTE: The MIME specification [RFC 1521], section 7.2, states
headers not beginning with "Content-" are generally to be ignored
body parts. People defining a header for use with "differences="
should take note of this.)
The mechanism for deciding which body part to present is outside
scope of this document
MIME EXAMPLE
Content-Type: multipart/alternative; differences=Content-Language
boundary="limit
Content-Language: en, fr,
--
Content-Language:
Le renard brun et agile saute par dessus le chien
--
Content-Language:
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-encoding: quoted-
Der schnelle braune Fuchs h=FCpft =FCber den faulen
--
Content-Language:
The quick brown fox jumps over the lazy
--limit--
When composing a message, the choice of sequence may be
arbitrary. However, non-MIME mail readers will show the first
part first, meaning that this should most likely be the
understood by most of the recipients
5. IANA registration procedure for language
Any language tag must start with an existing tag, and extend it
This registration form should be used by anyone who wants to use
language tag not defined by ISO or IANA
Alvestrand [Page 7]
RFC 1766 Language Tag March 1995
----------------------------------------------------------------------
LANGUAGE TAG REGISTRATION
Name of requester :
E-mail address of requester
Tag to be registered :
English name of language :
Native name of language (transcribed into ASCII):
Reference to published description of the language (book or article):
----------------------------------------------------------------------
The language form must be sent to for a 2-
week review period before submitting it to IANA. (This is an
list. Requests to be added should be sent to
request@uninett.no>.)
When the two week period has passed, the language tag reviewer,
is appointed by the IETF Applications Area Director, either
the request to IANA@ISI.EDU, or rejects it because of
objections raised on the list
Decisions made by the reviewer may be appealed to the IESG
All registered forms are available online in the
ftp://ftp.isi.edu/in-notes/iana/assignments/languages
6. Security
Security issues are not discussed in this memo
7. Character set
Codes may always be expressed using the US-ASCII character
(a-z), which is present in most character sets
The issue of deciding upon the rendering of a character set based
the language tag is not addressed in this memo; however, it
thought impossible to make such a decision correctly for all
unless means of switching language in the middle of a text
defined (for example, a rendering engine that decides font based
Japanese or Chinese language will fail to work when a
Japanese-Chinese text is encountered
Alvestrand [Page 8]
RFC 1766 Language Tag March 1995
8.
This document has benefited from innumberable rounds of review
comments in various fora of the IETF and the Internet working groups
As so, any list of contributors is bound to be incomplete;
regard the following as only a selection from the group of people
have contributed to make this document what it is today
In alphabetical order
Tim Berners-Lee, Nathaniel Borenstein, Jim Conklin, Dave Crocker
Ned Freed, Tim Goodwin, Olle Jarnefors, John Klensin, Keith Moore
Masataka Ohta, Keld Jorn Simonsen, Rhys Weatherley, and many,
others
9. Author's
Harald Tveit
Pb. 6883
N-7002
EMail: Harald.T.Alvestrand@uninett.
Phone: +47 73 59 70 94
10.
[ISO 639]
ISO 639:1988 (E/F) - Code for the representation of names
languages - The International Organization
Standardization, 1st edition, 1988 17 pages Prepared
ISO/TC 37 - Terminology (principles and coordination).
[ISO 3166]
ISO 3166:1988 (E/F) - Codes for the representation of
of countries - The International Organization
Standardization, 3rd edition, 1988-08-15.
[RFC 1521]
Borenstein, N., and N. Freed, "MIME Part One: Mechanisms
Specifying and Describing the Format of Internet
Bodies", RFC 1521, Bellcore, Innosoft, September 1993.
[RFC 1327]
Kille, S., "Mapping between X.400(1988) / ISO 10021 and
822", RFC 1327, University College London, May 1992.
Alvestrand [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
