ietf-nntp new draft of base document available

[Russ Allbery]

Charles Lindsey <chl at clw.cs.man.ac.uk> writes:

> 1. NEWNEWS would seem easy to fix. Presumably the following is meant to
> work:

> NEWNEWS news.announce.*,!news.announce.conferences

> It works fine in current INN implementations. A text could easily be
> written for this special case, but first we need to see whether there is
> a more general solution.

I'm personally of the opinion that comma and ! should just be added to the
description of the wildmat language.  (It may be worthwhile to add @ too
while we're at it, as it allows an easier implementation without having to
use separate wildmat routines that use poison entries, but INN is
currently the only user of poison wildmats and doesn't currently expose
them over protocol, so we may have to solve our own problems there.)  The
advantage of doing it this way is that all commands immediately pick up
the additional functionality without needing a special description and all
working exactly the same way, plus it means that one can then escape
commas (although it should be mentioned that this may not work with all
servers).

> 2. Do we want the same behaviour in LIST NEWSGROUPS and friends? I.e.:

> LIST NEWSGROUPS news.announce.*,!news.announce.conferences

> That is not allowed in the current draft (there is only 1 wildmat
> allowed) but is seems a reasonable thing to expect. Does INN do it, and
> if not can it go into our present draft without getting involved in
> extensions?

INN does not currently, but will shortly.

I currently intend to rewrite INN's wildmat code along the lines I
describe above, making , and ! first-class citizens in the wildmat
routine.  I've checked every use of wildmat in the INN source base, and so
far as I can tell this will either not change anything or make available
useful additional functionality in every case.  Unless unforseen problems
arise, this will be in INN 2.4.

> 3. The main problem, for me, is PAT, because I just don't know what is
> MEANT to happen. But at least PAT is a new command (it used to be XPAT),
> so some tweaks of the syntax might be allowed. Three questions:

> a) Why is it a space-separated list of wildmats here, rather than a
> comma separated list?

> b) Is it meant to accept a header that matches ANY of the wildmats, or a
> header that matches ALL of the wildmats?

> c) Is it meant to match the WHOLE of the header (usually a Subject line)
> or is it sufficient to match a string in the middle?

Existing practice here is actually rather interesting.  At least for the
XPAT and XHDR commands as implemented in INN, these aren't multiple
wildmats in the sense that you're thinking of at all.  Any space between
the wildmats is collapsed down to a single space and then the entire thing
is taken as the pattern to match.  So, for example:

    PAT subject - Re: *nntp* *extension

would match any Subject line that matched precisely the wildmat:

    Re: *nntp* *extension

with spaces treated as significant.  wildmat is implicitly anchored, so
this would result in matching any subject beginning with exactly "Re: "
(no leading space), followed by any number of characters containing
"nntp", followed by at least one literal space and any number of
additional characters, and then ending in "extension" with no trailing
spaces or other characters.

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