ietf-nntp Draft comments

[Russ Allbery]

Stan O Barber <sob at verio.net> writes:

> 1. Section 5 -- Wildmat specification..... The last discussion we had
> (that I see in the archives) was to replace this section with something
> based on the latest INN documentation. I have not seen specific text on
> this. I'd prefer someone else offer that and I edit it, but I can write
> it if there is still interest in replacing this section.

Someone, I forget whom, had proposed text, but I think there was some
consensus against that proposed text and in favor of some modification of
my text at the IETF meeting?  I sent out my text with modifications to
remove the mentions of poison expressions (which is more of an
INN-specific thing that we don't need in the protocol), but I'm not sure
if it was suitable as-is for inclusion.

One of the outstanding issues with wildmat is handling of spaces and
whether to introduce C-like backslash sequence for particular characters.

My documentation is at <http://www.eyrie.org/~eagle/nntp/wildmat.txt>; the
section on WILDMAT EXPRESSIONS would be the proposed text for this
standard but the bits about poison expressions would need to be stripped
out.

> 2. Section 7 -- Streaming .... There was proposed text on this that I
> didn't include in 11. My concern here is including this in the base
> specification rather than putting it in an extension. I think it makes a
> great extension, but I remain concerned about having in the base.

So am I.  I'm pretty much of the same opinion here; streaming just feels
potentially complicated.

> Are there others? Please bring them up (or bring them up again, if they
> were not addressed).

I think the other major issue was PAT.  How do you match strings
containing spaces, are the matches done against the raw headers (and if
so, how do you match newlines) or unfolded headers or something else, and
do you do the same munging of the headers as overview does before
matching?

The only other minor issue that I can recall right now is that the
NEWGROUPS description of the date parameter allows for either two-digit or
four-digit years without any expressed preference.  I think we should add
a SHOULD use four digit years if the server supports that syntax, just to
give a bit of impetus to people switching over.

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