ietf-nntp Commetns on draft-15.pdf
Charles Lindsey
chl at clw.cs.man.ac.uk
Fri Dec 28 10:00:27 PST 2001
I have now had a good read right through the draft-of-a-draft that Stan
put up in PDF format.
Basically, I think we have now, with the inclusion of wildmats, cracked
all the big issues (except for streaming, which is currently subject
to a vote).
So the matters I raise here are mainly minor ones. I have divided them
into two sections - Significant Issues which will need discussion on
this list because the solution is either controversial, or non-obvious;
and Nitpicks which I hope are not so controversial (though their
solutions are not necessarily obvious either).
Significant Issues
------------------
These items all need to be discussed on the List.
P19. S9.1.1.1.1 (GROUP Responses)
Some servers permit active file entries of the form
comp.bar 00003456 4567 y
comp.foo 00001234 2345 =comp.bar
in which the group comp.foo is "aliased" onto comp.bar (and the low/high
marks 00001234 and 2345 are actually redundant - see comp.bar for the true
marks). In that case, if you give
GROUP comp.foo
I would expect the response
211 1111 3456 4567 comp.bar
IOW the newsgroup-name in the response is not always the same as the one
asked for. USEFOR now has a mvgroup control message, and one of its
allowed implementations (at the MAY level) could give rise to this effect.
I think you should point out that this effect is legitimate with servers
that do aliasing, and that clients that care about such aliasing can look
out for it.
P33. S9.3.1.1 (POST responses)
If an article is POSTed, and the server can discover, in real time, that
it is syntactically invalid, or breached site policy, or whatever, does it
return 441, or do we need to invent a 541 response (there would surely be
no point in trying to send it again)?
There is also a remark in S9.3.2 (IHAVE) that some servers may not be able
to provide such responses in real-time. Should that remark not appear here
also, since it seems to apply equally to POST?
P41. S9.4.3 (LIST DISTRIBUTIONS)
I am totally confused at to what the LIST DISTRIBUTIONS command is
supposed to do, but then I do not have access to any server that provides
it. What does it actually return in typical cases? Or do current servers
actually provide any useful response at all?
Just to give some background, USEFOR assumes that servers will somehow to
be configured with a set of distributions that they are prepared to supply
(or "leak"), perhaps a different set for each downstream site; and also a
set of distributions they are prepared to accept. One presumes that the
server's configuration files would use some wildmat-like notation to
express this information. Also, USEFOR now permits negative-distributions,
as in
Distribution: !us
It also defines the distributions "world", "local" and all the two-letter
ISO country codes (beyond that, people can invent what distributions they
like).
Now, back to LIST DISTRIBUTIONS. Is it meant to list all the distributions
that the particular server accepts; or does not accept; or just an
interesting collection that it happens to know about?
P42. S9.4.4 (LIST DISTRIB.PATS)
I am even more confused by the LIST DISTRIB.PATS command. Again, can
someone provide me with examples of how it is actually used?
It seems to be based on the idea that some distribution-name might
encompass some particular class of newsgroups. For example:
9 alt.*.binaries binaries
Is that its intended use, and if so does that usage occur anywhere?
If it is the case that neither LIST DISTRIBUTIONS nor LIST DISTRIB.PATS
serves any useful purpose on the presnt Usenet (even assuming that the
attempt in USEFOR to bring the Distribution header back into fashion bears
fruit), then should we not consider declaring these commands to be
obsolete, and remove them from the draft?
P47. S9.5.2.1 (LIST OVERVIEW.FMT)
9.5.2.2 (OVER) defines 8 obligatory fields which MUST appear, in order, in
every overview line. 5 of these correspond to headers in the article, 3 of
them (article number, byte count, line count) do not. Question: are these
obligatory entries supposed to be included in the LIST OVERVIEW.FMT
output?
If so, then the Example in 9.5.2.1.2 is wrong (it omits References;
moreover what is to be shown for the non-header entries?). If not, then
the Example in 9.5.2.1.2 is still wrong, because it includes the other 4
of them. Also, what is the point of the "full" parameter (as in
"Xref: full"
I presume)? I thought all of the non-obligatory entries were REQUIRED to
include the header-name (in which case that "full" is redundant, or have I
got it wrong?). Either way, it would be a good idea to include one of the
non-obligatory entries (Xref is the obvious choice) in the Example,
together with its "full" (if that remains).
P48. S9.5.2.2
I am slightly surprised that the OVER command does not have a <message-id>
alternative (since all the other commands with a [range] parameter seem to
have one).
P50. S9.5.3.1 (HDR)
There is a definite Bug here, and possibly some confusion also.
Suppose I am in group comp.foo, and ask for "HDR Subject 49". It gives me
221 Subject fields follow
49 This is a subject
Now suppose I am in group comp.foo, and ask for "HDR Subject <1234 at bar.com>",
where the article requested is _not_ in that group (hence no meaningful
article number can be provided). It doesn't say what is supposed to be
returned. I can envisage two possibilities:
0 This is a subject
<1234 at bar.com> This is a subject
Giving '0' would accord with similar situations elswehere in the draft.
Giving <1234 at bar.com> is what the model implementation actually does with
XHDR. The example at P51-2 is plain wrong (it tries to give an article
number in the current group). I think I prefer the '0', but we need to
decide on something.
OTOH, there is a 412 response provided for "No newsgroup selected". That
is fine when you gave a range parameter, but is ridiculous when you gave a
<message-id> parameter. So it should be explained that there is no error in
that case, and the example at P52+11 should be removed. I am sure we have
discussed this matter before, but I do not recall the conclusion reached.
P52. Suggested further extension.
Currently, a command line is restricted to 512 octets (with a maximum of
497 octets for any parameters). The only command likely to run into this
limit is NEWNEWS, but it can be a confounded nuisance in that case.
Would this WG be agreeable to a service extension
CMDLENGTH <parameter>
where <parameter> is either a number (the maximum length allowed) or the
token "unlimited"? The default is, of course, 512 octets, and the limit on
the length of the parameters is <parameter>-15.
P56. S11.4 (NEWNEWS)
We took out the Distribution parameter that used to be in this command
(maybe on the grounds that it necessitated a scan of the articles in order
to implement it). Is anyone in favour of reinstating it on the grounds that
USEFOR still supports the Distribution header (and has even augmented its
features to give it a better chance of working)? (I might be in favour,
but don't want to make a huge issue of it.)
P58. S12 (Extensions)
We allow IANA registration of extensions defined in standards-track and
experimental RFCs. Should we also allow "provisional registration" (with
six months validity, say) for proposed extensions (with safeguards, such
as existence of an ietf draft and/or approval from an Area Director). That
might reduce the number of occasions when we are contronted with a widely
used command such as XOVER, and are forced to redefine it as OVER before
we can standardize it. I believe there are precedents for provisional IANA
registrations (for port number, for example).
P61. 14.1 (Personal and Proprietary Information)
It seems to imply that administrators should be "able to report with
confidence what information is and is not being forwarded in news articles
passing through their servers".
I will leave it to Clive Feather to comment on that one :-) .
P62. S14.3 (Authentication)
We took AUTHINFO out of an earlier draft, because it was not well enough
understood. Are we in a position to bring it back yet? In this section we
are apparently "strongly encouraging" people to use it, but we do not say
how.
P62. S14.4 (DNS)
Do we want to add somewhere something like:
"The NNTP implementation SHOULD make the IP address of the domain
name of the client available to the server, so as to establish the
source of articles arriving via the POST and IHAVE commands".
There is wording in USEFOR (Path verification) which implies that NNTP
implementations ought to be doing this.
P63. References
Currently, USEFOR is written on the assumption that the NNTP draft would
be published first, and hence will refer to it by its RFC number.
Likewise, the NNTP draft refers to RFC 1036, rather than to USEFOR.
As it turns out, both documents are running late, and indeed both are
hopefully now entering "final tidy-up". That leaves the possibility that
they might actually come out in the wrong order. Alternatively, we should
perhaps be considering the possibility that they will come out together
and refer to each other, as was done with RFC 2821/2.
Note than such a situation would come about more by luck than by
judgement, but it would certainly make things easier in some respects. I
do not suggest that we make strenuous efforst at this point to MAKE it
happen that way, but we should at least bear the possibility in mind.
Nitpicks
--------
I hope there is nothing particularly controversial in here, though some of
the issues raised will require some thought to fix them. And I hope
somebody in addition to Stan will read carefully through this lot to fix
any errors I have made.
Line numbers are counted from the top or bottom of a page, not including
headers or footers.
P1. S1. Status
Shouldn't it say somewhere that this document is intended for Standards
Track?
P1-18 document has been found -> document have been found
P2+6,7 communication method -> communication channel
P2+8 insure -> ensure
{"insure" in what insurance companies do; scan document for other
instances}
P4-6 The draft refers to itself, at various places, as
this standard
this document
this memo
this specification
I don't really care, but please can we be consistent?
P5+5 multilane message -> multiline message
P7-9 for matching patterns -> for matching newsgroup-names
{since we only use them for newsgroup-names now}
P12-2 to not require -> not to require
{split infinitive}
P15-18 503 -> 502
{I think so; certainly not 503}
P15-13 Please can we have an example with a parameter in it. E.g.
[S] FOOBAR Version-3
P16-3 {Why 16 digits? If the maximum is 4,294,967,295, then that is 10
digits}
P18-4 on the server MUST -> on the server, it MUST
P18 {bad page split in the middle of a line of a table}
P22+6 From: nobody at whitehouse.gov (Demo User) ->
From: "Demo User" <nobody at whitehouse.gov>
{The former usage is now deprecated both in RFC 2822 and in
USEFOR; you need to scan for all occurrences of "Demo User" to fix
it}
P23+16 may have been posted -> may have been crossposted
P24+8 function no performed -> function not performed
P26-1 function no performed -> function not performed
P31+9 Article follows -> Article exists
{This is the STAT command}
P31+13 Article follows -> Article exists
P34-6 to posting -> to post
P35-24 the~ -> the
{where '~' is some spurious character - may be an artefact of the
PDF}
P36+1,2 to immediately determine -> immediately to determine
{split infinitive}
P38+17 will be consist -> will consist
P40+5,6 Remove these redundant lines
{I think they are a relic of the days before wildmats had a ',' in
them}
P40-10 valid.) ->valid).
P40-4 information.) -> information).
P43-14 US-ASCII spaces -> US-ASCII TABs
{Surely it is standard practice that a "Newsgroups line" uses a
TAB between the name of the group and the descriptive text -
certainly USEFOR defines it that way both for newgroup and
checkgroups control messages.}
P44. S9.4.5.2
Please can we have a realistic example of a LIST NEWSGROUPS command with a
wildmat in it?
P44-10 to LIST EXTENSIONS ->
to LIST EXTENSIONS (assuming LIST EXTENSIONS is supported)
{servers are not obliged to support LIST EXTENSIONS}
P45+4 (e.g. "news.software.b") -> (e.g. "news.software.misc")
{news.software.b is currently moribund AFAICS}
P45-7 211 -> 211 n l h ggg {+ verbiage as in GROUP command}
{I find it odd that the 211 response from LISTGROUP is not the
same as the 211 response from GROUP; I also note that the model
NNTP implementation provides the full set of parameters: e.g.
group comp.risks
211 1 562 562 comp.risks
listgroup comp.risks
211 1 562 562 comp.risks
562
. }
P46+7 211 2000 3000234 3002322 -> 211 6 300234 3002322
{since you give only 6 groups in the example, the "2000" is hardly
realistic; moreover 2000 is impossible given those high/low
watermarks}
P46-9 We need an example of a LISTGROUP with an explicit ggg parameter.
I suggest:
GROUP example. -> LISTGROUP example.
P47+4 {The news convention seems to be to refer to "headers" in places
where RFC2822 would refer to "header fields". Likewise, RFC 2822
refers to the complete set of "header fields" as "the header",
whereas news (and even many email error messages) refers to them
as "the headers". USEFOR has consistently used the "news"
convention, and I recommend that this draft does the same
throughout.}
header fields -> headers (including the following colons)
P48+17,18
Delete "If no argument ... is returned"
{repeats the 1st sentence of the paragraph}
P48-17 servers do not -> servers which do not
P48-11 subject, author, date, message-ID, references ->
Subject, From, Date, Message-ID, References
P48-11 Point out that article number, byte count and line count are not
headers, and that "line count" means the true number of lines, not
the number that might appear in any Lines header.
P49-15 The Example MUST include the obligatory References, byte count and
line count entries. It would also be useful to include an Xref
header by way of example.
P53-17 I find it odd that the commands DATE, HELP, NEWGROUPS and NEWNEWS
are described _after_ the CONCLUSION step, and even after the
Extensions. I would recommend some section re-ordering here (but
I don't think I want a wholesale re-ordering as some others have
suggested).
P53-1 It needs to say what timezone is to be used in the DATE response.
Either the server's local timezone, or UTC (aka GMT). I am not
sure which is needed, but it must say one or the other.
P54+14 SHALL NOT -> MUST NOT
P55-20 It says there is no way to establish the server's timezone. This
would not be correct if the DATE command used the server's local
time.
P55-14 Time when possible ->
Time (i.e. by including the "GMT" parameter) when possible
P56+6 posted or received ->
posted or received on the server
P56+17 wildmat constructs -> wildmat-patterns
{alternatively, omit "and MAY consist...", which is merely stating
the obvious}
P56-11 when possible -> (i.e. by including the "GMT" parameter) when possible
P56-4 000000 -> 000000 GMT
{since we say "GMT" SHOULD be present}
P60-15 Unnecessary line split
P60-10 msg-id = <defined in RFC2822>
Sadly, that is wrong, since RFC2822 allows the msg-id
<"123\ 456"@[123.123.123.\ 123]>
which has two SP characters in it. That breaks the rules for
command arguments in our Section 4, and breaks existing software
all over Usenet. In addition, RFC 2822 also contains some obsolete
msg-id syntax which I really think we don't want to know about.
This problem came to light just as DRUMS was entering its 'last
call' phase, so it was not possible to get them to fix it (and we
had already had enough trouble to get them to remove comments and
folding from inside msg-ids).
We got around it in USEFOR by saying
"A msg-id MUST NOT contain any SP within any quoted-pair."
(we had already excluded all RFC2822 obsolete syntax). We also put
a 250 octet limit on a msg-id.
P60-8 "GMT"/"UTC" -> "GMT"
P60-7 newsgroup *("," newsgroup) -> wildmat
P60-4 newsgroup = parameter -> {delete line}
P61+8,14
The UTF-8 syntax in USEFOR is:
UTF8-xtra-2-head= %xC2-DF
UTF8-xtra-3-head= %xE0 %xA0-BF / %xE1-EC %x80-BF /
%xED %x80-9F / %xEE-EF %x80-BF
UTF8-xtra-4-head= %xF0 %x90-BF / %xF1-F7 %x80-BF
UTF8-xtra-5-head= %xF8 %x88-BF / %xF9-FB %x80-BF
UTF8-xtra-6-head= %xFC %x84-BF / %xFD %x80-BF
UTF8-xtra-tail = %x80-BF
UTF8-xtra-char = UTF8-xtra-2-head 1( UTF8-xtra-tail ) /
UTF8-xtra-3-head 1( UTF8-xtra-tail ) /
UTF8-xtra-4-head 2( UTF8-xtra-tail ) /
UTF8-xtra-5-head 3( UTF8-xtra-tail ) /
UTF8-xtra-6-head 4( UTF8-xtra-tail )
where <UTF8-xtra-char> corresponds to <UTF-8-non-ascii> in the
NNTP draft. The difference is that USEFOR has excluded more octets
that are not supposed to occur in UTF-8, including all those which
would belong to Unicode "surrogates". Do we want to make the two
drafts identical at this point, for the removal of all confusion?
P61+15,22
Replace wildmat syntax with the new stuff
P63+18 Is it still true that UNIX is a trademark of X/Open?
P63-1 one of the progenitors -> the many progenitors
P64+14 Is the reference to "Bnews" still appropriate?
P64-11 Is the reference to "AUTHINFO" still appropriate?
P65 There should be references to RFC 2822 and to RFC 1036 (or to USEFOR)
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl at clw.cs.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
More information about the ietf-nntp
mailing list