RE: : Re: why is Digest-Nextnonce mandatory ?

Miguel Garcia wrote:

> But having said that, I see the contradiction in RFC 2617: on one
> side, the nextnonce is mandatory, on the other, the text suggest
> that it is optional "If the nextnonce field is present ...". In the
> Diameter SIP application we just transposed the ABNF in RFC 2617 to
> Diameter AVPs.
>=20
> So, I would like to gather a better understanding of people who
> might know better RFC 2617: is there an error in the ABNF definition
> in the Authentication-Info header? Should the nextnonce be optional?

It looks like RFC2617 uses the ABNF notation (defined in RFC2616) in
a way that is not really consistent with the ABNF semantics:

   auth-info          =3D 1#(nextnonce | [ message-qop ]
                          | [ response-auth ] | [ cnonce ]
                          | [nonce-count] )

clearly suggests to the reader that "nextnonce" has to be present,
while the other parts are not always included. However, this is not
what the ABNF actually means according to RFC2616.  In fact, it looks
like the rule is equivalent to both of these:

   auth-info          =3D 1#(nextnonce | message-qop
                          | response-auth | cnonce
                          | nonce-count )

   auth-info          =3D 1#( [ nextnonce ] | [ message-qop ]
                          | [ response-auth ] | [ cnonce ]
                          | [ nonce-count ] )

In other words: any string containing at least one of the parts=20
(not necessarily nextnonce) matches this ABNF, and more precise
specification of when the different parts have to be present is=20
in the descriptive text.

Since the descriptive text says "If the nextnonce field is present
[..]", it's not actually in conflict with the ABNF. But the ABNF
is clearly misleading (and it looks like some other ABNF rules=20
in RFC2617 have this same problem).

Best regards,
Pasi