Zusammenfassung

  • RFC 3529 legte normale XML-RPC-Ergebnisse und XML-RPC-Faults gleichermaßen in BEEP RPY; ERR war nicht der Kanal für den Anwendungsfehler.
  • Namensauflösung, ein bereiter Kanal, Vertraulichkeit und Peer-Authentisierung bewiesen weder Methodenberechtigung noch Ausführung oder dauerhafte Wirkung.

Die aufschlussreichste Entscheidung dieses Experimental RFC betraf nicht XML-Syntax, sondern Fehlerzuordnung. Ein Client sandte methodCall in BEEP MSG. Der Server antwortete mit methodResponse in RPY. Selbst wenn diese Antwort einen XML-RPC-Fault enthielt, blieb die äußere BEEP-Nachricht RPY.

Damit bestätigte RPY den Abschluss des BEEP-Austauschmusters. Es bestätigte nicht den Erfolg der entfernten Prozedur. Wer nur den Frame-Typ protokollierte, konnte einen sauber gemeldeten Fehler als erfolgreichen Aufruf verbuchen. Die eigentliche Entscheidung lag im XML-Inhalt.

Schon die Initialisierung besaß eine eigene Grenze. Das Profil begann in boot. bootmsg benannte eine Ressource. Erkannte der Server sie, antwortete er mit bootrpy, und der Zustand wurde ready. Bei fehlerhafter Nachricht oder unbekannter Ressource folgte error oder ERR; der Zustand blieb unverändert. Dieser Fehler betraf Profil und Ressource, nicht die spätere Methode.

Auch ready war kein Funktionsbeweis. Es zeigte, dass der Kanal an eine bekannte Ressource gebunden war. Ob ein Methodenname existierte, der Aufrufer berechtigt war, Parameter gültig waren oder eine Änderung gespeichert wurde, entschied weiterhin die Anwendung.

Die URI legte den äußeren Pfad fest. Bei xmlrpc.beep wurde die Authority zum BEEP-serverName, der Pfad zur Boot-Ressource. Ohne expliziten Port konnte _xmlrpc-beep._tcp per SRV gesucht werden; fehlte ein geeigneter Eintrag, folgten Adressauflösung und der zugewiesene Port. Erfolgreiches DNS wählte ein Ziel, bewies aber weder Listener noch Profil oder Methode.

xmlrpc.beeps verlangte vor dem Profilstart eine auf Vertraulichkeit abgestimmte BEEP-Sitzung. Bei TLS musste der Client die URI-Authority mit der Zertifikatsidentität vergleichen. Das verbesserte die Antwort auf die Frage nach dem geschützten Peer. Es verlieh keine Methodenberechtigung und bestätigte keinen Geschäftsvorgang.

Die Sicherheitsvorgaben tragen ihr Datum. DIGEST-MD5 und TLS mit RSA/3DES waren 2003 als Mindestprofile genannt. Spätere SASL- und TLS-Dokumente veränderten den Stand dieser Verfahren. RFC 3529 ist deshalb eine Quelle für Protokollgeschichte, nicht für aktuelle Kryptokonfiguration.

Registrierung blieb ebenfalls symbolisch begrenzt. BEEP-Profil, xmlrpc.beep, xmlrpc.beeps und xmlrpc-beep auf TCP 602 schufen gemeinsame Bezeichner. Das IANA-Register belegt Koordination, nicht Implementierung, Erreichbarkeit, Datenverkehr oder Methodenerfolg.

BEEP Core und seine TCP-Abbildung lieferten Sitzung, Kanäle, Frames und Flusssteuerung. SOAP over BEEP zeigte eine benachbarte Verwendung, XML-Medientypen beschrieben die Dokumenthülle. Das gemeinsame Transportgerüst verringerte nicht die Zahl der Beweise. Es machte vielmehr erforderlich, den Besitzer jedes Beweises festzuhalten.

Eine belastbare Ablaufspur verband Authority, gewähltes Ziel, Peer-Identität, Kanal, Ressource, Nachrichtennummer, RPY oder ERR und schließlich Normalantwort oder Fault. Bei zustandsändernden Methoden kamen Operations-ID, Version, Audit-Eintrag oder späteres Auslesen hinzu.

Besonders kritisch waren Wiederholungen. Ein Abbruch vor der Antwort ließ offen, ob die Methode lief. Ein Fault in RPY war ein ausdrückliches negatives Ergebnis, sagte ohne Methodenkontrakt aber nichts Sicheres über Teilauswirkungen. Eine nicht idempotente Wiederholung konnte aus einer Beobachtungslücke einen doppelten Effekt machen.

RFC 3529 war Experimental. Seine bleibende Aussage ist weder Marktanteil noch heutige Empfehlung. Sie lautet: Eine Schicht kann erfolgreich eine negative Entscheidung der nächsten Schicht transportieren. Gute Systeme bewahren beide Wahrheiten.

Sources