[NNTP] Notes on auxiliary documents

[Ken Murchison]

Clive D.W. Feather wrote:

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

Fixed the one instance (in AUTHINFO) that I found.


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

502 is listed in both AUTHINFO and STARTTLS pro-forma sections to make 
it clear that it also applies after these commands have been used (per 
the notes).  I'm pretty sure this was discussed before and it was signed 
off on.  I really don't care if we keep it or remove it, but at this 
point, I'd like to change as little as possible since we appear to be in 
a "final tweaking" stage.


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

Done.


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

Done.


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

Correct, I think this is what Jeff is trying to say.  That the client 
can go ahead and authenticate without having received a 480 response and 
the server must accept authentication even is not prompted by a 480. 
Essentially, this sentence is to be paired up with the first sentence of 
the previous paragraph.

I'll gladly take some suggested text, unless you feel that this sentence 
can be deleted entirely.


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

This has already been changed.  Did you see my "proposed changes" posts?


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

Continuing to advertise only makes sense when a security layer is 
advertised, since the info can be trusted otherwise (a MiM attack could 
still be in progress).


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

That's a good question.  This wording comes from the other SASL profile 
docs (IMAP, POP, SMTP) in which authentication usually (always?) happens 
before other commands.

I don't *think* that server has to go back to the "unselected group" 
state after auth, but my guess is that if the client authenticates in 
the middle of a session its because they are trying to access a group 
that returned a 480 and therefore will be changing groups immediately 
after auth.

Does anyone have any string feelings on this?


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

I don't understand what change your are requesting (you only have 3 
quotes in your suggestion).

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

I added: "The minimum strength acceptable is a policy decision which is 
outside the scope of this specification."


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

Please look at my "proposed changes" post and see if it addresses this. 
  Of course, based on Andrew's post, we may have to change this yet again.


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

I fixed the two instances in Section 1.  I believe the wording is 
correct elsewhere.


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

First off, I think Russ signed off on the current text, but I'm willing 
to clarify if needed.  In fact, I like most of what you have above.

This is a similar situation to MODE READER.  We are trying to steer new 
implementations away from MODE STREAM but document its prior use.

Russ, can you provide some guidance?


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

I used the wording from your subsequent post.


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

I don't see the confusion.  For both client and server the negotiation 
starts after the CRLF.  The same wording (except for "octet") is in IMAP 
and POP.


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

I'm not sure about this.  Based on Mark's comments from the MODE READER 
thread, I *think* that this is almost a requirement of TLS (whether 
implicitly or explicity, I don't know).

Russ, guidance?


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

Sentence removed, not sure what "vice versa" gets us.


-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp