О документе
Network Working Group H. Alvestrand
Request for Comments: 2277 UNINETT
BCP: 18 January 1998
Category: Best Current Practice
Политика IETF в отношении наборов символов и языков
1. Введение
Интернет является международным.
Международный характер Интернета влечёт абсолютную необходимость обмениваться данными на множестве языков, в которых, в свою очередь, используется ошеломляющее число символов.
Этот документ содержит текущие политики, применяемые Internet Engineering Steering Group (IESG) к работам по стандартизации в Internet Engineering Task Force (IETF), чтобы помочь интернет-протоколам выполнить эти требования.
Документ в значительной степени основан на рекомендациях семинара IAB по наборам символов, проведённого 29 февраля — 1 марта 1996 года и задокументированного в RFC 2130 [WR]. Этот документ стремится быть кратким, явным и ясным; желающим получить больше исходных сведений рекомендуется прочитать RFC 2130.
В документе термины 'MUST', 'SHOULD' и 'MAY', а также их отрицательные формы используются в смысле, описанном в [RFC 2119]. В данном случае «спецификация» в смысле RFC 2119 относится к обработке протоколов, представляемых в процесс стандартизации IETF.
2. Где выполнять интернационализацию
Интернационализация предназначена для людей. Это означает, что интернационализации подлежат не протоколы, а текстовые строки. Если элементы протокола выглядят как текстовые лексемы, как во многих протоколах прикладного уровня IETF, протоколы ДОЛЖНЫ (MUST) указывать, какие части являются протоколом, а какие — текстом. [WR 2.2.1.1]
Имена представляют проблему, поскольку люди придают им большое значение, многие из них главным образом предназначены для локального использования, и все они время от времени выходят за пределы локального контекста. RFC 1958 [RFC 1958] рекомендует US-ASCII для всех глобально видимых имён.
Этот документ не предписывает политику интернационализации имён, но требует, чтобы все протоколы описывали, являются ли имена интернационализированными или US-ASCII.
ПРИМЕЧАНИЕ: В стеке протоколов для любого конкретного приложения обычно есть один или несколько уровней, которым необходимо решать эти проблемы.
Например, было бы неуместно определять языковые метки для кадров Ethernet. Однако рабочие группы (WG) несут ответственность за то, чтобы, когда ответственность за интернационализацию оставляется «другому уровню», ответственные за этот уровень действительно знали, что такая ответственность У НИХ есть.
3. Определение терминов
В этом документе термин «charset» означает набор правил отображения последовательности октетов в последовательность символов, например сочетание кодированного набора символов и схемы кодирования символов; это также то, что используется как идентификатор в параметрах MIME "charset=" и регистрируется в реестре наборов символов IANA [REG]. (Обратите внимание, что это НЕ термин, используемый другими органами по стандартизации, например ISO.)
Определение термина «coded character set» см. в отчёте о семинаре.
«Имя» — это идентификатор, такой как имя человека, имя хоста, доменное имя, имя файла или адрес E-mail; его часто рассматривают как идентификатор, а не как фрагмент текста, и часто используют в протоколах как идентификатор сущностей без окружающего текста.
3.1. Какой набор символов использовать
Все протоколы ДОЛЖНЫ (MUST) для всех символьных данных указывать, какой набор символов используется.
Протоколы ДОЛЖНЫ (MUST) быть способны использовать для всего текста набор символов UTF-8, состоящий из кодированного набора символов ISO 10646 в сочетании со схемой кодирования символов UTF-8, как определено в приложении R к [10646] (опубликованном в Amendment 2).
Протоколы МОГУТ (MAY) дополнительно определять, как использовать другие наборы символов или другие схемы кодирования символов для ISO 10646, например UTF-16, но отсутствие возможности использовать UTF-8 является нарушением этой политики; для такого нарушения до включения в путь стандартов или продвижения по нему потребовалась бы процедура отклонения ([BCP9], раздел 9) с ясным и убедительным обоснованием в документе спецификации протокола.
Для существующих протоколов или протоколов, перемещающих данные из существующих хранилищ данных, поддержка других наборов символов или даже использование значения по умолчанию, отличного от UTF-8, может быть требованием. Это допустимо, но поддержка UTF-8 ДОЛЖНА (MUST) быть возможна.
При использовании наборов символов, отличных от UTF-8, они ДОЛЖНЫ (MUST) быть зарегистрированы в реестре наборов символов IANA; при необходимости они регистрируются при публикации протокола.
(Примечание: ISO 10646 называет UTF-8 CES «Transformation Format», а не «character encoding scheme», но он соответствует приведённому в отчёте о семинаре определению схемы кодирования символов.)
3.2. Как выбирать набор символов
Когда протокол допускает выбор из нескольких наборов символов, кто-то должен принять решение о том, какой набор символов использовать.
В некоторых случаях, например HTTP, между производителем и потребителем данных, содержащих текст, существует прямое или полупрямое взаимодействие. В таких случаях может быть разумно согласовать набор символов до отправки данных.
В других случаях, например для E-mail или хранимых данных, такого взаимодействия нет, и лучшее, что можно сделать, — обеспечить, чтобы набор символов был ясно указан вместе с хранимыми данными, и выбрать настолько широко известный набор символов, насколько это возможно.
Обратите внимание, что набор символов является абсолютным условием; текст, закодированный в наборе символов, невозможно понятным образом отобразить без поддержки этого набора символов.
(Это относится и к английским текстам; такие наборы символов, как EBCDIC, НЕ содержат ASCII как корректное подмножество.)
Согласование набора символов можно рассматривать как промежуточный механизм, который следует поддерживать, пока поддержка обмена UTF-8 не станет распространённой; однако срок этой «промежуточности» может составлять не менее 50 лет, поэтому есть все основания считать этот механизм постоянным на практике.
4.1. Необходимость языковой информации
У любого текста, читаемого человеком, есть язык.
Многие операции, включая высококачественное форматирование, синтез речи из текста, поиск, переносы, проверку орфографии и так далее, существенно выигрывают от доступа к информации о языке фрагмента текста. [WC 3.1.1.4]
Люди обладают некоторой терпимостью к иностранным языкам, но, как правило, очень недовольны, когда им предъявляют текст на языке, которого они не понимают; именно поэтому необходимо согласование языка.
В большинстве случаев машины не смогут самостоятельно определить язык переданного текста; протокол должен указывать, как передавать языковую информацию, если она вообще должна быть доступна.
Взаимодействие языка и обработки сложно; например, если я сравниваю "name-of-thing(lang=en)" с "name-of-thing(lang=no)" на равенство, я, как правило, ожидаю совпадения, тогда как слово "ask(no)" обозначает вид дерева и едва ли полезно в качестве глагола-команды.
4.2. Требование к языковой маркировке
Протоколы, передающие текст, ДОЛЖНЫ (MUST) обеспечивать передачу информации о языке этого текста.
Протоколам также СЛЕДУЕТ (SHOULD) обеспечивать передачу информации о языке имён там, где это уместно.
Обратите внимание, что это НЕ означает, что такая информация должна всегда присутствовать; требование состоит в том, что если отправитель информации хочет передать информацию о языке текста, протокол предоставляет чётко определённый способ передачи этой информации.
4.3. Как идентифицировать язык
Языковая метка RFC 1766 в настоящее время является наиболее гибким доступным средством для идентификации языка; протоколам СЛЕДУЕТ (SHOULD) использовать её либо предоставить в документе ясное и убедительное обоснование для иного решения.
Также обратите внимание, что язык отличается от локали POSIX; локаль POSIX определяет набор культурных соглашений, которые могут подразумевать язык (локали POSIX или "C", разумеется, этого не делают), тогда как языковая метка, описанная в RFC 1766, идентифицирует только язык.
4.4. Соображения для согласования языка
Протоколы, в которых пользователям предъявляется текст в ответ на действия пользователя, ДОЛЖНЫ (MUST) поддерживать несколько языков.
Способ реализации этого будет различаться между протоколами; например, в одних случаях уместно согласование, при котором клиент предлагает набор языков, а сервер отвечает одним из них; в других случаях сервер может отправить несколько вариантов текста и позволить клиенту выбрать, какой из них отображать.
Согласование полезно, когда одна сторона обмена по протоколу способна представить другой стороне текст на нескольких языках, а другая сторона имеет предпочтение в отношении одного из них; наиболее распространённый пример — текстовая часть ответов об ошибках или веб-страницы, доступные на нескольких языках.
Согласование языка следует рассматривать как постоянное требование протокола, которое не исчезнет в какой-либо момент в будущем.
Во многих случаях должна быть возможность включить его в установление соединения вместе с аутентификацией и согласованием других предпочтений.
4.5. Язык по умолчанию
Когда текст, читаемый человеком, должен быть представлен в контексте, в котором отправитель не знает языковых предпочтений получателя (например, при неудачах входа в систему, предупреждениях, отправленных по E-mail, или до согласования языка), текст СЛЕДУЕТ (SHOULD) представлять на языке по умолчанию.
Языку по умолчанию присвоена метка "i-default" согласно процедурам RFC 1766. Это не конкретный язык, а обозначение условия, при котором нельзя установить языковые предпочтения пользователя.
Сообщения на языке по умолчанию ДОЛЖНЫ (MUST) быть понятны англоговорящему человеку, поскольку английский — это язык, на котором во всём мире наибольшее число людей сможет получить достаточную помощь в толковании при работе с компьютерами.
Обратите внимание, что согласование английского НЕ равнозначно языку по умолчанию; язык по умолчанию — экстренная мера для ситуаций, которые иначе не поддаются управлению.
Во многих случаях разумно использовать только английский текст; в некоторых случаях английский текст может быть дополнен текстом на других языках.
5. Локаль
Стандарт POSIX [POSIX] определяет понятие, называемое «locale», которое включает много информации о порядке сортировки, формате даты, формате валюты и так далее.
В некоторых случаях, особенно для текста, который пользователь должен обрабатывать, к тексту может быть полезно присоединить информацию о локали; она выражала бы мнение отправителя о надлежащих правилах, которым следует следовать при обработке документа, с которым получатель может согласиться или которое может проигнорировать.
Этот документ не требует передачи информации о локали для всего текста, но поощряет её включение там, где это уместно.
Обратите внимание, что информация о языке и наборе символов часто будет присутствовать как части метки локали (например, no_NO.iso-8859-1; язык находится перед символом подчёркивания, а набор символов — после точки); необходимо позаботиться о точном определении, какая спецификация набора символов и языка применяется к каждому элементу текста.
Локалью по умолчанию является локаль "POSIX".
6. Документирование решений по интернационализации
В документах, вообще затрагивающих вопросы интернационализации, краткое описание выбранных подходов к интернационализации СЛЕДУЕТ (SHOULD) собрать в раздел с названием "Internationalization considerations" и разместить рядом с разделом Security Considerations.
Это предоставляет удобную справку тем, кто ищет рекомендации по этим вопросам при реализации протокола.
7. Соображения безопасности
Помимо того факта, что предупреждения безопасности на иностранном языке могут вызвать ненадлежащее поведение пользователя, и того факта, что многоязычные системы обычно имеют проблемы с согласованностью между языковыми вариантами, не выявлено соображений безопасности, относящихся к данному документу.
8. Ссылки
[10646]
ISO/IEC, Information Technology - Universal Multiple-Octet Coded
Character Set (UCS) - Part 1: Architecture and Basic
Multilingual Plane, May 1993, with amendments
[RFC 2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[WR] Weider, C., Preston, C., Simonsen, K., Alvestrand, H,
Atkinson, R., Crispin, M., and P. Svanberg, "The Report of the
IAB Character Set Workshop held 29 February - 1 March, 1996",
RFC 2130, April 1997.
[RFC 1958]
Carpenter, B., "Architectural Principles of the Internet", RFC
1958, June 1996.
[POSIX]
ISO/IEC 9945-2:1993 Information technology -- Portable Operating
System Interface (POSIX) -- Part 2: Shell and Utilities
[REG]
Freed, N., and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2278, January 1998.
[UTF-8]
Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[BCP9]
Bradner, S., "The Internet Standards Process -- Revision 3," BCP
9, RFC 2026, October 1996.
9. Адрес автора
Harald Tveit Alvestrand
UNINETT
P.O.Box 6883 Elgeseter
N-7002 TRONDHEIM
NORWAY
Phone: +47 73 59 70 94
EMail: Harald.T.Alvestrand@uninett.no
10. Полное заявление об авторских правах
Copyright (C) The Internet Society (1998). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться
другим лицам, а производные работы, содержащие комментарии к нему,
иным образом разъясняющие его или содействующие его реализации,
могут подготавливаться, копироваться, публиковаться и распространяться,
полностью или частично, без каких-либо ограничений, при условии, что
приведённое выше уведомление об авторских правах и настоящий абзац
включаются во все такие копии и производные работы. Однако сам этот
документ не может быть изменён каким-либо образом, например путём удаления
уведомления об авторских правах или ссылок на Internet Society либо другие
интернет-организации, за исключением случаев, когда это необходимо для
разработки интернет-стандартов, при которой должны соблюдаться процедуры
в отношении авторских прав, определённые в процессе разработки интернет-
стандартов, или когда это требуется для перевода документа на языки,
отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не
будут отозваны Internet Society либо его правопреемниками или цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях
«КАК ЕСТЬ» («AS IS»), И INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE
ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО
ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ
ИНФОРМАЦИИ НЕ НАРУШИТ КАКИЕ-ЛИБО ПРАВА, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ
ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.