It might make more sense to prefix the JWT versions as not being what is here.
Jim > -----Original Message----- > From: Mike Jones [mailto:michael.jo...@microsoft.com] > Sent: Wednesday, March 7, 2018 9:47 PM > To: Benjamin Kaduk <ka...@mit.edu>; Adam Roach <a...@nostrum.com> > Cc: The IESG <i...@ietf.org>; draft-ietf-ace-cbor-web-to...@ietf.org; ace- > cha...@ietf.org; ace@ietf.org > Subject: RE: Adam Roach's No Objection on draft-ietf-ace-cbor-web-token- > 13: (with COMMENT) > > Thanks, Ben and Adam. I've recoded a note to address the improvements > below one the submission tool reopens. > > For what it's worth, I independently noticed the unintended overlap > between the Standards Action and Specification Required number ranges in > a conversation today with IANA. > > The point of including new CWT definitions for "StringOrURI" and > "NumericDate" was so that we could use them directly. Prefixing them with > "CWT" isn't necessary for the meaning to be clear in context. > > Thanks both for the attention to detail. > > -- Mike > > -----Original Message----- > From: Benjamin Kaduk <ka...@mit.edu> > Sent: Wednesday, March 7, 2018 8:24 PM > To: Adam Roach <a...@nostrum.com> > Cc: The IESG <i...@ietf.org>; draft-ietf-ace-cbor-web-to...@ietf.org; ace- > cha...@ietf.org; ace@ietf.org > Subject: Re: Adam Roach's No Objection on draft-ietf-ace-cbor-web-token- > 13: (with COMMENT) > > Hi Adam, > > With my shepherd hat... > > On Wed, Mar 07, 2018 at 04:05:32PM -0800, Adam Roach wrote: > > > > Thanks to the WG, chairs, and > > > > §3.1.1: > > > > > The "iss" (issuer) claim has the same meaning and processing rules > > > as the "iss" claim defined in Section 4.1.1 of [RFC7519], except > > > that the value is of type StringOrURI. The Claim Key 1 is used to > > > identify this claim. > > > > > > 1) Given that RFC 7159 defines "iss" to contain a "StringOrURI" value, it's > > not clear what the "except" clause is attempting to convey. > > I had to ask about this as well -- the crux is that the "StringOrURI" JWT type is > different from the CWT "StringOrURI" > type. IIRC there used to be an extra descriptor in here but it was removed as > redundant. > > > 2) Given the many uses of the word "type" in this context (including CBOR > > types and the JWT 'typ' field), and given that RFC 7519 never refers to > > "StringOrURI" as a "type," I think that the use of the word "type" here > > is likely to lead to reader confusion. > > In combination with the above, maybe we want "the value is a CWT > StringOrURI value". Authors? > > > This comment -- or a congruent form of it involving "NumericDate" > > rather than "StringOrURI" -- applies to §3.1.2 through §3.1.6. > > (Right.) > > > ---------------------------------------------------------------------- > > ----- > > > > §9.1: > > > > > Criteria that should be applied by the Designated Experts includes > > > determining whether the proposed registration duplicates existing > > > functionality, whether it is likely to be of general applicability > > > or whether it is useful only for a single application, and whether > > > the registration description is clear. Registrations for the > > > limited set of values between -256 and 255 and strings of length 1 > > > are to be restricted to claims with general applicability. > > > > Use of the word "between" without qualifying it as inclusive or > > exclusive of the endpoints is ambiguous. Suggest either "values from > > -256 to 255" or "values between -256 and 255 inclusive". > > Agreed, it should be qualified as inclusive. > > > ---------------------------------------------------------------------- > > ----- > > > > §9.1.1: > > > > > CBOR map key for the claim. Different ranges of values use > > > different registration policies [RFC8126]. Integer values between > > > -256 and 255 and strings of length 1 are designated as Standards > > > Action. Integer values from -65536 to 65535 and strings of length > > > 2 are designated as Specification Required > > > > Same comment as above. > > > > Also, please replace "from -65536 to 65535" with "from -65536 to -257 > > and from > > 256 to 65535". > > Good catch! > > Thanks, > > Ben _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
