Re: [jose] [Editorial Errata Reported] RFC7515 (4554)

[Mike Jones <[e-mail]>]

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:[e-mail]] 
Sent: Tuesday, December 8, 2015 6:13 AM
To: Kathleen Moriarty <[e-mail]>
Cc: Jim Schaad <[e-mail]>; RFC Errata System <[e-mail]>; Mike Jones <[e-mail]>; Nat Sakimura <[e-mail]>; Stephen Farrell <[e-mail]>; Karen Odonoghue <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Editorial Errata Reported] RFC7515 (4554)

+1

> On Dec 8, 2015, at 10:58 AM, Kathleen Moriarty <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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:[e-mail]]
>>>> Sent: Friday, December 04, 2015 7:17 AM
>>>> To: [e-mail]; [e-mail]; [e-mail]; 
>>>> [e-mail]; [e-mail]; 
>>>> [e-mail]; [e-mail]
>>>> Cc: [e-mail]; [e-mail]; [e-mail]
>>>> 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 <[e-mail]>
>>>> 
>>>> 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
>>