Oops, wrong one. I had already marked this one as rejected with the reason. I guess it doesn't matter that it was deleted instead.
Thanks, Kathleen On Tue, Dec 8, 2015 at 11:22 AM, Kathleen Moriarty <[email protected]> wrote: > Hi Megan, > > How will they know to add this text back in without the Hold for > Document Update? I'm afraid removing this will cause trouble down the > road as opposed to leaving it the way I had marked it unless a held > version is corrected. > > Thanks, > Kathleen > > On Tue, Dec 8, 2015 at 11:16 AM, Megan Ferguson <[email protected]> wrote: >> 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 >>>>> >>> >> > > > > -- > > Best regards, > Kathleen -- Best regards, Kathleen _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
