ietf-nntp DRAFT summary of IETF 49

[Stan O. Barber]

Jim Calvin wrote:
> Russ suggested considering the use of an alternate port. Once upon a
> time, someone started to do this. Port 443 is reserved for NNSP,
> which when I last looked at it, appeared to be a stripped down
> version of the NNTP protocol. Basically it removed all reader class
> commands.
> 
> Certainly worth considering a such a split.

We won't do this as part of this working group, per se. It could be some later
work, but it is a distraction right now.

However, this whole discussion has helped me consider how to address these
concerns within the current framework. I think it is important for the spec to
accomodate "split" implementations in some fashion. The main issues as I see are
handing mode changes (can you switch to being a reader and switch back?) and
what happens to streaming when a mode change happens. I believe that there is
general consensus that a mode change will interrupt the current stream and a new
one will need to be started. What I don't think we have clear consensus on is
requring the ability to switch back and forth between modes and exactly which
commands are active in which modes. We could certainly use INN as a model here,
but I am reluctant to tie the spec that closely to an existing implementation.

On streaming specifically, I want to be sure that if we define this behavior in
the spec that we consider what "interrupting" a stream means. For example, if a
client issues a mode changing command, does the stream of responses from the
server stop immediately, or does it 
continue until the end of the stream (the last response just before it would
have processed the mode change) and just start a new one? This is a
"transparency" issue. I think most clients expect the latter behavior. What are
others' experiences?