Subject: [NNTP] draft-ietf-nntpext-streaming-02

From: ken at oceana.com (Ken Murchison)
Date: Wed Oct 13 14:09:09 2004

I just submitted the following updated draft which I believe addresses 
the issues discussed on the list since draft -01:

http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-streaming-02.txt

Note that this draft uses the NNTPv2 extension label discussed in Russ' 
LIST EXTENSIONS thread (consider this a place holder if the label ends 
up being something different [NNTP]).

Also note that the CHECK and TAKETHIS descriptions use text taken 
directly from IHAVE in [NNTP], so I don't expect any issues with them

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

---

From: andrew at supernews.net (Andrew - Supernews)
Date: Wed Oct 13 15:38:10 2004

>>>>> "Ken" == Ken Murchison <[email-masked]> writes:

 Ken> I just submitted the following updated draft which I believe
 Ken> addresses the issues discussed on the list since draft -01:

2.5. TAKETHIS Command

2.5.1. Usage

     Syntax
        TAKETHIS message-id

     Responses
        239 message-id   Article transferred OK
        432 message-id   Transfer failed; try again later
        439 message-id   Transfer rejected; do not retry

Any implementation that actually returns 432 will break several of the
existing streaming-mode feeders in use. As a rule, existing software
expects specific response codes only, and will behave badly (e.g. by
giving up on the connection) if an unexpected code is received.

Existing implementations exist that do return 431 in response to
TAKETHIS (bogusly; see below) and existing feeders do cope with that
to some extent (despite the fact that 431 is also used for CHECK).

However, the idea of returning a deferral in response to TAKETHIS (or
indeed as the final response after IHAVE) is in any event logically
somewhat flawed. The client in this case will always have sent the
entire article body, and it is not reasonable to expect a client to do
that repeatedly. Once the body is transferred once, the server has all
the information needed to decide whether to accept or reject the
article; transient errors at this point, such as "disk full", are
better handled by pausing or throttling the server (without sending
either 239 or 439 to the client). Some implementations do actually
return 431 in that case, but practical experience is that the
resulting behaviour is never good (some senders will discard the
articles, others will retry them indefinitely, potentially wasting
large bandwidth volumes; throttling the server works much better).

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

---

From: rra at stanford.edu (Russ Allbery)
Date: Wed Oct 13 15:51:48 2004

"Andrew - Supernews" <[email-masked]> writes:

> article; transient errors at this point, such as "disk full", are better
> handled by pausing or throttling the server (without sending either 239
> or 439 to the client). Some implementations do actually return 431 in
> that case, but practical experience is that the resulting behaviour is
> never good (some senders will discard the articles, others will retry
> them indefinitely, potentially wasting large bandwidth volumes;
> throttling the server works much better).

So from a protocol standpoint, you believe the situations under which a
server might return a deferral to TAKETHIS or IHAVE are better handled by
just closing the connection without a response instead?

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: andrew at supernews.net (Andrew - Supernews)
Date: Wed Oct 13 17:14:16 2004

>>>>> "Russ" == Russ Allbery <[email-masked]> writes:

 >> However, the idea of returning a deferral in response to TAKETHIS
 >> (or indeed as the final response after IHAVE) is in any event
 >> logically somewhat flawed. The client in this case will always
 >> have sent the entire article body, and it is not reasonable to
 >> expect a client to do that repeatedly. Once the body is
 >> transferred once, the server has all the information needed to
 >> decide whether to accept or reject the article; transient errors
 >> at this point, such as "disk full", are better handled by pausing
 >> or throttling the server (without sending either 239 or 439 to the
 >> client). Some implementations do actually return 431 in that case,
 >> but practical experience is that the resulting behaviour is never
 >> good (some senders will discard the articles, others will retry

 Russ> So from a protocol standpoint, you believe the situations under
 Russ> which a server might return a deferral to TAKETHIS or IHAVE are
 Russ> better handled by just closing the connection without a
 Russ> response instead?

The distinguishing factor is whether the server has any reason to
expect that an immediate following TAKETHIS for a different article,
or a later following TAKETHIS for the same article, has any chance of
success. If the server is getting errors (such as disk full) that
aren't article-specific, then it should really fail in a way that also
isn't article-specific (and closing the connection, possibly rejecting
further connections until the problem is resolved, seems the better
option).

Such an unsolicited close of the connection should probably be done
with a 400 response rather than silently (see the base draft).
(Existing streaming clients do seem to understand this, as existing
server implementations do this when shutting down connections when
throttled)

Maybe someone can come up with a specific circumstance where returning
a deferral would make sense, but so far I've been unable to think of
one (and none of my own implementations have ever done it). If it
stays in the draft, then (a) it specifically needs to be the 431 code
rather than a new one, and (b) it should be made clear that it's only
appropriate if the problem is a _transient_ problem affecting _only that
specific article_, and that more general failures should be handled by
a connection close.

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

---

From: rra at stanford.edu (Russ Allbery)
Date: Wed Oct 13 17:17:24 2004

"Andrew - Supernews" <[email-masked]> writes:

> Maybe someone can come up with a specific circumstance where returning a
> deferral would make sense, but so far I've been unable to think of one
> (and none of my own implementations have ever done it). If it stays in
> the draft, then (a) it specifically needs to be the 431 code rather than
> a new one, and (b) it should be made clear that it's only appropriate if
> the problem is a _transient_ problem affecting _only that specific
> article_, and that more general failures should be handled by a
> connection close.

I think the argument in favor of it was mostly consistency, so I would
lean towards mentioning use of the 400 code and an immediate connection
close in response to TAKETHIS when the article can't be processed due to
some error condition.  (Yes, in theory, anyone should be able to realize
they can do that given that 400 is documented in the base draft, but I bet
people won't think of it unless we mention it explicitly.)

---

From: ken at oceana.com (Ken Murchison)
Date: Wed Oct 13 18:00:30 2004

> people won't think of it unless we mention it explicitly.)

So I should remove 432 and go back to what we had?

---

From: rra at stanford.edu (Russ Allbery)
Date: Wed Oct 13 18:05:43 2004

>> close in response to TAKETHIS when the article can't be processed due
>> to some error condition.  (Yes, in theory, anyone should be able to
>> realize they can do that given that 400 is documented in the base
>> draft, but I bet people won't think of it unless we mention it
>> explicitly.)

> So I should remove 432 and go back to what we had?

I think so (although if someone else has a different opinion, they should
weigh in here).  I'd add an explicit mention of a 400 response, saying
that it should be treated the same as no response, and I think we still
have to describe a deferral since that's the proper action to take if no
response or a 400 response is received.

---

From: ken at oceana.com (Ken Murchison)
Date: Wed Oct 13 20:26:00 2004

> response or a 400 response is received.

I'm not sure that I completely understand the argument, so some 
suggested text might be helpful.

---

From: rra at stanford.edu (Russ Allbery)
Date: Wed Oct 13 21:47:59 2004

>> I think so (although if someone else has a different opinion, they
>> should weigh in here).  I'd add an explicit mention of a 400 response,
>> saying that it should be treated the same as no response, and I think
>> we still have to describe a deferral since that's the proper action to
>> take if no response or a 400 response is received.

> suggested text might be helpful.

Right now, the document says:

     The client SHOULD NOT assume that the article has been successfully
     transferred unless it receives an affirmative response from the
     server.  A lack of response (such as a dropped network connection
     or a network timeout) SHOULD be treated the same as a 432 response.

I think it should say:

     The client SHOULD NOT assume that the article has been successfully
     transferred unless it receives an affirmative response from the
     server.  A lack of response (such as a dropped network connection or
     a network timeout) or a 400 response SHOULD cause the transfer to be
     tried again later if possible.

or something along those lines, including the wording from the 432
response in there under the assumption that we're taking out that response
code again.

---

From: ken at oceana.com (Ken Murchison)
Date: Thu Oct 14 05:29:15 2004

> response in there under the assumption that we're taking out that response

The existing paragraph was taken verbatim (other then the 432) from the 
base doc.  Does this change also apply to IHAVE, or does TAKETHIS have 
subtle differences from IHAVE in the wild?

---

From: rra at stanford.edu (Russ Allbery)
Date: Thu Oct 14 19:25:04 2004

> subtle differences from IHAVE in the wild?

I think it wouldn't be a bad idea to note this with IHAVE as well, but
maybe consistency is better.

---

From: clive at demon.net (Clive D.W. Feather)
Date: Fri Oct 15 03:21:51 2004

> subtle differences from IHAVE in the wild?

Hang on.

As I see it, the 432 response to TAKETHIS has exactly the same meaning as
the 436 response to IHAVE. We explicitly list 436 as being possible after
the article body has been sent. So when do existing servers generate this
response? If they do, why shouldn't they generate 432 in the same
situation?

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: clive at demon.net (Clive D.W. Feather)
Date: Fri Oct 15 03:24:40 2004

> just closing the connection without a response instead?

The problem with closing (or issuing a 400, which is far superior) is that
it prevents the client doing anything else, like newsreading.

---

From: clive at demon.net (Clive D.W. Feather)
Date: Fri Oct 15 03:29:44 2004

> further connections until the problem is resolved, seems the better

The problem is that the errors are only posting-specific; they don't stop
clients from doing anything else. Therefore closing the connection is a
draconian solution.

The answer, perhaps, is to define the 431/432/436/441 responses as "don't
try to post anything else for a while", not just "don't try this specific
article again for a while". That is, general rather than specific deferral.

> with a 400 response rather than silently (see the base draft).

Agreed. If it happens at all, that is.

> If it
> rather than a new one,

Back in March Russ explained why CHECK and TAKETHIS need different status
codes. I don't have the explanation to hand, but I see from my sent-mail
archive that they convinced me at the time.

---

From: clive at demon.net (Clive D.W. Feather)
Date: Fri Oct 15 03:35:37 2004

Andrew - Supernews said:
> that repeatedly.

Repeatedly, no. Once more after a problem, yes.

> practical experience is that the

Perhaps we need some recommendations for the client: after receiving a
posting failure (any of 431/432/436/441), it SHOULD NOT use TAKETHIS until
either an IHAVE (for a different article) or CHECK (for this article) has
succeeded. Similarly, TAKETHIS SHOULD NOT be pipelined in a session until
one of IHAVE, CHECK, or TAKETHIS has worked.

---

From: andrew at supernews.net (Andrew - Supernews)
Date: Fri Oct 15 10:55:40 2004

>>>>> "Clive" == Clive D W Feather <[email-masked]> writes:

 >> The existing paragraph was taken verbatim (other then the 432)
 >> from the base doc.  Does this change also apply to IHAVE, or does
 >> TAKETHIS have subtle differences from IHAVE in the wild?

 Clive> Hang on.

 Clive> As I see it, the 432 response to TAKETHIS has exactly the same
 Clive> meaning as the 436 response to IHAVE. We explicitly list 436
 Clive> as being possible after the article body has been sent. So
 Clive> when do existing servers generate this response?

INN never generates 436 after receiving an article body. Older diablo
versions (haven't checked newer ones) generate 436 if they failed to
store the article, which is bogus for the same reasons that I covered
for the TAKETHIS case (it results in the sending end wasting a lot of
effort).

 Clive> If they do, why shouldn't they generate 432 in the same
 Clive> situation?

I assume you mean "431" rather than "432", because generating 432
under any circumstances whatever breaks existing streaming clients.

Every implementation I've checked handles article bodies in IHAVE
and TAKETHIS commands the same, generally using the same code.

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

---

From: andrew at supernews.net (Andrew - Supernews)
Date: Fri Oct 15 10:58:21 2004

>>>>> "Clive" == Clive D W Feather <[email-masked]> writes:

 Clive> The problem with closing (or issuing a 400, which is far
 Clive> superior) is that it prevents the client doing anything else,
 Clive> like newsreading.

In practice, streaming feeds and newsreading are never done on the
same connection. If for some strange reason the client wants to use
reader commands, it can reconnect.

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

---

From: andrew at supernews.net (Andrew - Supernews)
Date: Fri Oct 15 11:16:34 2004

>> expect that an immediate following TAKETHIS for a different
 >> article, or a later following TAKETHIS for the same article, has
 >> any chance of success. If the server is getting errors (such as
 >> disk full) that aren't article-specific, then it should really
 >> fail in a way that also isn't article-specific (and closing the
 >> connection, possibly rejecting further connections until the
 >> problem is resolved, seems the better option).

 Clive> The problem is that the errors are only posting-specific; they
 Clive> don't stop clients from doing anything else. Therefore closing
 Clive> the connection is a draconian solution.

It's the only solution that works in practice. We have plenty of
experience with the "return 431 to every article body" scenario and
the mess it causes.

 Clive> The answer, perhaps, is to define the 431/432/436/441
 Clive> responses as "don't try to post anything else for a while",

Trying to redefine the meaning of responses that are already
recognized by existing code is a really bad idea.

 >> If it stays in the draft, then (a) it specifically needs to be the
 >> 431 code rather than a new one,

 Clive> Back in March Russ explained why CHECK and TAKETHIS need
 Clive> different status codes. I don't have the explanation to hand,
 Clive> but I see from my sent-mail archive that they convinced me at
 Clive> the time.

Superficially they do, and life would actually be a hell of a lot
simpler if they were still unique and no implementation ever returned
431 responses to TAKETHIS. Unfortunately that simplicity went away
years ago thanks to Diablo's misuse of 431. In practice, the only way
that works is to make sure that your servers never actually return
that 431 code. Changing it to 432 may sound sensible from the point of
view of uniqueness, but it founders on the problem of incompatibility
with existing software.

If no-one can actually come up with a realistic case for why a server
should ever need to return a defer in response to a TAKETHIS article
body, then I'd suggest dropping it out of the draft entirely.

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

---

From: ken at oceana.com (Ken Murchison)
Date: Fri Oct 15 12:37:11 2004

> and TAKETHIS commands the same, generally using the same code.

So, are you saying that in practice that servers will never (and should 
not ever) respond with a deferral type code to IHAVE, POST, and TAKETHIS 
after receiving the article?

---

From: andrew at supernews.net (Andrew - Supernews)
Date: Fri Oct 15 15:24:39 2004

>>>>> "Ken" == Ken Murchison <[email-masked]> writes:

 Ken> So, are you saying that in practice that servers will never (and
 Ken> should not ever) respond with a deferral type code to IHAVE,
 Ken> POST, and TAKETHIS after receiving the article?

What has POST got to do with this? There is no "deferral" response to
a POST command.

What I'm saying is that I know of no cases in which it makes sense for
a server to return a deferral after the article body in either IHAVE
or TAKETHIS. I'm also saying that there are existing servers that do
so anyway under certain conditions, and that in such cases the
response causes far more problems than it solves, so the spec
certainly shouldn't encourage it.

Deferral responses to IHAVE after the body aren't likely to cause a
huge problem in practice, though they won't necessarily work as
expected from the server's viewpoint.

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

---

From: clive at demon.net (Clive D.W. Feather)
Date: Mon Oct 18 02:36:27 2004

Andrew - Supernews said:
> same connection.

Why is that justification for hardwiring it into the specification for ever
more?

> If for some strange reason the client wants to use

And you don't think that's antisocial?

---

From: clive at demon.net (Clive D.W. Feather)
Date: Mon Oct 18 03:44:28 2004

Andrew - Supernews said:
> or TAKETHIS.

So your position is that the specification(s) should say something like:

    If the server is unable to process the article immediately, or
    runs into any problem when processing it, it will reject the
    article and the client MUST NOT attempt to re-send it *EVER AGAIN*.

If you disagree with this, then you're saying there needs to be a "defer"
code.

If you agree with this then I'm afraid I simply can't support you. This is
a prime opportunity for articles to get lost (and don't mention the inkblot
algorithm; there are plenty of bottlenecks in the system and this RFC
doesn't only apply to global-Usenet).

---

From: clive at demon.net (Clive D.W. Feather)
Date: Mon Oct 18 03:46:58 2004

> for the TAKETHIS case (it results in the sending end wasting a lot of

No, you mean "which triggers undesirable behaviour in broken clients". It's
not at all a bogus response; on the contrary, it's a conforming one.

> under any circumstances whatever breaks existing streaming clients.

No, I mean 432 because that's what the specification say. Just because
some existing clients are broken (and crashing when they receive 432 is
broken) doesn't mean that we have to pander to them.

There may be grounds for not distinguishing the CHECK and TAKETHIS
responses, but you need a better argument than bogusware.

---

From: clive at demon.net (Clive D.W. Feather)
Date: Mon Oct 18 03:51:47 2004

> body, then I'd suggest dropping it out of the draft entirely.

The realistic case is very simple: if the server can't accept the article
now but has no objection to the article itself, then it needs some way to
say so. There are only three ways to do this:

(1) Declare that you can never defer an article: if sending it goes wrong
for any reason, that article can NEVER EVER FOR ETERNITY be accepted.

(2) Give a bogus response like 400 plus dropping the connection, at which
point the client doesn't know what is wrong and will retry the same
action.

(3) A defer code.

This is so obviously superior that RFC 977 did it and SMTP does it.

---

From: ken at oceana.com (Ken Murchison)
Date: Mon Oct 18 07:33:05 2004

> broken) doesn't mean that we have to pander to them.

FWIW, I agree with Clive on this point (regarding 436, I think the jury 
is still out on 432).  I'm all for trying to document existing practice, 
as long as existing practice isn't horribly broken.  Poor 
implementations should wither and die, not continue to exist because we 
retroactively make them compliant.

---

From: andrew at supernews.net (Andrew - Supernews)
Date: Mon Oct 18 10:51:11 2004

>>>>> "Clive" == Clive D W Feather <[email-masked]> writes:

 Clive> Andrew - Supernews said:
 Clive> The problem with closing (or issuing a 400, which is far
 Clive> superior) is that it prevents the client doing anything else,
 Clive> like newsreading.

 >> In practice, streaming feeds and newsreading are never done on the

 Clive> Why is that justification for hardwiring it into the
 Clive> specification for ever more?

It's not. But it does mean that potential inconvenience to a client
that does both streaming feeds and newsreading is a very, very minor
consideration.

 >> If for some strange reason the client wants to use reader
 >> commands, it can reconnect.

 Clive> And you don't think that's antisocial?

Allowing TAKETHIS to respond with a connection close in certain
failure cases is too important to worry about the effect on
nonexistent clients.

Nothing I've suggested would impact the ability of a client to mix
reader commands and streaming feeds on the same connection if it
wanted to and was written to cope with it.

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

---

From: andrew at supernews.net (Andrew - Supernews)
Date: Mon Oct 18 11:15:08 2004

>> What I'm saying is that I know of no cases in which it makes sense
 >> for a server to return a deferral after the article body in either
 >> IHAVE or TAKETHIS.

 Clive> So your position is

My position is what _I_ said, not your misunderstandings of what I said.

 Clive> that the specification(s) should say something like:

 Clive>     If the server is unable to process the article
 Clive>     immediately, or runs into any problem when processing it,
 Clive>     it will reject the article and the client MUST NOT attempt
 Clive>     to re-send it *EVER AGAIN*.

I explicitly did not say that.

If the server can't accept the article for reasons that are specific
to that article, then re-sending it will be futile and therefore a
rejection rather than a deferral is appropriate.

If the server can't accept the article for reasons that are _not_
specific to the article, then those reasons will also apply to the
following articles in the stream, and returning a continuous stream of
deferrals is extremely client-hostile behaviour, since the client has
no way to know how long it will take before the articles can be
accepted again. Instead, the right action is for the server to close
the current connection with a 400 response, and then refuse the
client's attempts to re-establish it (or if it wishes to allow the
client to use non-feeding commands, allow the client to reconnect but
close the connection again on a subsequent TAKETHIS) until it is once
again able to accept articles. Note that in practice the server's
inability to accept articles could last from several minutes up to at
least a whole day.

This behaviour is already understood by clients because it is commonly
used in practice in existing implementations. The clients response to
it is to put all the currently in-flight articles (_including_ the one
that triggered the close since no 239 or 439 response was seen for it)
back into the queue and then try, at appropriate intervals, to re-open
the connection.

 Clive> If you disagree with this, then you're saying there needs to
 Clive> be a "defer" code.

I'm saying that in nine years of installing, running, maintaining and
writing from scratch NNTP implementations of various sorts, I've yet
to encounter a single case where returning a "defer" code _in response
to an article body_ was a reasonable thing to do. I also have
extensive experience of the things that go wrong when dealing with
implementations (that, obviously, I _didn't_ write) which attempt to
return such a response.

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

---

From: andrew at supernews.net (Andrew - Supernews)
Date: Mon Oct 18 11:26:06 2004

>> INN never generates 436 after receiving an article body. Older
 >> diablo versions (haven't checked newer ones) generate 436 if they
 >> failed to store the article, which is bogus for the same reasons
 >> that I covered for the TAKETHIS case (it results in the sending
 >> end wasting a lot of effort).

 Clive> No, you mean "which triggers undesirable behaviour in broken
 Clive> clients". It's not at all a bogus response; on the contrary,
 Clive> it's a conforming one.

Conforming with what? For the TAKETHIS case, the best existing
reference around is 2980, which does not list a deferral response for
TAKETHIS. (It allows only for 239, 439, 400, 480, 500)

 Clive> No, I mean 432 because that's what the specification say.

It's what the _draft_ says. Where reality and the text of the draft
conflict, then it's the draft which has to change, not the reality.

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

---

From: andrew at supernews.net (Andrew - Supernews)
Date: Mon Oct 18 12:04:29 2004

>>>>> "Clive" == Clive D W Feather <[email-masked]> writes:

 Clive> The realistic case is very simple: if the server can't accept
 Clive> the article now but has no objection to the article itself,
 Clive> then it needs some way to say so. There are only three ways to
 Clive> do this:

 Clive> (1) Declare that you can never defer an article: if sending it
 Clive> goes wrong for any reason, that article can NEVER EVER FOR
 Clive> ETERNITY be accepted.

This is obviously wrong.

 Clive> (2) Give a bogus response like 400 plus dropping the
 Clive> connection, at which point the client doesn't know what is
 Clive> wrong and will retry the same action.

This is not "bogus" because (a) it is the existing behaviour and (b) it
works well in practice.

 Clive> (3) A defer code.

 Clive> This is so obviously superior that RFC 977 did it and SMTP does it.

This is not SMTP, and there are some very important differences.

As for 977, the best you can say about it is that it is ambiguous. It fails
to distinguish well between codes that are used in response to the IHAVE
command itself, and those that are used in response to the article sent.
In the kind of environment in which 977 and the reference implementation
were written, having a "defer" response is actually of some value, but
that environment is very different from modern streaming feeds. This makes
it reasonable to keep the existing 436 response for IHAVE, but it doesn't
in any way justify breaking the streaming feed spec just to add a code that
is of no practical use.

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

---

From: chl at clerew.man.ac.uk (Charles Lindsey)
Date: Mon Oct 18 13:13:34 2004

>reader commands, it can reconnect.

Part of the problem is that, whilst we can say in LIST EXTENSIONS that
STREAMING is (now) allowed, there is no way to give an UN-EXTENSION which
says that reader commands are no longer available. The draft mandates
that every NNTP server has full 'reader' capability, even if it is
permanently used for streaming transit.

It almost suggests that the MODE STREAM command has a useful purpose.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: andrew at supernews.net (Andrew - Supernews)
Date: Mon Oct 18 13:27:52 2004

>>>>> "Charles" == Charles Lindsey <[email-masked]> writes:

 >> same connection. If for some strange reason the client wants to
 >> use reader commands, it can reconnect.

 Charles> Part of the problem is that, whilst we can say in LIST
 Charles> EXTENSIONS that STREAMING is (now) allowed, there is no way
 Charles> to give an UN-EXTENSION which says that reader commands are
 Charles> no longer available. The draft mandates that every NNTP
 Charles> server has full 'reader' capability, even if it is
 Charles> permanently used for streaming transit.

The draft mandates nothing of the kind. The server is allowed to
reject reader commands if MODE READER has not been used, and it's
allowed to reject the MODE READER command itself.

Don't ever lose sight of the fact that 90%+ of servers doing transit
feeding simply _do not have reader functionality at all_, and never
will have regardless of what any specification says.

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

---

From: ken at oceana.com (Ken Murchison)
Date: Mon Oct 18 15:25:38 2004

> permanently used for streaming transit.

This can be easily solved by adding a NOREADING or READINGDISABLED 
capability.  IMAP has a LOGINDISABLED capability if a server chooses to 
disable the standard LOGIN command (LOGIN is a base command, but the 
IMAP TLS spec allows it to be disabled).