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

[Ken Murchison]

Clive D.W. Feather wrote:
> Ken Murchison said:
> 

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

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 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):
> 
> 
> I don't see the point of this change; it actually makes things *less* clear
> 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
> transaction into easily digested pieces for syntax purposes.

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.

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

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.

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