Zusammenfassung

  • Der individuelle Entwurf vom 28. Oktober beschreibt, wie Dialoge und Aufgaben mehrerer Agenten einem Auftrag zugeordnet werden. Nicht jeder tatsächlich beteiligte Agent und jeder Dialog gehören zum gemeinsam verwalteten Verzeichnis dieser Verbindungen.
  • Die Kernpflicht liegt bei der übernommenen Verbindung: Ändert sich die Anforderung, muss der zuständige Vermittler die betroffenen Aufgaben erreichen. Kann er das nicht, soll der Fehler sichtbar werden. Die Namen privater Nachunternehmer muss er dafür nicht offenlegen.

Eine verschlossene Tür ist kein Papierkorb

Im Beispiel des Entwurfs spricht der Auftraggeber im Dialog D1 mit seinem ersten Gegenüber. Dieses gibt eine abhängige Aufgabe im Dialog D2 an Agent A, der im Dialog D3 mit Agent B arbeitet. Ändert der Auftraggeber seine Anforderung, müssen die übernommenen Verbindungen die Nachricht zu den betroffenen Aufgaben bringen. Sonst arbeitet B womöglich weiter nach der alten Vorgabe, und der Kunde erhält das falsche Ergebnis. Ein weiterer Dialog D5 ohne solche Abhängigkeit braucht keine Rundmail.

Die unscheinbare Arbeit dahinter ist eine Zuordnungstabelle. Eine Aufgabenkennung in D1 bezeichnet in D2 nicht automatisch dieselbe Sache. Ein Vermittler, der beide Seiten kennt, muss die Beziehung erhalten oder die Kennungen übersetzen. Fällt diese Zuordnung aus, kann die Oberfläche weiterhin „eine Aktivität“ anzeigen, obwohl Agent B nach der alten Anweisung arbeitet. Der Auftraggeber erhält dann womöglich ein Ergebnis für die überholte Aufgabe; der Integrator muss erklären können, an welcher Übergabe die Änderung hängen blieb.

Der Entwurf lässt B Arbeit an C delegieren, ohne C in das gemeinsame Korrelationsprotokoll einzuschreiben. Dessen verwalteter Bereich umfasst nur die Verbindungen, deren Pflege die Beteiligten darin tatsächlich übernommen haben. B kann die Brücke zu C lokal halten und C verborgen lassen. Das Protokoll kann C keine Pflicht auferlegen. B muss die von B übernommenen Verbindungen trotzdem pflegen. Diskretion schützt die private Abzweigung; sie löscht nicht die übernommene Übergabe.

Für die angenommene Übergabe muss B nur die nötige Zuordnung weitergeben. Eine Referenz auf den Gesamtauftrag kann reichen; Kundenname, interne Regeln und Gesprächsverlauf können zurückbleiben. Empfangene Angaben müssen nicht vollständig weitergereicht werden. Fehlt dadurch aber die Grundlage der zugesagten Zuordnung, verlangt das Modell einen erkennbaren Fehler statt endloses Warten. Eine Kennung für den Zusammenhang ist auch keine Vollmacht.

Laut IETF-Datatracker ist dies weiterhin ein individueller Entwurf. Er liefert weder ein Wire-Protokoll noch Betriebsergebnisse. Im Abschnitt „Failure Visibility and Bounded Accountability“ steht noch TBD. Als Nächstes braucht es einen nachprüfbaren Nachweis, wer welche Beziehung übernommen hat, wie eine Änderung durchgereicht wird und welchen Fehler die Gegenseite sehen kann.

Quellen: Originalentwurf; IETF-Status.