[NNTP] Snapshot 6

[Russ Allbery]

Clive D W Feather <clive at demon.net> writes:
> Russ Allbery said:

>> My point is that you can't get rid of it completely, so I'm not sure
>> how much getting rid of it in a few more cases really helps.

> If we have a mechanism for making things clear to the client then,
> hopefully, over time it will get used.

You're missing the point.  Even if this protocol is used extensively and
reliably by the server, it *still* doesn't get rid of "try it and see"
because there's no way for this protocol to express what will happen after
STARTTLS or AUTHINFO commands are used.  The results are going to vary
depending on the strength of encryption, the authentication credentials,
and other issues.  The client is *still* going to have to try it and see
in may cases; they just may have a few cases where it's no longer
ambiguous.

In other words, all this additional complexity doesn't actually solve the
problem for the client except in a few edge cases.  Is that worth it?

>> You still don't know whether you can post after authentication; you
>> just know that you *might* be able to.

> I don't think that's a fair comparison. The idea of

>     -480 READER POST

> is to say "you need to authenticate to post, you can't post without
> it". If the client doesn't have good enough credentials, that's a
> different matter entirely.

Why would this be a different matter entirely?  It's precisely my point!
Even given the above, the client has no more reliable information than if
the capabilities were just:

    READER
    AUTHINFO SASL

In both cases, the client knows that authentication is available and
posting is not.  In both cases, posting may or may not be available after
authentication.  In both cases, the client has to just try authentication
and see.  We're giving the client exactly the same amount of information
either way.

>> How many cases are there where you can't actually post even after
>> authentication but authentication is listed as a capability?  In my
>> experience, that's an extremely unusual configuration.

> How about a server carrying private read-only groups? Authenticating is
> necessary to get at those groups, but that doesn't mean posting will be
> available.

And, as I said, this is an extremely unusual configuration.

> But, in any case, we should NOT be building such assumptions into a
> specification, especially if they're not documented. You appear to be
> saying (and please correct me if I'm wrong) that our document should
> contain wording to the effect of:

>     If the READER capability is advertised without POST, and the
>     AUTHINFO capability or some other authentication capability is also
>     advertised, then the client MAY assume that posting will become
>     available after authentication.

No, that is absolutely NOT what I am saying.  What I'm saying is that
listing READER without POST and listing AUTHINFO gives the client exactly
the same information in practice as listing -480 READER POST, but without
introducing all this additional complexity into the CAPABILITIES syntax.
And by that, I mean that the client reaction to both of those situations
has to be the same; the addition of capability modifiers doesn't allow the
client to make different, more accurate decisions.

The only case in which it allows the client to make different, more
accurate decisions is in the case where posting is unavailable and
authentication cannot possibly change the client's ability to post, which
as I stated above is an unusual situation and not one that, IMO, is seen
frequently enough to justify introducing new syntax to deal with it.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>