[NNTP] [dispatch] PROPOSAL: NNTP Working Group

[Julien ÉLIE]

Hi all,

Le 15/03/2020 à 16:32, Dale R. Worley a écrit :
> Read News <netnewsmaster at gmail.com> writes:
>> I am writing this email today to see what you would think of an extension
>> of the NNTP (Usenet/Netnews) protocol. The last major update to the NNTP
>> protocol was in 2006, and the last minor update was in 2010. Since then,
>> the total amount of binaries on Usenet has extended by 10 fold.
>>
>> Usually, this would be cause for no concern, since "if it aint broken;
>> don't fix it". However, the sheer massive amounts of these articles have
>> caused some new nonstandardilzed additions to the NNTP protocol between
>> large scale peers. One of these additions are 64-bit article numbers, which
>> was specifically prohibited in 2006 in RFC 3977 but has been added anyway
>> since many newsgroups have exceeded the 2 billion article mark and Usenet
>> providers like HW Media keep articles for a *very* long time. There are
>> many other "unstandarlized" extensions to the NNTP protocol like commands
>> relating to hybrid feeds, binary article feeding, compressed articles, etc.

Yes, standardizing something about how to deal with 64-bit article 
numbers is worthwhile.  Some people already shared ideas about that.
Same thing for headers-only/hybrid/hash feeds, PAT command with extended 
wildmat format and a few other features.
There is a list of errata to RFC 3977 that should be dealt with, 
possibly leading to Version 3 of NNTP.
We also need to standardize internationalized Netnews headers.

As for compressed articles, note that RFC 8054 took care of it with the 
COMPRESS command standardized in 2017:

    It is currently addressed only partially by unstandardized commands
    like XZVER, XZHDR, XFEATURE COMPRESS, or MODE COMPRESS.  Yet, these
    commands are not wholly satisfactory because they enable compression
    only for the responses sent by the news server.  In comparison, the
    COMPRESS command permits the compression of data sent by both the
    client and the server, and removes the constraint of having to
    implement compression separately in each NNTP command.  Besides, the
    compression level can be dynamically adjusted and optimized at any
    time during the connection, which even allows disabling compression
    for certain commands, if needed.  If the news client wants to stop
    compression on a particular connection, it can simply use QUIT
    ([RFC3977], Section 5.4) and establish a new connection.  For these
    reasons, using other NNTP commands than COMPRESS to enable
    compression is discouraged once COMPRESS is supported.



>> To accomplish standardization of these features, I was wondering if any of
>> you would be interested in contributing to and setting up this WG. I know a
>> fair bit of people who are interested in working on it, and I wanted to see
>> what it would take to get something like this rolling. Thank you!
> 
> It sounds to me like there's good reason to undertake this work.  I
> myself probably won't be participating.  But the first step is to get
> five or 10 of the people who are interested in working on it to say so
> on this mailing list.  Then it shouldn't be hard to get a working group
> chartered.

I've added the list of the former NNTP working group in the discussion. 
Maybe people there will be interested in reviving the WG!

As far as I am concerned, I'm willing to participate.

-- 
Julien ÉLIE

« Passion is inversely proportional to the amount of real information
   available. » (Benford's law)