ietf-nntp Collected minor issues

[Russ Allbery]

OVERALL

  I think "netnews" is better than "net news".

Administration

  Ned and I are both chairs of the group.

Outstanding issues

  Yes, I think that every RFC mentioned should be included in the
  references, but most of them should be informative.  I also prefer the
  [RFC 977] syntax, although I don't know if xml2rfc can do that easily.

3. Basic Operations

  Saying that the client host and server host SHOULD exchange commands
  strikes me as odd.  It's not a big deal, but some other wording there
  would be better.  Maybe just saying "The client host and server host
  then exchange commands and responses (respectively)....".

  I agree that the whole breakdown of the NNTP protocol in this section
  seems unnecessarily complex.  It seems easier to just say that the
  client connects, the server returns a greeting, and then they exchange
  commands and responses until either the client sends QUIT or one or the
  other closes the connection.

  The reference to RFC 1036 specifying when parameters are case or
  language specific is odd.  What are we delegating to RFC 1036 here?

  I agree with the comment in OUTSTANDING ISSUE that the initial response
  line should also be limited to 512 octets; the proposed text looks fine
  to me.

4.1. Wildmat syntax

  The note at the end of this section is basically fine, but I'll nitpick
  the wording a little.  There is fairly standard practice for backslash
  and brackets, but they're not universally implemented.  Maybe something
  more like:

    Note: the characters \, [, and ] are not allowed in wildmats, while *
    and ? are always wildcards.  There is no need for a * or ? character
    that is not a wildcard in this specification since within it wildmats
    are only used on newsgroup names.  Backslash is commonly used to
    suppress the special meaning of characters and brackets to introduce
    sets, but this usage is not universal and interpretation of these
    characters in the context of UTF-8 strings is potentially complex and
    different from existing practice, so they were omitted from this
    specification.  A future extention to this specification may provide
    semantics for these characters.

7.1.1.2. Description (GROUP)

  Recommend a paragraph break after the sentence "No similar assumption
  can be made about the high water mark...."

7.3.1.2. Description (POST)

  To address Charles's comment, it may be worthwhile to add a note to the
  last paragraph saying:

    Reusing the same message-id is preferred since articles may not always
    be made available for reading immediately (for example, they may have
    to go through a moderation process first).

7.3.2.2. Description (IHAVE)

  In the paragraph starting with "This function differs from the POST
  command," the sentence beginning with "However" doesn't make a lot of
  sense to me in context.  It doesn't seem to be related to the previous
  paragraph.  Maybe add a paragraph break here and remove the "However,"
  at the beginning of the sentence?

8.1.2. Description (DATE)

  MUST NOT isn't appropriate when saying that DATE isn't NTP since it
  doesn't actually break anything directly; SHOULD NOT is sufficient.

  I don't think we should point to a particular protocol for keeping the
  server time; if the server is connected directly to a GPS receiver,
  that's as good as using NTP.  We also don't need to have a normative
  reference to NTP here.  Alternate text:

    A system providing NNTP service SHOULD keep the system clock as
    accurate as possible, either with NTP or by some other method.

8.3.2. Description (NEWGROUPS)

  Yes, the response from NEWGROUPS includes the high, low, and status
  information.  The examples should be fixed.  (At least, that's what INN
  does; if that isn't what we should standardize, people should speak up
  now.)

  Add to the end of the first paragraph:

    Clients SHOULD use four-digit years.  Two-digit years are supported
    only for backward compatibility.

8.6.2.2. Description (LIST ACTIVE.TIMES)

  The third field isn't always a mailbox as defined in RFC 2822 because
  mailbox requires that it be fully qualified, and unqualified addresses
  are very common for groups created directly by the administrator.  I
  know we talked about this before, and I don't remember the overall
  outcome of that discussion now, but I think it would be better to treat
  the third field as a purely free-form comment rather than trying to
  constrain its syntax.

8.6.5.2. Description (LIST NEWSGROUPS)

  The newsgroups file is normally tab-delimited.  Change "by one or more
  US-ASCII space characters" to "by one or more US-ASCII space or tab
  characters."

10. Framework for NNTP extensions

  Any extension should also include the valid responses from any new NNTP
  commands specified.

10.3.1.2. Description (LISTGROUP)

  Yes, I think we should require that the format of the first response
  line be the same as the response from GROUP.  INN didn't used to do
  this, but that's now been fixed.

10.4.1. The :bytes metadata item

  I like this section as written.  I think it should count octets, but I
  think it should be called :bytes because that's what people are used to
  thinking of it as.  I don't think it should count UTF-8 characters; that
  would require that we know the body encoding.

10.5.1.2. Description (OVER)

  I think we should simply omit the mention of 502 and that entire
  sentence.  That's an extremely rare case anyway, and the section on
  generic response codes covers it fine.

10.6.1.2. Description (HDR)

  The reference to RFC 1036 here should be omitted (just drop that
  sentence).  There are lots of interesting headers that aren't defined in
  RFC 1036.

  I think that metadata items should be required to begin with colons,
  yes.

  Recommend a paragraph break in the last paragraph before "A server MAY
  only allow HDR commands...."; that's important, and right now it's lost
  in the middle of that long paragraph.

Normative References

  [7], [8], and [10] are not normative after the above suggestions, I
  believe.  We need to clarify whether RFC 977 should be listed as a
  normative reference and whether RFC 1036 can be.

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