NNTP syntax (Was: [NNTP] Draft 26 pre-1)

[Ken Murchison]

Clive D.W. Feather wrote:

> So that we're all working off the same text, I have put a snapshot of the
> NNTP document up at the usual place:
> 
> <http://www.davros.org/nntp-texts/draft26.pre-1.txt>
> <http://www.davros.org/nntp-texts/draft26.pre-1.html>

I realize that its late in the game, but I've been staring at the ABNF 
(again) and a couple things still bother me.

First, the syntax doesn't specify that IHAVE and POST take an 
encoded-article as an argument, and by extension, forces a similar 
problem on AUTHINFO SASL and TAKETHIS.  I realize that this is probably 
the case because the first three of these commands are multi-stage 
commands, but I've looked at the ABNF for IMAP and POP3 (unfortunately 
SMTP doesn't have a *complete* ABNF) and both of them show the complete 
syntax for their multi-stage commands (AUTHENTICATE and APPEND for IMAP 
and AUTH for POP3).  In the case of IMAP, it has a paragraph which 
describes the multi-stage behavior.  So, I'd like to propose that a 
paragraph such as the following be inserted between p.2 and p.3 of 
section 3.1:

"There are two cases in which a line from the client does not represent
a complete command.  In one case, a command may take a
multi-line-data-block argument (note that there are no such commands
in this specification, but one may be defined by an extension); in the
other case, the command argument(s) require server feedback (see the
IHAVE and POST commands).  In the latter case, the server sends a
command continuation request (a 3xx response) if it is ready for the
argument and, if appropriate, the remainder of the command."


In conjunction with this, I'd propose that the ABNF for commands be 
changed to something like the following (note that this is not complete 
with all commands and terminals):


command = X-command EOL *(*B-CHAR CRLF)
X-command = keyword *(WS token)

command =/ simple-command EOL /
	   complex-command

simple-command = article-command /
		 ...

article-command = "ARTICLE" [WS article-ref]


complex-command = ihave-command /
		  post-command

ihave-command = "IHAVE" WS message-id EOL [encoded-article]
	; client waits for response from the server following EOL
	; client MUST send encoded-article if and only if
	; it receives a "335" response from the server

post-command = "POST" EOL [encoded-article]
	; client waits for response from the server following EOL
	; client MUST send encoded-article if and only if
	; it receives a "340" response from the server

; AUTHINFO
simple-command =/ authinfo-user-command /
		  authinfo-pass-command

authinfo-user-command = "AUTHINFO" WS "USER" WS username
authinfo-pass-command = "AUTHINFO" WS "PASS" WS password

complex-command =/ authinfo-sasl-command
authinfo-sasl-command = "AUTHINFO" WS "SASL" WS mechanism
	[WS initial-response] EOL *authinfo-sasl-continuation

authinfo-sasl-continuation = ("*" / base64-opt) CRLF
	; client waits for response from the server following each CRLF
	; client MUST send authinfo-sasl-continuation
	; following each "383" response from the server


; STREAMING
simple-command =/ check-command
check-command = "CHECK" WS message-id

complex-command =/ takethis-command
takethis-command = "TAKETHIS" WS message-id EOL encoded-article
	; client sends encoded-article immediately following EOL




Second, the syntax for responses is incorrect because it allows simple 
responses such as 111 and 223 to be followed by a multi-line-data-block 
and doesn't show which response codes go with each multi-line-response. 
  I realize that this occurs as a result of trying not to repeat junk 
like trailing-commment all over the place, but we may not have any 
choice.  Additionally, shouldn't we indicate that the ARTICLE and BODY 
responses (and perhaps others) need to be dot-stuffed and that the 
VERSION capability MUST be first in the capabilities response?  So, I'd 
like to propose that the ABNF for responses be changed to something like 
the following:

response = X-response-content EOIR *(*B-CHAR CRLF)
X-response-content = 3DIGIT *(SP response-argument)
response-argument = 1*A-CHAR
EOIR = [SP trailing-comment] CRLF  ; end of initial response
trailing-comment = *U-CHAR

response =/ simple-response /
	    multi-line-response

simple-response = simple-response-content EOIR

simple-response-content = response-111-content /
			  response-211-content /
			  response-223-content /
			  response-401-content

response-111-content = "111" SP date4y time
response-211-content = "211" 3(SP article-number) SP newsgroup-name
response-223-content = "223" SP article-number SP message-id
response-401-content = "401" SP capability-label


multi-line-response = article-response /
		      ... /
		      capabilities-response /
		      ... /
		      listgroup-response /
		      ...

article-response = "220" SP article-number SP message-id EOIR
		   encoded-article

capabilities-response = "101" EOIR
		        "VERSION" 1*(WS version-number) CRLF
			*(capability-line CRLF) termination

listgroup-response = response-211-content EOIR
		     *(article-number CRLF) termination


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