ietf-nntp Commetns on draft-15.pdf

[Andrew Gierth]

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

 Charles> I have now had a good read right through the
 Charles> draft-of-a-draft that Stan put up in PDF format.

I won't be commenting on it (or reading it) until such time as it
appears in plain text, which is the appropriate format for it.  For
now I'll comment on these comments.

 Charles> Basically, I think we have now, with the inclusion of
 Charles> wildmats, cracked all the big issues (except for streaming,
 Charles> which is currently subject to a vote).

Reality has this way of ignoring attempts to change it by vote.

 Charles> P19. S9.1.1.1.1 (GROUP Responses)
 Charles> Some servers permit active file entries of the form
 Charles> 	comp.bar 00003456 4567 y
 Charles> 	comp.foo 00001234 2345 =comp.bar
 Charles> in which the group comp.foo is "aliased" onto comp.bar (and
 Charles> the low/high marks 00001234 and 2345 are actually redundant
 Charles> - see comp.bar for the true marks). In that case, if you
 Charles> give
 Charles> 	GROUP comp.foo
 Charles> I would expect the response
 Charles> 	211 1111 3456 4567 comp.bar

have you tried this? last time I looked, INN did not do that. (In fact,
it did not behave at all sensibly if you tried to read from an aliased
group.)

 Charles> I think you should point out that this effect is legitimate
 Charles> with servers that do aliasing, and that clients that care
 Charles> about such aliasing can look out for it.

aliasing is a can of worms that needs to be looked at in terms of what
_does_ happen, not what you think currently happens.

 Charles> P33. S9.3.1.1 (POST responses)
 Charles> If an article is POSTed, and the server can discover, in
 Charles> real time, that it is syntactically invalid, or breached
 Charles> site policy, or whatever, does it return 441,

yes

 Charles> or do we need to invent a 541 response (there would surely
 Charles> be no point in trying to send it again)?

clients should not be sending the post again, though in fact many of
them do (we should include something to discourage clients from doing
this). If we were actually going to change existing practice in this
area, the thing to do would be to define 441 as a permanent error, and
provide a new code (442?) to mean "this post failed for some temporary
reason - try it again later", however I am highly dubious about this.

Please note: 4xx response codes in NNTP are _NOT_ temporary errors
except where documented as such; most of them are in fact permanent.

 Charles> There is also a remark in S9.3.2 (IHAVE) that some servers
 Charles> may not be able to provide such responses in
 Charles> real-time. Should that remark not appear here also, since it
 Charles> seems to apply equally to POST?

Servers can return 240 and then silently discard the post, yes.

 Charles> P41. S9.4.3 (LIST DISTRIBUTIONS)
 Charles> I am totally confused at to what the LIST DISTRIBUTIONS
 Charles> command is supposed to do, but then I do not have access to
 Charles> any server that provides it. What does it actually return in
 Charles> typical cases? Or do current servers actually provide any
 Charles> useful response at all?

On INN it outputs (verbatim, as a normal multiline response) the
contents of the "distributions" file, which has no other purpose than
to support this command (and which appears not to exist in a default
installation).

The intention appears to be to provide text descriptions for known
distributions.

I find no evidence of any use of this command by clients.

 Charles> P42. S9.4.4 (LIST DISTRIB.PATS)
 Charles> I am even more confused by the LIST DISTRIB.PATS
 Charles> command. Again, can someone provide me with examples of how
 Charles> it is actually used?

distrib.pats is used by INN (and, I believe, some other servers) to
choose a default Distribution: header for posts when none is supplied.
The INN sample file is:

##  distrib.pats -- specify default Distribution header for newsgroups
##  Format:
##	<weight>:<pattern>:<value>
##  All articles are matched against all patterns, value to be used is the
##  one with the highest weight.
##	<weight>	The weight assigned to this match, integer
##	<pattern>	Newsgroup name or single wildmat(3) pattern
##	<value>		Value of Distribution header.
##
##
## Uncomment to default all local.* groups to a distribution of local.
#10:local.*:local

list distrib.pats simply outputs this file.

I see some client requests for this (though it's not implemented on
the server in question, and no-one's ever queried its absence). I see
no point in supporting the command; however, the server may still wish
to provide a Distribution: header based on the groups posted to in
some circumstances, which may or may not involve the existence of an
actual distrib.pats file.

 Charles> P47. S9.5.2.1 (LIST OVERVIEW.FMT)
 Charles> 9.5.2.2 (OVER) defines 8 obligatory fields which MUST
 Charles> appear, in order, in every overview line. 5 of these
 Charles> correspond to headers in the article, 3 of them (article
 Charles> number, byte count, line count) do not. Question: are these
 Charles> obligatory entries supposed to be included in the LIST
 Charles> OVERVIEW.FMT output?

yes

 Charles> P52. Suggested further extension.
 Charles> Currently, a command line is restricted to 512 octets (with
 Charles> a maximum of 497 octets for any parameters). The only
 Charles> command likely to run into this limit is NEWNEWS, but it can
 Charles> be a confounded nuisance in that case.

 Charles> Would this WG be agreeable to a service extension
 Charles> 	CMDLENGTH <parameter>
 Charles> where <parameter> is either a number (the maximum length
 Charles> allowed) or the token "unlimited"? The default is, of
 Charles> course, 512 octets, and the limit on the length of the
 Charles> parameters is <parameter>-15.

no

Existing software that uses NEWNEWS seems to have little trouble with
this; breaking the desired list of groups up into chunks has very
little performance impact on a sensible implementation.

 Charles> P56. S11.4 (NEWNEWS)
 Charles> We took out the Distribution parameter that used to be in
 Charles> this command (maybe on the grounds that it necessitated a
 Charles> scan of the articles in order to implement it). Is anyone in
 Charles> favour of reinstating it on the grounds that USEFOR still
 Charles> supports the Distribution header

no

 Charles> P62. S14.3 (Authentication)
 Charles> We took AUTHINFO out of an earlier draft, because it was not
 Charles> well enough understood. Are we in a position to bring it
 Charles> back yet? In this section we are apparently "strongly
 Charles> encouraging" people to use it, but we do not say how.

have we fixed the description of x8x response codes yet? If so, then
an authinfo draft can be produced, provided it doesn't attempt to
mandate features which are impossible for some sites to implement like
the last one did.

I personally would like to get away from plaintext passwords, but I've
yet to see a SASL scheme described which allows it within the
restrictions I work under (namely that I don't have the user/password
information locally at all, all I have is ways of querying third
parties via other authentication protocols).

 Charles> P62. S14.4 (DNS)
 Charles> Do we want to add somewhere something like:
 Charles> "The NNTP implementation SHOULD make the IP address of the domain
 Charles> name of the client available to the server, so as to establish the
 Charles> source of articles arriving via the POST and IHAVE commands".

?

do you mean "domain name of the client's IP address"? (in which case
the usual warning about matching forward and reverse lookups needs to
be in there somewhere)

 Charles> There is wording in USEFOR (Path verification) which implies
 Charles> that NNTP implementations ought to be doing this.

the brokenness of that has been discussed at length (and apparently
ignored, as usual) on USEFOR

 Charles> P36+1,2	to immediately determine -> immediately to determine
 Charles> 	{split infinitive}

"to immediately determine" is correct in this context. Also correct
would be "to determine immediately". Your version is a classic example
of how _not_ to avoid split infinitives.

 Charles> P45+4	(e.g. "news.software.b") -> (e.g. "news.software.misc")
 Charles> 	{news.software.b is currently moribund AFAICS}

so is news.software.misc. Try news.software.nntp

 Charles> P45-7	211 -> 211 n l h ggg {+ verbiage as in GROUP command}
 Charles> 	{I find it odd that the 211 response from LISTGROUP is not the
 Charles> 	same as the 211 response from GROUP; I also note that the model
 Charles> 	NNTP implementation provides the full set of parameters: e.g.
 Charles> 	    group comp.risks
 Charles> 	    211 1 562 562 comp.risks
 Charles> 	    listgroup comp.risks
 Charles> 	    211 1 562 562 comp.risks
 Charles> 	    562
 Charles> 	    . }

I would _assume_ that those clients that use LISTGROUP ignore the text
of the response, therefore returning the same response as for GROUP
would not actually break them. Certainly current clients can't expect
the additional info, since INN certainly does not provide it.

 Charles> P53-1 It needs to say what timezone is to be used in the
 Charles> DATE response.  Either the server's local timezone, or UTC
 Charles> (aka GMT). I am not sure which is needed, but it must say
 Charles> one or the other.

DATE always returns UTC.

 Charles> P55-20 It says there is no way to establish the server's
 Charles> timezone. This would not be correct if the DATE command used
 Charles> the server's local time.

That's why the DATE command always returns UTC.

The server's timezone is not an interesting concept in any case.

 Charles> P63+18	Is it still true that UNIX is a trademark of X/Open?

I believe it's currently a trademark of the Open Group (formed when
X/Open merged with some other bodies). www.opengroup.org should have
the details somewhere.

-- 
Andrew.