Кратко

  • RFC 1556 описывал три распределения ответственности: в visual-режиме порядок заранее готовил редактор, в implicit-режиме его вычислял просмотрщик, а в explicit-режиме отображением управляли контрольные последовательности внутри текста.
  • MIME мог сохранить не-ASCII символы, не доказав тем самым, что получатель восстановил задуманное чтение. Charset, режим направления, управляющие функции и контекст рендерера требовали отдельных подтверждений.
  • Документ декабря 1993 года имел статус Informational и не был Internet Standard. Более поздние HTML, Unicode и почта UTF-8 показывают, что граница сохранилась, но не доказывают прямого происхождения или распространения предложенных суффиксов.

Архив подтвердил файл, но не строку на экране

Проверка старого письма может завершиться без единой ошибки. Хеш архивной копии совпадает с источником. MIME-декодер возвращает все ожидаемые символы. Ни один октет не исчез. И всё же латинское название оказывается слева от числа в одном клиенте и справа в другом; после копирования знак препинания снова меняет соседа.

Транспортное подтверждение остаётся верным. Оно только относится к предыдущему слою. После доставки системе всё ещё нужно выбрать базовое направление абзаца, разрешить встречные фрагменты, расположить числа и нейтральные знаки и применить правила к строкам, границы которых могут различаться.

Именно этот участок описывал RFC 1556Handling of Bi-directional Texts in MIME. Hank Nussbacher опубликовал меморандум в декабре 1993 года. Карточка RFC Editor и запись IETF относят его к Informational; сам текст прямо говорит, что он не задаёт стандарт Интернета.

Предложение было узким: описать соглашение direction для двунаправленных MIME-текстов. Но оно выявило более широкую границу. Сохранённое представление и верная презентация — не одно и то же доказательство.

MIME сначала расширил транспортный договор

RFC 1521 позволил телу письма выйти за пределы плоского ASCII. Часть сообщения могла объявить тип содержимого и charset, а Base64 или Quoted-Printable защищали значения на пути через старую инфраструктуру. Информационная страница фиксирует историческую роль MIME Part One.

RFC 1522 перенёс не-ASCII текст в определённые поля заголовка. Редактор создавал encoded-word; совместимый клиент распознавал его, снимал кодирование и показывал текст в указанном charset. Отдельная карточка определяет область этих Header Extensions.

Charset отвечает, какие символы соответствуют значениям. Transfer encoding отвечает, как провести значения через канал. Но в строке, где арабский ISO-8859-6 или иврит ISO-8859-8 соседствует с латиницей, ни один из этих ответов сам по себе не задаёт видимые отношения.

RFC 1556 не объявлял MIME неудачей. Он начинался там, где декодер мог успешно закончить работу, а читатель — всё ещё получить неверный результат.

Соседний документ об иврите показал предварительную раскладку

В том же месяце Nussbacher и Yehavi Bourvine выпустили RFC 1555 о почте на иврите с MIME и ISO-8859-8. Его карточка RFC Editor также указывает статус Informational.

По умолчанию направление было visual. Пользователь вводил иврит справа налево, однако программа кодировала его как визуальный ряд слева направо, и MIME передавал этот ряд слева направо. Просмотрщику не требовалось понимать направление содержания: составитель уже подготовил строку для ожидаемого экрана.

Совместимость с простым терминалом переносила долг к отправителю. Сохранённый порядок работал, пока более поздняя программа не принимала visual order за logical order. Если затем включался implicit-алгоритм, он повторно переставлял то, что уже было переставлено.

RFC 1555 описывал и прямую потерю контекста. Некоторые режимы Listserv рассылали сокращённые заголовки, а архивы могли не сохранять MIME-информацию. Кодированное содержимое оставалось, но инструкция для его понимания исчезала.

Даже будущая прозрачная восьмибитная почта должна была лишь частично сделать ненужными Base64 и Quoted-Printable. Content-Type и directionality продолжали требоваться. Более прозрачная труба не выбирала порядок чтения.

Visual: решение было принято до отправки

RFC 1556 оставлял visual режимом по умолчанию и использовал обычное имя ISO-8859 без суффикса. Приложение отображения следовало одному первичному направлению слева направо и считало материал однонаправленным. Редактор должен был заранее расположить символы так, чтобы они выглядели правильно. На стороне показа не применялись ни управляющие знаки направления, ни алгоритм перестановки.

Преимущество было практичным: простой терминал показывал строку, не понимая её языка. Но неведение viewer становилось частью договора. Composer выполнял всю работу, а получатель должен был не выполнить её снова.

Цена проявлялась при редактировании. Движение курсора, поиск, вставка латинского слова, новая ширина окна или копирование работали с последовательностью, подготовленной для конкретной картинки, а не обязательно с устойчивой логической структурой фразы.

Visual не устранял направление. Он переносил решение к авторской программе и во время до передачи.

Implicit: контекст стал исполняемым входом

Для implicit предлагались ISO-8859-6-i и ISO-8859-8-i. Алгоритм определял презентацию по типам символов, их положению относительно соседей и первичному направлению. Полная процедура была достаточно сложной, поэтому RFC 1556 отсылал разработчиков к ECMA TR/53.

Composer мог сохранить более логичную последовательность, но обязанности переходили к получателю. Он должен был распознать режим, применить совместимые свойства направленности и знать базу и границы абзаца. Числа, пунктуация и нейтральные символы зависят от окружения; перенос строки тоже меняет единицу вычисления.

Общий алгоритм уменьшает произвол, но его результат не заключён в хеше сообщения. Два движка могут получить одинаковую decoded sequence и разойтись из-за версии правил, базового направления, границ markup или разбиения на строки.

Для воспроизведения требовалась не только нагрузка, но и среда, принявшая решение.

Explicit: невидимым командам нужны были два хранителя

Названия ISO-8859-6-e и ISO-8859-8-e обозначали explicit. Контрольные последовательности вставлялись в текст и объявляли направление. Отправитель мог открыть или изменить контекст, не полагаясь полностью на вывод из соседних символов.

Явная команда не сохраняет себя автоматически. Sanitizer мог удалить непечатаемую функцию, конвертер — оставить неизвестное значение, которое viewer не исполняет, а незакрытая область могла повлиять на лишний текст. Сравнение только видимых букв скрывало решающее изменение.

Согласно RFC 1556, ECMA TR/53 добавил три управляющие функции и изменил 22 существующие функции ECMA-48. Речь шла не об одном маркере «справа налево». Направление влияло на активные позиции, движение и соответствие компонента данных компоненту презентации.

Отправитель отвечал за команды, получатель — за их сохранение и исполнение состояния. Обе половины входили в цепочку доказательств.

Позиция в данных не равнялась позиции на экране

Модель ECMA TR/53 описывала устройство, которое получает графические символы и управляющие функции и создаёт читаемое человеком изображение согласно правилам письма. Она разделяла data component и presentation component, где активные позиции могли двигаться по разным правилам.

Поэтому задача не сводилась к шрифту. Шрифт выбирает глиф. Модель презентации решает, рядом с каким глифом он окажется, куда переместится курсор и к какой позиции относятся backspace или carriage return.

RFC 1556 сжал эту архитектуру до выбора на стороне MIME. Получателю нужно было знать, пришёл ли готовый визуальный ряд, последовательность для implicit-вычисления или поток с explicit-командами. При потере выбора правильные данные попадали в неправильную машину отображения.

Четыре сбоя без потери символа

Первый — исчезновение метаданных. Gateway превращает ISO-8859-8-i в ISO-8859-8, либо архив отбрасывает Content-Type. Символы остаются; режим пропадает.

Второй — двойная перестановка. Composer подготовил visual order, а современный viewer считает её logical order и запускает implicit. Каждый компонент выполняет собственный договор, но их сочетание ошибочно.

Третий — удаление контролей. Политика безопасности сохраняет печатные знаки и стирает невидимые explicit-инструкции. Поверхностное сравнение сообщает эквивалентность.

Четвёртый — дрейф контекста. Два implicit-движка используют разную базу, перенос, границу стиля или ревизию алгоритма. Decoded sequence совпадает, visual sequence — нет.

Числа, пунктуация и идентификаторы делают эффект эксплуатационным. Знак может примкнуть не к той сумме; идентификатор может выглядеть правдоподобно и копироваться в другом порядке. Наличие всех символов не доказывает сохранность их отношений.

Поздние механизмы сохраняют границу, а не доказывают родословную

В 1997 году RFC 2070 добавил в HTML средства интернационализации, включая атрибут DIR и элемент override BDO. Его информационная карточка относится к Web markup и не подтверждает прямого внедрения суффиксов RFC 1556.

Ранняя версия Unicode Bidirectional Algorithm различала логический порядок в памяти и порядок отображения, а форматирующие коды относила к визуальному результату. Современный UAX #9 значительно развился и определяет также допустимый контекст от higher-level protocols.

В 2012 году RFC 6532 разрешил прямой UTF-8 в значениях заголовков при сквозной поддержке в почтовой среде. Страница документа фиксирует этот отдельный договор. Упрощение транспорта большого набора символов не объединило порядок хранения с порядком показа.

Эти источники доказывают повторяемость границы. Они не доказывают распространения -i и -e или единственной линии от RFC 1556 к Unicode, HTML и SMTPUTF8.

Одного снимка экрана недостаточно

Транспортный receipt хранит исходные октеты, хеш, transfer encoding и декодированную последовательность code points. Он отвечает, менялось ли представление в пути.

Интерпретационный receipt хранит Content-Type, charset, режим, explicit-контроли, базовое направление, верхнеуровневые markup и style, renderer и версию алгоритма. Он объясняет, какие правила считал применимыми получатель.

Презентационный receipt хранит разбиение строк, resolved visual order, screenshot и результат copy/paste или round trip. Он отвечает, что появилось в конкретной среде.

Изображение без входа доказывает только один показ; хеш без выхода — только одну последовательность. Тесты должны смешивать арабское или еврейское письмо с латиницей, числами, пунктуацией, нейтральными знаками, вложенностью и разной шириной. При миграции следует хранить оба результата до объяснения различия.

Публикация не стала эксплуатационной реальностью

Running-Code Primacy Heng Lu даёт современную дисциплину: документ координирует, а реализацию, эксплуатацию и применение показывает работающая система. Публикация RFC 1556 подтверждает документированное предложение, не его выполнение почтовыми клиентами.

Minimum Initial Specification, Localized Future Decision и Voluntary Adoption спрашивают, какие общие правила минимальны, детерминированы и проверяемы локально. Равенство перенесённых символов оказалось слишком слабым инвариантом; режим, контекст и процедура презентации тоже должны проверяться.

Подход Reality Layers не позволяет транспортному подтверждению говорить за экран. Это более поздняя аналитическая рамка, а не свидетельство намерений Nussbacher или ECMA; она ограничивает наш собственный исторический вывод.

Главный вопрос — кто уже выполнил перестановку

В visual composer уже действовал. В implicit решение ещё предстояло renderer. В explicit отправитель вложил команды, которые получатель должен был исполнить. Не зная, какая ситуация пришла, система могла безупречно следовать локальному правилу и всё же исказить сообщение.

История RFC 1556 не о неспособности MIME переносить иврит или арабский. MIME сделал путешествие возможным. Короткий меморандум отказался выдавать квитанцию о путешествии за сертификат чтения.

Совпадение последовательности доказывает целую доставку. Сохранённый режим и контроли доказывают контекст интерпретации. Названный и проверенный renderer доказывает один видимый результат. Только вместе они позволяют словам «доставлено правильно» значить больше, чем «байты здесь».

Источники