Multi-Sheet Tab-Separated Values (MTSV)

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 20 March 2027.¶

Copyright Notice

Copyright (c) 2026 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The tab-separated values format [TSV] encodes one set of records per file. Fields are separated by a tab, and records are separated by line breaks.¶

Both separators are ASCII format effectors [RFC20]. HT moves "to the next in a series of predetermined positions along the printing line", and LF moves "to the next printing line". MTSV adds FF, the format effector for the next larger unit, which moves "to the first pre-determined printing line on the next form or page". Tab gives the next field, line feed gives the next record, and form feed gives the next sheet.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

The grammar in this document uses ABNF [RFC5234], including its core rules HTAB, LF, and CRLF.¶

In examples, <TAB> denotes the tab character (%x09), as in [TSV], and <FF> denotes the form feed character (%x0C). Line breaks are shown as line breaks; every line shown, including the last, ends with a line break.¶

This document uses the following terms:¶

field:

A text value, as defined in [TSV].¶

record:

A sequence of fields on one line, as defined in [TSV].¶

header:

The first record of a sheet, which contains the name of each field, as defined in [TSV].¶

sheet:

A header followed by zero or more records, or no lines at all (an empty sheet). The term matches the corresponding structure in [OOXML].¶

sheet name:

The text that follows an FF on the same line.¶

unnamed sheet:

The sheet formed by the lines before the first FF, or by all lines of a file that contains no FF. It exists only if there is at least one such line.¶

MTSV file:

A sequence of sheets, conforming to Section 4.¶

TSV file:

A file conforming to [TSV].¶

generator:

An implementation that writes MTSV files.¶

parser:

An implementation that reads MTSV files.¶

3. Data Model

A field is text. A record is an ordered sequence of fields. A sheet is a header and an ordered sequence of zero or more records. Every record in a sheet has as many fields as the header of that sheet. A sheet with no lines is an empty sheet; it has neither a header nor records.¶

An MTSV file is an ordered sequence of sheets. The order of the sheets is the order in which they appear in the file.¶

Every sheet has a sheet name, except the unnamed sheet. An MTSV file has an unnamed sheet only if the file contains at least one line before the first FF. An empty sheet name is permitted. Sheet names are not required to be unique.¶

A TSV file that contains no FF, and no CR other than in CRLF line breaks, is an MTSV file that consists of exactly one unnamed sheet.¶

4. Syntax

mtsv-file     = unnamed-sheet *named-sheet
unnamed-sheet = sheet-body
named-sheet   = FF sheet-name eol sheet-body
sheet-body    = [header *record]
header        = record
record        = field *(HTAB field) eol
field         = *field-char
sheet-name    = *field-char
field-char    = %x00-08 / %x0B / %x0E-10FFFF
                ; any character except HTAB, LF, FF, and CR
FF            = %x0C
eol           = LF / CRLF

5. Parsers

An MTSV parser MUST accept every MTSV file that conforms to Section 4.¶

A parser MUST treat the lines before the first FF, if any, as the unnamed sheet, and each line that begins with an FF as the start of a new sheet.¶

A parser MUST accept both LF and CRLF as line breaks, consistent with the default line terminators in [CSVW].¶

A parser SHOULD treat a U+FEFF character at the start of a file as an encoding signature and not as part of the first field, consistent with Section 6 of [RFC3629].¶

A parser MAY accept input that does not conform to this document.¶

An implementation MAY set limits on the size of files, the number of sheets, records, and fields, and the length of fields and sheet names, consistent with Section 9 of [RFC8259].¶

6. Generators

An MTSV generator MUST produce MTSV files that conform to Section 4.¶

A generator MUST end every record with a line break. A generator SHOULD encode MTSV files in UTF-8, consistent with [RFC2277].¶

A field or sheet name that contains HT, LF, FF, or CR cannot be represented in MTSV, as with fields that contain a tab in [TSV]. A generator MUST NOT write such a value. How a generator handles such values is out of scope.¶

The first field of the unnamed sheet cannot begin with U+FEFF, because a parser treats that character as an encoding signature (Section 5). A generator MUST NOT write such a field.¶

7. Examples

Name<TAB>Age<TAB>Address
Paul<TAB>23<TAB>1115 W Franklin
Bessy the Cow<TAB>5<TAB>Big Farm Way
Zeke<TAB>45<TAB>W Main St

<FF>People
Name<TAB>Age<TAB>Address
Paul<TAB>23<TAB>1115 W Franklin
Zeke<TAB>45<TAB>W Main St
<FF>Animals
Name<TAB>Age<TAB>Address
Bessy the Cow<TAB>5<TAB>Big Farm Way

Name<TAB>Age
Paul<TAB>23
<FF>Empty
<FF>Animals
Name<TAB>Age
Bessy the Cow<TAB>5

8. Interoperability Considerations

Section 1.1 describes which TSV files are MTSV files. This section describes how common text processing affects MTSV files.¶

MTSV gives structure to four characters: HT, LF, FF, and CR. These characters also have other standard properties, and text processing that acts on those properties can change the structure of an MTSV file:¶

Line splitting:

FF has the mandatory break class in [UAX14]. An application that supports only TSV can present a line that begins with an FF either as a record whose first field begins with FF, or as an empty line followed by a line that contains the sheet name.¶

Whitespace:

HT, LF, FF, and CR have the White_Space property in [UCD]. Trimming whitespace from a line can remove an FF, which turns a sheet name into a record, or remove an HT at either end of a line, which removes empty fields. Splitting a line on runs of whitespace removes empty fields and splits fields that contain spaces.¶

Tab expansion:

Replacing HT with spaces removes the field structure, as it does for [TSV].¶

Control characters:

FF is a control character. Applications that remove or reject control characters remove sheet boundaries. [XML] does not permit FF, so an MTSV file cannot be carried as XML 1.0 character data without an additional encoding.¶

Line endings:

Converting between LF and CRLF does not change the structure of an MTSV file (Section 5). Converting line breaks to CR alone produces a file that does not conform to this document.¶

Concatenation:

Concatenating MTSV files produces an MTSV file that contains the sheets of each file, in order, only if each non-empty file ends with a line break and each non-empty file after the first begins with an FF. Otherwise, the unnamed sheet of a later file becomes part of the last sheet of the file before it.¶

Unchanged structure:

Printing, Unicode normalization, and conversion between character sets do not change the structure of an MTSV file.¶

Spreadsheets:

Spreadsheet applications apply their own rules to sheet names, such as uniqueness and length, and to data types and sizes. These rules are outside the scope of this document.¶

9. IANA Considerations

10. Internationalization Considerations

This section collects the internationalization decisions of this document, as Section 6 of [RFC2277] recommends.¶

HT, LF, CRLF, and FF are protocol elements. Fields and sheet names are text (Section 3), as Section 2 of [RFC2277] requires a protocol to distinguish.¶

An MTSV file carries no in-band charset information. The charset parameter of the media type identifies the charset (Section 9.1), and UTF-8 is assumed when that parameter is absent (Section 4.1), so that a stored file remains readable without it, as Section 3.2 of [RFC2277] advises. Any other charset is one registered in the IANA charset registry, as Section 3.1 of [RFC2277] requires.¶

Sheet names are internationalized. A sheet name is text and follows the same rules as a field (Section 3); it is not a US-ASCII identifier. Section 2 of [RFC2277] requires a document to state this.¶

MTSV carries no language information. This document leaves language to the enclosing protocol or to separate metadata such as [CSVW], which Section 2 of [RFC2277] permits where the responsibility belongs to another layer.¶

11. Security Considerations

MTSV files are text and contain no executable content. [TSV] lists no security considerations.¶

Applications that import MTSV files into spreadsheets can interpret fields that begin with characters such as "=", "+", "-", or "@" as formulas. Such applications need to treat imported fields as data.¶

Sheet names can contain control characters. Applications that display sheet names need to take care that such characters do not mislead users.¶

Parsers that do not set limits (Section 5) can exhaust resources when reading large files or files with very many sheets.¶

12. References

Appendix A. Change Log

This section is to be removed before publishing as an RFC.¶

draft-demosra-mtsv-00:

Replaces draft-demos-ra-mtsv-00, renamed so that the author component contains no hyphen. Replaced the byte order mark rules with a parser rule that follows Section 6 of RFC 3629, and stated that a first field that begins with U+FEFF cannot be represented. Removed the rule on a final record without a line break, which the rule on non-conforming input already covers. Cited CSVW as the source of LF and CRLF line breaks. Added an Internationalization Considerations section, and placed the IANA, Internationalization, and Security Considerations sections in the order that Section 4 of RFC 7322 recommends.¶

draft-demos-ra-mtsv-00:

Initial version.¶

Author's Address