Résumé

  • DATA se terminait sur une ligne composée d'un point ; la même ligne dans le message exigeait une règle réversible.
  • L'émetteur doublait tout point initial, le récepteur reconnaissait le terminateur solitaire et retirait un point ailleurs.
  • CHUNKING encadra plus tard les données par un nombre exact d'octets et un dernier bloc explicite, déplaçant l'autorité vers le comptage.

Un flux devait changer de rôle

Le dialogue de RFC 821 alterne commandes et réponses. DATA transforme temporairement le même flux ordonné en contenu. Il faut donc un point indiscutable où le message finit et où le dialogue reprend.

Le marqueur choisi, une ligne avec un seul point, était lisible et facile à implémenter. Mais il appartenait aussi au vocabulaire possible du texte humain : une donnée ordinaire pouvait ressembler au contrôle.

La transparence engageait les deux côtés

L'émetteur examine chaque ligne et ajoute un point lorsque le premier caractère en est déjà un. Le récepteur traite le point solitaire comme fin de DATA et retire le premier point des autres lignes concernées.

Le message sur le fil diffère du message livré, mais l'opération est réversible. RFC 821 insistait sur cette propriété, surtout lorsque des relais appliquent des transformations. Un côté protège l'ambiguïté ; l'autre l'interprète et restaure le contenu.

Le petit point entra dans toute la chaîne

RFC 5321 conserve la procédure et précise que le point ajouté ne compte pas dans la limite de 1000 octets d'une ligne. Tampons, relais, journaux et tests doivent donc savoir s'ils voient le message stocké, sa forme canonique ou sa forme transparente sur le réseau.

Les octets remplacèrent la ligne interdite

RFC 3030 définit CHUNKING et la commande BDAT. Chaque commande annonce le nombre exact d'octets suivants ; LAST désigne le dernier bloc. Le contenu n'est plus recherché pour un terminateur, donc une ligne-point perd sa signification spéciale.

Ce n'est pas un remplacement universel. Le serveur annonce CHUNKING avec EHLO, le client n'emploie BDAT qu'après accord et le serveur doit encore accepter DATA. La nouvelle capacité s'ajoute sans redéfinir les anciens pairs.

Compter devint l'acte souverain

Une taille erronée déplace la frontière. Des octets peuvent être absorbés dans le bloc ou présentés au parseur de commandes. BINARYMIME dépend donc de CHUNKING : des octets arbitraires ne peuvent reposer sur le marqueur orienté ligne de DATA.

La confiance n'a pas disparu. Elle a quitté la transformation du contenu pour le calcul exact et la négociation préalable.

Sources et limites

Les règles viennent de RFC 821, RFC 5321 et RFC 3030. Ces textes ne mesurent pas le déploiement. DATA reste obligatoire, et la transparence n'est ni chiffrement ni authentification.