Subject: [jose] Issue #90 - Section 9 References

From: "Jim Schaad" <[email-masked]>
Date: Fri, 7 Feb 2014 14:14:17 -0800

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?

---

From: Mike Jones <[email-masked]>
Date: Fri, 7 Feb 2014 23:39:41 +0000

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.

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.

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.

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.

RFC 3986 defines URI and the specs use URIs - therefore I believe that this is a normative reference.

                                                                -- Mike

From: jose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Friday, February 07, 2014 2:14 PM
To: [email-masked]
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

Algorithms draft -

-          RFC 5116 - this reference is going to disappear since it is just used in the changes section.

-          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

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 7 Feb 2014 16:34:15 -0800

From: Mike Jones [mailto:[email-masked]] 
Sent: Friday, February 07, 2014 3:40 PM
To: Jim Schaad; [email-masked]
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.

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?

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?

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.

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?

                                                                -- Mike

Algorithms draft -

Signature Draft

---

From: Mike Jones <[email-masked]>
Date: Sat, 8 Feb 2014 00:46:17 +0000

Replies inline marked [mbj]...

From: jose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Friday, February 07, 2014 4:34 PM
To: Mike Jones; [email-masked]
Subject: Re: [jose] Issue #90 - Section 9 References

From: Mike Jones [mailto:[email-masked]]
Sent: Friday, February 07, 2014 3:40 PM
To: Jim Schaad; [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] Issue #90 - Section 9 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.

[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.

[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).

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-masked]] On Behalf Of Jim Schaad
Sent: Friday, February 07, 2014 2:14 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [jose] Issue #90 - Section 9 References

Algorithms draft -

Signature Draft

---

From: Mike Jones <[email-masked]>
Date: Sat, 15 Feb 2014 01:46:37 +0000

These changes have been applied in the -21 drafts.

                                                                -- Mike

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, February 07, 2014 4:46 PM
To: Jim Schaad; [email-masked]
Subject: Re: [jose] Issue #90 - Section 9 References

From: jose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Friday, February 07, 2014 4:34 PM
To: Mike Jones; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Issue #90 - Section 9 References

                                                                -- Mike

Algorithms draft -

Signature Draft