]>

mrankin@oldgrognard.pub

next generation unicorn sparkling distributed ledger This document establishes the format used for Control-Character-Separated Values (CCSV) files and registers the associated MIME type "text/ccsv". About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction A CCSV (Control-Character-Separated Values file) is a file format that enables moving data between spreadsheets, statistical analysis programs, databases, and any other program that works with rectangular data. It is very similar to (CSV) Comma-Separated Values files , (TSV) Tab-Separated Values files, and their derivatives. Unlike those file types, the CCSV minimizes usage ambiguity by having non-printable characters as delimiters. The two delimiter characters may not appear in the document's text, making the practice of escaping certain characters or adding additional delimiters for certain strings unnecessary. This document seeks to define the format of Control Character Separated Values (CCSV) files and formally register the "text/ccsv" Media Type for CCSV in accordance with .

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 when, and only when, they appear in all capitals, as shown here.

Definition of the CCSV format In order for a file to be a CCSV, it MUST adhere to the following formatting rules:

Formatting Rules

1. The file MUST use UTF-8 encoding. Since US-ASCII is a subset of UTF-8, programs may create CCSV files with that encoding. A consuming program may not be able to interpret all characters if it only works with US-ASCII and SHOULD work with UTF-8 if the source is unknown.
2. The file MUST NOT begin with a Byte Order Mark (U+FEFF).
3. A CCSV MUST begin with a header. The header consists of the names of the columns separated with US (U+001F) entities.
4. A Unit Separator US (U+001F) is used between each field in a record. Note that carriage returns and line feeds are not part of the delimiter and are valid characters in the body of a field.
5. A Record Separator RS (U+001E) is used between each record in the file including the header.
6. A Record Separator RS (U+001E) MAY appear as the last entity of the last record but is NOT RECOMMENDED.
7. The header and each record, if any, MUST contain the same number of US (U+001F) entities. Consequently, the header and every record will have the same number of fields.
8. Empty fields are represented by consecutive delimiters.
9. The US (U+001F) entity and the RS (U+001E) entity MUST NOT appear in the body of a field.

The ABNF grammar appears as follows:

Encoding Considerations CCSV files MUST be encoded using UTF-8 . Implementations MUST NOT add a byte order mark (U+FEFF) to the beginning of the file or networked-transmitted text.

Why UTF-8?

Compatibility UTF-8 is widely supported across different platforms, operating systems, and languages. This ensures that CCSV files can be opened and read correctly regardless of the environment they are used in.

Internationalization UTF-8 supports a vast range of characters from various languages, including those that use non-Latin scripts. This is crucial for data that might include international names, addresses, or other text in multiple languages, ensuring that all characters are preserved and displayed correctly.

Efficiency UTF-8 is a variable-width encoding scheme that uses 1 to 4 bytes for each character. It is efficient for encoding text that is primarily in English, as it uses only one byte for the most common characters, but can still accommodate characters from other languages when needed.

Standardization By requiring UTF-8, the CCSV format ensures a standard way of encoding text, which simplifies processing, parsing, and exchanging files. It helps in avoiding the complexities and potential errors that can arise from dealing with multiple encodings.

Future-Proofing As the internet and technologies continue to evolve, UTF-8 remains a robust and forward-compatible choice, ensuring that CCSV files remain accessible and usable in the long term

Security Considerations CCSV files alone are considered relatively harmless as there is no additional prescribed processing. However, the file may be parsed and further processed by the recipient. To the extent that a receiving application executes arbitrary system level commands from strings contained in a CCSV file, they may be at risk.

Interoperability Considerations Adherence to the Formatting Rules and the Encoding Considerations ensures a high level of interoperability.

IANA Considerations This section provides the media-type registration application (as per ). Type name: text Subtype name: ccsv Required parameters: N/A Optional parameters: N/A Encoding considerations: See Security considerations: See Interoperability considerations: See Published specification: TBD Applications that use this media type: Fragment identifier considerations: N/A Additional information: Person & email address to contact for further information: Intended usage: COMMON Restrictions on usage: N/A Author/Change controller: Mike Rankin Provisional registration?

Normative References This RFC documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv". This memo provides information for the Internet community. This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.

Acknowledgments TODO acknowledge.