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

Russ Allbery rra at stanford.edu
Mon Mar 15 11:05:04 PST 2004


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

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

MODE STREAM doesn't set state on the server.  That's my point.  MODE
STREAM is nothing more or less than a single-feature version of LIST
EXTENSIONS.

> If I understand you correctly, what you're actually suggesting is:
> * MODE STREAM has no effect and does not affect the server state.

Or at least doesn't need to.  I don't know if some server has actually
added a bit to prevent people from sending streaming commands without
sending MODE STREAM first out of some ill-advised sense of cleanliness,
but that's easy enough to fix.

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

MUST NOT, actually, since it's used as an extension mechanism and sending
TAKETHIS when it's not supported is a big problem.

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

Right.

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

Right.  That sounds good to me.

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

Good idea.  Yes, I definitely recommend that.

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



More information about the ietf-nntp mailing list