On 7/7/2015 1:37 AM, Eliot Lear wrote:
On 7/7/15 10:27 AM, Melinda Shore wrote:
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.
That seems like a fair criticism, and at the very least calls for some
justification for that particular sentence. Thank you for being specific.
Actually, her comment points to a need to review the approach and
language of the entire Introduction, not just that sentence.
To whit:
Introduction
...
Each DOI is associated with bibliographic metadata about the object,
including one or more URIs where the object can be found. The DOI
system also provides many features not relevant to RFCs, such as the
ability to update the metadata after the DOI is assigned, and for
We change post-publication RFC meta-data all the time. Using my obvious
example:
RFC 822 --
Obsoleted by RFC2822
Updated by RFC1123, RFC1138, RFC1148, RFC1327, RFC2156
Errata
That's three kinds of post-publication meta-data changed and the details
are common to many RFCs.
And this error in the Introduction suggests that the use of DOI's has
not been considered all that thoughtfully -- which would be ok if the
document took a more modest approach to its justification and expected use.
The wide use of DOIs suggests that even though RFCs can be downloaded
directly from the IETF for free, organizations that use DOIs can have
trouble locating documents that don't have DOIs. DOIs with metadata
that points to the existing free online RFCs would make RFCs easier
to find and use. Some scholarly publishers accept DOIs as references
in published documents, and some versions of bibtex can automatically
retrieve the bibliographic data for a DOI and format it. Hence DOIs
would make RFCs easier to cite.
The 'can have trouble' suggests an approach here that is trying to
over-sell the need.
The benefits of DOIs apply equally to documents from all of the RFC
submission streams, so all RFCs are assigned DOIs.
DOIs are popular. DOIs are flexible. DOIs are inexpensive to obtain
and use. They are helpful to many potential consumers of IETF documents
to bring its publications under the DOI scheme for the convenience of
those consumers.
Really, that's all the Introduction needs to say.
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.
Do we have any reason to believe that we will be scaling a DOI to beyond
the use of RFC such that a flat name won't suffice? Additional
hierarchy comes with its own complexities.
We all tend to underestimate scaling effects. As an example, we used to
maintain the myth that internet-drafts had short-lived utility. I
submit the question asked here suffers the same problem: The IETF has
quite a few different document series. While the RFCs are the
pre-eminent example, the entire body of explicit publications (RFCs,
internet-drafts, "Statements", ...) are worthy candidates for citation
and therefore for inclusion under DOIs. (BTW, this list of additional
document series the IETF issues is why I suggest saying "IETF documents"
rather than just "RFCs".)
Global opacity of the left-hand side of email addresses proved to be a
strategic benefit in the Internet's extensibility, and in ways that I
believe were entirely unanticipated. Melinda's point represents, in my
view, a foundational issue in the development of any naming scheme.
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.
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net