Matroska Tags
draft-ietf-cellar-tags-02

Abstract

This document defines the Matroska tags, namely the tag names and their respective semantic meaning.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 23, 2020.

Copyright Notice

Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Status of this document
• 3. Security Considerations
• 4. IANA Considerations
• 5. Notations and Conventions
• 6. Tagging
• 6.1. Why official tags matter
• 6.2. Tag translations
• 6.3. Tag Formatting
• 6.4. Target types
• 6.5. Official tags
• 6.6. Nesting Information
• 6.7. Organization Information
• 6.8. Titles
• 6.9. Nested Information
• 6.10. Entities
• 6.11. Search and Classification
• 6.12. Temporal Information
• 6.13. Spacial Information
• 6.14. Personal
• 6.15. Technical Information
• 6.16. Identifiers
• 6.17. Commercial
• 6.18. Legal
• 6.19. Notes
• Authors' Addresses

1. Introduction

Matroska aims to become THE standard of multimedia container formats. It can store timestamped multimedia data but also chapters and tags. The Tag Elements add important metadata to identify and classify the information found in a Matroska Segment. It can tag a whole Segment, separate Track Elements, individual Chapter Elements or Attachment Elements.

While the Matroska tagging framework allows anyone to create their own custom tags, it's important to have a common set of values for interoperability. This document intends to define a set of common tag names used in Matroska.

2. Status of this document

This document is a work-in-progress specification defining the Matroska file format as part of the IETF Cellar working group. It uses basic elements and concepts already defined in the Matroska specifications defined by this workgroup.

3. Security Considerations

Tag values can be either strings or binary blobs. This document inherits security considerations from the EBML and Matroska documents.

4. IANA Considerations

To be determined.

5. Notations and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

6. Tagging

When a Tag is nested within another Tag, the nested Tag becomes an attribute of the base tag. For instance, if you wanted to store the dates that a singer used certain addresses for, that singer being the lead singer for a track that included multiple bands simultaneously, then your tag tree would look something like this:

• Targets
  • TrackUID
• BAND
  • LEADPERFORMER
  • ADDRESS
    • DATE
    • DATEEND
  • ADDRESS
    • DATE

In this way, it becomes possible to store any Tag as attributes of another tag.

Multiple items SHOULD never be stored as a list in a single TagString. If there is more than one tag of a certain type to be stored, then more than one SimpleTag SHOULD be used.

For authoring Tags outside of EBML, the following XML syntax is proposed used in mkvmerge. Binary data SHOULD be stored using BASE64 encoding if it is being stored at authoring time.

6.1. Why official tags matter

There is a debate between people who think all tags SHOULD be free and those who think all tags SHOULD be strict. If you look at this page you will realize we are in between.

Advanced-users application might let you put any tag in your file. But for the rest of the applications, they usually give you a basic list of tags you can use. Both have their needs. But it's usually a bad idea to use custom/exotic tags because you will probably be the only person to use this information even though everyone else could benefit from it. So hopefully when someone wants to put information in one's file, they will find an official one that fit them and hopefully use it ! If it's not in the list, this person can contact us any time for addition of such a missing tag. But it doesn't mean it will be accepted... Matroska files are not meant the become a whole database of people who made costumes for a film. A website would be better for that... It's hard to define what SHOULD be in and what doesn't make sense in a file. So we'll treat each request carefully.

We also need an official list simply for developers to be able to display relevant information in their own design (if they choose to support a list of meta-information they SHOULD know which tag has the wanted meaning so that other apps could understand the same meaning).

6.2. Tag translations

To be able to save tags from other systems to Matroska we need to translate them to our system. There is a translation table on our site.

6.3. Tag Formatting

• The TagName SHOULD always be written in all capital letters and contain no space.
• The fields with dates SHOULD have the following format: YYYY-MM-DD hh:mm:ss.mss YYYY = Year, MM = Month, DD = Days, HH = Hours, mm = Minutes, ss = Seconds, mss = Milliseconds. To store less accuracy, you remove items starting from the right. To store only the year, you would use, "2004". To store a specific day such as May 1st, 2003, you would use "2003-05-01".
• Fields that require a Float SHOULD use the "." mark instead of the "," mark. To display it differently for another local, applications SHOULD support auto replacement on display. Also, a thousandths separator SHOULD NOT be used.
• For currency amounts, there SHOULD only be a numeric value in the Tag. Only numbers, no letters or symbols other than ".". For instance, you would store "15.59" instead of "$15.59USD".

6.4. Target types

The TargetType element allows tagging of different parts that are inside or outside a given file. For example in an audio file with one song you could have information about the album it comes from and even the CD set even if it's not found in the file.

For application to know what kind of information (like TITLE) relates to a certain level (CD title or track title), we also need a set of official TargetType names. For now audio and video will have different values & names. That also means the same tag name can have different meanings depending on where it is (otherwise we would end up with 15 TITLE_ tags).

An upper level value tag applies to the lower level. That means if a CD has the same artist for all tracks, you just need to set the ARTIST tag at level 50 (ALBUM) and not to each TRACK (but you can). That also means that if some parts of the CD have no known ARTIST the value MUST be set to nothing (a void string "").

When a level doesn't exist it MUST NOT be specified in the files, so that the TOTAL_PARTS and PART_NUMBER elements match the same levels.

Here is an example of how these organizational tags work: If you set 10 TOTAL_PARTS to the ALBUM level (40) it means the album contains 10 lower parts. The lower part in question is the first lower level that is specified in the file. So if it's TRACK (30) then that means it contains 10 tracks. If it's MOVEMENT (20) that means it's 10 movements, etc.

6.5. Official tags

The following is a complete list of the supported Matroska Tags. While it is possible to use Tag names that are not listed below, this is not recommended as compatibility will be compromised. If you find that there is a Tag missing that you would like to use, then please contact the Matroska team for its inclusion in the specifications before the format reaches 1.0.

6.6. Nesting Information

Nesting Information tags are intended to contain other tags.

6.7. Organization Information

6.8. Titles

6.9. Nested Information

Nested Information includes tags contained in other tags.

6.10. Entities

6.11. Search and Classification

6.12. Temporal Information

6.13. Spacial Information

6.14. Personal

6.15. Technical Information

6.16. Identifiers

6.17. Commercial

6.18. Legal

6.19. Notes

• In the Target list, a logical OR is applied on all tracks, a logical OR is applied on all chapters. Then a logical AND is applied between the Tracks list and the Chapters list to know if an element belongs to this Target.

Authors' Addresses