From: The IESG <firstname.lastname@example.org>
To: IETF-Announce <email@example.com>
Cc: RFC Editor <firstname.lastname@example.org>
Subject: Protocol Action: 'Terminology Used in Internationalization in the IETF' to BCP (draft-ietf-appsawg-rfc3536bis-06.txt)
The IESG has approved the following document:
- 'Terminology Used in Internationalization in the IETF'
(draft-ietf-appsawg-rfc3536bis-06.txt) as a BCP
This document is the product of the Applications Area Working Group.
The IESG contact persons are Pete Resnick and Peter Saint-Andre.
A URL of this Internet Draft is:
This document provides a glossary of terms used in the IETF when discussing internationalization.
The purpose is to help frame discussions of internationalization in the various areas of the IETF and
to help introduce the main concepts to IETF participants.
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.
Some of the overview is a somewhat tuturial in nature. 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
Working Group Summary
Not surprisingly for a document such as this, there were many suggestions of terminology to include,
and of alternative definitions to the ones included. The editors have done a good job of striking a
necessary balance between an overly bloated document and one that includes the right set of terms,
with definitions that reflect reasonable consensus, if not always unanimity. There were a number of
such discussions, with none bearing particular mention here.
This document replaces RFC 3536, cleaning up and updating many of the definitions therein. RFC
3536 has been in use for eight years, and this document reflects that maturity and what we've learned
about the gaps in the terminology and definitions over that time. Section 7 is a significant new section
that talks about IDNA work done since RFC 3536.