Subject: [NNTP] Draft 26 pre-1

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 27 Apr 2005 10:40:59 +0100

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>

This *will* change (in particular, the I18N stuff) and it has some known
formatting problems. However, any comments will be gratefully received.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: Ken Murchison <[email-masked]>
Date: Wed, 27 Apr 2005 09:38:24 -0400

> <http://www.davros.org/nntp-texts/draft26.pre-1.html>

If its not too much trouble, could you list which sections have changed? 
  I'll eventually re-read the entire doc, but for now, I'd just like to 
browse the changes.

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 28 Apr 2005 07:19:15 +0100

> If its not too much trouble, could you list which sections have changed? 

* New IPR boilerplate.
* Change "current" to "currently" in many places.
* One "must" became "MUST" in section 2.
* Scattered changes in 3.1 to 3.4.
* Changes in 6 introduction, 6.1.1, 6.1.2, 6.3.1, 6.3.2, 7.2, 7.6.6,
  8.3.2, 8.5.2.
* Various changes to the formal syntax.
* New section "Internationalisation Considerations" and consequential
  renumbering.
* 12.6 examples.
* More names in acknowledgements.
* Appendixes B and C.

---

From: Ken Murchison <[email-masked]>
Date: Thu, 28 Apr 2005 16:02:25 -0400

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 29 Apr 2005 12:10:45 +0100

> (again) and a couple things still bother me.

Thanks for this, even if I don't agree with what follows.

> problem on AUTHINFO SASL and TAKETHIS.

Um, section 9.2:

     command-continuation = ihave-continuation /
           post-continuation
     
     ihave-continuation = encoded-article
     post-continuation = encoded-article
   
     encoded-article = multi-line-data-block
       ; after undoing the "byte-stuffing", this MUST match <article>

> So, I'd like to propose that a 

I've added a shorter paragraph just before "Each response MUST start ...":

    In some cases a command involves more data than just a single line.
    The further data may be sent either immediately after the command
    line (there are no instances of this in this specification, but
    there are in extensions such as [NNTP-STREAM]) or following a
    request from the server (indicated by a 3xx response).

> with all commands and terminals):

I don't see the point of this change; it actually makes things *less* clear
in my view. The bulleted list at the start of section 9 splits the
transaction into easily digested pieces for syntax purposes.

> and doesn't show which response codes go with each multi-line-response. 

This is the sort of semantic issue which I'm not sure is well-addressed
in the syntax, but I will think carefully about it.

> Additionally, shouldn't we indicate that the ARTICLE and BODY 
> responses (and perhaps others) need to be dot-stuffed

   9.3.3  Multi-line response contents
  
   This syntax defines the content of the various multi-line responses;
   more precisely, it defines the part of the response in the multi-line
   data block after any "byte-stuffing" has been undone.

> and that the 
> VERSION capability MUST be first in the capabilities response?

Good point. Fixed.

---

From: Ken Murchison <[email-masked]>
Date: Fri, 29 Apr 2005 08:53:59 -0400

>        ; after undoing the "byte-stuffing", this MUST match <article>

I'm aware of this section, but nowhere are ihave-command and 
ihave-continuation explicitly tied together in the syntax.  In fact, its 
ambiguous enough where it allows me to put ihave-command and 
post-continuation together.  I realize that the "right thing" is 
implied, but its not definitive in the syntax.  IMO, a client should be 
able to read just the ABNF and construct valid commands (it may not know 
what to do with them, but they will be syntactically correct).

> in my view.

How so?  It shows the direct relationship between "POST" and 
"encoded-article".

> The bulleted list at the start of section 9 splits the

True, but it requires the reader to piece things together, rather than 
there being a direct relationship with "POST" and "encoded-article".  I 
haven't seen any other ABNF syntax which requires readers to piece 
things together by reading some pseudo-code and matching up syntax items 
by the prefix of the names (post-command, post-continuation).  I guess 
I'm just more familiar and comfortable with an explicit and unambiguous 
ABNF like that in RFC3501.

The draft states:

"the non-terminals <command-line>, <command-datastream>, 
<command-continuation>, <response>, and <multi-line-response-content> 
describe basic concepts of the protocol and are not referred to by any 
other rule;"

I guess I have a problem with the fact that <command-datastream>, 
<command-continuation>, and <multi-line-response-content> aren't 
referred to.  IMO, the syntax needs to be explicit without any "holes", 
specifically with the "complex" commands, and multi-line-responses.

>    data block after any "byte-stuffing" has been undone.

Fair enough, but like the "complex" commands, nowhere is 
article-response tied (and ONLY tied) to "220".  Conversely, its 
ambiguous enough where it allows article-response to be tied to 
response-111-content.