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

[Christer Holmberg <[e-mail]>]

Hi,

... 

>>>>>>>> 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.
>>>
>>> Perhaps then say "As defined in RFC7617,...."
>>>
>>> And, perhaps mention it in section 2, where the changes are listed.
>>>
>>> The normative text for SIP is specified in this document, so I do not see the need to add such a sentence.
>>
>> When we update an RFC, it is good to have an overview about what the updates are, so that people don't have to start reading 3261, 7617 
>> and try to figure out themselves. They will obviously have to read the RFCs to figure out the details, but it helps if they know what the updates 
>> are about.
>
> Section 2 is all about the changes introduced to the Digest mechanism.

Yes, but that doesn't really say anything about what exactly is updated.

> If that is not sufficient, can you propose some text?
 
Something like this:

"2.  Updates RFC 3261

This section replaces the reference to RFC2617 with a reference to RFC7617 in RFC3261, and
describes the modifications to the usage of the Digest mechanism in RFC3261 resulting from 
that reference update. It adds support for the SHA-256 and SHA-512/256 algorithms. It adds
required support for the "qop" option. It provides additional UAC and UAS procedures regarding usage of
multiple SIP Authorization, WWW-Authenticate and Proxy-Authenticate header fields, including 
in which order to insert and process them. It provides guidance regarding forking. Finally, it
updates the SIP protocol BNF as required by the updates."

Feel free to modify, remove - or add if I have forgot something.


In addition, I suggest to change the names of subsections 2.3 and 2.4.

The current name of subsection 2.3 is "The Authenticate Response Header Field". But, there is no such header field described. The section talks about other header fields (with similar names). Could we simply call it "UAS behavior"?

The current name of subsection 2.4 is "The Authorization Request Header Field". But, the section also talks about the WWW-Authenticate header field. Could we simply call it "UAC behavior"?

Regards,

Christer