Since DOIs are opaque, that doesn't preclude future use of a numeric prefix
as well for something completely different.
Right. Now I see what the problem is -- opaque identifiers are jargon
from databases (I did my PhD research on them) and many IETFers don't
understand what they are.
The point of an opaque identifier is that you can make no assumptions
whatsoever about what its structure or format is. You can just find it
somehow, and you can hand it back to services that use it to look up
what it refers to.
At the moment, the code happens to use the database field published as the
<doc-id> in the XML RFC index to create the DOI. But tomorrow the code
might do something else. This week the DOI it assigned to RFC 7612 was
10.17487/RFC7612 but next week the DOI it assigns to RFC 7613 might be
10.17487/gazornplatz.
This isn't an idle threat. The RFC production software stores the DOI for
each document in a separate field in the database. There is literally one
line of code that creates new DOIs -- change that, and all future DOIs
will have some other form. (Existing DOIs are in the database and won't
change. That's what stable means.)
The only, and I mean *ONLY* way to find the DOI for an RFC is to look it
up. That's not a big deal, because the the DOIs are now included in the
mechanically created RFC index and bibxml files, so anyone using the usual
xml2rfc tools will get the correct DOIs automatically.
The draft should be clear about whether or not leading zeros are used for
low-numbered documents.
I hope it's now clear why that would be a bad idea, and also why you
shouldn't make any assumptions about what the DOIs of RFCs after RFC9999
will be.
R's,
John