ietf-nntp Review of draft-dfncis-netnews-admin-sys-04.txt

[Russ Allbery]

ned <ned+ietf-nntp at innosoft.com> writes:

> The draft listed above has been submitted to the RFC Editor for
> publication. It is customary for the IESG to ask WGs in areas related to
> such individual submissions to review them. NNTPEXT seems like the right
> group to me to do such a review, so please have a look and tell me
> (either on the NNTPEXT list or privately) what you think.

I'd previously reviewed this protocol somewhat privately.  I think it
would be workable, but I have the following general concerns:

 * Most of the information that sites are currently tracking about news
   hierarchies is available via the NNTP protocol itself with LIST
   ACTIVE and LIST NEWSGROUPS.  There already exists software to connect
   to any number of servers via NNTP and use those commands to build a
   newsgroup list and merge it into the local newsgroup list.  It seems
   kind of unfortunate to design a whole new protocol to do this, although
   if anyone actually starts using all that additional information
   provided for in this draft, it could be useful.

 * I'd really like to see the packets of information about a hierarchy
   registered as a MIME type.  I don't think that would be much additional
   work for this draft, and then those packets could also be included in
   control messages.

 * The section on PGP keys (6.7) I think should be reviewed by someone who
   is familiar with PGP interoperability and standardization issues.  I
   think some of the information being provided is underspecified and
   worthless (the PGP version number, for example) and that other things
   should be specified and aren't (like the key algorithm or the packet
   format version).  It looks like the basics originally came from the
   pgpverify work, and that's one of the open problems with the format of
   the headers produced by pgpverify (not enough information, and the
   information included isn't all that useful).  Similarly, the PGP type
   parameter to GETP and GETA is using PGP2, PGP5, and GPG as types of
   signatures and it would probably be better to use standard OpenPGP
   version numbers with some special designated version number for old PGP
   2.6.x-compatible signatures (since GnuPG signatures are interoperable
   with current versions of PGP now, and are properly termed OpenPGP v4
   signatures).

 * The protocol version number approach that they're taking is an
   interesting one, but I think it may be less flexible than the approach
   used by most other protocols, which is to provide a base protocol and
   then some method of querying the server for extensions.  One can
   simulate the former with the latter, and the latter also allows for
   more degrees of freedom.  Not sure if it's important enough to ask them
   to change it or not.

 * I dislike the way that data about individual groups in GETP and GETA
   are, in effect, delimited by a Name: header.  That requires additional
   code to figure out when data for one group ends and another starts and
   is unnecessarily hard to read.  Requiring a blank line between data for
   groups would be a simple change and make coding this easier.

 * The DATA example implies that RFC 2822-style header continuation is
   allowed in the key-value pairs, but that doesn't appear to be allowed
   by the ABNF.

 * Minor nit:  There is no discussion of how long each line in a multiline
   response can be.  If the intent is for it to be unlimited, that should
   probably be stated explicitly.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>