Network Working Group
Request for Comments: 3536
Category: Informational
P. Hoffman
May 2003

Terminology Used in Internationalization in the IETF

Status of this Memo


Copyright Notice




Table of Contents

     1.2 Format of the definitions in this document..................  3
     3.2 Encodings and transformation formats of ISO/IEC 10646....... 10
   6. Text in current IETF protocols................................. 19
   7. Other Common Terms In Internationalization..................... 22

1. Introduction

As [RFC2277] summarizes: "Internationalization is for humans. This means that protocols are not subject to internationalization; text strings are." Many protocols throughout the IETF use text strings that are entered by, or are visible to, humans. It should be possible for anyone to enter or read these text strings, which means that Internet users must be able to be enter text in typical input methods and displayed in any human language. Further, text containing any character should be able to be passed between Internet applications easily. This is the challenge of internationalization.

1.1 Purpose of this document


Internationalization is discussed in many working groups of the IETF. However, few working groups have internationalization experts. When designing or updating protocols, the question often comes up "should we internationalize this" (or, more likely, "do we have to internationalize this").

This document gives an overview of internationalization as it applies to IETF standards work by lightly covering the many aspects of internationalization and the vocabulary associated with those topics. It is not meant to be a complete description of internationalization. The definitions in this document are not normative for IETF standards; however, they are useful and standards may make informative reference to this document after it becomes an RFC. Some of the definitions in this document come from many earlier IETF documents and books.


This document uses definitions from many documents that have been developed outside the IETF. The primary documents used are:

      - ISO/IEC 10646 [ISOIEC10646]
      - The Unicode Standard [UNICODE]
      - W3C Character Model [CHARMOD]
      - IETF RFCs, including [RFC2277]

1.2 Format of the definitions in this document

In the body of this document, the source for the definition is shown in angle brackets, such as "<ISOIEC10646>". Many definitions are shown as "<NONE>", which means that the definitions were crafted originally for this document. The angle bracket notation for the source of definitions is different than the square bracket notation used for references to documents, such as in the paragraph above; these references are given in Section 9.



2. Fundamental Terms

This section covers basic topics that are needed for almost anyone who is involved with making IETF protocols more friendly to non-ASCII text and with other aspects of internationalization.


A language is a way that humans interact. The use of language occurs in many forms, the most common of which are speech, writing, and signing. <NONE>

Some languages have a close relationship between the written and spoken forms, while others have a looser relationship. [RFC3066] discusses languages in more detail and provides identifiers for languages for use in Internet protocols. Note that computer languages are explicitly excluded from this definition.


A set of graphic characters used for the written form of one or more languages. <ISOIEC10646>

Examples of scripts are Latin, Cyrillic, Greek, Arabic, and Han (the ideographs used in writing Chinese, Japanese, and Korean). [RFC2277] discusses scripts in detail.


A single name can mean either a language or a script; for example, "Arabic" is both the name of a language and the name of a script. In fact, many scripts borrow their names from the names of languages. Further, many scripts are used for many languages; for example, the Russian and Bulgarian languages are written in the Cyrillic script. Some languages can be expressed using different scripts; the Mongolian language can be written in either the Mongolian and Cyrillic scripts, and the Serbo-Croatian language is written using both the Latin and Cyrillic scripts. Further, some languages are normally expressed with more than one script at the same time; for example, the Japanese language is normally expressed in the Kanji (Han), Katakana, and Hiragana scripts in a single string of text.


A member of a set of elements used for the organization, control, or representation of data. <ISOIEC10646>


  • a general description of a text entity
  • a unit of a writing system, often synonymous with "letter" or similar terms
  • the encoded entity itself

When people talk about characters, they are mostly using one of the first two definitions.


   coded character

A character together with its coded representation. <ISOIEC10646>

   coded character set


   character encoding form

A character encoding form is a mapping from a character set definition to the actual code units used to represent the data. <UNICODE>


The collection of characters included in a character set. Also called a character repertoire. <UNICODE>


A glyph is an abstract form that represents one or more glyph images. The term "glyph" is often a synonym for glyph image, which is the actual, concrete image of a glyph representation having been rasterized or otherwise imaged onto some display surface. In displaying character data, one or more glyphs may be selected to depict a particular character. These glyphs are selected by a rendering engine during composition and layout processing. <UNICODE>

   glyph code



Transcoding is the process of converting text data from one character encoding form to another. Transcoders work only at the level of character encoding and do not parse the text. Note: Transcoding may involve one-to-one, many-to-one, one-to-many or many-to-many mappings. Because some legacy mappings are glyphic, they may not only be many-to-many, but also discontinuous: thus XYZ may map to yxz. <CHARMOD>


   character encoding scheme


Some CESs are associated with a single CCS; for example, UTF-8 [RFC2279] applies only to ISO/IEC 10646. Other CESs, such as ISO 2022, are associated with many CCSs.



Many protocol definitions use the term "character set" in their descriptions. The terms "charset" or "character encoding scheme" are strongly preferred over the term "character set" because "character set" has other definitions in other contexts and this can be confusing.


In the IETF, "internationalization" means to add or improve the handling of non-ASCII text in a protocol. <NONE>

Many protocols that handle text only handle one script (often, the one that contains the letters used in English text), or leave the question of what character set is used up to local guesswork

(which leads, of course, to interoperability problems). Adding non-ASCII text to such a protocol allows the protocol to handle more scripts, hopefully all of the ones useful in the world.






Do not confuse "localization" with "locale", which is described in Section 7 of this document.

   i18n, l10n

These are abbreviations for "internationalization" and "localization". <NONE>




displaying and rendering text

      To display text, a system puts characters on a visual display
      analyzes the character input to determine how to display the text.
      The terms "display" and "render" are sometimes used
      interchangeably.  Note, however,  that text might be rendered as
      designed for people with visual disabilities.  <NONE>


3. Standards Bodies and Standards


3.1 Standards bodies


The International Organization for Standardization has been involved with standards for characters since before the IETF was started. ISO is a non-governmental group made up of national bodies. ISO has many diverse standards in the international characters area; the one that is most used in the IETF is commonly referred to as "ISO/IEC 10646", although its official name has more qualifications. (The IEC is International Electrotechnical Commission). ISO/IEC 10646 describes a CCS that covers almost all known written characters in use today.

ISO/IEC 10646 is controlled by the group known as "ISO/IEC JTC 1/SC 2 WG2", often called "WG2" for short. ISO standards go through many steps before being finished, and years often go by between changes to ISO/IEC 10646. Information on WG2, and its work products, can be found at <http://www.dkuug.dk/JTC1/SC2/WG2/>.

The standard, which comes in multiple parts, can be purchased in both print and CD-ROM versions. One example of how to cite the standard is given in [RFC2279]. Any standard that cites ISO/IEC 10646 needs to evaluate how to handle the versioning problem that is relevant to the protocol's needs.

ISO is responsible for other standards that might be of interest to protocol developers. [ISO 639] specifies the names of languages, and [ISO 3166] specifies the abbreviations of countries. Character work is done in the group known as ISO/IEC JTC1/SC22 and ISO TC46, as well as other ISO groups.

      Another relevant ISO group is JTC 1/SC22/WG20, which is
      responsible for internationalization in JTC1, such as for
      international string ordering.  Information on WG20, and its work
      products, can be found at <http://www.dkuug.dk/jtc1/sc22/wg20/>
   Unicode Consortium


The Unicode Consortium publishes addenda to the Unicode Standard as Unicode Technical Reports. There are many types of technical reports at various stages of maturity. The Unicode Standard and affiliated technical reports can be found at <http://www.unicode.org/>.

World Wide Web Consortium (W3C)


local and regional standards organizations

Just as there are many native CCSs and charsets, there are many local and regional standards organizations to create and support them. Common examples of these are ANSI (United States), and CEN/ISSS (Europe).

3.2 Encodings and transformation formats of ISO/IEC 10646

Characters in the ISO/IEC 10646 CCS can be expressed in many ways. Encoding forms are direct addressing methods, while transformation formats are methods for expressing encoding forms as bits on the wire.

Basic Multilingual Plane (BMP)

The BMP is composed of the first 2^16 code points in ISO/IEC 10646. The BMP is also called "plane 0".

   UCS-2 and UCS-4

UCS-2 and UCS-4 are the two encoding forms defined for ISO/IEC 10646. UCS-2 addresses only the BMP. Because many useful characters (such as many Han characters) have been defined outside of the BMP, many people would consider UCS-2 to be dead. Theoretically, UCS-4 addresses the entire range of 2^31 code points from ISO/IEC 10646 as 32-bit values. However, for interoperability with UTF-16, ISO 10646 restricts the range of characters that will actually be allocated to the values 0..0x10FFFF.


UTF-8, a transformation format specified in [RFC2279], is the preferred encoding for IETF protocols. Characters in the BMP are encoded as one, two, or three octets. Characters outside the BMP are encoded as four octets. Characters from the US-ASCII repertoire have the same on-the-wire representation in UTF-8 as they do in US-ASCII.

   UTF-16, UTF-16BE, and UTF-16LE

UTF-16, UTF-16BE, and UTF-16LE, three transformation formats defined in [RFC2781], are not required by any IETF standards, and are thus used much less often than UTF-8. Characters in the BMP are always encoded as two octets, and characters outside the BMP are encoded as four octets. The three formats differ based on the order of the octets and the presence of a special lead-in mark called the "byte order mark" or "BOM".


The Unicode Consortium has defined UTF-32 as a transformation format for UCS-4 in [UTR19].

   SCSU and BOCU-1

The Unicode Consortium has defined an encoding, SCSU, which is designed to offer good compression for typical text. SCSU is described in [UTR6]. A different encoding that is meant to be MIME-friendly, BOCU-1, is described in [UTN6]. Although compression is attractive, as opposed to UTF-8 , neither of these (at the time of this writing) has attracted much interest in the IETF.

3.3 Native CCSs and charsets

Before ISO/IEC 10646 was developed, many countries developed their own CCSs and charsets. Many dozen of these are in common use on the Internet today. Examples include ISO 8859-5 for Cyrillic and Shift- JIS for Japanese scripts.

The official list of the registered charset names for use with IETF protocols is maintained by IANA and can be found at <http://www.iana.org/assignments/character-sets>. The list contains preferred names and aliases. Note that this list has historically contained many errors, such as names that are in fact not charsets or references that do not give enough detail to reliably map names to charsets.


[UTR22] describes issues involved in mapping character data between charsets, and an XML format for mapping table data.

4. Character Issues


   combining character


   composite sequence

A sequence of graphic characters consisting of a non-combining character followed by one or more combining characters. A graphic symbol for a composite sequence generally consists of the combination of the graphic symbols of each character in the sequence. A composite sequence is not a character and therefore is not a member of the repertoire of ISO/IEC 10646. <ISOIEC10646>

In some CCSs, some characters consist of combinations of other characters. For example, the letter "a with acute" might be a combination of the two characters "a" and "combining acute", or it might be a combination of the three characters "a", a non- destructive backspace, and an acute. The rules for combining two or more characters are called "composition rules", and the rules for taking apart a character into other characters is called "decomposition rules". The results of composition is called a "precomposed character"; the results of decomposition is called a "decomposed character".


Normalization is the transformation of data to a normal form, for example, to unify spelling. <UNICODE>

Note that the phrase "unify spelling" in the definition above does not mean unifying different words with the same meaning (such as "color" and "colour"). Instead, it means unifying different character sequences that are intended to form the same composite characters (such as "<a><n><combining tilde><o>" and "<a><n with tilde><o>").

The purpose of normalization is to allow two strings to be compared for equivalence. The strings "<a><n><combining tilde><o>" and "<a><n with tilde><o>" would be shown identically on a text display device. If a protocol designer wants those two strings to be considered equivalent during comparison, the protocol must define where normalization occurs.

The terms "normalization" and "canonicalization" are often used interchangeably. Generally, they both mean to convert a string of one or more characters into another string based on standardized rules. Some CCSs allow multiple equivalent representations for a written string; normalization selects one among multiple equivalent representations as a base for reference purposes in comparing strings. In strings of text, these rules are usually based on decomposing combined characters or composing characters with combining characters. [UTR15] describes the process and many forms of normalization in detail. Normalization is important when comparing strings to see if they are the same.


Case is the feature of certain alphabets where the letters have two distinct forms. These variants, which may differ markedly in shape and size, are called the uppercase letter (also known as capital or majuscule) and the lowercase letter (also known as small or minuscule). Case mapping is the association of the uppercase and lowercase forms of a letter. <UNICODE>

There is usually (but not always) a one-to-one mapping between the same letter in the two cases. However, there are many examples of characters which exist in one case but for which there is no corresponding character in the other case or for which there is a special mapping rule, such as the Turkish dotless "i" and some Greek characters with modifiers. Case mapping can even be dependent on locale. Converting text to have only one case is called "case folding".

   sorting and collation

Collating is the process of ordering units of textual information. Collation is usually specific to a particular language. It is sometimes known as alphabetizing, although alphabetization is just a special case of sorting and collation. <UNICODE>




Many processes have a need to order strings in a consistent sequence (sorted). For only a few CCS/CES combinations, there is an obvious sort order that can be done without reference to the linguistic meaning of the characters: the codepoint order is sufficient for sorting. That is, the codepoint order is also the order that a person would use in sorting the characters. For many CCS/CES combinations, the codepoint order would make no sense to a person and therefore is not useful for sorting if the results will be displayed to a person.

Codepoint order is usually not how any human educated by a local school system expects to see strings ordered; if one orders to the expectations of a human, one has a language-specific sort. Sorting to codepoint order will seem inconsistent if the strings are not normalized before sorting because different representations of the same character will sort differently. This problem may be smaller with a language-specific sort.

   code table

A code table is a table showing the characters allocated to the octets in a code. <ISOIEC10646>

Code tables are also commonly called "code charts".

4.1 Types of characters



An informative Unicode property. Characters that are the primary units of alphabets and/or syllabaries, whether combining or noncombining. This includes composite characters that are canonical equivalents to a combining character sequence of an alphabetic base character plus one or more combining characters: letter digraphs; contextual variant of alphabetic characters; ligatures of alphabetic characters; contextual variants of ligatures; modifier letters; letterlike symbols that are compatibility equivalents of single alphabetic letters; and miscellaneous letter elements. <UNICODE>






One of a set of characters other than those used for letters, digits, or punctuation, and representing various concepts generally not connected to written language use per se. Examples include symbols for mathematical operators, symbols for OCR, symbols for box-drawing or graphics, and symbols for dingbats. <NONE>

Examples of symbols include characters for arrows, faces, and geometric shapes. [UNICODE] has a property that defines characters as symbols.

   nonspacing character




A mark applied or attached to a symbol to create a new symbol that represents a modified or new value. They can also be marks applied to a symbol irrespective of whether it changes the value of that symbol. In the latter case, the diacritic usually represents an independent value (for example, an accent, tone, or some other linguistic information). Also called diacritical mark or diacritical. <UNICODE>

   control character
      They are also known as control codes.  <UNICODE>
   formatting character

Characters that are inherently invisible but that have an effect on the surrounding characters. <UNICODE>


   compatibility character

A graphic character included as a coded character of ISO/IEC 10646 primarily for compatibility with existing coded character sets. <ISOIEC10646>

For example, U+FF01 (FULLWIDTH EXCLAMATION MARK) was included for compatibility with Asian character sets that include full-width and half-width ASCII characters.

5. User interface for text


   input methods

An input method is a mechanism for a person to enter text into an application. <NONE>


For example, there are dozens of different input methods for Han characters in Chinese, Japanese, and Korean. Some start with phonetic input through the keyboard, while others use the number of strokes in the character. Input methods are also needed for scripts that have many diacritics, such as European characters that have two or three diacritics on a single alphabetic character.

   rendering rules

A rendering rule is an algorithm that a system uses to decide how to display a string of text. <NONE>


Some examples of these rendering rules include:

  • Arabic and Hebrew scripts, where the order of the characters displayed are changed by the bidirectional properties of the alphabetic characters and with right-to-left and left-to-right ordering marks. The rendering rules must choose the order that characters are displayed.
   graphic symbol

A graphic symbol is the visual representation of a graphic character or of a composite sequence. <ISOIEC10646>


A font is a collection of glyphs used for the visual depiction of character data. A font is often associated with a set of parameters (for example, size, posture, weight, and serifness), which, when set to particular values, generate a collection of imagable glyphs. <UNICODE>

   bidirectional display


Most of the world's written languages are displayed left-to-right. However, many widely-used written languages such as ones based on the Hebrew or Arabic scripts are displayed right-to-left. Right- to-left text often confuses protocol writers because they have to keep thinking in terms of the order of characters in a string in memory, and that order might be different than what they see on the screen. (Note that some languages are written both horizontally and vertically.)

Further, bidirectional text can cause confusion because there are formatting characters in ISO/IEC 10646 which cause the order of display of text to change. These explicit formatting characters change the display regardless of the implicit left-to-right or right-to-left properties of characters.


[UNICODE] has a long and incredibly detailed algorithm for displaying bidirectional text.

   undisplayable character

A character that has no displayable form. <NONE>


6. Text in current IETF protocols


   protocol elements

Protocol elements are uniquely-named parts of a protocol. <NONE>

      protocol standard.  The names of protocol elements are not
      normally seen by end users.
   name spaces

A name space is the set of valid names for a particular item, or the syntactic rules for generating these valid names. <NONE>

      Many items in Internet protocols use names to identify specific
      instances or values.  The names may be generated (by some
      IANA), or have a distributed registration and control mechanism,
      such as the names in the DNS.
   on-the-wire encoding



   parsed text

Text strings that is analyzed for subparts. <NONE>

In some protocols, free text in text fields might be parsed. For example, many mail user agents will parse the words in the text of the Subject: field to attempt to thread based on what appears after the "Re:" prefix.

   charset identification

Specification of the charset used for a string of text. <NONE>


   language identification

Specification of the human language used for a string of text. <NONE>

Some protocols (such as MIME and HTTP) allow text that is meant for machine processing to be identified with the language used in the text. Such identification is important for machine-processing of the text, such as by systems that render the text by speaking it. Language identification is also called "language tagging".


MIME (Multipurpose Internet Mail Extensions) is a message format that allows for textual message bodies and headers in character sets other than US-ASCII in formats that require ASCII (most notably, [RFC2822], the standard for Internet mail headers). MIME is described in RFCs 2045 through 2049, as well as more recent RFCs. <NONE>

   transfer encoding syntax

A transfer encoding syntax (TES) (sometimes called a transfer encoding scheme) is a reversible transform of already-encoded data that is represented in one or more character encoding schemes. <NONE>

TESs are useful for encoding types of character data into an another format, usually for allowing new types of data to be transmitted over legacy protocols. The main examples of TESs used in the IETF include Base64 and quoted-printable.



   quoted printable




XML (which is an approximate abbreviation for Extensible Markup Language) is a popular method for structuring text. XML text is explicitly tagged with charsets. The specification for XML can be found at <http://www.w3.org/XML/>. <NONE>

   ASN.1 text formats


   ASCII-compatible encoding (ACE)

Starting in 1996, many ASCII-compatible encoding schemes (which are actually transfer encoding syntaxes) have been proposed as possible solutions for internationalizing host names. Their goal is to be able to encode any string of ISO/IEC 10646 characters as legal DNS host names (as described in STD 13). At the time of this writing, no ACE has become an IETF standard.

7. Other Common Terms In Internationalization

This is a hodge-podge of other terms that have appeared in internationalization discussions in the IETF. It is likely that additional terms will be added as this document matures.

      Locale is the user-specific location and cultural information
      managed by a computer.   <NONE>



It should be noted that there are many thorny, unsolved issues with locale. For example, should text be viewed using the locale information of the person who wrote the text or the person viewing it? What if the person viewing it is travelling to different locations? Should only some of the locale information affect creation and editing of text?

   Latin characters

"Latin characters" is a not-precise term for characters historically related to ancient Greek script and currently used throughout the world. <NONE>

The base Latin characters make up the ASCII repertoire and have been augmented by many single and multiple diacritics and quite a few other characters. ISO/IEC 10646 encodes the Latin characters in the ranges U+0020..U+024F, U+1E00..U+1EFF, and other ranges.


The transliteration of a non-Latin script into Latin characters. <NONE>

Because of the widespread use of Latin characters, people have tried to represent many languages that are not based on a Latin repertoire in Latin. For example, there are two popular romanizations of Chinese: Wade-Giles and Pinyin, the latter of which is by far more common today. Many romanization systems are inexact and do not give perfect round trip mappings between the native script and the Latin characters.

CJK characters and Han characters

The ideographic characters used in Chinese, Japanese, Korean, and traditional Vietnamese writing systems are often called 'CJK characters' after the initial letters of the language names in English. They are also called "Han characters", after the term in Chinese that is often used for these characters. <NONE>

Note that CJK and Han characters do not include the phonetic characters used in the Japanese and Korean languages.






The process of representing the characters of an alphabetical or syllabic system of writing by the characters of a conversion alphabet. <NONE>



The process of systematically writing the sounds of some passage of spoken language, generally with the use of a technical phonetic alphabet (usually Latin-based) or other systematic transcriptional orthography. Transcription also sometimes refers to the conversion of written text into a transcribed (usually Latin- based) form, based on the sound of the text as if it had been spoken. <NONE>


   regular expressions




   private use



8. Security Considerations

Security is not discussed in this document.

9. References

9.1 Normative References

   [ISOIEC10646] ISO/IEC 10646-1:2000.  International Standard --
                 Information technology -- Universal Multiple-Octet
                 Basic Multilingual Plane, 2000.
   [UNICODE]     The Unicode Standard, Version 3.2.0 is defined by The
                 Unicode Standard, Version 3.0 (Reading, MA, Addison-
                 Wesley, 2000.  ISBN 0-201-61633-5), as amended by the
                 Unicode Standard Annex #27: Unicode 3.1
                 Unicode Standard Annex #28: Unicode 3.2
                 (http://www.unicode.org/reports/tr28/), The Unicode
                 Consortium, 2002.

9.2 Informative References

   [CHARMOD]     Character Model for the World Wide Web 1.0, W3C,
   [FRAMEWORK]   ISO/IEC TR 11017:1997(E).  Information technology -
                 Framework for internationalization, prepared by ISO/IEC
                 JTC 1/SC 22/WG 20, 1997.
   [ISO 639]     ISO 639:2000 (E/F) - Code for the representation of
                 names of languages, 2000.
                 names of countries, 2000.
   [RFC2045]     Freed, N. and N. Borenstein, "MIME Part One: Format of
                 Internet Message Bodies", November 1996.
   [RFC2047]     Moore, K., "MIME Part Three: Message Header Extensions
                 Languages", BCP 18, RFC 2277, January 1998.
   [RFC2279]     Yergeau, F., "UTF-8, a transformation format of ISO
                 10646", RFC 2279, January 1998.
                 10646", RFC 2781, February 2000.
                 Languages", BCP 47, RFC 3066, January 2001.
                 Information Interchange, ANSI X3.4-1986, 1986.
   [UTN6]        "BOCU-1: MIME-Compatible Unicode Compression", M.
                 Scherer & M.  Davis, Unicode Technical Note #6.
   [UTR6]        "A Standard Compression Scheme for Unicode", M. Wolf,
                 et. al., Unicode Technical Report #6.
   [UTR15]       "Unicode Normalization Forms", M. Davis & M. Duerst,
                 Unicode Technical Report #15.
   [UTR18]       "Unicode Regular Expression Guidelines", M. Davis,
                 Unicode Technical Report #18.
   [UTR19]       "UTF-32", M. Davis, Unicode Technical Report #19.
   [UTR22]       "Character Mapping Markup Language", M. Davis, Unicode
                 Technical Report #22.

10. Additional Interesting Reading

   ALA-LC Romanization Tables, Randall Barry (ed.), U.S. Library of
   Congress, 1997, ISBN 0844409405

Blackwell Encyclopedia of Writing Systems, Florian Coulmas, Blackwell Publishers, 1999, ISBN 063121481X

The World's Writing Systems, Peter Daniels and William Bright, Oxford University Press, 1996, ISBN 0195079930

Writing Systems of the World, Akira Nakanishi, Charles E. Tuttle Company, 1980, ISBN 0804816549

11. Index

   alphabetic -- 4.1
   ASCII-compatible encoding (ACE) -- 6
   ASN.1 text formats -- 6
   Base64 -- 6
   Basic Multilingual Plane (BMP) -- 3.2
   bidirectional display -- 5
   BOCU-1 -- 3.2
   case -- 4
   character -- 2
   character encoding form -- 2
   character encoding scheme -- 2
   charset -- 2
   charset identification -- 6
   CJK characters and Han characters -- 7
   code chart -- 4
   code table -- 4
   coded character -- 2
   coded character set -- 2
   combining character -- 4
   compatibility character -- 4.1
   composite sequence -- 4
   control character -- 4.1
   diacritic -- 4.1
   displaying and rendering text -- 2
   font -- 5
   formatting character -- 4.1
   glyph -- 2
   glyph code -- 2
   graphic symbol -- 5
   i18n, l10n -- 2
   ideographic -- 4.1
   input methods -- 5
   internationalization -- 2
   ISO -- 3.1
   language -- 2
   language identification -- 6
   Latin characters -- 7
   local and regional standards organizations -- 3.1
   locale -- 7
   localization -- 2
   MIME -- 6
   multilingual -- 2
   name spaces -- 6
   nonspacing character -- 4.1
   normalization -- 4
   on-the-wire encoding -- 6
   parsed text -- 6
   private use -- 7
   protocol elements -- 6
   punctuation -- 4.1
   quoted printable -- 6
   regular expressions -- 7
   rendering rules -- 5
   romanization -- 7
   script -- 2
   SCSU -- 3.2
   sorting and collation -- 4
   symbol -- 4.1
   transcoding -- 2
   transcription -- 7
   transfer encoding syntax -- 6
   translation -- 7
   transliteration -- 7
   UCS-2 and UCS-4 -- 3.2
   undisplayable character -- 5
   Unicode Consortium -- 3.1
   UTF-32 -- 3.2
   UTF-16, UTF-16BE, and UTF-16LE -- 3.2
   UTF-8 -- 3.2
   World Wide Web Consortium -- 3.1
   XML -- 6

A. Acknowledgements


James Seng contributed to the initial outline of this document. Harald Alvestrand and Martin Duerst made extensive useful comments on early versions. Others who contributed to the development include:

Dan Kohn
Jacob Palme
Johan van Wingen
Peter Constable
Yuri Demchenko
Susan Harris
Zita Wenzel
John Klensin
Henning Schulzrinne
Leslie Daigle
Markus Scherer
Ken Whistler

B. Author's Address

   Paul Hoffman
   Internet Mail Consortium and VPN Consortium
   127 Segre Place
   Santa Cruz, CA  95060 USA
   EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org

Full Copyright Statement





