ietf-nntp Collected minor issues

[Clive D.W. Feather]

Russ Allbery said:

[If I don't comment, it means I've accepted the general point and will edit
the text in the next draft.]

> 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.

Not as far as I can tell. Unless I start hacking on the source, which means
our document will use a different style to other RFCs.

> 3. Basic Operations
>   Saying that the client host and server host SHOULD exchange commands
>   strikes me as odd.

Agreed.

>   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.

I'll look at new wording.

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

The decision on whether header names, message-IDs, and such-like things -
when they appear in NNTP commands and responses - are case or language
specific.

> 4.1. Wildmat syntax

>     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.

I'd rather keep the present sentence there.

>     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.

But I prefer this one and will use it, or something similar.

> 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?

Disagree. It's saying "this command is for the onward propogation of
articles, but that still doesn't prevent you deciding not to accept this
particular article".

> 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.

Does anyone want to trawl the archives for this? I'll put it as an issue
for now.

> 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.

Any objectors?

> 10.4.1. The :bytes metadata item
>   I like this section as written.

Thank you.

>   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.

True. The bytes v octets thing is not a big deal over the wire, where
everyone sends 8 bit bytes, but they *are* different concepts on
non-POSIX systems (POSIX now requires 8 bit bytes).

Is there an IETF style guide on such things?

> 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.

Okay. This turns out to be the only reference to 502 outside the generics
and the startup phase.

> 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.

True. I'll drop it if no objections.

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

Noted.

> 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.

I'm not going to worry too much about the normative/informative split until
we've got some fairly final text. Then I'll make a proper pass through the
references and clean that up.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <clive at davros.org>  | Fax:  +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |