ietf-nntp draft-ietf-nntpext-base-17

[Russ Allbery]

Commenting just on those points where I disagree; I've finished my
comments and will be sending them out immediately after this message.

Charles Lindsey <chl at clw.cs.man.ac.uk> writes:

> p9. OUTSTANDING ISSUE
>       Leave it as it is. It seems to be the fashion :-)

I think that the current breakdown is a bit overblown, but it's not
particularly confusing, so I have no strong opinion either way.  I have no
objections to simplifying, although there are some other references to
those stages scattered about.

> P10. OUTSTANDING ISSUE (initial response lime)
>       No.

Any more comments on why?

> p18. '?' in wildmats
>       This is supposed to work with UTF-8 chars. Clearly any existing
>       implementation of '?' will not so work.

I don't think this is much of an issue, since the previous NNTP standard
mandated ASCII parameters, and the change to UTF-8 is specifically noted
as an incompatibility with RFC 977.  Since wildmats are only applied to
newsgroup names (and more than that, only to names of newsgroups carried
on that server), servers can just avoid UTF-8 newsgroup names until the
wildmat implementation has been upgraded

I think we should leave in ?, but I don't have strong opinions.  We did
spend a bunch of time hashing this out already, though, so I'd rather not
reopen it unless we really have to.

> p25. LIST EXTENSIONS
>       This is described as optional. I suppose it must be so because of
>       lack of mention in RFC 977. But what is the actual situation in
>       current implementations?

Most servers don't implement it.

>       Anyway, it says:
>    ...  This command MUST be
>    implemented by any server that implements any extensions defined in
>    this document.
>       It would be useful to add "or in any other standards-track
>       extension", or even in any future informational or experimental
>       extension.

Agreed.

> p26. Extension labels and parameters
>       It would be useful to say what characters are allowed in these.
>       The syntax at the end seems to say ASCII letters (hence uppercase
>       letters) but nowhere is the syntax of parameters given.

That's because the syntax of the parameters is defined by the extension.
I think that's fairly clear

> p27. Message-ids It says:

I strongly disagree with including all of this junk in the NNTP standard.
I'll post an alternative proposal shortly that instead defers all of the
syntactical restrictions not directly relevant to the NNTP protocol to
other documents.

> p43.  "A response of 240 ... the posted article will be made available on the
>        server ..." and later on
>       "The intent is that the server just passes the incoming message
>       to be posted to the server installation's news posting software,
>       which is not defined by this document."
      
>       I think it would be useful to indicate here, at least at the
>       "Note" level, that mailing to a moderator is an alternative action
>       in appropriate cases.

I don't.  I think the language is fine as is.  Mailing the message to a
moderator is passing the article along to another server, which is part of
the text behind one of the ellipses above.  It's done by the news posting
software, which is not defined by this document.

> p43.  "Therefore, in any subsequent session the client SHOULD use the same
>       message-id in the article when resending it or check whether the
>       article was successfully posted before resending it to ensure that
>       the resend will not result in a duplicate article."
      
>       If this strategy were to be followed by a client, it might result
>       in a loop if the article had been mailed to a moderator. Or if, as
>       happens in CNews, the article is not actually processed until the
>       next time the batch process is run.

Yes, I have a slightly alternative wording that will be in my comments.

> p53.  Is it possible for the list returned by LIST ACTIVE to be empty?

Yes.

> p55.  "If the optional wildmat parameter is specified, the list is limited to
>       only the groups whose names match the wildmat (and therefore may
>       be empty)."

>       I believe an empty list is possible even when no wildmat is provided.

Yes.

> p76.  "11. Augmented BNF Syntax for NNTP Commands"

>       A reference to RFC 2234 would be useful here.

Yes.

>       BTW, is this section normative? All the commands have been defined
>       earlier. However, you do need to look here for some of the fine
>       details.

Aren't all sections assumed to be normative unless otherwise stated?

> p77.  "header-name-char = %x21-39 / %x3B-7E ; exclude SP and :"

>       This seems excessively liberal. Granted it is what RFC 2822 says,
>       but Usefor chose to restrict them to something much closer to what
>       actually occurs in the wild.

That's Usefor's business; I believe this is correct for NNTP.  Someone may
want to serve a B News article with its Article-I.D. header via NNTP,
after all.  There's no point in adding unnecessary restrictions.

> p77.  "message-id"

>       Something nasty seems to have happened to the formatting here. In any 
> case, it might be better to include the more limited systax for RFC 2822, or 
> even from Usefor.

See my alternate proposal to be posted shortly.  I think this is good for
NNTP.

> p77. "UTF8-1"

>       See draft-yergeau-rfc2279bis-04.txt which is currently up for IETF
>       last call. It includes a full syntax for UTF8, and you need to
>       check that you conform to that and use their notation. Note also
>       that they now exclude entirely all those cases which could give
>       rise to code points beyond U+10FFFF.

We can switch our reference to this when it's published as an RFC if it's
done before we are, yes.

> New Proposal for parameter to HDR extension.
> --------------------------------------------

Discussed in a separate message.

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