Yes, this is the path if things need to change in an RFC. But in this case, the question was about something that is already in the current RFC text that doesn’t need to change. I was trying to point out that "proposed standard" is code for the final text of that RFC. In this instance, carrying on the work really is implementing it, not changing the text in question, which was agreed with.
— Justin On Oct 10, 2024, at 10:00 AM, Pierce Gorman <pierce.gor...@numeracle.com> wrote: It might be worth reviewing how updates or changes are made available to a completed “Proposed Standard”. In my experience I’ve seen: * Errata * An updated version noted as RFC xxxx bis (where bis is Old Latin for “repeat”) * A new Internet-Draft which, if promoted to “Proposed Standard” may obsolete or deprecate all or a portion of a previous RFC. I’m pretty sure I’ve mangled the part about “obsolete” and “deprecate” but hopefully that helps some. Pierce From: Justin Richer <jric...@mit.edu<mailto:jric...@mit.edu>> Sent: Thursday, October 10, 2024 8:51 AM To: Lee, Matt D <Matt.Lee=40kbslp.cl...@dmarc.ietf.org<mailto:Matt.Lee=40kbslp.cl...@dmarc.ietf.org>> Cc: oauth@ietf.org<mailto:oauth@ietf.org> Subject: [OAUTH-WG] Re: RFC 9068 You don't often get email from jric...@mit.edu<mailto:jric...@mit.edu>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> EXTERNAL EMAIL My apologies - I just realized that I mistakenly typed "RFC6086" on the first part of the message, to be clear the entire comment is in fact about RFC9068. — Justin On Oct 10, 2024, at 9:48 AM, Justin Richer <jric...@mit.edu<mailto:jric...@mit.edu>> wrote: Hi Matt, RFC6086 is published and final — there is not ongoing work on that document, because it is complete. I’m sure there is also other work happening all around about profiling JWTs for specific purposes and circumstances. The wording of "Proposed Standard" can be confusing. It does not mean that the document is still in process. Instead, it speaks to the nature of organizations like the IETF: we can only really propose and describe standards, it’s the implementations that make those standards concrete in the real world. With that in mind, the best way to continue the work of RFC9068 is to implement it and advocate for others to implement it as well. — Justin On Oct 8, 2024, at 4:41 PM, Lee, Matt D <Matt.Lee=40kbslp.cl...@dmarc.ietf.org<mailto:Matt.Lee=40kbslp.cl...@dmarc.ietf.org>> wrote: First, my sincerest condolences regarding the loss of Vittorio Bertocci, someone who had an astonishing impact on the industry and community at large. I was reminded of this loss today as I was having a conversation with some peers about the optional nature of the sub claim in JWTs used in OAuth grants. After we searched for guidance we found this proposed standard from Vittorio that would move sub from optional to required, and wondered if anyone was picking this up now that he has passed. Thank you Matt Lee | KGS Enterprise Architect _______________________________________________ OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org> To unsubscribe send an email to oauth-le...@ietf.org<mailto:oauth-le...@ietf.org> _______________________________________________ OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org> To unsubscribe send an email to oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
