Hey,

I was wondering what the practical differences were between OVER and XOVER.
It looks like XOVER is specified in RFC 2980 while OVER is specified in the newer RFC 3977. Also it seems like OVER supports the same syntax as XOVER
along with a message-id argument. From what I can tell, slrn 1.0.3 sends
XOVER instead of OVER. Is OVER actually in use right now?

- meff

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-12-26, meff <email@example.com> wrote:

along with a message-id argument. From what I can tell, slrn 1.0.3 sends XOVER instead of OVER. Is OVER actually in use right now?

To partially answer my own question, it seems like slrn pre-emptively sends an XOVER, on failure of that an XHDR, and on failure of that a LIST OVERVIEW.FMT. The last one _is_ valid under RFC 3977.

- meff

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

meff wrote:

[...]
I was wondering what the practical differences were between OVER and XOVER.

OVER has a corresponding capability: <https://datatracker.ietf.org/doc/html/rfc3977#section-3.3.2>

It looks like XOVER is specified in RFC 2980 while OVER is specified in the newer RFC 3977. Also it seems like OVER supports the same syntax as XOVER along with a message-id argument. From what I can tell, slrn 1.0.3 sends XOVER instead of OVER. Is OVER actually in use right now?

flnews uses OVER if the corresponding capability is advertised by the
server.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Meff,

I was wondering what the practical differences were between OVER and XOVER. It looks like XOVER is specified in RFC 2980 while OVER is specified in the newer RFC 3977. Also it seems like OVER supports the same syntax as XOVER along with a message-id argument. From what I can tell, slrn 1.0.3 sends XOVER instead of OVER. Is OVER actually in use right now?

Like Michael said, OVER should be used if CAPABILITIES is supported by
the news server, and OVER is present. Otherwise, XOVER should be tried.

You well noted the new OVER <msgid> syntax.

The 423 return code when there are no articles in the given range is new
in RFC 3977, and used by OVER. In that case, XOVER responds 224 (OK)
with an empty list of overview lines.

In the response, OVER will return the real number of bytes and lines of
the article (known as :bytes and :lines medatada).
The description of how each item returned by OVER is precise.
I believe implementations of XOVER pre-dating RFC 3977 may sometimes
return data not totally following the expected rewrite of spaces and
like. They may also return the contents of the Bytes and Lines header
fields if present, instead of real computed values by the news server.

--
Julien ÉLIE

« Nous avons mergitur, mon vieux, et je ne sais pas quand nous allons
fluctuat de nouveau ! » (banquier romain)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

For your reference, records indicate that
meff <email@example.com> wrote:

On 2021-12-26, meff <email@example.com> wrote:

along with a message-id argument. From what I can tell, slrn 1.0.3 sends XOVER instead of OVER. Is OVER actually in use right now?

To partially answer my own question, it seems like slrn pre-emptively sends an
XOVER, on failure of that an XHDR, and on failure of that a LIST OVERVIEW.FMT.
The last one _is_ valid under RFC 3977.

It’s essentially *necessary*, by my reading of the RFCs (admittedly, I
wrote my NNTP framework years ago, so my exact thinking on it is fuzzy
at this point). My process is to:

1. Unconditionally fetch the supported capabilities.
2. Unconditionally fetch the overview format.
3. Conditionally fetch the overviews via OVER if supported, XOVER if not.

I don’t even bother with XHDR (or HDR). I can’t imagine anyone bothering to run a server that doesn’t support overviews at this point.

--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Doc O'Leary <droleary@2017usenet1.subsume.com> writes:

It’s essentially *necessary*, by my reading of the RFCs (admittedly, I wrote my NNTP framework years ago, so my exact thinking on it is fuzzy
at this point). My process is to:

1. Unconditionally fetch the supported capabilities.
2. Unconditionally fetch the overview format.
3. Conditionally fetch the overviews via OVER if supported, XOVER if not.

I don’t even bother with XHDR (or HDR). I can’t imagine anyone
bothering to run a server that doesn’t support overviews at this point.

I'm not sure I would fetch the overview format, btw, unless you care about
any possible supplemental fields. The first seven fields are fixed; implementations aren't allowed to change them (and I don't know of any
that do).

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)