[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