Common Format and Media Type for Control-Character-Separated Values (CCSV) Files

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 2 May 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

A CCSV (Control-Character-Separated Values) file is a file format for moving rectangular data between applications such as spreadsheets, statistical analysis programs, databases, and conversion utilities.¶

CCSV is similar in purpose to Comma-Separated Values (CSV) files [RFC4180], Tab-Separated Values (TSV) files, and their derivatives. CCSV differs primarily in its use of non-printable ASCII control characters as field and record separators.¶

Using control characters as separators reduces ambiguity when field values contain characters commonly used as delimiters in other formats. In particular, CCSV does not require quoting or escaping ordinary printable characters solely because those characters have special meaning in other delimited-value formats.¶

A CCSV file consists of a required header followed by zero or more records. The header and every record contain the same number of fields. The first row therefore defines the names of the columns, while subsequent rows contain the corresponding values.¶

This document defines the CCSV file format and registers the text/ccsv media type.¶

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 following terms are used throughout this document:¶

• Field: A single value withing a CCSV record.¶

• Record: A sequence of fields representing one row of data.¶

• Header: The first record in a CCSV file. The fields in the header identify the columns of the file.¶

• Unit Separator (US): The Unicode character U+001F, used to separate fields.¶

• Record Separator (RS): The Unicode character U+001E, used to separate records.¶

3. CCSV Format

file       = header RS *(record RS) [record]
header     = field *(US field)
record     = field *(US field)
field      = *field-char
field-char = %x00-1D /
             %x20-7F /
             UTF8-2 /
             UTF8-3 / UTF8-4

RS         = %x1E ; Record Separator, U+001E

US         = %x1F ; Unit Separator, U+001F

UTF8-2     = %xC2-DF UTF8-tail

UTF8-3     = %xE0 %xA0-BF UTF8-tail /
             %xE1-EC 2( UTF8-tail ) /
             %xED 3( UTF8-tail ) /
             %xEE-EF 2( UTF8-tail )

UTF8-4     = %xF0 %x90-BF 2( UTF8-tail ) /
             %xF1-F3 3( UTF8-tail ) /
             %xF4 %x80-8F 2( UTF8-tail )

UTF8-tail  = %x80-BF

field<US>field2
<US>field2
field1<US>
<US>

4. Encoding Considerations

CCSV files MUST be encoded using UTF-8 [RFC3629].¶

The UTF-8 encoding applies to the entire CCSV file, including the header and all field contents.¶

A CCSV file MUST NOT begin with a UTF-8 byte order mark (BOM, U+FEFF).¶

UTF-8 permits CCSV to represent Unicode text while retaining the single-octet representation of the ASCII control characters used as delimiters.¶

CR and LF are data characters in CCSV and are not record delimiters. Applications transporting CCSV content MUST preserve CR and LF occurring within fields as data.¶

When CCSV is transported using a protocol or representation that imposes additional requirements on textual content, those requirements apply to the transport representation. Such processing MUST NOT alter the CCSV data represented by the payload.¶

5. Internationalization Considerations

CCSV uses UTF-8 [RFC3629] and therefore supports Unicode text in field and header values.¶

CCSV does not define a language, locale, collation, numeric format, date format, or other interpretation of field contents. Applications processing CCSV data are responsible for applying appropriate locale-specific or application-specific interpretation to field values.¶

Unicode strings are intended to be compared as identifiers or used in security-sensitive operations may require Unicode normalization or other application-specific processing. CCSV does not prescribe a normalization form.¶

6. Security Considerations

CCSV is a passive data format and does not itself define executable content. However, CCSV data is commonly imported into applications such as spreadsheets, databases, statistical software, and scripts. Those applications may assign additional semantics to particular field values.¶

In particular, applications that import CCSV data into spreadsheet software or other systems capable of evaluating expressions MUST NOT assume that field contents are trustworthy. An application may interpret a field beginning with a particular character as a formula, expression, command, or other executable content. Such applications SHOULD treat CCSV field contents as untrusted input and apply appropriate validation or escaping before passing the data to an interpreter.¶

Implementations parsing CCSV data SHOULD also protect against resource-exhaustion attacks, including excessively large fields, records, or files.¶

CCSV provides no confidentiality, integrity, authentication, or access-control mechanisms. Applications requiring those properties MUST provide them through mechanisms outside the CCSV format.¶

Implementations MUST reject malformed UTF-8 rather than silently interpreting invalid UTF-8 sequences as valid CCSV data.¶

7. Interoperability Considerations

Interoperability depends on consistent implementation of the CCSV formatting and encoding requirements.¶

In particular, implementations MUST agree on all of the following:¶

• UTF-8 encoding;¶

• absence of a leading UTF-8 BOM;¶

• US (U+001F) as the field separator;¶

• RS (U+001E) as the record separator;¶

• equal field counts in the header and every record;¶

• representation of empty fields;¶

• prohibition of US and RS within field contents; and¶

• treatment of the CR and LF as field data rather than record separators.¶

Implementations MUST NOT treat printable delimiter characters as having special CCSV semantics. CCSV does not require quoting or escaping of printable characters merely because they have special meaning in other delimited-value formats.¶

Implementations that consume CCSV SHOULD validate the file structure of the file before processing its contents.¶

8. IANA Considerations

IANA is requested to register the following media type in the Standards Tree:¶

Type name:

text¶

Subtype name:

ccsv¶

Required parameters:

charset. The charset parameter MUST have the value "UTF-8".¶

Optional parameters:

None.¶

Encoding considerations:

8bit. CCSV content is encoded using UTF-8 as specified in Section 4. CR and LF occuring within fields are data characters and are not CCSV record separators.¶

Security considerations:

See Section 6.¶

Interoperability considerations:

See Section 7.¶

Published specification:

This document.¶

Applications that use this media type:

Databases, spreadsheets, statistical programs, data conversion utilities, and other applications that process rectangular tabular data.¶

Fragment identifier considerations:

CCSV does not define a fragment identifier syntax.¶

Additional information: :¶

Deprecated alias names for this type:

None.¶

Magic number(s):

None.¶

File name extension(s):

.ccsv¶

Macintosh file type code(s):

None.¶

Person & email address to contact for further information:

Mike rankin mrankin@oldgrognard.pub¶

Intended usage:

COMMON¶

Restrictions on usage:

None.¶

Author:

Mike Rankin mrankin@oldgrognard.pub¶

Change controller:

IETF¶

9. Examples

In the examples below <US> represents U+001F and <RS> represents U+001E. The notation is used only to make the control characters visible and not part of an actual CCSV file¶

Name<US>Age<US>City<RS>
Alice<US>42<US>Boston<RS>
Bob<US>37<US>Chicago

Alice<US><US>Boston

<US>42<US>Boston

Alice<US>42<US>Boston

Alice<US>42<US>Boston<RS>

10. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3629]

Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/rfc/rfc3629>.

[RFC4180]

Shafranovich, Y., "Common Format and MIME Type for Comma-Separated Values (CSV) Files", RFC 4180, DOI 10.17487/RFC4180, October 2005, <https://www.rfc-editor.org/rfc/rfc4180>.

[RFC5234]

Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/rfc/rfc5234>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Acknowledgments

The author thanks those individuals who provided feedback and technical discussions concerning the CCSV format and its proposed media type.¶

Author's Address