[ietf-nntp] I-D ACTION:draft-ietf-nntpext-authinfo-00.txt

[Ken Murchison]

Russ Allbery wrote:

> You have a point there.  RFC 1734 doesn't require sending any sort of
> capability command (it predates the CAPA command for POP), and reading
> over RFC 3501, while there are some implications that most clients are
> going to want to send the CAPABILITY command, I don't see any actual
> requirement that a client do so before beginning AUTHENTICATE.
> 
> Ken?

I don't think that its ever been explicitly stated as a MUST in the SASL 
spec or any other protocol profile that I'm familiar with, I think its 
just assumed that a client would check.


> It does make sense to me that a client that only has one authentication
> mechanism that it considers to be of appropriate strength and is willing
> to use has no real use of LIST EXTENSIONS prior to authentication (since
> it must discard the output after authentication anyway).

I suppose this makes sense.


> 
>>So I think it's a MAY, not a SHOULD or MUST.
> 
> 
> I think you may be right.

I'm not going to fight this either way.  I'll change it to MAY or use 
some other wording which makes it optional as opposed to required.


> In the middle of the negotiation, empty data and no data are the same
> thing, or rather, there's no way for SASL to return no data in the middle
> of a negotiation (since SASL allows for an implementation that doesn't add
> any status codes to the beginning of the data replies).

I've already made the mental note to use "383 =" for an empty challenge.


> It's only potentially ambiguous at the end of the negotiation.

This is currently being discussed over on the ietf-sasl list as part of 
RFC 2222bis.  Nobody has come up with a case where an empty success data 
(final challenge) makes any sense, but if we do, then I'll use "283 =" 
for it.  In fact, I'll probably just allow for it in the draft, and if 
its never used, no harm done.

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