I think that the current SHOULD is more realistic. In the real world,
particularly while developing and testing, people will have many iterations of
pre-release software for a given version, all of which will likely be
identified with the intended version number before the final release of that
version of the software is made.
-- Mike
-----Original Message-----
From: Ben Campbell [mailto:[email protected]]
Sent: Tuesday, April 07, 2015 11:11 AM
To: Phil Hunt
Cc: The IESG; [email protected]; [email protected]; Justin
Richer
Subject: Re: Ben Campbell's No Objection on draft-ietf-oauth-dyn-reg-27: (with
COMMENT)
On 7 Apr 2015, at 13:03, Phil Hunt wrote:
> Section 2:
>>
>> The software_version "SHOULD change on any update identified with the
>> same software_id" --why not MUST? What happens if this doesn't
>> happen?
>
>
> The group didn’t necessarily agree to make software_version mandatory
> to provide. Thus the word, SHOULD seemed appropriate to indicate that
> if used it SHOULD change from version to version. That said, I am ok
> with MUST (e.g. if software_version is used, it MUST change...).
>
> In answer to your question what happens: this is not so much a
> security issue (in the traditional sense of an attacker), but rather a
> regular software versioning/maintenance issue. The idea is that some
> client software updates may prove to be buggy (or have performance
> issues) and service providers may want to be able to refuse some
> versions of client software while accepting others (e.g. 2.5 is broken
> and causes DoS issues, while 2.5.1 is acceptable). If a version is
> not provided, than an AS’s only choice is to ban all versions and
> force the client developer to use or obtain a different software_id
> for future registrations.
Thanks for the response. I can live with either a SHOULD or a MUST, but if the
SHOULD stays, it would be good to add a sentence or two to the effect of the
above paragraph. That being said, "If used, it MUST change" seems to be more
precise if that fits the WG intent.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
