דילוג לתוכן
Dialova

תיעוד IRC · מתקדמים

משא ומתן על יכולות עם CAP

משא ומתן CAP מאפשר לבחור הרחבות שהלקוח יודע לעבד. רשימת השרת היא הצעה, ולא הפעלה אוטומטית. מכונת מצבים נכונה חיונית כשמעורבים SASL או רשימת יכולות מפוצלת.

צוות Dialova · נבדק בתאריך

קבלת הרשימה המלאה #

CAP LS 302 מבקשת את הפרסום המודרני. השרת עשוי לשלוח כמה שורות; פרמטר * אחרי LS מסמן שתגיע שורה נוספת. יש לאסוף את הרשימה לפני שמחליטים. ערך כמו sasl=PLAIN,EXTERNAL מתאר מנגנונים; שם היכולת שמבקשים הוא עדיין sasl.

תעבורת IRC:‏ C = לקוח, S = שרת
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

הפעלת יכולות שהלקוח מבין בלבד #

הלקוח בוחר רשימה ושולח CAP REQ. תשובת ACK מאשרת הפעלה; NAK דוחה את הבקשה. אין להתייחס ליכולת שרק פורסמה כפעילה. אין להעתיק ערכי LS ל־REQ בלי להבין אותם.

תעבורת IRC:‏ C = לקוח, S = שרת
C: CAP REQ :server-time sasl
S: :irc.example CAP Alice ACK :server-time sasl

במהלך הרישום לחיבור, CAP משהה את השלמתו. מבצעים את האימות הנדרש ואז שולחים CAP END להמשך. הממשק אינו אמור להכריז ״מחובר״ רק משום שחיבור TLS נפתח.

אחרי הרישום ובמקרה של שינוי #

CAP LIST מציגה את היכולות הפעילות. אפשר להשתמש ב־CAP REQ גם אחרי הרישום. הודעות CAP NEW ו־CAP DEL שייכות למנגנון cap-notify: שירות שאינו זמין עשוי לשנות את הצעת השרת. הלקוח חייב לעדכן את מצבו, ולא להמשיך כאילו יכולת שהוסרה עדיין פועלת.

מול שרת ישן שאינו מבין CAP, לקוח יכול לתכנן מסלול חיבור רגיל. אם המדיניות מחייבת אימות לפני גישה, חיבור שמדלג עליו בשקט אינו פתרון קביל.

דוגמה להשפעה ממשית #

ב־Ergo, הפעלת היסטוריה מפורשת יכולה לבטל החזרה אוטומטית של הודעות שהוחמצו. לקוח שמצהיר על היכולת חייב לטפל בהתאוששות הנדרשת, ולא רק לזהות את שמה. Dialova שומר לאחר מכן את ההודעות הפרטיות באתר בהיסטוריה משלו: אחריות השרת ואחריות היישום נפרדות.

מקורות ובדיקת המידע

הדוגמאות משתמשות בכינויים ובדומיינים בדויים, למעט כתובות חיבור שמתועדות במפורש. הרחבות והגדרות ייחודיות לרשת מצוינות בטקסט.