ietf-nntp Draft summary of IETF 48 meeting

[Russ Allbery]

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

>> The third and subsequent arguments to the command are taken to be the
>> wildmat.  Multiple spaces or other whitespace are collapsed down into a
>> single space (ew).  The wildmat *is* anchored at the beginning and end
>> of the header.

> I see no problem with letting the 'gaps' between the various widlmats
> represent arbitrary whitespace rather than single spaces.

It means that you're not really dealing with a wildmat any more; you're
dealing with some special matching syntax peculiar to PAT that's
preprocessed into a wildmat.  That strikes me as rather ugly.

> The effect of the anchoring is that the Subject of this message would NOT
> match
> 	PAT Subject nnn Draft summary * IETF [0-9][0-9]
> is that correct?

Yup.

>> The problems with this are the grody way wildmats are parsed and the
>> differing returns depending on whether a message ID or a range of
>> articles was given.  I think the latter is due to the combining of
>> multiple commands into one handler (including XHDR and XPAT), so I
>> don't think we need to preserve it.

> I have no problem with the "grody way". What is the problem with message
> IDs and ranges?

Hm.  I guess it wasn't due to that.  Never mind; it's just weird but I
understand what it's doing now.  It lists either the message ID or the
article number depending on which one the client searched for.

>> My preferred return from PAT would be a list of matches, either article
>> numbers or a message ID depending on which way of specifying the
>> article(s) to match against was used.

> But I presume you want the matching headers to be listed as well, as at
> present?

Yup.

> Yes, I see the problem with returning an article number, since there may
> not even exist a current group if a message-ID had been given.

It should return a message ID if a message ID was specified.  If an
article range was specified, I think it makes more sense to return article
numbers; you know the user is talking about one particular group already
and there's no real need to fish the message ID out of overview when the
client will be ready to request articles by number anyway.

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