John,
In general, I agree with you.
In particular, we COULD choose to openly publish the algorithm used to
generate DOIs for RFCs, and to not change it in the future. In which case,
while the DOI is opaque to anyone who hadn't seen that algorithm, it isn't
quite so opaque to anyone that has seen it.
That still doesn't preclude future documents under 10.17487/ that aren't
RFCs from using a different identification scheme, as long as it doesn't
start with the string "rfc" or "RFC".
In the current revision of the draft, the choice was made to not publish
the DOI generation algorithm. I'm not sure that I agree with that choice,
but I can live with it if that's the consensus.
Cheers,
Andy
On Sat, Jul 4, 2015 at 4:00 PM, John R Levine <johnl(_at_)taugh(_dot_)com>
wrote:
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