The Library of Congress >> Especially for Librarians and Archivists >> Standards

MARC Standards

HOME >> MARC Development >> Discussion Paper List


DATE: December 20, 2019

NAME: Modernization or Replacement of Field 856 in the MARC 21 Formats

SOURCE: OCLC and the German National Library, for the Committee on Data Formats

SUMMARY: This paper considers options for the modernization of the existing field 856 (Electronic Location and Access) and/or the definition of a new field 857; a new subfield $e to account for access, use, and reproduction information; and the possibility of reassigning the existing subfield $7 for access status.

KEYWORDS: Field 856 (All formats); Electronic location and access (All formats); Access to online information resources (All formats); Open access information (BD, HD); Subfield $7, in field 856 (All formats); Subfield $e, in field 856 (All formats); Access status (All formats); Uniform Resource Identifier (All formats); URIs

RELATED: Proposal 93-4; 97-1; 99-06; 2019-01; DP 49; DP 54; DP 69; 2018-DP11; Guidelines for the Use of Field 856, Revised August 1999; Guidelines for the Use of Field 856, Revised March 2002

12/20/19 – Made available to the MARC community for discussion.

01/25/20 – Results of MARC Advisory Committee discussion: Though MAC members agreed that several 856 subfields were outdated and no longer useful, there was divergence of opinion on which subfields should be retained and which should be made obsolete, depending on which field option was chosen. MAC members expressed divergent opinions on which field solution to pursue (field 856 and/or field 857), and whether to carry over access restrictions subfields from fields 506 and 540. There was general agreement that subfield $7 for access status can be retained. It was noted that, moving forward with the 856 initiative, careful consideration should be given to the use case of single-record bibliographic descriptions of multiple formats (often found in legacy data) vs. manifestation-specific bibliographic descriptions used in numerous library catalogs. There was discussion that there may be a need for at least two separate papers in the future: one intended to clear out irrelevant or no-longer-needed 856 subfields, and another intended to make a better job of defining the field to reflect current needs and usage. OCLC and the German National Library will work further on this topic based on the MAC discussion and responses; it is possible it will return as two (or more) separate papers.

Discussion Paper No. 2019-DP01: Modernization or Replacement of Field 856


1.1. Historical Background

Field 856 was originally proposed in 1993 in Assessing Information on the Internet: Toward Providing Library Services for Computer-Mediated Communication, published as OCLC Research Report OCLC/OR/RR-93/1 (  It is also available in a slightly different version as the final report of the OCLC Internet Resources Project to the U.S. Department of Education, Office of Educational Research and Improvement, Library Programs (  Appendix A of either version reproduces MARC Proposal 93-4, "Changes to the USMARC Bibliographic Format for Computer Files to Accommodate Online Information Resources," intended for discussion at ALA Midwinter on January 23, 1993.  (The MARC Advisory Committee website itself does not provide links to discussion papers and proposals older than 1995.)

According to the World Wide Web Consortium (W3C) (, the Internet Engineering Task Force (IETF) formed the Uniform Resource Identifiers Working Group "to define a set of standards for the encoding of system-independent resource location and identification information for the use of Internet information services" ( in March 1994.  At the time that MARC field 856 was initially proposed, URIs as we know them today did not even have a defined standard.  MARC Proposal 93-4 acknowledged this fact:

Working groups of the Internet Engineering Task Force have been actively pursuing the establishment of a standardized way of encoding a pointer to a resource for any system (the Universal Resource Locator, or URL) and standardized ways of identifying resources (the Uniform Resource Identifier and Uniform Resource Number--names of these have changed and are current as of November 1992).  The Uniform Resource Number is roughly equivalent to an ISBN for a networked resource. The definition of a Uniform Resource Identifier is still under discussion.  Once the IETP standards are developed and implemented, it will be necessary to include fields in the USMARC format for some or all of these data elements.

The volatility of the electronic location may be a problem if this data is included in a USMARC record.  The content designators that follow are being proposed to allow for electronic location and access information to be carried in a USMARC record. At the point when the IETF completes its work in developing a Universal Resource Locator and its implementation is possible, including approporiate [sic] links to USMARC systems, this field may no longer be needed.  The work of the IETF promises a solution more useful than that being proposed in this paper.  However, in the meantime, the data is needed in the USMARC record for electronic resources, even if it is less than a perfect solution.  It is expected that the kinds of resources for which USMARC cataloging will be done will likely be less volatile than much of what exists on the Internet as a whole.

Proposal 93-4 as it originally stood included twenty subfields for field 856, but none of them resembled what we now know as subfield $u, Uniform Resource Identifier, for the logical reason that URIs did not yet exist.  By the time of the publication of the "format integrated" 1994 Edition of the USMARC Format for Bibliographic Data in March of that year, subfield $u, defined as Uniform Resource Locator, had been added to field 856.

LC’s superseded document Guidelines for the Use of Field 856, Revised August 1999 ( included an “Attachment B:  Subfield Use When Not Using $u (URL),” which outlined which subfields were likely and unlikely to be used in certain circumstances, even in 1999.  Earlier iterations of the document do not seem to be available.

ATTACHMENT B: Subfield Use When Not Using $u (URL)

If 1st indicator = 0 (email) and a URL is not recorded in $u, the following subfields are used:

$a Host name
$f Electronic name

May also use: $b, $h, $i, $m, $n, $s, $x, $z
Unlikely to use: $c, $d, $k, $l, $o, $p, $t, $2

Those not listed can theoretically be used but no examples have been identified. This is equivalent to URL mailto: scheme.

If 1st indicator = 1 (ftp) and a URL is not recorded in $u, the following subfields are used:

$a Host name (or can use unique elements in $d and/or $f below and omit $a)
$d Path
$f Electronic name

May also use: $b, $c, $g, $i, $k, $l, $m, $n, $o, $p, $q, $s, $x, $3
Unlikely to use: $h, $t, $2

Those not listed can theoretically be used but no examples have been identified. This is equivalent to URL ftp: scheme.

If 1st indicator = 2 (Remote login) and a URL is not recorded in $u, the following subfield is used:

$a Host name

May also use: $b, $k, $l, $m, $n, $o, $p, $t, $x, $z, $3
Unlikely to use: $c, $d, $f, $g, $q, $s, $2

Those not listed can theoretically be used but no examples have been identified. This is equivalent to URL telnet: scheme.

The document’s current version, Guidelines for the Use of Field 856, Revised March 2003 ( omits the attachment but states, "The data in field 856 may be a Uniform Resource Identifier (URI), which is recorded in subfield $u. The necessary locator information may also be parsed into separate defined subfields. Note that separate subfields for locator data was provided when this field was first established in 1993, but generally, these are seldom used."  It further noted that the most commonly used elements are First Indicator value 4 and subfields $u, $z, and $3.

As what is now called MARC 21 continued to evolve within the ever-changing digital environment, field 856 remained saddled with alphabetic subfields of limited, if not downright obsolete, utility.  There being a mere 26 letters in the English alphabet, those many now-useless subfields occupy valuable real estate that, after some careful examination, could be freed up for uses more beneficial to catalogers for describing, and to library users for accessing, what have become ubiquitous online resources.

1.2. Current Definition of Field 856

Field 856 is structured identically in the MARC Bibliographic, Authority, Holdings, Classification, and Community Information formats, although the definition and scope differ slightly from format to format. The Bibliographic field 856 is currently defined as follows:


Information needed to locate and access an electronic resource. The field may be used in a bibliographic record for a resource when that resource or a subset of it is available electronically. In addition, it may be used to locate and access an electronic version of a non-electronic resource described in the bibliographic record or a related electronic resource.

See the Guidelines for the Use of Field 856 for a more thorough discussion on the use of field 856.

Field 856 is repeated when the location data elements vary (the URL in subfield $u or subfields $a, $b, $d, when used). It is also repeated when more than one access method is used, different portions of the item are available electronically, mirror sites are recorded, different formats/resolutions with different URLs are indicated, and related items are recorded.



$g - Electronic name - End of range [REDEFINED, 1997]

$g - Uniform Resource Name [OBSOLETE, 2000]
Because subfield $g (Electronic name - End of range) was rarely if ever used, it was redefined as Uniform Resource Name in 1997. It was subsequently made obsolete in favor of recording the URN in subfield $u.

$q - File transfer mode [REDEFINED, 1997]
Subfield $q was defined to contain an indication of whether the file was transferred as binary or ASCII. It was redefined to contain type of electronic format.

$u - Uniform Resource Identifier [RENAMED, 2000]
Prior to 1999, subfield $u was defined as repeatable. It was changed to not repeatable in favor of repeating the field due to ambiguity in determining when the subfield could be repeatable. Subfield $u was changed back to repeatable and renamed in 2000 to record URNs after subfield $g was made obsolete.

$y - Link text [NEW, 2000]

$7 - Access status [NEW, 2019]

In the particular case of field 856, it seemed instructive to include the “Content Designator History,” which documents two subfield redefinitions and other changes of interest.  It also seemed relevant to note the slight variations in field 856 usage in each of the five MARC 21 formats.

In a bibliographic record, field 856 may be used for a resource when that resource or a subset of it is available electronically. In addition, it may be used to locate and access an electronic version of a non-electronic resource described in the bibliographic record or a related electronic resource.

In an authority record, field 856 may be used to provide supplementary information available electronically about the entity for which the record was created.

In a holdings record, field 856 identifies the electronic location containing the resource or from which it is available. It also contains information needed to retrieve the resource by the access method identified in the first indicator position. The information contained in this field is sufficient to allow for the electronic transfer of a file, subscription to an electronic journal, or logon to an electronic resource. In some cases, only unique data elements are recorded which allow the user to access a locator table on a remote host containing the remaining information needed to access the resource.

In a classification record, field 856 may be used for a resource when that resource or a subset of it is available electronically. In addition, it may be used to locate and access an electronic version of a non-electronic resource described in the classification record or a related electronic resource. This field may also be used to link to an electronic resource intended to supplement the classification scheme, e.g. an image of a map.

In a community information record, field 856 contains the information needed to locate and access electronic information pertaining to a community service such as the service or event website or related resources.

1.3. Meeting at LC, 2019 June 20

On 2019 June 20, representatives of the Library of Congress Network Development and MARC Standards Office (NDMSO) (Sally McCallum, Jodi Williamschen, and John Zagas), the Deutsche Nationalbibliothek (DNB) (Reinhold Heuvelmann), and OCLC (Robert Bremer, Nathan Putnam, and Jay Weitz) met at LC to discuss what would become MARC 21 Update No. 28:  Addendum (//  Additional outcomes of that meeting are documented in the Status/Comments section of MARC Proposal No. 2019-01 (//

In the past, the MARC Advisory Committee and its predecessor, MARBI, have generally been reluctant to redefine an existing MARC element for some different use, although that has occasionally been done.  With that in mind, this discussion paper offers the three options from the June 2019 meeting:

  1. Making currently "unused" subfields in field 856 obsolete to make room for full access and use information.
  2. Defining a new field 857(?) that parallels field 856 but is to be used only for Open Access URIs.  The new field would carry over only the subfields from field 856 that are needed while adding the access and use subfields.
  3. Defining a new field 857(?) and making field 856 obsolete, keeping only the subfields needed today and adding the new ones needed for access and use.

In each option, the full access and use information being added would closely parallel that in fields 506 (Restrictions on Access Note) and 540 (Terms Governing Use and Reproduction Note).

As part of the preparation for the June 2019 meeting, the three institutions compiled statistics on the respective uses of the elements of field 856 in bibliographic records, as of mid-2019.

Note that the “D-A-CH Statistics” column sums up statistics gathered from several institutions (including the regional library networks) in Germany, Austria, and Switzerland, kindly combined and provided by the German National Library.  The acronym “D-A-CH” represents those three major German-speaking nations based on their international vehicle registration codes:  Germany (D for Deutschland), Austria (A for Austria), and Switzerland (CH for Confoederatio Helvetica).



OCLC Statistics

D-A-CH Statistics

LC Statistics

Candidate for Deprecation?

First Indicator

Access method





 I1 #

 No information  provided





 I1 0






 I1 1






 I1 2

 Remote login  (Telnet)





 I1 3






 I1 4






 I1 7

 Method specified in  subfield $2





Second Indicator


 I2 #

 No information  provided





 I2 0






 I2 1

 Version of resource





 I2 2

 Related resource





 I2 8

 No display constant  generated





Numeric Subfields






 [Not defined]






 [Not defined]






 Access method






 Materials specified






 [Not defined]






 [Not defined]












 Access status [New  2019]






 Field link and  sequence number






 [Not defined]





Alphabetic Subfields






 Host name






 Access number






 Compression  information












 Electronic name






 Uniform Resource  Name (URN)  [Obsolete 2000]






 Processor of request












 Bits per second


















 Contact for access  assistance






 Name of location of  host






 Operating system












 Electronic format  type [Redefined  1997]












 File size






 Terminal emulation






 Uniform Resource  Identifier (URI)






 Hours access  method available






 Record control  number






 Nonpublic note






 Link text [New  2000]






 Public note





The aforementioned “Attachment B:  Subfield Use When Not Using $u (URL),” reproduced in Section 1.1, may offer some insight into why certain defined subfields were rarely used.


As stated concisely in the minutes of the MARC Advisory Committee meetings of June 2019 (//, "[T]he current MARC 856 structure was largely devised during an early period of online resource description and connectivity; many of the 856 structures and values defined are no longer applicable within today’s environment."

One major outcome of the June 20, 2019, meeting at LC was the charge to begin a process of thoroughly reexamining field 856 with an eye towards incorporating access and use conditions, cleaning out and deprecating subfields that are now of little use, and deciding which of the three options outlined in Section 1.3 would offer the most advantageous and forward-looking results.


3.1. Subfields to be Deprecated

Regardless of the option chosen, some of the existing subfields that are no longer useful are candidates for deprecation.  Based on such criteria as the usage statistics spelled out in Section 1.3, the ways in which online access policies and practices have evolved, and the recommendations from the June 20, 2019, meeting, two tiers of deprecations are suggested.

The first tier includes subfields that might be regarded as of little continuing value or that are already obsolete:

$b - Access number (R)
Access number associated with a host. It can contain the Internet Protocol (IP) numeric address if the item is an Internet resource, or a telephone number if dial-up access is provided through a telephone line. This data may change frequently and may be generated by the system, rather than statically stored.
May be repeated if all the other information in the field applies.

$c - Compression information (R)
Information about the compression of a file, in particular, whether a specific program is required to decompress the file.
May be repeated if two compression programs are used, noting the latest compression first.

$g - Uniform Resource Name [OBSOLETE, 2000]

$h - Processor of request (NR)
Username, or processor of the request; generally the data which precedes the at sign (@) in the host address.

$j - Bits per second (NR)
Lowest and highest number of bits (binary units) of data that can be transmitted per second when connected to a host. The syntax for recording the number of bits per second (BPS) should be: <Lowest BPS>-<Highest BPS>. If only lowest given: <Lowest BPS>- ; If only highest given: -<Highest BPS>.

$k - Password (NR)
Password required to access the electronic resource. An FTP site may require the user to enter an Internet Protocol address or may require a specific password. Electronically accessed catalogs may also require a password. If a system that requires a password will accept anything entered as valid, this subfield can be omitted from field 856. This subfield is used to record general-use passwords, and should not contain passwords requiring security. Textual instructions about passwords are contained in subfield $z (Public note).

$l - Logon (NR)
Characters needed to connect (i.e., logon, login, etc.) to an electronic resource or FTP site. Used to record general-use logon strings which do not require special security.
An account number required for login may also be indicated. For many general-use File Transfer Protocol servers, access is gained by entering the string anonymous.

$r - Settings (NR)
Settings used for transferring data. Included in settings are: 1) Number Data Bits (the number of bits per character); 2) Number Stop Bits (the number of bits to signal the end of a byte); and 3) Parity (the parity checking technique used). The syntax of these elements is:
<Parity>-<Number Data Bits>-<Number Stop Bits>
If only the parity is given, the other elements of settings and their related hyphens are omitted (i.e., <Parity>). If one of the other two elements is given, the hyphen for the missing element is recorded in its proper position (i.e., <Parity>--<Number Stop Bits> or <Parity>-<Number Data Bits>- ). The values for parity are: O (Odd), E (Even), N (None), S (Space), and M (Mark).

$t - Terminal emulation (R)
Terminal emulation is usually specified for remote login (first indicator contains value 2 (Remote login (Telnet))).

The second tier includes subfields that might be regarded as of questionable value but that may be worthy of retention or at least of discussion:

$i - Instruction (R)
Instruction or command needed for the remote host to process a request.

$n - Name of location of host (NR)
Conventional name of the location of the host in subfield $a, including its physical (geographic) location.

$p - Port (NR)
Portion of the address that identifies a process or service in the host.

$s - File size (R)
Size of the file as stored under the filename indicated in subfield $f. It is generally expressed in terms of 8-bit bytes (octets). It may be repeated in cases where the filename is repeated and directly follows the subfield $f to which it applies. This information is not given for journals, since field 856 relates to the entire title, not to particular issues.

3.2. New Subfields to be Defined

MARC Proposal No. 2019-01 originally suggested the addition of a new subfield $e to field 856, which was temporarily set aside for consideration as part of this field 856 revamping. Subfield $e in field 856 was envisioned as an equivalent to the subfields $a, $f, and $u, in fields 506 and 540. With the potential freeing-up of subfields in fields 856 and/or 857, another possibly more useful option would be to parse out the several points of data that had been combined into the proposed subfield $e into separate subfields.

Option 1:  Depending upon which field option is chosen, a new subfield $e could be defined for field 856 and/or 857:

$e - Information governing access, use, and reproduction (R)
The subfield provides information about access rights, use rights, and reproduction rights. It may contain a free-text term, a standardized term, or a URI.

856 4#  $e Closed access, Embargo: 2019-02-07 $e CC BY-NC-ND 4.0 $q application/pdf $u $7 1

856 4#  $e $u $x Resolving-System $z kostenfrei $3 Volltext // Exemplar mit der Signatur: München, Bayerische Staatsbibliothek -- 4 Ital. 376 $7 0

Option 2: Single specific subfields for each piece, or for selected pieces, of information could be defined. Equivalents to some of the subfields defined in field 506 (Restrictions on Access Note), containing "information about restrictions imposed on access to the described materials" and field 540 (Terms Governing Use and Reproduction Note), containing "terms governing the use of the materials after access has been provided," could be parsed out when similar information is needed in the context of a URI. The relevant subfields in question are presented here for purposes of discussion regarding which might be useful to define separately or in combination in field 856 and/or 857.

506 $a Terms governing access
506 $f Standardized terminology for access restriction
506 $g Availability date
506 $q Supplying agency
506 $u Uniform Resource Identifier for access restriction
506 $2 Source of controlled vocabulary for access

540 $a Terms governing use and reproduction
540 $f Use and reproduction rights
540 $g Availability date
540 $q Supplying agency
540 $u Uniform Resource Identifier for use and reproduction
540 $2 Source of controlled vocabulary for use and reproduction

For example, the equivalents of subfields $q may be unified to become a single subfield.

3.3. Field 856 Subfield $7

Field 856 subfield $7 was part of Proposal No. 2019-01 as a two-position Control Subfield.  It was implemented as the single-position Access Status subfield, part of the Update 28 Addendum of July 2019, currently defined in MARC 21:

$7 - Access status (NR)
Code indicating the availability of access to the remote electronic resource the address of which appears in subfield $u. Subfield $7 applies to all subfields $u present in the field.

0 - Open access
The remote electronic resource is freely and openly accessible online to everyone, without restriction, login, or payment.

1 - Restricted access
The remote electronic resource is not freely and openly accessible online.

u - Unspecified

z - Other

856 40  $3 HathiTrust Digital Library, Full view $u $7 0

The choice of numerical subfield $7 for this function may not have been ideal but was thought to be necessitated by the lack of other subfield options at that time. In the proposal, it was justified as follows:

Subfield $7 has been defined and used in bibliographic records to indicate special MARC characteristics of the linked entry in fields 76X-78X (Type of Main Entry Heading, Form of Name, Type of Record, and Bibliographic Level) and in fields 800, 810, 811, and 830 (Type of Record and Bibliographic Level). In the Bibliographic field 533 (Reproduction Note), subfield $7 contains coded information pertaining to the reproduction (Type of date/Publication status; Date 1; Date 2; Place of Publication, Production, or Execution; Frequency; Regularity; and Form of Item). In all instances, the definition of each code is position-dependent.

In the 7XX and 8XX cases, the use of subfield $7 was limited to MARC structural characteristics corresponding to an existing field indicator or MARC Leader value. In the case of field 533, the coded data elements correspond to various existing 008 character positions, which are both MARC structural characteristics and substantively reflective of the resource itself. The use of subfield $7 within the context of this proposal may be seen as an extension of the way it has been used in field 533, in the sense of containing coded data substantively reflective of the resource itself.

With the clearing away of numerous superfluous alphabetic subfields in field 856, the choice of subfield $7 for this purpose may now be reevaluated, if so desired.


Because the choices of which existing subfields to deprecate and which to retain is an open question deserving careful consideration and discussion, the three field options will be considered only briefly and in the most general terms. More details can be part of a follow-up discussion paper or formal proposal.

4.1. Option 1:  Field 856 Alone

Option 1:  Making currently "unused" subfields in field 856 obsolete to make room for full access and use information.

Option 1 retains a simplified field 856 without deprecated subfields but with a new subfield for access and use information.

4.2. Option 2:  Fields 856 and 857

Option 2:  Defining a new field 857(?) that parallels field 856 but is to be used only for Open Access URIs.  The new field would carry over only the subfields from field 856 that are needed while adding the access and use subfields.

Option 2 retains an intact field 856 and defines a new 857 field that parallels field 856 but minus the deprecated subfields; a new 857 subfield for access and use information would be defined.  The new field 857 would be used only for Open Access URIs.

4.3. Option 3:  Field 857 Alone

Option 3:  Defining a new field 857(?) and making field 856 obsolete, keeping only the subfields needed today and adding the new ones needed for access and use.

Option 3 deprecates field 856 entirely but defines a new field 857 in which only the subfields fit for current use are defined or added, including a new subfield for access and use information.


Cleaning up this field and only defining currently relevant elements in it will improve conversions between MARC and BIBFRAME.  The unnecessary elements would probably not be carried over into the BIBFRAME environment.


6.1. Are any of the proposed first tier subfields, listed in Section 3.1., worthy of retention?

6.2. What are the cases to be made for deprecation or retention of each of the proposed second tier subfields, listed in Section 3.1.?

6.3. Of the two options in Section 3.2. for adding new subfields to account for aspects of restrictions on access and terms governing the use of the resources represented by a URI, which is preferable?

6.4. Of the field 506 and 540 subfield suggestions in Section 3.2 Option 2, which might be most useful to define and in what combinations?

6.5. Are there current and/or anticipated needs for which it would be advisable to define additional new subfields at this time?

6.6. Should the current subfield $7 (Access Status) be retained as is or would it be preferable to reassign it to an alphabetic designation?

6.7. Of the three options in Section 4 for dealing with the existing field 856 and/or defining a new field 857, which is preferable?

6.8. Are there other potential issues that need to be taken into account?

HOME >> MARC Development >> Discussion Paper List

The Library of Congress >> Especially for Librarians and Archivists >> Standards
Legal | External Link Disclaimer Contact Us