ietf-nntp DRAFT summary of IETF 49

[Russ Allbery]

Stan O Barber <sob at verio.net> writes:

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

Changing to reader mode is pretty easy to do.  Being able to change both
directions requires file descriptor passing and is considerably more
complex.  I'm not aware of any split implementation that does this.  (It's
also never used in practice, so there doesn't seem to be any real reason
to write the code to support it.)

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

I'll offer language for MODE READER and we'll see where we go from there.
I personally think that running both services on the same port is a
mistake and personally for the servers that I run am moving towards
running readers on 119 and transit on 433.  I think that's the best
long-term solution.

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

The latter is what I would expect.  The way I would phrase this is:

    MODE READER cannot be streamed; after sending MODE READER, the
    client SHOULD wait for the server's response to that command before
    sending any additional commands.

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