Кратко

  • RFC 3676 добавил DelSp, чтобы отличать пробел, изначально разделявший слова, от пробела, который отправитель вставляет только как метку мягкого переноса.
  • Значение по умолчанию — no. При новом способе переноса текста на языках, где ASCII-пробел редок или отсутствует, отправитель обязан указать DelSp=yes, чтобы получатель удалил метку и не добавил лишний символ в восстановленную строку.

Пробел в конце строки может иметь две разные истории. В text/plain; format=flowed он может сообщать, что абзац продолжается на следующей физической строке. Но стоял ли этот пробел между словами в исходном тексте или почтовая программа добавила его как метку переноса? Опубликованный в 2004 году RFC 3676 сделал это различие явным с помощью DelSp. Документ заменил RFC 2646, сохранив flowed-текст и добавив правило восстановления мягкого переноса. (§§4–4.2.)

Старый метод позволял переносить строку только там, где уже был пробел между словами. Отправитель ставил CRLF после этого пробела, а получатель при соединении физических строк сохранял разделитель. Для такого метода RFC рекомендует DelSp=no: пробел относится к исходному содержимому, а не к разметке, которую надо удалить.

В языках и системах письма, где ASCII-пробел встречается редко или не используется, естественного места для переноса может не быть. Новый метод позволяет вставить SP CRLF в выбранной точке. Конечный пробел помечает продолжение; при DelSp=yes получатель удаляет именно эту метку, соединяя строки. Если оставить её, преобразование отображения добавит символ, которого не было в исходной последовательности. Поэтому RFC 3676 требует DelSp=yes для этого способа. Параметр не определяет язык автоматически — отправитель объявляет выбранное правило кодирования. (§§4.1–4.2.)

Для отсутствующего параметра правило тоже определено. Если DelSp не указан или его значение неизвестно, получатель считает его равным no. Использование DelSp без Format=Flowed не определено; вне text/plain; format=flowed получателям следует его игнорировать. Клиент не должен угадывать, что конечный пробел искусственный. Значение по умолчанию сохраняет прежнюю интерпретацию, но не возвращает намерение отправителя, если нужные метаданные потеряны.

Имеет значение и место вставки. Если добавить метку прямо перед исходным пробелом, тот станет первым символом следующей строки. Flowed-текст защищает строки, начинающиеся с пробела, > или From , с помощью space-stuffing; неудачный выбор позиции запускает дополнительную обработку. RFC 3676 рекомендует вставлять SP CRLF после уже существующего пробела. Тогда разделитель слов и новая метка переноса остаются разными элементами. (§§4.2, 4.4.)

Область стандарта узкая: RFC 3676 описывает передаваемый по сети формат text/plain, а не хранение локального файла. Content-transfer encoding относится к другому уровню. Документ также определяет порядок подготовки flowed-текста, подписи или шифрования и последующего отображения; криптографическая тема закреплена за отдельной работой о RFC 2646 и здесь не повторяется. Сам текст стандарта не доказывает, что конкретный почтовый клиент соблюдал правила. Подход Note 65 Лу Хэна требует различать написанную спецификацию и наблюдаемое поведение работающего кода. Чтобы утверждать, что увидел пользователь, нужны версии программы и захваченные сообщения.

Источники

  • RFC 3676, прежде всего §§4.1–4.2 и приложение A.
  • RFC 2646, прежняя спецификация flowed-текста.
  • RFC 2046, структура типов MIME.
  • RFC 2045, контекст тела сообщения и MIME-кодирования передачи.
  • Лу Хэн, Note 65, раскрытая аналитическая перспектива, а не доказательство реализации.