On Wed, Dec 11, 2024 at 10:35 AM Eliot Lear <[email protected]> wrote: > This is not to say that drafts can't still get code point assignments, but > that those assignments should clearly be marked as for development purposes. > Most of the time, the only value in having a code point assignment is that nobody else will get that same assignment.
I really don't care what my SRV prefix is in DNS. But I care that nobody else will get it. I care about that A LOT. And when we were writing the SAML specs and I tried to get prefixes assigned, the response from IETF was unprofessional and unpleasant to say the least. That was back in the days when people imagined prefixes were to be jealously guarded less the unwitting corrupted them. So I went and did what any self respecting engineer would do in that situation. Faced with a preposterous demand for what should have been a purely administrative recording of a code point, I MADE MY OWN UP. And that is what is happening in the real world and will continue to happen because IANA is not a control point, either IANA records code points as they are used or the registries become increasingly incomplete, unreliable and lose value as a result. And that fact was eventually recognized and so the requirement to wait for the IETF to decide upon a process for SRV prefix registration and the three plus year wait that would have involved was dropped and it is specification required. Did anyone think one standards body is going to wait for another for that long? As a practical matter, I want the code point reserved when I begin to deploy which is (almost) never going to be a point at which I have a final specification. And when people come along looking to implement, they are going to be looking to interop with the end-point. I am currently deploying a system that is based on OAUTH2 with three extensions described in Internet drafts, plus another described on a corporate Web site and another chunk on a GitHub. I certainly want the code points to be registered right now but the protocol itself certainly needs work before it becomes any sort of RFC.
_______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
