--On June 7, 2006 1:35:10 PM -0500 Kyle Marvin <[EMAIL PROTECTED]> wrote:
I prefer Paul's proposed text as well. I think APP client library and app developers are better served by being led to understand that may need to support multiple schemes and include things like auth pluggability to accomodate this than by a false assumption that one admittedly faulty scheme might be available everywhere. And as this is true of HTTP clients in general (as Thomas points out), I don't see the problem with this.
"auth pluggability" sounds good, but our search spider sees arbitrarily bogus login schemes on a fairly frequent basis. My favorite recent ones are: * redirect to a page with a form for the user name, which redirects to another page with a form for the password, which redirects back to to original page. * redirect to a page with a form built with JavaScript. These are built with standard technologies, but they certainly are not software-friendly. They make human-in-the-loop and full-browser assumptions. It is pretty easy to build auth schemes which are effectively proprietary using only standard components. I support a SHOULD for common auth schemes, and I don't think that RFC 2119 supports the interpretation of "a MUST with exceptions". It says that there are valid reasons to not implement a SHOULD, but ignoring it may cause problems. wunder -- Walter Underwood Principal Software Architect, Autonomy (Ultraseek)
