ietf-nntp Commetns on draft-15.pdf
Andrew Gierth
andrew at erlenstar.demon.co.uk
Fri Dec 28 21:40:15 PST 2001
>>>>> "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.
More information about the ietf-nntp
mailing list