Résumé

  • RFC 3676 a ajouté DelSp pour distinguer l’espace réel conservé à une coupure de texte « flowed » de celui que l’émetteur insère uniquement pour signaler une continuation.
  • La valeur par défaut est no. Pour couper dans une langue qui utilise peu ou pas l’espace ASCII, la méthode récente exige DelSp=yes, afin que le destinataire retire le marqueur et n’ajoute pas un caractère au texte reconstitué.

À la fin d’une ligne, une espace peut raconter deux histoires. Dans text/plain; format=flowed, elle peut signifier que le paragraphe continue sur la ligne suivante. Mais cette espace appartenait-elle au texte, entre deux mots, ou a-t-elle été ajoutée par le logiciel pour marquer une coupure souple ? Publiée en 2004, la RFC 3676 a rendu cette différence explicite grâce à DelSp. Elle remplace la RFC 2646 tout en conservant le principe du texte réagencé à l’affichage. (§§4–4.2.)

La méthode ancienne ne coupait qu’à un endroit où un espace séparait déjà deux mots. L’émetteur plaçait CRLF après cet espace ; à la réception, le client réunissait les lignes physiques sans supprimer le séparateur. La RFC recommande alors DelSp=no. L’espace est du contenu d’origine, pas une instruction de mise en page : le raccordement ne doit donc pas l’effacer.

Cette méthode ne suffit pas lorsque la langue écrite n’emploie pas, ou emploie rarement, l’espace ASCII. Il n’existe alors pas toujours de séparation naturelle où couper. La nouvelle méthode insère SP CRLF au point choisi. L’espace final marque la continuation ; avec DelSp=yes, le destinataire retire cet espace précis en réunissant les lignes. S’il le gardait, la transformation de présentation introduirait un caractère absent de la séquence initiale. Pour cette méthode, la RFC exige que l’émetteur indique explicitement DelSp=yes. Il ne s’agit pas d’une détection automatique de langue : le paramètre annonce la règle d’encodage utilisée. (§§4.1–4.2.)

L’absence du paramètre a une conséquence définie. Si DelSp manque ou si sa valeur n’est pas reconnue, le destinataire suppose no. Employé sans Format=Flowed, le paramètre est indéfini ; hors de text/plain; format=flowed, les destinataires DEVRAIENT l’ignorer. Un client ne doit donc pas deviner qu’une espace finale est synthétique. Ce défaut prudent garde l’interprétation historique, mais ne reconstitue pas l’intention si la métadonnée requise a été perdue.

Le côté de la coupure compte aussi. Insérer un marqueur juste avant un espace d’origine transforme ce dernier en premier caractère de la ligne suivante. Le mécanisme de « space-stuffing » protège précisément les lignes qui commencent par une espace, > ou From . La RFC recommande donc d’insérer SP CRLF après l’espace préexistant. On conserve ainsi le séparateur lexical et le marqueur de coupure comme deux éléments distincts. (§§4.2, 4.4.)

La portée est étroite : RFC 3676 décrit un format sur le fil pour text/plain, pas le stockage local d’un fichier. L’encodage de transfert MIME est une autre couche. La norme précise aussi l’ordre entre préparation du texte, signature et réagencement ; ce sujet cryptographique appartient à l’analyse distincte de RFC 2646 et n’est pas repris ici. Enfin, une règle normative ne prouve pas le comportement d’un logiciel nommé. La lentille du Note 65 de Lu Heng rappelle de distinguer la conception écrite du « running code » observé. Pour savoir ce qu’un client a réellement affiché, il faudrait des versions identifiées et des messages capturés.

Sources

  • RFC 3676, notamment §§4.1–4.2 et l’appendice A.
  • RFC 2646, spécification antérieure du texte flowed.
  • RFC 2046, cadre des types MIME.
  • RFC 2045, contexte des corps de message et du codage de transfert MIME.
  • Lu Heng, Note 65, lentille analytique déclarée, non preuve d’implémentation.