- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 19 Oct 2006 09:01:53 +0200
- To: Paul Leach <paulle@windows.microsoft.com>
- CC: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>, lists@ingostruck.de, HTTP Working Group <ietf-http-wg@w3.org>
Paul Leach schrieb: > > > > A MUST NOT requiring that the default configuration not allow Basic auth (or equivalent) unless SSL (or equivalent) was in use would be more justifiable than a flat out prohibition. > > However, I think even that is inappropriate _as a protocol requirement_ -- by the test that conformance isn't decidable by compliant implementations. In the "security considerations" section, however, it is permissible to make requirements that are not protocol requirements (e.g., don't store passwords in files accessible by ordinary users). > > On the other hand, when there is a choice of authentication mechanisms defined for a protocol, and one or more of them is made "mandatory to implement", it is decidable whether the other party has done so. So I think that such requirements are a valid protocol "MUST". Well, how do you decide that if the protocol implementation is a service, such as Google GData (please take this as just an example for the situation; I have no idea what they currently implement, and what they may in the future)? In cases like these "not implemented" and "not deployed" can not be distinguished from the outside. Best regards, Julian
Received on Thursday, 19 October 2006 07:08:44 UTC