[NNTP] Re: [ietf-nntp] draft-ietf-nntpext-streaming-01.txt

[Russ Allbery]

Ken Murchison <ken at oceana.com> writes:

> I'm bored so I'm spending time updating this doc to use similar
> formatting as AUTHINFO and STARTTLS.  I decided to take a look back at
> the list traffic and see what the outstanding issues are.

Moving this over to the new list.  Apologies for all the quoting, but I
wanted to make sure that Ken's full message was included.

> Russ Allbery wrote:

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

> Agreed on all of the above.

> Question:

> Should any of the STREAMING commands be allowed after MODE READER?  I'm
> assuming that INN (and possibly other servers) would have a problem
> switching from reader-only mode back to streaming mode.

I think we can handle this via LIST EXTENSIONS, yes?  I expect that most
implementations that do something with MODE READER will not advertise the
STREAMING extension after MODE READER, but there's no particular reason
not to allow them to if they want to.

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

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

> Is this something that we want to add to the document?

I don't see any obvious reason not to add it.

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