[NNTP] Notes on auxiliary documents

[Clive D.W. Feather]

A cluster of notes on the three auxiliary documents (authinfo, tls, and 
streaming). Mostly editorial.


General
=======
The word "draft" shouldn't be used to refer to the document itself. It 
should be "specification" or "document".

The core specification never includes generic responses in the pro-forma 
sections for each command (unless they have some unusual meaning, such 
as 502 for MODE READER). They *are* referred to in the description to 
explain how to report various situations. The one case I have 
specifically noted is in STARTTLS, but there may be others.


authinfo-05
===========
Section 1 para 1: change "has traditionally provided public access" to 
"has traditionally been used to provide public access". [NNTP is the 
mechanism, not the agent.]

Next para, last sentence, I would reword as:

    Due to their ubiquity they are formalized in this specification but,
    because of their insecurity, only for use ...

Section 2.2: "Servers are not required to accept unsolicited 
authentication". I don't follow this. Since the server advertises its 
conformance with this document (through CAPABILITY / LIST EXTENSIONS), 
it is soliciting authentication. The only way I can read this is that, 
despite that, authentication is not permitted *until* a 480 happens. Um:

    [C] LIST EXTENSIONS
    [S] 202
    [S] AUTHINFO USER SASL:EXTERNAL
    [S] .
    [C] AUTHINFO USER fred flintstone
    [S] 481 unsolicited authentication rejected (or is it 503?)
    [C] GROUP secret.group
    [S] 480 need to authenticate
    [C] AUTHINFO USER fred flintstone
    [S] 281 Hello Fred.

Surely that can't be desirable?

Section 2.4.2: I know that we've discussed this before, but I think the 
code for "don't handle this mechanism" shouldn't be 501 but, rather, 503 
or something AUTHINFO-specific.

Just above the wording you changed, I suggested that "if a security 
layer as part of the authentication," be deleted after "In agreement 
with [SASL]". If this ability is useful (I'm still agnostic), then it 
could be useful in other circumstances as well.

Sections 2.4.2 and 6: we say that the server MUST discard all knowledge. 
Does this include NNTP state? E.g.

    [C] GROUP a.group
    [S] 211 10 555 666 a.group selected
    [C] AUTHINFO SASL MECHANISM
    [SASL details omitted, security layer created]
    [S] 281
    [C] ARTICLE 10

Does the server respond with 220 or 412? Whichever the answer is, it 
needs to be made more clear.

Section 3.1: in the last paragraph, insert ", both exclusive, after 
"between the first ... CRLF".

Section 6, last paragraph: add something like "The minimum strength 
acceptable will, of course, depend on specific circumstances and is 
outside the scope of this specification." Otherwise it implies there's 
some definition of "weak" which we're hiding (just to be perverse?).


streaming-02
============

I notice that you switch between "pipeline", "stream", and "asynchronous 
transfer" with no apparent consistency. We agreed to call the basic 
concept "pipelining", and that's what the core document calls it. You 
may want to revisit this.

Section 1 (and possibly elsewhere) talks about "server-to-server". NNTP 
doesn't have server-to-server links. Again, we should be consistent and 
only say "peer-to-peer" and "client-to-server".

Section 2.3.2 gives too much emphasis on non-conforming implementations. 
Replace it completely with something very similar to:

    On a server which conforms to this specification, the MODE STREAM
    command MUST return a 203 response (or 501 if an argument is given)
    and MUST NOT have any other effect.

    Historic note: some old server implementations did not advertise
    streaming in the response to LIST EXTENSIONS but provided CHECK and
    TAKETHIS commands similar or identical to those in this document.
    Clients could test for this by issuing the MODE STREAM command; if
    it succeeded, pipelining was possible. However, even if the command
    succeeded it does not mean that the CHECK and TAKETHIS commands
    conform to this specification. Clients SHOULD use the CAPABILITY
    command to determine server capabilities.

Section 2.4.2: is "another client is sending the same article" the best 
example? Surely "disc full" or something like that would be better.


tls-03
======

Section 2.2.2 para 6: The text "The TLS negotiation begins ... response" 
only handles one direction; compare the corresponding text in AUTHINFO 
SASL. It should be something like "For the server to client direction, 
the TLS negotiation ... response; for client to server it begins with 
the next octet sent after the CRLF at the end of the command."

In the following paragraph, surely "MUST discard" should be "SHOULD NOT 
rely on", since the client can still make heuristic decisions.

Section 5 para 3: you've got two sentences beginning "Further,"; I would 
omit the first instance. And the last sentence needs something like "or 
vice versa" at the end.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
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            |                            |