Zum Inhalt springen
Dialova

IRC-Dokumentation · Experten

Capabilities mit CAP aushandeln

Mit CAP wählt ein Client Erweiterungen aus, die er verarbeiten kann. Die Serverliste ist ein Angebot, keine automatische Aktivierung. Besonders bei SASL oder mehrteiligen Capability-Listen ist eine korrekte Zustandsverwaltung entscheidend.

Dialova-Team · Überprüft am

Die vollständige Liste ermitteln #

CAP LS 302 fordert die moderne Capability-Ankündigung an. Der Server kann mehrere Zeilen senden. Ein Parameter * nach LS zeigt an, dass eine weitere Zeile folgt. Sammle zuerst die vollständige Liste. Ein Wert wie sasl=PLAIN,EXTERNAL beschreibt Mechanismen; der anzufordernde Capability-Name bleibt sasl.

IRC-Austausch: C = Client, S = Server
C: CAP LS 302
C: NICK Alice
C: USER alice 0 * :Alice
S: :irc.example CAP * LS * :message-tags server-time
S: :irc.example CAP * LS :batch sasl=PLAIN,EXTERNAL

Nur unterstützte Funktionen aktivieren #

Der Client wählt eine Liste und sendet CAP REQ. ACK bestätigt die Aktivierung, NAK lehnt die Anfrage ab. Eine lediglich angekündigte Capability darf nicht als aktiv behandelt werden. Übernimm Werte aus LS nicht ungeprüft in REQ.

IRC-Austausch: C = Client, S = Server
C: CAP REQ :server-time sasl
S: :irc.example CAP Alice ACK :server-time sasl

Während der Anmeldung hält CAP deren Abschluss an. Führe die vorgesehene Authentifizierung durch und sende anschließend CAP END, damit die Anmeldung weitergehen kann. Eine Oberfläche darf nicht allein deshalb „verbunden“ anzeigen, weil die TLS-Verbindung geöffnet ist.

Nach der Anmeldung und bei Änderungen #

CAP LIST zeigt die aktiven Capabilities an. CAP REQ kann auch nach der Anmeldung verwendet werden. CAP NEW und CAP DEL gehören zum Mechanismus cap-notify. Wird ein Dienst nicht verfügbar, kann sich das Angebot des Servers ändern. Der Client muss seinen Zustand anpassen, statt eine entfernte Capability weiter als funktionsfähig zu behandeln.

Für ältere Server ohne CAP-Unterstützung kann ein Client einen klassischen Verbindungsablauf vorsehen. Verlangt die Zugangsrichtlinie eine Authentifizierung, ist eine unbemerkt ohne sie fortgesetzte Verbindung keine zulässige Ausweichlösung.

Ein konkretes Beispiel für die Folgen #

Bei Ergo kann die Aushandlung expliziter Verlaufsabfragen die automatische Nachlieferung verpasster Nachrichten deaktivieren. Ein Client, der diese Capability aushandelt, muss deshalb auch die erwartete Wiederaufnahme implementieren, statt nur den Namen zu kennen. Dialova speichert seine Web-Privatgespräche zusätzlich im eigenen Verlauf. Die Zuständigkeiten von IRC-Server und Anwendung bleiben getrennt.

Quellen und Überprüfung

Die Beispiele verwenden erfundene Nicknames und Domains. Ausgenommen sind ausdrücklich dokumentierte Verbindungsadressen. Netzwerkspezifische Erweiterungen und Einstellungen werden im Text gekennzeichnet.