[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