(registered by RFC 4180, last updated 2014-01-17) Type name: text Subtype name: csv Required parameters: none Optional parameters: charset, header The "charset" parameter specifies the charset employed by the CSV content. In accordance with RFC 6657 [RFC6657], the charset parameter SHOULD be used, and if it is not present, UTF-8 SHOULD be assumed as the default (this implies that US- ASCII CSV will work, even when not specifying the "charset" parameter). Any charset defined by IANA for the "text" tree may be used in conjunction with the "charset" parameter. The "header" parameter indicates the presence or absence of the header line. Valid values are "present" or "absent". Implementors choosing not to use this parameter must make their own decisions as to whether the header line is present or absent. Encoding considerations: CSV MIME entities consist of binary data [RFC6838]. As per section 4.1.1. of RFC 2046 [RFC2046], this media type uses CRLF to denote line breaks. However, implementers should be aware that some implementations may use other values. Security considerations: Text/csv consists of nothing but passive text data that should not pose any direct risks. However, it is possible that malicious data may be included in order to exploit buffer overruns or other bugs in the program processing the text/csv data. The text/csv format provides no confidentiality or integrity protection, so if such protections are needed they must be supplied externally. The fact that software implementing fragment identifiers for CSV and software not implementing them differs in behavior, and the fact that different software may show documents or fragments to users in different ways, can lead to misunderstandings on the part of users. Such misunderstandings might be exploited in a way similar to spoofing or phishing. Implementers and users of fragment identifiers for CSV text should also be aware of the security considerations in RFC 3986 [RFC3986] and RFC 3987 [RFC3987]. Interoperability considerations: Due to lack of a single specification, there are considerable differences among implementations. Implementers should "be conservative in what you do, be liberal in what you accept from others" (RFC 793 [RFC0793]) when processing CSV files. An attempt at a common definition can be found in Section 2. Implementations deciding not to use the optional "header" parameter must make their own decision as to whether the header is absent or present. Published specification: While numerous private specifications exist for various programs and systems, there is no single "master" specification for this format. An attempt at a common definition can be found in Section 2 of RFC 4180 [RFC4180]. Applications that use this media type: Spreadsheet programs and various data conversion utilities. Fragment identifier considerations: Fragment identification for text/csv is supported by using fragment identifiers as specified by RFC7111. 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 and Erik Wilde Intended usage: COMMON Restrictions on usage: none Author: Yakov Shafranovich and Erik Wilde Change controller: IESG