ietf-nntp Draft 17 pre-2

[Ken Murchison]

"Clive D. W. Feather" wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> In message <3E5BD31A.2ED32C9E at oceana.com>, Ken Murchison
> <ken at oceana.com> writes
> >> I think this is going to depend some on what extensions one is using.  In
> >> another five years, for example, I certainly won't expect clients to send
> >> LIST EXTENSIONS before trying OVER.
> >
> >Why not?  It might be safe to assume that all servers implement OVER,
> >but what's the harm in checking?  Is there some technical reason why
> >clients would/should/might not want to do option discovery, or is this
> >just an argument being made by potentially lazy authors (not saying that
> >Russ is lazy)?
> 
> Code option 1:
> 
> * Call LIST EXTENSIONS
> * Check for 202 return code
> * Check output for OVER
> * Set a flag
> * As required:
>    * If flag set:
>      * Call OVER
>      * Check for 224 versus 423 versus 503
> 
> Code option 2:
> 
> * As required:
>    * Call OVER
>    * Check for 224 versus 423 versus 500


I would hope that if you get a 500, that you'd set a flag so that you
don't keeping asking for OVER even though the server tells you that you
its doesn't support it.

> 
> Code option 2bis:
> 
> * Set a flag
> * As required:
>    * If flag set:
>      * Call OVER
>      * Check for 224 versus 423 versus 500
> 
> Which would *you* implement?


Your example is over (excuse the pun) simplified.  If you only care
about one extension then I agree that LIST EXTENSIONS doesn't get you
anything.  However, given that the current draft documents 3 extensions
and Jeff's drafts will introduce 3 others, eg:

200 eagle.oceana.com Cyrus NNTP v2.2.prealpha server ready, posting
allowed
LIST EXTENSIONS
202 Extensions supported:
AUTHINFO USER
SASL NTLM OTP DIGEST-MD5 LOGIN PLAIN SRP CRAM-MD5
HDR
LISTGROUP
OVER
STARTTLS
.

a smart client (one that uses LIST EXTENSIONS) can find out what it can
and can't do in *one* round trip.  Using the hunt-n-peck methodology in
option 2, you waste a round trip for each unsupported extension that you
try.  It seems to me that if my client supports multiple extensions, it
is much cheaper and friendlier to use option 1, hence that is what *I*
would implement.

There *are* reasons why POP3, IMAP, and SMTP have extension discovery
commands, and clients *use* them.

-- 
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