Subject: Re: [NNTP] Snapshot 4

From: "Andrew - Supernews" <[email-masked]>
Date: Wed, 01 Dec 2004 10:10:18 +0000

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

 >> LIST is already a complete mess and the idea of two-part command
 >> names is also a complete mess. I can't do much about the ones
 >> already there, but I see no reason to make the situation worse.

 Russ> I don't have any real opinion on this and am happy to let
 Russ> someone make an arbitrary decision unless we can come up with a
 Russ> strong argument one way or the other.  (Andrew?  You'd said
 Russ> you'd prefer LIST before as well.)

I have a strong preference for LIST in these cases:

1) The command makes no changes to server-side state

2) The command returns a list of items in a one-per-line format, where
the results are either constant or mostly constant (for a specific
server configuration or state), or are obtained from a scan of the
active file against a wildmat qualifier

3) The command isn't used very frequently (LIST ACTIVE is the only
existing LIST subcommand that gets heavy usage)

There's a lot of common code in handling LIST subcommands in existing
implementations (both client and server), despite the rather ad-hoc
nature of the response formats of the existing subcommands, and it
makes sense to me to take advantage of that rather than put lots of
new entries in the top-level command table.

For the same reasons, plus the whole "last-minute major changes" thing,
I am strongly opposed to changing any of the existing LIST subcommands
in the spec (LIST HEADERS etc) to top-level commands.

The "making the situation worse" argument is nonsense given the number
of LIST subcommands which already exist and can't be removed. I would
argue that, in fact, changing tack _now_ to use top-level commands for
commands which would previously have been LIST subcommands is a far
worse step, introducing much more confusion than it could ever remove.

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

---

From: Russ Allbery <[email-masked]>
Date: Wed, 01 Dec 2004 02:21:34 -0800

> 1) The command makes no changes to server-side state

CAPABILITIES certainly fits here.

> active file against a wildmat qualifier

Likewise here.

> existing LIST subcommand that gets heavy usage)

This is where I don't think that it does.  If clients do what we're going
to tell them to do, CAPABILITIES will be used at least once a session,
perhaps more.  That may still not qualify as very frequently, but I think
it's still as frequent as LIST ACTIVE or perhaps more.

Certainly my intention is to hard-code the output of the command except
for SASL mechanisms and the needed switches to add or remove commands that
aren't available for a particular session and make the command reasonably
fast.  Note that currently in INN, we weren't able to share code for LIST
EXTENSIONS with the other LIST commands (most of which do all share code).

> nature of the response formats of the existing subcommands, and it makes
> sense to me to take advantage of that rather than put lots of new
> entries in the top-level command table.

Agreed in general.  CAPABILITIES does feel somewhat special to me,
although I could be convinced otherwise.

> in the spec (LIST HEADERS etc) to top-level commands.

I strongly agree with you here.

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

---

From: "Andrew - Supernews" <[email-masked]>
Date: Wed, 01 Dec 2004 10:38:06 +0000

>> existing LIST subcommand that gets heavy usage)

 Russ> This is where I don't think that it does.  If clients do what
 Russ> we're going to tell them to do, CAPABILITIES will be used at
 Russ> least once a session, perhaps more.  That may still not qualify
 Russ> as very frequently, but I think it's still as frequent as LIST
 Russ> ACTIVE or perhaps more.

Once per session isn't what I call "very frequently". LIST ACTIVE is
often used thousands of times per session or more (LIST ACTIVE
group.name being a common way to check for new arrivals, being faster
than GROUP).  Anything used only a couple of times per session is down
in the noise in comparison to LIST ACTIVE and the common top-level
commands (ARTICLE, OVER/XOVER, GROUP etc.)

 Russ> Certainly my intention is to hard-code the output of the
 Russ> command except for SASL mechanisms and the needed switches to
 Russ> add or remove commands that aren't available for a particular
 Russ> session and make the command reasonably fast.  Note that
 Russ> currently in INN, we weren't able to share code for LIST
 Russ> EXTENSIONS with the other LIST commands (most of which do all
 Russ> share code).

INN's implementation of the other LIST subcommands is possibly a bit
more rigid than mine is.

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 1 Dec 2004 11:35:54 GMT

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

>ACTIVE.TIMES, if provided, always accepts a wildmat. DISTRIB.PATS, again if
>provided, never does. However, there's an arbitrary number of further
>keywords that servers could provide, not documented in this specification.
>For any given keyword, does it accept a wildmat or not? Does LIST XTRA.DATA?
>What about LIST PRIVATE.GROUPS? Or LIST CHARGED.GROUPS?

>Obviously, there's no way for this to be specified ahead of time. So do we
>make clients suck it and see, or do we provide the information in the
>CAPABILITIES output?

If the LIST FOOBAR command exists (as evidenced by the CAPABILITIES), it
is still the case that no client is going to issue it without knowing what
is means, which it can only discover by reading (or having its implementor
read) the RFC (or private communication) that introduced the FOOBAR
extension. But that RFC (or whatever) will already have explained the
syntax, including the applicability of wildmats.

The only exception is some private individual telneting to port 119 out of
curiosity, and that individual it quite capable of experimenting and
deducing what is allowed by observing the return codes.

-- 
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: Ken Murchison <[email-masked]>
Date: Wed, 01 Dec 2004 10:21:56 -0500

Russ Allbery wrote:
> Clive D W Feather <[email-masked]> writes:
> 
> 
>>Okay, a fourth snapshot is in the usual place:
>>    <http://www.davros.org/nntp-texts/draft25.pre-4.txt>
>>    <http://www.davros.org/nntp-texts/draft25.pre-4.html>
> 
> 
> Some more general comments on this:
> 
> I really dislike the leading underscores on _VERSION, _TRANSIT, and
> _READER.  Since we have an IANA registry for extensions, there is no
> concern about namespace conflict; unlike with C or POSIX, we have a
> central body that can administer the namespace.  I would really prefer all
> of the extension labels to look the same, the way that other protocols do.

Not to be redundantly redundant, but I (still) agree.

> I would still rather see something like NNTPv2 rather than VERSION 2, but
> I don't feel strongly enough about it to really debate it if no one else
> agrees with me.  This won't hurt anything.

I have, and will continue to agree with this (mostly since I suggested 
the NNTPv2 token).  I also think that it *might* be worth putting this 
token in the initial line of the CAPABILITIES response, e.g.:

[C] CAPABILITIES
[S] 101 NNTPv2 Capabilties follow:
[S] READER
[S] TRANSIT
[S] STARTTLS
[S] AUTHINFO SASL:DIGEST-MD5
[S] .

By doing this the client knows what the protocol version is immediately, 
before it parses the multi-line response, and therefore we don't have to 
specify a particular order for the capabilities list.

> I don't see any point in the _SERVER line.  Traditionally, this
> information is returned in the initial greeting.

But since the info in the initial greeting is free-form text, it would 
be unwise for a client to attribute any meaning to it, regardless of the 
fact that most servers put version info there.  I think most other 
protocols also discourage deriving meaning from any initial greeting 
text (except for SMTP's <domain> param and ad-hoc ESMTP token).

 > It isn't really a
> capability and clients should be actively *discouraged* from attributing
> any meaning to it or using it to guess capabilities, so I think putting it
> into CAPABILITIES is sending the wrong message.

I agree that clients MUST NOT attribute any meaning to this, but this 
info can be useful.  If the server returns this "capability" the client 
can be fairly certain that its accurate and use it for reporting 
bugs/problems against.  Although the same *might* be true about the 
initial greeting text, its also possible that the greeting text just 
says "good morning".

FWIW, POP3 has a similar capability named "IMPLEMENTATION" (which I 
prefer to "SERVER") and IMAP4 has an extension named "ID" (which the 
client can use to present implementation info to the server and the 
server can present implementation info back to the client).

-- 
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: Ken Murchison <[email-masked]>
Date: Wed, 01 Dec 2004 11:07:37 -0500

Russ Allbery wrote:

>>Issue: do we provide a way for CAPABILITIES to advertise features that
>>aren't available right now but could be, or have been.
> 
> 
>>Ken Murchison said:
>>
>>>2505:  I thought we had already decided that all of this "negative 
>>>capability" business was too much.  I'm opposed to this proposal.
> 
> 
>>It came back again in at least one of Russ's messages.
> 
> 
>>The reason for proposing it is that it addresses a number of issues:
>>* advertising "can only authenticate after TLS", "can do more SASL options
>>  with TLS", "can only authenticate after MODE READER", and so on;
>>* indicating the authentication methods that were available after
>>  successful SASL;
>>* indicating that the server is mode-switching;
>>and so on. Now we can come up with ad-hoc solutions for each of those, but
>>isn't it better to have a framework for it?
> 
> 
>>In particular, the present SASL stuff is an abomination - advertising a
>>capability as available with the secret understanding that that means it
>>*isn't* available - and goes directly against a MUST in the core
>>specification.
> 
> 
> I'm not particularly worried about the SASL case because this is what
> everyone else does too.  To me, that makes it not an abomination; no
> matter what else one might think about it, it has the significant
> advantage of cross-protocol consistency, and a lot of implementors write
> multi-protocol clients.

In all honesty, the current way that we're handling this *is* kind of 
ugly.  I would prefer to go back to listing the SASL mechs on a separate 
capability line (like in the original drafts), so that we don't give the 
impression that AUTHINFO is still a valid command after authentication. 
  For example:

[C] CAPABILTIES
[S] 101 Here's what I can do:
[S] NNTPv2
[S] TRANSIT
[S] AUTHINFO
[S] SASL DIGEST-MD5 GSSAPI
[S] STARTTLS
[S] .
[C] STARTTLS
<TLS negotiation here>
[C] CAPABILTIES
[S] 101 Here's what I can do after TLS:
[S] NNTPv2
[S] TRANSIT
[S] AUTHINFO USER
[S] SASL DIGEST-MD5 GSSAPI PLAIN
[S] .
[C] AUTHINFO PLAIN xxxxx
[S] 281 Authentication successful
[C] CAPABILTIES
[S] 101 Here's what I can do after auth:
[S] NNTPv2
[S] TRANSIT
[S] READER
[S] OVER
[S] HDR
[S] SASL DIGEST-MD5 GSSAPI PLAIN
[S] .

> 
> 
>>What is the objection to this? If it's the detail of the "-", "--",
>>"-480" stuff, then I'm happy to amend or drop that part. But what is
>>wrong with the basic principle of having a consistent way of saying
>>"extension X wishes to tell you that capability Y isn't currently
>>available"?
> 
> 
> This is a pure complexity versus expressiveness tradeoff.  I'm again
> inclined to go for less complexity and less expressiveness because other
> protocols do not have this and have not apparently needed it.  I can see
> the cases where this might be helpful, but in practice I just don't think
> they're going to be all that useful or important.

Agreed.  This would add complexity which the most similar protocols 
don't have and haven't longed for (especially SMTP which also is 
frequently used unauthenticated), and would possibly inhibit 
implementation and adoption.  I won't repeat the entire discussion which 
took place in the other thread, but the arguments still apply.  FWIW, 
Mark Crispin as a client author is still opposed to this proposal 
(offline rant omitted).

---

From: Ken Murchison <[email-masked]>
Date: Wed, 01 Dec 2004 11:30:25 -0500

Russ Allbery wrote:

>>Charles Lindsey said:
>>>For the record, I would prefer "LIST CAPABILITIES"
> 
> 
>>I don't.
> 
> 
>>LIST is already a complete mess and the idea of two-part command names is
>>also a complete mess. I can't do much about the ones already there, but I
>>see no reason to make the situation worse.
> 
> 
> I don't have any real opinion on this and am happy to let someone make an
> arbitrary decision unless we can come up with a strong argument one way or
> the other.  (Andrew?  You'd said you'd prefer LIST before as well.)

If we're keeping "LIST HEADERS" and "LIST OVERVIEW.FMT" for the many 
reasons listed by Russ and Andrew, then I'm in favor of "LIST CAPABILITIES".

> I would prefer to drop LIST EXTENSIONS entirely; it was an invention of
> this working group, has only small (and not very useful) deployment in
> practice, and really doesn't seem useful for any client to send given the
> direction that we're going.  v1 clients wouldn't know anything about it,
> so I don't know how it could provide a bridge.

If "LIST EXTENSIONS" was never formally documented in something other 
than a WG draft, then I'm also in favor of dropping it entirely.

---

From: Russ Allbery <[email-masked]>
Date: Wed, 01 Dec 2004 11:36:16 -0800

>> I would still rather see something like NNTPv2 rather than VERSION 2,
>> but I don't feel strongly enough about it to really debate it if no one
>> else agrees with me.  This won't hurt anything.

> I have, and will continue to agree with this (mostly since I suggested the
> NNTPv2 token).  I also think that it *might* be worth putting this token
> in the initial line of the CAPABILITIES response, e.g.:

> specify a particular order for the capabilities list.

Hm, that's an interesting thought.  There is something to be said for
this, and I wouldn't mind if that initial line looked exactly like the
current VERSION line if people really want to keep the number separate
from the word.  In other words, something like:

    101 VERSION 2
    READER
    TRANSIT
    STARTTLS
    AUTHINFO SASL:DIGEST-MD5
    .

After all, the version information *is* special and different than the
rest of the capabilities and could conceivably be required in order to
understand the rest of the list.

I'd defend this deviation from other protocols (and claim I'm still being
somewhat consistent) on the grounds that other protocols don't use the
initial response and then multiline response method in the protocol and
therefore don't have that initial line to worry about.

On the other hand, doing this (and keeping the 101 response code instead
of using the regular LIST code) makes it a lot harder to use the same code
as other LIST commands if we go back to LIST CAPABILITIES.

> text (except for SMTP's <domain> param and ad-hoc ESMTP token).

Is the SERVER response not also freeform text?  And surely we would also
prohibit deriving any meaning from it as well, from a protocol standpoint?

> initial greeting text, its also possible that the greeting text just

But surely this wouldn't be done on an automated basis, and a human could
look at the initial greeting as well.  Yes, a server could not advertise
its implementation in the greeting, but in that case it probably wouldn't
provide a SERVER capability either.

It just feels to me like if we put this into CAPABILITIES, no matter what
the standard might say we're just begging a client to make protocol
decisions based on what's there, since the client would do that for
everything else in the CAPABILITIES output.

> server can present implementation info back to the client).

This does make me feel better about the idea, although it makes me wonder
why IMAP went the route of a different command.  Maybe because in IMAP
capabilities can't take arguments?

---

From: Russ Allbery <[email-masked]>
Date: Wed, 01 Dec 2004 11:37:20 -0800

> impression that AUTHINFO is still a valid command after

Oh, hm, good point.  I'd forgotten we'd been there before.  Clive, what do
you think of this?  Would this address your issue?

---

From: Ken Murchison <[email-masked]>
Date: Wed, 01 Dec 2004 14:49:12 -0500

> capabilities can't take arguments?

That would be my guess.  All IMAP capabilites are listed in a single 
line response (whitespace separated), so they really can't have 
arguments, and definitely can't have freeform text.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 2 Dec 2004 08:49:12 +0000

Russ Allbery said:
>> I can see the viewpoint that says that this horse bolted long ago and
>> this is just shutting the stable door. So I'm not wedded to keeping it.
> This is exactly my opinion.  It's a nice thought, but it's way too late.

Okay. Done.

-- 
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 D.W. Feather" <[email-masked]>
Date: Thu, 2 Dec 2004 09:56:51 +0000

Russ Allbery said:
>> Issue: if MODE READER remains significant, what response code is used
>> for "you can't do this until you've issued MODE READER"? The historical
>> answer is 502. We added 401 in draft as "you need to invoke this feature
>> first" and this seems cleaner. On the other hand, clients are going to
>> have to be prepared for 502 anyway.

> Both 502 and 401 have arguments in favor of them -- 401 is a lot clearer,
> but 502 is what everything already does and we're discouraging people from
> requiring MODE READER anyway, even if we're keeping it.

This points towards 502 for this circumstance. I think I'm leaning towards
this as well, but I won't do it until you tell me to.

> I think I lean
> slightly towards removing the 401 code, since this is the only thing that
> uses it right now.  I wasn't very happy with it in the first place; I
> would rather have explicit codes for the few commands that will need this
> kind of thing.  But I don't feel very strongly about this.

We still need the 401 code. The reason for it, in case it's slipped your
mind, is that some future extension may need a way to say to a core
command "you can't do this until you've invoked this extension". If each
such extension could invent its own code, clients wouldn't know what to do;
in any case, we EXPLICITLY banned extensions from altering the core
protocol until the client invokes them.

So we needed at least one "an extension needs to be invoked" response. We
decided to give authentication and privacy explicit codes, since there
mighe be more than one extension of these types and because they are clear
and separate concepts, but we still need a catch-all for other future
cases.

Here's a somewhat contrived example. Suppose that a server extension allows
for "paid-for" articles, using a micropayment system. The extension needs a
way to say "you need to pay for this article". So:

    [C] GROUP local.reports
    [S] 211 3 1001 1003 local.reports
    [C] ARTICLE 1001
    [S] 220 1001 <[email-masked]>
    [article contents omitted]
    [S] .
    [C] ARTICLE 1002
    [S] 401 XPAYMENT This article costs EUR 0.25
    [C] XPAY MAX=EUR0.50 micropayment.token ARTICLE 1002
    [S] 220 1002 <[email-masked]>
    [article contents omitted]
    [S] .
    [C] ARTICLE 1003
    [S] 401 XPAYMENT This article costs EUR 5.00
    [C] XPAY MAX=EUR0.50 micropayment.token ARTICLE 1002
    [S] 491 price not met

("micropayment.token" would be replaced by the actual token, of course).

The point of the 401 response is that it is a core response and so can be
used in the above situation where - to that point - the client had done
nothing to indicate it knows anything about the XPAYMENT extension.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 2 Dec 2004 10:05:16 +0000

Russ Allbery said:
>> Issue: if a server advertises itself as transit-only, should it be
>> allowed to implement some of the reader-only commands or not?
> Yes.  As Andrew pointed out, there's no reason to forbid a server from
> doing this, and it's useful for various purposes.
> 
> The question is more whether we want to define a mechanism for the server
> to *tell* a client that it's doing this.

Agreed.

> If we don't, then a compliant
> client will never know it can use the commands, won't use them, and
> therefore they'll be there basically only for debugging and for internal
> purposes.
> 
> Personally, I think that's fine, and better than the complexity of trying
> to define a way of communicating all this information.  I would rather
> take the route of specifying what the *client* should do based on what the
> server says it supports and simply remain mum on the question of what the
> server might do outside of what it's advertising that it does.

Okay, this is a path I can follow (very happily). I'll rewrite this bit
accordingly.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 2 Dec 2004 10:06:08 +0000

Ken Murchison said:
> General comments:
> 
> - I still don't understand the reasoning for the '_' used in the core 
> capability tokens.

I'll take this up in the separate thread that is also discussing it.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 2 Dec 2004 10:39:15 +0000

Russ Allbery said:
>> Issue: what do we do with the MODE READER command? Make it optional on
>> servers that aren't mode-switching?
[...]
> If we keep it, I think it should be mandatory to implement; as you say,
> returning a fixed response code is trivial.

Agreed.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 2 Dec 2004 10:40:31 +0000

Russ Allbery said:
>> Issue: should LIST OVERVIEW.FMT be renamed as something else?
> No.  The main reason why we have it is for backward compatibility with
> existing implementations, which is broken by renaming it.

Okay.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 2 Dec 2004 10:47:00 +0000

Assuming for the moment that we're keeping mode-switching servers, is
everyone now happy with the 25-pre4 wording for MODE READER?

*IF* we do decide to drop mode-switching (and please let's discuss this in
the other thread, not here), then I will replace the last two paragraphs
with the single line:

    The MODE READER command has no effect on the state of the server.

and move the whole command to the "deprecated commands" section.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 2 Dec 2004 10:53:18 +0000

Ken Murchison said:
> I'm in favor of B to clean up the protocol, but from an implementation 
> standpoint does it really matter?  Isn't the cat already out of the bag 
> on this one?
> 
> I think its already been determined that given its current architecture, 
> making INN a full-time general purpose server is a non-starter, at least 
> for the short term.

I thought Mark Crispin was going to take a six-pack of beer over to Russ
and fix that code? Or did I misunderstand?

How are we going to resolve the stuff about the ordering of AUTHINFO/TLS
and MODE READER?

Question: if mode-switching stands, are people happy with the way I present
it in pre4? In particular, Ken, are you happy that this better addresses
the stuff about using extensions before and after MODE READER?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 2 Dec 2004 13:34:48 +0000

Russ Allbery said:
> Er, the client should look at the specification for that particular LIST
> command to figure out whether it takes a wildmat.  If we're not requiring
> a specification here in some form, I think we may be going down the wrong
> road.  If the client doesn't have access to a specification, it's going to
> have a lot more problems than just not knowing whether to include a
> wildmat, like having any clue whatsoever what the output is supposed to
> mean.

True. Ish.

Given that (currently - I know there's another thread) the only valid
argument to an arbitrary LIST keyword command is a wildmat, this struck me
as an "almost no pain, some gain" sort of thing.

Would anyone object violently to wording saying that future versions of
this specification, or extensions, may put non-alphanumeric suffixes on
the keywords in the LIST capability line? The purpose would be to give room
for future changes or improvements without having to go through a "client
says it's willing to receive this" loop. Note:
* Servers need to do nothing to conform to this.
* Clients need only make sure they won't barf if such a suffix appears;
  they can ignore it.

I'm trying to think ahead a little, that's all.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 2 Dec 2004 13:59:20 +0000

> everyone else does too.

Is it?

I've just skimmed the various SMTP documents, and as far as I can tell
they differ from NNTP in a major way: EHLO lists the extensions available,
*NOT* the extensions available at any given moment. That is, an extension
should be listed even if it can't be used until something else has been.
Looking at RFC 2554, it appears that you should advertise AUTH even if
there's no privacy layer in place, with the 538 code meaning "you can't do
AUTH yet".

Hmm, I see that RFC 3207 does require a server not to advertise TLS once
TLS is in place.

But see my response to Ken's response.

> they're going to be all that useful or important.

Can I start by noting that, under my proposal, the minimal requirements
are:
* Servers need to do nothing.
* Clients need to be prepared to ignore lines beginning with "-".
That's a pretty low barrier and, in the case of clients, it's likely to be
what they're doing anyway (rather than panicking when they see such a
line). But, in exchange, we get the framework for future facilities if we
need them. Again, let me ask you see my response to Ken's response, which
I'm about to write.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 2 Dec 2004 14:52:26 +0000

> impression that AUTHINFO is still a valid command after authentication. 

Okay, I've been thinking about this some more.

Back when it was called LIST EXTENSIONS, there was plenty of reason to say
"one extension, one line". However, now that it's CAPABILITIES it's
possible to make a mental shift. Suppose I rewrite the description to say
that its purpose is to describe capabilities, and these are done one per
line (see below for more on this). In most cases an extension would be a
single capability, but in exceptional situations it can have more than one.

Now the AUTHINFO extension becomes such an exceptional situation: it
defines *two* capabilities:

(1) The AUTHINFO capability says which AUTHINFO commands are allowed at the
moment. If none are (including when authentication is complete), then this
capability isn't listed.

(2) The SASL capability says which SASL mechanisms are understood by the
server. This is listed at all times, even if AUTHINFO currently isn't.

Thus your example would become:

    [C] CAPABILITIES                         <=== spelling fixed
    [S] 101 Here's what I can do:
    <other entries omitted>
    [S] AUTHINFO SASL                        <=== NOTE SASL
    [S] SASL DIGEST-MD5 GSSAPI
    [S] STARTTLS
    [S] .
    [C] STARTTLS
    <TLS negotiation here>
    [C] CAPABILITIES
    [S] 101 Here's what I can do after TLS:
    <other entries omitted>
    [S] AUTHINFO SASL USER                   <=== NOTE SASL
    [S] SASL DIGEST-MD5 GSSAPI PLAIN
    [S] .
    [C] AUTHINFO PLAIN xxxxx                 <=== AUTHINFO SASL PLAIN surely?
    [S] 281 Authentication successful
    [C] CAPABILITIES
    [S] 101 Here's what I can do after auth:
    <other entries omitted>
    [S] SASL DIGEST-MD5 GSSAPI PLAIN         <=== AUTHINFO now omitted
    [S] .

The same output would be produced if AUTHINFO USER had been used instead;
you still list the SASL capability.

If you are happy with this, then let's go that way.

I would like you to think about SASL methods that are unavailable before
encryption. Consider a client that can only do SASL PLAIN (or some other
method that requires TLS in place). At present, it has no way to find out
whether or not it's worth going through the effort of doing TLS; the only
way to see whether PLAIN is going to appear is to actually try it. Now
we're trying to get *away* from the suck-it-and-see school of protocol
design. So I would suggest that the SASL capability should indicate what
will be available once a privacy layer is in place. This could be via
specific flags:

    [C] CAPABILITIES
    [S] 101 Here's what I can do:
    <other entries omitted>
    [S] AUTHINFO SASL
    [S] SASL DIGEST-MD5 GSSAPI -PLAIN
    [S] STARTTLS
    [S] .

or it could use my generic facility:

    [C] CAPABILITIES
    <other entries omitted>
    [S] AUTHINFO SASL
    [S] - SASL PLAIN
    [S] STARTTLS
    [S] .

But I suggest it goes against our own principles not to provide the
information at all.

>>> But what is

I'm afraid that both he and you aren't thinking it through. In particular,
the "inhibit implementation and adoption" is nonsense.

I was very careful when writing the proposal to set the bar low. Using the
wording I proposed in 25.pre-4:

* A server DOES NOT HAVE TO DO ANYTHING WHATSOEVER to conform. I wrote
  "A server MAY provide an indication ...". Note that keyword: MAY.

* A client has to do exactly one thing to conform: it has to NOT barf when
  it sees a capability line beginning with a hyphen. Instead, it needs to
  ignore it, just like it has to ignore one that begins with a keyword that
  it doesn't recognise. Is this really a hard thing to implement?

Under this proposal, a server that wants to be helpful to clients *MAY*
provide this extra information. And a client that wants to be more
efficient *MAY* parse these extra lines. But this doesn't put a burden on
those who don't want to.

Having got that off my chest a bit, let me try to explain my vision for the
CAPABILITIES command. What I'm suggesting is that each line of the response
consists of:

    [flags ...] name [arguments ...]

and the general rules are:

* The name tells us which capability we're talking about. It's the primary
  key for interpreting the line.
* All capability names begin with a letter. So if it doesn't begin with a
  letter, it's a flag.
* Arguments are capability-specific.
* Flags have a global meaning; once a version of the NNTP specification
  defines a flag, it applies to all capabilities.
* If a client doesn't understand a flag, it MUST ignore any line
  beginning with that flag.

This gives us a structure for future expansion without having to worry
about compatibility. The only imposition it makes is the last bullet point:
if a client doesn't understand a flag, it MUST ignore it (just like it
MUST ignore any extension it doesn't understand).

The "not available now, but could be" thing is then just one such flag.

[I need to run to catch a train. I hope this has at least made you think a
bit.]

---

From: Ken Murchison <[email-masked]>
Date: Thu, 02 Dec 2004 09:59:00 -0500

> everyone now happy with the 25-pre4 wording for MODE READER?

Based on the earlier posts, you'll want to remove the 401 response from 
the example(s).

Are we still planning on having a MODE_READER capability?  Without this 
or the 401 response, a 502 response doesn't definitively tell the client 
that its needs to do MODE READER (unless I'm missing something).

---

From: Ken Murchison <[email-masked]>
Date: Thu, 02 Dec 2004 10:04:54 -0500

> and fix that code? Or did I misunderstand?

I also volunteered to fix the code (or at least help drink the beer).

> How are we going to resolve the stuff about the ordering of AUTHINFO/TLS

Good question.  I don't see any *easy* way of keeping TLS or SASL 
security layers alive across a MODE READER if it spawns a separate 
process.  If we put the TLS and/or SASL context in shared memory, then 
it would survive the fork()/exec() and could be retained, but this 
probably isn't portable on all platforms that INN runs on.  Or we could 
make innd multi-threaded.

> the stuff about using extensions before and after MODE READER?

Can you direct me to the text to which you refer?  I don't recall seeing 
any reference to MODE READER and extensions.

---

From: "Ruud H.G. van Tol" <[email-masked]>
Date: Thu, 2 Dec 2004 16:06:48 +0100

Clive D.W. Feather wrote:

> I would like you to think about SASL methods that are unavailable
> before encryption. Consider a client that can only do SASL PLAIN (or
> some other method that requires TLS in place). At present, it has no
> way to find out whether or not it's worth going through the effort of
> doing TLS; the only way to see whether PLAIN is going to appear is to
> actually try it. Now
> design. So I would suggest that the SASL capability should indicate
> what will be available once a privacy layer is in place. This could
> be via specific flags:

Is it also useful to indicate what is *not* available?

I first read your '-PLAIN' as 'minus PLAIN', meaning 'PLAIN is not
supported'.

-- 
Grtz, Ruud

---

From: Ken Murchison <[email-masked]>
Date: Thu, 02 Dec 2004 10:12:08 -0500

> as an "almost no pain, some gain" sort of thing.

Why does it have to be defined that way?  I discussed this in another 
post, but why can't LIST be defined as:

LIST [ keyword *(WSP argument) ]

and each variant describes in detail what the keyword and argument(s) 
are?  Maybe I should extract my text and start a new thread discussing LIST?

> * Clients need only make sure they won't barf if such a suffix appears;

I'm completely clueless as to what problem this is trying to solve or 
feature its trying to add.  Can you elaborate?

---

From: Ken Murchison <[email-masked]>
Date: Thu, 02 Dec 2004 11:46:43 -0500

> server. This is listed at all times, even if AUTHINFO currently isn't.

Yes.  The is exactly what the AUTHINFO document used to have.

>     [C] CAPABILITIES                         <=== spelling fixed

Or possibly "LIST CAPABILITIES".

>     [S] AUTHINFO SASL                        <=== NOTE SASL

The SASL argument to AUTHINFO is redundant given the SASL capability, 
but I won't fight it.

>     [C] AUTHINFO PLAIN xxxxx                 <=== AUTHINFO SASL PLAIN surely?

Yup.  My mistake.

>     [S] SASL DIGEST-MD5 GSSAPI PLAIN         <=== AUTHINFO now omitted

Correct.

> If you are happy with this, then let's go that way.

Yes, I'm fine with this.  I'll resurrect the old text.

> way to see whether PLAIN is going to appear is to actually try it.

Since NNTP *requires* PLAIN to be protected by some type of privacy 
layer, any client will know that if it wants to use it, it probably 
needs to do STARTTLS (or XENCRYPT or whatever) before it will be 
available.  The same is true for AUTHINFO USER.

> Now

I agree in principle, but I think in this case its unneeded, as the link 
between PLAIN and TLS is clear.

> The "not available now, but could be" thing is then just one such flag.

I'm not opposed to your proposal in principle, I just don't think its 
necessary right now.  We're already having enough trouble getting what 
we have out the door, and I don't think we need to spend more time 
figuring out what might be needed down the road.  As long as we don't 
paint ourselved into a corner with the current draft, this facility can 
always be added at a later time, when a more compelling need is discovered.

---

From: Ken Murchison <[email-masked]>
Date: Thu, 02 Dec 2004 11:56:30 -0500

Russ Allbery wrote:

> to *tell* a client that it's doing this.  If we don't, then a compliant

I agree in pricipal, but is a transit-only server which allows "suck" 
feeds a common enough case where a "NEWNEWS" argument to the "TRANSIT" 
capability would make sense?

We're special-casing the POST command for reader-only servers and 
NEWNEWS for transit-only seems similar.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 02 Dec 2004 10:24:27 -0800

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

> command "you can't do this until you've invoked this extension".

Yeah, I'm still not really convinced by this, but everyone else seems
happy with it, so I'll stop arguing about it.  :)  It makes sense in the
future-proofing department, I suppose.

The disadvantage of sticking with 502 for the MODE READER case is that
then 401 isn't actually used by anything that currently exists, which
always makes me a bit nervous.  But 502 is existing practice.

Leave 401 in, and I don't care a lot about 502 vs. 401 for MODE READER but
I'd tend to lean towards 502 (which also lets us simplify the 401
description slightly to always use an extension label).

---

From: Russ Allbery <[email-masked]>
Date: Thu, 02 Dec 2004 10:27:40 -0800

> capability would make sense?

I've never heard of such a beast.  I haven't ever done an exhaustive
survey of news software, but I've never heard of a server that implements
NEWNEWS but not GROUP, ARTICLE, etc.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 02 Dec 2004 10:28:25 -0800

> that its needs to do MODE READER (unless I'm missing something).

I think we were relying on the CAPABILITIES output to tell the client that
they have to send MODE READER.

---

From: Ken Murchison <[email-masked]>
Date: Thu, 02 Dec 2004 13:30:32 -0500

> NEWNEWS but not GROUP, ARTICLE, etc.

OK, I'm all wet.  I assumed that a server which wanted to allow suck 
feeds but not full reading, was just a transit server with NEWNEWS support.

Never mind  ;)

---

From: Russ Allbery <[email-masked]>
Date: Thu, 02 Dec 2004 10:30:31 -0800

>> inclined to go for less complexity and less expressiveness because
>> other protocols do not have this and have not apparently needed it.  I
>> can see the cases where this might be helpful, but in practice I just
>> don't think they're going to be all that useful or important.

> need them. Again, let me ask you see my response to Ken's response, which

It's not implementation complexity that I'm worrying about so much as
complexity of the standard itself.  It's not that the software has to
understand all of that; it's that an implementor has to read it all and
understand it and figure out when to use it and how to use it properly.

---

From: Ken Murchison <[email-masked]>
Date: Thu, 02 Dec 2004 13:35:15 -0500

> they have to send MODE READER.

Right, but this is still tied to issue 2505.  I was asking if we're 
going to have a separate MODE_READER capability, an argument to the 
READER capability or use Clive's "negative capability" proposal.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 02 Dec 2004 10:34:46 -0800

>> I think we were relying on the CAPABILITIES output to tell the client
>> that they have to send MODE READER.

> READER capability or use Clive's "negative capability" proposal.

Oh, okay, I get it.  I have a mild preference for an argument to the
READER capability, but no strong opinion.

---

From: [email-masked] (Kai Henningsen)
Date: 02 Dec 2004 22:16:00 +0200

[email-masked] (Ken Murchison)  wrote on 26.11.04 in <[email-masked]>:

> capability tokens.  It makes things look ugly and I don't see any
> technical benefit.  I guess I can live with it except for LIST (see below).

It's a completely misguided attempt at namespace cleanliness. The reason  
it's misguided is that we have private tokens starting with X. Everything  
not starting with X already is reserved, and there's no historic use of  
the namespace to cope with. This is not C.

MfG Kai

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 3 Dec 2004 14:15:02 +0000

Kai Henningsen said:
> it's misguided is that we have private tokens starting with X.

Wrong.

The intent was not to separate private tokens from others; as you say,
we've reserved X for that.

The intent was to separate core protocol capabilities from extension
capabilities. I can't see a specific need *right now*, but I was trying to
be forward-looking and ensure that, should it be necessary, clients could
make the distinction without having to have a built-in list of core
capability names.

However, as we've evolved the concepts during discussion, it's become less
clear that there is a meaningful distinction (particularly with things like
the SASL capability). So I'm going to get rid of the underlines.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 3 Dec 2004 14:34:32 +0000

> I first read your '-PLAIN' as 'minus PLAIN', meaning 'PLAIN is not

Hmm.

I have no problem with designing a mechanism that allows a server to
distinguish all three; so:

    SASL CRAM-MD5
    -483 SASL PLAIN
    -- SASL GSSAPI

would mean:

    "I do CRAM-MD5, I'll do PLAIN once privacy is in place, but I'll never
    do GSSAPI".

Whether there's enough demand that server authors would actually do it is
another question.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 3 Dec 2004 14:35:52 +0000

> understand it and figure out when to use it and how to use it properly.

That is something I can cure by writing it better. Let me have another go
and see what you think then.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 3 Dec 2004 14:39:28 +0000

> description slightly to always use an extension label).

I think it's finely balanced, but I'm going to go for 502 on the basis of:
- existing practice
- a transit-only server is going to be returning 502 for reader commands
  (and vice versa)
- CAPABILITIES is the right way to decide what the problem is (when we
  started we didn't have it).

I'm going to change the 401 wording to allow any capability name, rather
than only an extension name. That might come in useful one day.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 3 Dec 2004 14:59:06 +0000

> Based on the earlier posts, you'll want to remove the 401 response from 

Now done.

> that its needs to do MODE READER (unless I'm missing something).

There will be something in the capabilities list, yes.
I don't know what yet.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 3 Dec 2004 15:06:14 +0000

> I also volunteered to fix the code (or at least help drink the beer).

If only I were nearer ...

> any reference to MODE READER and extensions.

Basically grep for "mode-switching" in pre-4. But basically:

* In 3.3, look at the two paragraphs either side of issue 2504; the ones
beginning "A server may also" and "A server MAY provide". Do these
adequately express the way in which INN and suchlike servers work?

* In 8.1, the last three bullet points:
  o for each command added by the extension, whether it is a transit,
    reader, or general command;
  o if the extension provides any other features, whether they are
    available on reader-only servers or transit-only servers (all
    facilities will be available in general-use servers; for mode-
    switching servers it will depend on the current server mode);
  o how the use of MODE READER on a mode-switching server interacts
    with the extension.

(though I'm not sure that that last one is actually needed).

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 3 Dec 2004 15:36:07 +0000

[...]
> the other.  (Andrew?  You'd said you'd prefer LIST before as well.)

I'm going to claim editorial privilege unless someone comes up with a
really really good technical reason.

>>> Do we actually need a LIST EXTENSIONS command at all?
[...]
> this working group,

It was?

If so then, I agree, it should be quietly killed. It Shall Be So.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 3 Dec 2004 15:52:01 +0000

Ken Murchison said:
> CAPABILTIES:
> 
> - Why the specific order?  I can see a possible reason for _VERSION 
> being first (in fact _VERSION could almost go in the initial line of the 
> response), but I don't see where the order of the others really matters.

I thought it would be potentially useful for clients. It's no big deal, and
with the more generic handling of capabilities I no longer think it's worth
having.

As to putting VERSION in the initial line of the response, there's one
problem. If a server supports two compatible versions of NNTP (let's say 2
and 3) then the capability line is:

    VERSION 2 3

You can't have a variable number of arguments on an initial response line.
So which one do you have there?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 3 Dec 2004 15:55:09 +0000

Ken Murchison said:
> CAPABILTIES:
> 
> - May I suggest 'IMPLEMENTATION' instead of '_SERVER'.  POP3 uses the 
> former and seems to be a more descriptive name.

No problem. Done.

However, given Russ's concerns about the client making decisions on the
basis of this line, would "COMMENT" or "REMARK" be better?

---

From: Ken Murchison <[email-masked]>
Date: Fri, 03 Dec 2004 10:57:04 -0500

> So which one do you have there?

Yes, I thought about this yesterday.  The only solution would be to 
separate the versions with something other than whitespace, e.g.:

VERSION 2,3

BTW, didn't Russ say that he preferred "NNTPv2" to "VERSION 2"?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 3 Dec 2004 16:01:10 +0000

> separate the versions with something other than whitespace, e.g.:

<Cringe />

If people want the version information in the initial response line, then
we could put it there, and like that, instead of a capability line. This
would then mean there's no reason at all to require the lines to be
ordered.

Pre-4 defines the version numbers as just that, integers. Since the message
is "I support this one and that one and that one", I would suggest using +
or & rather than comma:

    [C] CAPABILITIES
    [S] 101 2+3+7 I'm talented, I am. Here's the capability list.
    [S] READER
    [S] OVER MSGID
    [S] HDR
    [S] .

Preferences from others? VERSION line with spaces, or argument to the 101
response with plus signs?

> BTW, didn't Russ say that he preferred "NNTPv2" to "VERSION 2"?

But I don't. In particular, I don't want "NNTPv2 NNTPv3" as a capability
line.

---

From: Ken Murchison <[email-masked]>
Date: Fri, 03 Dec 2004 11:02:50 -0500

> basis of this line, would "COMMENT" or "REMARK" be better?

I think IMPLEMENTATION describes the kind of info that's 
desired/expected better than COMMENT or REMARK.

As far as concern that a client would make decisions based on this:

1.  Why would it need to given the rest of the advertised capabilities?
2.  We can specifically state that the info is for informational 
purposes only and MUST not be used to determine a server's capabilities.
3.  Such clients are poorly implementated and should/will be selected 
for extinction.

This being said, I'm not going to cry if this capability goes away.  I 
still think its a good idea and replicates something that has already 
been done in IMAP and POP and doesn't appear to have resulted in crappy 
clients.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 3 Dec 2004 16:04:24 +0000

> desired/expected better than COMMENT or REMARK.

I was thinking of giving more freedom, so that the server operator can
provide other comments there (using more than one line, perhaps).

> purposes only and MUST not be used to determine a server's capabilities.

Current text:

    The server MAY include a line that begins with the token
    "IMPLEMENTATION" to provide information such as the server software
    name and version number. The client MUST NOT use this line to
    determine capabilities of the server.

> been done in IMAP and POP and doesn't appear to have resulted in crappy 

Right. It's staying as far as I'm concerned.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 3 Dec 2004 16:07:25 +0000

Ken Murchison said:
> I also think that it *might* be worth putting this 
[...]

See other thread.

> specify a particular order for the capabilities list.

Agreed. That wasn't enough to convince me, but it's enough to remove any
resistance I had.

> I think most other 

And in SMTP that's not listed as free-form text, it's specific syntax.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 3 Dec 2004 16:11:21 +0000

Russ Allbery said:
[Putting version number in the 101 initial response line]
> as other LIST commands if we go back to LIST CAPABILITIES.

I really think this command is different enough that it doesn't belong with
LIST. After all, you could argue that *anything* that doesn't change state
should be a LIST command. NEWNEWS. DATE. HDR. OVER!

> provide a SERVER capability either.

A client might well log the SERVER (now IMPLEMENTATION) capability line and
include it in automated error reports. It's far less likely to log the
comment field of the initial greeting.

---

From: Ken Murchison <[email-masked]>
Date: Fri, 03 Dec 2004 11:13:39 -0500

>     determine capabilities of the server.

Cool.  FWIW, here's the relevent text from RFC 2449 (POP extensions). 
Use it as you see fit.

        It is often useful to identify an implementation of a particular
        server (for example, when logging).  This is commonly done in the
        welcome banner, but one must guess if a string is an
        implementation ID or not.

        The argument to the IMPLEMENTATION capability consists of one or
        more tokens which identify the server. (Note that since CAPA
        response tag arguments are space-separated, it may be convenient
        for the IMPLEMENTATION capability argument to not contain spaces,
        so that it is a single token.)

        A server MAY include the implementation identification both in
        the welcome banner and in the IMPLEMENTATION capability.

        Clients MUST NOT modify their behavior based on the server
        implementation.  Instead the server and client should agree on a
        private extension.

The first paragraph might be useful to describe why we have this 
capability.  I think you already have language similar to paragraphs two 
and four.  I don't know if the third paragraph is really necessary.

---

From: Ken Murchison <[email-masked]>
Date: Fri, 03 Dec 2004 11:16:46 -0500

> comment field of the initial greeting.

Yes, this was the point I was trying to make.  Thank you for clarifying it.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 03 Dec 2004 08:39:18 -0800

> and see what you think then.

I'll certainly take a look, but really, I don't think it's a matter of
wording; regardless of how it's worded, it adds syntactic complexity to
the CAPABILITIES command.  Not a lot, admittedly, but I'm also not seeing
a lot of benefit for the way that I expect most clients to work.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 03 Dec 2004 08:41:16 -0800

> response with plus signs?

Bleh.  I don't want yet another delimiter and parsing problem to show up.
I'm not sure the problem is complex enough to invent even more syntax.

>> BTW, didn't Russ say that he preferred "NNTPv2" to "VERSION 2"?

I did, but also that I didn't feel that strongly about it.

> But I don't. In particular, I don't want "NNTPv2 NNTPv3" as a capability

They'd be separate lines, in the vague way I'd been thinking about the
world, for whatever it's worth.

---

From: Ken Murchison <[email-masked]>
Date: Fri, 03 Dec 2004 11:44:33 -0500

> a lot of benefit for the way that I expect most clients to work.

I propose that we put this issue to rest for the current document.  We 
have bigger fish to fry.  The WG can revisit it down the road if deemed 
necessary.

Can we can an official ruling from the chair?  ;)

---

From: Ken Murchison <[email-masked]>
Date: Fri, 03 Dec 2004 11:47:43 -0500

> world, for whatever it's worth.

That was might thought too, which would then throw my initial response 
line idea out the window.  Using the initial response line might be 
useful down the road, but not if we have to introduce syntactic cruft to 
make it happen.  Specifying that the version token(s) MUST be the first 
capability(s) in the list might be sufficient.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 3 Dec 2004 17:01:23 +0000

> have bigger fish to fry.  The WG can revisit it down the road if deemed 

<scream>
If the world [not just this list, I'm not complaining at you two] would
stop sending me emails that I need to answer, I could explain myself.
</scream>

Quick attempt at explaining the core issue follows.

If we say nothing, the WG will have potential problems revisiting the issue
in the future because clients won't be expecting new things. We need to
leave ourselves just enough space to play with. When I get three moments to
myself, I can write that minimum. Then the rest *can* be safely left,
because client authors Have Been Warned.

Remember the "capabilities in the initial response line" idea? If the
original authors of NNTP had thought far enough ahead, they'd have said
something like:

    The server MUST begin any comment with a letter or digit.
    The client MUST NOT assume this, and MUST be prepared to find any
    character present.

    Extensions to, and future versions of, this specification may put
    other information between the arguments and the comment, using a
    non-alphanumeric character to indicate its presence. Clients can
    safely ignore any such information that they do not understand.

Space for the future, you see?

---

From: Russ Allbery <[email-masked]>
Date: Fri, 03 Dec 2004 09:04:55 -0800

> stop sending me emails that I need to answer, I could explain myself.

Don't worry, I'm not going to make a final decision until you get a chance
to write something.  :)  It's cool, we can take our time to some degree.

> If we say nothing, the WG will have potential problems revisiting the
> issue in the future because clients won't be expecting new things. We
> need to leave ourselves just enough space to play with. When I get three
> moments to myself, I can write that minimum. Then the rest *can* be
> safely left, because client authors Have Been Warned.

At first glance, I don't have a problem with this basic idea.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 3 Dec 2004 17:08:58 +0000

> to write something.  :)  It's cool, we can take our time to some degree.

Thanks.

I'm a bit flustered this afternoon. I have four "need to sort out" things
going on, of which this is one, and my inbox is gaining about a megabyte
every hour (after spam filtering).

> At first glance, I don't have a problem with this basic idea.

Phew.

---

From: Ken Murchison <[email-masked]>
Date: Fri, 03 Dec 2004 12:14:07 -0500

> stop sending me emails that I need to answer, I could explain myself.

Well, your at least looking in my direction.  ;)  But I'm fine with it.

> Quick attempt at explaining the core issue follows.

I don't have a problem with your text.

---

From: Ken Murchison <[email-masked]>
Date: Fri, 03 Dec 2004 12:17:23 -0500

> every hour (after spam filtering).

Go grab yourself a pint.  :)

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 3 Dec 2004 17:22:03 +0000

> Go grab yourself a pint.  :)

That's on the schedule for 35 minutes from now.

And also for 38 minutes from now.

---

From: Ken Murchison <[email-masked]>
Date: Fri, 03 Dec 2004 12:29:52 -0500

> And also for 38 minutes from now.

Ahh, the start of a perfect rhythm for a Friday evening.

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 4 Dec 2004 19:17:42 GMT

>NEWNEWS but not GROUP, ARTICLE, etc.

For a pure suck feed using NEWNEWS, you need NEWNEWS, DATE and ARTICLE.
You might find a use for HEAD and BODY as well. But you would have no use
at all for GROUP, NEXT, POST, and indeed most other reader commands

---

From: Russ Allbery <[email-masked]>
Date: Sat, 04 Dec 2004 19:27:55 -0800

Charles Lindsey <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:

>> survey of news software, but I've never heard of a server that
>> implements NEWNEWS but not GROUP, ARTICLE, etc.

> You might find a use for HEAD and BODY as well. But you would have no
> use at all for GROUP, NEXT, POST, and indeed most other reader commands

Once again, I have never heard of such a beast.  Do you have a pointer to
such an implementation?

---

From: [email-masked] (Kai Henningsen)
Date: 05 Dec 2004 11:51:00 +0200

> 3.  Such clients are poorly implementated and should/will be selected

4. Or the client may want to work around a bug in a particular  
implementation.

MfG Kai

---

From: [email-masked] (Kai Henningsen)
Date: 05 Dec 2004 12:15:00 +0200

> And in SMTP that's not listed as free-form text, it's specific syntax.

This sounds rather confusing.

There's exactly one place in RFC 2821 where the string ESMTP is used  
outside generic text, and that is in the content of Received: lines (as a  
protocol value). That has exactly zero use for the actual message exchange  
protocol.

There's a myth going around about putting ESMTP into the 220 greeting  
line. There's never been such a rule. In fact, such a rule was discussed  
and rejected.

There's the EHLO command that a new client sends instead of HELO, always  
prepared to fall back to HELO if EHLO doesn't work; this command is also  
the CAPABILITIES command of SMTP.

The 220 greeting does have a single specified parameter, the server's  
domain name; it's specified by position just like, say, the answer to the  
GROUP command in NNTP. In fact, it's been that way since RFC 772  
(September 1980), the first draft of this new "MAIL TRANSFER PROTOCOL"  
that was to replace mail-via-FTP, before even HELO was invented. (They  
also had a baroque MRSQ "Mail Recipient Scheme Query" that was supposed to  
negotiate the sequence in which text and recipients were communicated.  
Hey, protocol negotiation in the very first draft!)

MfG Kai

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 6 Dec 2004 15:56:35 GMT

>Once again, I have never heard of such a beast.  Do you have a pointer to

I use a program called 'nntpxfer', written by Brian Kantor (UCSD) and
bundled with Stan Barber's Model NNTP implementation (and much hacked
about by myself). I had awlays assumed that other systems using the
NEWNEWS command worked similarly.

Note, it uses a standard NNTP server, but only invokes those particular
commands. But one could envisage a server cut down and optimized just to
service that particular kind of client.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 06 Dec 2004 10:08:13 -0800

>>> For a pure suck feed using NEWNEWS, you need NEWNEWS, DATE and
>>> ARTICLE.  You might find a use for HEAD and BODY as well. But you
>>> would have no use at all for GROUP, NEXT, POST, and indeed most other
>>> reader commands

>> Once again, I have never heard of such a beast.  Do you have a pointer
>> to such an implementation?

> service that particular kind of client.

So you have not heard of such a server either, you just think that one
might possibly exist.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 7 Dec 2004 14:02:44 GMT

>So you have not heard of such a server either, you just think that one

Indeed; I never claimed that such a server existed. But it should be
possible to construct one and to give a sensible set of CAPABILITES for
it. Mind you, a 'reader' server with POST inhibited and various optional
commands not implemented would probably be near enough.