ietf-nntp draft-ietf-nntpext-base-17
Charles Lindsey
chl at clw.cs.man.ac.uk
Thu Mar 13 11:30:03 PST 2003
Lots of nit-picks, a few serious problems, and one new proposal.
p2. OUTSTANDING ISSUE
Documents should be referred to everywhere they occur, unless
there are two references close together (e.g. in the same section).
BTW, I don't like the RFC 1234 [3] style. I prefer the [RFC 1234]
style. Note, in any case the confusion between [1] meaning a
reference and [1] meaning a footnote.
p9. OUTSTANDING ISSUE
Leave it as it is. It seems to be the fashion :-)
p9-7 in the NNTP -> in NNTP
P10. OUTSTANDING ISSUE (initial response lime)
No.
p18. '?' in wildmats
This is supposed to work with UTF-8 chars. Clearly any existing
implementation of '?' will not so work.
There was recent discussion of this in the Usefor list where it
was alleged that '?' did not occur in any prior standard, and
that it was being excluded from the new NNTP draft so as to avoid
confusion with existing unofficial usage. There was also evidence
from Turnpike that they could not find an example of actual usage
of '?' in the wild.
AFAICS, '?' did not appear in any form in RFC 977.
It does occur in Stan Barber's 'model' implementation.
It does occur in RFC 2980
So it looks like the Usefor list was seriously misinformed :-( .
What was our position on this the last time we discussed it?
I thought we had managed to arrange that existing wildmat
implementations would work with UTF-8 (e.g. we removed the [...]
notation).
p18. It says:
... Backslash is commonly used to supress the special
meaning of characters and brackets to introduce sets, but there is no
existing standard practice for these in wildmats and so they were
omitted from this specification. A future extension to this
specification may provide semantics for these characters.
Certainly, [...] is use in Stan's model implementation and is
mentioned in RFC 2980, so that statement is certainly not correct.
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?
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.
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.
p27. Message-ids It says:
o A message-id MUST NOT contain a US-ASCII space within any
quoted-pair.
o A message-id MUST NOT be longer than 250 octets.
o RFC 2822 obsolete syntax for message-ids is not supported by the
protocol specified in this document.
Since that was written, we encountered some more horrors on in the
Usefor WG. Consider:
<"fooba\r"@baz.com>
<"foobar"@baz.com>
<foobar at baz.com>
According to RFC 2047, those are all considered to be the _same_
msg-id (and apparently some email implementations will even treat
them as such, if they get the chance). We fixed it in Usefor by
requiring that quoted-pairs could only be used when there was no
other way to represent what was needed (e.g. '\"' is OK but not
'\r') and likewise for quoted-strings.
This was all enshrined in some truly ugly syntax which you will
find in the current usefor draft (it might have been less ugly
if we had ruled out a little more than the absolute minumum to
solve the problem). I think the NNTP document needs to say the same
thing as Usefor on this, but whether you do it by copying the ugly
syntax or by other means does not matter so much.
There is also an issue whether '<' and '>' should be excluded (see
remarks on p77 below).
There was also some recent Usefor discussion on that 250 octets
limit, and I think the conclusion was that it should stand.
Likewise, the exclusion of obsolete syntax is fine.
p29-6 the any -> any
p34-19 header, -> headers,
for consistency with useage elsewehere.
Also, would it be better to say 'empty' rather than 'blank'? It
needs to be absolutely clear that this line has no WS in it.
p43+11 header and body -> headers and body
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.
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.
p45-19 header and body -> headers and body
p48. "All servers MUST implement these commands."
However, some of the commands in the LIST * series are optional.
So you need to add "unless otherwise stated" or somesuch.
p53. Is it possible for the list returned by LIST ACTIVE to be empty?
p54. "Other status strings may exist. The definition of these other
values and the circumstances under which they are returned is
covered in other specifications."
What "other specifications" have you in mind? AKAIK, these other
cases arise at the whim of individual implementors (though some,
such as aliasing of groups, are fairly widely supported).
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.
p56-8 in a news article header -> in news article headers
or, better still:
"... for the Distribution: header in a news article ..."
p57-6 Distribution: line in the header -> Distribution: header
p66. OUTSTANDING ISSUE
Should this be called ":octets" instead? Or should it be a count
of UTF characters rather than octets?
No and No.
p67. OUTSTANDING ISSUE
Should this be 502 ("not permitted") or 503 ("there is no overview
database")? In which case, why provide the command?
Maybe the client did an AUTHINFO and acquired a higher privilege
which made the command available to him.
p72-3 "See RFC 1036 [6] for a list of valid header lines."
I am not sure this is helpful. There may be lots of other headers
arising from extensions, from email usage, and X-headers, and this
HDR command is potentially useable with all of them.
p73. OUTSTANDING ISSUE
Should this be changed to require the name to *begin* with a colon?
Sorry! Don't understand the question.
p73+13 if neither are specified -> if neither is specified
p74. "A server MAY only allow HDR commands for a ..."
Please could we start a new paragraph here.
However, see below for a proposed change in this area.
p76. "11. Augmented BNF Syntax for NNTP Commands"
A reference to RFC 2234 would be useful here.
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.
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.
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.
p77. "message-id-char"
You have excluded '<' and '>' which is probably fair. However,
RFC 2822 does not exclude these, so you need a mention of that
in section 7. Come to think of it, Usefor does not exclude them
either - that probably needs fixing.
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.
p80. "o replacing such sequences by a "guessed" valid sequence (based on
properties of the UTF-8 encoding);"
That "guessing" is a definite MUST NOT in both RFC 2279 and RFC
2279bis (and also in Usefor). I suggest you take it out.
p83. Since the draft does not mention AUTHINFO, do we still need the
reference to Chris Lewis?
p84. [2]
You will need to refer to RFC 2279bis as soon as it is accepted.
New Proposal for parameter to HDR extension.
--------------------------------------------
I have raised this previously, and Russ even stated he could live with it.
p72. 10.6 The HDR extension
This extension provides one new command: HDR. The label for this
extension is HDR, and it MAY be followed in the output of LIST
EXTENSIONS by one of the parameters ALL and OVERVIEW.
p74. "A server MAY only allow HDR commands for a limited set ..."
Replace with new paragraph:
A server MAY only allow HDR commands for a limited set of headers
and metadata items. If the parameter ALL follows the HDR label
in the output of LIST EXTENSIONS, it MUST allow the HDR commands
for all headers and supported metadate items; otherwise, if the
OVER extension is supported and OVERVIEW follows the HDR label,
it MUST allow at least those headers and metadata items that
would have been included in the response to a LIST OVERVIEW.FMT
command at that moment; (otherwise, it may restrict the allowed
headers in any arbitrary manner). In the case of any header that
is not allowed, it MUST respond with a 503 response to attempts
to request that header, rather than returning erroneous results
such as a successful empty response.
Observe that is would be necessary to retain the LIST OVERVIEW.FMT
command if this goes ahead (but I support the retention of that
command anyway).
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