Résumé

  • Deux clients nommés par RFC 1957 échouaient si aucune espace ne suivait l’indicateur d’état, alors que RFC 1939 autorisait la réponse courte.
  • Netscape exigeait UIDL et Eudora TOP, deux commandes classées facultatives par RFC 1939.
  • Une implémentation répandue peut ainsi imposer une compatibilité pratique sans modifier formellement la norme.

Le serveur UCB popper, ensuite développé par Qualcomm, accompagnait toujours l’indicateur d’état d’informations supplémentaires. Son +OK ou son -ERR était donc toujours suivi d’une espace. Ce choix ne posait aucun problème au serveur et pouvait même sembler utile à l’humain qui lisait la réponse.

La fragilité se trouvait de l’autre côté. RFC 1957 indique que le client Unix librement copiable popclient et le produit propriétaire netApp Systems Internet Series attendaient cette espace et échouaient lorsqu’elle n’était pas présente. Or RFC 1939 ne l’imposait pas lorsqu’aucun texte ne suivait. L’implémentation la plus courte pouvait respecter le protocole tout en perdant l’interopérabilité.

Ce détail révèle une hiérarchie concurrente. Le texte définit plusieurs réponses admissibles. Une implémentation très présente n’en émet qu’une. Les clients, testés surtout contre elle, apprennent à n’en accepter qu’une. La diversité autorisée disparaît alors sans vote, sans nouvelle exigence normative et sans même une décision explicite.

La réponse de RFC 1957 est pragmatique mais limitée. Les auteurs des deux clients avaient été contactés et les nouvelles versions ne devaient plus dépendre de l’espace. Les anciennes versions, toutefois, devaient être prises en charge. Corriger l’avenir n’efface pas instantanément le parc installé. Un opérateur doit parfois reproduire une anomalie connue tout en organisant sa disparition.

Le même phénomène apparaît au niveau des fonctions. RFC 1939 range TOP et UIDL parmi les commandes facultatives. RFC 1957 observe pourtant que Netscape exigeait UIDL et qu’Eudora exigeait TOP. Il ne s’agit pas ici d’expliquer la fonction de ces commandes : l’enjeu est l’accès. Une option du serveur devenait, par l’attente d’un client populaire, une condition pratique pour servir ses utilisateurs.

À cette époque, la découverte des capacités était faible. RFC 1939 ne donnait pas de méthode générale pour distinguer l’absence d’une commande facultative d’un refus temporaire ou contextuel. RFC 2449 décrira ensuite les options comme détectables seulement par essai, si elles l’étaient, puis introduira CAPA pour annoncer notamment TOP et UIDL. Cette évolution rend le contrat plus visible ; elle ne prouve ni que RFC 1957 l’a causée, ni que tous les logiciels l’ont adoptée.

La portée de la preuve doit rester exacte. RFC 1957 est une note informationnelle de juin 1996 qui met à jour RFC 1939, publié le mois précédent sur la voie des normes. Elle cite des logiciels précis, pas une population statistique. Elle ne mesure ni parts de marché, ni durée des pannes, ni coût. Elle ne transforme pas l’espace, TOP ou UIDL en obligations normatives.

Sa force historique vient de ce refus d’exagérer. Le document montre comment une obligation opérationnelle peut naître entre les lignes : le serveur courant produit un surplus stable, le client courant le consomme comme une nécessité, puis tout nouvel arrivant doit choisir entre le texte et le monde. Le code en fonctionnement dit où se trouve la dépendance ; il ne suffit pas à dire où doit se trouver l’autorité.

Sources