Capabilities onderhandelen met CAP

De volledige lijst opvragen #

CAP LS 302 vraagt de moderne aankondiging. De server kan meerdere regels sturen. * na LS geeft aan dat nog een regel volgt. Verzamel de hele lijst vóór je beslist. sasl=PLAIN,EXTERNAL beschrijft mechanismen. De aan te vragen naam blijft sasl.

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

Alleen begrepen functies inschakelen #

De client kiest een lijst en stuurt CAP REQ. ACK bevestigt, NAK weigert. Beschouw een alleen aangekondigde capability niet als actief. Kopieer LS-waarden niet blind naar REQ.

C: CAP REQ :server-time sasl
S: :irc.example CAP Alice ACK :server-time sasl

Tijdens registratie stelt CAP de afronding uit. Doe de vereiste authenticatie en stuur dan CAP END. Meld niet ‘verbonden’ alleen omdat de TLS-socket openstaat.

Na registratie en bij wijzigingen #

CAP LIST toont actieve capabilities. CAP REQ kan ook na registratie. CAP NEW en CAP DEL horen bij cap-notify. Onbeschikbare diensten kunnen het aanbod veranderen. Werk de clientstatus bij en neem niet aan dat een ingetrokken capability blijft werken.

Een client kan voor een oude server zonder CAP een klassieke aanmeldroute voorzien. Vereist het beleid authenticatie vóór toegang, dan is ongemerkt minder beveiligd verbinden geen acceptabele oplossing.

Een concreet gevolg #

Op Ergo kan expliciete geschiedenisonderhandeling het automatisch terugsturen van gemiste berichten uitschakelen. Een client moet het verwachte herstel dus uitvoeren, niet alleen de capabilitynaam herkennen. Dialova bewaart webprivéberichten daarnaast in eigen geschiedenis. Server en toepassing hebben verschillende verantwoordelijkheden.

• Geschiedenisgroepen begrijpen →
• Het account tijdens verbinden authenticeren →