[NNTP] Revisiting POST as a separate capability

[Jeffrey M. Vinocur]

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

> Jeffrey M. Vinocur said:
>> 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.
>
> True. But when the syntax can help you, why not let it?

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


>> this won't work if the subsidiary capability needs arguments of its 
>> own
>> (for example, SASL PLAIN can't be advertised without STARTTLS,
>
> 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).


>> 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).
>
> See first comment.

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

-- 
Jeffrey M. Vinocur
jeff at litech.org