ietf-nntp The way forward?
peter.mee at freakshow.madasafish.com
Tue Feb 8 23:15:33 PST 2000
(Just looked through the archives) I see there's a sticking point on how to
split possible conflictions between current practice & possible (required)
Perhaps the most obvious thing to do would be to define a new addition to
the LIST EXTENSIONS that only indicates the availability of a new command.
For arguments sake, I'll call this extension NNTPEXT.
Assuming the server is a draft-compliant implementation, when the client
software (of any version) requests LIST EXTENSIONS, among the answers is:
Old clients that utilise the LIST EXTENSIONS command will (well, should)
blatantly ignore the above - no alteration is therefore made to the way LIST
EXTENSIONS functions and backward compatibility is thereby assured so far.
So what does this do? This allows the draft to state a new command (again,
for arguments sake: VERSION). The draft can then state, categorically, that
until the VERSION command is used any use by the client of the PAT, OVER and
other "non-experimental, unstandardised" versions of commands are outside of
the scope. All other commands used before the VERSION command is issued by
the client are considered to be utilised as previous standards dictate.
Once the VERSION command is issued by the client, the server will know that
the client software does (well, again, should) conform to the draft as set
Looking forward to some comments... ;-)
More information about the ietf-nntp