From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs Subject: bug#51342: 29.0.50; remove non-CAPs from rcirc capability list Date: Sun, 24 Oct 2021 07:03:38 -0700 Message-ID: <87r1caseo5.fsf@neverwas.me> References: <87o87gzjpd.fsf@neverwas.me> <878ryiwxf4.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1909"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) Cc: 51342@debbugs.gnu.org To: Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 24 16:04:22 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mee6o-0000DS-9k for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 24 Oct 2021 16:04:22 +0200 Original-Received: from localhost ([::1]:49418 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mee6n-0001z3-69 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 24 Oct 2021 10:04:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54984) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mee6U-0001yd-6t for bug-gnu-emacs@gnu.org; Sun, 24 Oct 2021 10:04:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57130) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mee6T-0004zN-UW for bug-gnu-emacs@gnu.org; Sun, 24 Oct 2021 10:04:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mee6T-0008Hx-Qn for bug-gnu-emacs@gnu.org; Sun, 24 Oct 2021 10:04:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 24 Oct 2021 14:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51342 X-GNU-PR-Package: emacs X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.163508423431848 (code B ref -1); Sun, 24 Oct 2021 14:04:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 24 Oct 2021 14:03:54 +0000 Original-Received: from localhost ([127.0.0.1]:40443 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mee6L-0008Hc-MN for submit@debbugs.gnu.org; Sun, 24 Oct 2021 10:03:53 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:52826) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mee6J-0008HU-MY for submit@debbugs.gnu.org; Sun, 24 Oct 2021 10:03:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54962) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mee6J-0001yS-H6 for bug-gnu-emacs@gnu.org; Sun, 24 Oct 2021 10:03:51 -0400 Original-Received: from mail-108-mta12.mxroute.com ([136.175.108.12]:39393) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mee6G-0004p2-Ij for bug-gnu-emacs@gnu.org; Sun, 24 Oct 2021 10:03:51 -0400 Original-Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta12.mxroute.com (ZoneMTA) with ESMTPSA id 17cb29d40d60000b55.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Sun, 24 Oct 2021 14:03:42 +0000 X-Zone-Loop: 31b61d72e86a26dc12a2bba2f4cf13dadca972ca70e0 X-Originating-IP: [149.28.56.236] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=zik+Ri6jPkuaoXWZRsk9Q/Fk22PlDpCUSNpTuU7um74=; b=VabFP91b7KAE35LUThxXa7tAbg kDOGpTNSmkb16EHGtnmDuGVe2cbZeZCeHoxg+1cvikiQTOZZ1VbRfgvptpF0aNbzIhBxsjCM1OOFo jeX8RXcGKHGEM03+QpKoR/+iaW0F86oUW3jzBdJl7kl3XgzwQXWi+/cXKws/gePILcCETsvGuQzdW jod3HQSEieSrrGINTJdxNsjLlsr6hx4gI+BvKPxBpI7GL/M4jGMyXg7gAC00WKsJiwy3/uxFjla/K 4bQwDrLtZiaaaqLL5HMiIVKdDQeSgRlVHqTd1oA5n7ETV8rzFETTwzCI+k3SBb5UZ2Nmt03gXknsP y9N1TQ1w==; In-Reply-To: <878ryiwxf4.fsf@posteo.net> (Philip Kaludercic's message of "Sun, 24 Oct 2021 10:05:03 +0000") X-AuthUser: masked@neverwas.me X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-0.1, required=15, tests=[ARC_NA=0, RCPT_COUNT_TWO=0, FROM_HAS_DN=0, TO_DN_SOME=0, MIME_GOOD=-0.1, FROM_EQ_ENVFROM=0, MIME_TRACE=0, RCVD_COUNT_ZERO=0, NEURAL_SPAM=0, MID_RHS_MATCH_FROM=0] Received-SPF: pass client-ip=136.175.108.12; envelope-from=jp@neverwas.me; helo=mail-108-mta12.mxroute.com X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:218123 Archived-At: Philip Kaludercic 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.