Re: [sipcore] draft-ietf-sipcore-digest-scheme comments

[Rifaat Shekh-Yusef <[e-mail]>]

On Sat, May 25, 2019 at 10:53 AM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
> >>>> Section 2.1:
> >>>>
> >>>> "Note that [RFC7616] defines a -sess variant for each algorithm; the
> >>>>   -sess variants are not used with SIP.”
> >>>>
> >>>> Is this already forbidden in 3261 or is this new proposed language?
> If so, “are not” should propably
> >>>> be something like “MUST not”
> >>>
> >>> I do not think that 3261 forbids the -sess variant, and I do not see
> the need to forbid it here either
> >>> So then I suggest we remove the statement that the -sess variants are
> not used with SIP.
> >>>
> >>> If -sess variant was defined in RFC 7616, it was obviously not
> mentioned in RFC 3261 __
> >>
> >> What is the difference between the session variant and the non-session
> variant? What is meant by "session"? RFC 7616 doesn't give any explanation,
> and I couldn't find anything by googling either.
> >
> > See RFC 7616, section 3.4.2 for more details.
> >
> >> I do think we need to say *something*.
> >
> > Any suggestion?
>
> Not at the moment. But, if allowing both adds something new to what is
> currently defined/assumed in RFC 3261 I think it would be good to point it
> out.
>
>
The ABNF allows for the -see variant, but my understanding is the the -sess
variant was never implemented in SIP.
This document does not introduce any new -sess specific changes.



> ...
>
> >>> Section 2.4:
> >>>
> >>> "When the UAC receives a response with multiple header fields with the
> >>>   same realm it SHOULD use the topmost header field that it supports,
> >>>   unless a local policy dictates otherwise.”
> >>>
> >>> Why a SHOULD? I would prefer a MUST.
> >>
> >> I can do that, but the last part of this paragraph states that local
> policy can override this recommendations anyway.
> >> So, does it make any difference?
> >> Should we allow that? Why would local policy enforce a downgrade?
> >>
> >>> “When the UAC receives a 401 response with multiple WWW-Authenticate
> >>>   header fields with different realms it SHOULD retry and include an
> >>>   Authorization header field containing credentials that match the
> >>>   topmost header field of any one of the realms.”
> >>>
> >>> If you are disallowing multiple Authorization headers for the same
> realm,
> >>> but with different algorithms I think this should be clearly written.
> In my
> >>> view, that would be a good thing.
> >>
> >> This is allowed.
> >
> > RFC 3261 does not say anything about using the topmost header, does it?
> >
> > I was referring to this document.
>
> So, the should-use-topmost is something new, defined in this document?
>
>
Yes, as per RFC7616.

Regards,
 Rifaat




> Regards,
>
> Christer
>
>