Кратко

  • RFC 2277 потребовал от спецификаций IETF отделять элементы протокола от текста, указывать charset, обеспечивать возможность UTF-8 и определять способ передачи языковой информации.
  • Эти требования создавали проверяемую запись о проектном решении, но не доказывали поддержку у получателя, принятие результата согласования, locale, правильное отображение или человеческое понимание.

RFC 2277 был опубликован в январе 1998 года как BCP 18. Это не новая кодировка, а политика IESG для протоколов, входивших в процесс стандартизации IETF. Одновременное объявление IESG сформулировало порог: текстовый протокол должен уметь использовать UTF-8 и переносить языковые метки; отступление требовало отдельного обоснования и процедуры variance.

Нормативные слова относились к спецификации. Она должна была объяснить, какие похожие на текст элементы являются машинными символами протокола, а какие предназначены человеку. Если интернационализация оставлялась другому уровню, рабочая группа обязана была убедиться, что этот уровень осознаёт ответственность. Для имён также следовало явно выбрать интернационализацию либо US-ASCII.

Так появлялась квитанция проектирования: рецензент мог увидеть выбор и владельца. Но спецификация не проверяла конкретную установленную программу и не наблюдала будущего читателя.

Под charset RFC 2277 понимал правила отображения последовательности octets в последовательность символов. Для всех символьных данных надо было определить charset, а текстовый протокол должен был допускать UTF-8. Старые протоколы и хранилища могли сохранять иные значения по умолчанию; дополнительные charsets следовало регистрировать.

Метка отвечает, какое правило декодирования предполагается. Она не подтверждает, что байты допустимы, приёмник реализует правило, а средство отображения имеет нужные глифы. Формально верная, но неверная по фактам метка лишь точно направит декодер по неправильному пути.

RFC разделял интерактивный выбор и хранение. В обмене вроде HTTP производитель и потребитель могут согласовать charset. В почте или архиве нет живого разговора с будущим адресатом, поэтому остаётся связать с данными ясную метку и выбрать широко известное представление. Согласование фиксирует предложение и выбор; архивная метка — утверждение отправителя. Ни то ни другое не подтверждает результат отображения.

Язык образует отдельную поверхность. Протокол обязан был предоставлять способ его указать, но значение не требовалось для каждого текста. RFC 2277 рекомендовал тогда RFC 1766 и отличал язык от POSIX locale. Locale может задавать сортировку, даты и валюту, а получатель вправе принять или отвергнуть мнение отправителя об этих правилах.

Поэтому ru не доказывает, что конкретный человек понимает сообщение. Accept-Language в RFC 2068 выражал предпочтение и одновременно предупреждал, что понятность зависит от пользователя. Сопоставление по префиксу не означало понимание всех более точных вариантов. RFC 1766 также не позволял во всех случаях вывести правильное отображение charset только из языка, особенно в смешанном японско-китайском тексте.

Рекомендованный раздел “Internationalization Considerations” рядом с Security Considerations собирал решения в одном месте: где текст, какие представления доступны, как переносится язык, как идёт согласование и какой уровень отвечает. Это сильный механизм управления спецификацией. Однако он не доказывает, что реализация исполнила решение, переводы сохранили смысл, а предупреждение вызвало верное действие.

Сам RFC отмечал, что предупреждение на чужом языке способно привести к неправильному поведению, а многоязычные версии часто расходятся. Историческое достижение документа состояло в том, что такие решения нельзя было молча скрыть. Декларация, способность, выбор, декодирование, представление и понимание оставались разными свидетельствами.

Источники и пределы

Источники подтверждают политику 1998 года, её связь с RFC 2130, механизмы MIME, HTTP и языковых меток того времени, а также развитие формального определения UTF-8. Они не измеряют нынешнее внедрение, работу именованного продукта или понимание конкретного пользователя.