RFC 6207

The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, and application/sru+xml

πŸ“… published April 2011, from ietf

RFC 6207 πŸŽ€

The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, and application/sru+xml

Okay bestie, this is RFC 6207 from the IETF (Internet Engineering Task Force) πŸ’…. It's dated April 2011 and has ISSN 2070-1721. Ray Denenberg is the editor (that's the "Ed." after the name) and he's from the Library of Congress πŸ“š. It's in the Informational category, which means it's published for information and is not an Internet Standards Track spec 🌸. The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨.

Abstract πŸŽ€

This doc sets out media types for five formats: MODS (Metadata Object Description Schema), MADS (Metadata Authority Description Schema), METS (Metadata Encoding and Transmission Standard), MARCXML (MARC21 XML Schema), and the response XML schema for the SRU (Search/Retrieve via URL Response Format) protocol. They're all XML schemas, and they represent things like metadata and search results 🧚.

Status of This Memo πŸ“œ

Not an Internet Standards Track specification, just published for info purposes 🫢.

This is an IETF product that reflects the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is eligible for any level of Internet Standard, so see Section 2 of RFC 5741 for that bit πŸ’œ.

For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6207 πŸ”—.

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document πŸ“–. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Simplified BSD License says πŸ’–.

Table of Contents πŸ“‘

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Registration for mods+xml  . . . . . . . . . . . . . . . . . .  4
3.  Registration for mads+xml  . . . . . . . . . . . . . . . . . .  5
4.  Registration for mets+xml  . . . . . . . . . . . . . . . . . .  6
5.  Registration for marcxml+xml . . . . . . . . . . . . . . . . .  7
6.  Registration for sru+xml . . . . . . . . . . . . . . . . . . .  8
7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
  8.1.  Harmful Content  . . . . . . . . . . . . . . . . . . . . .  9
  8.2.  Authenticity and Confidentiality . . . . . . . . . . . . .  9
9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
  9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
  9.2.  Informative References . . . . . . . . . . . . . . . . . . 11

1. Introduction ✨

The Library of Congress, working on behalf of and alongside various parts of the metadata and information retrieval community, has put out specs that define formats for representing things like metadata and search results πŸ’…. This memo covers the media types for several of those formats, and they're all XML schemas πŸ¦‹.

  • MODS: Metadata Object Description Schema. An XML schema for a bibliographic element set. It can be used for all kinds of purposes, especially library applications πŸ“š.
  • MADS: Metadata Authority Description Schema. An XML schema for an authority element set, used to give metadata about agents (people, organizations), events, and terms (topics, geographics, genres, etc.). It's the companion to MODS πŸ‘‘.
  • METS: Metadata Encoding and Transmission Standard. An XML schema for encoding descriptive, administrative, and structural metadata about objects in a digital library 🌸.
  • MARCXML: MARC21 XML Schema. An XML schema for the direct XML representation of the MARC format. MARC already has a media type, application/marc (see [RFC2220]). By "direct XML representation" they mean the actual MARC data gets encoded inside XML. This is different from MODS, because MARC uses codes for its element names, while MODS uses meaningful names and MARCXML keeps the MARC codes 🧠.
  • SRU: Search/Retrieve via URL Response Format. An XML schema for the SRU response. SRU is a protocol, and sru+xml is specifically for the default SRU response. The response can come in several other schemas too, RSS and ATOM for example, and the client picks which one it wants in the request. That's why a media type is needed. This mechanism is coming in SRU 2.0. In earlier versions (every version so far, since 2.0 is still in development), responses all use the one default format, so there was no need for a media type. SRU 2.0 is being developed within the Organization for the Advancement of Structured Information Standards (OASIS) 🫢.

2. Registration for mods+xml πŸ¦‹

This is the registration for application/mods+xml. Here's the whole template, copied exactly:

MIME media type name: application
MIME subtype name: mods+xml
Required parameters: None
Optional parameters: (charset)  This parameter has semantics
   identical to the charset parameter of the "application/xml" media
   type as specified in [RFC3023].
Encoding considerations:  Identical to those of "application/xml" as
   described in [RFC3023].
Security considerations:  See Section 8 of RFC 6207.
Interoperability considerations:  There are no known interoperability
   issues.
Published specification:  [MODS-SCHEMA], [MODS].
Applications which use this media type:  Various MODS-conformant
   toolkits use this media type.
Additional information:
   Magic number(s): None
   File extension(s): .mods
   Macintosh file type code(s): TEXT
   Person and email address to contact for further information:
      Ray Denenberg <rden@loc.gov>
   Intended usage: COMMON
   Restrictions on usage: None
Author/Change controller:  The MODS specification was developed by
   the Library of Congress and is maintained by the Library of
   Congress in conjunction with the MODS Editorial Committee, which
   has change control over the specification.

3. Registration for mads+xml 🌈

Next up is application/mads+xml, with the same structure. Full template:

MIME media type name: application
MIME subtype name: mads+xml
Required parameters: None
Optional parameters: (charset)  This parameter has semantics
   identical to the charset parameter of the "application/xml" media
   type as specified in [RFC3023].
Encoding considerations:  Identical to those of "application/xml" as
   described in [RFC3023].
Security considerations:  See Section 8 of RFC 6207.
Interoperability considerations:  There are no known interoperability
   issues.
Published specification:  [MADS-SCHEMA], [MADS].
Applications which use this media type:  Various MADS conformant
   toolkits use this media type.
Additional information:
   Magic number(s): None
   File extension(s): .mads
   Macintosh file type code(s): TEXT
   Person and email address to contact for further information:
      Ray Denenberg <rden@loc.gov>
   Intended usage: COMMON
   Restrictions on usage: None
Author/Change controller:  The MADS specification was developed by
   the Library of Congress and is maintained by the Library of
   Congress in conjunction with the MODS Editorial Committee, which
   has change control over the specification.

4. Registration for mets+xml 🌸

Now application/mets+xml. Full template:

MIME media type name: application
MIME subtype name: mets+xml
Required parameters: None
Optional parameters: (charset)  This parameter has semantics
   identical to the charset parameter of the "application/xml" media
   type as specified in [RFC3023].
Encoding considerations:  Identical to those of "application/xml" as
   described in [RFC3023].
Security considerations:  See Section 8 of RFC 6207.
Interoperability considerations:  There are no known interoperability
   issues.
Published specification:  [METS-SCHEMA], [METS].
Applications which use this media type:  Various METS conformant
   toolkits use this media type.
Additional information:
   Magic number(s): None
   File extension(s): .mets
   Macintosh file type code(s): TEXT
   Person and email address to contact for further information:
      Ray Denenberg <rden@loc.gov>
   Intended usage: COMMON
   Restrictions on usage: None
Author/Change controller:  The METS specification was developed by
   the Library of Congress and is maintained by the Library of
   Congress in conjunction with the METS Editorial Board as an
   initiative of the Digital Library Federation.

5. Registration for marcxml+xml πŸ”₯

Here's application/marcxml+xml. Full template:

MIME media type name: application
MIME subtype name: marcxml+xml
Required parameters: None
Optional parameters: (charset)  This parameter has semantics
   identical to the charset parameter of the "application/xml" media
   type as specified in [RFC3023].
Encoding considerations:  Identical to those of "application/xml" as
   described in [RFC3023].
Security considerations:  See Section 8 of RFC 6207.
Interoperability considerations:  There are no known interoperability
   issues.
Published specification:  [MARCXML-SCHEMA], [MARCXML].
Applications which use this media type:  Various MARCXML conformant
   toolkits use this media type.
Additional information:
   Magic number(s): None
   File extension(s): .mrcx
   Macintosh file type code(s): TEXT
   Person and email address to contact for further information:
      Ray Denenberg <rden@loc.gov>
   Intended usage: COMMON
   Restrictions on usage: None
Author/Change controller:  The MARCXML standard is driven by the MARC
   standards, maintained at the Library of Congress.

6. Registration for sru+xml 🧚

Last registration in this part: application/sru+xml. Full template:

MIME media type name: application
MIME subtype name: sru+xml
Required parameters: None
Optional parameters: (charset)  This parameter has semantics
   identical to the charset parameter of the "application/xml" media
   type as specified in [RFC3023].
Encoding considerations:  Identical to those of "application/xml" as
   described in [RFC3023].
Security considerations:  See Section 8 of RFC 6207.
Interoperability considerations:  There are no known interoperability
   issues.
Published specification:  [SRU-SCHEMA], [SRU].
Applications which use this media type:  Various SRU conformant
   toolkits use this media type.
Additional information:
   Magic number(s): None
   File extension(s): .sru
   Macintosh file type code(s): TEXT
   Person and email address to contact for further information:
      Ray Denenberg <rden@loc.gov>
   Intended usage: COMMON
   Restrictions on usage: None
Author/Change controller:  The SRU specification for versions earlier
   than 2.0 is maintained at the Library of Congress, in conjunction
   with the SRU Editorial Board.  Version 2.0 (for which the sru+xml
   media type pertains) is being developed within OASIS.

7. IANA Considerations 🌳

So IANA went ahead and registered all five media types from Sections 2, 3, 4, 5, and 6 in the MIME media type registry, which lives in the Standards Tree πŸ’–.


8. Security Considerations πŸ”βœ¨

okay bestie, this section is SO important, so let's get into it πŸ’… an XML resource doesn't compromise data security by itself 🫢 but apps that grab XML files over the network by dereferencing a Uniform Resource Identifier [RFC3986] are advised to properly interpret the data so nothing gets accessed that shouldn't be πŸ‘€ so the security issues in Section 7 of [RFC3986] apply here, obviously πŸ’–

because the media types in this document use the "+xml" convention, they share the security considerations in Section 10 of [RFC3023] 🌸 same energy, same vibes πŸ’œ

and in general, the security issues for using XML in IETF protocols from Section 7 of [RFC3470] also apply πŸŽ€ the next sections look at a few things that matter most for document-centric XML used for text encoding, so stay with me πŸ¦‹

8.1. Harmful Content πŸ’€

any app that retrieves the XML media types from this spec needs to be aware of the risks from injecting harmful scripts and executable XML (aka "active content", as described in [RFC4288]) 😭 ngl, external entities and XML inclusion mechanisms can open the door to spoofing and can also reveal stuff about a service in a way that might compromise its security πŸ™ˆ but those vulnerabilities are application specific, so it depends on the app πŸ”₯

the good news? MODS documents do NOT contain "active content" πŸ™Œβœ¨

8.2. Authenticity and Confidentiality πŸ”’

historical and bibliographical info can often be encoded in MODS documents, and that info might even have legal force in some jurisdictions βš–οΈ digitizing and encoding it might need technologies for assuring authenticity, like cryptographic check sums and electronic signatures πŸ” historical docs might also be confidential in whole or in part 🀫 that confidentiality could be required by law, or by terms and conditions (like with donated or deposited text from private sources) πŸ’Œ a text archive might need content filtering or cryptographic technologies to meet those requirements πŸ›‘οΈ

9. References πŸ“š

9.1. Normative References πŸ’œ

[RFC3023]         Murata, M., St. Laurent, S., and D. Kohn, "XML
                  Media Types", RFC 3023, January 2001.

[RFC3470]         Hollenbeck, S., Rose, M., and L. Masinter,
                  "Guidelines for the Use of Extensible Markup
                  Language (XML) within IETF Protocols", BCP 70,
                  RFC 3470, January 2003.

[RFC3986]         Berners-Lee, T., Fielding, R., and L. Masinter,
                  "Uniform Resource Identifier (URI): Generic
                  Syntax", STD 66, RFC 3986, January 2005.

[MADS-SCHEMA]     Denenberg, R., "MADS Schema",
                  <http://www.loc.gov/standards/mads/mads.xsd>.

[MADS]            Denenberg, R., "Metadata Authority Description
                  Schema", <http://www.loc.gov/standards/mads/>.

[MARCXML-SCHEMA]  Trail, N., "MARCXML Schema", <http://www.loc.gov/
                  standards/marcxml/schema/MARC21slim.xsd>.

[MARCXML]         Trail, N., "MARCXML MARC21 XML Schema",
                  <http://www.loc.gov/standards/marcxml/>.

[METS-SCHEMA]     Redding, C., "METS Schema",
                  <http://www.loc.gov/standards/mets/mets.xsd>.

[METS]            Redding, C., "Metadata Encoding and Transmission
                  Standard", <http://www.loc.gov/standards/mets/>.

[MODS-SCHEMA]     Denenberg, R., "MODS Schema",
                  <http://www.loc.gov/standards/mods/mods.xsd>.

[MODS]            Denenberg, R., "Metadata Object Description
                  Schema", <http://www.loc.gov/standards/mods/>.

[SRU-SCHEMA]      Denenberg, R., "SRU Schema", <http://www.loc.gov/
                  standards/sru/oasis/schemas/sruResponse.xsd>.

[SRU]             Denenberg, R., "Search/Retrieve via URL Response
                  Format", <http://www.loc.gov/standards/sru/>.

9.2. Informative References 🌈

[RFC2220]         Guenther, R., "The Application/MARC Content-type",
                  RFC 2220, October 1997.

[RFC4288]         Freed, N. and J. Klensin, "Media Type
                  Specifications and Registration Procedures",
                  BCP 13, RFC 4288, December 2005.

Author's Address πŸ¦‹

Ray Denenberg (editor)
Library of Congress
101 Independence Ave, SE
Washington, DC  20540
USA

Phone: (202) 707-5795
EMail: rden@loc.gov
πŸ“¦ where this page comes from