Subject: [OAUTH-WG] [Errata Rejected] RFC8176 (6314)

From: RFC Errata System <[email-masked]>
Date: Tue, 20 Oct 2020 09:21:45 -0700 (PDT)

The following errata report has been rejected for RFC8176,
"Authentication Method Reference Values".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6314

--------------------------------------
Status: Rejected
Type: Editorial

Reported by: David Brossaard <[email-masked]>
Date Reported: 2020-10-20
Rejected by: Benjamin Kaduk (IESG)

Section: 1.

Original Text
-------------
For context, the "amr" (Authentication Methods References) claim is
   defined by Section 2 of the OpenID Connect Core 1.0 specification
   [OpenID.Core] as follows:

Corrected Text
--------------
For context, the "amr" (Authentication Methods References) claim is
   defined by Section 2 of the OpenID Connect Core 1.0 specification
   [OpenID.Core] as follows:

Notes
-----
There is no text change but the link on "Section 2" points to section 2 in the same RFC rather than section 2 in the OpenID Connect Core 1.0 specification.
 --VERIFIER NOTES-- 
Errata reports are for reporting issues with the authoritative RFC version(s) as published by the RFC Editor.  RFC 8176 predates the usage of the "v3 XML" format, so the plain text version is the authoritative one, and thus questions of HTML links are irrelevant for it.

--------------------------------------
RFC8176 (draft-ietf-oauth-amr-values-08)
--------------------------------------
Title               : Authentication Method Reference Values
Publication Date    : June 2017
Author(s)           : M. Jones, P. Hunt, A. Nadalin
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 20 Oct 2020 09:24:16 -0700

> Errata reports are for reporting issues with the authoritative RFC version(s) as published by the RFC Editor.  RFC 8176 predates the usage of the "v3 XML" format, so the plain text version is the a…

For what it's worth, this "bad HTML link" situation occurs with some
regularity -- the "html" versions of non-v3-XML RFCs are created by running
a script over the text version.  The script uses heuristics to convert
certain types of text into links, and "Section <N>" gets expanded to this
document unless followed by "of RFC <Y>".  I believe this script is
open-source and patches would be welcome, though I don't know the location
of the source-code repository in question off the top of my head.

-Ben

---

From: David Brossard <[email-masked]>
Date: Tue, 20 Oct 2020 09:26:21 -0700

Thanks Ben (and apologies about the double submission).

In this case, given the reference is not an RFC, that would explain why the
script failed. Can we do a manual fix after the script has run to update
the RFC?

On Tue, Oct 20, 2020 at 9:24 AM Benjamin Kaduk <[email-masked]> wrote:

> > Errata reports are for reporting issues with the authoritative RFC
> version(s) as published by the RFC Editor.  RFC 8176 predates the usage of
> the "v3 XML" format, so the plain text version is the authoritative one,
> and thus questions of HTML links are irrelevant for it.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
*David Brossard*
Sr. Director of Product Management
Identity, Authentication, Federation, and Single Sign-On | Salesforce
c: +1 502-922-6538 (US) | +1 236-333-6379 (Canada)
Learn more about identity here
<https://trailhead.salesforce.com/content/learn/modules/identity_basics/identity_basics_product>
|
Identity for Developers
<https://developer.salesforce.com/developer-centers/identity/>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 20 Oct 2020 09:31:45 -0700

[adding back [email-masked]]

Hi David,

I am quite far removed from the actual operation of the script and the
rfc-editor.org website, so I don't know the answer to your question.  That
said, my understanding is that it's set up with automation that assumes the
script is idempotent, and can regenerate various bits from scratch in
certain cases, so a manual edit might not be very reliable.

-Ben

---

From: Sandy Ginoza <[email-masked]>
Date: Tue, 20 Oct 2020 11:49:47 -0700

Hi all,

The HTML file (available from https://www.rfc-editor.org/rfc/rfc8176 <https://www.rfc-editor.org/rfc/rfc8176>) was generated using rfc2html (https://www.pypi.org/project/rfc2html <https://www.pypi.org/project/rfc2html>). Please feel free to direct questions to the maintainers listed on that page.

Thanks,
RFC Editor/sg

> On Oct 20, 2020, at 9:31 AM, Benjamin Kaduk <[email-masked]> wrote:
>