ietf-nntp LIST EXTENSIONS non-pipelined and non-cacheable?
Ken Murchison
ken at oceana.com
Wed Sep 10 07:09:26 PDT 2003
Clive D.W. Feather wrote:
> Note that what you're saying is:
>
> [C] DATE
> [C] AUTHINFO SASL PLAIN asdlfnkasf
> [S] 111 20030910090204
> [S] 502 No mechanism available
>
> is fine but, on the other hand:
I'm not saying this is fine at all. A client MUST make sure that the
plaintext mechanism can be used before using it.
>
> [C] LIST EXTENSIONS
> [C] AUTHINFO SASL PLAIN asdlfnkasf
> [S] 202 Extension list follows:
> [S] AUTHINFO USER
> [S] .
> [S] 502 No mechanism available
>
> isn't.
Correct, for the same reason as above.
> You are assuming that clients will always use LIST EXTENSIONS to decide how
> to do authentication. Surely it's equally likely that they'll just work
> down their list of known methods in order of security, or something like
> that?
That would be extremely poor design. As I said before, why would a
client author be so stupid as to blindly try a bunch of command and/or
authentication mechanisms in a hit-or-miss fashion, when in ONE rountrip
is can find out exactly what it can and can't do?
I ask again, why would a client NOT want to use LIST EXTENSIONS?
> In any case, forcing a LIST EXTENSIONS isn't going to cure any client that
> badly designed.
True, but we also shouldn't encourage what IMO is bad design.
--
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