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: ietf-types@iana.org 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
