Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-03.txt

From: [email-masked]
Date: Sun, 19 Jan 2014 07:46:16 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF.

        Title           : HTTP Digest Access Authentication
        Authors         : Rifaat Shekh-Yusef
                          David Ahrens
                          Sophie Bremer
	Filename        : draft-ietf-httpauth-digest-03.txt
	Pages           : 28
	Date            : 2014-01-19

Abstract:
   HTTP provides a simple challenge-response authentication mechanism
   that may be used by a server to challenge a client request and by a
   client to provide authentication information. This document defines
   the HTTP Digest Authentication scheme that may be used with the
   authentication mechanism.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-digest-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 19 Jan 2014 10:48:20 -0500

Hi,

I think that I have addressed all the comments that I have received on the
mailing list so far.
Please, take a look and let us know if you have any further comments.

Regards,
 Rifaat

On Sun, Jan 19, 2014 at 10:46 AM, <[email-masked]> wrote:

>  This draft is a work item of the Hypertext Transfer Protocol
> Authentication Working Group of the IETF.
>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Julian Reschke <[email-masked]>
Date: Sun, 19 Jan 2014 17:37:02 +0100

On 2014-01-19 16:48, Rifaat Shekh-Yusef wrote:
> Hi,
>
> I think that I have addressed all the comments that I have received on
> the mailing list so far.

a) The RFC 2617 reference can't be normative (we're replacing parts of it)

b) the URI RFC is RFC 3986.

Best regards, Julian

---

From: Yoav Nir <[email-masked]>
Date: Sun, 19 Jan 2014 16:49:38 +0000

> a) The RFC 2617 reference can't be normative (we're replacing parts of it)

Moreover, we (as in "http-auth") are entirely replacing 2617, so it shouldn't be referenced at all.

If you look at I-D nits ([1]) this, along with 2195 are unused references. Please resolve the other nits as well.

> b) the URI RFC is RFC 3986.

Yoav

[1] http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-httpauth-digest-03.txt

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 19 Jan 2014 19:20:10 +0200

> Please, take a look and let us know if you have any further comments.

Some comments (some are bit nitpicking):
- The sections about on-wire format don't say what the actual authscheme name is
  (Digest), one has to go to IANA considerations for that.
- Realm was one of those parameters that had to be quoted? It doesn't say in the
  description. Also, can't the description just refer to HTTPBIS p7 section 2.2?
- Description of userhash doesn't say the valid values (true/false).

-Ilari

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Jan 2014 08:15:00 +0100

On 2014-01-19 17:49, Yoav Nir wrote:
 > ...

Yes, it should. This is an update of a (part of a) standards track RFC, 
so we really need a section summarizing what changed.

Related to that: right now the boilerplate says that the document 
obsoletes RFC 2617. That is incorrect, because the framework is 
obsoleted by HTTPbis P7, and the bits about the "Basic" scheme are in 
yet another document.

Best regards, Julian

---

From: Yoav Nir <[email-masked]>
Date: Mon, 20 Jan 2014 08:24:53 +0000

On Jan 20, 2014, at 9:15 AM, Julian Reschke <[email-masked]> wrote:

> Yes, it should. This is an update of a (part of a) standards track RFC, so we really need a section summarizing what changed.
> 
> Related to that: right now the boilerplate says that the document obsoletes RFC 2617. That is incorrect, because the framework is obsoleted by HTTPbis P7, and the bits about the "Basic" scheme are in yet another document.

But all three documents taken together will obsolete 2617, so it's fine for each of their boilerplates to carry the "Obsoletes: 2617". I don't know at what point in time all three will get published (Basic and Digest have to wait for p7, but not the other way around), but once they are, there will be no need to read 2617, which is the definition of "Obsoletes".

Yoav

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Jan 2014 09:45:06 +0100

> But all three documents taken together will obsolete 2617, so it's fine for each of their boilerplates to carry the "Obsoletes: 2617". I don't know at what point in time all three will get publishe…

I'm not sure this is the case. For P7 we have concluded that it can't 
say "obsoletes" (cc'ing our AD).

And no, P7 is past IESG review, so you shouldn't have to wait for it.

Best regards Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Jan 2014 20:11:42 +0100

On 2014-01-20 09:45, Julian Reschke wrote:
>> But all three documents taken together will obsolete 2617, so it's
>> fine for each of their boilerplates to carry the "Obsoletes: 2617". I
>> don't know at what point in time all three will get published (Basic
>> and Digest have to wait for p7, but not the other way around), but
>> once they are, there will be no need to read 2617, which is the
>> definition of "Obsoletes".
>

Assuming

a) We don't want to make any HTTPbis change that risks a delay in 
publication,

and

b) We want the RFC database to contain useful pointers.

My proposal would be:

1) Leave P7 as is

2) In the Digest spec, state that the set P7/Basic/Digest obsoletes 
2617, and have a normative ref to the Basic spec.

3) In the Basic spec, state that the set P7/Basic/Digest obsoletes 2617, 
and have a normative ref to the Digest spec.

This will make sure that the obsoletion doesn't happen to early, and 
that the pointers actually lead to the documents that are relevant 
(although indirectly for P7).

And yes, I'll get to Basic once HTTPbis is in the publication queue.

Best regards, Julian

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 20 Jan 2014 14:35:21 -0500

> 2) In the Digest spec, state that the set P7/Basic/Digest obsoletes 2617,
and have a normative ref to the Basic spec.

Just to make sure I understand your proposal:
In the Abstract, we would state that the set P7/Basic/Digest obsoletes
2617, and we would keep the Obsoletes line on the front page?
This sounds like a reasonable approach to me.

Regards,
 Rifaat

On Mon, Jan 20, 2014 at 2:11 PM, Julian Reschke <[email-masked]>wrote:

> 2) In the Digest spec, state that the set P7/Basic/Digest obsoletes 2617,
> and have a normative ref to the Basic spec.
>
> This will make sure that the obsoletion doesn't happen to early, and that
> the pointers actually lead to the documents that are relevant (although
> indirectly for P7).
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Jan 2014 21:28:10 +0100

> This sounds like a reasonable approach to me.

Yes, something like that...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 21 Jan 2014 12:30:47 +0100

> Yes, something like that...

See <http://trac.tools.ietf.org/wg/httpauth/trac/changeset/36#file1>.

Best regards, Julian

---

From: Yoav Nir <[email-masked]>
Date: Tue, 21 Jan 2014 11:48:57 +0000

> See <http://trac.tools.ietf.org/wg/httpauth/trac/changeset/36#file1>.

Right. And just as in Julian's example, please state this in the Introduction, rather than the Abstract.

Yoav