Early comments for merged document RFC 977 plus extensions draft

Fri Jun 28 14:07:47 PDT 1996

Stan,

You mentioned in the nntp BOF at the Montreal IETF meeting that you
would correct and clarify RFC 977, and merge it with your draft
"current practice extensions".

Appended are my comments on RFC 977, followed by my comments on your
extensions draft.  I hope they're useful.

Anne.
-- 
Ms. Anne Bennett, Computing Services, Concordia University, Montreal H3G 1M8
anne at alcor.concordia.ca                                       (514) 848-7606
----------------------------------------------------------------------------

Comments on RFC 977:

| 2.2.  Character Codes
| 
|    Commands and replies are composed of characters from the ASCII
|    character set.  When the transport service provides an 8-bit byte
|    (octet) transmission channel, each 7-bit character is transmitted
|    right justified in an octet with the high order bit cleared to zero.

A 7-bit response implies that an article returned by, say, the article
command, would have its high bits stripped, which I am sure is not the
case, at least with INN-1.4sec.  Ideally, we'd have an 8-bit channel
for everything, but in any case, current practice should be documented
correctly.

| 2.3.  Commands
[...]
|    Commands and command parameters are not case sensitive. That is, a
|    command or parameter word may be upper case, lower case, or any
|    mixture of upper and lower case.

I may be mistaken here, but aren't Message-IDs case sensitive?

| 3.7.1.  NEWGROUPS
| 
|    NEWGROUPS date time [GMT] [<distributions>]
[...]
|    The optional parameter "distributions" is a list of distribution
|    groups, enclosed in angle brackets.  If specified, the distribution
|    portion of a new newsgroup (e.g, 'net' in 'net.wombat') will be
|    examined for a match with the distribution categories listed, and
|    only those new newsgroups which match will be listed.  If more than
|    one distribution group is to be listed, they must be separated by
|    commas within the angle brackets.

This use of the word "distributions", where really "hierarchy" is
meant, has led to many misunderstandings and flame wars later.  Or
perhaps it would be more fair to say that subsequent changes in usage
were at fault -- I wasn't around NNTP ten years ago, so I should not
venture an opinion as to the origin of the problem.

However, the fact remains that "distributions" now refers to the
content of the "Distributions:" field -- and indeed you use it that
way in your draft, as I recall -- so I think it would be wise to use
another word in the text above.

The same can be said under the description of NEWNEWS.

----------------------------------------------------------------------------

Comments on extensions draft:

| 1. Transport Extensions
[...]
|     Each command is shown in upper case for clarity, although
|     case is ignored in the interpretation of commands by the
|     NNTP server.  Any parameters are shown in lower case.  A

As per my comments on the RFC, I believe that Message-IDs are
case-sensitive.

Absolute path of article?  This seems rather
implementation-dependent...  Of what use is it?

| 2.1.3 LIST ACTIVE.TIMES
| 
|     LIST ACTIVE.TIMES

No "[wildmat]" on this one?  This seems non-orthogonal and
counter-intuitive, since other commands which refer to a list of
newsgroups permit a wildmat restriction.  If this is indeed the
implementation and we are supposed to be describing current practice,
there's not much to be done, but I question the wisdom of having this
command different from its siblings.

This is, IMHO, the "right" way to use the word "distribution" (cf my
comments on the RFC).  We should add a mention, though, that the
"validity" of the values is site-dependent.

| 2.1.6 LIST NEWSGROUPS
[...]
|     When the optional parameter is specified, this command is
|     equivalent to the XGTITLE command, though the response code
                                                             ^^^^
                                                             codes
|     are different.

| 2.5 XGTITLE
[...]
|     Please note that this command and the LIST NEWSGROUP command
|     provide the same functionality with different response codes.
| 
|     Since this command provides the same functionality as LIST NEWSGROUP
|     it is suggested that this extension be depreciated and no longer be
                                             ^^^^^^^^^^^
                                             deprecated
|     used in newsreading clients.

I'd use stronger language, and state that the extension *is*
deprecated, not just suggest that it should be.

| 2.6 XHDR
[...]
|     The XHDR command has been available in the UNIX reference
|     implementation from its first release. However, until now,
|     it has only been documented in the source for the server.
             ^^^^^^^^^^^^^^^^^^^^
             been documented only

| 2.7 XINDEX
[...]
|     Since more recent
|     versions of TIN support the news overview (NOV) format, it
|     is recommended that this extension become historic and no
|     longer be used in current servers or future implementations.

Again, I'd use stronger language and state that this extension is
deprecated.

| 2.9 XPAT
| 
|     XPAT header range|<message-id> pat [pat...]
| 
|     The XPAT command is used to retrieve specific headers from
|     specific articles.
                       ^
                       , based on pattern matching on the contents
      of the header.

[...]
|                At least one pattern in wildmat must be specified
|     as well. If there are additional arguments the are joined
|     together separated by a single space to form the complete
|     pattern. 

What are the semantics?  "Or" on the various patterns given?

Will empty lists be "successful"?

|              If the optional argument is a message-id and no
|     such article exists, the 430 error response is returned.
|     A 502 response will be returned if the client only has
|     permission to transfer articles.

The sentence fragment "if the client only has permission to transfer
articles" is sub-optimal, because it refers to the problem
only indirectly -- i.e., saying what permission the client *has* instead
of what permission is *lacking* and thus causes the denial of the
service request.  How about "if the client has no permission to read
news, or is denied access to the current newsgroup or to the article
specified by the Message-ID"?

Hmm, it occurs to me that the facility which exists (at least in INN)
to permit a client access to a subset of available newsgroups affects
several commands.  It might be useful to define "client has no
permission to read" at the top of the document, stating that this
might mean that the client is expected to transfer news only and not
read, or that the client has permission to read, but is denied access
to the newsgroup or article in question.

| 2.10 XROVER
[...]
|     The XROVER command returns reference information 
                                                      , i.e. the
      contents of the "References:" header,

|                                                       from the
|     overview database for the article(s) specified.
[...]
|     The output will be formatted with the article number,
|     followed by the contents of the References: line for that article.

Does the contents of the line include the initial word "References: "
or not?

|     This command provides the same basic functionality as using
|     the XHDR command and "references" as the header arguement except
                                                      ^^^^^^^^^
                                                      argument
|     that it only uses information from the overview database. XHDR
|     typically searches the articles themselves.

Not necessarily true;  for example, in Wayne Davison's nntp
implementation, the overview database is used for XHDR when possible,
and this resulted in a tenfold performance improvement according to my
tests.  In any case, it's an implementation matter, and probably
should not be mentioned in this document.

IMHO, since XHDR provides the functionality (or can do so, if overview
is used and is configured according to the author's default), this
command should be deprecated.

| 2.10.1 Responses
| 
|         224 Overview information follows
              ^^^^^^^^
              Is this a typo?

|         412 No news group current selected
|         420 No article(s) selected
|         502 no permission

| 2.11 XTHREAD
[...]
|     Since more recent
|     versions of TRN support the news overview (NOV) format, it
|     is recommended that this extension become historic and no
|     longer be used in current servers or future implementations.

Again, I suggest stronger language.

| 3.1.2 AUTHINFO SIMPLE
[...]
| 
|     This version of AUTHINFO was part of the proposed NNTP V2
|     specification 

That sounds very definite; a reference should be given.
Alternatively, if the proposal never took off at all and no reference
can be given, perhaps an alternative phrasing would be better, such as
"a proposed specification for NNTP V2, which started in 19?? but was
never completed and has been abandoned".

[...]
|     Note that the response codes used here were part of the
|     NNTP V2 specification and are violations of RFC 977.

Since this will now be in a document which supersedes 977, I think
that this sentence is no longer needed. :-)

| 3.2 DATE
| 
|     DATE
| 
|     The NNTP v2 draft specification added this command to help
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Same comment as above.  It might be easiest to explain the situation
at the top of the document, and subsequently refer to "the abandoned
nntp v2 specification".

|     clients find out the current time from the server's perspective.
|     At the time this command was discussed (1991-1992), the
|     Network Time Protocol [9] (NTP) was not yet in wide use and there
|     was also some concern that small systems may not be able to make
|     effective use of NTP.

Nice rationale, BTW.  Should we add something to the effect that this
is still considered a useful command, since there are still many
systems which do not use ntp, and in any case it circumvents potential
confusion when client and server are in different time zones, or worse
when the client is mobile and may change time zones?

| 3.4 Additional Headers
| 
|     Many NNTP implementations add headers to Usenet articles when then
|     are POSTed via NNTP. These headers are discussed in this section.

I'm not sure that headers should be discussed at all in this document
(other than under commands where they are given as a parameter or
otherwise implied by the command), and your intro here above only half
convinces me.

| 3.4.1 NNTP-Posting-Host

If you list this one, though, I'd like to see NNTP-Posting-User as
well.

[...]
|     If the client article contains this line,
|     it is removed by the server before acceptance of the article
|     by the Usenet transport system.

Or the server (INN, anyway) rejects the article with 441.  This
eventuality should be covered in the description of POST, if it is not
already.

|     This header provides some idea of the actual host posting
|     the article as opposed to information in the Sender or From
|     lines that may be present in the article. This is not a
|     fool-proof methodology since reverse lookups in the DNS
|     are vulnerable to certain types of spoofing, 
                                                   as are IP
      addresses themselves,
|                                                  but such
|     discussions are outside the scope of this document.

| 3.4.2 X-Newsreader and others

Now this really does not belong in this document, but rather in
son-of-1036.

| 4.0 Future Work

I guess that this section will be revised completely to describe the
(human) procedure for adding extensions.

| 5.0 Security
| 
|     No security issues are discussed in this document.

I attended the Security area open meeting at the IETF this week, and
it was made clear that avoidance of security issues in protocol
specifications is no longer acceptable.  I think that a brief
discussion could be added of authentication (of hosts for transfer,
and of hosts and users for reading and posting), and of whether the
protocol can be used to attack the server, for example by denial of
service (unavoidable), to trick the server into performing unexpected
commands (can be done by certain articles if implementation does not
parse them carefully, but this is not the fault of the protocol), or
in other ways that have not occurred to me offhand. :-)  This is not
to say that the protocol must be changed to improve security (though
there is something to be said for that!), but that we should be aware
of what the issues are, and make our readers aware of them as well.

General comments:  for the responses to the commands, I believe it is
correct to state that the number (first word of the response) is
significant, while the text following the number and on the same line
is *not* significant (is implementation dependent).  If so, we should
make this clear.

Also, since this document is to be merged with the revised RFC, I
think we should be careful to avoid throwing in everything but the
kitchen sink.  In particular, it's fine to document certain extensions
for historic reasons, but they should be clearly marked as deprecated
-- perhaps there should be a separate section for deprecated commands.
If the "new" extensions are optional, we should note that as well.

Several commands have an optional range or Message-ID argument; I
think we should define the syntax and semantics once at the top of the
document, instead of repeating the same description multiple times.

----------------------------------------------------------------------------