Subject: [NNTP] Misc changes

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 11 Apr 2005 22:14:25 +0100

A couple of weeks ago we were discussing a number of changes, particularly
to capabilities but possibly also to other things. I don't think I made any
changes to the draft because I didn't think any of them had converged.

So can anyone (Russ?) remember what they were and where they got to? My
memory lists the following, but I don't claim it's complete:

(1) Placeholder for capability information in responses. I think we settled
that this can be an extension requested by the client - the only thing this
loses is the ability to put capability information in the initial greeting.

(2) Make POST a separate capability. I think this was agreed.

(3) Make LISTGROUP a separate capability. I remember being against this.

(4) A range facility for LISTGROUP. From memory there was significant
disagreement as to the semantics.

-- 
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: Russ Allbery <[email-masked]>
Date: Mon, 11 Apr 2005 14:28:46 -0700

> (1) Placeholder for capability information in responses. I think we
> settled that this can be an extension requested by the client - the only
> thing this loses is the ability to put capability information in the
> initial greeting.

I agree.  I think we aren't going to make any changes in this area.

> (2) Make POST a separate capability. I think this was agreed.

Yes.

> disagreement as to the semantics.

I'm going to make one more shot at writing up a proposal for how to change
LISTGROUP and see if we can get consensus.  If not, we'll drop it,
although I think we should still seriously consider making LISTGROUP
mandatory.

The other item that was raised was adding a capability for NEWNEWS.  I
agree with the feeling that servers should really provide it, but given
the number that choose not to, maybe we shouldn't be dictating policy in
the standard to quite that degree.  It does have the problem that a
syntactically proper NEWNEWS command can take a huge amount of resources
without any realistic way of reducing those resources:

    NEWNEWS * 19700101 000000 GMT

something that I don't believe is shared by any other mandatory command.
It's not that servers won't implement it at all, but rather that they may
not want to make it available to general (unautheticated, lower-paying,
whatever) clients.

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

---

From: Ken Murchison <[email-masked]>
Date: Tue, 12 Apr 2005 09:52:52 -0400

> not want to make it available to general (unautheticated, lower-paying,

Here's my $.02:

I think both of these fall into the gray area of trying to document what 
we feel is the proper "core" functionality vs. what is actually done in 
practice.  In both of these cases it think we need to lean towards 
existing deployed behavior.  IMO, both of these changes can be made 
without breaking existing clients.

If virtually all deployed servers provide LISTGROUP then we can/should 
make it mandatory because virtually all clients will depend on it 
anyways (whether its advertised or not).  With respect to LISTGROUP 
<range> functionality, I think an argument can be made either way for a 
separate capability.  Since this is v2 of NNTP we *can* mandate that a 
v2 server provide LISTGROUP <range>.  On the other hand, if providing 
this functionality will be too difficult for some server architectures, 
then we should make it optional.

Regardless of the fact that NEWNEWS has always been mandatory, if a 
large portion of deployed servers/admins disable it, we should make it 
optional and give it its own capability.

-- 
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: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 12 Apr 2005 22:37:23 +0100

> although I think we should still seriously consider making LISTGROUP

Mandatory if READER is advertised, or mandatory full stop? I would be happy
with the former but not the latter (it makes no sense without the rest of
the READER group).

---

From: Russ Allbery <[email-masked]>
Date: Tue, 12 Apr 2005 14:39:20 -0700

>> I'm going to make one more shot at writing up a proposal for how to
>> change LISTGROUP and see if we can get consensus.  If not, we'll drop
>> it, although I think we should still seriously consider making
>> LISTGROUP mandatory.

> Mandatory if READER is advertised, or mandatory full stop?

If READER is advertised.  Sorry for the lack of clarity.

---

From: [email-masked] (Peter Robinson)
Date: Tue, 12 Apr 2005 23:22:17 +0100

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

[snips]

> > (2) Make POST a separate capability. I think this was agreed.

Excellent.

> the standard to quite that degree.

My opinion is that NEWNEWS should be given its own CAPABILITY.

Despite RFC977, some servers don't implement NEWNEWS because it's seen
as too expensive (or for some other reason).  That's not going to change
just because this new spec says it should.  Surely a large part of the
purpose of this group is to document current behaviour, including
(especially?) where it diverges from RFC977.

Now we've gone to all the trouble of adding a beautiful new CAPABILITIES
mechanism, it seems to me to be madness to preserve the current
situation where a client author can diligently read the specs, design
and test his algorithm, ship it, and only then discover that it doesn't
work with N% of servers despite being completely correct wrt the specs.

Regards,

Peter

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 25 Apr 2005 09:51:08 +0100

>> (2) Make POST a separate capability. I think this was agreed.

Done.

> something that I don't believe is shared by any other mandatory command.

I'm not sure that's really unique; after all, a HDR or OVER on a large
group can also produce huge amounts of output.

I don't like the idea of making NEWNEWS optional, but I'll leave it to you
to make the final call.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 25 Apr 2005 10:09:35 -0700

>> the number that choose not to, maybe we shouldn't be dictating policy
>> in the standard to quite that degree.  It does have the problem that a
>> syntactically proper NEWNEWS command can take a huge amount of
>> resources without any realistic way of reducing those resources:
>> 

> group can also produce huge amounts of output.

Yeah, but it's really not the same; that at least is limited to a single
group, so you can use something like sendfile and you're mostly just
eating bandwidth.

> I don't like the idea of making NEWNEWS optional, but I'll leave it to
> you to make the final call.

Well, right now it looks like a rough consensus to me, modulo your
concerns.  If anyone other than Clive dislikes giving NEWNEWS its own
capability (and hence making it optional), please speak up; if not, I'm
going to say that there's a consensus to do so.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 26 Apr 2005 10:05:03 GMT

>I don't like the idea of making NEWNEWS optional, but I'll leave it to you

I don't like the idea of making NEWNEWS optional.

I do like the idea of introducing a NEWNEWS capability (because we _know_
some servers won't implement it, optional or not).

Is there some way we can both have this cake and eat it? For example,
could we say "The NEWNEWS command SHOULD be provided"?

-- 
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: Russ Allbery <[email-masked]>
Date: Tue, 26 Apr 2005 11:45:23 -0700

> could we say "The NEWNEWS command SHOULD be provided"?

I have kind of a bleh feeling about that, since we don't say that about
other things that are even more core to the protocol (POST, for instance).

---

From: "Jeffrey M. Vinocur" <[email-masked]>
Date: Tue, 26 Apr 2005 21:57:17 -0400

>> I don't like the idea of making NEWNEWS optional.

Can you say why this is, concretely?

> other things that are even more core to the protocol (POST, for 

I agree with Russ here.  It's not a protocol issue by any means, and 
since we all know that some servers aren't going to provide it no 
matter what we say, client authors are still going to have to consider 
that possibility (and work around it or accept reduced functionality).

I would be fine with the document making an advisory statement to 
implementors that encourages implementation of NEWNEWS (and explains 
that it became optional only because, in the past, it was woefully 
inefficient).

-- 
Jeffrey M. Vinocur
[email-masked]

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 27 Apr 2005 06:57:50 +0100

> that possibility (and work around it or accept reduced functionality).

Okay, sitting back and looking again I suppose that is the case.

* Should it be NEWNEWS or READER NEWNEWS (currently NEWNEWS is in the
  READER bundle of commands)?
* What do we want to do about NEWGROUPS (currently also in the READER
  bundle)?

> that it became optional only because, in the past, it was woefully 

Would you care to do some words? I'm having trouble crafting something
right now.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 27 Apr 2005 10:05:36 GMT

>Can you say why this is, concretely?

Because I use it, and get annoyed by servers that don't provide it. So I
would still like to be able to accuse such servers of non-compliance :-( .

>that it became optional only because, in the past, it was woefully 

Yes, I could go along with that.

---

From: Russ Allbery <[email-masked]>
Date: Wed, 27 Apr 2005 11:16:23 -0700

>   READER bundle of commands)?

READER NEWNEWS, I think, since the resulting information is used in
conjunction with ARTICLE, but that's just a first impression.

> * What do we want to do about NEWGROUPS (currently also in the READER

I'd leave it alone.

---

From: Ade Lovett <[email-masked]>
Date: Wed, 27 Apr 2005 21:24:49 -0700

Charles Lindsey wrote:
> would still like to be able to accuse such servers of non-compliance :-(

As one of the originators of a NEWNEWS-that-didn't-suck, I'd like
nothing better too.  However there are way more interesting battles to
fight.  Too many people who should know better, on both the server- and
client- side of the equation, don't give a rats arse about compliance.

Indeed, having it as an optional capability looks "better", since if you
do implement NEWNEWS, you get the bragging rights of specifically adding
it in to the capabilities list which will be somewhat more visible to
the old school that use it, who will also tend to be the ones that run
telnet sessions to nn{t,r}p hosts and type 'list capabilities' by hand,
rather than have some whizzbang GUI process it for them.

I also believe that it should be a capability in its own right (ie:
'NEWNEWS' instead of 'READER NEWNEWS') -- there's no intrinsic reason
why the list of message IDs generated would be used for only reader
purposes -- ditto for NEWGROUPS, whilst the primary reason is
undoubtedly for client newsreaders, it's not solely a reader command,
and thus should not be compartmentalized as such.

> Yes, I could go along with that.

Honestly, I don't see the need.  The vast majority of systems are going
to continue to not care about NEWNEWS (which is fine).  Having it
mentioned in the standard capability text and then the formal
description is plenty, imo.

There's no other places where the efficiency, or lack thereof, of
commands, are mentioned.  NEWNEWS does not need to be special in this
regard.  With the right conditions, it's pretty trivial to nadger a
certain piece of well-known commercial Usenet server software with
nothing more than GROUP, LAST, and NEXT...

-aDe

---

From: Ken Murchison <[email-masked]>
Date: Fri, 29 Apr 2005 09:41:55 -0400

> and thus should not be compartmentalized as such.

Agreed.  Didn't we use the same logic for making "POST" its own 
capability rather than an argument to "READER"?

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 29 Apr 2005 11:48:41 GMT

>and thus should not be compartmentalized as such.

Hmmm! If you are a pure transit server, then the only use for NEWNEWS
would appear to be for discovering what articles the server has already
got, to avoid sending them with TAKETHIS. Does anybody actually use it
that way? ISTM that is what IHAVE was meant for.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 29 Apr 2005 09:21:55 -0700

> and thus should not be compartmentalized as such.

I would prefer not to fiddle with NEWGROUPS at this point (it doesn't have
its own capability).  We have to stop at some point.

Okay, I wanted to see if anyone felt that way about NEWNEWS.  I'm happy to
have it be its own capability.