ietf
[Top] [All Lists]

Re: Call for comment: <draft-iab-doi-04.txt> (Assigning Digital Object Identifiers to RFCs)

2015-07-07 03:27:52
On 7/6/15 11:36 PM, Eliot Lear wrote:
There goes the whistle.  Unsupported assertion while claiming same,
Offense.  5 yard penalty.  How about instead pointing out the incorrect
statements and test your assertion?

I assume that this is some sort of sports metaphor?

I've pointed this out several times but the justifications
presented in the intro are largely false, and if they're
not false it's because they're hedged.  Statements like
"organizations that use DOIs can have trouble locating
documents that don't have DOIs" are true only because of
the presence of the word "can"; I think you'd be extremely
hard-pressed to find an organization that can't track down
a publicly-available document that doesn't have a DOI
assigned.  DOIs would not make RFCs easier to find and use.
RFCs already have stable, unique identifiers that are
widely known and understood by the community of people who
use RFCs.  In fact, there are effectively two - the RFC
number and the URN.  The relationship between the DOI
and URN is not discussed, which is a bit unfortunate because
while the draft does mention the expectation on the part
of the IDF that we'd start using DOIs in IETF documents,
it doesn't really describe how that would be referenced.
The IDF proxy server processes URNs into DOIs, so that
both https://doi.org/10.17487/RFC5280 and
https://doi.org/10.17487/urn:ietf:rfc:5280 would point to
the same bibliographic record or document.  Generally
there are implications throughout the document that
things we consider to be normal bibliographic processes
(uniquely identifying items, assigning metadata,
providing access mechanisms) are not available without a
DOI.

There have also been suggestions that since the local part
of a DOI is opaque its structure doesn't actually matter.
I would argue that its structure doesn't matter to the
IDF but should matter to us, much in the same way that
a protocol that carries an encrypted blob of something
doesn't care about what's inside that blob but the blob's
sender and recipients care a very great deal.  That's
a feature of plain old layering and encapsulation.  At
this point we have enough experience with naming to be
reluctant to adopt flat namespaces when avoidable, I think.

I'm not opposed to putting DOIs on RFCs despite seeing scant
benefit from doing so.  I am opposed to putting out documents
that provide justifications that are not actually correct.

Melinda

<Prev in Thread] Current Thread [Next in Thread>