ietf-nntp Currently outstanding issues

Ken Murchison ken at oceana.com
Sat Apr 26 05:38:06 PDT 2003


"Jeffrey M. Vinocur" wrote:
> 
> On Fri, 25 Apr 2003, Russ Allbery wrote:
> 
> > Clive D W Feather <clive at demon.net> writes:
> >
> > >     http://www.davros.org/nntp-texts/draft18.txt
> > >     http://www.davros.org/nntp-texts/draft18.html
> 
> > Section 3.1:
> >
> > | OUTSTANDING ISSUE
> > |
> > | Should the initial response line be limited to 512 octets as well? [...]
> >
> > Yes.
> 
> Agreed.
> 
> (Hmm, you might want to point out here that an extension could "increase
> in the maximum length of commands over the value specified in this
> document" [section 8] -- or is that being silly?)

I assume that you're mentioning this for SASL?  I agree, that extensions
should be able to extend this limit.


> I just noticed something:
> 
> | An NNTP client MUST NOT cache (for use in another session) any
> | information returned if the LIST EXTENSIONS command succeeds. That
> | is, an NNTP client is only able to get the current and correct
> | information concerning available extensions at any point during a
> | session by issuing a LIST EXTENSIONS command at that point of that
> | session and processing the response.  [section 5.3.2]
> 
> In the SASL draft-to-be, I believe we indicate that a client might be wise
> to cache this information in order to display a cautionary message to the
> user should a high-security method be missing (perhaps indicating a

I don't follow what you're saying without seeing the actual AUTHINFO
SASL text, but a single session can do whatever it wishes with the info
that it discovers.


> cipher downgrade type attack).  The first sentence above seems to prohibit
> that usage, but then the second seems to be more acceptable.  Are we happy
> with the wording as is?

I think the wording is fine as-is.  Similar wording is used for the
other messaging protocols.  The key phrase is "(for use in another
session)".  If a client makes multiple connections to the same server,
it can't use the information that it discovered in the first session for
the second (the second must find out for itself).

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp



More information about the ietf-nntp mailing list