• Re: New error in SLRN

    From Ray Banana@21:1/5 to All on Tue Mar 14 20:23:40 2023
    XPost: news.software.readers

    * RonB wrote:
    I don't know what this error means. Just showed up today. I use news.eternal-september.org.

    OVERVIEW.FMT not RFC 2980 compliant -- XOVER support disabled.

    Is it something to do with slrn or an issue with the news server? I use slrn 1.0.3.

    This is slrn failing to parse the new OVERVIEW.FMT in INN 2.8.
    See Julièn's post from last July in <tc6fmu$2q025$1@news.trigofacile.com>.

    I must admit that slrn without XOVER is painfully slow and so I'm reverting
    to the previous version of INN for now.

    From a practical point of view, I wonder what the benefit of the new format is, especially as the articles contain the Bytes: and Lines: headers in the traditional
    format.

    --
    Пу́тін — хуйло́
    http://www.eternal-september.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Thu Mar 16 09:06:18 2023
    Hi Wolfgang,

    OVERVIEW.FMT not RFC 2980 compliant -- XOVER support disabled.

    Is it something to do with slrn or an issue with the news server? I use slrn >> 1.0.3.

    This is slrn failing to parse the new OVERVIEW.FMT in INN 2.8.
    See Julièn's post from last July in <tc6fmu$2q025$1@news.trigofacile.com>.

    I must admit that slrn without XOVER is painfully slow and so I'm reverting to the previous version of INN for now.

    From a practical point of view, I wonder what the benefit of the new format is

    Disambiguating metadata items computed by the server (:bytes and :lines)
    and the real contents of the headers (Bytes: and Lines:). It is for consistency with the use of these strings in other commands.

    HDR :bytes <mid>
    HDR Bytes <mid>
    may not return the same results.



    especially as the articles contain the Bytes: and Lines: headers in the traditional
    format.

    Is slrn 1.0.3 sending CAPABILITIES?

    Maybe the best move here is to use the "preferred format" per RFC 3977
    with :bytes and :lines advertised in LIST OVERVIEW.FMT only when the
    news reader has previously used CAPABILITIES? And we keep Bytes: and
    Lines: otherwise.


    Thanks again Wolfgang for running the latest development version of INN.
    It permits finding these sorts of compatibility issues before stable releases.

    --
    Julien ÉLIE

    « Mieux vaut prendre le changement par la main avant qu'il ne nous
    prenne par la gorge. » (Winston Churchill)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ray Banana@21:1/5 to All on Fri Mar 17 12:57:26 2023
    * Julien ÉLIE wrote:

    Disambiguating metadata items computed by the server (:bytes and :lines)
    and the real contents of the headers (Bytes: and Lines:). It is for consistency with the use of these strings in other commands.

    HDR :bytes <mid>
    HDR Bytes <mid>
    may not return the same results.

    I see. Haven't been aware of this.
    Thanks for the clarification.

    Is slrn 1.0.3 sending CAPABILITIES?

    No.

    Maybe the best move here is to use the "preferred format" per RFC 3977
    with :bytes and :lines advertised in LIST OVERVIEW.FMT only when the
    news reader has previously used CAPABILITIES? And we keep Bytes: and
    Lines: otherwise.

    I'm not sure of the correlation between clients using CAPABILITIES and clients using LIST OVERVIEW.FMT. In slrn's case it would certainly work.

    --
    Пу́тін — хуйло́
    http://www.eternal-september.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Ray Banana on Fri Mar 17 12:03:35 2023
    Ray Banana <rayban@raybanana.net> writes:
    * Julien ÉLIE wrote:

    Maybe the best move here is to use the "preferred format" per RFC 3977
    with :bytes and :lines advertised in LIST OVERVIEW.FMT only when the
    news reader has previously used CAPABILITIES? And we keep Bytes: and
    Lines: otherwise.

    I'm not sure of the correlation between clients using CAPABILITIES and clients using LIST OVERVIEW.FMT. In slrn's case it would certainly work.

    The underlying issue is that LIST OVERVIEW.FMT changed somewhat during its standardization process from what it was like before RFC 3977,
    specifically to add the metadata syntax. CAPABILITIES was added in RFC
    3977, so older clients that don't understand the new syntax presumably
    also won't send that command.

    --
    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)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Fri Mar 17 20:08:58 2023
    Hi Wolfgang,

    Is slrn 1.0.3 sending CAPABILITIES?

    No.

    Maybe the best move here is to use the "preferred format" per RFC 3977
    with :bytes and :lines advertised in LIST OVERVIEW.FMT only when the
    news reader has previously used CAPABILITIES? And we keep Bytes: and
    Lines: otherwise.

    I'm not sure of the correlation between clients using CAPABILITIES and clients
    using LIST OVERVIEW.FMT. In slrn's case it would certainly work.

    As the CAPABILITIES command has been added in RFC 3977 which defines
    Version 2 of NNTP, my guess is that a news client which uses that
    command has been updated to conform with RFC 3977.
    Of course, that may not be true but such a client would then not be
    compliant with servers which are supposed to followed this MUST...

    The first 7 lines [of the LIST OVERVIEW.FMT response] MUST (except
    for the case of letters) be exactly as follows:

    Subject:
    From:
    Date:
    Message-ID:
    References:
    :bytes
    :lines

    For compatibility with existing implementations, the last two lines
    MAY instead be:

    Bytes:
    Lines:

    even though they refer to metadata, not headers.


    The MAY is there so that servers could comply with both RFC 3977 and
    clients pre-dating RFC 3977. That's why I suggested that heuristics.
    Clients which have implemented RFC 3977 /normally/ shouldn't choke on
    receiving ":bytes"...
    I should really have ensured CAPABILITIES has previously been sent
    before changing the syntax in INN 2.8.0; that's a genuine bug.

    slrn currently implements RFC 977 and RFC 2980, corresponding to Version
    1 of NNTP, according to the error message it gives:
    OVERVIEW.FMT not RFC 2980 compliant -- XOVER support disabled.

    It couldn't be said when RFC 3977 is implemented...

    --
    Julien ÉLIE

    « Campagne électorale : c'est l'art de gagner les voix des pauvres avec
    l'argent des riches en promettant à chacun des deux de les protéger
    contre l'autre. » (Oscar Ameringer)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Franck@21:1/5 to All on Sat Mar 18 07:21:42 2023
    Hello Julien,

    Before or after a CAPABILITIES command, in LIST OVERVIEW.FMT, I'm
    currently sending:

           Subject:
           From:
           Date:
           Message-ID:
           References:
           :bytes
           :lines


    HDR :bytes sends metadata.
    HDR Bytes: sends value of header "Bytes".

    If I understand well, you are suggesting to send :bytes and :lines (in
    LIST OVERVIEW.FMT) after CAPABILITIES was sent otherwise to send Bytes:
    and Lines:?

    Correct?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Sat Mar 18 08:50:20 2023
    Hi Franck,

    HDR :bytes sends metadata.
    HDR Bytes: sends value of header "Bytes".

    "HDR Bytes" without the ending semi-colon for the second form.


    If I understand well, you are suggesting to send :bytes and :lines (in
    LIST OVERVIEW.FMT) after CAPABILITIES was sent otherwise to send Bytes:
    and Lines:?

    Correct?

    Exactly. Otherwise, current slrn version cannot access overview data.
    A few other news clients may also not deal with that new syntax
    introduced with NNTP version 2.

    Wolfgang, the fix is committed for INN 2.8.0. You can re-install this
    version whenever you want. (If you're using generated snapshots, the
    20230318 one will have it.)

    --
    Julien ÉLIE

    « Sol attigit talos. »

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Franck@21:1/5 to All on Sat Mar 18 09:43:19 2023
    Hello Julien,

    "HDR Bytes" without the ending semi-colon for the second form.

    Yes, it was a typo of mine.

    Exactly.  Otherwise, current slrn version cannot access overview data. A
    few other news clients may also not deal with that new syntax introduced
    with NNTP version 2.

    Ok, I'll update SNS to reflect this.
    Thanks for confirmation.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ray Banana@21:1/5 to All on Sat Mar 18 14:58:30 2023
    * Julien ÉLIE wrote:

    Wolfgang, the fix is committed for INN 2.8.0. You can re-install this version whenever you want. (If you're using generated snapshots, the 20230318 one will have it.)

    Thanks. I will try 20230318 then.
    BTW: I was informed that John Davis is working on a solution for slrn.
    I will test that, too, once it's available on github.

    --
    Пу́тін — хуйло́
    http://www.eternal-september.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ray Banana@21:1/5 to All on Mon Mar 20 16:37:22 2023
    Thus spake Ray Banana <rayban@raybanana.net>

    * Julien LIE wrote:
    Wolfgang, the fix is committed for INN 2.8.0. You can re-install this
    version whenever you want. (If you're using generated snapshots, the
    20230318 one will have it.)
    Thanks. I will try 20230318 then.

    slrn 1.0.3 is happy with inn-CURRENT-20230319.

    Thanks, Julien.

    --
    Too many ingredients in the soup, no room for a spoon http://www.eternal-september.org

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