Кратко

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

Обе стороны соединения редко обновляются одновременно. Некоторое время новая программа должна слышать прошлое, не выбирая его языком своей выдачи. Восьмистраничный RFC 2062 сделал эту разницу явной.

Документ имел статус Informational и прямо не объявлял себя интернет-стандартом. Он собрал синтаксис из RFC 1176, экспериментальных вариантов IMAP2bis и RFC 1730 после того, как IMAP4rev1 вынес его из основного текста. Историческая запись сохранилась, но не право на штатное производство.

В перечень вошли FIND ALL.MAILBOXES, FIND MAILBOXES, SUBSCRIBE MAILBOX, UNSUBSCRIBE MAILBOX, PARTIAL и старые элементы FETCH вроде BODY[0] и RFC822.HEADER.LINES. Новый сервер не обязан был их реализовывать. Он мог сделать это ради старого клиента, но добровольный мост не превращался в рекомендацию новым клиентам.

PARTIAL показывает, что замена была не косметической. Данные возвращались в FETCH-ответе без указания диапазона. Несколько команд могли выполняться не по порядку, поэтому клиенту приходилось обрабатывать и синхронизировать каждый шаг. Новая частичная выборка могла сохранять назначение, но давать более ясную связь между запросом и результатом.

Для устаревших ответов действовали разные правила. Новый сервер обычно не должен был их отправлять. MAILBOX допускался только в ответ на старый FIND. Клиент обязан был игнорировать экспериментальный COPY, а STORE трактовать как FETCH. Совместимость на входе означала условный разбор, безопасное отбрасывание или нормализацию, но не безусловное доверие.

RFC 2683 позднее предупредил: если терпимый сервер принимает старую команду, это не делает её отправку правильной. RFC 2061 тоже отделил советы по совместимости от требований базового IMAP и рекомендовал не возвращать команды bboard даже ради старых клиентов. Терпимость служила выходу, а не продлению.

RFC 3501 сохранил RFC 2062 как исторический контекст. RFC 9051 сделал выбор IMAP4rev1 или IMAP4rev2 видимым через возможности и ENABLE IMAP4rev2. Сервер с обеими версиями обычно не выдаёт удалённые формы без соответствующего запроса клиента rev1. Это поздняя инженерная параллель, а не доказательство прямой причинности.

В эксплуатации успешный тест парсера доказывает только возможность приёма, но не настройку выдачи. Терпимость к FIND не означает, что клиент должен его посылать. Регистрация возможности в IANA не доказывает внедрение или байты конкретного сеанса.

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

Источники