Subject: [NNTP] Snapshot 4

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 18 Nov 2004 11:56:25 +0000

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>

This is the one that has the CAPABILITIES command, version numbers, and so
on. It is, I hope, the last major organisational change to the document.

There are a number of outstanding issues; when commenting, please quote the
reference number [2501] [2502] etc.

Russ, would you like me to start separate threads to discuss each of the
issues, beginning each with a brief description of the issue? That way
this thread can be left for comments on the structural changes and reports
of any typos.

Changes since 25.pre-3:
* CAPABILITIES command added - section 5.2.
* Almost all references to LIST EXTENSIONS replaced by either CAPABILITIES
  or "capability/ies" as appropriate, including in examples.
* MODE READER moves to 5.3 and has one minor edit:
  "the results of LIST EXTENSIONS MAY be different" becomes
  "the available extensions may differ".
* A new section 9 ("Deprecated commands"). If we decide to drop MODE READER,
  it will move there. Note that all section numbers from 9 onwards have
  increased by one; in particular, ABNF is now 10 and Security
  Considerations is now 12.
* LIST EXTENSIONS moved from 5.3 to 9.1 and completely rewritten; it is now
  defined in terms of CAPABILITIES.
* 7.6.3 minor wording changes.
* 7.6.4.3 fourth example: I can't believe that NOBODY spotted the missing
  "not".
* 8.1 assorted wording changes to interact better with the capability
  concept; consequential changes in appendix D.
* 10 contains assorted new syntax for CAPABILITIES.
* 10.4 and 12.6 title change.
* New ABNF entity "token = 1*P-CHAR"; this represents any valid sequence
  of ASCII/UTF-8 printable characters (but not space, TAB, or controls).
* Separator between arguments on an extension-descriptor (and indeed on
  all capability lines) is now WS rather than SPA (thus allowing tabs).
* Appendix C: new code 101 and change to description of 402.

-- 
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: "Charles Lindsey" <[email-masked]>
Date: Fri, 19 Nov 2004 14:32:48 GMT

>* CAPABILITIES command added - section 5.2.

For the record, I would prefer "LIST CAPABILITIES"

>  defined in terms of CAPABILITIES.

Do we actually need a LIST EXTENSIONS command at all? Other than to say it
is an obsolete version of [LIST] CAPABILITIES that may be encountered in a
few servers.

-- 
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: Fri, 26 Nov 2004 15:33:33 -0500

> reference number [2501] [2502] etc.

General comments:

- I still don't understand the reasoning for the '_' used in the core 
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).

Outstanding issues:

2501:  I personally don't care if an implementation supports more than 
the relevant minimal commands.  However, if this does occur, then we're 
back to a situation of not knowing what commands a server supports. 
Perhaps if a transit-only server also supports NEWNEWS, then it 
advertises "_TRANSIT NEWNEWS".  Likewise if a reader-only server also 
supports IHAVE, then it advertises "_READER IHAVE".

2502:  Per 3.2.1 paragraph 2, it would seem that 500 is the correct 
response for "fails to implement.  I definitely don't think we want to 
use 502 since it has permanent failure connotations (i.e. the closing of 
the connection business).  I'd be happy with 503 however.

2504:  I think 401 is a cleaner solution regardless of other issues.

2505:  I thought we had already decided that all of this "negative 
capability" business was too much.  I'm opposed to this proposal.

2506:  I don't see the point of a new 6xx response.  How would a client 
ever find itself in such a situation?   All existing commands have well 
defined responses, so the client MUST know when to expect a multi-line 
response.  If the client gets an unexpected multi-line response, then it 
probably issued a command that it doesn't support, and gets what it 
deserves.  I'm in favor or removing Appendix A from the draft.

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.

- May I suggest 'IMPLEMENTATION' instead of '_SERVER'.  POP3 uses the 
former and seems to be a more descriptive name.

- I disagree with the statement that the _LIST capability "MUST NOT 
include variants defined by extensions".  I discuss this more below.

LIST:

Like Charles, I'd like to see LIST defined in general terms and all of 
the variants (whether mandatory, optional or extension) described within 
this framework.  More specifically, I think the discussion of LIST 
should start with most of the text from 7.6.4.  Perhaps it should be 
defined as more generally as 'LIST [ keyword *( WSP argument ) ]'.  This 
would allow LIST HEADERS and LIST OVERVIEW.FMT to be compliant with the 
syntax.

Then the mandatory variants (ACTIVE and NEWSGROUPS) can be discussed 
within this framework followed by the optional variants (ACTIVE.TIMES 
and DISTRIB.PATS).  Charles suggested that *all* LIST variants should be 
advertised by the _LIST (or hopefully LIST) capability.  I'm open to 
this or continuing to have only the optional and extension variants 
advertised.  I'm fine with either choice.

Regardless, I'd like to see the optional and extension variants use the 
same _LIST (or LIST) capability.  They are all defined under the same 
framework anyways, so having two different capabilities doesn't seem to 
make any sense to me.  If it makes it easier to make the optional 
variants an extension, then I guess I'm in favor of that.

LIST EXTENSIONS:

- So is LIST EXTENSIONS supposed to list *all* extensions or just legacy 
extensions?  How many clients currently use LIST EXTENSIONS, and which 
servers advertise which extensions?

- I don't see any point in LIST EXTENSIONS advertising new extensions, 
especially those defined in this draft (e.g. OVER or HDR).  If a client 
is aware of OVER or HDR as defined in this draft, then they damn well be 
aware of CAPABILITIES.

-- 
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: Sat, 27 Nov 2004 11:12:39 -0500

> reference number [2501] [2502] etc.

Missed some outstanding issues in my previous post:

2507:  I don't think it needs to be mandatory, but general/reader 
servers SHOULD implement it (at least as a no-op) and always return 
200/201.  Transit-only servers can probably return whatever code 
corresponds to "unimplemented" (500/503).

2508:  Is the wildmat allowed by some servers and not by others?  We 
should just specify whether ACTIVE.TIMES accepts a wildmat or not, 
instead of leaving it as optional.  That way this issue is moot.

2509:  Doesn't matter to me, but this would be an easy change since this 
command is newly defined by this document.

2510:  For legacy reasons, this might be difficult.  Servers will 
probably support it anyways for XOVER clients, so does it make sense to 
have two commands which return the same info?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 29 Nov 2004 08:31:03 +0000

>     <http://www.davros.org/nntp-texts/draft25.pre-4.html>

In the absence of any view for or against, I'm going to start separate
threads for each of the issues in this draft. I'll feed existing comments
into those threads.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 29 Nov 2004 08:37:33 +0000

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

> is an obsolete version of [LIST] CAPABILITIES that may be encountered in a

If we are going to say anything about it at all, let's give it a proper
specification. It's a lack of proper specifications that have caused the
previous messes.

As to whether we need it at all, I think we do to provide a bridge between
v2 servers and v1 clients.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 29 Nov 2004 08:43:54 +0000

Issue: should LIST HEADERS be renamed as something else, since it doesn't
fit with much of the other LIST structure?

> command is newly defined by this document.

I'm in favour of changing it. Any objectors?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 29 Nov 2004 08:48:20 +0000

Issue: should LIST OVERVIEW.FMT be renamed as something else?

> have two commands which return the same info?

Well, we could remove some of the warts. But I agree that it's perhaps less
compelling than renaming LIST HEADERS.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 29 Nov 2004 09:15:59 +0000

Issue: if a server advertises itself as transit-only, should it be allowed
to implement some of the reader-only commands or not?

> supports IHAVE, then it advertises "_READER IHAVE".

One problem is that, as you say, we're back to a situation of not knowing
what commands a server supports.

Another problem is that we're creating lots and lots of different subsets
of NNTP. There's a reasonable amount of logic in separating transit and
reader functionality, but do we really want to go beyond that? Do we want
to have lots of different subsets so that you can never be sure what is and
isn't available.

One thing to note is the distinct asymmetry between transit-only and
reader-only. There is only one transit command in the core: IHAVE. On the
other hand, there are 12 different reader commands, giving 4095 possible
combinations. And it's worse than that: could a server implement everything
except GROUP, say? And then only implement the message-ID versions of
ARTICLE etc? This way, I think, lies madness.

Thinking it through, I think we need to decide exactly what subsets we
allow and forbid anything else. Currently we have five cases:
    transit-only:            general commands plus IHAVE
    reader-only no posting:  all commands except IHAVE and POST
    reader-only:             all commands except IHAVE
    general-use no posting:  all commands except POST
    general-use:             all commands
Is this sufficient?

If not, what further subsets do we really need?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 29 Nov 2004 09:26:17 +0000

Issue: what response code should be returned for IHAVE with a reader-only
server, or reader commands (e.g. ARTICLE) with a transit-only server?

> the connection business).  I'd be happy with 503 however.

I'm deliberately trying to distinguish "IHAVE on a reader-only server" from
"unimplemented command". In previous drafts, IHAVE was a mandatory command
- though you shouldn't use it after MODE READER - and so 500 was
inappropriate. I feel that that hasn't changed.

I believe we all have the mental model of a "server site". Some connections
are transit ones and others are reader ones, but they're all connections to
the same site and, in principle, both are available at every site. Therefore
if you have a reader connection and want to do IHAVE, it's not that the
command isn't available but, rather, that you have the wrong connection. The
502 response code means "you can't do this without appropriate authority,
and you can't get that authority on this connection" and I think this is
the right one.

I accept, though, that it does to some extent come down to how we see
things structured. As with 2501, is this one protocol used in two different
ways, or is it two protocols that happen to have some things in common?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 29 Nov 2004 09:53:03 +0000

Issue: appendix A says that 6xx response codes should be used for new
multi-line responses. Do we do this or drop the appendix?

Ken Murchison said:
> deserves.

You're assuming that the results parsing is tied in tightly with the bit of
code that issues the specific command. In other words, where the pseudo
code is along the lines of:

    sprintf (command, "ARTICLE <%s>", message_id);
    send_command (command);
    switch (get_response_code ())
    {
    case 220:
        while (get_line (buffer), strcmp (buffer, ".") != 0)
        {
            if (buffer [0] == '.')
                append_to_saved_copy (buffer + 1);
            else
                append_to_saved_copy (buffer);
        }
        break;

    case 430: failed (/* no such article */); break;
    case 412:
    case 420:
    case 423: error ("Invalid response code in this context"); break;
    // etc.
    }

then you're right, there's no benefit to this. On the other hand, if you
have a separate module for handling the connection, something like:

    sprintf (command, "ARTICLE <%s>", message_id);
    response = do_command (command, buffer);
    switch (get_response_code ())
    {
    case 220: save_article (message_id, buffer); break;
    case 430: failed (/* no such article */); break;
    case 412:
    case 420:
    case 423: error ("Invalid response code in this context"); break;
    // etc.
    }

then having a predictable protocol is a good idea. This sort of thing,
after all, is why we require all response codes to have a fixed number of
arguments. Allowing client code to distinguish single- and multi-line
responses just from the response code is more of the same.

> I'm in favor or removing Appendix A from the draft.

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.

Other views?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 29 Nov 2004 10:02:44 +0000

Issue: whither MODE READER and mode-switching servers?

We need to decide once and for all what we are going to do with MODE READER
and the idea of completely switching modes in the middle of a session.

Option A: we retain the idea of mode-switching servers. The MODE READER
command is significant on such servers; before it is issued, reader
commands aren't available, while afterwards transit commands might not be
available.

Option B: we forbid mode-switching in NNTPv2, requiring each connection to
decide at the beginning whether it is transit, reader, or general-use; once
the decision is made, it's stuck with it. MODE READER becomes a deprecated
command that does nothing that CAPABILITIES doesn't.

Whichever we pick will require a fair amount of wording to be sorted out,
so I'd like to start ASAP.

In an earlier thread Russ seemed unhappy to make this decision, so who is
going to?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 29 Nov 2004 10:11:20 +0000

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.

If we get rid of the idea of mode-switching servers, this becomes moot.

Ken is in favour of 401.

---

From: "maurizio codogno" <[email-masked]>
Date: Mon, 29 Nov 2004 10:43:52 +0000

>and the idea of completely switching modes in the middle of a session.

as a plain user, I'd prefer option B. I never managed to have a 
real session which changes its mode, anyway :-)

ciao, .mau.

---

From: "Howard Swinehart" <[email-masked]>
Date: Mon, 29 Nov 2004 08:39:02 -0500

From: "Clive D.W. Feather" <[email-masked]>
> and the idea of completely switching modes in the middle of a session.

B (forbid mode switching).

We're only talking about INN, right?  Correct me if I'm wrong, but INN can 
be configured to use ports instead of MODE READER without any code changes 
so even INN isn't impacted much.

Allowing mode switching would preserve a command that no one likes or wants.

---

From: "Andrew - Supernews" <[email-masked]>
Date: Mon, 29 Nov 2004 16:14:52 +0000

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

 Clive> Issue: should LIST HEADERS be renamed as something else, since
 Clive> it doesn't fit with much of the other LIST structure?

No. Leave it alone.

Firstly, this is entirely too late in the process to start pissing
around changing stuff unnecessarily. Secondly, LIST is _exactly_
the right place to put any infrequently-used command which returns
a simple line-oriented result. Putting them all together in one
place actually makes life simpler, compared to adding a bunch of
random cruft as new top-level commands.

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

---

From: "Andrew - Supernews" <[email-masked]>
Date: Mon, 29 Nov 2004 16:21:23 +0000

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

 Clive> Issue: if a server advertises itself as transit-only, should
 Clive> it be allowed to implement some of the reader-only commands or
 Clive> not?

Yes. Many deployed transit servers implement some subset of reader
commands. The fact that there's no way to tell what subset is
completely irrelevent, because these commands are used only within the
context of a single site or cluster and interoperability is never a
concern.

If the spec says "MUST NOT implement any other commands" it will be
ignored. period.

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

---

From: "Andrew - Supernews" <[email-masked]>
Date: Mon, 29 Nov 2004 16:33:43 +0000

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

 Clive> Issue: appendix A says that 6xx response codes should be used
 Clive> for new multi-line responses. Do we do this or drop the
 Clive> appendix?

Drop it.

 >> 2506: I don't see the point of a new 6xx response.  How would a
 >> client ever find itself in such a situation?  All existing
 >> commands have well defined responses, so the client MUST know when
 >> to expect a multi-line response.  If the client gets an unexpected
 >> multi-line response, then it probably issued a command that it
 >> doesn't support, and gets what it deserves.

 Clive> You're assuming that the results parsing is tied in tightly
 Clive> with the bit of code that issues the specific command.

It is not possible, with the protocol as it stands, to parse the
results of a command without knowing which command was issued. This is
an unfortunate wart, but it's not fixable without breaking backward
compatibility for LISTGROUP, which _is_ used reasonably widely by
clients.

In practice, the pseudo-code for clients is more usually along the
lines of:

    sprintf(command, "ARTICLE %s", message-id);
    response_code = issue_command_multiline(command);
    if response_code is 2xx then process the multiline response...

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

---

From: Ken Murchison <[email-masked]>
Date: Mon, 29 Nov 2004 13:03:38 -0500

> In an earlier thread Russ seemed unhappy to make this decision, so who is

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.  So, even if INN removes MODE READER (leaving no way 
to switch modes on a single port server), how realistic is it that 
existing mode-switching sites will reconfigure their server(s) to use 
port 433 for transit?  My (uneducated) guess is that people would just 
patch INN to add MODE READER support back in.

It seems to me that this is something that we can try to change in the 
protocol, but it will be ignored.  Clients will *have* to support MODE 
READER for the foreseeable future and servers will probably have to 
support it as a no-op.

In a nutshell, I'd like to see MODE READER go away, but I won't be 
crushed if it remains in the protocol.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 30 Nov 2004 09:17:39 +0000

Issue: what do we do with the MODE READER command? Make it optional on
servers that aren't mode-switching?

Ken Murchison said:
> 200/201.

Personally I think it should be mandatory. The effort of returning a fixed
code isn't exactly big.

> Transit-only servers can probably return whatever code 

502 - see other discussions.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 30 Nov 2004 09:33:51 +0000

Issue: should we indicate in the CAPABILITES output whether or not each
keyword accepts a wildmat?

> instead of leaving it as optional.  That way this issue is moot.

I think you've misunderstood my point.

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?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 30 Nov 2004 09:51:10 +0000

Issue: do we provide a way for CAPABILITIES to advertise features that
aren't available right now but could be, or have been.

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

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 30 Nov 2004 11:04:13 GMT

>standpoint does it really matter?  Isn't the cat already out of the bag 

I think we have to stick with A, simply because that is the way INN does
it and it isn't going to go away.

By all means pour cold water on it, deprecate it, threaten to remove it in
the next standard. But it is not going to go away, which means the command
still has to remain with the meaning as outlined above.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 30 Nov 2004 10:00:51 -0500

> make clients suck it and see, or do we provide the information in the

Yuck.  If a client chooses to use a private extension, it better damn 
well know what the syntax is ahead of time (preferably because its 
documented somewhere).  I don't think we want to get into specifying 
syntax via protocol, just what options are available.  IMO, this is a 
solution looking for a problem.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 30 Nov 2004 20:07:58 -0800

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

>> Do we actually need a LIST EXTENSIONS command at all? Other than to say
>> it is an obsolete version of [LIST] CAPABILITIES that may be
>> encountered in a few servers.

> v2 servers and v1 clients.

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.

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

---

From: Russ Allbery <[email-masked]>
Date: Tue, 30 Nov 2004 20:09:37 -0800

> threads for each of the issues in this draft. I'll feed existing comments

Thanks; this is what I would have requested had I been current on the
working group.  (I'll try to remain more current in the future.)

---

From: Russ Allbery <[email-masked]>
Date: Tue, 30 Nov 2004 20:10:15 -0800

> random cruft as new top-level commands.

I'm with Andrew on this.  It seems to me like it fits perfectly with the
rest of the LIST commands.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 30 Nov 2004 20:10:37 -0800

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

---

From: Russ Allbery <[email-masked]>
Date: Tue, 30 Nov 2004 20:13:31 -0800

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

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

---

From: Russ Allbery <[email-masked]>
Date: Tue, 30 Nov 2004 20:15:00 -0800

> multi-line responses. Do we do this or drop the appendix?

I think we should drop it.

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

---

From: Russ Allbery <[email-masked]>
Date: Tue, 30 Nov 2004 20:18:41 -0800

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

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

> Ken is in favour of 401.

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

---

From: Russ Allbery <[email-masked]>
Date: Tue, 30 Nov 2004 20:19:20 -0800

> Personally I think it should be mandatory. The effort of returning a fixed

If we keep it, I think it should be mandatory to implement; as you say,
returning a fixed response code is trivial.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 30 Nov 2004 20:21:01 -0800

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

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.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 30 Nov 2004 20:27:51 -0800

> *isn't* available - and goes directly against a MUST in the core

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.

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

---

From: Russ Allbery <[email-masked]>
Date: Tue, 30 Nov 2004 20:42:33 -0800

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

In the initial connection section, I would mention explicitly that
CAPABILITIES will return far more useful information about whether the
client can post than the initial response code does (in particular, it
will change appropriately based on the authentication state).  The initial
response indicator for posting vs. read-only has been a disaster in
practice, and servers have to return 200 if there is even any possibility
that a client might be able to post after authentication, since otherwise
some clients will give up and not even try.  The expressiveness is just
too limited.

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 don't see any point in the _SERVER line.  Traditionally, this
information is returned in the initial greeting.  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.