[NNTP] Additions to LIST commands

Julien ÉLIE julien at trigofacile.com
Fri Nov 20 11:27:42 PST 2009


Hi Russ,

>> 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-X FLAG-ALIAS
>
> as an extension label, which would expand to any other new features of the
> active file that one wants to specify later.

The problem is that if something like that is done, it makes more difficult
a possible integration of these flags into a future update to RFC 3977
(VERSION 3 of the protocol).
And it doesn't seem homogeneous to have all these keywords if we do not
also have FLAG-Y, FLAG-N and FLAG-M.

Besides, it would need to have two separate documents:  one for the ACTIVE
extension, and one for the additions to LIST.

Last but not least, we will have the same problem for an extension of wildmats
and metadata items...
It is very unclear how to extend them too.


>> 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.

Unless we say, in the documentation of INN, that "l" works only
if the server has Unix domain sockets.  And, for other cases (or to
handle inews, nnrpdposthost...), we could add a parameter in incoming.conf
(localpost: yes) to allow postings to "l" groups for the connection
which has localpost set to yes.  One could add here "localhost" or the IP
of his server.


>> 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.

So we would have "r" in the active file.
And LIST REMOVALS would return the relevant information as for the removal.
That seems great!  Thanks for the idea.

(I would suggest LIST ACTIVE.REMOVALS but LIST REMOVALS seems better.)

-- 
Julien ÉLIE

« Rien n'est plus agaçant que de ne pas se rappeler ce dont on ne parvient
  pas à se souvenir et rien n'est plus énervant que de se souvenir de ce qu'on
  voudrait parvenir à oublier. » (Pierre Dac) 



More information about the ietf-nntp mailing list