[NNTP] LIST EXTENSIONS (again)

Ken Murchison ken at oceana.com
Tue Nov 2 08:39:14 PST 2004


Clive D.W. Feather wrote:

> Two things. Firstly, I want the number separate from the pseudo
> extension-label, to make it clear that it is a number and not an arbitrary
> string. Whether it's "_RFC_ 3977" or "_NNTP_ 2" is secondary.

Ah, OK.  I didn't notice the space.  I'm not sure I like it, but I'm not 
going to make a big deal of it.

The main point is that we need a way to specify the core functionality 
and behavior to the client.  I *think* we are all in agreement on this 
point.


> Case 3: a new specification is not upwards compatible for whatever reason.

Hopefully case 3 is never allowed to happen without *very* good reason, 
but discussing it OK.


> Approach C is my preference and matches (e.g.) HTTP. I only suggested an
> alternative because people choked on the major.minor idea previously.

A and C seem to be functionally identical to me and just differ in the 
syntax.  I could live with either.  FWIW, A is similar to IMAP.  IMAP 
has both "IMAP4" and "IMAP4bis" capabilities.


> These are features of the core protocol, not extensions. Therefore, in my
> opinion, they belong with the support information for the core extension.
> Note how we have "OVER MSGID" rather than separate "OVER" and "OVER-MSGID"
> capabilities.

Agreed, since they are not extensions they do belong as arguments to the 
NNTP version capability.  My main point was that we should enumerate the 
optional LIST commands.


> Nor do I. I have no objection to splitting them; I'm just getting chary of
> making complex-looking proposals (even when they're actually conceptually
> simple).

Sorry, didn't mean to scare you off.  ;)

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



More information about the ietf-nntp mailing list