[NNTP] draft-ietf-nntpext-base-25 comments

[Russ Allbery]

David Magda <dmagda+nntpext at ee.ryerson.ca> writes:

> 2.  Notation
>     [...]
>    A "keyword" MUST consist only of US-ASCII letters, digits, and the
>    characters dot (".") and dash ("-"), and must begin with a letter.

> Should this be:

>     ... and MUST begin with a letter.

I think so.

> 3.1  Commands and Responses
>     [...]
>     NNTP operates over any reliable data stream 8-bit-wide
>     channel. Initially, the server host starts the NNTP service by
>     listening on a TCP port.  When a client host wishes to make use
>     of the service, it MUST establish a TCP connection with the
>     server host by connecting to that host on the same port on which
>     the server is listening.

> The first sentence says "any ... channel", but then there's a MUST
> for using TCP. A bit contradictory? This would explicitly disallowd
> using Unix sockets or pipes for connections. 

Yeah, that doesn't seem quite right to me either, as people certainly do
use NNTP over something other than TCP.  There's nothing inherent to NNTP
that requires a TCP channel.  I'd prefer to just drop the standards
language from that sentence and instead just say:

    NNTP operates over any reliable data stream 8-bit-wide channel.  This
    document assumes use of TCP, but other bidirectional stream protocols
    can and sometimes are used.

    Initially, the server host starts the NNTP service by listening on a
    TCP port.  When a client host wishes to make use of the service, it
    establishes a TCP connection with the server host by connecting to
    that host on the same port on which the server is listening.

or something along those lines.

> 7.3.1  Usage
>       NEWGROUPS date time [GMT]
>     [...]
>     The token "GMT" specifies that the date and time are given in
>     Coordinated Universal Time [TF.686-1]; if it is omitted then the
>     date and time are specified in the server's local timezone

> Just curious: if you mean UTC, why not have "UTC". I know it's probably
> for backwards compatibility, but perhaps a SHOULD for "UTC" and MAY
> accept "GMT"?

This was discussed a fair bit previously.  The problem with switching to
UTC is that in essence we would be declaring all existing clients
noncompliant with the standard for solely pedantic reasons, and in
practice there are so many servers that only understand GMT that clients
couldn't switch anyway.  To properly do a migration, we'd need to add a
capability flag saying which one to use, and it's overkill for a point of
minor technical accuracy.

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