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

[Russ Allbery]

Clive D W Feather <clive at demon.net> writes:

> Okay, a critique of this one.

> Section 2: why is there a suggestion that LIST EXTENSIONS might stop
> advertising the extension once MODE STREAM has been used? This feels
> completely wrong to me.

Given the way that the extension is worded (namely, saying that the server
supports the streaming commands), I think it's pretty clear that STREAMING
MUST continue to be advertised after MODE STREAM.  Since the server most
definitely still supports the streaming commands.

> Section 3.1: a 500 response doesn't conform to [NNTP]. Since your
> description only applies to implementations providing the extension, I
> would just drop the whole reference to 500 and 501 (but see below).

Dropping 500 at least, yeah.

> Section 3.2: given the "MUST NOT be pipelined" in 3.1, there's no need
> to explicitly mention pipelining here.

Agreed.

> 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, and state that servers that support
streaming commands for those clients MUST NOT require MODE STREAM be sent.

I'd at least like to try that and see if it goes over okay with
implementors.

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
can just use LIST EXTENSIONS for that purpose.

> Section 4.1: delete the "MAY send additional text" sentence, since this
> is a requirement of [NNTP]. Ditto section 5.1.

Agreed.

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

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

You cannot reuse CHECK status codes for TAKETHIS status codes given the
way that client software is written.  The streaming extensions were
designed so that client software doesn't have to keep track of the order
of its commands and server responses; there's enough information contained
in the response to completely disambiguate the response without needing to
know the order.  That means that CHECK responses and TAKETHIS responses
MUST be distinct from each other and contain the message ID.

If we want to add a deferral, we need to use 432 or some similar code.  I
don't think we need two types of deferrals; all streaming deferrals should
be delayed at least a little while.

> Section 6: delete the reference to the core rules of [ABNF], and replace
> by a reference to section 13 of [NNTP] (rather than having the comment
> at the end). "STREAM" is missing the closing quote.

> Section 7: I suggest a formal section like that in [NNTP] appendix D.

> Section 10: note that we're up to draft 21.

These all sound good.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>