Re: [OAUTH-WG] [Editorial Errata Reported] RFC7591 (6619)

["John R. Levine" <[e-mail]>]

> Fair enough, I guess. The HTML versions of the older RFCs must be peppered with bad links if this is the case.

Yes, we've gotten a steady trickle of reports like this.

The htmlizing script is available if someone wants to play with it but I 
think we're already in the region of diminishing returns, and I don't 
think there's any appetite to manually create exception lists for the 
links point in old RFCs.

R's,
John

>
> From: John R. Levine <[e-mail]>
> Date: Tuesday, June 22, 2021 at 7:03 PM
> To: RFC Errata System <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
> Cc: Dave Isaacs <[e-mail]>, [e-mail] <[e-mail]>
> Subject: Re: [Editorial Errata Reported] RFC7591 (6619)
> Htmlized legacy RFCs are created by a script that uses heuristics to add
> formatting to the canonical text document.  One of the limitations of the
> script is that it does not know when a section link is to another
> document.
>
> For RFCs published since we switched to XML v3 two years ago, the HTML is
> created directly from the XML and the links are correct.
>
> Since the underlying RFC is correct and currrent RFCs don't have the
> problem we're not planning to try to fix it.
>
> Regards,
> John Levine, temporary RFC series manager
>
> On Tue, 22 Jun 2021, RFC Errata System wrote:
>
>> The following errata report has been submitted for RFC7591,
>> "OAuth 2.0 Dynamic Client Registration Protocol".
>>
>> --------------------------------------
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid6619
>>
>> --------------------------------------
>> Type: Editorial
>> Reported by: Dave Isaacs <[e-mail]>
>>
>> Section: 2
>>
>> Original Text
>> -------------
>> token_endpoint_auth_method
>>      String indicator of the requested authentication method for the
>>      token endpoint.  Values defined by this specification are:
>>
>>      *  "none": The client is a public client as defined in OAuth 2.0,
>>         Section 2.1, and does not have a client secret.
>>
>>      *  "client_secret_post": The client uses the HTTP POST parameters
>>         as defined in OAuth 2.0, Section 2.3.1.
>>
>>      *  "client_secret_basic": The client uses HTTP Basic as defined in
>>         OAuth 2.0, Section 2.3.1.
>>
>> Corrected Text
>> --------------
>> Text unchanged. It is the links that are incorrect.
>>
>> Notes
>> -----
>> The links that are present in each bullet—to Section 2.1, and to Section 2.3.1 (twice)—link internally to the current RFC (RFC 7591) when they are supposed to link to the OAuth 2.0 RFC (RFC 6749).
>>
>> 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.
>>
>> --------------------------------------
>> RFC7591 (draft-ietf-oauth-dyn-reg-30)
>> --------------------------------------
>> Title               : OAuth 2.0 Dynamic Client Registration Protocol
>> Publication Date    : July 2015
>> Author(s)           : J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt
>> Category            : PROPOSED STANDARD
>> Source              : Web Authorization Protocol
>> Area                : Security
>> Stream              : IETF
>> Verifying Party     : IESG
>>
>>
>
> Regards,
> John Levine, [e-mail], Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly
> Have you heard? SurveyMonkey (SVMK Inc.) is now Momentive. Learn more at momentive.ai<https://momentive.ai>
>

Regards,
John Levine, [e-mail], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly