SolidMatrix Technologies, Inc.

ietf@shaftek.org http://www.shaftek.org

CSV MIME comma separated This document defines MIME types "text/csv" and "text/comma-separated-values" which used for Comma-Separated Values (CSV) files.

The comma separated values format (CSV) has been used for exchanging and converting data between various spreadsheet programs for quite some time. Surprisingly, while this file is very common it has never been formally documented. Additionally, while the IANA MIME registration tree includes a registraton for "text/tab-separated-values" type, no MIME types have ever been registered with IANA for CSV. At the same time, various programs and operating systems have begun to use different MIME types for this format, many of which vary from system to system. This document seeks to formally register two MIME types for CSV in accordance with RFC 2048.

This section provides the media-type registration application (as per RFC 2048, which will be submitted to IANA after IESG approval of this document. To: ietf-types@iana.org Subject: Registration of MIME media types text/csv and text/comma-separated-values MIME media type name: text MIME subtype name: csv, comma-separated-values Required parameters: none Optional parameters: charset Common usage of CSV is US-ASCII, but other character sets as defined by IANA for the "text" tree may be used. Encoding considerations: While section 4.1.1. of RFC 2046 stipulates that "text" subtypes MUST use a CRLF sequence as a line break, in practice that is not always true for CSV. Therefore, implementors should be aware that either CR or CRLF maybe used as a line break for this format. Security considerations: CSV files contain passive text data which should not pose any risks. However, it is possible in theory that malicious binary data maybe included in order to exploit potential buffer overruns in the program processing CSV data. Additionally, private data maybe shared via this format which of course applies to any text data. Interoperability considerations: Due to lack of a single specification there are considerable differences among different implementations as described in appendix A. The most common difference among various format is whether double quotes (") are used to enclose strings. Implementors should "be conservative in what you do, be liberal in what you accept from others" (RFC 793) when processing CSV files. Published specification: While numerous private specifications exist for various programs and systems, there is no single "master" specification for this format. A sampling of formats and discussion of differences is included in appendix A. Applications which use this media type: Spreadsheet programs and various data conversion utilities Additional information: Magic number(s): none File extension(s): CSV Macintosh File Type Code(s): TEXT Person & email address to contact for further information: Yakov Shafranovich <ietf@shaftek.org> Intended usage: COMMON Author/Change controller: IESG

After IESG approval, IANA is expected to register these two types "text/csv" and "text/comma-separated-values" using the application provided in this document.

See discussion above

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US

Innosoft International, Inc.

1050 East Garvey Avenue South West Covina CA 91790 US +1 818 919 3600 +1 818 919 3614 ned@innosoft.com

First Virtual Holdings

25 Washington Avenue Morristown NJ 07960 US +1 201 540 8967 +1 201 993 3032 nsb@nsb.fv.com

STD 11, RFC 822 defines a message representation protocol specifying considerable detail about US-ASCII message headers, but which leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for (1) textual message bodies in character sets other than US-ASCII, (2) an extensible set of different formats for non-textual message bodies, (3) multi-part message bodies, and (4) textual header information in character sets other than US-ASCII. These documents are based on earlier work documented in RFC 934, STD 11 and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822. The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. This second document defines the general structure of the MIME media typing sytem and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. Internet Mail Consortium

675 Spruce Dr. Sunnyvale CA 94086 US +1 408 246 8253 +1 408 249 6205 dcrocker@imc.org

Demon Internet Ltd.

Dorking Business Park Dorking Surrey England RH4 1HN UK paulo@turnpike.com

ABNF Augmented Backus-Naur Form electronic mail Creativyst, Inc.

120 Jefferson St. Riverside NJ 08075 USA +1-856-764-5099 http://www.creativyst.com

Edoceo, Inc.

620 W. Olympic Pl. #206 Seatle WA 98119 USA +1-206-378-5619 http://www.edoceo.com

Addison-Wesley

esr@thyrsus.com http://www.catb.org/~esr/

Ricebridge

Waterford Ireland

Innosoft International, Inc.

1050 East Garvey Avenue South West Covina CA 91790 USA +1 818 919 3600 +1 818 919 3614 ned@innosoft.com

MCI

2100 Reston Parkway Reston VA 22091 +1 703 715-7361 +1 703 715-7436 klensin@mci.net

USC/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90292 USA +1 310 822 1511 +1 310 823 6714 Postel@ISI.EDU

Applications mail media type multipurpose internet mail extensions STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for (1) textual message bodies in character sets other than US-ASCII, (2) an extensible set of different formats for non-textual message bodies, (3) multi-part message bodies, and (4) textual header information in character sets other than US-ASCII. These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822. This fourth document, RFC 2048, specifies various IANA registration procedures for the following MIME facilities: (1) media types, (2) external body access types, (3) content-transfer-encodings. Registration of character sets for use in MIME is covered elsewhere and is no longer addressed by this document. These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions.

While there are various specifications and implementations for the CSV format (for ex. , , and ), no formal specification exists. This causes a wide variety of interpretations for CSV files. While this document does not seek to document the CSV format, nevertheless we want to document the format that seems to be followed by most implementations: Each record is located on a separate line delimited by a line break (either CR or CR/LF). For example: aaa,bbb,ccc CRLF zzz,yyy,xxx CRLF The last record in the file may or may not have an ending linebreak. For example: aaa,bbb,ccc CRLF zzz,yyy,xxx There maybe an optional header line appearing as the first line of the file with the same format as normal record lines. This header will contain names corresponding to the fields in the file and will usually contain the same number of fields as the records in the rest of the file. For example: field_name,field_name,field_name CRLF aaa,bbb,ccc CRLF zzz,yyy,xxx CRLF Within the header and each record there may be one or more fields, delimited by commas. The last field in the record may or may not be followed by a comma. For example: aaa,bbb,ccc Each field may or may not be enclosed in double quotes, however some programs such as Microsoft Excel do not use double quotes at all. For example: "aaa","bbb","ccc" CRLF zzz,yyy,xxx Field containing line breaks (CR or CR/LF) and commas should be enclosed in double-quotes. For example: "aaa","b CRLF bb","ccc" CRLF zzz,yyy,xxx If double-quotes are used to enclosed fields, then double-quotes inside fields must be surounded by double quotes. For example: "aaa","b"""bb","ccc" Whitespace immediately before and after commas maybe removed unless it appears inside double-quotes. For example: zzz, yyy , xxx would be processed as if it was: zzz,yyy,xxx The ABNF grammar appears as follows: COMMA = %x2C file = [header] *record end-of-field = COMMA / (CR / CRLF) header = *(*WSP field *WSP end-of-field) record = *(*WSP field *WSP end-of-field) field = escaped / non-escaped escaped = DQUOTE *(VCHAR / CR / CRLF / 3*DQUOTE) DQUOTE non-escaped = *VCHAR