> -----Original Message-----
> From: iesg <iesg-boun...@ietf.org> On Behalf Of Barry Leiba
> Sent: 01 June 2020 14:24
> To: Rob Wilton (rwilton) <rwilton=40cisco....@dmarc.ietf.org>
> Cc: RFC Errata System <rfc-edi...@rfc-editor.org>; m...@microsoft.com;
> Benjamin Kaduk <ka...@mit.edu>; ve7...@ve7jtb.com;
> hannes.tschofe...@gmx.net; oauth@ietf.org; Pete Resnick
> <resn...@episteme.net>; i...@ietf.org
> Subject: Re: [Errata Verified] RFC7800 (6187)
>
> Further on this:
>
> In the "editorial" realm, there are two classes of "correct" errata
> reports:
>
> 1. Trivial and obvious typos, such as spelling "and" as "adn".
>
> 2. Others, such as a number with transposed digits, which could,
> indeed, be confusing.
[RW]
This seems entirely reasonable.
>
> The guideline that we're discussing is meant to separate those out,
> saying that class 1 should go to HFDU, while class 2 might qualify as
> Verified. Whether a particular report falls into class 1 or 2 is
> usually clear, but sometimes a matter of judgment. And then whether a
> class 2 report rates Verified or HFDU is also sometimes a matter of
> judgment. I'm personally happy with leaving that to judgment, rather
> than trying to be overly rigorous about making rules for it. I'm also
> happy with the idea of clarifying or altering the guidelines, if
> someone wants to make a specific proposal.
[RW]
Personally, at least for new ADs, I think that it would probably be useful to
clarify the guidelines.
I could propose some text, but I think that the first question to answer really
relates to the inline-errata output. It would be nice if spelling and
grammatical mistakes were included in the inline-errata, since there seems to
be no good reason why they should not be and they may be helpful to a
non-native speaker. If only "verified" errata can be included inline then it
might be an idea to classify these as something like "verified,
inconsequential".
Thanks,
Rob
>
> One thing we have talked about is having the RPC handle editorial
> class 1 reports, and we can discuss that again if we like. Should we
> do that, it might make sense to have a separate handling code for
> those that the RPC resolves.
>
> Barry
>
> On Mon, Jun 1, 2020 at 9:16 AM Barry Leiba <barryle...@computer.org>
> wrote:
> >
> > That's what the "technical" vs "editorial" distinction is supposed to be
> for.
> >
> > Barry
> >
> > On Mon, Jun 1, 2020 at 8:27 AM Rob Wilton (rwilton)
> > <rwilton=40cisco....@dmarc.ietf.org> wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: iesg <iesg-boun...@ietf.org> On Behalf Of Benjamin Kaduk
> > > > Sent: 31 May 2020 05:09
> > > > To: Pete Resnick <resn...@episteme.net>
> > > > Cc: m...@microsoft.com; i...@ietf.org; ve7...@ve7jtb.com;
> > > > hannes.tschofe...@gmx.net; oauth@ietf.org; RFC Errata System <rfc-
> > > > edi...@rfc-editor.org>
> > > > Subject: Re: [Errata Verified] RFC7800 (6187)
> > > >
> > > > The new text is clearly the right thing, and there is no need
> > > > to debate it if/when the document gets updated. "Don't hold
> > > > it; do it now", so to speak -- and noting that (my
> > > > understanding/recollection of) the plan for
> > > > https://www.rfc-editor.org/rfc/inline-errata/rfc7800.html is that
> only
> > > > verified errata, not those in other states, will be displayed.
> > > [RW]
> > >
> > > If this ends up being the plan, then I think that we may wish to
> modify the RFC guidance, or possibly have two different verified states:
> > > (i) Verified, could impact implementations
> > > (ii) Verified, editorial only.
> > >
> > > Certainly, it seems to be makes sense for these sorts of errata to be
> displayed.
> > >
> > > Regards,
> > > Rob
> > >
> > >
> > > >
> > > > (Yes, that link 404s at the moment, I assume a caching issue.)
> > > >
> > > > -Ben
> > > >
> > > > On Sat, May 30, 2020 at 10:55:01PM -0500, Pete Resnick wrote:
> > > > > "Verified", not "Hold For Document Update"?
> > > > >
> > > > > pr
> > > > >
> > > > > On 30 May 2020, at 20:34, RFC Errata System wrote:
> > > > >
> > > > > > The following errata report has been verified for RFC7800,
> > > > > > "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)".
> > > > > >
> > > > > > --------------------------------------
> > > > > > You may review the report below and at:
> > > > > > https://www.rfc-editor.org/errata/eid6187
> > > > > >
> > > > > > --------------------------------------
> > > > > > Status: Verified
> > > > > > Type: Editorial
> > > > > >
> > > > > > Reported by: Pete Resnick <resn...@episteme.net>
> > > > > > Date Reported: 2020-05-26
> > > > > > Verified by: Benjamin Kaduk (IESG)
> > > > > >
> > > > > > Section: 7.1
> > > > > >
> > > > > > Original Text
> > > > > > -------------
> > > > > > [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517,
> > > > > > DOI 10.17487/RFC7157, May 2015,
> > > > > > <http://www.rfc-editor.org/info/rfc7517>.
> > > > > >
> > > > > >
> > > > > > Corrected Text
> > > > > > --------------
> > > > > > [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517,
> > > > > > DOI 10.17487/RFC7517, May 2015,
> > > > > > <http://www.rfc-editor.org/info/rfc7517>.
> > > > > >
> > > > > >
> > > > > > Notes
> > > > > > -----
> > > > > > DOI has a typo: 7157 instead of 7517.
> > > > > >
> > > > > > --------------------------------------
> > > > > > RFC7800 (draft-ietf-oauth-proof-of-possession-11)
> > > > > > --------------------------------------
> > > > > > Title : Proof-of-Possession Key Semantics for JSON
> Web
> > > > > > Tokens (JWTs)
> > > > > > Publication Date : April 2016
> > > > > > Author(s) : M. Jones, J. Bradley, H. Tschofenig
> > > > > > Category : PROPOSED STANDARD
> > > > > > Source : Web Authorization Protocol
> > > > > > Area : Security
> > > > > > Stream : IETF
> > > > > > Verifying Party : IESG
> > > > >
> > > > >
> > > > > --
> > > > > Pete Resnick https://www.episteme.net/
> > > > > All connections to the world are tenuous at best
> > >
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
