Subject: [NNTP] Revisiting POST as a separate capability

From: Russ Allbery <[email-masked]>
Date: Tue, 22 Mar 2005 15:06:19 -0800

Mark found POST and LISTGROUP as READER modifiers but OVER and HDR as
separate capabilities confusing.  After tracing the discussion on this, we
did that because we didn't want POST as a separate capability with a
dependency on READER that wasn't represented in the protocol.

I'd like to take another step back from that.  Does anyone remember why we
felt like advertising POST without READER didn't make any sense?  I seem
to recall that we had that discussion, but I can't find it in the mailing
list archives (it may have been part of that huge thread about the initial
LIST EXTENSIONS rethink when we weren't changing subject headers).  I'm
not aware of any servers currently that allow POST without the READER
commands intentionally, but it's certainly a sensible configuration and I
believe possible in INN.

Could we talk this over again and make sure we understand why we're doing
things this way?  It looks a bit simpler and orthogonal to have all of
these capabilities be independent, even if we have to insert some language
about how advertising LISTGROUP without READER doesn't make any sense.

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 23 Mar 2005 11:57:08 GMT

>commands intentionally, but it's certainly a sensible configuration and I

Surely the point is that a server that does not advertise READER is a
transit-only server, and transit servers just don't do POST (they do
IHAVE, or TAKETHIS, or whatever).

So leave it be.

-- 
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: Wed, 23 Mar 2005 11:20:02 -0800

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

>> I'd like to take another step back from that.  Does anyone remember why
>> we felt like advertising POST without READER didn't make any sense?  I
>> seem to recall that we had that discussion, but I can't find it in the
>> mailing list archives (it may have been part of that huge thread about
>> the initial LIST EXTENSIONS rethink when we weren't changing subject
>> headers).  I'm not aware of any servers currently that allow POST
>> without the READER commands intentionally, but it's certainly a
>> sensible configuration and I believe possible in INN.

> transit-only server,

Why would you assume that?  That's certainly one possible use for it, but
all that not advertising READER means is that the reader commands
(ARTICLE, GROUP, etc.) are not supported.

There's nothing inconsistent about supporting POST without supporting the
reader commands.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 23 Mar 2005 14:48:07 -0500

> about how advertising LISTGROUP without READER doesn't make any sense.

I'm guessing the distinction was made because POST and LISTGROUP we're 
once considered optional commands, where OVER and HDR were considered 
extensions.

I have no problem giving POST and LISTGROUP their own capabilities.  In 
fact, didn't LISTGROUP have its own until someone (perhaps me) suggsted 
otherwise?

-- 
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: Thu, 24 Mar 2005 09:25:51 +0000

> There's nothing inconsistent about supporting POST without supporting the

There's nothing technically inconsistent, no.

However, we currently have two commands that do almost the same thing:
POST and IHAVE. The only protocol-level difference (except that different
response codes are used) is that the latter specifies a message-id on the
command line and the former does not.

The *reason* for having these two separate commands is, as we say, that one
is intended to signal "new article" and the other "relayed article". The
former is very unlikely to happen unless the client is also doing
newsreading. Yes, there's nothing inconsistent about POST without READER,
but do we want to encourage it? I would suggest that we don't.

Looking back through the archives, it seems that we decided that this was
probably the best choice. I don't see a good reason to change it.

-- 
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, 24 Mar 2005 09:30:19 +0000

> fact, didn't LISTGROUP have its own until someone (perhaps me) suggsted 

<http://lists.eyrie.org/pipermail/ietf-nntp/2005-January/000806.html>
and work both ways along the thread.

OVER and HDR can be used by message-ID, so it's practical to use them
on a server that doesn't provide READER commands. There's also the problem
that OVER has an argument.

LISTGROUP only makes sense as part of READER.

We didn't want servers to *advertise* POST without READER, even if they
implement it.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 24 Mar 2005 10:35:39 -0800

> POST and IHAVE. The only protocol-level difference (except that
> different response codes are used) is that the latter specifies a
> message-id on the command line and the former does not.

The difference in practice is that POST inserts trace information, while
IHAVE presumes that the remote host is trusted and modifies only the Path.
(I know you know this, but I want to make sure it's part of the
discussion.)

> The *reason* for having these two separate commands is, as we say, that
> one is intended to signal "new article" and the other "relayed
> article". The former is very unlikely to happen unless the client is
> also doing newsreading.

I don't think this is the case.  I can name a half-dozen processes just
off the top of my head that only need POST access to my server, not read
access, but are still posting new articles.  All of the moderators I
provide an injection point for, for example (although they're currently
using IHAVE, that's not completely correct in many cases).

> Yes, there's nothing inconsistent about POST without READER, but do we
> want to encourage it? I would suggest that we don't.

I don't think this constitutes encouragement, just making it possible.
After thinking about this for a while, I do think we should make it
possible (although it's not sufficiently important enough to me to argue
against a consensus if people disagree).

---

From: Ken Murchison <[email-masked]>
Date: Thu, 24 Mar 2005 13:57:47 -0500

> against a consensus if people disagree).

I'm perfectly happy to separate POST from READER.

---

From: [email-masked] (Peter Robinson)
Date: Thu, 24 Mar 2005 23:29:46 +0000

> dependency on READER that wasn't represented in the protocol.

I see no good reason to outlaw POST-without-READER in either the
protocol or the text.  I think that CAPABILITY options should be avoided
where possible and (because?) different capabilities should be
independent where possible.  Allowing POST-without-READER to be
implemented but not advertised is worse if anything, since it encourages
the old trial and error approach if it gets used at all.

[...]

> It looks a bit simpler and orthogonal to have all of

I agree.

Peter

---

From: "Jeffrey M. Vinocur" <[email-masked]>
Date: Thu, 24 Mar 2005 17:49:52 -0500

> I don't think this constitutes encouragement, just making it possible.

Why don't we want to encourage it, anyway?

> against a consensus if people disagree).

Perhaps I'll be convinced by the debate, but at the moment I don't see 
any reason to forbid it.  (I mean, if we did forbid it, a server that 
theoretically wanted to do this could simply provide hardcoded versions 
of READER commands that return responses consistent with a server 
having no groups -- and a client could still try to post if it wanted 
to.  Sure, it's a strange thing to do, but nothing in the -protocol- 
makes me think it's a problem.)

-- 
Jeffrey M. Vinocur
[email-masked]

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 25 Mar 2005 08:57:56 +0000

> IHAVE presumes that the remote host is trusted and modifies only the Path.

Right. But those aren't *protocol* issues; they're part of what I described
as:

>> article".

I then wrote:

>> The former is very unlikely to happen unless the client is
>> also doing newsreading.
> I don't think this is the case.

This is the crux of the matter.

> I can name a half-dozen processes just

Hmm, moderation injection point is a case I hadn't thought of.

> against a consensus if people disagree).

I'm still a little bit uncomfortable but not enough to argue against a
consensus on your side. I think that means we cancel each other out :-)

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 25 Mar 2005 08:58:59 +0000

Jeffrey M. Vinocur said:
> (I mean, if we did forbid it, a server that 
> to.

For that matter, just because READER (and therefore POST) isn't advertised
doesn't stop a server implementing POST.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 25 Mar 2005 09:01:30 +0000

Peter Robinson said:
> independent where possible.

But different capabilities *aren't* always independent.

I can see the arguments for POST without READER. I'm not yet convinced but,
as I said a moment ago, if the consensus is to allow it then I won't feel
particularly bothered.

>> about how advertising LISTGROUP without READER doesn't make any sense.

But here I don't. Having LISTGROUP without READER doesn't make sense.
Therefore it is far better to implement the restriction by making LISTGROUP
be an argument to the READER capability than to have to special-case it in
the text.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 25 Mar 2005 12:09:09 GMT

>I'm perfectly happy to separate POST from READER.

I would be somewhat unhappy.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 25 Mar 2005 09:58:13 -0800

>> (I mean, if we did forbid it, a server that theoretically wanted to do
>> this could simply provide hardcoded versions of READER commands that
>> return responses consistent with a server having no groups -- and a
>> client could still try to post if it wanted to.

> For that matter, just because READER (and therefore POST) isn't
> advertised doesn't stop a server implementing POST.

Right, but it means that you're not supposed to use it unless you have a
special arrangement with the server.  That means that generic software
libraries may be confused by such a negotiation, etc.

The case that actually sparked this was Mark Crispin's case of having a
post-only server and using IMAP to do all article reading, but I can think
of a number of other cases.  To take another example, the mail to news
gateway that I run for a large number of Stanford groups has no need to
read any group, but I would prefer that it post messages with POST to get
stronger syntax checking.  A third example of a client that only needs to
post but not read would be a monitoring system that keeps a trace of
alerts in a local newsgroup, another thing that we do here at Stanford.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 25 Mar 2005 09:59:33 -0800

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

> Therefore it is far better to implement the restriction by making
> LISTGROUP be an argument to the READER capability than to have to
> special-case it in the text.

The problem with this is that if we ever want to add the range argument to
LISTGROUP later on (since it's looking like specifying this may involve
more details than we want to deal with at this stage), you end up with a
very ugly way of specifying that in capabilities.

It also then looks odd.  We would be leaving LISTGROUP as the only command
capability that isn't its own line in CAPABILITIES.  (That's more of an
aesthetic argument, though, and isn't as strong.)

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 25 Mar 2005 18:10:36 +0000

> very ugly way of specifying that in capabilities.

Slightly ugly, yes. But that's still better than the alternative in my
opinion.

Anyway, I thought the consensus was for making LISTGROUP mandatory.

> aesthetic argument, though, and isn't as strong.)

It's not at all strong - it's simply that this is the only case where one
command requires another to be present. If, say, BODY was to be optional
we'd have the same situation.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 28 Mar 2005 10:27:17 GMT

>aesthetic argument, though, and isn't as strong.)

Then let LISTGROUP have its own capabilities (for consistency and
avoidance of confusion), but say somewhere that "The LISTGROUP capability
MUST NOT be advertised if the READER capability is not advertised also".

---

From: "Jeffrey M. Vinocur" <[email-masked]>
Date: Mon, 28 Mar 2005 19:37:46 -0500

I agree.

We're trying to find a sensible and concise way to represent a universe 
of fine-grained possible combinations of available features.  I 
wouldn't want to eliminate the notion of arguments to capabilities, but 
I think we should try to discourage it.  In essence, that approach uses 
the syntax to encode the semantics of what can be advertised when, but 
only for the special case of one capability depending on another.  But 
this won't work if the subsidiary capability needs arguments of its own 
(for example, SASL PLAIN can't be advertised without STARTTLS, but that 
has to be made clear from the text rather than encoded in the syntax of 
CAPABILITIES).  Similarly, it won't work if the subsidiary capability 
depends on having any of several alternatives available (no obvious 
example comes to mind, but I hope the idea is clear).

-- 
Jeffrey M. Vinocur
[email-masked]

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 29 Mar 2005 09:14:54 +0100

Jeffrey M. Vinocur said:
> only for the special case of one capability depending on another.

True. But when the syntax can help you, why not let it?

> But 
> (for example, SASL PLAIN can't be advertised without STARTTLS,

Yes it can. Firstly, it can be advertised with XENCRYPT, or any other
encryption technique. Secondly, right at the end of 2.4.2 you say:

    The SASL PLAIN mechanism is
    preferred over AUTHINFO USER, even if there is not a strong
    encryption layer active,

Even section 6 only requires the existence of a mode that prevents plain
passwords without encryption.

> Similarly, it won't work if the subsidiary capability 

See first comment.

---

From: "Jeffrey M. Vinocur" <[email-masked]>
Date: Tue, 29 Mar 2005 06:17:30 -0500

On Mar 29, 2005, at 3:14 AM, Clive D.W. Feather wrote:

>> that approach uses

I guess what I'm trying to say is that I don't like the resulting 
asymmetry.  There are many reasonable real-world cases where this 
technique won't work, so client authors are going to have to rely on 
reading the text of the specification regardless.

Also, the issue with LISTGROUP stems from the fact that we're defining 
all sorts of extensions with the main document; if we were adding it at 
a later date, I don't believe we'd be trying to find a way to add a new 
argument to an existing capability (unless this possibility is clearly 
defined a priori, as for the list of SASL mechanisms).

> Yes it can. [...]

I spoke in haste, trying to use a concrete example without going into 
excruciating detail.  Set aside the fact that we like PLAIN for dealing 
with charsets properly, and that in principle some other encryption 
method might become widely implemented some day, and pretend that we 
wanted to make SASL PLAIN require STARTTLS...encoding that in the 
syntax seems quite impractical (and requiring client authors to 
implement more complex parsers for no real benefit).

>> example comes to mind, but I hope the idea is clear).

I don't see how the first comment applied here.

-- 
Jeffrey M. Vinocur
[email-masked]

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 29 Mar 2005 14:00:09 +0100

Jeffrey M. Vinocur said:
> technique won't work,

I think we just have a difference of philosophy; I'm not sure it's worth
debating that bit any further.

> defined a priori, as for the list of SASL mechanisms).

Disagree. Suppose LISTGROUP were a separate capability and, at a later
date, someone wrote an extension to allow ranges. Wouldn't they expect to
advertise it as an argument to the LISTGROUP capability?

Which reminds me: Russ, there was a suggestion to make LISTGROUP mandatory.
What happened to it?

> I don't see how the first comment applied here.

Just because the syntax can't always help you doesn't mean you should
prevent it when the opportunity *is* there.

---

From: [email-masked] (Peter Robinson)
Date: Wed, 30 Mar 2005 00:15:02 +0100

> But different capabilities *aren't* always independent.

As far as NNTP is concerned, POST and READER can be independent if we
allow CAPABILITIES to say so.  Some server implementations might be
structured so that POST without READER never arises, but that's no
reason to make this arbitrary restriction in the protocol.

Russ (and others) suggested some rare but realistic situations in which
it could be useful.  So what's the reason for the restriction?  What
harm is is preventing?

Also, it's quite possible that there will be a future extension that
would benefit from a CAPABILITY argument to POST.  (I'm thinking
specifically of an extra parameter to one of the POST response stages
returning the message-id that will be used, or similar.)

Regards,

Peter

---

From: [email-masked] (Peter Robinson)
Date: Wed, 30 Mar 2005 00:15:04 +0100

Charles Lindsey <[email-masked]> wrote:

> avoidance of confusion),

Fine (assuming it remains optional).

> but say somewhere that "The LISTGROUP capability

We could say that, but what for?  There's probably no good[1] reason to
have LISTGROUP without READER, but just because I can't think of one,
why should we write that assumption into the protocol?  What harm does
it do to allow some server to advertise only LISTGROUP, on some
connections, if that really is all it wants to provide?

Regards,

Peter

[1] I can think of at least two bad ones.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 30 Mar 2005 07:24:18 +0100

> it could be useful.  So what's the reason for the restriction?  What

Um, I've already conceeded this.