wildmats (was: Re: ietf-nntp Draft summary of IETF 48 meeting)

[Stan O. Barber]

Andrew Gierth wrote:
> 
> >>>>> "Stan" == Stan Barber <sob at academ.com> writes:
> 
>  Stan> Clarification of wildmat usage in various commands
> 
>  Stan> There has been some discussion about how to deal with compound
>  Stan> wildmats versus multiple wildmats. The group decided that
>  Stan> commas can be used to link together wildmats to form a compound
>  Stan> wildmat. A space would separate multiple wildmats.  Spaces can
>  Stan> be embedded in a wildmat if preceded by a backslash.
> 
> absolutely not. This breaks all attempts to parse the command into a
> parameter list prior to interpreting it; the command parser would need
> to know which parameters are wildmats and which are not. Much existing
> server code depends on being able to split parameters on whitespace
> alone.

I think you are overstating here. It can't break all attempts if the parser is
smart enough. It may break such attempts in current implementations. Perhaps
that is really all you are
trying to say here.

> 
> In existing code, there is no way to include spaces in wildmats _at
> all_ (they are after all never needed for group-matching wildmats, so
> that only leaves XPAT; as far as I know, those clients that use XPAT
> substitute whitespace and other unacceptable characters with '?' and
> do their own post-matching on the results). This is clearly not
> optimal, which is one reason I looked at adding general \-escapes (so
> that \040 or \x20 (or \u0020) could be used for literal spaces).

The addition of the \ was to attempt to address the embedded space issue. If
there is
consensus that this is not really an issue (i.e. wildmats can't have embedded
spaces, period), then we can just move pass this. The "\u"  "\U" suggestion was
rejected 
in the meeting in Pittsburgh.

So, is there agreement that wildmats can't have embedded spaces in them? 

> 
> As for commas, to the best of my knowledge no existing implementation
> supports the use of compound wildmats using commas except in relation
> to specific commands (i.e. NEWNEWS) where the syntax explicitly states
> so. Therefore this would be an incompatible change to existing
> practice.

This is a very confusing paragraph. You are saying that commas are not supported
except
where they are supported. Are you really trying to say that the use of commas
should not 
be generalized? If so, that means we will have to remove them from those
commands where such generalization might be useful. I don't have a problem with
this, but it's important that everyone understand the fall out of such a
decision.