[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