W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2007

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 07 Jun 2007 18:01:13 +0200
Message-ID: <46682BC9.9050504@gmx.de>
To: Paul Hoffman <phoffman@imc.org>
CC: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Apps Discuss <discuss@apps.ietf.org>

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.
> ...


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


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

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

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 

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
Received on Thursday, 7 June 2007 16:01:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:42 UTC