[NNTP] Re: MODE READER

[Andrew - Supernews]

>>>>> "Mark" == Mark Crispin <mrc at CAC.Washington.EDU> writes:

 >> - the client doesn't have to do LIST EXTENSIONS before STARTTLS if
 >> it wants to initiate TLS on its own initiative rather than at the
 >> server's request.

 Mark> No!!!  The client must know that the server supports a
 Mark> non-mandatory command before issuing it.  That is the entire
 Mark> point of a capability announcement mechanism.

 Mark> Please expunge this notion of "just try the command and see if
 Mark> it works." It is *extremely* harmful to a protocol to have a
 Mark> mixed mode of capability announcement and "just try."

I can see we're not going to agree on this.

 >> - if the client doesn't want to initiate TLS but the server wants
 >> to force it to do so, your suggested exchange doesn't make any
 >> sense.

 Mark> In all protocols, a server forces TLS by requiring
 Mark> authentication and not advertising any authentication
 Mark> mechanisms until TLS is in force.

It's very common with NNTP to not require authentication at all.
That's why we have a response code specifically saying "you can't do
that without starting TLS first" in addition to the one that says "you
can't do that without authenticating".

 Mark> In all protocols with the exception of NNTP, TLS is forced
 Mark> unless the server has an authentication mechanism that does not
 Mark> exchange passwords in the clear.  Even then, it is advisable to
 Mark> use TLS since it is absolutely trivial to hijack sessions.

When authentication isn't necessary, it's extremely rare (by proportion
of traffic) for TLS to have any value at all for an NNTP session.

 >> (It's important that servers not encourage clients to initiate TLS
 >> unnecessarily, since that leads to overhead that can only be
 >> avoided by disabling TLS altogether.)

 Mark> TLS is here.  TLS is mandatory.  We need to live with it.

So you'll be happy to foot the bill?

Let me ask you this question. What would you say is a typical range
for peak (or 95-percentile) traffic in megabits/sec (client -> server
and server -> client combined) for a large POP3 or IMAP installation?

 Mark> Yes, indeed, this battle has been fought many times before;
 Mark> your argument has been advanced many times before; and it's
 Mark> been thoroughly crushed many times before.  Hard feelings have
 Mark> very commonly resulted.

I suggest you read what I actually said.

 >> There are two fundamental objections to that. First is that you're
 >> assigning semantics to fields which in the deployed specification
 >> are explicitly designated as containing arbitrary non-semantic
 >> text.

 Mark> There is ample precedent in other protocols: MIME and IMAP have
 Mark> both done it, and quite successfully.

MIME did it? where?

 Mark> Removal of extraneous RTTs is always a good thing.

Only where it doesn't break stuff.

 >> The second is that you can't just handwave MODE READER out of
 >> existence; if you make it impossible to conform to the spec, then
 >> people will just not bother conforming to the spec and will stick
 >> with the established practice.

 Mark> Is it really just one server, inn, that has this issue?

I believe so. However, you have to understand the _reason_ why that is
so - other servers, such as Diablo for example (or indeed our
proprietary one) simply split the two functions (transit and reader)
apart and require that they be run on separate servers or separate
ports, thus adding an order of magnitude to the difficulty of
installing and setting up. That's tolerable at large sites, but INN
is still usually the favoured (free) solution for small to medium
sites.

Furthermore, the problem is architectural in nature and not a mere
implementation issue - good design usually requires separating the
transit and reader functions since they have almost no overlap, and
forcing use of an alternate port number for transit is not an
acceptable solution.  That means that any INN-like implementation
will run into exactly the same issue.

 Mark> It certainly is not "impossible to conform to the spec";

It would be impossible to conform to the spec (sans MODE READER)
without taking away features that people are, in fact, using quite
widely. 

I agree that MODE READER is an extremely annoying wart, but it exists
for a specific reason, and you can't legislate that reason out of
existence. Which is why I proposed an approach that actually _is_
implementable.

 Mark> Science does not emerge from voting, party politics, or public
 Mark> debate.

I think you should read your own signature more often.

-- 
Andrew, Supernews
http://www.supernews.com