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

[Christer Holmberg <[e-mail]>]

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.
 
... 

>>> 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?

Regards,

Christer