HTTP Digest Access Authentication
draft-ietf-httpauth-digest-19

Just a few minor comments:

3.3, domain: "If the URI is an abs_path..."

Should that be "path-absolute", in keeping with the reference to 3986?

3.6, paragraph 4: "Because the client is REQUIRED to return..."

The use of a 2119 keyword in a dependent clause seems odd.

5.1:  "Digest authentication SHOULD be used over a secure channel like HTTPS"

Does this mean that, if you have a secure channel you should use digest, or if you use digest you should use a a secure channel? I assume the second, but the sentence can be parsed either way.

IANA questions have been addressed.

I'm a yes on this, not because it's great
technology (it just isn't;-), but because it is a
valiant effort to do responsible updates to a
scheme that is used somewhat. Thanks for doing
the work.

- The intro could usefully say that this extends
but is generally backwards compatible with 2617
if you don't use any new stuff and include a
pointer to appendix A as well.

- p5, "nonce": "data string" is an odd
combination

- p6, "stale": Is "TRUE" the literal value? What
if it's "1" or "y" - just wondering in case
current code does something there. Section 3.3
(and elsewhere) uses "true" and "false" which
aren't the same as TRUE and FALSE (or are they?)
It'd be good to be consistent or to say that
we're not being consistent, presumably for
historical reasons.

- end of 3.4: is there a specific section of 7234
that's most relevant? If so, good to say so.

- 5.3, you could maybe add a reference to RFC7486
at the end of the 1st para (that is blatent
self-advertisement, but I couldn't resist:-)

- 5.6, is the "note" about Basic still true? I
thought Julian or someone tested it and found it
not quite so bad?

- I think something went wrong with the secdir
review [1] but I'd also encourage us to try to
bottom out on Hilarie's comments. There may be
something there that could be used, without any
damage to backwards compatibility, which would be
interesting.

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05621.html