ietf-nntp Draft 20 pre-release 2

Rob Siemborski rjs3 at andrew.cmu.edu
Thu Oct 9 11:42:06 PDT 2003


On Thu, 9 Oct 2003, Russ Allbery wrote:

> Rob Siemborski <rjs3 at andrew.cmu.edu> writes:
>
> > This section is broken in *dire* ways.  It contains a direct
> > contradiction to section 5.3:
>
> We just had a big discussion of this.  You could have weighed in then!  :)

I only intermittantly follow this list, but Ken's comments seem to be in
line with my own.

> > I believe that 5.3 is correct and that a client MUST NOT rely on cached
> > versions of the extension list at any time.  This is in line with
> > similar protocols that offer extension discovery commands.
>
> It must not rely on cached versions of the extension list for security
> extensions.  We just had a long discussion about this and I don't see any
> reason why it can't rely on cached versions for non-security extensions.
>
> If you disagree, could you please explain your reasoning?

Is there any way for the client to refresh the security capabilities
without refreshing all of them?  Yes, anonymous clients may not care, but
I suspect client authors are more likely to get it wrong and not refresh
for the security case if the leave the document as it is now.

In any case, having a document that says "MUST NOT do x" in one section
and (implies) "MAY do x" in another is broken, regardless of what the
particular issue is.

-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