Replies inline marked [mbj]... From: jose [mailto:[email protected]] On Behalf Of Jim Schaad Sent: Friday, February 07, 2014 4:34 PM To: Mike Jones; [email protected] Subject: Re: [jose] Issue #90 - Section 9 References
From: Mike Jones [mailto:[email protected]] Sent: Friday, February 07, 2014 3:40 PM To: Jim Schaad; [email protected]<mailto:[email protected]> Subject: RE: [jose] Issue #90 - Section 9 References RFC 5116 is used in the JWA security considerations. I believe that security considerations are normative, correct? (RESPONSE TO THIS QUESTION REQUESTED) Otherwise this can be moved to the set of informative references. [JLS] No they are not considered normative. They can be either normative or informative depending on what and how much of the document needs to be understood in order to correctly implement the current protocol. It is always a value judgment. [mbj] OK, if the security consideration references aren't normative, I'll move them to the Informative References section. The "Specification Required" in RFC 5226 is required to be understood by people registering registry values, and therefore seems normative to me - at least for those using the registry. This imposes a normative requirement on specification writers. [JLS] So - do I need to understand RFC 5226 in order to either understand or implement JOSE? [mbj] If the criteria is only normative requirements on implementers, versus normative requirements on people using the registries defined, I'll move them to the Informative References section. draft-mcgrew-aead-aes-cbc-hmac-sha2 is definitely not required by implementers, since all the relevant normative content has been copied into JWA. The reference is there for background or historical reasons only - clearly fitting the criteria for informative references. In fact, the draft appears to have been abandoned - having expired, despite specific requests for specific changes that would make it more JOSE-friendly having been communicated to the author quite a while ago. [JLS] In that case - why have the reference at all? [mbj] To give credit where credit is due (and in hopes that David will eventually apply the requested updates so we don't have to continue duplicating the normative text). What specific references in JWS do you believe will not be present in the final text? If the will not be present in the final text, I agree that they should be non-normative. Yes, section 15.12 (The JSON Object) of ECMAScript must be understood by implementers, since it specifies the "lexically last duplicate member name" semantics, which are required by JOSE. [JLS] And you have stated that explicitly in the document - so why make the reference at all - except to say that this is the same thing they do? That is not normative. [mbj] This seems like a judgment call to me, since ECMASCript defines the "lexically last duplicate member name semantics" and JOSE requires its use. That seems normative to me, even if we paraphrase the requirement in the JOSE specs. RFC 3986 defines URI and the specs use URIs - therefore I believe that this is a normative reference. [JLSJ] In order to implement JOSE - do I need to understand all of the details of URIs or can I just treat them as opaque strings? [mbj] This seems like another judgment call. We're using URIs in normative definitions, so a normative reference seems appropriate to me. What do others think in this case? -- Mike From: jose [mailto:[email protected]] On Behalf Of Jim Schaad Sent: Friday, February 07, 2014 2:14 PM To: [email protected]<mailto:[email protected]> Subject: [jose] Issue #90 - Section 9 References I'll start with a quote from the RFC Editor "Instructions to Request for Comments (RFC) Authors" Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. An informative reference is not normative; rather, it provides only additional information. For example, an informative reference might provide background or historical information. Material in an informative reference is not required to implement the technology in the RFC. Based on the above criteria, there are a number of references which I believe are not in the correct bucket. I would ask the authors to review this prior to WGLC ending and re-evaluate based on the above criteria Examples of things that I think are misplaced: Algorithms draft - - RFC 5116 - this reference is going to disappear since it is just used in the changes section. - RFC 5226 - Don't know why implementers would ever care about this - McGrew-aed-aes-cbc-hmac-sha2 - you need to know how to do this in order to implement - thus it should be normative Signature Draft - Some of the drafts here are not reference in long term text Is ECMAScript something that needs to be understood? Is 3986 really a normative reference?
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
