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. -- Kyle On 6/7/06, Thomas Broyer <[EMAIL PROTECTED]> wrote:
2006/6/7, Tim Bray <[EMAIL PROTECTED]>: > > On Jun 7, 2006, at 10:21 AM, Paul Hoffman wrote: > > > Note that in IETF parlance, a "SHOULD" is "MUST but with a few > > stated exceptions". I don't feel that that is what people were > > saying +1 to. > > Gack; seems to me it would be way out of line to point a MUST at any > one of the options. Among other things I expect APP to be longer- > lived than any particular web-authent flavor. -Tim +1 HTTP/1.1 doesn't mandate support for any authentication scheme, so why would APP do? Nothing more should be said than "you, as a server implementor, might want to consider protecting your APP endpoints with whatever mechanism you choose –presumably using HTTP authentication, SAML, NTLM or something else– and clients implementors should be aware of that". Eventually, something like "at the time of this writing, Basic+TLS seems a good catch and widely deployed solution, so client implementors should at least support HTTP-Basic and TLS", but no more (I personnaly haven't TLS at my shared hosting, so I'll use Basic first, and then move to Digest, HMACDigest or any better algorithm –and given that I'm progressing no faster than a snail, there might be some new ones since then :-p –) -- Thomas Broyer
