RFC 1807

RFC 1807: A Format for Bibliographic Records 📚✨

okay bestie, so this is RFC 1807 🎀 (part 1 of 3), called A Format for Bibliographic Records. It's an Informational doc from June 1995, written by R. Lasher (Stanford) and D. Cohen (Myricom) under the Network Working Group. It obsoletes RFC 1357, so that one is officially replaced now 💅

Status of this Memo ✨

This memo is here to give info to the Internet community 🦋 It does not set any Internet standard, and you're free to pass it around as much as you want 🌸

Abstract 🫶

This RFC defines a format for bibliographic records describing technical reports 📖 The Cornell University Dienst protocol and the Stanford University SIFT system both use this format. The original RFC (RFC 1357) was written by D. Cohen, ISI, July 1992, and this doc is the revision of it. New fields include handle, other_access, keyword, and withdraw ✨

Introduction 🎀

Lowkey, a lot of universities and R&D orgs announce new technical reports by mailing the bibliographic records through the postal service 📬 That's expensive and slow 😭 Plus, the people who get them can't easily file them electronically for later retrieval and searching.

So orgs that want to send these announcements by e-mail or file transfer can use the format in this doc 💖

Organizations can automate as much as they want (or nothing at all) for two things: making records about their own publications, and handling records they get from other orgs 🤖

The format is supposed to be simple for both people and machines. It's easy to read ("human readable") and you can create records without any special programs 🍓

This RFC only defines what the records look like. It doesn't tell you how to process them 🧚

It's a "tagged" format with self-explaining alphabetic tags, so you can write and read records in any text editor 💅

This RFC includes CR-CATEGORY, which is a field that's useful for Computer Science publications. Similar fields are expected to be added for other domains too 🌈

RFC 1357 described this format, and it got put into the Dienst system. Five ARPA-funded computer science institutions (Cornell, SU, UC, MIT, and CMU) have been using it to swap bibliographic records 🎓 People also wrote programs to map between this RFC and structured USMARC cataloging records (USMARC is a format from the Library of Congress), in both directions ✨

The ARPA-funded research looked at lots of digital library stuff, including searching and access techniques that don't rely on bibliographic records at all (like natural language processing, and automatic and full-text indexing) 🔍 Still, bibliographic records are expected to stay a big part of the library system world, and they link the physical world of scientific works to the online world of digital objects. This format is what builds that link 🔗

A bunch of people helped develop this, including folks from Carnegie Mellon University, Corporation for National Research Initiatives (CNRI), Cornell University, University of Southern California/Information Sciences Institute (ISI), Meridian (now called DynCorp), Massachusetts Institute of Technology, Stanford University, and the University of California 🫶 Jerry Saltzer of MIT and Larry Lannom of DynCorp made key contributions. The initial draft was done by Danny Cohen and Larry Miller of ISI, and the revision was done by Rebecca Lasher from Stanford, with help from the CS-TR participants 💜

This RFC doesn't limit how the bibliographic records get spread around 🌸 If a publication itself has restrictions on who can see it, it should be protected some way, like with passwords. This RFC doesn't cover that protection part.

Using this format is encouraged, and there are no limits on using it 🎀

The Information Fields 🧚

These are the fields, and the format rules for them, coming up next 💅 <M> means Mandatory, so a record without it is invalid. <O> means Optional. The tags (aka Field-IDs) are written in upper case.

           <M>  BIB-VERSION of this bibliographic records format
           <M>  ID
           <M>  ENTRY date
           <O>  ORGANIZATION
           <O>  TITLE
           <O>  TYPE
           <O>  REVISION
           <O>  WITHDRAW
           <O>  AUTHOR
           <O>  CORP-AUTHOR
           <O>  CONTACT for the author(s)
           <O>  DATE of publication
           <O>  PAGES count
           <O>  COPYRIGHT, permissions and disclaimers
           <O>  HANDLE
           <O>  OTHER_ACCESS
           <O>  RETRIEVAL
           <O>  KEYWORD
           <O>  CR-CATEGORY
           <O>  PERIOD
           <O>  SERIES
           <O>  MONITORING organization(s)
           <O>  FUNDING organization(s)
           <O>  CONTRACT number(s)
           <O>  GRANT number(s)
           <O>  LANGUAGE name
           <O>  NOTES
           <O>  ABSTRACT
           <M>  END

Meta Format 🍓

• Keep It Simple. Seriously, that's the whole vibe 💅
• Each bibliographic record is for one publication. A "publication" is whatever the publishing institution decides counts as one 📚
• A record has several fields 🎀
• Each field starts with its tag (aka the field-ID). The tag is a reserved identifier with no separators, and it begins a new line (with or without spaces before it). After the tag come two colons (::), and then the field data 💖
• Continuation lines: lines are limited to 79 characters ✂️ If needed, a field can keep going over several lines, with an implied space in between. No special marking is used to show a continuation line, so a field ends at a line that starts (apart from white space) with a word followed by two colons. The one exception is END::, which is terminated by the end of the line. For easier human reading, it's suggested to start continuation lines with some spaces 🫶
• Several fields are mandatory and must appear in the record 🔥 All fields (unless they're specifically not allowed to) can come in any order, and they can be repeated as needed (like the AUTHOR field). The order of repeated fields is always kept 🌈
• Only printable ASCII characters are allowed 💅 The permissible characters are ASCII codes 040 (Space) through 176 (~), plus line breaks, which are \012 (LF) or \012\015 (CRLF). Empty lines mean a paragraph break. \009 (tab) must be replaced by spaces. Tabs, null characters, DEL, backspaces, etc. are specifically banned. If you use them, the record is invalid 🙈
• Full 8-bit ASCII is allowed too 🌸

WARNING: some electronic mailers can't handle 8-bit ASCII, so these records may need to go through other mechanisms instead 😭

Throughout this document, the word "publisher" means the publishing organization of a report (like a university or a department in one) 🎓 It doesn't have to be an organization authorized to issue ISBN numbers.

The Actual Format 💜

Heads up: "Open Ended Format" in the following just means arbitrary text ✨ Double-quotes around things mean complete strings. They're only there for grouping, and they aren't supposed to show up in the actual records 🎀

The BIB-VERSION, ID, ENTRY, and END fields must appear as the first, second, third, and last fields, and they can't be repeated in the record. Every other field can be repeated as needed 🦋

BIB-VERSION (M) 🫧

This is the first field of any record, and it's mandatory. It tells you which version of the format was used to make this bibliographic record. This RFC defines BIB-Version TR-v2.1 💖

BIB-VERSIONs that start with the letter X (case independent) count as experimental. Bib-records sent with such a BIB-VERSION SHOULD NOT be incorporated in the permanent database of the recipient 🙅‍♀️

When you use this version of the format, this field is always:

Format:   BIB-VERSION:: CS-TR-v2.1

ID (M) 🆔

This is the second field of any record, and it's mandatory too 💅 The ID field identifies the bibliographic record, and it's used to manage these records. The format is ID:: XXX//YYY. XXX is the publisher-ID (the controlled symbol of the publisher), and YYY is the ID of the publication as the publisher assigned it (like a report number). The ID is usually printed on the cover, and it can contain slashes ✨

The organization symbols "DUMMY" and "TEST" (case independent) are reserved for test records. Those SHOULD NOT be incorporated in the permanent database of the recipients 🧪

Format:   ID:: <publisher-ID>//<free-text>
Example:  ID:: OUKS//CS-TR-91-123

**** See the note at the end regarding the **** **** controlled symbols of the publishers *****

ENTRY (M) 📅

This is a mandatory field. It's the date the bibliographic record was created 🎀

The ENTRY date format is "Month Day, Year". The month has to be alphabetic (spelled out). "Day" is a 1- or 2-digit number, and "Year" is a 4-digit number 💖

Format:   ENTRY:: <date>
Example:  ENTRY:: January 15, 1992

Here's the full example record, which I'll be honest is giving main character energy 🌟

-------------------------------------------------------------
 BIB-VERSION:: CS-TR-v2.1
          ID:: OUKS//CS-TR-91-123
       ENTRY:: January 15, 1992
ORGANIZATION:: Oceanview University, Kansas, Computer Science
        TYPE:: Technical Report
    REVISION:: January 5, 1995; FTP access information added
       TITLE:: Scientific Communication must be timely
      AUTHOR:: Finnegan, James A.
     CONTACT:: Prof. J. A. Finnegan, CS Dept, Oceanview Univ,
               Oceanview, KS 54321  Tel: 913-456-7890
               <Finnegan@cs.ouks.edu>
      AUTHOR:: Pooh, Winnie The
     CONTACT:: 100 Aker Wood
        DATE:: December 1991
       PAGES:: 48
   COPYRIGHT:: Copyright for the report (c) 1991, by J. A.
               Finnegan.  All rights reserved.  Permission is granted
               for any academic use of the report.
      HANDLE:: hdl:oceanview.electr/CS-TR-91-123
OTHER_ACCESS:: url:http://electr.oceanview.edu/CS-TR-91-123
OTHER_ACCESS:: url:ftp://electr.oceanview.edu/CS-TR-91-123
   RETRIEVAL:: send email to Finnegan@cs.ouks.edu with fax number
     KEYWORD:: Scientific Communication
 CR-CATEGORY:: D.0
 CR-CATEGORY:: C.2.2 Computer Sys Org, Communication nets, Net
               Protocols
      SERIES:: Communication
     FUNDING:: FAS
    CONTRACT:: FAS-91-C-1234
  MONITORING:: FNBO
    LANGUAGE:: English
       NOTES:: This report is the full version of the paper with
               the same title in IEEE Trans ASSP Dec 1976
ABSTRACT::

Many alchemists in the country work on important fusion problems.
All of them cooperate and interact with each other through the
scientific literature.  This scientific communication methodology
has many advantages.  Timeliness is not one of them.

END:: OUKS//CS-TR-91-123
---------------------------- End of Example -------------------

Fyi, the example is about 1,689 characters (184 words), and roughly 249 characters (36 words) of that is the abstract 📊

ORGANIZATION (O) is the publisher's full name, spelled out with no acronyms, bestie 🏛️💅 The name is controlled together with the publisher's controlled symbol (same deal as the ID field, see above). Acronyms are a no because so many are common, like ISI and USC 💀 Put it in ascending order, like "X University, Y Department" and not the other way round 🎀

Format:   ORGANIZATION:: <free-text>
Example:  ORGANIZATION:: Stanford University, Department of
                         Computer Science

TITLE (O) 📖

TITLE (O) is the title exactly as the author gave it, and it should include every subtitle too. The full vibe, no trimming 🌸

Format:   TITLE:: <free-text>

Example:  TITLE:: The Computerization of Oceanview with
                  High Speed Fiber Optics Communication

TYPE (O) 🦋

TYPE (O) says what kind of publication it is (a summary, a final project report, and so on), as the issuing organization assigned it ✨

Format:   TYPE:: <free-text>

Example:  TYPE:: Technical Report

REVISION (O) 🔁

REVISION (O) says this record is a revision of an earlier one and is meant to replace it. The revision info is a date and/or, followed by a semicolon and then open-ended text. A revised record should be the complete record for the publication, not just a list of changes to the old one 🙅‍♀️ If REVISION is left out, the record counts as new and not a revision.

If the revision date is 0, that means January 1, 1900. This is for programs that might process records from RFC1357, which used revision data of 0, 1, 2, 3, and so on 🍓

The text before the semicolon is a date in the form month day, year. A record with a more recent revision date completely replaces any record with an earlier one (whether that date was given explicitly or by default). Use the text after the semicolon to describe the revision. Good reasons to send a revised record include an error in the original, or a change in the access information 💜

Format:  REVISION:: January 1, 1995; <free-text>

Example: REVISION:: January 1, 1995; FTP information
                added

WITHDRAW (O) 🚫

WITHDRAW means the document is no longer available. Some institutions delete the record, and others just remove some fields. Each institution decides how to handle withdrawn records 🤷‍♀️

A withdraw record has all the mandatory fields, plus the WITHDRAW field and a mandatory REVISION field. The WITHDRAW field should give the reason in free text. Here's the example for withdrawing a bibliographic record:

    BIB-VERSION::  CS-TR-v2.1
    ID::           OUKS//CS-TR-91-123
    ENTRY::        January 21, 1995
    ORGANIZATION:: Oceanview University, Kansas, Computer
                   Science
    TITLE::        The Computerization of Oceanview with
                   High Speed Fiber Optics Communication
    REVISION::     January 21, 1995
    WITHDRAW::     Withdrawn, found to be irrelevant
    END::          OUKS//CS-TR-91-123

AUTHOR (O) ✍️

AUTHOR (O) is for personal names only, with the normal last-name-first inversion. Editors go here too, marked with the usual "(ed.)" as in the last example 🎀

If the report wasn't written by a person, like if a committee or panel wrote it, use CORP-AUTHOR (below) instead of AUTHOR.

Each extra author gets their own line, in the form AUTHOR:: <free-text>. The system keeps the order of the authors 📋

Format:   AUTHOR:: <free-text>

Example:  AUTHOR:: Finnegan, James A.
          AUTHOR:: Pooh, Winnie The
          AUTHOR:: Lastname, Firstname (ed.)

CORP-AUTHOR (O) 🏢

CORP-AUTHOR (O) is the corporate author (a committee or a panel, for example) that wrote the report. It can be different from the ORGANIZATION that issued it. When you enter the corporate name, leave off an initial "the" or "a". If it's really part of the name, invert it instead 🙃

Format:   CORP-AUTHOR:: <free-text>

Example:  CORP-AUTHOR:: Committee on long-range computing

CONTACT (O) 📬

CONTACT (O) is the contact for the author(s). It's open-ended, but most likely it's an email and a postal address. Give a CONTACT for each author, separately, or one for all the AUTHOR fields together. Email addresses always go in "pointy brackets", like in the example 💌

Format:   CONTACT:: <free-text>

Example:  CONTACT:: Prof. J. A. Finnegan, CS Dept,
                    Oceanview Univ., Oceanview, Kansas, 54321
                    Tel: 913-456-7890 <Finnegan@cs.ouks.edu>

DATE (O) 📅

DATE (O) is the publication date. The allowed formats are "Month Year" and "Month Day, Year". The month has to be alphabetic and spelled out. The day is a 1- or 2-digit number, and the year is a 4-digit number 🗓️

Format:   DATE:: <date>

Example:  DATE:: January 1992
Example:  DATE:: January 15, 1992

PAGES (O) 📄

PAGES (O) is the total number of pages, and nobody's going to be too picky about it 😌 The final numbered page is actually preferred, as long as it's a reasonable approximation of the total.

Format:   PAGES:: <number>

Example:  PAGES:: 48

COPYRIGHT (O) ©️

COPYRIGHT (O) is the copyright info, in an open-ended format. This field applies to the cited report, not to the bibliographic record itself 🔒

Format:  COPYRIGHT:: <free-text>

Example: COPYRIGHT:: Copyright for the report (c) 1991,
                     by J. A. Finnegan.  All rights
                     reserved.
                     Permission is granted for any academic
                     use of the report.

HANDLE (O) 🪪

Handles are unique, permanent identifiers. The Handle Management System uses them to look up location data. A handle is a printable string that, when given to a handle server, returns the location of the data 🧚

Handles identify digital objects stored in a digital library. If the technical report is available electronically, the Handle MUST be supplied in the bibliographic record. The format is HANDLE:: hdl:<naming authority>/string of characters. The string can be the report number that the publisher assigned to the technical report. For more on handles and handle servers, check the CNRI WEB page at http://www.cnri.reston.va.us.

NOTE: White space in HANDLE caused by a line wrap is ignored.

Format:  HANDLE:: hdl:<naming authority>/string of
                  characters

Example: HANDLE:: hdl:oceanview.electr/CS-TR-91-123

OTHER_ACCESS (O) 🔗

OTHER_ACCESS (O) is for URLs, URNs, and other retrieval systems that haven't been invented yet 🛸 Each occurrence of the field holds only one URL or URN.

URL and URN info is in the IETF (Internet Engineering Task Force) internet drafts. The newest drafts are on the CNRI WEB page at http://www.cnri.reston.va.us.

NOTE: White space in a URL or URN caused by a line wrap is ignored.

Format:  OTHER_ACCESS:: URL:<URL>
         OTHER_ACCESS:: URN:<URN>

Example: OTHER_ACCESS:: URL:http://elib.stanford.edu/Docume
nt/STANFORD.CS:CS-TN-94-1

Example: OTHER_ACCESS:: URL:ftp://JUPITER.CS.OUKS.EDU/PUBS/
computerization.txt.

URNs are placeholders for now. Once the URN standard is finalized, naming authorities will be registered and URNs will become viable unique identifiers. For the latest URN drafts, check the CNRI WEB page at http://www.cnri.reston.va.us.

RETRIEVAL (O) 📦

RETRIEVAL (O) is an open-ended description of how to get a copy of the full text. It's optional, and you can repeat it 💫

Nothing limits how the bibliographic records get spread around. If the publication itself has dissemination limits, protect it some other way, like with passwords. This format doesn't cover that protection 🔐

Format:  RETRIEVAL:: <free-text>

         RETRIEVAL:: for full text with color pictures
                   send a self-addressed stamped envelope to
                   Prof. J.A.  Finnegan, CS Dept,
                   Oceanview University, Oceanview, KS 54321

KEYWORD (O) 🔑

KEYWORD (O) is for any keywords, controlled or uncontrolled. It's optional and repeatable. Multiple keywords go on multiple lines, each in the form KEYWORD:: <free-text>. 🌈

Format:   KEYWORD:: <free-text>

Example:  KEYWORD:: Scientific Communication
          KEYWORD:: Communication Theory

CR-CATEGORY (O) 🧠

CR-CATEGORY (O) gives the CR-category, which is the Computer Reviews Category index (like "B.3"). Always include the index, and you can optionally add the category name after it. If you do add the name, fully specify it with parent levels as needed to make it clear, like in the second example. Use multiple lines for multiple categories 🦋

Every year, the January issue of CR has the full list of these categories, a detailed discussion of the CR Classification System, and a full index. The full index usually shows up in every January issue, and the top two levels show up in every issue 📚

Format:   CR-CATEGORY:: <free-text>

Example:  CR-CATEGORY:: D.1

Example:  CR-CATEGORY:: B.3 Hardware, Memory Structures

PERIOD (O) ⏳

PERIOD (O) is the time period covered, as a date range. It's mostly for progress reports and things like that. Any format works, as long as the two dates are separated by " to " (the word "to" with spaces on both sides) and each date follows the date format described above under DATE 🗓️

Format:   PERIOD:: <date> to <date>

Example:  PERIOD:: January 1990 to March 1990

SERIES (O) 📚

SERIES (O) is the series title, including the volume number within the series. It's open-ended, but the producing institution is strongly encouraged to stay internally consistent 🎀

Format:   SERIES:: <free-text>

Example:  SERIES:: Communication

FUNDING (O) 💰

FUNDING (O) is the name(s) of the funding organization(s) ✨

Format:   FUNDING:: <free-text>

Example:  FUNDING:: ARPA

MONITORING (O) 👀

MONITORING (O) is the name(s) of the monitoring organization(s) 🛰️

Format:   MONITORING:: <free-text>
Example:  MONITORING:: ONR

CONTRACT (O) 📝

CONTRACT (O) is the contract number(s) 🖋️

Format:   CONTRACT:: <free-text>

Example:  CONTRACT:: MMA-90-23-456

GRANT (O) 🌱

GRANT (O) is the grant number(s) 🌻

Format:   GRANT:: <free-text>

Example:  GRANT:: NASA-91-2345

LANGUAGE (O) 🌍

LANGUAGE (O) is the language the report is written in. Use the full English name of that language. Please include the Abstract in English if possible. If LANGUAGE isn't specified, English is assumed 💖

Format:   LANGUAGE:: <free-text>

Example:  LANGUAGE:: English
Example:  LANGUAGE:: French

NOTES (O) 📝 Miscellaneous free text

okay so NOTES is your catch-all bin for any random free text you want to tuck in 🧺 it's totally optional, bestie.

Format:

NOTES:: <free-text>

Example:

NOTES:: This report is the full version of the
                paper with the same title in IEEE Trans ASSP
                Dec 1976

ABSTRACT (O) ✨ Highly recommended, but not mandatory

the ABSTRACT is giving main character energy 💅 it's highly recommended but NOT mandatory, so you're not in trouble if you skip it 🫶 there's no limit defined for its length, but it's suggested not to expect applications to handle more than 10,000 characters 😭 that's a LOT of text, babe.

the ABSTRACT is expected to be used for subject searching, because titles alone just aren't enough 🔍 even if the report isn't in English, an English ABSTRACT is preferable 🌸 and if there's no formal abstract on the document, the people making the bibliographic records are encouraged to borrow pieces of the introduction, the first paragraph, etc. 🧚 resourceful, iconic.

Format:

ABSTRACT:: xxxx .............. xxxxxxxx
                    xxxx .............. xxxxxxxx

                    xxxx .............. xxxxxxxx
                    xxxx .............. xxxxxxxx

END (M) 🏁 This is a mandatory field

END is the one you absolutely cannot skip 🚨 it's mandatory, and it has to be the last entry of a record. It identifies the record it ends by repeating the same ID that was used at the very beginning of the records, in its "ID::" 🎀 think of it as the bookend that matches the opening, so the whole thing is wrapped up neatly 💖

Format:

END:: XXX//YYY

Example:

END:: OUKS//CS-TR-91-123

             >>>>>>>   [END OF FORMAT DEFINITION]   <<<<<<<

A Note Regarding the Controlled Symbols of the Publishers 🏛️

okay this part is lowkey important 🫣 to avoid conflicts among the symbols of the publishing organizations (the XXX part of the "ID:: XXX//YYY"), it's suggested that the various organizations that publish reports (like universities, departments, and laboratories) register their <publisher-ID> symbols and names. It's similar to how other key parameters and names get registered on the Internet 🌈

Rebecca Lasher (RLASHER@Forsythe.stanford.edu), of Stanford working with CNRI, has agreed to coordinate this registration with the IANA for the publishers of Computer Science technical reports 👑 it's suggested that before using this format, the publishing organizations coordinate with her (by e-mail) about their symbols and the names of their organizations 📧

and one more thing 🫶 to help automated handling of the bibliographic records people receive, it's expected that the producers of those records will always use the same name, exactly, in the ORGANIZATION field. no typos, no vibes-based spelling 💀

Security Considerations 😱

okay bestie, brace yourself 🙈 security issues are not discussed in this memo. full stop. nothing on security here, so don't go looking for it in these pages 🫠

Acknowledgements 🙏

this work was supported by the Advanced Research Projects Agency under Grant No. MDA-972-92-J-1029 with the Corporation for National Research Initiatives (CNRI) 🌟 its content does not necessarily reflect the position or the policy of the Government or CNRI, and no official endorsement should be inferred. just so we're clear, it's not an endorsement 💜

Authors' Addresses 💌

meet the authors 🦋

Rebecca Lasher
Mathematical and Computer Sciences Library
M.S. 2125
Stanford University
Stanford, CA, USA 94305

Phone: +1 415 723 0864
EMail: rlasher@forsythe.stanford.edu


Danny Cohen
Myricom
325 N. Santa Anita Ave.
Arcadia, CA 91006
USA

Phone: +1 818 821 5555
EMail: Cohen@myri.com