ietf-nntp NNTP AUTH draft

Stan O. Barber sob at verio.net
Mon Nov 8 04:03:25 PST 1999



Andrew Gierth wrote:
> 
> >>>>> "Stan" == Stan O Barber <sob at verio.net> writes:
> 
>  Stan> Andrew,
>  Stan> ANY authentication in current NNTP implementation is a LOCAL
>  Stan> extension, not a standard one.
> 
> I'm aware of that.
> 
> On the other hand, the standard extension will simply not be adopted
> unless it can be done in a way that doesn't break compatibility with
> existing practice.


Why is that? If you code your server correctly, it can choose to present 480
unless the client does a "LIST EXTENSIONS" and then present a 450 after that,
after all WHY should a client do a "LIST EXTENSIONS" if it didn't plan to make
use of the extensions?

> 
>  Stan> We are specifying a STANDARD one. As such, it needs new
>  Stan> response codes.
> 
> Even when the price is complete failure to interoperate with a large
> existing client base?

Again, WHY is that? WHY would you present a 450 code to clients that don't use
"LIST EXTENSIONS"?

> 
>  Stan> It's your choice as a server designer how you choose to support
>  Stan> the legacy RFC 977 + well-known local extensions in the context
>  Stan> of the new RFC977bis specs.
> 
> Suppose I wish to implement the new spec, and further suppose that I
> have a large existing client base that uses the widespread existing
> AUTHINFO USER/PASS extension.
> 
> My problem is that _any_ attempt to follow the new spec results in
> complete loss of the ability to support that existing client base.
> There is no way to reconcile the two; the new spec specifies behaviour
> that is not compatible with existing clients, and there is no way for
> the server to adapt its behaviour to the client either.

Any attempt to implement the new spec that does not implement it correctly, will
certainly have problem. Perhaps you are unable to figure out how to implement it
correctly. That may indicate the need for an additional document that
specifically discusses "transition" strategies so that implementors like you can
get a very specific answer on how to attack this effectively.



More information about the ietf-nntp mailing list