ietf-nntp Re: [NNTP Draft] 8. The CAPABILITIES DISCOVERY Step

[Russ Allbery]

These are responses to a complete reading of the current draft (I took
advantage of Andrew's recent posting of it to news.software.nntp to review
it).  I'm commenting as I see things that seem unclear.

Andrew Gierth <andrew at erlenstar.demon.co.uk> writes:

>           8.1 LIST EXTENSIONS

[...]

>             Each line listing an extension in the extension-listing
>             begins with a single space.  That space IS NOT optional, nor
>             does it indicate general white space.  This space guarantees
>             that the line can never be misinterpreted as the end of the
>             extension- listing, but is required even where there is no
>             possibility of ambiguity.

I don't understand the purpose of this.  What's the justification for not
using period-stuffing like every other multiline response uses?  In
practice, the stuffing will rarely be necessary, as capabilities won't
begin with a period (in fact, that could simply be explicitly ruled out).

Requiring specific types of whitespace is a recipe for disaster.  Humans
assume that where there is whitespace, arbitrary whitespace is allowed.

>             A typical example reply to the LIST EXTENSIONS command might
>             be a multiline reply of the form:

>                     [C] LIST EXTENSIONS

>                     [S] 202 Extensions supported:

>                     [S] OVER

>                     [S] PAT

>                     [S] LISTGROUP

>                     [S] .

Note that the single space doesn't appear to be present in the example.

>             The client NNTP should configure itself for the basic NNTP
>             functionality defined in this document, or issue commands that
>             might change the state of the server, or issue the QUIT
>             command (see section 10.1) if a particular extension is
>             required for the client to properly operate.

The note about "commands that might change the state of the server" seems
a bit poorly specified and vague.  At the least, I think it would be worth
saying that the client, upon taking any action that may make extensions
available, should confirm their presence by sending LIST EXTENSIONS again.

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