FYI, Ben, "crit" is now required with "b64", as you'd requested.
-----Original Message----- From: Mike Jones [mailto:[email protected]] Sent: Wednesday, December 16, 2015 5:01 PM To: Ben Campbell <[email protected]>; The IESG <[email protected]> Cc: [email protected]; Jim Schaad <[email protected]>; [email protected]; [email protected]; [email protected] Subject: RE: Ben Campbell's No Objection on draft-ietf-jose-jws-signing-input-options-07: (with COMMENT) Hi Ben. Thanks for your useful review. > -----Original Message----- > From: Ben Campbell [mailto:[email protected]] > Sent: Thursday, December 17, 2015 12:16 AM > To: The IESG <[email protected]> > Cc: [email protected]; Mike Jones > <[email protected]>; Jim Schaad <[email protected]>; > [email protected]; [email protected]; [email protected] > Subject: Ben Campbell's No Objection on > draft-ietf-jose-jws-signing-input- > options-07: (with COMMENT) > > Ben Campbell has entered the following ballot position for > draft-ietf-jose-jws-signing-input-options-07: 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 > https://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: > https://datatracker.ietf.org/doc/draft-ietf-jose-jws-signing-input-opt > ions/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > -7, last paragraph: > > " Thus, method 1 - > requiring support for this extension - is the preferred approach and > the only means for this extension to be practically useful to > applications." > > One might wonder why method 2 and 3 are included. I assume it is to > allow existing apps to migrate to method 1 over time? If so, some > guidance on app migration might be useful. Methods 2 and 3 are not about application functionality migration. In both of these cases, the application doesn't work if it doesn't support the extension, so there's no migration path enabled by them. They're there strictly to describe how to ensure that JWSs that would be misunderstood by recipients not implementing the extension are cleanly rejected by those implementations, rather being processed with incorrect payloads. I'll look into adding text to that effect in the draft. > Editorial: > > -6, last paragraph: > It’s confusing to see "(JWT) [JWT]" . I suggest either removing (JWT), > or changing the anchor for the citation to use [RFC7519] Barry made the same observation. :-) Will do. Thanks again, -- Mike _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
