Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

There's got to be more to life than compile-and-go.


computers / news.software.nntp / Re: Proposal specifications for MAXARTNUM

SubjectAuthor
* Re: Proposal specifications for MAXARTNUMJulien ÉLIE
`* Re: Proposal specifications for MAXARTNUMMichael Bäuerle
 +* Re: Proposal specifications for MAXARTNUMUrs Janßen
 |`* Re: Proposal specifications for MAXARTNUMMichael Bäuerle
 | +* Re: Proposal specifications for MAXARTNUMUrs Janßen
 | |`* Re: Proposal specifications for MAXARTNUMJulien ÉLIE
 | | `- Re: Proposal specifications for MAXARTNUMMichael Bäuerle
 | `- Re: Proposal specifications for MAXARTNUMJulien ÉLIE
 `* Re: Proposal specifications for MAXARTNUMJulien ÉLIE
  `* Re: Proposal specifications for MAXARTNUMMichael Bäuerle
   `* Re: Proposal specifications for MAXARTNUMJulien ÉLIE
    `- Re: Proposal specifications for MAXARTNUMMichael Bäuerle

1
Re: Proposal specifications for MAXARTNUM

<tp53et$7clk$1@news.trigofacile.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=1328&group=news.software.nntp#1328

 copy link   Newsgroups: news.software.nntp
Path: i2pn2.org!i2pn.org!aioe.org!news.gegeweb.eu!gegeweb.org!news.trigofacile.com!.POSTED.176.143-2-105.abo.bbox.fr!not-for-mail
From: iul...@nom-de-mon-site.com.invalid (Julien ÉLIE)
Newsgroups: news.software.nntp
Subject: Re: Proposal specifications for MAXARTNUM
Date: Thu, 5 Jan 2023 00:51:57 +0100
Organization: Groupes francophones par TrigoFACILE
Message-ID: <tp53et$7clk$1@news.trigofacile.com>
References: <tnqm14$35bas$1@news.trigofacile.com>
<tou5si$1na9g$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 4 Jan 2023 23:51:57 -0000 (UTC)
Injection-Info: news.trigofacile.com; posting-account="julien"; posting-host="176.143-2-105.abo.bbox.fr:176.143.2.105";
logging-data="242356"; mail-complaints-to="abuse@trigofacile.com"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.6.1
Cancel-Lock: sha1:yvk84vwbQi5+ZWPoh54ig9Haf6I= sha256:5evzX2awRSnCq1dC0LoU97uh7eFAfNzca59znCie1x4=
sha1:w+CI9R5uTyafVE011V2zAnv7Uf4= sha256:SiFjxoqWrVFrO8o5iepMYAThtgYwkPQXor8YMP17cX0=
In-Reply-To: <tou5si$1na9g$1@dont-email.me>
 by: Julien ÉLIE - Wed, 4 Jan 2023 23:51 UTC

Hi Bo,

> The maximum article number is a capability of the client which is useful
> for the server to know. Is this the only such capability that could exist?
> If there are others, it might be better to instead define a general CLIENTCAP
> command with a MAXARTNUM sub-command.

That's a good point.
We could define a general ENABLE extension, like IMAP has (RFC 5161).
They defined only 1 extension to start with (CONDSTORE), and afterwards
only two up to now if I am not mistaken: METADATA (RFC 5464) and UTF8
(RFC 6855).

We could do something similar, indeed...
I am unsure we'll end up with many capabilities, though. Maybe one for
UTF-8 to advertise that a client cope with internationalized newsgroup
names?
I am unsure "enabling UTF-8" for a client is really needed for NNTP as
RFC 3977 says clients SHOULD match newsgroups names octet by octet. A
news server may already send non-ASCII newsgroup names, and I don't
think it should not do that unless the client asks for it. But I may be
wrong. Any point of view about that?

From RFC 3977:

o Although this specification allows UTF-8 for newsgroup names, they
SHOULD be restricted to US-ASCII until a successor to RFC 1036
[RFC1036] standardises another approach. 8-bit encodings SHOULD
NOT be used because they are likely to cause interoperability
problems.

Until such specifications
are published, implementations SHOULD match newsgroup names octet by
octet. It is anticipated that any approved scheme will be applied
"at the edges", and therefore octet-by-octet comparison will continue
to apply to most, if not all, uses of newsgroup names in NNTP.

If we're going to have only a very few, if any, more general "ENABLE"
commands, is it worth the complexification of defining its parsing
instead of just having top-level commands?

ENABLE MAXARTNUM=18446744073709551615 UTF8=ACCEPT NULCHARS=ACCEPT
MAXRESPLINES=UNLIMITED

Just an example; apart from MAXARTNUM, the other keywords aren't
probably the right way to extend the requirements of NNTP Version 2.

--
Julien ÉLIE

« Il ne faut jamais parler sèchement à un Numide. » (Astérix)

Re: Proposal specifications for MAXARTNUM

<AABjtplGZckAAAqY.A3.flnews@WStation7.micha.freeshell.org>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=1329&group=news.software.nntp#1329

 copy link   Newsgroups: news.software.nntp
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.imp.ch!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: michael....@gmx.net (Michael Bäuerle)
Newsgroups: news.software.nntp
Subject: Re: Proposal specifications for MAXARTNUM
Date: Thu, 5 Jan 2023 10:32:54 +0100 (CET)
Lines: 55
Message-ID: <AABjtplGZckAAAqY.A3.flnews@WStation7.micha.freeshell.org>
References: <tnqm14$35bas$1@news.trigofacile.com> <tou5si$1na9g$1@dont-email.me> <tp53et$7clk$1@news.trigofacile.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=fixed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net iCsEZx8KGXLKyMaaOHDcJQ816HROUdZIFPGiPyUwVSVj3++kEX
X-Orig-Path: not-for-mail
Cancel-Lock: sha1:WC/YkYlUtAGPjA2ZiF+Yv5JDGu8= sha256:k8FFedP7vQ+xsMUkQnKw7/jB5RVZUg2jnwwMMWTb9FM= sha1:u4YqJbaRFbZ6kxBT+ApyyTRN5LM=
Injection-Date: Thu, 5 Jan 2023 09:32:54 -0000
User-Agent: flnews/1.2.0pre17 (for GNU/Linux)
 by: Michael Bäuerle - Thu, 5 Jan 2023 09:32 UTC

Julien ÉLIE wrote:
>
> [...]
> From RFC 3977:
>
> o Although this specification allows UTF-8 for newsgroup names, they
> SHOULD be restricted to US-ASCII until a successor to RFC 1036
> [RFC1036] standardises another approach. 8-bit encodings SHOULD
> NOT be used because they are likely to cause interoperability
> problems.
>
> Until such specifications
> are published, implementations SHOULD match newsgroup names octet by
> octet. It is anticipated that any approved scheme will be applied
> "at the edges", and therefore octet-by-octet comparison will continue
> to apply to most, if not all, uses of newsgroup names in NNTP.
>
> If we're going to have only a very few, if any, more general "ENABLE"
> commands, is it worth the complexification of defining its parsing
> instead of just having top-level commands?
>
> ENABLE MAXARTNUM=18446744073709551615 UTF8=ACCEPT NULCHARS=ACCEPT
> MAXRESPLINES=UNLIMITED

There are potential problems if not all of the features are supported
by the server. The command likely will be rejected with an error code,
no feature will be enabled and the client doesn't know which subcommand
was responsible for the problem. The client has to parse the response
for information or test all features individually.
In theory this should not happen, if the client has parsed CAPABILITIES
carefully, but in real world there may be bugs somewhere.

I would prefer simplicity, this means only one feature per command.
But maybe the toplevel command "ENABLE", to enable/negotiate features,
is useful to share the same return codes for all features.

Like this it would work similar to LIST or COMPRESS:

C CAPABILITIES
S 101 Capability list:
S VERSION 2
S ENABLE MAXARTNUM UTF8 NULCHARS MAXRESPLINES
S .

C ENABLE MAXARTNUM=18446744073709551615
S 2xx
C ENABLE UTF-8=ACCEPT
S 500
C ENABLE NULCHARS=ACCEPT
S 2xx
C ENABLE MAXRESPLINES=UNLIMITED
S 2xx

This has to be done only once per session and the additional roundtrip
times should be acceptable if the number of features is small.

Re: Proposal specifications for MAXARTNUM

<tp6bjr$kk4$1@nntp.de>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=1330&group=news.software.nntp#1330

 copy link   Newsgroups: news.software.nntp
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!2.eu.feeder.erje.net!feeder.erje.net!nntp.de!.POSTED.akk21-int.akk.kit.edu!not-for-mail
From: urs...@buil.tin.org (Urs Janßen)
Newsgroups: news.software.nntp
Subject: Re: Proposal specifications for MAXARTNUM
Date: Thu, 5 Jan 2023 11:17:15 -0000 (UTC)
Organization: tin.org
Archive: no
Message-ID: <tp6bjr$kk4$1@nntp.de>
References: <tnqm14$35bas$1@news.trigofacile.com> <tou5si$1na9g$1@dont-email.me> <tp53et$7clk$1@news.trigofacile.com> <AABjtplGZckAAAqY.A3.flnews@WStation7.micha.freeshell.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 5 Jan 2023 11:17:15 -0000 (UTC)
Injection-Info: nntp.de; posting-host="akk21-int.akk.kit.edu:2a00:1398:5:f602:cafe:cafe:cafe:21";
logging-data="21124"; mail-complaints-to="abuse@nntp.de"
User-Agent: tin/2.6.3-20221225 ("Pittyvaich") (Linux/4.19.0-14-amd64 (x86_64))
Cancel-Lock: sha1:LfjJX5yYs3Q8Ze/4EuI8IKmdn8g=
X-No-Archive: yes
X-No-HTML: yes
 by: Urs Janßen - Thu, 5 Jan 2023 11:17 UTC

In <AABjtplGZckAAAqY.A3.flnews@WStation7.micha.freeshell.org> on Thu, 05 Jan 2023 10:32:54,
Michael Bäuerle wrote:
> I would prefer simplicity, this means only one feature per command.

ACK

> S ENABLE MAXARTNUM UTF8 NULCHARS MAXRESPLINES
> S .

but now the server does not tell the client it's MAXARTNUM limit anymore

> C ENABLE MAXARTNUM=18446744073709551615

and that might be beyond the servers limit of e.g. 2^63-1 and thus
leading to 4xx ...

Re: Proposal specifications for MAXARTNUM

<AABjtspvADYAABbL.A3.flnews@WStation7.micha.freeshell.org>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=1331&group=news.software.nntp#1331

 copy link   Newsgroups: news.software.nntp
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: michael....@gmx.net (Michael Bäuerle)
Newsgroups: news.software.nntp
Subject: Re: Proposal specifications for MAXARTNUM
Date: Thu, 5 Jan 2023 14:02:39 +0100 (CET)
Lines: 27
Message-ID: <AABjtspvADYAABbL.A3.flnews@WStation7.micha.freeshell.org>
References: <tnqm14$35bas$1@news.trigofacile.com> <tou5si$1na9g$1@dont-email.me> <tp53et$7clk$1@news.trigofacile.com> <AABjtplGZckAAAqY.A3.flnews@WStation7.micha.freeshell.org> <tp6bjr$kk4$1@nntp.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=fixed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net Chltvl3qfW8lTEIhBtjQfAQX2oLHRPvp1KwIeuO58NuNn0N/6s
X-Orig-Path: not-for-mail
Cancel-Lock: sha1:kxlgRR9rm0ryLbe2GdJfS18p7zI= sha256:53L04Ize+w3c6Mkk++pnDE/1yGYjZuhBONBo2eCkv5I= sha1:J0wLL7Nr4jNH/9eLPgJlJML1OCg=
Injection-Date: Thu, 5 Jan 2023 13:02:39 -0000
User-Agent: flnews/1.2.0pre17 (for GNU/Linux)
 by: Michael Bäuerle - Thu, 5 Jan 2023 13:02 UTC

Urs Janßen wrote:
> In <AABjtplGZckAAAqY.A3.flnews@WStation7.micha.freeshell.org> on Thu, 05 Jan 2023 10:32:54,
> Michael Bäuerle wrote:
> >
> > I would prefer simplicity, this means only one feature per command.
>
> ACK
>
> > S ENABLE MAXARTNUM UTF8 NULCHARS MAXRESPLINES
> > S .
>
> but now the server does not tell the client it's MAXARTNUM limit anymore

There is a similar situation for AUTHINFO with SASL in CAPABILITIES:
|
| AUTHINFO USER SASL
| SASL CRAM-MD5 PLAIN

> > C ENABLE MAXARTNUM=18446744073709551615
>
> and that might be beyond the servers limit of e.g. 2^63-1 and thus
> leading to 4xx ...

In our example it could look like:

ENABLE MAXARTNUM UTF8 NULCHARS MAXRESPLINES
MAXARTNUM 18446744073709551615

Re: Proposal specifications for MAXARTNUM

<tp6l3e$n0q$1@nntp.de>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=1332&group=news.software.nntp#1332

 copy link   Newsgroups: news.software.nntp
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!nntp.de!.POSTED.akk21-int.akk.kit.edu!not-for-mail
From: urs...@buil.tin.org (Urs Janßen)
Newsgroups: news.software.nntp
Subject: Re: Proposal specifications for MAXARTNUM
Date: Thu, 5 Jan 2023 13:59:10 -0000 (UTC)
Organization: tin.org
Archive: no
Message-ID: <tp6l3e$n0q$1@nntp.de>
References: <tnqm14$35bas$1@news.trigofacile.com> <tou5si$1na9g$1@dont-email.me> <tp53et$7clk$1@news.trigofacile.com> <AABjtplGZckAAAqY.A3.flnews@WStation7.micha.freeshell.org> <tp6bjr$kk4$1@nntp.de> <AABjtspvADYAABbL.A3.flnews@WStation7.micha.freeshell.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 5 Jan 2023 13:59:10 -0000 (UTC)
Injection-Info: nntp.de; posting-host="akk21-int.akk.kit.edu:2a00:1398:5:f602:cafe:cafe:cafe:21";
logging-data="23578"; mail-complaints-to="abuse@nntp.de"
User-Agent: tin/2.6.3-20221225 ("Pittyvaich") (Linux/4.19.0-14-amd64 (x86_64))
Cancel-Lock: sha1:DKQ4hnlvy/AEcOvTyXWDp4iBkro=
X-No-Archive: yes
X-No-HTML: yes
 by: Urs Janßen - Thu, 5 Jan 2023 13:59 UTC

In <AABjtspvADYAABbL.A3.flnews@WStation7.micha.freeshell.org> on Thu, 05 Jan 2023 14:02:39,
Michael Bäuerle wrote:
> In our example it could look like:
>
> ENABLE MAXARTNUM UTF8 NULCHARS MAXRESPLINES
> MAXARTNUM 18446744073709551615

but what's the point in listing MAXARTNUM in ENABLE when it is
announced with its limit anyway (if available)?

Re: Proposal specifications for MAXARTNUM

<tp7415$90fr$1@news.trigofacile.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=1333&group=news.software.nntp#1333

 copy link   Newsgroups: news.software.nntp
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.trigofacile.com!.POSTED.176.143-2-105.abo.bbox.fr!not-for-mail
From: iul...@nom-de-mon-site.com.invalid (Julien ÉLIE)
Newsgroups: news.software.nntp
Subject: Re: Proposal specifications for MAXARTNUM
Date: Thu, 5 Jan 2023 19:13:57 +0100
Organization: Groupes francophones par TrigoFACILE
Message-ID: <tp7415$90fr$1@news.trigofacile.com>
References: <tnqm14$35bas$1@news.trigofacile.com>
<tou5si$1na9g$1@dont-email.me> <tp53et$7clk$1@news.trigofacile.com>
<AABjtplGZckAAAqY.A3.flnews@WStation7.micha.freeshell.org>
<tp6bjr$kk4$1@nntp.de>
<AABjtspvADYAABbL.A3.flnews@WStation7.micha.freeshell.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 5 Jan 2023 18:13:57 -0000 (UTC)
Injection-Info: news.trigofacile.com; posting-account="julien"; posting-host="176.143-2-105.abo.bbox.fr:176.143.2.105";
logging-data="295419"; mail-complaints-to="abuse@trigofacile.com"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.6.1
Cancel-Lock: sha1:b+Idd6yEiGscUpSXvzIknSLCZsI= sha256:OOQ50RCAlF0x9k1/Ld+epKBZ6cSc0cJPQ5YhJDbM48E=
sha1:giz68y1uuSw7hzbXF129f3+dmtg= sha256:yTThxlMuWbot7Ol6ZCq+jyW4AxXIkLoyNy/9pU+fZ40=
In-Reply-To: <AABjtspvADYAABbL.A3.flnews@WStation7.micha.freeshell.org>
 by: Julien ÉLIE - Thu, 5 Jan 2023 18:13 UTC

Hi Michael,

> There is a similar situation for AUTHINFO with SASL in CAPABILITIES:
> |
> | AUTHINFO USER SASL
> | SASL CRAM-MD5 PLAIN

A separate capability list was needed because of:

In agreement with [SASL], the server MUST continue to advertise the
SASL capability in response to a CAPABILITIES command with the same
list of SASL mechanisms that it did before authentication (thereby
enabling the client to detect a possible active down-negotiation
attack).

Whereas AUTHINFO is no longer advertised after a successful authentication.

> In our example it could look like:
>
> ENABLE MAXARTNUM UTF8 NULCHARS MAXRESPLINES
> MAXARTNUM 18446744073709551615

It could. And after a successful use of MAXARTNUM, the capability
disappears in the ENABLE keywords, and the separate MAXARTNUM line.

--
Julien ÉLIE

« Le tennis c'est comme le ping-pong, sauf qu'au tennis, les joueurs
sont debout sur la table. »

Re: Proposal specifications for MAXARTNUM

<tp749m$90fs$1@news.trigofacile.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=1334&group=news.software.nntp#1334

 copy link   Newsgroups: news.software.nntp
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.trigofacile.com!.POSTED.176-143-2-105.abo.bbox.fr!not-for-mail
From: iul...@nom-de-mon-site.com.invalid (Julien ÉLIE)
Newsgroups: news.software.nntp
Subject: Re: Proposal specifications for MAXARTNUM
Date: Thu, 5 Jan 2023 19:18:30 +0100
Organization: Groupes francophones par TrigoFACILE
Message-ID: <tp749m$90fs$1@news.trigofacile.com>
References: <tnqm14$35bas$1@news.trigofacile.com>
<tou5si$1na9g$1@dont-email.me> <tp53et$7clk$1@news.trigofacile.com>
<AABjtplGZckAAAqY.A3.flnews@WStation7.micha.freeshell.org>
<tp6bjr$kk4$1@nntp.de>
<AABjtspvADYAABbL.A3.flnews@WStation7.micha.freeshell.org>
<tp6l3e$n0q$1@nntp.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 5 Jan 2023 18:18:30 -0000 (UTC)
Injection-Info: news.trigofacile.com; posting-account="julien"; posting-host="176-143-2-105.abo.bbox.fr:176.143.2.105";
logging-data="295420"; mail-complaints-to="abuse@trigofacile.com"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.6.1
Cancel-Lock: sha1:2ilMtK5UUGJ6vMnAymFqPjmxLgQ= sha256:xwtcXxcGtQCu+Jr+YJabk2Ll9GjjiZQW2CTWSetQJmU=
sha1:q3v1U30B3i2mNNBst2oaR7tCtdk= sha256:+SoLIr/UsXBzCxzEOCAMiresFBK/sMlaG6UK259asSI=
In-Reply-To: <tp6l3e$n0q$1@nntp.de>
 by: Julien ÉLIE - Thu, 5 Jan 2023 18:18 UTC

Hi Urs,

>> ENABLE MAXARTNUM UTF8 NULCHARS MAXRESPLINES
>> MAXARTNUM 18446744073709551615
>
> but what's the point in listing MAXARTNUM in ENABLE when it is
> announced with its limit anyway (if available)?

Out of consistency, as it is a capability negotiated with the ENABLE
command?
Yet, I agree it is redundant, compared with "ENABLE MAXARTNUM=xxx".
Both the approaches seem to make sense, though.

--
Julien ÉLIE

« – Frappe quelqu'un !
– Mais je ne suis fâché avec personne ! » (Astérix)

Re: Proposal specifications for MAXARTNUM

<tp76sd$90fs$2@news.trigofacile.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=1335&group=news.software.nntp#1335

 copy link   Newsgroups: news.software.nntp
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.trigofacile.com!.POSTED.176-143-2-105.abo.bbox.fr!not-for-mail
From: iul...@nom-de-mon-site.com.invalid (Julien ÉLIE)
Newsgroups: news.software.nntp
Subject: Re: Proposal specifications for MAXARTNUM
Date: Thu, 5 Jan 2023 20:02:37 +0100
Organization: Groupes francophones par TrigoFACILE
Message-ID: <tp76sd$90fs$2@news.trigofacile.com>
References: <tnqm14$35bas$1@news.trigofacile.com>
<tou5si$1na9g$1@dont-email.me> <tp53et$7clk$1@news.trigofacile.com>
<AABjtplGZckAAAqY.A3.flnews@WStation7.micha.freeshell.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 5 Jan 2023 19:02:37 -0000 (UTC)
Injection-Info: news.trigofacile.com; posting-account="julien"; posting-host="176-143-2-105.abo.bbox.fr:176.143.2.105";
logging-data="295420"; mail-complaints-to="abuse@trigofacile.com"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.6.1
Cancel-Lock: sha1:5vWjKjVcfnW2havPKjDNn8riso8= sha256:HmYRLE9BzM0uHIxPS3YmcEtVJvZCy0LZzE0lcSi00u4=
sha1:FDGxdlM/MicPs9DGxCIvAVze1TQ= sha256:vLB7eAkg174O1cVqaAAW+5972yLvILfMRgKjAb2BQa0=
In-Reply-To: <AABjtplGZckAAAqY.A3.flnews@WStation7.micha.freeshell.org>
 by: Julien ÉLIE - Thu, 5 Jan 2023 19:02 UTC

Hi Michael,

>> If we're going to have only a very few, if any, more general "ENABLE"
>> commands, is it worth the complexification of defining its parsing
>> instead of just having top-level commands?
>>
>> ENABLE MAXARTNUM=18446744073709551615 UTF8=ACCEPT NULCHARS=ACCEPT
>> MAXRESPLINES=UNLIMITED
>
> There are potential problems if not all of the features are supported
> by the server. The command likely will be rejected with an error code,
> no feature will be enabled and the client doesn't know which subcommand
> was responsible for the problem.

The ENABLE command in IMAP does:

- If the argument is not an extension known to the server, the server
MUST ignore the argument.

- If the argument is an extension known to the server, and it is not
specifically permitted to be enabled using ENABLE, the server MUST
ignore the argument. (Note that knowing about an extension doesn't
necessarily imply supporting that extension.)

- If the argument is an extension that is supported by the server and
that needs to be enabled, the server MUST enable the extension for
the duration of the connection. At present, this applies only to
CONDSTORE ([RFC4551]). Note that once an extension is enabled,
there is no way to disable it.

The ENABLE command can be issued multiple times in a session. It is
additive; i.e., "ENABLE a b", followed by "ENABLE c" is the same as a
single command "ENABLE a b c".

The server MUST NOT change the CAPABILITY list as a result of
executing ENABLE; i.e., a CAPABILITY command issued right after an
ENABLE command MUST list the same capabilities as a CAPABILITY
command issued before the ENABLE command.

For the last point about going on advertising the capability, I am
unsure we should do the same for NNTP, if we use ENABLE. Once the
maximum article number is negotiated, it cannot be changed a second
time, so there's no need in advertising the capability.

> The client has to parse the response
> for information or test all features individually.
> In theory this should not happen, if the client has parsed CAPABILITIES
> carefully, but in real world there may be bugs somewhere.

I agree that parsing ENABLE commands and results without error will be
challenging...
It is far more work than unique commands, one per feature.

Capability list:
[S] ENABLE MAXARTNUM=18446744073709551615 UTF8=NEWSGROUPS,HEADERS
NULCHARS MAXRESPLINES=4096
(or a variant on several lines with individual MAXARTNUM, UTF8 and
MAXRESPLINES capabilities - not needed for NULCHARS)

Command:
[C] ENABLE MAXARTNUM=9223372036854775807 UTF8=NEWSGROUPS MAXRESPLINES=2048
[S] 206 UTF8=NEWSGROUPS MAXARTNUM=9223372036854775807 MAXRESPLINES=2048

Responding what has been enabled, without trailing comment.

We may have instead of a 501 syntax error, not giving useful information:
[C] ENABLE MAXARTNUM=badnumber UTF8=NONE MAXRESPLINES=2048
[S] 506 MAXARTNUM UTF8
(new error code to indicate syntax error in recognized commands, listed
after 506, and MAXRESPLINES is not enabled)
Or we can just use 501 without that complexity.

A bit of work...

> I would prefer simplicity, this means only one feature per command.
> But maybe the toplevel command "ENABLE", to enable/negotiate features,
> is useful to share the same return codes for all features.

Defining shared return codes, and enabling all features in only 1
command, may be the only advantages for ENABLE.
I don't know if that's worth the extra work in complexity of
coding/debugging/getting it right.
Notably if we end up only having MAXARTNUM as a feature to enable...

> C ENABLE UTF-8=ACCEPT
> S 500

Might be 503 (feature not supported) in case the extension is unknown to
the server. (500 is for the base command.)

> This has to be done only once per session and the additional roundtrip
> times should be acceptable if the number of features is small.

We already have many roundtrips in sessions like this one, where the
client sends CAPABILITIES several times:

CAPABILITIES (gosh, MODE-READER is advertised)
MODE READER
CAPABILITIES (gosh, there is no argument to AUTHINFO)
STARTTLS
CAPABILITIES (yes, I can now authenticate)
AUTHINFO USER
AUTHINFO PASS
CAPABILITIES (I now have more capabilities available)
COMPRESS DEFLATE
ENABLE MAXARTNUM=18446744073709551615

And now after 10 commands (sic), I can send LIST ACTIVE & co.

Using implicit TLS on port 563, which is the most wide-spread situation,
we have 4 less commands.
Seems reasonable after all to have separate commands (MAXARTNUM, and
other possible future extensions) instead of ENABLE...

--
Julien ÉLIE

« On appelle ça une insula. C'est une maison où les gens habitent les
uns au-dessus des autres… » (Astérix)

Re: Proposal specifications for MAXARTNUM

<AABjuS+bqKIAAAoW.A3.flnews@WStation7.micha.freeshell.org>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=1337&group=news.software.nntp#1337

 copy link   Newsgroups: news.software.nntp
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.imp.ch!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: michael....@gmx.net (Michael Bäuerle)
Newsgroups: news.software.nntp
Subject: Re: Proposal specifications for MAXARTNUM
Date: Sat, 7 Jan 2023 09:38:51 +0100 (CET)
Lines: 20
Message-ID: <AABjuS+bqKIAAAoW.A3.flnews@WStation7.micha.freeshell.org>
References: <tnqm14$35bas$1@news.trigofacile.com> <tou5si$1na9g$1@dont-email.me> <tp53et$7clk$1@news.trigofacile.com> <AABjtplGZckAAAqY.A3.flnews@WStation7.micha.freeshell.org> <tp6bjr$kk4$1@nntp.de> <AABjtspvADYAABbL.A3.flnews@WStation7.micha.freeshell.org> <tp6l3e$n0q$1@nntp.de> <tp749m$90fs$1@news.trigofacile.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=fixed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net 9PxIk0eZ6cM0e2Yj7yLgiAx+m/WRCrYnLZDf13LTJ86WKG+pgR
X-Orig-Path: not-for-mail
Cancel-Lock: sha1:KXzhKOvpalV4P6bUAtACdihH8e8= sha256:LGj6VURSHfJOzuPVNMm2M1jtEIKd1EVRXsi4fZhg6Rw= sha1:La2pj8lH6rauyKOh9VBmq8wtsxs=
Injection-Date: Sat, 7 Jan 2023 08:38:51 -0000
User-Agent: flnews/1.2.0pre17 (for GNU/Linux)
 by: Michael Bäuerle - Sat, 7 Jan 2023 08:38 UTC

Julien ÉLIE wrote:
> Urs Janßen wrote:
> > Michael Bäuerle wrote:
> > >
> > > ENABLE MAXARTNUM UTF8 NULCHARS MAXRESPLINES
> > > MAXARTNUM 18446744073709551615
> >
> > but what's the point in listing MAXARTNUM in ENABLE when it is
> > announced with its limit anyway (if available)?
>
> Out of consistency, as it is a capability negotiated with the ENABLE
> command?

Yes, because other commands use a similar scheme.
But this does not mean that I would prefer the variant with ENABLE.

> Yet, I agree it is redundant, compared with "ENABLE MAXARTNUM=xxx".
> Both the approaches seem to make sense, though.

Without ENABLE it is simpler to implement.

Re: Proposal specifications for MAXARTNUM

<AABjuUUYqSEAAAnM.A3.flnews@Server4.micha.freeshell.org>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=1338&group=news.software.nntp#1338

 copy link   Newsgroups: news.software.nntp
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.imp.ch!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: michael....@gmx.net (Michael Bäuerle)
Newsgroups: news.software.nntp
Subject: Re: Proposal specifications for MAXARTNUM
Date: Sat, 7 Jan 2023 10:10:32 -0000
Lines: 162
Message-ID: <AABjuUUYqSEAAAnM.A3.flnews@Server4.micha.freeshell.org>
References: <tnqm14$35bas$1@news.trigofacile.com> <tou5si$1na9g$1@dont-email.me> <tp53et$7clk$1@news.trigofacile.com> <AABjtplGZckAAAqY.A3.flnews@WStation7.micha.freeshell.org> <tp76sd$90fs$2@news.trigofacile.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=fixed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net Pr+Vb1fupUvwVDHQfPZb/gKhuz8dZuNa0LiZbt/YmEP2EgV475
X-Orig-Path: not-for-mail
Cancel-Lock: sha1:rm7htuzo/4jRdg/VX3DiYXwTPNU=
Injection-Date: Sat, 7 Jan 2023 10:10:32 -0000
User-Agent: flnews/1.1.0 (for HP-UX)
 by: Michael Bäuerle - Sat, 7 Jan 2023 10:10 UTC

Julien ÉLIE wrote:
> Michael Bäuerle wrote:
> > Julien ÉLIE wrote:
> > >
> > > If we're going to have only a very few, if any, more general "ENABLE"
> > > commands, is it worth the complexification of defining its parsing
> > > instead of just having top-level commands?
> > >
> > > ENABLE MAXARTNUM=18446744073709551615 UTF8=ACCEPT NULCHARS=ACCEPT
> > > MAXRESPLINES=UNLIMITED
> >
> > There are potential problems if not all of the features are supported
> > by the server. The command likely will be rejected with an error code,
> > no feature will be enabled and the client doesn't know which subcommand
> > was responsible for the problem.
>
> The ENABLE command in IMAP does:
>
> - If the argument is not an extension known to the server, the server
> MUST ignore the argument.
>
> - If the argument is an extension known to the server, and it is not
> specifically permitted to be enabled using ENABLE, the server MUST
> ignore the argument. (Note that knowing about an extension doesn't
> necessarily imply supporting that extension.)

Anything unknown or not permitted is ignored.

> - If the argument is an extension that is supported by the server and
> that needs to be enabled, the server MUST enable the extension for
> the duration of the connection. At present, this applies only to
> CONDSTORE ([RFC4551]). Note that once an extension is enabled,
> there is no way to disable it.
>
> The ENABLE command can be issued multiple times in a session. It is
> additive; i.e., "ENABLE a b", followed by "ENABLE c" is the same as a
> single command "ENABLE a b c".

Could be simplified by only allowing one extension per command:

ENABLE a
ENABLE b
ENABLE c
> The server MUST NOT change the CAPABILITY list as a result of
> executing ENABLE; i.e., a CAPABILITY command issued right after an
> ENABLE command MUST list the same capabilities as a CAPABILITY
> command issued before the ENABLE command.
>
>
> For the last point about going on advertising the capability, I am
> unsure we should do the same for NNTP, if we use ENABLE. Once the
> maximum article number is negotiated, it cannot be changed a second
> time, so there's no need in advertising the capability.

For IMAP this would match the case "not specifically permitted to be
enabled using ENABLE" (should be ignored, if enabled again).

> > The client has to parse the response
> > for information or test all features individually.
> > In theory this should not happen, if the client has parsed CAPABILITIES
> > carefully, but in real world there may be bugs somewhere.
>
> I agree that parsing ENABLE commands and results without error will be
> challenging...
> It is far more work than unique commands, one per feature.
>
> Capability list:
> [S] ENABLE MAXARTNUM=18446744073709551615 UTF8=NEWSGROUPS,HEADERS
> NULCHARS MAXRESPLINES=4096
> (or a variant on several lines with individual MAXARTNUM, UTF8 and
> MAXRESPLINES capabilities - not needed for NULCHARS)
>
> Command:
> [C] ENABLE MAXARTNUM=9223372036854775807 UTF8=NEWSGROUPS MAXRESPLINES=2048
> [S] 206 UTF8=NEWSGROUPS MAXARTNUM=9223372036854775807 MAXRESPLINES=2048
>
> Responding what has been enabled, without trailing comment.
>
> We may have instead of a 501 syntax error, not giving useful information:
> [C] ENABLE MAXARTNUM=badnumber UTF8=NONE MAXRESPLINES=2048
> [S] 506 MAXARTNUM UTF8
> (new error code to indicate syntax error in recognized commands, listed
> after 506, and MAXRESPLINES is not enabled)
> Or we can just use 501 without that complexity.
>
> A bit of work...

Because adoption of new features is already so slow for Usenet, I think
we should look for a simpler solution.
> > I would prefer simplicity, this means only one feature per command.
> > But maybe the toplevel command "ENABLE", to enable/negotiate features,
> > is useful to share the same return codes for all features.
>
> Defining shared return codes, and enabling all features in only 1
> command, may be the only advantages for ENABLE.
> I don't know if that's worth the extra work in complexity of
> coding/debugging/getting it right.
> Notably if we end up only having MAXARTNUM as a feature to enable...

Maybe for VERSION 3, if there would really be a lot of extensions.

> > C ENABLE UTF-8=ACCEPT
> > S 500
>
> Might be 503 (feature not supported) in case the extension is unknown
> to the server. (500 is for the base command.)

Yes, 500 only if ENABLE itself would be not supported.

> > This has to be done only once per session and the additional roundtrip
> > times should be acceptable if the number of features is small.
>
> We already have many roundtrips in sessions like this one, where the
> client sends CAPABILITIES several times:
>
> CAPABILITIES (gosh, MODE-READER is advertised)
> MODE READER
> CAPABILITIES (gosh, there is no argument to AUTHINFO)
> STARTTLS
> CAPABILITIES (yes, I can now authenticate)
> AUTHINFO USER
> AUTHINFO PASS
> CAPABILITIES (I now have more capabilities available)
> COMPRESS DEFLATE
> ENABLE MAXARTNUM=18446744073709551615
>
> And now after 10 commands (sic), I can send LIST ACTIVE & co.
>
> Using implicit TLS on port 563, which is the most wide-spread
> situation, we have 4 less commands.

For your server I already have 8 commands even with implicit TLS and
without MODE-READER:

CAPABILITIES
AUTHINFO USER
AUTHINFO PASS
CAPABILITIES
COMPRESS DEFLATE
CAPABILITIES
LIST OVERVIEW.FMT
LIST DISTRIB.PATS

Would be 9 commands with MAXARTNUM.

The capability refresh after COMPRESS may be required because flnews
supports immediate and 480-triggered authentication (the order listed
above is not guaranteed).

<https://www.rfc-editor.org/rfc/rfc8054#section-2.2.2>
|
| [...], a server MUST either list the AUTHINFO capability with
| no arguments or not advertise it at all, in response to a
| CAPABILITIES command received from an unauthenticated client after a
| successful use of the COMPRESS command, [...]

> Seems reasonable after all to have separate commands (MAXARTNUM, and
> other possible future extensions) instead of ENABLE...

Agreed.

Re: Proposal specifications for MAXARTNUM

<tpbhpq$cd9b$1@news.trigofacile.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=1339&group=news.software.nntp#1339

 copy link   Newsgroups: news.software.nntp
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.trigofacile.com!.POSTED.176.143-2-105.abo.bbox.fr!not-for-mail
From: iul...@nom-de-mon-site.com.invalid (Julien ÉLIE)
Newsgroups: news.software.nntp
Subject: Re: Proposal specifications for MAXARTNUM
Date: Sat, 7 Jan 2023 11:33:30 +0100
Organization: Groupes francophones par TrigoFACILE
Message-ID: <tpbhpq$cd9b$1@news.trigofacile.com>
References: <tnqm14$35bas$1@news.trigofacile.com>
<tou5si$1na9g$1@dont-email.me> <tp53et$7clk$1@news.trigofacile.com>
<AABjtplGZckAAAqY.A3.flnews@WStation7.micha.freeshell.org>
<tp76sd$90fs$2@news.trigofacile.com>
<AABjuUUYqSEAAAnM.A3.flnews@Server4.micha.freeshell.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 7 Jan 2023 10:33:30 -0000 (UTC)
Injection-Info: news.trigofacile.com; posting-account="julien"; posting-host="176.143-2-105.abo.bbox.fr:176.143.2.105";
logging-data="406827"; mail-complaints-to="abuse@trigofacile.com"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.6.1
Cancel-Lock: sha1:+djGT9JO1+gAm+v5syujUSglYlA= sha256:ErwknOHb9RrrYIspp6/m/9bGFWedsQ9qCE+DvwwQJz8=
sha1:6Bclk43W3pcLl3uTcmGEkUTGjrg= sha256:jlY3R3Q3UOhZKM+dd5ZkI0Qd6F4CzewqdQevGMYFozI=
In-Reply-To: <AABjuUUYqSEAAAnM.A3.flnews@Server4.micha.freeshell.org>
 by: Julien ÉLIE - Sat, 7 Jan 2023 10:33 UTC

Hi Michael,

>> We may have instead of a 501 syntax error, not giving useful information:
>> [C] ENABLE MAXARTNUM=badnumber UTF8=NONE MAXRESPLINES=2048
>> [S] 506 MAXARTNUM UTF8
>> (new error code to indicate syntax error in recognized commands, listed
>> after 506, and MAXRESPLINES is not enabled)
>> Or we can just use 501 without that complexity.
>>
>> A bit of work...
>
> Because adoption of new features is already so slow for Usenet, I think
> we should look for a simpler solution.

Agreed.

> For your server I already have 8 commands even with implicit TLS and
> without MODE-READER:
>
> CAPABILITIES
> AUTHINFO USER
> AUTHINFO PASS
> CAPABILITIES
> COMPRESS DEFLATE
> CAPABILITIES
> LIST OVERVIEW.FMT
> LIST DISTRIB.PATS
>
> Would be 9 commands with MAXARTNUM.

Oh yes, I had forgotten about these useful generic LIST requests.
When and if flnews supports automatic display of the message of the day
(when changed from a previous session), it will also be another LIST
MOTD command to send...
You may also have generic LIST SUBSCRIPTIONS (only on 1st connection on
a news server probably) so it does not really count, and LIST HEADERS if
you use HDR commands.

Also wondering whether a news reader couldn't periodically check for new
newsgroups and propose them to the user? (with an option like "check
and advertise new newsgroups every XX days", which would refresh the
list and propose new newsgroups from NEWGROUPS or LIST ACTIVE.TIMES
commands, or maybe direct check in LIST ACTIVE because a news server may
not maintain the information)

> The capability refresh after COMPRESS may be required because flnews
> supports immediate and 480-triggered authentication (the order listed
> above is not guaranteed).
>
> | [...], a server MUST either list the AUTHINFO capability with
> | no arguments or not advertise it at all, in response to a
> | CAPABILITIES command received from an unauthenticated client after a
> | successful use of the COMPRESS command, [...]

OK, then it would be 9 commands if COMPRESS is sent before AUTHINFO.
Otherwise, only 8 commands because sending CAPABILITIES after COMPRESS
when the user is already authenticated is normally not useful, is it?

--
Julien ÉLIE

« – Ben où est l'eau ?
– Elle est sortie quand tu es entré Obélix. Il n'y a pas de place pour
vous deux là dedans ! » (Astérix)

Re: Proposal specifications for MAXARTNUM

<AABjuW2WIpIAAAxz.A3.flnews@WStation7.micha.freeshell.org>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=1340&group=news.software.nntp#1340

 copy link   Newsgroups: news.software.nntp
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.imp.ch!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: michael....@gmx.net (Michael Bäuerle)
Newsgroups: news.software.nntp
Subject: Re: Proposal specifications for MAXARTNUM
Date: Sat, 7 Jan 2023 14:03:18 +0100 (CET)
Lines: 66
Message-ID: <AABjuW2WIpIAAAxz.A3.flnews@WStation7.micha.freeshell.org>
References: <tnqm14$35bas$1@news.trigofacile.com> <tou5si$1na9g$1@dont-email.me> <tp53et$7clk$1@news.trigofacile.com> <AABjtplGZckAAAqY.A3.flnews@WStation7.micha.freeshell.org> <tp76sd$90fs$2@news.trigofacile.com> <AABjuUUYqSEAAAnM.A3.flnews@Server4.micha.freeshell.org> <tpbhpq$cd9b$1@news.trigofacile.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=fixed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net tVRCmLLZGSmswyUIpJLBugq1PsIzP96fRDTRnOWaIf9z6bHYPl
X-Orig-Path: not-for-mail
Cancel-Lock: sha1:vQoVvQtb8o5y9BqGlmkxFKE5VOI= sha256:fI1Cwd6IzzUcSw1gqUgC4/OahvIkzW/+L5tVRF2QmxM= sha1:XvAhpipY2kj2B+EOAAJI6GRg2CU=
Injection-Date: Sat, 7 Jan 2023 13:03:18 -0000
User-Agent: flnews/1.2.0pre17 (for GNU/Linux)
 by: Michael Bäuerle - Sat, 7 Jan 2023 13:03 UTC

Julien ÉLIE wrote:
> Michael Bäuerle wrote:
> >
> > [...]
> > For your server I already have 8 commands even with implicit TLS and
> > without MODE-READER:
> >
> > CAPABILITIES
> > AUTHINFO USER
> > AUTHINFO PASS
> > CAPABILITIES
> > COMPRESS DEFLATE
> > CAPABILITIES
> > LIST OVERVIEW.FMT
> > LIST DISTRIB.PATS
> >
> > Would be 9 commands with MAXARTNUM.
>
> Oh yes, I had forgotten about these useful generic LIST requests.
> When and if flnews supports automatic display of the message of the day
> (when changed from a previous session), it will also be another LIST
> MOTD command to send...

MOTD is supported, but only from the menu (must be explicitly requested
by the user).

> You may also have generic LIST SUBSCRIPTIONS (only on 1st connection on
> a news server probably) so it does not really count,

This is supported too.

> and LIST HEADERS if
> you use HDR commands.

I have never used HDR.

> Also wondering whether a news reader couldn't periodically check for new
> newsgroups and propose them to the user? (with an option like "check
> and advertise new newsgroups every XX days", which would refresh the
> list and propose new newsgroups from NEWGROUPS or LIST ACTIVE.TIMES
> commands, or maybe direct check in LIST ACTIVE because a news server may
> not maintain the information)

Sounds useful. But currently flnews does not store lists of "all"
groups, neither former nor current.

The group list is loaded again for the subscription window every time
(via LIST in RFC 977 mode or LIST ACTIVE).

Normally only the subscribed groups are used.

> > The capability refresh after COMPRESS may be required because flnews
> > supports immediate and 480-triggered authentication (the order listed
> > above is not guaranteed).
> >
> > | [...], a server MUST either list the AUTHINFO capability with
> > | no arguments or not advertise it at all, in response to a
> > | CAPABILITIES command received from an unauthenticated client after a
> > | successful use of the COMPRESS command, [...]
>
> OK, then it would be 9 commands if COMPRESS is sent before AUTHINFO.
> Otherwise, only 8 commands because sending CAPABILITIES after COMPRESS
> when the user is already authenticated is normally not useful, is it?

The current logic is not smart enough for that and the refresh is always
executed.

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor