ietf-nntp Draft comments

[Russ Allbery]

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

>> 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.

> Okey. I will look it over tonight and give some feedback.

If there are specific changes that I could make to my text to make it more
suitable for inclusion, I'd be happy to try to take those on.  The other
proposed text took a very different approach from mine; I was writing user
documentation, so I was aiming for approachable and informal, which may be
the wrong tone for a technical standard.  A complete rewrite for a
different approach or tone will unfortunately require more time than I
have free to spend on that right now.

I found my previous documentation in the mailing list archives.  It begins
at line 94,458.  Note that the last paragraph of that documentation should
be omitted, as it's dealing with an internal INN interface that isn't
relevant to the standard.

It's message ID <ylya2t3cgk.fsf at windlord.stanford.edu>.

At line 103,101, message ID <20000727233251.H8294 at demon.net>, is Clive
Feather's proposed text, which is the other more formal approach that I
was referring to earlier.

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

> Understood.

I'm not sure how to resolve this outstanding issue; I'm leaning slightly
towards not introducing such sequences if we can find some other way of
dealing with the PAT problems, and I know that Andrew is in favor of them,
but I don't have a good feel for the general consensus of the rest of the
group.

> Yep. I remain concerned about how to list which commands are
> "stream-able" and which are not and how that list gets amended.

Hm.

I wonder if it would be at all useful to start putting together a template
for the documentation of an NNTP command, sort of like the way there are
templates for writing documentation of C library functions and the like.
There's a set of things one wants to know about any given NNTP command,
and it might be nice to have that list written down somewhere.  There's a
beginning of this list in section 12 of the current standard, but it's not
quite the same thing.

Something like the name of the command, the syntax, the possible response
codes (errors and successes), the LIST EXTENSIONS tag if any, what modes
the command can be used in (reader vs. transit), a description, and at
least one example.  And given the above, whether or not it can be
streamed.

The current document sort of does this, and it might be nice to have a
standard set of information available about any NNTP command that various
servers can use as a template for documenting their private extensions as
well.

>> 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?

> I tried to clarify this by not permitting spaced in PAT at all. I tried
> to add this in an earlier version, but that seemed to get pooh-poohed,
> so I intended to remove it in 11.  I may have not been as effective as I
> should have been in doing that.  Good point on the folded headers. I
> think theey should be unfolded before matching so the newline issue is
> removed.

I don't think it's necessarily a bad idea, just that it doesn't completely
solve the issue.

I think we have the following separate issues:

 * How do you match a literal space in the header content with a wildmat
   argument to PAT?  One solution would be to introduce a mechanism into
   the wildmat syntax for specifying a space, such as \40 or \x20 or
   whatever syntax we want to use.  Existing practice in at least INN for
   the XPAT command was to consider any whitespace between portions of the
   last argument to PAT to represent a literal space, which is sort of
   another way of solving this problem but which is amazingly ugly.

 * Based on the answer to the above question, do we want to say something
   about existing practice?  I assume that the consensus here is that
   since PAT is new in this document, there's no real worry about breaking
   from existing practice.

 * Are the headers unfolded before the matching?  If so, exactly what
   mechanism is used to unfold the headers?  (If not, we have the same
   issue for how to match a CRLF as we had for matching a space.)

 * Are the headers munged in the same way as overview data is munged?
   Note that this is a different question than just the unfolding, since
   overview munging also replaces tabs with spaces.  Existing practice for
   XPAT is to match against the contents of overview for headers that are
   in overview for the obvious speed reasons, but I think the munging
   applied to headers before a match is attempted should really be
   consistent between headers in overview and headers not in overview
   (particularly given that what is in overview is a configurable option
   on most servers).

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