Charset/Language Tags: Registration of Charset and Languages Media Features Tags
Registers two media feature tags so devices can say which character sets and human languages they handle.
Hoffman, P., "Registration of Charset and Languages Media Features Tags", RFC 2987, DOI 10.17487/RFC2987, November 2000, <https://www.rfc-editor.org/info/rfc2987>.
@misc{rfc2987,
series = {Request for Comments},
number = 2987,
howpublished = {RFC 2987},
publisher = {RFC Editor},
doi = {10.17487/RFC2987},
url = {https://www.rfc-editor.org/info/rfc2987},
author = {P. Hoffman},
title = {{Registration of Charset and Languages Media Features Tags}},
pagetotal = 6,
year = 2000,
month = nov,
} RFC text
Contents
Network Working Group P. Hoffman
Request for Comments: 2987 Internet Mail Consortium
Category: Standards Track November 2000
Registration of Charset and Languages Media Features Tags
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This document contains the registration for two media feature tags:
"charset" and "language". These media features allow specification
of character sets and human languages that can be understood by
devices and the devices' users. The templates in this document are
derived from RFC 2506.
1. Registration for charset
To: media-feature-tags@apps.ietf.org (Media feature tags mailing list)
Subject: Registration of media feature tag charset
Media feature tag name:
charset
ASN.1 identifier associated with feature tag:
1.3.6.1.8.1.31
Summary of the media feature indicated by this feature tag:
Ability to display particular charsets as defined in [CHARSET].
For most devices, this media feature is usually a capability;
that is, most devices cannot intelligently process text in a
charset that is unknown to the device.
Values appropriate for use with this feature tag:
The values are tokens as defined in [CHARSET]. The values can
only be compared for equality. Comparison is not case
sensitive.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms:
Any protocol that uses media tags
Examples of typical use:
(| (charset=utf-8);q=1.0 (charset=iso-8859-1);q=0.9
(charset=utf-16);q=0.5 )
Related standards or documents:
"IANA Charset Registration Procedures", RFC 2978
Considerations particular to use in individual applications,
protocols, services, or negotiation mechanisms:
None
Interoperability considerations: Aliases for charsets should not be
used in media feature expressions because feature expression
manipulation tools may convert aliases to the the principal
name for the charset. Even though charset names are not
case-sensitive, values should be expressed as all lowercase
letters to increase the likelihood of interoperability. The
"charset" capability should always be indicated in
conjunction with any capability to handle textual data.
Security considerations:
If it is known that there is a security bug in the display of a
particular charset in a particular environment, knowing that a
device can accept that charset may slightly help an attacker.
Additional information:
None
Name(s) & email address(es) of person(s) to contact for further
information:
Paul Hoffman <phoffman@imc.org>
Intended usage:
COMMON
Author/Change controller:
IETF
Requested IANA publication delay:
None
Other information:
None
2. Registration for language
To: media-feature-tags@apps.ietf.org (Media feature tags mailing list)
Subject: Registration of media feature tag language
Media feature tag name:
language
ASN.1 identifier associated with feature tag:
1.3.6.1.8.1.32
Summary of the media feature indicated by this feature tag: Ability
to display particular human languages as defined in [LANG]. Note
that "display" in this case will most often mean speech by a
computer. For most devices, this media feature is a preference,
not a requirement.
Values appropriate for use with this feature tag:
The values are tokens, with allowable values defined by
registration as defined in [LANG]. The values can only be
compared for equality. As described in [LANG], language tags
are always handled as a single token, and "subtags" are not
used for comparison. Comparison is not case sensitive.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms:
Any protocol that uses media tags
Examples of typical use:
(| (language=no-nynorsk);q=1.0 (language=no-bokmaal);q=0.9
(language=i-sami-no);q=0.5 )
Related standards or documents:
"Tags for the Identification of Languages", RFC 1766
Considerations particular to use in individual applications,
protocols, services, or negotiation mechanisms:
None
Interoperability considerations:
Even though language tags are not case-sensitive, values should be
expressed as all lowercase letters to increase the likelihood
of interoperability.
Security considerations:
If it is known that there is a security bug in the display of a
particular language in a particular environment, knowing that a
device can accept that language may slightly help an attacker.
Additional information:
None
Name(s) & email address(es) of person(s) to contact for further
information:
Paul Hoffman <phoffman@imc.org>
Intended usage:
COMMON
Author/Change controller:
IETF
Requested IANA publication delay:
None
Other information:
None
3. Security Considerations
The security considerations are listed in the two registrations above.
4. IANA Considerations
The bulk of this document is IANA registrations.
5. References
[CHARSET] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
[LANG] Alvestrand, H., "Tags for the Identification of Languages",
RFC 1766, March 1995.
[TAG-REG] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999.
6. Author's Address
Paul Hoffman
Internet Mail Consortium
127 Segre Place
Santa Cruz, CA 95060 USA
EMail: phoffman@imc.org
7. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
§0What Is Being Registered
This document is almost entirely a pair of registrations. It registers two media feature tags, charset and language, which let a device describe the character sets and human languages that it and its user can understand. The templates are derived from RFC 2506, the media feature tag registration procedure.
Both registrations say they are intended for any protocol that uses media tags, both have intended usage COMMON, and both name the IETF as author and change controller. The contact for both is Paul Hoffman.
Think of a form for new labels. This memo fills the form out twice, once for the letters a device can show and once for its language.
§1The charset Tag
The charset tag has ASN.1 identifier 1.3.6.1.8.1.31. It indicates the ability to display particular charsets as defined in RFC 2978. For most devices it is usually a capability, because most devices cannot intelligently process text in a charset they do not know.
Values are tokens defined in that RFC. They can only be compared for equality, and the comparison is not case sensitive. The RFC's example is a weighted list: (| (charset=utf-8);q=1.0 (charset=iso-8859-1);q=0.9 (charset=utf-16);q=0.5 ).
The charset label tells others which alphabets and symbol sets the device can draw on its screen. Unknown ones turn into gibberish, so it matters.
§2The language Tag
The language tag has ASN.1 identifier 1.3.6.1.8.1.32. It indicates the ability to display particular human languages as defined in RFC 1766. Here "display" will most often mean speech by a computer, and for most devices the feature is a preference, not a requirement.
Values are tokens whose allowed values come from language tag registration. Language tags are handled as a single token and subtags are not used for comparison. Comparison is for equality only and is not case sensitive. The example is (| (language=no-nynorsk);q=1.0 (language=no-bokmaal);q=0.9 (language=i-sami-no);q=0.5 ).
The language label says which spoken or written languages a person likes, in order of favorite, such as Norwegian first.
| Tag | ASN.1 identifier | Defined by | Usually |
|---|---|---|---|
| charset | 1.3.6.1.8.1.31 | RFC 2978 | A capability |
| language | 1.3.6.1.8.1.32 | RFC 1766 | A preference |
§3Interoperability Advice
For both tags, the RFC advises writing values in all lowercase letters, even though names are not case sensitive, to make interoperability more likely.
For charset, aliases should not be used in media feature expressions, because tools that manipulate expressions may convert aliases to the principal charset name. The charset capability should always be indicated together with any capability to handle textual data.
Write the labels in small letters and use the main name, not a nickname, so everyone reads them the same way.
§4Security and IANA Considerations
Each registration carries the same kind of note. If a security bug is known in how a particular charset or language is displayed in a particular environment, knowing that a device accepts it may slightly help an attacker. The document's own Security Considerations section just points back to the two registrations.
The IANA Considerations section is one line: the bulk of the document is IANA registrations. Both registrations request no IANA publication delay.
If someone knows your device shows a certain alphabet and that alphabet has a bug, they might use that. The risk is small.