I'm seeing 4 rough categories of server implementors in this discussion: (1) Don't care about authentication at all (open wikis, family servers, etc. etc.) (2) Care about authentication, but cannot implement Basic+https for some reason (restricted hosting environment, etc.) (3) Care about authentication, and are okay with Basic+https, though they may implement other things as well (4) Care about authentication but don't think it can or should be standardized in the spec.
Category (1) can be satisfied as long as the spec wording doesn't mandate that servers support authentication. (Right?) Category (2) is covered as long as Basic+https is at most a SHOULD[*]. Category (3) is happy with Basic+https as a SHOULD. Category (4) should have a different discussion, perhaps on a separate thread? [*] SHOULD: ...there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Restricted environments seem to me to be a reasonable reason to ignore a particular item. I would like to point out that if we simply point at RFC 2617, it itself uses a SHOULD (NOT) which already affects category (2): > Because Basic authentication involves the cleartext transmission of > passwords it SHOULD NOT be used (without enhancements) to protect > sensitive or valuable information. Now, I'd be happy with using MAY instead of SHOULD everywhere above for server Basic+https, except for one concern: MAY: > ... An implementation which does not include a particular option MUST be > prepared to interoperate with another implementation which does > include the option, though perhaps with reduced functionality. If this means that servers MUST interoperate with clients that don't support Basic+https, then I don't think MAY works. Unless by "reduced functionality" we can say that it works only for operations that don't require authentication? --- John Panzer System Architect http://abstractioneer.org
