[NNTP] Additions to LIST commands

[Russ Allbery]

Julien ÉLIE <julien at trigofacile.com> writes:

>> For the new LIST ACTIVE flags, no CAPABILITIES line should be required
>> since the client doesn't need to know whether or not the server might send
>> these flags before the server sends them.  That was intentional in how we
>> defined LIST ACTIVE in RFC 3977:
>>
>>   Other values for the status may exist; the definition of these other
>>   values and the circumstances under which they are returned may be
>>   specified in an extension or may be private to the server.  A client
>>   SHOULD treat an unrecognized status as giving no information.

> But what for that MUST in RFC 3977?

>   "Each extension MUST define at least one new capability label (this
>   will often, but need not, be the name of one of these new commands)."

Oh, good point.  I'm not sure that defining the meaning of those flags
quite counts as an extension in the way that we were thinking of, but I
suppose that we could do something like:

    ACTIVE FLAG-J FLAG-N FLAG-ALIAS

as an extension label, which would expand to any other new features of the
active file that one wants to specify later.

> I do not know whether "l" can be used with INN because innd injects the
> article and it does not always have the information about the source
> (depending on the presence of Unix domain sockets, or a different
> nnrpdposthost) to decide if it is local.  (?)  Anyway, other news
> servers may know that better.

It would be a bit tricky to implement in INN, yes.

> As for "r", is it OK to have either "r" or "r1258739643" (time since
> epoch)?

That would be kind of a neat feature, but I'm not sure that encoding it in
the active file is the best place to return that information.  I'd be more
tempted to add a new list, like LIST REMOVALS [wildmat], that shows
upcoming groups to be removed to avoid putting too much different data
into the active file.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>