[NNTP] Suggestions for NNTP extensions (CAPABILITIES)

[Julien ÉLIE]

Hi Russ,

>>    * LIST DISTRIBUTIONS (with a wildmat for the area?)
>>    * LIST MODERATORS
>>    * LIST MOTD
>>    * LIST SUBSCRIPTIONS
>
> I certainly agree with standardizing all of these based on the INN
> implementation.  The implementations of these haven't changed in quite
> some time and for whatever they're worth to the world, we may as well
> write a specification for them.

The same as what there is in INN?  So no second argument for LIST DISTRIBUTIONS
or the others?
No new LIST keywords?


> To a reader, j groups really don't exist.  They will never contain any
> articles, and are really just an internal hint to the serving agent to
> move articles into a junk group.  nnrpd should ideally just suppress them
> from LIST ACTIVE output.
>
> To a reader, x groups are completely equivalent to n groups.  The only
> difference is the behavior of incoming new messages from peers.  nnrpd
> should probably change x to n when responding to LIST ACTIVE.

All right.  Easy to do for nnrpd.
I believe the same applies to innd (junk for j and ignore for x).


> So I think INN should actually not return any flags other than the ones
> already standardized and the alias flag.  Standardizing aliasing requires
> deciding how it's supposed to work, but I think it's a useful capability.

Isn't what INN does right for them?

    If the <flag> field begins with an equal sign, the newsgroup is an alias.
    Articles cannot be posted to that newsgroup, but they can be received
    from other sites.  Any articles received from peers for that newsgroup
    are treated as if they were actually posted to the group named after
    the equal sign.  Note that the Newsgroups: header of the articles are
    not modified.  (Alias groups are typically used during a transition
    and are typically created manually with ctlinnd(8).)  An alias should
    not point to another alias.

Just a bit of rewording for an RFC is needed.


> There are two main reasons why we didn't standardize PAT.  The first and
> most serious is whitespace handling in patterns.  Given the way that NNTP
> command parsing works, how would you search for a pattern containing two
> spaces?  And what do the spaces between patterns really mean?

We could say that a server which complies with PAT does not parse the
pattern argument the same way it would for other commands.

RFC 4643 suggests that something like that could be done:

   Note that a server MAY (but is not required to) allow white space
   characters in usernames and passwords.  A server implementation MAY
   blindly split command arguments at white space and therefore may not
   preserve the exact sequence of white space characters in the username
   or password.

It would lift the problem of spaces for a real good PAT.


> The second, as you mention below, is the encoding problem, which is very
> hairy and difficult to deal with.

Only compare octets then.  It is what XPAT does by the way.
Otherwise, if we care about encoding, we will not find a decent solution...


> IMAP has addressed the search problem at some length, and my impression
> was that it wasn't at all simple to deal with.  I'm afraid that doing a
> good job of it is going to require quite a lot of work.

It would be another extension (SEARCH for instance, if anybody wishes to
write it) and not tackled by PAT.
It would then allow to standardize a real PAT, and not only an informational
draft for XPAT; I do not know what is the best thing to do.


>> 3/ Something to deal with large article numbers.  What can be done?
>>   An extension?  But what kind of capability and use?
>
> IIRC, Clive had an extension proposal for how to deal with this.

Oh, great.  It should then be proposed to Giganews, as we discussed
last month on news.software.nntp.


> XBATCH is worth documenting.  I don't know if it's worth standardizing as
> BATCH, but I wouldn't mind at all.  Most of the work there will be
> defining the batch format, and that will depend on how many different
> transforms people feel like writing up (c7unbatch, cunbatch, gunbatch,
> etc.).

Why should it be specified what the user does with the batch?
Let's give an opaque stream of n octets.  What the news server does with
that is of no concern.  POST does not define storage methods for instance.
Or is there something I am missing?


> Does the Diablo
> implementation do streaming for header feeds?  If so, we need a
> header-only equivalent for TAKETHIS, maybe TAKEHEADER.

I think it does streaming but I am not sure.
And CHECK also needs to be split in order to know whether the news
server only has the headers (?)
And IHAVEHDR?


It makes me think that another extension could be to change the newsgroups
subscriptions of the remote peer.  FEEDADD wildmat, FEEDDEL wildmat
for instance.  Server A connects to server B and *asks* for the feed.
But the protocol will not be proper because A needs to ask for an article
and then wait.  Server B could answer a code within n seconds to say
it has no articles.  And A could ask again...
A bit complicated, though.


>> 7/ I also see QUOTA there:
>>    http://lists.eyrie.org/pipermail/ietf-nntp/2007-February/005989.html
>
> I think we'd need someone who would actually use it to write it up.

Sure.


>> 8/ INN also implements a wider syntax for wildmats (with "[" and "]" for
>>   instance).  Ranges like "-12" and "-" are also recognized in order to
>>   be more symmetric with the already defined "12-".
>>   Notwithstanding, I do not think it needs an extension for that...
>
> The wildmat extensions would be nice to write up formally, but I'm not
> sure it's worth a full extension.

But in what kind of document could it be written?
An informational draft for only 12 lines of real content?  :-)
Or in a new man page for INN?


> To write an I-D, I recommend using xml2rfc:
>
>    http://xml.resource.org/
>
> It makes the whole process much easier.  I thought there was a repository
> somewhere of the XML versions of RFCs written with xml2rfc, but I haven't
> been able to find it.

Thanks, Russ.
I saw XML templates, which are a good starting point:
    http://tools.ietf.org/tools/templates/

-- 
Julien ÉLIE

« On ne va jamais si loin que lorsque l'on ne sait pas où l'on va. »