ietf-nntp LIST EXTENSIONS non-pipelined and non-cacheable?

Peter Robinson pmrobinson at gmx.net
Tue Sep 9 05:03:50 PDT 2003


| 5.3 LIST EXTENSIONS

| This command MUST NOT be pipelined.

Why not?  I can understand that a client should wait until the LIST
EXTENSIONS response before trying to use an extension (or not), but why
shouldn't it do something like this:

 [C] LIST EXTENSIONS
 [C] GROUP misc.test 
 [S] 202 Extensions supported:
 [S] OVER
 [S] HDR 
 [S] .
 [S] 211 1234 3000234 3002322 misc.test
 [C] OVER
(...)
?

| It is not required that the client issues this command before
| attempting to make use of any extension. The response generated by
| this command MAY change during a session because of other state
| information (which in turn may be changed by the effects of other
| commands). An NNTP client MUST NOT cache (for use in another session)
| any information returned if the LIST EXTENSIONS command succeeds.

It seems inconsistent that on one hand, a client can (try to) use an
extension having no idea whether it's supported, while on the other hand
it is forbidden to cache the LIST EXTENSIONS response, and use it to
make an educated guess.

I'd have thought that that kind of decision should be left to newsreader
authors and users.  So 

  An NNTP client SHOULD NOT cache [...]

or

 An NNTP client SHOULD NOT rely on any information cached from the LIST
 EXTENSIONS response in another session.

So the client can use the cached information if it wants to, but it
should cope with it being out of date.  cf LIST ACTIVE etc..

Peter




More information about the ietf-nntp mailing list