ietf-nntp Wildmats

[Russ Allbery]

Charles Lindsey <chl at clw.cs.man.ac.uk> writes:
> Russ Allbery <rra at stanford.edu> writes:

>> I would expect it to be a syntax error.

>> Transforming " " to "\uXXXX" or whatever, I would expect it to match the
>> literal subject "bar bar", any subject ending in "foo", and any subject
>> beginning with "baz".

> Yes, that's one way to look at it, but it would be counter-intuitive to
> people who have been told that XPAT takes a sequence of independent
> wildmats, which are to be matched in succession.

But we're not specifying XPAT.  We're specifying PAT.  XPAT is a confusing
mess; my preference is to not duplicate that mess in PAT and instead do
something clean and clear, even if it isn't bug-compatible with XPAT.

> One of our problems is that, if we introduce ',' into wildmats and
> existing implementations incorporate it, their XPAT implementations will
> suddenly acquire some "interesting" properties.

If the want to continue supporting XPAT in the previous fashion, they may
need to use a separate wildmat implementation for that.  I really don't
think this is our problem.  It's not particularly hard to do this; just
grab an older wildmat implementation, drop it into the code that
implements XPAT, and don't use your main wildmat implementation in that
bit of backwards compatibility support.  Older wildmat implementations are
extremely stable; INN's hadn't changed in years.

Clients that want to use UTF-8, a cleaner syntax, or a better specified
command can switch to PAT.

> And since the official definition of XPAT resides in our
> recently-finalised Common Extensions RFC, they won't find the answer by
> looking in there :-( .

I disagree with labelling an informational RFC documenting common
extensions an "official definition."  Many of those extensions are
implemented in slightly different ways on different servers; that's one of
the reasons why we're supposed to standardize them.

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