On 25/02/2019 18:08, Jim Schaad wrote:
3. In section 8.3 - Is/Should there be a requirement that the
error also be registered in an OAuth registry? If so then this
needs to be part of the expert reviewer instructions on this
registry.
The expert reviewer instructions already state this:
"Since a high degree of overlap is expected between these
registries and the contents of the OAuth parameters registries,
experts should require new registrations to maintain a reasonable
level of alignment with parameters from OAuth that have comparable
functionality."
This includes the error registry, do you think this is
sufficiently clear or should I elaborate?
The question I had was the difference between SHOULD and MUST be
registered. The text there says - try and keep them in sync, but if
they are not it is not a problem. If that is what you want then
this is not a problem, I was just validating this.
The intention of the "should require ... a reasonable level of
alignment" was "try and keep them in sync, but if they are not you need
a good reason for this".
Your alternate interpretation makes me think the text is not worded
strongly enough.
4. In section 8.4 - Is there a reason to require a specification
for this registry? Should it be sufficient to have somebody
request that a mapping be registered and the DE approves it? The
previous comment would apply
to
all of the mapping registries that are just mappings.
The idea is to prevent the squatting of low byte count
abbreviations by parameters that are not frequently used, thus
there is a range of different policies for different integer
abbreviation number ranges. (note: I'm following the example of the
CWT specification here)
Not requiring a document to exists could still allow this. IANA
would still have the DE approve the assignment.
Ok so you mean not having "specification required" for -65536 to -257
and 256 to 65535 and not having "standards action" for -256 to 255 would
be ok?
Note that this would be different from the policy in RFC 8392 (CWT).
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
