Résumé

  • Dans RFC 3529, une faute XML-RPC voyageait dans la réponse BEEP RPY, et non dans ERR : le transport de la réponse pouvait réussir tandis que l’appel échouait.
  • L’adresse résolue, le canal prêt, la confidentialité et l’identité du pair ne prouvaient ni l’autorisation de la méthode, ni son effet durable.

Imaginons un journal qui affiche trois réussites : connexion établie, ressource reconnue, RPY reçu. Un quatrième champ, enfoui dans le document XML, contient la faute applicative. RFC 3529 obligeait précisément l’observateur à conserver ce quatrième champ. Sa convention la plus instructive était de ne pas traduire une faute XML-RPC en erreur BEEP.

Le profil s’ouvrait en état boot. Le client proposait un canal et envoyait bootmsg avec une ressource. Le serveur répondait bootrpy s’il reconnaissait cette ressource ; le profil passait alors à ready. Une demande mal formée ou une ressource inconnue produisait error ou ERR, sans changement d’état. Cette erreur appartenait au démarrage du profil, pas à l’exécution d’une méthode XML-RPC.

Une fois ready, le client plaçait methodCall dans MSG. Le serveur achevait l’échange un-à-un avec RPY, qui contenait methodResponse. La spécification insistait : même une faute XML-RPC devait revenir dans RPY. Ainsi, RPY attestait une correspondance entre requête et réponse au niveau BEEP. Le succès ou l’échec de la procédure restait une propriété du contenu XML.

Ce partage évitait une ambiguïté entre deux espaces d’erreur. ERR pouvait signaler que le profil, la ressource ou l’échange BEEP ne pouvait pas fonctionner. La structure de faute XML-RPC signalait que l’application avait compris suffisamment l’appel pour formuler un résultat négatif. Fusionner les deux supprimait une information utile : l’infrastructure avait peut-être parfaitement livré le verdict de refus.

Le chemin commençait encore plus tôt. L’URI xmlrpc.beep fournissait une autorité et un chemin. L’autorité alimentait serverName, le chemin devenait la ressource du message de démarrage. Sans port explicite, le mécanisme SRV cherchait _xmlrpc-beep._tcp, puis utilisait la résolution d’adresse et le port attribué si aucun enregistrement convenable n’était trouvé. Une résolution correcte n’était qu’une sélection de destination, pas une preuve qu’un service écoutait.

Avec xmlrpc.beeps, le même algorithme de destination restait en place, mais la session devait être réglée pour la confidentialité avant le lancement du profil XML-RPC. Sous TLS, le client comparait l’autorité de l’URI à l’identité du certificat. Cette opération pouvait établir un canal protégé vers le serveur attendu. Elle ne décidait pas si un compte avait le droit d’appeler une méthode, si les paramètres respectaient une règle métier ou si une écriture survivait à une panne.

La section sécurité montre aussi son époque. Elle exigeait DIGEST-MD5 et un profil TLS utilisant RSA avec 3DES. Les textes ultérieurs sur SASL et TLS ont déplacé ces choix dans l’histoire. Citer RFC 3529 aujourd’hui comme recette cryptographique serait une erreur de temporalité ; l’intérêt durable du document réside dans la séparation de ses preuves.

Les enregistrements IANA gardent cette même portée limitée. Un profil BEEP, deux schémas d’URI et le service xmlrpc-beep sur le port TCP 602 constituent un vocabulaire coordonné. Ils ne démontrent ni adoption, ni écoute active, ni conformité, ni exécution d’une méthode. Le registre décrit les symboles disponibles ; le code en fonctionnement produit les faits d’exécution.

Cette architecture se situait dans un moment où BEEP proposait une session structurée à plusieurs profils et canaux, tandis que XML-RPC et SOAP transportaient des appels applicatifs en XML. RFC 3080 définissait le cadre de session ; RFC 3081 répartissait le débit entre canaux ; RFC 3288 réalisait une opération comparable pour SOAP. RFC 3529 ajoutait une décision propre : ne pas confondre le type de trame BEEP avec la valeur applicative de la réponse.

Pour auditer un appel, il fallait donc relier l’autorité, l’adresse choisie, l’identité du pair, le numéro de canal, la ressource, le numéro de message, le type de trame, puis la forme du methodResponse. Une méthode qui modifiait un état exigeait enfin une preuve appartenant à l’application : identifiant d’opération, version, lecture ultérieure ou trace durable.

Le traitement des reprises dépendait de cette chaîne. Une coupure avant la réponse laissait indéterminé le sort de l’appel. Un RPY contenant une faute indiquait un résultat négatif explicite, mais ne garantissait pas l’absence de tout effet partiel si la sémantique de la méthode ne le disait pas. Une relance automatique sans règle d’idempotence pouvait donc transformer une simple lacune d’observation en double action.

RFC 3529 était expérimental. Il ne prouve pas que ce transport ait gagné. Il montre mieux : une couche peut réussir à rapporter l’échec d’une autre. L’ingénierie devient trompeuse lorsque le tableau de bord conserve la couleur de l’enveloppe et jette son contenu.

Sources