RFC2616 vs RFC2617, was: Straw-man charter for http-bis

Paul Hoffman wrote:
> 
> At 3:42 PM -0700 6/6/07, Chris Newman wrote:
>> 1. HTTP Digest Authentication
>>
>> The SASL WG appears to have decided that SASL DIGEST-MD5 is not a 
>> useful authentication mechanism for a number of technical reasons. I 
>> would be uncomfortable having a WG spend a lot of time refining the 
>> existing HTTP Digest mechanism based on that experience. However, 
>> documenting the i18n behavior of deployed implementations sounds like 
>> a sensible thing to do.
> 
> It seems weird to do significant clarification work on 2616 and 
> basically ignore 2617, given the normative reference to the latter. A 
> better option would be to do full clarifications in 2617, including a 
> discussion of the not-clarifiable internationalization issues. One such 
> clarification is a list of the problems of HTTP Digest in the modern world.
> 
> This probably should not take "a lot of time"; if it does, it means that 
> the clarifications are all the more valuable. HTTP implementers who see 
> a lot of work in 2616bis and nothing in 2617 will not necessarily come 
> to the conclusion that the IETF wants; it would be better to have a 
> 2617bis that says what we want to say.
> ...

Hi,

maybe things become clearer if we consider re-organizing the security stuff?

Currently,

- RFC2616 refers (normatively?) to RFC2617 for authentication, and

- RFC2617 defines a framework (Section 1.2) and two schemes (Basic and 
Digest).

Assuming that there's no immediate need to change the framework defines 
in RCF2617, Section 1.2, wouldn't it make sense to:

- Move the authentication framework itself into RFC2616bis, and

- to then publish stand-alone documents upgrading/fixing both Basic and 
Digest?

The benefits being:

- RFC2616bis doesn't have the dependency on its sister spec anymore, 
which suffers from Basic and Digest problems, and

- Basic, Digest and new schemes could evolve independently.

Best regards, Julian