On 10. Dec 2024, at 22:02, Joel Halpern <j...@joelhalpern.com> wrote: > > 4) Related to 3, citing an I-D for an IANA registry that requires a stable > specification seems very odd.
I agree with your first three points, but this one is off. The I-D by definition is guaranteed stable and accessible, so that is not the problem. Whether it actually fulfills the requirements of Section 4.6 of RFC 8126 is for the designated expert to decide. The RFC that created the registry can give instructions to the DE, including about whether an I-D or a GitHub page or any other page on the Web is acceptable or the specification requires some blessing beyond that (good luck with defining that precisely, but the designated experts can make a decision). > Do we intend the code point to mean any version of the document (even though > they probably differ? No! The code point is tied to the stable document (which happens to be an I-D here). Of course, there should be a way to update a reference, and I would expect the designated expert to have a look when such an update is desired whether the requirements of Section 4.6 of RFC 8126 are violated by it. > Do we intend the code point to mean the behavior in this version of the > document, even though the IETF may later decide that the right behavior is > something else? Yes! (More precisely: Get a new code point if you need to indicate the new behavior to prevent false interoperability. Deprecate the old code point if that is actively harmful. Don’t get a new code point if old behavior and new behavior can interoperate.) There is a change controller for each registration, and that (together with the designated expert) can manage such kinds of evolution in such a way that there is an acceptable outcome. > If we claimed to want a stable specification so implementations using the > code point interoperate (as distinct from an FCFS registry where the point is > just to make sure folks don't collide) then we need to actually be stable. Yes, modulo bug fixing (see above). > (If we discover that while we thought we wanted interoperable code points all > we really want is non-conflicting code points then fix the rules for the > specific registry.) Well, that can be complicated [1]. But you put this point into parentheses, so I think you agree that this isn’t a required part of the solution. The nice thing is that we already have all the above in place and working; we actually don’t need to change anything. (The likely outcome of any protracted change process is that we have wasted a lot of time and made the actual result in terms of the resulting behavior of the people involved worse. See Eliot’s concerns above.) Grüße, Carsten [1]: https://www.ietf.org/archive/id/draft-fossati-core-cf-reg-update-03.html _______________________________________________ rfc-interest mailing list -- rfc-interest@rfc-editor.org To unsubscribe send an email to rfc-interest-le...@rfc-editor.org
