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

[Ken Murchison]

Russ Allbery wrote:

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

Oops!  Sorry about that.  I forgot that this thread was old enough to 
have started on the old list.


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

Good point.  So we should add text that states that the server MAY 
choose to not advertise STREAMING after MODE READER.


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

So, is 432 the definitive code?


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