These changes have been applied in the -21 drafts.
-- Mike
From: jose [mailto:[email protected]] On Behalf Of Mike Jones
Sent: Friday, February 07, 2014 4:46 PM
To: Jim Schaad; [email protected]
Subject: Re: [jose] Issue #90 - Section 9 References
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]<mailto:[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
