idnits 2.17.1 draft-levine-doi-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 10, 2014) is 3752 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3044' is defined on line 185, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3044 (Obsoleted by RFC 8254) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Levine 3 Internet-Draft Taughannock Networks 4 Intended status: Informational January 10, 2014 5 Expires: July 14, 2014 7 Assigning Digital Object Identifiers to RFCs 8 draft-levine-doi-00 10 Abstract 12 The Digital Object Identifier (DOI) is a widely used system that 13 assigns unique identifiers to digital documents that can be queried 14 and managed in a consistent fashion. We propose a method to assign 15 DOIs to past and future RFCs. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 14, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Structure and resolution of DOIs . . . . . . . . . . . . . . 2 53 3. DOIs for RFCs . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. The process of assigning DOIs . . . . . . . . . . . . . . . . 3 55 4.1. Getting a DOI prefix . . . . . . . . . . . . . . . . . . 4 56 4.2. Retroactively assigning DOIs . . . . . . . . . . . . . . 4 57 4.3. Assigning DOIs to new RFCs . . . . . . . . . . . . . . . 4 58 5. Informative References . . . . . . . . . . . . . . . . . . . 4 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 61 1. Introduction 63 The Digital Object Identifier (DOI) is a widely used system that 64 assigns unique identifiers to digital documents that can be queried 65 and managed in a consistent fashion. The structure of DOIs is 66 defined by ISO 26324:2012 [ISO-DOI] and is implemented by a group of 67 registration agencies coordinated by the International DOI 68 Foundation. 70 Each DOI is accompanied by metadata about the object, such as one or 71 more URIs where the object can be found. The DOI system also 72 provides many features not relevant to RFCs, such as the ability to 73 update the metadata after the DOI is assigned, and for organizations 74 to maintain local caches of metadata, e.g., a university or corporate 75 library that tracks its copies of purchased documents so subsequent 76 users don't buy them again. 78 Nonetheless, the wide use of DOIs suggests that even though RFCs can 79 be downloaded directly from the IETF for free, organizations that use 80 DOIs can have trouble locating non-DOI documents. DOIs with metadata 81 that points to the existing free online RFCs would make RFCs easier 82 to find. Some scholarly publishers accept DOIs as references in 83 published documents, so DOIs would make RFCs easier to cite. 85 2. Structure and resolution of DOIs 87 DOIs are an application of the handle system defined by RFCs 88 [RFC3650], [RFC3651], and [RFC3652]. A DOI for an RFC might be 90 10.123456/rfc1234 92 The first part of a DOI is the number 10, which means a DOI within 93 the handle system, a dot, and a unique number assigned to a 94 publisher, in this example 123456. This part is the DOI prefix. 95 Following that is a slash and a text string assigned by the 96 publisher, called the DOI suffix. A reasonable way to assign DOIs 97 would be to use the familiar series names and numbers, e.g., rfc1234, 98 bcp100, or std11. (DOIs are case-insensitive.) 100 Although the handle system has its own protocol described in 101 [RFC3652], the usual way to look up a DOI is to use web lookup. CNRI 102 provides a Firefox plugin that adds a "doi:" URI scheme. Lacking 103 that, one can use a public http proxy, usually http://dx.doi.org, so 104 the sample DOI above could be looked up at: 106 http://dx.doi.org/10.123456/rfc1234 108 Whenever a publisher assigns a DOI, it provides the metadata for the 109 object (henceforth called a document, since that what they are in 110 this context) to its registration agency which then makes it 111 available to clients that look up DOIs. Publishers have considerable 112 flexibility as to what actually resides at the URI(s) that a DOI 113 refers to. Sometimes it's the document itself, while for commercial 114 publishers it's typically a page with the abstract and bibliographic 115 information, and some way to buy the actual document. Since some 116 RFCs are in multiple formats (e.g., Postscript and text) an 117 appropriate URI would be that of the RFC Editor's info page that has 118 the RFC's abstract and links to the document in various formats. 119 Hence the URI above would be set to redirect to 121 http://www.rfc-editor.org/info/rfc1234 123 More information on the structure and use of DOIs is in the DOI 124 Handbook [DOI-HB]. 126 3. DOIs for RFCs 128 Once the RFC series has DOIs assigned, it would be a good idea to 129 include the DOI in the boilerplate for each RFC, perhaps next to the 130 ISSN. Online databases and indexes that include RFCs would be 131 updated to include the DOI, e.g. the ACM Digital Library. (A 132 practical advantage of this is that the DOI would link directly to 133 the IETF, rather than perhaps to a copy of an RFC behind a paywall.) 135 Since RFCs are immutable, existing RFCs still wouldn't mention their 136 own DOIs within the RFC itself, but putting the DOIs into indexes 137 would still provide value. 139 4. The process of assigning DOIs 141 There are three phases to assigning DOIs to RFCs, getting a DOI 142 prefix, retroactively assigning DOIs to existing documents, and 143 updating the publication process to assign DOIs as new RFCs are 144 published, 146 4.1. Getting a DOI prefix 148 There are ten registration agencies [DOI-RA] that assign DOI 149 prefixes. Most of them serve specialized audiences or limited 150 geographic areas, but there are a few that handle scholarly and 151 technical materials. All registration agencies charge for DOIs to 152 defray the cost of maintaining the metadata databases. The prices 153 are fairly low, on the order of $660/year for membership, and deposit 154 fees of 15 cents per document for a bulk upload of the backfile, and 155 $1/per document as they are published. 157 4.2. Retroactively assigning DOIs 159 Other than of paying the submission fees, assigning DOIs to all of 160 the existing RFCs is primarily a software problem. We'd need tools 161 to extract or create the metadata for all of the RFCs and submit it 162 to the registration agency an online API. Where we are aware of 163 indexes and databases that include RFCs, we would try to get them to 164 include the DOI. 166 4.3. Assigning DOIs to new RFCs 168 As new RFCs are published, the publication process will add steps to 169 collect and submit the metadata to the registration agency. 171 5. Informative References 173 [DOI-HB] International DOI Foundation, "DOI Handbook", April 2012, 174 . 176 [DOI-RA] International DOI Foundation, "DOI Registration Agencies", 177 July 2013, 178 . 180 [ISO-DOI] International Organization for Standardization (ISO), "ISO 181 26324:2012 Information and documentation -- Digital object 182 identifier system", 2012, 183 . 185 [RFC3044] Rozenfeld, S., "Using The ISSN (International Serial 186 Standard Number) as URN (Uniform Resource Names) within an 187 ISSN-URN Namespace", RFC 3044, January 2001. 189 [RFC3650] Sun, S., Lannom, L., and B. Boesch, "Handle System 190 Overview", RFC 3650, November 2003. 192 [RFC3651] Sun, S., Reilly, S., and L. Lannom, "Handle System 193 Namespace and Service Definition", RFC 3651, November 194 2003. 196 [RFC3652] Sun, S., Reilly, S., Lannom, L., and J. Petrone, "Handle 197 System Protocol (ver 2.1) Specification", RFC 3652, 198 November 2003. 200 Author's Address 202 John Levine 203 Taughannock Networks 204 PO Box 727 205 Trumansburg, NY 14886 207 Phone: +1 831 480 2300 208 Email: standards@taugh.com 209 URI: http://jl.ly