Haven't seen any replies to this, which probably means it was too long for people to process. Sorry! Here's a shorter post: What's the next step on resolving the authentication issues? (We have a couple of Paces and a TBD that needs removing from the spec, at least.)
-John John Panzer wrote on 6/8/2006, 5:35 PM: > > 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 > > -- Abstractioneer John Panzer System Architect http://abstractioneer.org
