Resumo

  • A RFC 3676 acrescentou DelSp para distinguir o espaço que já existia entre palavras daquele inserido pelo remetente apenas para marcar uma quebra suave.
  • O padrão é no. Para quebrar texto em idiomas ou conjuntos de caracteres que raramente usam o espaço ASCII, o método novo exige DelSp=yes, permitindo que o destinatário retire a marca sem acrescentar um caractere ao texto recomposto.

Um espaço no fim da linha pode contar duas histórias. Em text/plain; format=flowed, ele pode indicar que o parágrafo continua na linha física seguinte. Mas o espaço já fazia parte das palavras ou foi acrescentado pelo cliente de e-mail para marcar uma quebra? Publicada em 2004, a RFC 3676 tornou essa diferença explícita com DelSp. Ela substituiu a RFC 2646, preservando o texto refluível e definindo como o receptor deve remontar uma quebra suave. (§§4–4.2.)

O método antigo só permitia quebrar onde já havia um espaço entre palavras. O remetente inseria CRLF depois dele; ao juntar as linhas físicas, o destinatário mantinha o separador. Para esse método, a RFC recomenda DelSp=no. O espaço é conteúdo original, não um marcador de formatação a ser apagado.

Isso não resolve todos os sistemas de escrita. Em alguns idiomas e conjuntos de caracteres, o espaço ASCII é raro ou inexistente; portanto, nem sempre há um intervalo natural entre palavras para quebrar. O método novo permite inserir SP CRLF no ponto escolhido. O espaço final sinaliza a continuação e, com DelSp=yes, o destinatário remove essa marca ao juntar as linhas. Se a mantiver, a operação de apresentação introduzirá um caractere que não estava na sequência original. Por isso, a RFC 3676 exige DelSp=yes quando se usa essa técnica. O parâmetro não tenta identificar o idioma: ele declara qual regra de codificação o remetente aplicou. (§§4.1–4.2.)

A ausência do parâmetro também tem semântica definida. Se DelSp não aparecer ou seu valor não for reconhecido, o receptor assume no. Seu uso sem Format=Flowed é indefinido; fora de text/plain; format=flowed, a RFC recomenda que os destinatários o ignorem. Portanto, não cabe ao cliente adivinhar que o espaço final é sintético. O padrão conserva a leitura anterior, mas não recupera a intenção se os metadados necessários forem perdidos.

A posição do marcador também importa. Se o remetente inserir a quebra imediatamente antes de um espaço original, esse espaço passa a iniciar a próxima linha. Flowed text usa space-stuffing para proteger linhas iniciadas por espaço, > ou From ; uma escolha de posição acaba acionando outra regra. A RFC recomenda inserir SP CRLF depois do espaço já existente, mantendo separados o divisor entre palavras e a marca de quebra. (§§4.2, 4.4.)

O escopo é específico: a RFC 3676 trata do formato transmitido de text/plain, não de como arquivos locais são armazenados. Content-transfer encoding é outra camada. A especificação também descreve a ordem entre preparar o texto flowed, assinar e reformatar; a tese criptográfica pertence à cobertura separada da RFC 2646 e não é repetida aqui. Tampouco se afirma que algum cliente conhecido tenha obedecido à regra. A lente da Note 65 de Lu Heng exige distinguir norma publicada de comportamento observado em código em execução. Para saber o que usuários viram, seriam necessárias versões identificadas e mensagens capturadas.

Fontes

  • RFC 3676, em especial §§4.1–4.2 e Apêndice A.
  • RFC 2646, especificação anterior de texto flowed.
  • RFC 2046, estrutura de tipos de mídia MIME.
  • RFC 2045, contexto do corpo de mensagens e da codificação de transferência MIME.
  • Lu Heng, Note 65, lente analítica declarada, não evidência de implementação.