Subject: [NNTP] Capability modifiers

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 9 Feb 2005 12:02:13 +0000

Okay, this remains the one contentious issue. I'd like us to get it closed
off because we'd all like to see the draft out.

I initially proposed them so that we wouldn't get stuck if we ever need to
extend the syntax of capabilities. The minimal requirements are:
* servers: none.
* clients: MAY completely ignore lines with modifiers completely,
           MUST NOT crash.

I then proposed the modifiers beginning with dash to mean "not available
for reason X":

  --      cannot be re-enabled
  -480    requires authentication
  -483    requires privacy protection
  -label  requires something related to the capability with that label

Other people suggested some wording and concept cleanups; in particular,
two modifiers on a line is an "and" while multiple lines is an "or".

-MODE-READER is seeing actual use elsewhere in the draft; specifically
    -MODE-READER READER
indicates that reader commands will be available after MODE READER.

Russ sees little or no point in the concept and, more specifically, the
-480 and -483 cases. If I'm understanding his point, he's saying that
authentication or privacy setup might fail anyway (e.g. wrong credentials
for the desired operation) and so these provide little or no information
except in edge cases.

I'm not sure where we go from here.

If we remove modifiers entirely, we still want to say *something* about
extensibility of the CAPABILITIES syntax, and we still need something to
replace the -MODE-READER modifier in particular.

So, some questions for people:

* Is the modifier *concept* worth retaining as a hook for syntax extension?
If not, how do we address that?

* Is the -- modifier useful as a documentation technique?

* Is the -label modifier useful for interrelated capabilities?

* Are the -480 and -483 modifiers useful for indicating what is and
isn't available with and without security and privacy?

* If we remove modifiers, what do we do about -MODE-READER?

-- 
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: Ken Murchison <[email-masked]>
Date: Wed, 09 Feb 2005 10:33:09 -0500

> replace the -MODE-READER modifier in particular.

I don't see why either of these are required.  If we need to extend the 
CAPABILTIES response syntax in the future, this can be done with a new 
VERSION 3 response.  As far as -MODE-READER, I don't see its value.  A 
mode-switching server will be advertising MODE-READER and the client 
will know that its required before it can use any reader commands.

> * Is the modifier *concept* worth retaining as a hook for syntax extension?

I've never been in favor of it, but won't fight it as long as its 
complexity doesn't hinder implementation and/or deployment.

I realize that I've been pushing hard for a client to gleen everything 
possible from CAPABILITIES, but not at the expense of additional 
syntactic sugar.  I think we're at that 80/20 place where the current 
CAPABILITIES gives us 80% of what a client needs.  The modifiers *may* 
get us the remaining 20%, but adds more complexity to the client to sift 
through what the server is telling it.

> If not, how do we address that?

Still not convinced that a mechanism for extending the syntax is required.

> * Is the -- modifier useful as a documentation technique?

I really don't see its value.  It really only applies to STARTTLS after 
TLS/auth, to AUTHINFO after auth and to reader commands after MODE 
READER, all of which is documented behavior.  What's the point of 
telling the client something that it should already know?

> * Is the -label modifier useful for interrelated capabilities?

Possibly.

> isn't available with and without security and privacy?

Possibly.

> * If we remove modifiers, what do we do about -MODE-READER?

Not convinced we need a replacement.

-- 
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: [email-masked] (Kai Henningsen)
Date: 09 Feb 2005 20:51:00 +0200

[email-masked] (Clive D.W. Feather)  wrote on 09.02.05 in <[email-masked]>:

> extensibility of the CAPABILITIES syntax,

Why?

>and we still need something to

How about nothing? It would seem to dramatically simplify the various  
places

> * Is the modifier *concept* worth retaining as a hook for syntax extension?

I don't think so.

> If not, how do we address that?

By taking it out.

> * Is the -- modifier useful as a documentation technique?

Not useful enough, IMO.

> * Is the -label modifier useful for interrelated capabilities?

I don't really see it.

> isn't available with and without security and privacy?

Again, not useful enough, IMO.

> * If we remove modifiers, what do we do about -MODE-READER?

Remove it, too.

MfG Kai

---

From: Russ Allbery <[email-masked]>
Date: Wed, 09 Feb 2005 17:22:23 -0800

Please, anyone with any sort of opinion on this, speak up.  We need to
make a decision on it as I believe it's the only issue holding us up from
getting out a final version of this draft and going into a working group
last call on our documents.

> replace the -MODE-READER modifier in particular.

As noted by others, I think the VERSION line offers sufficient
extensibility in the general case, and for this in particular it seems
like one could safely introduce modifiers later by stating that servers
MUST NOT send lines beginning with characters not allowed in capabilities
and clients MUST ignore any such lines if present.  That would allow
modifiers to be added as a separate experimental provision and adopted if
they prove useful in practice.

I would not replace -MODE-READER with anything; I would require readers to
issue a MODE READER command if they want to use READER facilities, those
facilities are not advertised, and MODE-READER is.

I think most people know my opinion on this, but to restate it just for
the record:

> * Is the modifier *concept* worth retaining as a hook for syntax
> extension?  If not, how do we address that?

I don't think it's sufficiently useful to be worth pursuing at this time.

> * Is the -- modifier useful as a documentation technique?

I find -- to be the most useful of the lot, as it's a way of clearly
indicating "posting will never be permitted" that's better than the 201
greeting code.  But that isn't sufficiently interesting to have the
modifier be worth it for me.

> isn't available with and without security and privacy?

I like -480 and -483 better than -label, but none of them seem
particularly useful to me.  I think the client has sufficient information
to make good decisions for all of the common cases, and I'm not sure
modifiers really help the uncommon cases that much.

> * If we remove modifiers, what do we do about -MODE-READER?

Akin to authentication and encryption, I would have the server simply not
advertise capabilities that are not currently available but that will
become available after MODE READER.

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 10 Feb 2005 08:25:24 +0000

> they prove useful in practice.

Okay.

> facilities are not advertised, and MODE-READER is.

I suppose that can be derived from the wording about MODE READER.

> modifier be worth it for me.

We could still add a "no longer available" flag in any case.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 10 Feb 2005 08:28:16 +0000

>> extensibility of the CAPABILITIES syntax,

Because we should be able to design a extensible mechanism this time,
instead of having to patch around problems from lack of thinking.

And because, in particular, CAPABILITIES tells you what features are
available, and having to see whether a feature to tell you what features
are supported is supported before using it to find out what features are
supported is a really dumb idea.

---

From: [email-masked] (Kai Henningsen)
Date: 10 Feb 2005 18:39:00 +0200

> Because we should be able to design a extensible mechanism this time,

I am not convinced this particular mechanism *should* be all that  
extensible.

> supported is a really dumb idea.

This argues to me that CAPABILITIES should NOT be significantly  
extensible.

MfG Kai

---

From: [email-masked] (Peter Robinson)
Date: Thu, 10 Feb 2005 22:38:27 +0000

> off because we'd all like to see the draft out.

I like the idea of capability modifers and I think they fit neatly with
the rest of the protocol.  However, uncomfortable though it is, Russ's
point that they would rarely change the behaviour of a client, and
therefore gain you nothing, is difficult to argue with.  Therefore my
opinion is that we should remove all capability modifiers from the
draft.

The important thing (and what motivated the excellent work since the old
LIST EXTENSIONS) is that clients can now tell for sure whether there's
any need to send MODE READER.  If nothing else will get clients using
CAPABILITIES that will, since for the common case of no MODE READER,
there's now no net cost in terms of round trip times.

Peter