So, just to be clear, I'm approving all of these errata, yes?
That's what I'd do.
On Wed, Aug 03, 2022 at 6:38 PM, John R. Levine <jo...@iecc.com> wrote:
On Wed, 3 Aug 2022, Dave Crocker wrote:
Original Text
-------------
| URI | _acct | [RFC6118] |
Corrected Text
--------------
| URI | _acct | [RFC7566] |
In Spring, 2018 and again in Fall, 2018, there was some focused discussion
(see: dnsop) about _acct, and related strings, and which citation to use
for the enum-related values. The choice bounced around, as I've cited.
This includes having what is now being deemed the 'correct' choice in
-14...
Note that none of the cited documents refers to the exact string "_acct".
So there is a derivation process that seems to be unclear. I believe the
attrleaf RFC contains no pedagogy about this, but it probably should.
I remember the rather long discussions about the possible collisions in
URI names between transport and enumservice names, and again about whose
job it is to keep registries in sync. Bu in this case we made a clerical
mistake, and missed the important detail that after the enumservices update
in RFC 6118, some of the types were added in later RFCs.
Having looked at all of Bernie's errata, I don't think any of them present
subtle errors. There was an eye-glazing list of entries in that document
and we unsurprisingly missed a few details.
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for
Dummies", Please consider the environment before reading this e-mail.
https://jl.ly
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
