ietf-nntp Wildmats

[Andrew Gierth]

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

 >> I reiterate my objection that a single wildmat, and a
 >> comma-delimited list of (possibly negated) wildmats, are separate
 >> syntactic entities and should not be combined in this way.

 Charles> I disagree.

well, good for you. How many news clients or servers have you written
in the past couple of years?

 >> The combined approach disguises the fact that we are making
 >> incompatible changes to commands such as LIST ACTIVE, and has no
 >> justification either from a specification or implementation point of
 >> view.

 Charles> It provides a useful extension of functionality (one which I
 Charles> would have found useful on several occasions in the past),

in which case the fast that it is new functionality should be clearly
specified

 Charles> AIUI, the extension (or something very close to it) is
 Charles> already present in INN.

actually, it's not. INN-CURRENT contains a wildmat routine that
includes support for ',','!' and '@', but it does not in fact make use
of it in a way that conforms with the proposed text. In particular,
commands like NEWNEWS that previously worked with a comma-delimited
list still split the supplied pattern on ',' characters without regard
for quoting.

 >> In fact, the present text severely interferes with attempts to
 >> handle complex pattern lists efficiently.

 Charles> I don't see why. 

I want to be able to match the components right-to-left rather than
left-to-right in some contexts (the rightmost match wins, after all).
I also special-case in some cases where no metacharacters are present,
since I have known-unique hash values already computed.

 Charles> In any case, complex pattern lists are unlikely to arise
 Charles> during routine newsreading or transport (with the exception
 Charles> of NEWNEWS, which already has this feature).

It's partly NEWNEWS that concerns me. (INN still treats NEWNEWS as a
second-class citizen, I don't.)

 Clive> [W6: the grammar does not treat , in sets as special. This
 Clive> means that the wildmat "a[b,c]d" is a single pattern that
 Clive> matches the three strings "abd", "a,d", and "acd". Are we
 Clive> happy with this ? It matches existing practice

 >> it does no such thing. Existing practice, where a list of wildmats
 >> is expected, treats ',' as a delimiter without any escape
 >> mechanism (and none is needed).

 Charles> There is NO EXISTING PRACTICE on this. For a start, the
 Charles> whole wildmat-set business is new since RFC 977, so there is
 Charles> no existing definition in the matter (and it only arises in
 Charles> the NEWNEWS command currently).

well, exactly. Every single existing implementation of NEWNEWS,
including the one in INN-CURRENT, will treat ',' as a delimiter with
no possible escape. Since commas can't appear in newsgroup names, the
only effect of the new specification is to require that if a client
supplies a pattern like "foo\,*", it matches nothing (rather than
everything as at present). While there seems little point for a client
to do this, it is nevertheless strictly in accordance with the text
as proposed.

 Charles> And in the case of XPAT, if it has ever arisen it SHOULD NOT
 Charles> have been treated as a separator of alternative patterns
 Charles> because that has not been a feature of wildmats until
 Charles> now. Implementors who continue to offer XPAT will have to
 Charles> decide what to do in this new situation, and following
 Charles> Clive's suggestion is likely as easy a way for them to
 Charles> proceed as any other; certainly, existing practice does not
 Charles> enter into it.

well, INN-CURRENT seems to have quietly changed the meaning of XPAT
such that commas are now used for alternation; that means that there
are now even more incompatible implementations than previously (at
least four now).

 Clive> but means that you can't split a wildmat into the component
 Clive> patterns just by looking for unescaped commas.

 >> which is intolerable.

 Charles> Respectfully disagree.

I refer you to my initial comment.

-- 
Andrew.