[NNTP] Snapshot 6

[Clive D.W. Feather]

Ken Murchison said:
> 3.2.2:

Addressed elsewhere.

> 3.3.5:
> - The meaning of IHAVE should probably just say "IHAVE command 
> available" rather than "Transit commands available".

Oops. Missed that one.

> - The meaning of SASL should probably say "Supported SASL mechanisms" 
> rather than "SASL capabilities".

Okay.

> 3.4.2:
> 
> Objection to "MUST advertise the READER capability with the -MODE-READER 
> modifier" noted in another thread.

Will address there.

> 5.2.3:
> 
> Second example advertises LIST HEADERS but not HDR, as I feared might 
> happen in real implementations.

Bad editing on my part; sorry. I've now checked all examples using
CAPABILITIES, and LIST always includes entries implied by other
capabilities.

> I'm going to renew my concern over 
> having two capabilities for a single command (HDR & LIST HEADERS, READER 
> & LIST ACTIVE, etc), but I'll defer to the consensus.

Technically there is a difference. A server could provide LIST OVERVIEW.FMT
without OVER, or LIST NEWSGROUPS without the reader commands. Unless we
categorically want to forbid it, which has problems of its own, I think we
just live with that.

More generally, I've been converted to the "show all LIST variants in the
capabilities line" view.

> 6.3.1.1:
> 
> Should the indicating capability be "READER POST" instead of just "POST"?

You mean "READER"? I was thinking in terms of "POST is part of the READER
group of commands", but I suppose "READER with argument POST" is actually
the best way to put it.

> 9:
> 
> Not really a problem with the base doc, but with the STREAMING doc. 
> Section 9 states that <command-continuation> follows a server 
> <response>.  We use <command-continuation> with the TAKETHIS command, 
> but this is clearly incorrect because we don't get a server response 
> before we send the article.

Ah, I didn't think of this case. My bad.

I've changed the base document to read:

In 9:
   * the client sends an instance of <command-line>;
+  * if the client is one that immediately streams data [1], it sends
+    an instance of <command-datastream>;
   * the server sends an instance of <response>;
[...]
+  [1] There are no commands in this specification that immediately
+  stream data, but this non-terminal is defined for the convenience of
+  extensions.

In 9.2:

+  command-datastream = UNDEFINED
+    ; not used, provided as a hook for extensions

In 9.8:

   command
      for each new command other than a variant of the LIST command -
      the syntax of each command MUST be compatible with the definition
      of <X-command>;
+  command-datastream
+     for each new command that immediately streams data;
   command-continuation 
      for each new command that sends further material after the initial
[...]
+  the non-terminal <UNDEFINED> is deliberately not defined.

> I'm guessing that the syntax for TAKETHIS 
> should probably be something along the lines of:
> 
> takethis-command = "TAKETHIS" WS message-id EOL encoded-article

No, it would become:

    command =/ takethis-command
    command-datastream =/ takethis-datastream

    takethis-command = "TAKETHIS" WS message-id
    takethis-datastreadm = encoded-article

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