Aller au contenu
Dialova

Documentation IRC · Avancé

Négocier les capacités avec CAP

La négociation CAP permet de choisir les extensions qu’un client sait traiter. La liste du serveur est une proposition, pas une activation automatique. Une machine d’état correcte reste essentielle lorsque SASL ou une liste de capacités fractionnée intervient.

Équipe Dialova · Vérifié le

Découvrir la liste complète #

CAP LS 302 demande l’annonce moderne. Un serveur peut envoyer plusieurs lignes ; un paramètre * après LS indique qu’une autre ligne suivra. Accumulez la liste avant de décider. Une valeur comme sasl=PLAIN,EXTERNAL décrit des mécanismes ; le nom à demander reste sasl.

Échange IRC : C = client, S = serveur
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

Activer seulement ce qui est compris #

Le client choisit une liste et envoie CAP REQ. ACK confirme l’activation ; NAK refuse la demande. Ne traitez pas une capacité simplement annoncée comme active. Les valeurs reçues dans LS ne se recopient pas aveuglément dans REQ.

Échange IRC : C = client, S = serveur
C: CAP REQ :server-time sasl
S: :irc.example CAP Alice ACK :server-time sasl

Pendant l’inscription, CAP suspend sa finalisation. Effectuez l’authentification prévue, puis envoyez CAP END pour permettre la suite. Une interface ne doit pas annoncer « connecté » seulement parce que la socket TLS est ouverte.

Après inscription et en cas de changement #

CAP LIST permet de voir les capacités actives. CAP REQ peut également servir après inscription. Les notifications CAP NEW et CAP DEL relèvent du mécanisme cap-notify : un service indisponible peut modifier ce que le serveur propose. Le client doit revoir son état, pas continuer comme si une capacité retirée fonctionnait toujours.

Sur un serveur ancien ne comprenant pas CAP, un client peut prévoir un chemin de connexion classique. Si une politique exige une authentification avant accès, une connexion silencieusement dégradée n’est pas une solution acceptable.

Un exemple réel de conséquence #

Sur Ergo, négocier l’historique explicite peut désactiver le renvoi automatique des messages manqués. Un client qui annonce cette capacité doit donc prendre en charge la reprise attendue, et pas seulement reconnaître son nom. Dialova conserve ensuite ses PV Web dans son propre historique : les responsabilités du serveur et de l’application restent distinctes.

Sources et vérification

Les exemples utilisent des pseudos et domaines fictifs, sauf les points de connexion explicitement documentés. Les extensions et réglages propres à un réseau sont signalés dans le texte.