[ietf-nntp] draft-ietf-nntpext-streaming-01.txt

[Clive D.W. Feather]

Russ Allbery said:
>> Section 3.2: I don't understand the reason for this command at all, let
>> alone why it can't be pipelined. Why can't a client just start issuing
>> CHECK and TAKETHIS commands immediately after the initial connection?
>> If there is some technical reason for either requiring the command at
>> all, or for making it non-pipelined, you need to give it.
> 
> I go back and forth on this, but I think we should take the stance that
> there is no technical reason for this command and that the only reason why
> it's included is that all current streaming implementations send it and
> the server needs to do something sensible with it.  In other words,
> include it, state that clients that intend to use streaming commands MUST
> send either it *or* LIST EXTENSIONS,

I don't ever like the idea of using LIST EXTENSIONS to set state in the
server. However, see below.

> and state that servers that support
> streaming commands for those clients MUST NOT require MODE STREAM be sent.
[...]
> I don't know of an implementation that would inherently require that this
> command be sent (unlike with MODE READER).  In practice, it was used
> instead of LIST EXTENSIONS because sending TAKETHIS without a positive
> indication that the remote side supports it is a bad idea.  Now, clients

If I understand you correctly, what you're actually suggesting is:
* MODE STREAM has no effect and does not affect the server state.
* A server supporting this extension MUST support the MODE STREAM command,
  while a server that does not SHOULD NOT support it (for the reason given
  below).
* A client really really should not attempt a TAKETHIS unless it is *SURE*
  that the server understands it, because if it doesn't then the server
  is going to issue 500s (hopefully) for every line of the article!
* There are three ways to know if the server supports TAKETHIS:
  - LIST EXTENSIONS reports this extension (preferred)
  - MODE STREAM returns 2xx (legacy)
  - external configuration or memory of previous session (dangerous).
* Therefore clients SHOULD NOT use TAKETHIS unless a LIST EXTENSIONS or
  MODE STREAM in the same session has reported accordingly.

Do you agree with this analysis? If so, can we word things as such?

>> Section 5.1: what's the meaning of the 439 response? Does it indicate a
>> technical failure (so the client should retry later) or is it a "I didn't
>> want that"? The point of response codes is that they tell the client what
>> further action to take. I would suggest:
>>   239 - I got it successfully, thanks
>>   431 - I can't handle it right now, try again later
>>   438 - I got it and I've deliberately thrown it away
>>   439 - Temporary failure, please send it again ASAP.
> 439 is a rejection.  The article should never be sent again.

Okay.

> TAKETHIS has no deferral return status.  We could add one as part of this
> standardization process; it's not a bad idea.

Thanks.

> You cannot reuse CHECK status codes for TAKETHIS status codes given the
> way that client software is written.
[...]

Okay, that makes a lot of sense. Can I suggest that the text says that
these two commands have deliberately different responses for just this
reason?

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