[NNTP] Revisiting POST as a separate capability

[Jeffrey M. Vinocur]

On Mar 28, 2005, at 5:27 AM, Charles Lindsey wrote:

> In <87oed7li7u.fsf at windlord.stanford.edu> Russ Allbery 
> <rra at stanford.edu> writes:
>
>> 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.)
>
> 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".

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
jeff at litech.org