RFC 2220 (rfc2220) - Page 2 of 4

The Application/MARC Content-type

RFC 2220             Application/MARC Content-type          October 1997


2.  Definition

   Since there are different flavors of MARC which would be processed by
   different applications, this content-type/subtype refers to the
   harmonized USMARC/CANMARC specification.  Additional content-
   types/subtypes may be defined in the future (e.g.
   application/unimarc).

   MARC records involve three elements: the record structure, content
   designation, and data content.  Only those records that contain all
   three elements according to the standard would use this content-
   type/subtype, i.e. content extracted from the structure would not.
   Since MARC does not mandate an internal storage format, parameters
   have not been assigned to specific implementations (e.g. OCLC-MARC,
   LC-MARC, etc.).  In addition, parameters have not been defined for
   the specific type of MARC format (e.g. bibliographic, authority,
   holdings), since the information is contained in the Leader portion
   of the record.

3. Registration Information

   To: 

   Media type name: application

   Media subtype name: marc

   Required parameters: None

   Optional parameters: None

   Encoding considerations:  MARC records may contain long lines and/or
   arbitrary octet values.  The base64 content-transfer-encoding is
   recommended for transmission of MARC over electronic mail.

4.  Security Considerations

   There are no known security risks associated with the use or viewing
   of MARC data.  A MARC record may have security classification
   associated with the document it describes or metadata in that record.
   Although this does not present any security risk to the user of MARC
   data, it may provide an opportunity for a security breach for the
   source of classified MARC data.








Guenther                     Informational