RFC2987 - Registration of Charset and Languages Media Features Tags

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 RFC2506.

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", RFC2978

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", RFC1766

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, RFC2978, October 2000.

[LANG] Alvestrand, H., "Tags for the Identification of Languages",

RFC1766, March 1995.

[TAG-REG] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag

Registration Procedure", BCP 31, RFC2506, 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 RFCEditor function is currently provided by the

Internet Society.