ietf-nntp Draft 20 pre-release 2

Rob Siemborski rjs3 at andrew.cmu.edu
Fri Oct 10 07:41:04 PDT 2003


On Fri, 10 Oct 2003, Jeffrey M. Vinocur wrote:

> > I agree.  (preferring the MUST NOT cache security extensions).
>
> I do support Clive's point that this *is* a protocol document and thus
> it's not really well-formed (or even in our scope?) for us to prohibit
> caching per se.
>
> An alternative phrasing along the lines of "clients MUST send LIST
> EXTENSIONS before using ..." would probably be more appropriate.  Or maybe
> we should emphasize that each extension document needs to state whether or
> not LIST EXTENSIONS is required before use of that extension, and remind
> extension document authors that security extensions should invoke that
> requirement.

But its the *caching* that is dangerous, not the lack of sending LIST
EXTENSIONS.  (And this might encourage server implementations to fail
commands when LIST EXTENSIONS has not been issued, which is poor
behavior).

If you want to avoid talking about it, then drop all mention of caching
from the document, except possibly a MUST NOT cache for
security/privacy/etc extensions.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * rjs3 at andrew.cmu.edu * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----




More information about the ietf-nntp mailing list