ietf-nntp Comments on the November draft
Clive D.W. Feather
clive at demon.net
Wed Nov 10 01:01:13 PST 1999
Note: I'm reading this as a "black box" specification, deliberately not
relying on knowledge of other implementations. Questions in this message
should be read as if they contained "it should be easy to determine the
answer to this question from the document but it isn't at the moment".
Where I suggest changes, I am willing to assist on detailed wordsmithing if
and when the concept is agreed.
> NNTP operates over any reliable data stream 8-bit-wide
> channel.
[...]
Can we add something about streaming/pipelining here ? In other words,
though the protocol requires the client to send commands and the server to
respond, the client should be able to send further commands without having
to wait for the server to respond to the previous command (providing, of
course, that it gets the overall protocol correct). This may seem obvious,
but see RFC 1854 for why it isn't.
> There MUST be only one CONNECTION,
> CONCLUSION and DISCONNECTION step for each NNTP session. All
> other steps MAY be repeated as needed.
How do you repeat the GREETING step ?
> Command lines MUST NOT
> exceed 512 octets, which includes the terminating US-ASCII
> CRLF pair. Arguments MUST NOT exceed 497 octets.
Where did this 497 come from ? It's not 512 minus a three character
command, space, and CRLF.
> However, certain
> commands MAY permit multi-line responses.
This is a misuse of "MAY".
However, certain responses from commands are multi-line.
> A NNTP server MAY have an inactivity autologout timer. Such a
> timer MUST be of at least three minutes duration. The receipt
> of any command from the client during that interval should
> suffice to reset the autologout timer.
s/should/SHOULD/ or, even better, s/should/MUST/.
> In addition, below is
> listed a general set of response codes that MAY be received at
> any time.
Does this refer to the x9x debugging codes below, or something else ?
If the latter, please add a reference.
> Parameters MUST be separated from the numeric status indicator
> and from each other by a single US-ASCII space. All numeric
> parameters MUST be in base 10 (decimal) format, and may have
> leading zeros.
s/may/MAY/
> The use of unspecified response codes for a standard command
> is prohibited.
>
> The status indicator pattern x9x is provided for debugging.
> Since much debugging output may be classed as "informative
> messages", it MUST be the case that responses 190 through 199
> WILL be used for various debugging outputs. There is no
> requirement in this specification for debugging output.
> However, if such is provided over the connected stream, it
> MUST use these response codes. If appropriate to a specific
> implementation, other x9x codes MAY be used for debugging.
> (For example, response code 290 could be used to acknowledge a
> remote debugging request.)
I cannot make head or tail out of this part of the specification. For a
start, what on earth does "it MUST be the case that ... WILL be used"
mean ? As a potential implementor, I have the following questions.
Can any command, including standard commands, return a 19x response ?
What about other x9x responses ? If not, then this section needs rewriting
to just say that the x9x codes are available for debugging. If standard
commands *can* return x9x responses, then it needs rewriting to make this
fact clear.
If a standard command can receive a 19x response, what is the client
supposed to do ? Is the server required to send another response following
it ? Is this also the case for other 1xx responses ? If the server doesn't
followup the 19x, has the command succeeded or not ?
What about other x9x responses ?
> The third specifies a
> specific set of characters. The set is specified as a list of
> characters, or as a range of characters where the beginning
> and end of the range are separated by a minus (or dash)
> character, or as any combination of lists and ranges.
Many implementers are not going to be familiar with the implications of
UTF-8. I would suggest that either a note or an example would be worthwhile
here. Something like this:
Note: Implementers must be careful to apply the pattern-matching
operators to whole characters encoded in UTF-8, and not to individual
octets.
Examples:
61 3F 3F 64 matches 61 C2 A3 C4 B5 64
but not 61 C2 A3 64
5B 7E 2D C2 A3 5D matches either a single octet 7E or 7, or one of
the 36 sequences from C2 80 to C2 A3 inclusive.
> The meaning of the backslash operator cannot be
> negated by the exclamation point.
That does not make sense. What I think you mean is that:
!\\x*
means a pattern other than those beginning "\x", in which case I would
suggest having it as an example rather than as those words.
> 5.1 Negating the expression
The word "expression" hasn't appeared before. Change it to "wildmat" or
"pattern".
> The exclamation point can be used at the beginning of a
> wildmat to negate it.
To clarify what "negate" means, perhaps add:
That is, if the remainder of the pattern would match the string then
the negated pattern does not, and vice versa.
> 6. Format for Keyword Descriptions
> Each keyword is shown in upper case for clarity, although the
> NNTP server ignores case in the interpretation of commands.
> Any parameters are shown in lower case. A parameter shown in
> [square brackets] is optional. For example, [GMT] indicates
> that the triglyph GMT may be present or omitted.
These three sentences, read together, don't make much sense. A better way
to word it would be:
Each keyword is shown in upper case for clarity, although the
NNTP server ignores case in the interpretation of commands.
A parameter shown in [square brackets] is optional. For example,
[wildmat] indicates that a wildmat may be present or omitted.
A parameter
[...]
group name or a <message-id> may be specified, but not both.
Unless stated otherwise, a parameter name in lowercase represents
a token described elsewhere, while one in uppercase is a literal
string that is included as written.
> The pattern in all cases is
> based on the WILDMAT format. Arguments expected to be in
> wildmat format
Please be consistent throughout the document.
> 7.1 Initial Connection
There are four codes described. These are:
200 - further commands will be accepted, POST allowed
201 - further commands will be accepted, POST not allowed
502 - not authorised, connection will be closed
400 - all other cases
What I'm not clear about is when a 400 is generated and whether further
commands will be accepted. Assuming that they won't (if they would, then
why not a 20x code), I presume that 400 means "authorised but I'm going to
terminate the connection anyway".
If I'm right so far, then I would suggest a complete rewording of this bit:
If the server will accept further commands from the client including
POST, it MUST present a 200 greeting code.
If the server will accept further commands from the client, but it is
not authorised to post articles using the POST command, it MUST present
a 201 greeting code.
Otherwise the server MUST present a 400 or 504 greeting code and then
immediately close the connection. 504 MUST be used if the client is
not permitted under any circumstances to interact with the server, and
400 otherwise.
> 7.1.2 MODE READER
> MODE READER MAY be used by the client to indicate to the
> server that it is a news reading client.
As opposed to what ? What is the effect of sending, or not sending, this
command ?
> 7.1.2.1 Responses
> 200 Hello, you can post
> 201 Hello, you can't post
> 400 Service temporarily unavailable
> 502 Service unavailable
Is there any circumstance where the initial greeting is 20x but this
command responds 400 or 502 ? Is the server required to close the
connection after a 400 or 502 ?
> 8. The CAPABILITIES DISCOVERY Step
> The extension-label to be used in the
> response to the LIST EXTENSIONS command will be specified as
> each new extension is added to the NNTP command set.
[...]
> The extension-label is nominally case sensitive, however the
> definitions of specific labels and parameters specify the
> precise interpretation, and it is to be expected that those
> definitions will usually specify the label in a case
> independent manner. Where this is done, implementations are
> recommended to use US-ASCII upper case letters when
> transmitting the extension response.
This sounds like the worst of all possible worlds; the client has to do a
case-insensitive comparison of some names but a case-sensitive comparison
of others.
Since this is, AIUI, a new command in this specification, why not just
declare it to be case-insensitive like commands are ?
> The LIST EXTENSIONS command itself is not included in the list
> of features supported, support for the LIST EXTENSIONS command
> is indicated by return of a reply other than a 500 or 502
> reply.
What other commands are not indicated by an entry in the list of features
supported ? Reading this makes it look as if the default is for all
commands to be listed in some way. This sentence probably ought to be
reworded. Perhaps:
Except where stated otherwise, the commands in this document
are understood (even if not supported) by all servers and are not
described in the list of features returned by the LIST EXTENSIONS
command.
> A typical example reply to the LIST EXTENSIONS command might
> be a multiline reply of the form:
>
> [C] LIST EXTENSIONS
> [S] 202 Extensions supported:
> [S] OVER
> [S] PAT
> [S] LISTGROUP
> [S] .
Where are those essential spaces ? [And why on earth are they there ?]
> 8.1.3 Error responses from extended servers
> must return code 400. Note that this is response code should
s/this is/this/
> In the case of any error response outlined in this section,
> the client NNTP should issue the QUIT command (see section
> 10.1).
Why ?
> 8.1.5 Responses from improperly implemented servers
>
> A server NNTP that improperly implements the LIST EXTENSIONS
> command may return an empty list. Clients SHALL accommodate
> this protocol violation and interpret it as a response code
> 402.
If they SHALL accommodate it, then it isn't a violation but rather a
required part of the protocol. Is there any reason to call this "improper"
rather than just another way of saying the same thing ?
> 9.1 Article Retrieval
> Article numbers MUST lie between 1 and 4,294,967,295
> inclusive. The client and server SHOULD NOT use leading zeroes
> in specifying article numbers, and MUST NOT use more than 16
> digits. In some situations, the value zero replaces an article
> number to show some special situation.
That much is fine, but this bit:
> One case involves
> responses to the ARTICLE, STAT, BODY and HEAD commands where a
> <message-id> is specified as the argument. In those cases, the
> "current article pointer" is not changed.
isn't. It should be removed and merged with the relevant text in 9.2 (see
below).
> 9.1.1 Article Retrieval by News Group Name and Article Number
>
> The following commands are used to set the current news group
> name and the "current article pointer" which is used by other
> commands for article retrieval.
At the start of the NNTP session no news group is selected.
> 9.1.1.1 GROUP
> If an
> invalid group is specified, the previously selected group and
> article MUST remain selected.
s/group/group, if any,/
> 9.1.1.2 LAST
> The internally-maintained "current article pointer" MUST be
> set by this command.
What is the point of this sentence ? It's not true if there's no current
group, and it's implied by the preceding text anyway.
The following sentence needs "If successful, " prefixed to it.
> 9.1.1.3 NEXT
Same comments. In addition:
> A response indicating the current article number and the
> message-id string MUST be returned. No text is sent in
> response to this command.
s/text/article text/
> Example of an attempt to retrieve an article using the NEXT
> command when the current article pointer is pointing at the
> first article in the group
s/first/last/
> 9.2 Retrieval of Articles and Article Sections
>
> There are two forms to the ARTICLE command (and the related
> BODY, HEAD, and STAT commands), each using a different method
> of specifying which article is to be retrieved. When the
> ARTICLE keyword is followed by a message-id in angle brackets
> ("<" and ">"), the first form of the command MUST be used;
> when a numeric parameter or no parameter is supplied, the
> second form MUST be invoked.
This is badly worded: the form of the article *is* ARTICLE followed by a
parameter - it makes no sense to say that, if the parameter is such and
such then this form MUST be used. Here's a rewrite:
The ARTICLE command (and the related BODY, HEAD, and STAT commands)
have three forms, each specifying the article to be retrieved in a
different way.
ARTICLE <message-id>
indicates that the message is to be retrieved by message-id as given
in the article's header.
ARTICLE nnn
(where nnn is a number) indicates that the message with that number
is to be retrieved from the currently selected group, and
ARTICLE
indicates that the message with the current article number is to be
retrieved from the currently selected group. Apart from the missing
number this third form behaves identically to the second form.
> In the cases where the argument
> is a message-id, the article number specified in the response
> must be zero.
Either that should read "MUST be zero", or (based on an early message on
the list) it should be changed to:
If the argument is a message-id, the article number specified in the
response MUST be either zero, or if the article occurs in the currently
selected group, the number that it holds in that group.
> This is one of the special cases described in
> section 9.1.
Do we actually need this ?
> 9.2.1 ARTICLE
This and the next three commands are *very* similar, and the reader will
have difficulty in determining the differences between them. I would
suggest that almost all the text is moved into 9.2. In fact, move all the
paragraphs except the first, which then gets reduced to:
> ARTICLE [<message-id>|nnn]
>
> This response displays the header, a blank line, then the body
> (text) of the specified article.
The rest is in the rewrite above (except for the bit about:
> and
> SHOULD be chosen from the range of articles provided when the
> news group was selected
which, I think, is a misuse of the term SHOULD.
Looking through the text moved:
> The internally-maintained "current article pointer" MUST be
> set when a valid article number is specified as the argument.
Set to what ? The number of the article specified ? It should say so.
> Example of a failure due to the service being unavailable
> [S] 200 NNTP Service Ready
> [C] ARTICLE <i.am.a.test.article at nowhere.to>
> [S] 500 Service unavailable
I thought it was 502.
> 9.2.2 HEAD
> HEAD [<message-id>|nnn]
>
> This response displays the header of the specified article.
Now delete the rest (up to and excluding the responses) and add:
Except for the different response code when successful, and that it
only displays the header and not the blank line or body of the
article, it is identical to the ARTICLE command.
> Example of a failure due to the service being unavailable
> [S] 200 NNTP Service Ready
> [C] HEAD <i.am.a.test.article at nowhere.to>
> [S] 500 Service unavailable
502 again.
> 9.2.3 BODY
Again, the definition becomes:
This response displays the header of the specified article. Except
for the different response code when successful, and that it only
displays the body of the article and not the blank line or header,
it is identical to the ARTICLE command.
> 9.2.4 STAT
Again:
This response returns only status information about the existence
of the specified article. Except for the different response code
when successful, and that it does not return any text (and so does
not have a terminating dot) it is identical to the ARTICLE command.
> 9.3.1 POST
> 9.3.1.1 Responses
>
> 240 article received ok
> 340 send article to be posted. End with <CR-LF>.<CR-LF>
> 440 posting not allowed
> 441 posting failed
It would be worth having separate "initial responses" and "second
responses" sections to make it clear which is allowed when.
> 9.4 The LIST Keyword
Is there any reason that this is in 9.X but other commands are in 11.X ?
As far as I can see none of the stuff in 9.4 (which, by the way, *isn't*
just LIST) alters the internal state of the server, which is what 11 gives
as the basis for the split.
> 9.4.1 LIST
> group first last status
>
> where <group> is the name of the news group, <last> is the
> number of the last known article currently in that news group,
> <first> is the number of the first article currently in the
> news group,
This should use the same terminology as GROUP does, rather than having an
equivalence described later.
> and <status> indicates the current status of the
> group on this server. Typically, the <status> will be consist
> of the US-ASCII character `y' where posting is permitted, `n'
> where posting is not permitted and `m' where postings will be
> forwarded to the news group moderator by the news server.
> Other status strings may exist. The definition of these other
> values is covered in other specifications.
In what circumstances will other codes be returned ? Can a client assume
that if LIST EXTENSIONS doesn't return anything, or if no extension listed
defines otherwise, no other such codes will appear ?
> Note that posting may still be prohibited to a client although
> the LIST command indicates that posting is permitted to a
> particular news group. See the POST command for an explanation
> of client prohibitions. The posting flag exists for each news
> group because some news groups are moderated or are digests,
> and therefore cannot be posted to; that is, articles posted to
> them must be mailed to a moderator who will post them for the
> original poster.
Bad description; you can usually POST to a moderated group (it's just that
the posting is handled differently).
Can a POST command ever succeed for a "n" group ?
> If the optional matching parameter is specified, the list is
> limited to only the groups that match the pattern.
s/matching/wildmat/ After all, "ACTIVE" is an optional parameter.
> Specifying a single group is usually very efficient for the
> server. Multiple groups may be specified by using wildmat
> patterns (described in section 5), not regular expressions.
Since we don't define regular expressions anywhere, do we need this last
sentence ?
> 9.4.2 LIST ACTIVE.TIMES
> The active.times file is maintained by some news transport
> systems to contain information about when and who created a
> particular news group.
s/when and who created ... group/who created ... group, and when/
> The format of this file generally
> includes three fields.
"generally" ? When is it permitted for the server to return something
different ?
Same comments about wildmat as above.
> 215 information follows
> 503 program error, function not performed
Can 503 be returned if the information is not maintained (I wouldn't call
that an error) ?
> 9.4.4 LIST DISTRIB.PATS
>
> LIST DISTRIB.PATS
>
> The distrib.pats file is maintained by some news transport
> systems to contain default values for the Distribution: line
> in a news article header when posting to particular news
> groups. This information could be used to provide a default
> value for the Distribution: line in the header when posting an
> article. The information returned contains three fields
> separated by colons. The first column is a weight. The second
> is a group name or a wildmat pattern that can be used to match
> a group name. The third is the value of the Distribution:
> line that should be used when the group name matches and the
> weight value is the highest. All this processing is done by
> the news posting client and not by the server itself. The
> server provides this information to the client for it to use
> or ignore as it chooses.
Sorry, but I'm having trouble with this. I *think* that what it means is:
The distrib.pats file is maintained by some news transport
systems to allow clients to choose a value for the Distribution:
line in the header of a news article being posted. The information
returned consists of lines, in no particular order, each of which
contains three fields separated by colons. These fields are a
weight, a group name or wildmat pattern, and a Distribution: value,
in that order.
The client MAY use this information to select a Distribution: value
based on the name of a newsgroup. To do so, it should determine the
lines whose second field matches the newsgroup name, select that line
with the highest weight (with 0 being the lowest), and use the
Distribution: field from that line.
Is that right ?
> 503 program error, function not performed
Again, does 503 include "information not maintained" ?
> 9.4.6 LIST OVERVIEW.FMT
> This is command is part of the optional OVER extension which
> includes the OVER command defined in section 9.4.8. If the
> OVER extension is not implemented, then this command MUST NOT
> be implemented.
s/This is/This/
This paragraph should be first, possibly even before the line that says
LIST OVERVIEW
> 9.4.7 LISTGROUP
> The successful selection response will be a list of the
> article numbers in the group followed by a period on a line
> by itself.
Must they be in numerical order ? Are they all valid articles, or can the
server just list all numbers from low to high water mark ?
> When a valid group is selected by means of this command,
Does this command have the side effect of selecting the group like GROUP
does ? It doesn't say so.
> The LISTGROUP command is an optional extension. It MAY be
> implemented. If it is not implemented, then the LISTGROUP
> label MUST NOT be included in the response to the LIST
> EXTENSIONS command.
This is entirely back to front.
Firstly, if parts of this specification are optional, they are better off
in a separate "optional facilities" clause. That would be a much better way
to split 9.X and 11.X than you have at present. Each extension should be in
a separate 11.X clause with an introduction (this is not the same as the
existing clause 12 on the framework for extensions; in fact, that should
come before the clause I'm discussing here). So, something like this:
11. Standard extensions
Each of the following sections describes an extension that a server
MAY provide. If the server provides the extension, it MUST include
the appropriate extension label in the response to LIST EXTENSIONS.
If it does not provide it, it MUST NOT include the appropriate
extension label.
The descriptions of facilities in each section are written as if the
extension is provided. If it is not provided, the entire section
should be ignored.
11.1 LISTGROUP extension
The extension label for this extension is "LISTGROUP". It provides
one new command.
11.1.1 LISTGROUP command
[Most of what we have right now]
11.2 OVER extension
The extension label for this extension is "OVER". It provides two
new commands: OVER and LIST OVERVIEW.FMT.
11.2.1 LIST OVERVIEW.FMT command
...
11.2.2 OVER command
...
and so on.
> 9.4.7.1 Responses
>
> 211 list of article numbers follow
> 411 No such group
> 412 Not currently in news group
What is the response for "this extension not supported" ? If there is a
generic code for this, I seem to have overlooked it.
> 9.4.8 OVER
There's no need to mention an "overview database", since that is just an
implementation technique.
Nowhere does it say that a range argument applies to the currently selected
group.
> Each line of output MUST be formatted with the article number,
> followed by each of the headers in the overview database or
> the article itself (when the data is not available in the
> overview database) for that article separated by a US-ASCII
> tab character. The sequence of fields must be in this order:
> subject, author, date, message-id, references, byte count, and
> line count. Other optional fields may follow line count. These
> fields are specified by examining the response to the LIST
> OVERVIEW.FMT command. Where no data exists, a null field must
> be provided (i.e. the output will have two tab characters
> adjacent to each other). Servers should not output fields for
> articles that have been removed since the overview database
> was created.
>
> Note that all US-ASCII tab characters in any header data that
> is returned will be converted to a single US-ASCII space
> character. A contiguous sequence of US-ASCII non-printing
> characters will be compressed to a single US-ASCII space
> character in any output response.
>
Better wording:
The output consists of one line per article, sorted in numerical
order of article number. Each line consists of a number of fields
separated by a US-ASCII tab character. The first 8 fields MUST be
the following, in order:
article number, subject, author, date, message-ID, references,
byte count, line count
The content of any subsequent field is given by the response to the
LIST OVERVIEW.FMT command. A field may be empty (in which case there
will be two adjacent tabs, and a sequence of trailing tabs may be
omitted). Any sequence of US-ASCII white-space or non-printing
characters in a field MUST be replaced by a single space.
The server SHOULD not produce output for articles that no longer
exist.
Actually, even better wording would be to give a proper syntax for these
responses, using RFC 2234.
I've made a number of assumptions in this rewording; someone should check
that I'm correct.
Should the response from LIST OVERVIEW.FMT include "Subject:" etc ? What
about the article number ?
> 9.4.9 PAT
>
> PAT header range|<message-id> [wildmat[ wildmat"]]
I take it the " is a typo.
> An
> additional argument consisting of one wildmat or two or more
> wildmats separated by a space may be specified. If there are
> no additional argument, a wildmat "*" is the default.
Additional arguments consisting of one or more wildmats, separated
by a space, may be specified. The default is the single wildmat "*".
Nowhere does it say that the range argument applies to the currently
selected group.
> Successful responses start with a 221 response followed by
> article number, an US-ASCII space, and the header from that
> message in which the argument pattern matches the contents of
> the specified header line.
A successful response consists of a 221 code followed by the output
from the command. The output consists of one line for each article
where the relevant header line matches one or more of the wildmats.
The line consists of the article number, a US-ASCII space, and then
the contents of the header (without the header name).
Note that the present wording implies that the output is on the same line
as the 221 code.
[The following applies to all commands with multi-line output.]
> Once the output
> is complete, a period is sent on a line by itself.
You know, this wording appears in a number of places, yet when we say it
we never talk about stuffing lines that begin with dot with an extra dot.
The last but one paragraph of section 4 adequately explains how multi-line
responses are formatted, including the trailing dot. Having this wording is
just confusing - a naive server implementer could be forgiven for thinking
that the output be:
221 1234 Subject of 1234
1234 Subject of 1235
..
.
where the .. is the "period is sent on a line by itself" and the . is the
terminating octet described on page 3.
Why not be consistent with section 4 and describe the response like this:
A successful response is indicated by a 221 response code. This is
a multi-line response, and each additional line of output corresponds
to an article where the relevant header line matches one or more of
the wildmats. Each line consists of the article number, a US-ASCII
space, and then the contents of the header (without the header name).
That's it; no need to mention the trailing dot.
The responses section for each command could reasonably indicate whether
each response was single- or multi-line (perhaps by putting "[M]" in front
of, or after, the present description).
> [S] 221 Header Follows
>
> 3000234 I am just a test article
>
> 3000237 Re: I am just a test article
>
> 3000238 Ditto
>
> .
>
Please can we either omit the blank lines or put an [S] at the start of
every line of output ?
> 10. The CONCLUSION Step
>
> 10.1 QUIT
>
> QUIT
>
> The server process MUST acknowledge the QUIT command and then
> closes the connection to the client.
s/closes/close/
> 11. Other Keywords
>
> There are other keywords that may be used at any time between
> the beginning of a session and its termination. Using these
> keywords do not alter any state information, but the response
s/do not/does not/
> 11.1 DATE
> that might be useful when using the NEWNEWS command (see
> section 0).
Section 0 ?
> 11.1.2 Example
> [S] 200 NNTP Service Ready
>
> [C] DATE
>
> [S] 19990623135624
This does not match the specification.
Do we actually need the server 200 response in these examples ? It tends to
imply that the command is only allowed as the first thing in a session.
> 11.4 NEWNEWS
>
> NEWNEWS newsgroups date time [GMT]
>
> A list of message-ids of articles posted or received to the
> specified news group since "date" will be listed.
s/group/group or groups/
> Note that an empty list (i.e., the text body returned by this
> command consists only of the terminating period) is a possible
> valid response, and indicates that there is currently no new
> news.
Can the same ID appear more than once in the response ? Is there any
significance to the order of the lines in the response ?
> 12. Framework for NNTP Extensions
> . any new parameters the extension associates with any other
> pre-existing NNTP verbs
s/verbs/commands/ or s/verbs/keywords/ (can we be consistent about this ?)
> . the increment by which the extension is increasing the maximum
> length of the any commands over that specified in this
> document.
. any increase in the maximum length of commands over the value
specified in this document.
> Additional verbs are bound by the same rules as NNTP keywords;
> specifically, verbs beginning with "X" are local extensions
> that MUST NOT be registered or standardized and verbs not
> beginning with "X" must always be registered.
s/always be registered/be part of a registered extension/
> 13. Augmented BNF[9] Syntax for NNTP Commands
>
> This syntax defines the non-terminal "command". The non-terminal
> "parameter" is used for command parameters whose syntax is
> specified elsewhere. The syntax is in alphabetical order.
Is alphabetical order really best ?
> 16. References
> 2 Yergeau, F., "UTF-8, a transformation format of ISO 10646",
> RFC 2278, Alis Technologies.
s/2278/2279/
> 17. Acknowledgments
> The author gratefully acknowledges the work of the Marshall
> Rose & John G. Meyers in RFC 1939
Colour me puzzled: RFC 1939 is POP3, and I don't see the relevance.
> This work was precipitated by the work of various newsreader
> authors and newsserver authors,
Is "precipitated" the word you want here ?
--
Clive D.W. Feather | Work: <clive at demon.net> | Tel: +44 20 8371 1138
Internet Expert | Home: <clive at davros.org> | Fax: +44 20 8371 1037
Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646
More information about the ietf-nntp
mailing list