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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 7/7/15 9:52 AM, John C Klensin wrote:
> 
> 
> --On Tuesday, July 07, 2015 16:18 +0000 "Eggert, Lars" 
> <lars@xxxxxxxxxx> wrote:
> 
>>> Unless the IAOC and RFC Editor negotiated a particularly 
>>> unusual deal with the chosen DOI Registration Agency, probably
>>> not.  In general, signing up to issue DOIs carries with it not
>>> only a set of charges but an obligation to use DOIs in one's
>>> own documents.
>> 
>> As Eliot said, it seems to be a request, not an obligation. The
>> ACM and IEEE - both of which assign DOIs for all their 
>> publications - are not turning down papers because the authors 
>> didn't include DOIs in their bibliographies, and neither would 
>> we.
> 
> We haven't seen the contract and this question is presumably easily
> answered by someone with the information rather than starting a
> long thread of speculation.  In particular, even if it were a firm
> obligation, all the above would prove is that ACM and IEEE are not
> insisting that authors supply DOIs in references that they can
> include in articles, something that would, in turn, require that
> they not publish articles that contain references to document for
> which no DOIs have been assigned.  The latter would be an
> unsustainable requirement and an impossible one for non-digital
> documents and documents whose publishers are no longer around.
> While third-party assignment of bibliographic categories is
> feasible (and common), DOIs have to be assigned by publishers or
> surrogates for them.
> 
> Given Dave Crocker's recent comments about I-Ds, Statements, etc.
> (better examples than mine about possible additional series, btw),
> it would also be good for someone who actually knows to assure us
> that the contract is strictly limited to RFCs or RFC Editor
> projects and cannot be used to expand the obligation (or "request")
> to other IETF publications.

The RFC Editor has been assigned a DOI prefix. It is up to us
regarding how that prefix is used. I do have a request in hand that
someone would like us to assign DOIs to the old IEN documents (see
http://www.rfc-editor.org/RFCoverview.html#history), but I'm holding
off regarding any decisions in that matter pending how the experience
with DOIs for RFCs go.

I strongly advise against DOI assignment for I-Ds, but that's up to
the IESG.

> 
> Let me say again what I think many others have said.  There is 
> really no objection to including DOIs in RFCs on the basis 
> represented by recently-published ones.  There is probably no 
> objection to including the DOI identifier in the header or a new 
> footer of newly-published RFCs at the discretion of the RFC Editor
> (something I believe is covered by the obligation and/or request
> and to make it easy to include them in references to an RFC someone
> has in hand, even if retroactively-assigned ones have to be looked
> up as metadata).
> 
> The objections are to:
> 
> * The review process that got us here, including the apparent 
> request to have the community review and endorse something that has
> already been done and won't be un-done.

This is an interesting problem, as a very similar process is being
done with the format work. We are working on drafts, testing
implementations, and at least at the moment, don't intend to finalize
the drafts until we have some running code to validate what we've
done. There is some discussion as to whether that model should change,
but at least the original plan was "discuss then code/implement then
publish".  I think, all things considered, that keeping the community
informed AND waiting for running code is a reasonable process. If you
have a suggestion on how to reorder this type of egg and chicken that
won't leave projects deadlocked, please let me know.

> 
> * A document that appears to make claims that are hard to justify
> as completely accurate, most of all of which claims could be
> eliminated by simply turning the document into a factual statement
> as to what was (or is being) done whose justification is limited to
> the obvious truth that some groups in the community wanted this and
> no one saw evidence of harm. As Dave says, the document may be
> trying to over-sell the need. I would add that we really don't need
> to "sell" DOIs at all; if more or less lavish claims about either
> utility or demand need to be made, let's leave them to the DOI
> community and promoters.
> 

I think some explanation is necessary for people who have no idea
around the context, but I'll reread with an eye towards determining if
it went overboard on that.

Thank you for the feedback,
Heather


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCAAGBQJVnEHnAAoJEER/xjINbZoGSl4H/05hZbT34Gb1uq6bah3FwkuF
06/lS5MIatEow/Mto/hkUB2CMXuigjJuLq/ssBre0nGkSuqbMonAg4NdA2lUggUQ
3P2vYY2iH7Iew6tySWYzu/jMQGMV67aF1cgKXGPs0E8zWTzHj/b+eewZcbvyDkwv
B3fao65ejQzYDvD/575ybIBPz4t+NVIxpmlkHMw/Ue9jH5POTZmhPTVnesBk18In
AinLBBhz8DNQasZdd+0DYlUU6NgKnr6s8qbyfZEY33QZJL3ahKivMF4O1lJyxan9
xlXR/0vES9n4COF3f4eyLdbBMTzlVjF6HdPR2gdelfZLOIKCkfEGne7sQvl0HW4=
=ibue
-----END PGP SIGNATURE-----




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]