GNU bug report logs - #51342
29.0.50; remove non-CAPs from rcirc capability list

Previous Next

Package: emacs;

Reported by: "J.P." <jp <at> neverwas.me>

Date: Sat, 23 Oct 2021 00:09:02 UTC

Severity: minor

Tags: moreinfo

Found in version 29.0.50

Done: "J.P." <jp <at> neverwas.me>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51342 in the body.
You can then email your comments to 51342 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#51342; Package emacs. (Sat, 23 Oct 2021 00:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to "J.P." <jp <at> neverwas.me>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 23 Oct 2021 00:09:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: bug-gnu-emacs <at> gnu.org
Cc: Philip Kaludercic <philipk <at> posteo.net>
Subject: 29.0.50; remove non-CAPs from rcirc capability list
Date: Fri, 22 Oct 2021 17:08:30 -0700
[Message part 1 (text/plain, inline)]
Severity: minor

Hi Philip,

Nice job on the v3 stuff. I happened across a couple capabilities being
requested that don't officially exist, a distinction you've probably
picked up on in the course of pursuing this work [1]. The couple that
slipped by are always NAK'd but basically harmless, so you may just want
to leave 'em or otherwise go your own way. If so, please ignore this.

Thanks,
J.P.

P.S. The CTCP "KEEPALIVE" in the ergo session below jumped out at me;
just FYI in case that's of any interest.


[1] For others who may be wondering, the specs are still a bit rough
    when it comes to denoting with any consistency when an extension has
    a corresponding ("requestable") capability. For example, some
    extensions (like STS) have caps that are strictly server-only,
    meaning you, a client, shouldn't REQ them. Other caps are only
    effectively server-only, meaning it doesn't matter if you REQ them
    or not (negated or otherwise). And some extensions (like the two in
    this bug) don't offer caps at all. This has confused me enough over
    the years that I've taken to looking to other clients as well as WG
    chatter on Github for clues, which can get old pretty fast.


In GNU Emacs 29.0.50 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4)
 of 2021-10-15 built on localhost
Repository revision: ca3d7234d39fd55e6cd4521e5e583aba12434402
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Fedora 34 (Workstation Edition)

Configured using:
 'configure --enable-check-lisp-object-type --enable-checking=yes,glyphs
 --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu
 --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin
 --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share
 --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec
 --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
 --with-gpm=no --with-xwidgets --with-modules --with-harfbuzz
 --with-cairo --with-json build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu CC=gcc 'CFLAGS=-O0 -g3'
 LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
seq gv subr-x byte-opt bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads
xwidget-internal dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit
x multi-tty make-network-process emacs)

Memory information:
((conses 16 50942 5933)
 (symbols 48 6632 1)
 (strings 32 18373 2087)
 (string-bytes 1 622208)
 (vectors 16 13731)
 (vector-slots 8 186505 9804)
 (floats 8 21 35)
 (intervals 56 259 0)
 (buffers 992 10))
[0001-Don-t-request-phony-capabilities-in-rcirc.patch (text/x-patch, attachment)]
[rcirc-ergo.log (text/plain, attachment)]
[rcirc-inspircd.log (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51342; Package emacs. (Sat, 23 Oct 2021 02:00:02 GMT) Full text and rfc822 format available.

Message #8 received at 51342 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 51342 <at> debbugs.gnu.org
Cc: Philip Kaludercic <philipk <at> posteo.net>
Subject: Re: bug#51342: 29.0.50; remove non-CAPs from rcirc capability list
Date: Fri, 22 Oct 2021 18:59:12 -0700
"J.P." <jp <at> neverwas.me> writes:

> The couple that slipped by are always NAK'd but basically harmless

Not to suggest that NAK'ing implies invalidation or even a denial of
support (as in you oughtn't try again later) or really *anything* other
than what caps weren't enabled. (I'm sure this is old news, but it took
me a while to fully process, as usual.)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51342; Package emacs. (Sun, 24 Oct 2021 10:06:01 GMT) Full text and rfc822 format available.

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: "J.P." <jp <at> neverwas.me>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: 29.0.50; remove non-CAPs from rcirc capability list
Date: Sun, 24 Oct 2021 10:05:03 +0000
"J.P." <jp <at> neverwas.me> writes:

> Severity: minor
>
> Hi Philip,
>
> Nice job on the v3 stuff. I happened across a couple capabilities being
> requested that don't officially exist, a distinction you've probably
> picked up on in the course of pursuing this work [1]. The couple that
> slipped by are always NAK'd but basically harmless, so you may just want
> to leave 'em or otherwise go your own way. If so, please ignore this.

I have to be honest, I was not familiar with this distinction.  As you
say, I assuming that anything that wasn't implemented by a server would
be NAK'd.

What confuses me is how standard-replies doesn't have to be requested.
message-ids is clear, because they rely on message-tags and if a that is
provided, sending message IDs even if they were not requested wouldn't
pose any issues.  The thing is that standard-replies introduces new
types, that the client must be able to parse.  Just sending them to any
non IRCv3-capable client would presumable confuse it.  From reading the
spec, I don't immediately see that it says the capability should be
requested.  Could you explain this?

-- 
	Philip Kaludercic




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51342; Package emacs. (Sun, 24 Oct 2021 14:04:01 GMT) Full text and rfc822 format available.

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: 29.0.50; remove non-CAPs from rcirc capability list
Date: Sun, 24 Oct 2021 07:03:38 -0700
Philip Kaludercic <philipk <at> posteo.net> writes:

> What confuses me is how standard-replies doesn't have to be requested.
> message-ids is clear, because they rely on message-tags and if a that is
> provided, sending message IDs even if they were not requested wouldn't
> pose any issues.  The thing is that standard-replies introduces new
> types, that the client must be able to parse.  Just sending them to any
> non IRCv3-capable client would presumable confuse it.  From reading the
> spec, I don't immediately see that it says the capability should be
> requested.  Could you explain this?

Standard replies are quite mysterious. From what I can gather:

  - Future extensions are to favor this form of reply whenever possible.
  - These *aren't* for recasting existing replies.

So there's no need to explicitly request them because support is implied
when asking for an extension that uses them, much like with message IDs.

However, I *have* noticed at least one progressive IRCd sending standard
replies not defined in any spec [1]. I can only guess they assume
clients not privy to the new syntax are resilient enough to take these
in stride [2]. And while being privy does buy a client more useful info
for presenting to the user, it's still the particulars, like the
specific reply code and the shape/meaning of the "context params", that
allow it to respond decisively to a given situation (IMO). Thanks.


[1] https://github.com/ircv3/ircv3-specifications/pull/276

[2] As in recognize these messages as at least adhering to the standard
    IRC format and therefore capable of withstanding whatever treatment
    is normally reserved for extracting the most degenerate
    understanding (like simply printing the message to the server buffer
    as a quasi error), in much the same way Libera likely doesn't worry
    much about its nonstandard numerics 479 and 435(?) causing much of a
    stir.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51342; Package emacs. (Tue, 26 Oct 2021 03:51:01 GMT) Full text and rfc822 format available.

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: 29.0.50; remove non-CAPs from rcirc capability list
Date: Mon, 25 Oct 2021 20:50:29 -0700
"J.P." <jp <at> neverwas.me> writes:

> However, I *have* noticed at least one progressive IRCd sending
> standard replies not defined in any spec [1].
>
> [...]
>
> [1] https://github.com/ircv3/ircv3-specifications/pull/276

That link is bogus/unrelated (sorry). It's actually a

  :irc.org FAIL NICK NICKNAME_RESERVED tester :Nickname is reserved ...

that I encountered, but it's not documented anywhere (that I could
find). It's sent by Ergo 2.6.1 whether or not you request any caps.
NICKNAME_RESERVED was ostensibly created to prevent confusion with the
traditional 433/ERR_NICKNAMEINUSE, which accompanies it in the same
burst.

Whether it's safe to expect such redundancy across the board when
nothing dependent has been negotiated is anyone's guess, but the
existence of the vendor cap inspircd.org/standard-replies [1] perhaps
tips things in favor of the yeas. This cap gives permission for a server
to send undeclared replies in standard-replies form, possibly in lieu of
traditional ones, like 433.

> I can only guess they assume clients not privy to the new syntax are
> resilient enough to take these in stride [2].

Yeah, "new syntax" is just confusing. What I meant was rather than
extending the IRC message format, a standard-replies declaration merely
specifies a concrete reply within the constraints of the broader
protocol, meaning

  [@tags] [:src] cmd    p0     p1     p2     ... pn-1    :pn
  [@tags] [:src] <type> <req> <code> [<cxt0> ... <ctxn>] :<desc>

from the spec is just a way of getting us ready for specific interface
descriptions, like those for setname [2]. So when folks talk about
safely degrading in this context [3], they mean devolving to a catch-all
handler (usually NOTICE) for all unrecognized/unhandled replies. Thanks.

[1] https://docs.inspircd.org/3/modules/cap/
[2] https://ircv3.net/specs/extensions/setname#errors
[3] https://github.com/inspircd/inspircd/issues/1809




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51342; Package emacs. (Sun, 14 Nov 2021 18:12:02 GMT) Full text and rfc822 format available.

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: "J.P." <jp <at> neverwas.me>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: 29.0.50; remove non-CAPs from rcirc capability list
Date: Sun, 14 Nov 2021 18:10:58 +0000
(Sorry that it took me a while to respond)

"J.P." <jp <at> neverwas.me> writes:

> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>> What confuses me is how standard-replies doesn't have to be requested.
>> message-ids is clear, because they rely on message-tags and if a that is
>> provided, sending message IDs even if they were not requested wouldn't
>> pose any issues.  The thing is that standard-replies introduces new
>> types, that the client must be able to parse.  Just sending them to any
>> non IRCv3-capable client would presumable confuse it.  From reading the
>> spec, I don't immediately see that it says the capability should be
>> requested.  Could you explain this?
>
> Standard replies are quite mysterious. From what I can gather:
>
>   - Future extensions are to favor this form of reply whenever possible.
>   - These *aren't* for recasting existing replies.
>
> So there's no need to explicitly request them because support is implied
> when asking for an extension that uses them, much like with message IDs.

I understand the issue, but am still hesitant. If this is vague, then it
seems better to err on the side of safety and request a message even if
the request constitutes a noop. Or are there any real downsides to being
more explicit?

-- 
	Philip Kaludercic




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51342; Package emacs. (Sun, 14 Nov 2021 23:08:01 GMT) Full text and rfc822 format available.

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: 29.0.50; remove non-CAPs from rcirc capability list
Date: Sun, 14 Nov 2021 15:07:14 -0800
Philip Kaludercic <philipk <at> posteo.net> writes:

>> Standard replies are quite mysterious. From what I can gather:
>
> [...]
>
> I understand the issue, but am still hesitant. If this is vague, then
> it seems better to err on the side of safety

What's mysterious and vague isn't the existence of a capability called
standard-replies. No such capability currently exists. As mentioned in
my last reply (not sure if you saw that one), the closest thing is
inspircd.org/standard-replies. Hope that makes sense.

> Or are there any real downsides to being more explicit?

No downsides at present because you request one cap per line. And you
have no interdependent caps as yet. So long as both remain true, there's
nothing to worry about. And rcirc doesn't make you accrue flood debt,
so early messages (even spurious ones) don't cost extra.

In ERC's case, we *do* have to worry because we implement 302 and have
multiple dependencies. If any one gets NAK'd, there goes the ball game.
There's also some undefined behavior [1] that can turn connection
registration into a bit of a limbo without additional planning (should
you ever decide to go that route). Thanks.


[1] https://github.com/ircv3/ircv3-specifications/pull/400#issuecomment-579063998





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51342; Package emacs. (Wed, 17 Nov 2021 20:23:01 GMT) Full text and rfc822 format available.

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: "J.P." <jp <at> neverwas.me>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: 29.0.50; remove non-CAPs from rcirc capability list
Date: Wed, 17 Nov 2021 20:22:14 +0000
"J.P." <jp <at> neverwas.me> writes:

> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>>> Standard replies are quite mysterious. From what I can gather:
>>
>> [...]
>>
>> I understand the issue, but am still hesitant. If this is vague, then
>> it seems better to err on the side of safety
>
> What's mysterious and vague isn't the existence of a capability called
> standard-replies. No such capability currently exists. As mentioned in
> my last reply (not sure if you saw that one), the closest thing is
> inspircd.org/standard-replies. Hope that makes sense.
>
>> Or are there any real downsides to being more explicit?
>
> No downsides at present because you request one cap per line. And you
> have no interdependent caps as yet. So long as both remain true, there's
> nothing to worry about. And rcirc doesn't make you accrue flood debt,
> so early messages (even spurious ones) don't cost extra.

Ok, then I think we should leave it the way it is for now.

> In ERC's case, we *do* have to worry because we implement 302 and have
> multiple dependencies. If any one gets NAK'd, there goes the ball game.
> There's also some undefined behavior [1] that can turn connection
> registration into a bit of a limbo without additional planning (should
> you ever decide to go that route). Thanks.

I think you should report this as a separate bug report.

> [1] https://github.com/ircv3/ircv3-specifications/pull/400#issuecomment-579063998
>

-- 
	Philip Kaludercic




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51342; Package emacs. (Tue, 13 Sep 2022 14:50:02 GMT) Full text and rfc822 format available.

Message #29 received at 51342 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "J.P." <jp <at> neverwas.me>
Cc: 51342 <at> debbugs.gnu.org, Philip Kaludercic <philipk <at> posteo.net>
Subject: Re: bug#51342: 29.0.50; remove non-CAPs from rcirc capability list
Date: Tue, 13 Sep 2022 16:49:35 +0200
"J.P." <jp <at> neverwas.me> writes:

> Nice job on the v3 stuff. I happened across a couple capabilities being
> requested that don't officially exist, a distinction you've probably
> picked up on in the course of pursuing this work [1]. The couple that
> slipped by are always NAK'd but basically harmless, so you may just want
> to leave 'em or otherwise go your own way. If so, please ignore this.

Skimming this thread, I'm not quite sure what the conclusion is.  Should
we leave things as they are here?




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Tue, 13 Sep 2022 14:50:03 GMT) Full text and rfc822 format available.

Reply sent to "J.P." <jp <at> neverwas.me>:
You have taken responsibility. (Tue, 13 Sep 2022 18:31:02 GMT) Full text and rfc822 format available.

Notification sent to "J.P." <jp <at> neverwas.me>:
bug acknowledged by developer. (Tue, 13 Sep 2022 18:31:02 GMT) Full text and rfc822 format available.

Message #36 received at 51342-done <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51342-done <at> debbugs.gnu.org, Philip Kaludercic <philipk <at> posteo.net>
Subject: Re: bug#51342: 29.0.50; remove non-CAPs from rcirc capability list
Date: Tue, 13 Sep 2022 11:30:00 -0700
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> "J.P." <jp <at> neverwas.me> writes:
>
>> Nice job on the v3 stuff. I happened across a couple capabilities being
>> requested that don't officially exist, a distinction you've probably
>> picked up on in the course of pursuing this work [1]. The couple that
>> slipped by are always NAK'd but basically harmless, so you may just want
>> to leave 'em or otherwise go your own way. If so, please ignore this.
>
> Skimming this thread, I'm not quite sure what the conclusion is.  Should
> we leave things as they are here?

Sounds good, closing.

(There's no actual protocol violation here, just some unneeded messages.)




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 12 Oct 2022 11:24:06 GMT) Full text and rfc822 format available.

bug unarchived. Request was from "J.P." <jp <at> neverwas.me> to control <at> debbugs.gnu.org. (Wed, 12 Oct 2022 13:35:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51342; Package emacs. (Wed, 12 Oct 2022 13:37:01 GMT) Full text and rfc822 format available.

Message #43 received at 51342 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 51342 <at> debbugs.gnu.org
Subject: Re: bug#51342: 29.0.50; remove non-CAPs from rcirc capability list
Date: Wed, 12 Oct 2022 06:36:04 -0700
Just a note for posterity. Looks like `standard-replies' is now being
formally proposed as a capability:

  https://github.com/ircv3/ircv3-specifications/pull/506




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 10 Nov 2022 12:24:08 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 140 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.