Кратко

  • Команда LANGUAGE из RFC 5255 выбирает язык фиксированных ответов сервера и локализованное представление префиксов NAMESPACE. Канонический namespace и идентичность почтового ящика при этом не меняются.
  • COMPARATOR влияет на смысл SEARCH, SORT и THREAD. Поэтому воспроизводимый результат должен указывать декодирование, преобразование кодировки, активный компаратор и возможный переход к i;octet.

Под одним словом скрыты две разные власти

В пользовательском интерфейсе интернационализация часто выглядит как один переключатель. Спецификация RFC 5255 показывает, почему для эксплуатации этого недостаточно. LANGUAGE управляет тем, на каком языке сервер формулирует фиксированные объяснения и как он предлагает отображать префиксы пространства имён. I18NLEVEL и COMPARATOR управляют тем, как строки сравниваются при выполнении запросов.

Первый выбор меняет представление. Второй способен изменить набор найденных сообщений и их порядок. Ни один не переписывает хранимое письмо. Если же система сведёт оба решения к единственному полю «locale», расследование потеряет причинную цепочку. Оно не сможет отличить смену подписи от смены колlation, а штатный fallback — от прямого результата выбранного правила.

Именно поэтому интернационализация здесь является вопросом не только удобства, но и полномочий. Видимая строка имеет силу на уровне интерфейса. Каноническое имя имеет силу на уровне адресации. Выдача имеет силу лишь для конкретного алгоритма и поколения сеанса. Эти утверждения связаны, но не взаимозаменяемы.

Перевод префикса не создаёт новый объект

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

В ответе NAMESPACE поле TRANSLATION сопровождает канонический префикс отображаемым вариантом. Клиент отвечает за преобразование в обе стороны, когда показывает имя пользователю. Если он сохраняет только локализованный текст, соответствие становится необратимым. После смены языка один ящик может выглядеть как два; закладка может указывать на подпись вместо адреса; средство миграции может принять новую локализацию за переименование.

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

Сама команда LANGUAGE имеет несколько исходов, которые нельзя объединять. Успешный выбор возвращает один тег и вступает в силу сразу после ответа. Ответ с несколькими тегами перечисляет доступные языки, но ничего не выбирает. Ошибка оставляет прежнюю настройку. Для меню эти состояния могут выглядеть похожими; для журнала это выбор, инвентаризация и неудавшийся переход.

Значение default тоже нельзя записывать как неизменное свойство пользователя. Оно просит язык, предпочитаемый администратором, и выбор может зависеть от того, кто уже вошёл в систему. Это результат политики в конкретном контексте, а не атрибут почтового ящика и не универсальный язык владельца.

Защитный слой создаёт новое поколение выбора

Команду LANGUAGE можно отправить до аутентификации. Это полезно: объяснение просроченного пароля или неудачной попытки установить защиту должно быть понятно ещё до входа. Но ранняя доступность помещает выбор языка в незащищённую часть соединения.

Активный посредник способен подавить или изменить такой обмен до включения TLS либо SASL. В результате последующие сообщения об ошибках могут оказаться непонятными или ввести пользователя в заблуждение. RFC 5255 поэтому требует повторить LANGUAGE после того, как защитный слой уже работает.

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

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

Компаратор исполняет политику запроса

В RFC 5255 есть «компаратор по умолчанию» и «активный компаратор». Первый применяется, пока клиент не согласовал другую настройку. Второй реально используется сеансом. Уровень I18NLEVEL=1 требует i;unicode-casemap, а I18NLEVEL=2 добавляет возможность узнавать и выбирать компараторы командой COMPARATOR.

Выбранное правило является частью смысла запроса, а не примечанием к нему. Оно применяется к определённым полям SEARCH — например, теме, телу, отправителю и заголовкам. Оно также влияет на соответствующие ключи SORT и сравнение тем в THREAD. Одинаковое видимое слово может дать другой состав выдачи или иной порядок при неизменных сообщениях.

После аутентификации компаратор по умолчанию должен оставаться постоянным для данного соединения. Это создаёт стабильную исходную точку. При этом явная команда COMPARATOR способна изменить активное правило. Для воспроизведения нужны обе величины: неизменная база и выбранное отклонение.

Не всякий компаратор поддерживает каждую необходимую операцию. SEARCH требует поиска подстроки. SORT требует отношения порядка, которое зависит и от равенства. Если активное правило не умеет требуемую операцию, команда должна завершиться ошибкой. Серверу нельзя молча подменить её приблизительным сравнением. Поэтому подтверждённый выбор COMPARATOR ещё не означает, что любой следующий запрос выполним.

До сравнения проходит целый конвейер

Компаратор получает не исходные байты сообщения. Сначала удаляются MIME-кодировки передачи и заголовков. Затем текст преобразуется в кодировку, которую ожидает правило сравнения. Лишь после этого выполняется collation.

На каждом этапе возможен отдельный исход. Некоторые ошибки MIME-декодирования RFC 5255 оставляет зависимыми от реализации. Преобразование набора символов может не сработать. Компаратор может признать строку недопустимой или выдать неопределённый результат. Спецификация не скрывает эти границы, а задаёт пути отступления.

Для поиска подстроки ошибка преобразования приводит к сравнению через i;octet; неопределённость активного компаратора тоже может включить этот fallback. При сортировке успешно преобразованные и допустимые строки упорядочиваются активным правилом. Ошибочные и недопустимые строки отделяются, сортируются через i;octet и добавляются после корректной группы.

Пользователь всё равно увидит аккуратный единый список. Однако верхняя часть могла быть упорядочена лингвистически, а нижняя — по октетам. Сообщение могло попасть в SEARCH не потому, что выбранный компаратор его сопоставил, а потому, что после сбоя сработал запасной путь. Внешний вид не показывает это происхождение.

Полноценная квитанция запроса должна хранить поколение корпуса, поле, результат MIME-декодирования, заявленную кодировку, исход преобразования, запрошенный и активный компараторы, причину fallback и точный состав либо порядок результата. Перечень номеров сообщений без этих данных не позволяет проверить вывод.

Один и тот же корпус не гарантирует один ответ

Два соответствующих стандарту сервера могут иметь равные сообщения, но разные наборы кодировок, установленные компараторы или обработку неопределённых случаев. После обновления одной системы может смениться библиотека декодирования или collation. Результат тогда изменится без изменения писем.

Это не произвол протокола. Это требование точнее описывать условия воспроизводимости. Помимо текста запроса нужны версия и политика сервера, объявленные capabilities, защитное поколение сеанса, активный компаратор, путь декодирования и версия корпуса. Без этих связей запись «поиск ничего не нашёл» не различает отсутствие письма и неспособность конкретного пути правильно понять текст.

Реестр IANA по-прежнему содержит LANGUAGE, I18NLEVEL=1 и I18NLEVEL=2 со ссылкой на RFC 5255. Реестр подтверждает имена и нормативные источники. Он не показывает распространённость функции, качество конкретной реализации или совпадение версий компаратора в разных системах.

Более поздний UTF-8 не стирает границы полномочий

RFC 5255 не делает все идентификаторы IMAP международными. Спецификация прямо отмечает, что расширения используют UTF-8, но не для идентификаторов. Позднее RFC 6855 добавил поддержку UTF-8 для имён пользователей, почтовых адресов, заголовков и работы с именами ящиков. RFC 9051 затем заменил IMAP4rev1 как базовую версию протокола.

Эта эволюция подчёркивает исходную границу. Переведённый ответ, локализованный префикс для показа, настоящее UTF-8-имя ящика и нормализованный поисковый термин могут выглядеть одинаково, но действуют в разных слоях. Совпадение письменности не означает совпадения идентичности.

Поэтому архитектуре вредно иметь единое поле locale, которое одновременно управляет представлением, адресацией, сравнением и доверием к каналу. Каждое решение требует собственной области, источника и поколения. Связи должны быть обратимыми: от экрана нужно вернуться к каноническому имени, а от выдачи — к правилам и преобразованиям, которые её создали.

Дисциплина слоёв реальности Лу Хэна даёт руководству практический принцип. Интерфейсная строка реальна в слое представления. Почтовый ящик реален в пространстве имён. Результат реален для конкретного компаратора и конвейера декодирования. Защищённый канал имеет отдельное основание доверия. Ошибка начинается тогда, когда один слой без доказательства получает право удостоверять другой.

Источники