All, FYI, this report has been removed. We will forward notice to [email protected].
Thank you. RFC Editor/mf On Dec 8, 2015, at 11:04 AM, Mike Jones <[email protected]> wrote: > Agreed. I'll note that the HTML produced by xml2rfc directly from the XML > source doesn't have this problem. Unfortunately, the RFCmarkup tool that's > used to produce the HTML that's posted based on the .txt version has > heuristics that are wrong. Does anyone know how Simon can instead file a bug > against RFCmarkup? (And to people know whether the plan is to drop using > RFCmarkup once the RFC evolution changes roll out?) > > -- Mike > > -----Original Message----- > From: John Bradley [mailto:[email protected]] > Sent: Tuesday, December 8, 2015 6:13 AM > To: Kathleen Moriarty <[email protected]> > Cc: Jim Schaad <[email protected]>; RFC Errata System > <[email protected]>; Mike Jones <[email protected]>; Nat > Sakimura <[email protected]>; Stephen Farrell <[email protected]>; > Karen Odonoghue <[email protected]>; [email protected]; [email protected] > Subject: Re: [Editorial Errata Reported] RFC7515 (4554) > > +1 > >> On Dec 8, 2015, at 10:58 AM, Kathleen Moriarty >> <[email protected]> wrote: >> >> Thanks for your advice on this. >> >> How about I mark it as 'editorial' and hold for document update, then add a >> note that says the normative section is correct and this is just an HTML >> markup from txt issue? >> >> Thanks, >> Kathleen >> >> Sent from my iPhone >> >>> On Dec 8, 2015, at 8:47 AM, John Bradley <[email protected]> wrote: >>> >>> I agree, Rfcmarkup strikes again:) >>> >>> The canonical version is txt and that is correct. >>> >>> The link is probably correct in the XML version. >>> One day we will publish RFC from the XML and can get rid of these stupid >>> HTML markup from TXT issues. >>> >>> Worth keeping a note of if we do do an errata and can publish in XML. >>> >>> Until that time nothing to do for it. >>> >>> John B. >>> >>>> On Dec 8, 2015, at 1:21 AM, Jim Schaad <[email protected]> wrote: >>>> >>>> >>>> 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
