ietf-nntp new draft of base document available

Charles Lindsey chl at clw.cs.man.ac.uk
Mon Jul 17 13:06:39 PDT 2000


In <200007140545.AAA19326 at academ.com> sob at academ.com (Stan Barber) writes:


>A new draft of the base document has been sent to the Internet Drafts folks.

>A copy is available at ftp://ftp.academ.com/pub/nntp/ietf/nntpext.txt.

>The diffs from the previous release are available at this URL:
>	ftp:///ftp.academ.com/pub/nntp/ietf/nntp-diffs.txt

>In this version, all the changes suggested by Clive Feather on the previous
>draft have been consider in this update with the except of those that
>relate to including pipelining in the draft.

Yes, those look fine, but you still have not addressed the problems with
the wildmat, or with the cpommand that use it, that I have been raising
for nearly two years now.

Here is what I wrote on 10 Nov 1999, followed by what I wrote on 15 Nov. I
have no solutions to these problems to propose yet, for the simple reason
that I don't even know what is MEANT to happen in the given cases. But
these sure are bugs in the present draft, and they need to be fixed
somehow.

------------------------------------------------------------------------------

>Does this mean all of subsequent wildmats patterns is negated?
>I.e. "!alt.*,junk" means to negate both alt.* and junk?

No, but there is still so much left undefined about the new wildmat format
that the mind boggles.

Look first at the NEWNEWS command, where you have a comma-separated list
of wildmats. Presumably you are asking to see the disjunction of the list;
i.e. if a group matches any wildmat in the list, you want it, as in

NEWNEWS news.announce.*,news.admin.* ...
(so I don't get, for example, news.answers)

Now try

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

The draft, as currently written, seems to give me the whole of news.*!.
For example, 'news.answers' matches "!news.announce.conferences" and
'news.announce.conferences' matches "news.announce.*".

That is clearly not what was intended, and it is clearly not what current
implementations do, and it conflicts with RFC 977. So we need something
that recognises that a '!' wildmat serves to exclude things that were
included by wildmats earlier in the list (so the order of the list becomes
important).

And note also that the syntax of a comma-separated list is itself
ambiguous, because a comma is a valid character in a wildmat. The only
reason it works here is that commas cannot occur in newsgroup-names.

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

would be quite different. Presumably it gives you everything there is (all
of alt.*, all of comp.*, etc) except the conferences, and the second entry
is redundant because it is already included in the first.

Now look at the PAT command, which has a space-separated list of wildmats.
Again, it does not say whether these are a conjunction or a disjunction,
let alone whether the order matters. And the example given does not
resolve the matter:

PAT Subject ... j* ? *est

Does that mean the subject has to match ALL of "j*", "?", and "*est" or
just one of them? It does not say. The example quoted is 'I am just a test
article' which does not actually match any of them (you are supposed to
anchor the pattern to both ends of the string accoding to section 5). But
the semantics for PAT is silent on the issue (if does not even say that
the
wildmat is supposed to be matched at all - you have to read between the
lines to deduce even that). Note also that a wildmat cannot include a
space, so the space-separated list of wildmats is OK (you use "\ " if you
really want to match a space).

Now look at LIST NEWSGROUPS (and others with a similar single wildmat in
them).

LIST NEWSGROUPS !alt.*

is clear enough, but suppose I want to see all of alt.* except the
binaries:

LIST NEWSGROUPS alt.*,!alt.binaries.*

would seem to do the right thing (it would work in the NEWNEWS command),
but no, that is not allowed because there are two wildmats there, and you
are allowed only one. Why can we not have a comma separated list of
wildmats in all cases where a wildmat is currently allowed (or,
alternatively, introduce a comma operator within the wildmat)?

And finally, there are errors in the collected syntax at the end. It says

newnews-command = "NEWNEWS" 1*WSP newsgroup *("," newsgroup) ...
newsgroup = parameter
parameter = 1*(%x21-FF)

Surely that should be

newsgroup = wildmat

Also, at the start of the collected syntax there is a rule "augment"
which, I am pretty sure, is meant to be "argument".

And finally, finally, can I remind you that I raised all these exact
issues in December 1998, and since then we have had two drafts which have
not corrected them. PLEASE can we have discussions of these texts on the
LIST. You are trying to debug a complicated program by bringing it to an
IETF meeting once a year. And if the fix does not work you wait until the
next IETF meeting to fix that, and so on.

-----------------------------------------------------------------------------

And then on 15 Nov 1999, in reply to Stan who complained I had not
provided detailed solution to these problems:



It is no use proposing texts until we have decided what effects we want.
In any case, I have my work cut out writing texts for the USEFOR draft,
and I don't really want to get involved with the nitty of NNTP.

OK, let's ask some questions.

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.

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?

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?

------------------------------------------------------------------------------

>Also, the WG is scheduled to meet in Pittsburgh on Tuesday afternoon. 
>Suggestion for agenda topics should be posted here real soon now. I expect to
>post an agenda next week.

Fine. Please can we have my two messages above on the Agenda?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     chl at clw.cs.man.ac.uk  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5



More information about the ietf-nntp mailing list