My inclination is to say that this is not a valid Errata. The complaint is really against the tools and not the document as the complaint is dealing with the line, which is not part of the RFC, rather than with either technical or editorial content of the document.
I believe that the original text is sufficiently clear as to which section is being referred to for a human. But it would not be clear to a tool. The suggested change may or may not fix that for the tool and a better approach is probably to start using the xml source for the generation of the html page rather than to fix up the text version. Jim > -----Original Message----- > From: RFC Errata System [mailto:[email protected]] > Sent: Friday, December 04, 2015 7:17 AM > To: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: [Editorial Errata Reported] RFC7515 (4554) > > The following errata report has been submitted for RFC7515, "JSON Web > Signature (JWS)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7515&eid=4554 > > -------------------------------------- > Type: Editorial > Reported by: Simon <[email protected]> > > Section: 2 > > Original Text > ------------- > Base64url Encoding > Base64 encoding using the URL- and filename-safe character set > defined in Section 5 of RFC 4648 [RFC4648], with all trailing \\'=\\' > characters omitted (as permitted by Section 3.2) and without the > inclusion of any line breaks, whitespace, or other additional > characters. Note that the base64url encoding of the empty octet > sequence is the empty string. (See Appendix C for notes on > implementing base64url encoding without padding.) > > Corrected Text > -------------- > Base64url Encoding > Base64 encoding using the URL- and filename-safe character set > defined in Section 5 of RFC 4648 [RFC4648], with all trailing \\'=\\' > characters omitted (as permitted by Section 3.2 of RFC 4648) and > without the inclusion of any line breaks, whitespace, or other > additional characters. Note that the base64url encoding of the > empty octet sequence is the empty string. (See Appendix C for > notes on implementing base64url encoding without padding.) > > Notes > ----- > in the html version https://tools.ietf.org/html/rfc7515 the link on \\"Section > 3.2\\" goes to Section 3.2 of RFC7515 but it should go to Section 3.2 of > RFC4648. Not sure how the automatic link generation is made (or is it manual?), > so i would propose explicitly saying \\"Section 3.2 of RFC 4648\\". > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please use "Reply > All" to discuss whether it should be verified or rejected. When a decision is > reached, the verifying party (IESG) can log in to change the status and edit the > report, if necessary. > > -------------------------------------- > RFC7515 (draft-ietf-jose-json-web-signature-41) > -------------------------------------- > Title : JSON Web Signature (JWS) > Publication Date : May 2015 > Author(s) : M. Jones, J. Bradley, N. Sakimura > Category : PROPOSED STANDARD > Source : Javascript Object Signing and Encryption > Area : Security > Stream : IETF > Verifying Party : IESG _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
