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

[Ken Murchison]

Russ Allbery wrote:

> Clive D W Feather <clive at demon.net> writes:
>>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.

After thinking about this some more, should we even bother discussing 
MODE STREAM as a formal part of the STREAMING extension?  Since we all 
agree that MODE STREAM has been historically used as a capability 
discovery mechanism, which is now deprecated by LIST EXTENSIONS, what's 
the point of formalizing it?  I can see possibly documenting it as an 
obsolete command somewhere in the document, but including it as part of 
the STREAMING extension seems wrong.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp