[NNTP] [2501] Reader commands in transit servers and vice-versa
Charles Lindsey
chl at clerew.man.ac.uk
Tue Dec 7 06:15:43 PST 2004
In <41B4CDDC.2010800 at oceana.com> Ken Murchison <ken at oceana.com> writes:
>Russ Allbery wrote:
>> That's what the TRANSIT capability does.
>>
>> Given that IHAVE is at present the *only* transit command, I'm wondering
>> if it might be more future-proof to just call the TRANSIT capability IHAVE
>> instead. What do people feel about that?
Yes, I think I might prefer that. There might be other transit commands
some day.
Essentially, I would like to be able to distinguish the case of
"IHAVE plus READER" from the case of "IHAVE without READER". The first is
basically a reader system (e.g. NNRP) with a (possibly differently
implemented) IHAVE feature added, and the second is definitely a genuine
transit engine.
>>
>> If we did that, we could also potentially take Andrew's simplification
>> proposal, at least to some degree, and reduce matters to three cases
>> (reader commands supported, reader commands supported after MODE READER,
>> reader commands not supported). But regardless of whether we went that
>> route, I think renaming the capability may be a good idea.
>Having digested this weekend's posts, here's my current thinking.
>- We have a set of mandatory "core" commands which *all* servers MUST
>implement. The set of "core" commands is defined by the VERSION
>capability and as of VERSION 2, these are: CAPABILITIES, QUIT, HEAD,
>STAT, LIST ACTIVE
I am dubious about HEAD there. And even LIST ACTIVE (don't some pure
transit engines manage without an Active file?).
>- We have a set of optional "reader" commands which, if implemented,
>MUST be implemented in its entirety. The set of "reader" commands is
>also defined by the VERSION capability and is advertised by the READER
>capability. The VERSION 2 "reader" commands currently are: GROUP, LAST,
>NEXT, ARTICLE, BODY, DATE, HELP, NEWGROUPS, NEWNEWS, LIST NEWSGROUPS
>(Note: a case might be made that both DATE and HELP should be "core"
>commands, and that NEWNEWS should be split from the "reader" commands)
Yes, NEWNEWS might be optional (some systems turn it off), but DATE should
be paired with NEWNEWS.
>I've included the last 3 in this list because given the fact that the
>line between capabilities and extensions has been blurred, I don't think
>it makes any sense to define "extensions" within the base document. I'm
>currently thinking that an "extension" is any command (or set of
>commands) defined outside of the base document. The base document
>should just define mandatory and optional commands, the framework for
>optional LIST variants, and the framework for extensions.
Please leave OVER and HDR as "extensions". It is just too much
restructuring of the document to change that now.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
More information about the ietf-nntp
mailing list