Hi Mike, On Sep 29, 2014, at 3:50 PM, Mike Jones <[email protected]> wrote:
> Thanks for your review, Alissa. I’ve added the working group to this thread > so they're aware of your comments. Replies are inline below… > > -----Original Message----- > From: Alissa Cooper [mailto:[email protected]] > Sent: Sunday, September 28, 2014 7:23 PM > To: The IESG > Cc: [email protected]; > [email protected] > Subject: Alissa Cooper's No Objection on > draft-ietf-jose-json-web-encryption-33: (with COMMENT) > > Alissa Cooper has entered the following ballot position for > draft-ietf-jose-json-web-encryption-33: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > == Section 2 == > It seems a bit odd that some of these terms are re-defined by this document > rather than re-using existing definitions, e.g. from RFC 4949 (plaintext, > ciphertext, etc.). Was that deliberate? > > Thanks for the RFC 4949 reference. I propose that we use those definitions, > where applicable. > > == Section 4.1 == > "As indicated by the common registry, JWSs and JWEs share a common > Header Parameter space; when a parameter is used by both > specifications, its usage must be compatible between the > specifications." > > Since both the JWS and JWE specifications are on their way to becoming RFCs, > would it make more sense to say "its usage is compatible between the > specifications"? Or is this for the future when new parameters may get > defined? > > This text is applicable both to the current documents and to future > registrations in the IANA JSON Web Signature and Encryption Header Parameters > Registry. The registration instructions include this text, reinforcing this > requirement: > The same Header Parameter name can be > registered multiple times, provided that the parameter usage is > compatible between the specifications. Different registrations of > the same Header Parameter name will typically use different Header > Parameter Usage Location(s) values. > > -- Mike > Ah, ok. In the 4.1 text I didn’t get the implied “both specifications that defined a parameter with the same name.” Thanks, Alissa
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
