Subject: Re: [jose] [Editorial Errata Reported] RFC7515 (6118)

From: John Bradley <[email-masked]>
Date: Sun, 3 May 2020 20:30:39 -0400

+1

The normative version is text.

One day this will be fixed for new RFC but not for existing ones.

On Wed, Apr 22, 2020, 4:23 PM Jim Schaad <[email-masked]> wrote:

> This is a tooling issue and not an issue of the document itself.
>
> Jim
>
>
> -----Original Message-----
> From: RFC Errata System <[email-masked]>
> Sent: Wednesday, April 22, 2020 1:10 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Editorial Errata Reported] RFC7515 (6118)
>
> The following errata report has been submitted for RFC7515, "JSON Web
> Signature (JWS)".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6118
>
> --------------------------------------
> Type: Editorial
> Reported by: Jason Heiss <[email-masked]>
>
> Section: 2
>
> Original Text
> -------------
> (as permitted by Section 3.2)
>
> Corrected Text
> --------------
>
>
> Notes
> -----
> This appears to be a reference to section 3.2 of RFC 4648, but because it
> is somewhat ambiguous the HTML and PDF versions of the RFC link to section
> 3.2 of this RFC instead.
>
> 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 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
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 4 May 2020 08:00:10 +0200

[On the usual problem with htmlizing links to other RFCs:]

> One day this will be fixed for new RFC but not for existing ones. 

Why not?

It would be a SMOP(*) to invest the htmlizer with knowledge about misdirected links that were discovered in existing RFCs.  Each of these errata reports (and all the existing rejected ones) would inform this.

Grüße, Carsten

(*) SMOP: Small matter of programming.
Usually said by people who don’t want to do the work themselves.

---

From: John Bradley <[email-masked]>
Date: Mon, 4 May 2020 08:31:13 -0400

It may be possible to improve the tools, however TEXT to HTML has been a
issue for a long time.

The exesting TEXT RFC 7515 won't change.  Perhaps the HTML rendering
will imporove, but our best bet is still the impovement in the nomative
version to be something other than TEXT.

In any event nothing that a eratta to RFC7515 can help with.

John B.

On 5/4/2020 2:00 AM, Carsten Bormann wrote:
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 4 May 2020 16:53:06 +0200

> It may be possible to improve the tools, however TEXT to HTML has been a

Yes.  And the SMOP below solves that problem nicely.

> The exesting TEXT RFC 7515 won't change.  

It doesn’t need to (as long as it is read by a human).
The issue is that the htmlizer’s heuristics only have limited AI.

> Perhaps the HTML rendering

Which is already the case with the RFCXMLv3 transition.

> In any event nothing that a eratta to RFC7515 can help with.

No, but the report is still useful as the information in it could go into the database the SMOP uses.
I just picked this specific report for responding as it is number N+1 of the same kind, where N is the number where I’m finally losing the patience needed to ignore the problem.

Grüße, Carsten

---

From: Robert Sparks <[email-masked]>
Date: Mon, 4 May 2020 10:19:00 -0500

Hi Carsten -

How is the SMOP you are envisioning different from the inline-errata 
tooling?

See https://www.rfc-editor.org/rfc/inline-errata/rfc6016.html or 
https://www.rfc-editor.org/rfc/inline-errata/rfc8400.html for small 
examples.

https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html#btn_1051 and 
https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html#btn_1470 show 
placers where the errata could be algorithmically applied directly to 
the text.

RjS

On 5/4/20 9:53 AM, Carsten Bormann wrote:
> ___________________________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
>
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to [email-masked]
>
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to [email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Mon, 4 May 2020 17:30:32 +0200

On 04.05.2020 17:19, Robert Sparks wrote:
> ...

The inline errata tooling can only help if something is an actual
erratum (some kind of a bug in the published RFC).

The thing discussed above refers to a bug introduced by the "rfcmarkup"
tool, which transforms the plain text version into HTML, and
occasionally messes up section links.

FWIW, I agree with Carsten that some kind of exception list would help
in that at least we wouldn't get the same errata reports all over again.

Best regards, Julian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 5 May 2020 08:47:11 +1200

An even SmallerMOP is to add a disclaimer to the info block at the head of
each HTMLised RFC. Fixed it for you:
https://www.cs.auckland.ac.nz/~brian/RFC7515x.html

Regards
   Brian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 4 May 2020 22:53:44 +0200

> https://www.cs.auckland.ac.nz/~brian/RFC7515x.html

s/a disclaimer/noise/

— increases usability in no way
— won’t be read anyway...

My SMOP is better (sent code to Robert already).

Grüße, Carsten