In some parts of the text, RFC 4976 makes confusing sluggish use of
established IETF standard terminology.

Since RFC 2045 ff., and reinforced by many more RFCs, the distinction
between "header" and the elements of a header, "header fields" should be
clear to all. I once again recommend BCP 90, RFC 3864, and in particular
Section 3.1.1 of RFC 4249 for clarification of this terminological issue.

Hint:
Additionally, the RFC sometimes is not precise enough in distinguishing
the parts of a header field from the whole, e.g. saying "header" where
it should say "header field value" ; this issue will be mentioned below
as case e) and additionally be addressed in specific errata reports.

Note: Remarkably, other parts of RFC 4976, and the whole companion
document, RFC 4975, do not suffer from this deficiency.

The following parts of RFC 4976 suffer from the four variants
of this abuse of language shown in the OLD / NEW boxes above:

This should draw the attention to the lack of specification in the RFC
(cf. extra report) for the Relay behavior w.r.t. Use-Path in repsonses.

From descriptive text in the RFC it becomes clear that the 3rd message
above should contain one URI in the Use-Path header field, and that the
second one shown there in fact needs to be added by the relay into the
4th message (final response to the client).
The simple URI repetition shown in the 4th message doen not make sense
at all.

a) The prose of the RFC indicates that the restriction stated in the
added ABNF comment indeed should hold. See also note below.

b) The <digest-param> syntax as stated in the RFC makes no sense;
allowing optional productions in the ABNF alternative would allow
empty <digest-param>s , i.e. immediately adjacent commas in the
WWW-Authenticate header field value; I suspect that the square
brackets might have been intended to indicate what I suggest to
express in the ABNF comment a).

To express the full set of requirements for WWW-Authenticate in pure,
formal ABNF would perhaps make it much less readable.

These issues are replicated for <credentials> and <digest-response>
-- this is addressed in a separate report.

The text in Sections 4.3 through 4.5 refers to Section 5.1
for the details of HTTP Digest authentication.
Most of these in fact are in Section 9.1; thus the reader
should be directly advised to consult Section 9.1 as well.

It might even be better to only point to 9.1 in these 3 instances.

Note: The pointer to Section 5.1 given in Section 4.2 seems to be
appropriate.

<< add to the end of the section: >>
Before forwarding a 200 response containing a Use-Path header field,
the relay MUST prepend to the existing header field value the URI it
supplies and wants the upstream neighbor to use in future requests in
this session.

Notes:

As sadly confirmed by the flaws in the example in Section 5.1 (on p. 17),
the Relay Behavior / Handling Responses underspecifies the required
synthesis of the Use-Path header field value.

The above text is a strawman proposal and should be elaborated upon
before signing off this report.
--VERIFIER NOTES--
From reviewer Dale Worley:

The suggested change is incorrect. The value of the Use-Path header
generated by the server-relay in the 200 response is not intended to
be modified by any intermediate relay on the way to the client. This
can be seen by (1) the lack of any text specifying any transformation
of the Use-Path value by intermediate relays, and (2) the skeleton
example in section 5.1, page 14, which says "Use-Path returned by C: B
C". (In that example, a better rendering would be "Use-Path returned
by C: Btoken Ctoken".)

A relay can generate a complete Use-Path because the initial elements
can be extracted from the From-Path value of the request.