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

[Clive D.W. Feather]

Ken Murchison said:
>> 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.

That's a point. In response to it and your other comments, I've expanded
the introduction to section 9 (and renumbered it as 9.1) to explain the
naming convention more explicitly.

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

But you haven't encoded that into the syntax; you've done it in comments
and ambiguous syntax.

    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

Now that I've expanded the description, I think I've captured all the
benefits of your approach without adding confusion.

> True, but it requires the reader to piece things together, rather than
> there being a direct relationship with "POST" and "encoded-article".

Well, now the naming convention is explicit, I think that is reasonable
enough.

> I'm just more familiar and comfortable with an explicit and unambiguous
> ABNF like that in RFC3501.

Um, that syntax has four unreferenced rules <greeting>, <command>,
<response>, and <atom-specials>; it would appear that the first three are
being used in the same way as I do it, though it isn't clear from the
syntax section alone. [That syntax is also erroneous, in that it has 6
undefined non-terminals and does not include RFC2234 Appendix A by
reference.] I guess I don't get your point.

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

Shrug. Why do these differ from <command-line> and <response>?

> Fair enough, but like the "complex" commands, nowhere is
> article-response tied (and ONLY tied) to "220".

It is now using the new naming convention.

> Conversely, its
> ambiguous enough where it allows article-response to be tied to
> response-111-content.

Well, if an ARTICLE could produce a 111 response, then it would be.
However, I've again used rule naming to make this clearer.

The new 9.1:

====
9.1  Introduction

   Each of the following sections describes the syntax of a major
   element of NNTP.  This syntax extends and refines the descriptions
   elsewhere in this specification, and should be given precedence when
   resolving apparent conflicts.  Note that ABNF [RFC2234] strings are
   case-insensitive.  Non-terminals used in several places are defined
   in a separate section at the end.

   The non-terminals <command-line>, <command-datastream>, <command-
   continuation>, and <response> between them specify the text that
   flows between client and server.  A consistent naming scheme is used
   in this document for the non-terminals relating to each command, and
   SHOULD be used by the specification of registered extensions.

   For each command, the sequence is:
   o  The client sends an instance of <command-line>; the syntax for the
      EXAMPLE command is <example-command>.
   o  If the client is one that immediately streams data, it sends an
      instance of <command-datastream>; the syntax for the EXAMPLE
      command is <example-datastream>.
   o  The server sends an instance of <response>.
      *  The initial response line is independent of the command that
         generated it; if the 000 response has arguments, the syntax of
         the initial line is <response-000-content>.
      *  If the response is multi-line, the initial line is followed by
         a <multi-line-data-block>.  The syntax for the contents of this
         block after "byte-stuffing" has been removed is (for the 000
         response to the EXAMPLE command) <example-000-ml-content> and
         is an instance of <multi-line-response-content>.
   o  While the latest response is one that indicates more data is
      required (in general, a 3xx response):
      *  the client sends an instance of <command-continuation>; the
         syntax for the EXAMPLE continuation following a 333 response is
         <example-333-continuation>.
      *  the server sends another instance of <response> as above.

   (There are no commands in this specification that immediately stream
   data, but this non-terminal is defined for the convenience of
   extensions.)
====

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