RFC 2220 (rfc2220) - Page 2 of 4
The Application/MARC Content-type
Alternative Format: Original Text Document
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