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

Editorial issues with RFC 7616

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Mon, 28 Jun 2021 09:45:26 +0000
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <HE1PR07MB44416A26EB0A106B3574DFC293039@HE1PR07MB4441.eurprd07.prod.outlook.com>
(I am bringing the issues below to this list, as the HTTPAUTH list has been terminated.)


The following issues can probably be considered editorial, and people will claim that "When you read the RFC you'll get it".

However, they have caused some confusion, why I think it is important to bring them up. If considered worthwhile fixing, I assume it can be done with the errata tool.

My apologies if the issues have already been discussed.

Section 3.8 contains the following text:

   "The digest-challenge used in the
   Proxy-Authenticate header field is the same as that for the WWW-
   Authenticate header field as defined above in Section 3.3."

Similar text existed in RFC 2617, which RFC 7616 obsoletes, but the difference is that Section 3.3 of RFC 7616 does not define the WWW-Authenticate header field.


The WWW-Authenticate header field is nowadays defined in RFC 7235. And, eventhough Section 3.3 of RFC 7616 does contain a couple of references to RFC 7235, it is not clear that the references are for the header field definition. In addition, the references are to Section 2.2 of RFC 7235, which does not define the header field.


"digest-challenge" is not mentioned in Section 3.3 - or anywhere else in RFC 7616 (except in the statement above). RFC 7235 does not use the terminology either. It was used as an ANBF term in RFC 2617. It should be "Digest scheme challenge", which is also used elsewhere.

Again, it could be claimed that anyone should understand what "digest-challenge" means, but the confusion can arise if people look at 2617 ABNF and then wonder where it has disappeared.


Section 3.3 of RFC 7616 lists the allowed WWW-Authenticate parameters. But, there is no syntax for them. At the end of Section 3.3 there is text saying which parameters should be encoded as quoted-strings, and which should not be encoded as quoted-strings. But, for the 'charset' and 'userhash' parameters there is no text. Should they be encoded as quoted-strings or not, or can they be both?

Yes, there are some examples where 'charset' and 'userhash' values are used without quoted-strings, but one should not have to implement examples.


Received on Monday, 28 June 2021 09:45:42 UTC

This archive was generated by hypermail 2.4.0 : Monday, 28 June 2021 09:45:45 UTC