These comments are addressed in the -34 specification. Thanks again for your
review.
-- Mike
From: Alissa Cooper [mailto:[email protected]]
Sent: Wednesday, October 01, 2014 11:10 AM
To: Mike Jones
Cc: IESG; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: Re: Alissa Cooper's No Objection on
draft-ietf-jose-json-web-encryption-33: (with COMMENT)
Hi Mike,
On Sep 29, 2014, at 3:50 PM, Mike Jones
<[email protected]<mailto:[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]<mailto:[email protected]>;
[email protected]<mailto:[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
