[NNTP] Extension docs snapshots

[Ken Murchison]

Clive D.W. Feather wrote:
> Ken Murchison said:
> 
>>Per Clive's request, here are the current extensions docs with 
>>(hopefully) all issues discussed on the list resolved.  Once the LIST 
>>EXTENSIONS/CAPABILITY issue is settled, I will update the docs 
>>appropriately.
>>
>>http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-authinfo-06pre1.txt
>>http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-streaming-03pre1.txt
>>http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-tls-nntp-04pre1.txt
> 
> 
> Thanks for these.
> 
> authinfo, section 1, para 1, s/be used/been used/

Done.


> authinfo, section 3.1, last para,
>   s/and CRLF as the/and CRLF, both exclusive, as the/

Is "both exclusive" intended to pair up USER and PASS with username and 
password respectively?  If so, the language seems to be a little obsure. 
  Would simply splitting them into separate sentences be better?  E.g.:

	To solve this ambiguity, such implementations typically treat
	everything between the first white space character following
	"USER" and CRLF as the username.  Likewise, everything between
	the first white space character following "PASS" and CRLF is the
	password.


> streaming, section 2.3.1, why is MODE STREAM "MUST NOT be pipelined"? I
> understand the reasoning with MODE READER, but I don't understand it here
> (of course, the client needs to be careful what it does immediately
> afterwards, but if it pipelined a sequence of CHECKs would it hurt?).

Don't know.  Someone more familiar with streaming (Andrew?) needs to 
chime in here.  I don't recall when this came into the document.  It 
seems to me that any argument that can be made for MODE READER can be 
made for MODE STREAM and vice versa.


> streaming, section 2.3.2, para 1: make it clear that a 501 is allowed if an
> argument is given, and that the server state must not be affected by this
> command. So something like:
>     ... to the MODE STREAM command (or 501 if an argument is given).

Is explicitly mentioning 501 really necessary?  If so, why don't we 
mention it for NEXT?  The formal grammar shows that MODE STREAM doesn't 
take any extra arguments.  I think its implied in all of the texts 
(including the base doc) that the client issues a syntaxtically correct 
command.


>     The MODE STREAM command MUST NOT have any other effect.

Seems reasonable.


> Generic issues:
> * With the agreed change on command name and extension label syntax, the
> extension labels are now case-insensitive. So the hex sequences in the
> formal grammar can be replaced by quoted strings.

OK.  I didn't catch this in -25.


> * I've seen *NO* feedback on 25-pre3, which rewrites the MODE READER issue
> in terms of "transit" and "reader" connections. If the consensus is to
> accept this change, then all these extension documents will need
> corresponding changes:
>   - each command needs labelling as "transit", "reader", or "general";
>   - the bits about "can be used before and after MODE READER" can either
>     be dropped or else become "can be used on transit-only servers" or
>     "can be used on reader-only servers".
> 
> I've just added another bullet point to the "what is needed in an extension
> description":
>   - how the use of MODE READER on a mode-switching server interacts
>     with the extension.
> This is relevant for AUTHINFO and STARTTLS; both say that the commands can
> be used before and after MODE READER, but neither explains what happens if
> MODE READER is issued on a secured connection.
> 
> * There will, of course, be issues to resolve when CAPABILITY is added
> (which will be the next draft I issue).


I'm waiting for all of the dust to settle on the above before I make any 
changes.  Hopefully we can agree on the text currently in the extension 
docs and the above changes can be made without any further discussion.


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