BioFortis, Inc.

10320 Little Patuxent Parkway, Suite 410 Columbia MD 21044 US +1 443 276-2464 ietf@shaftek.org

SQL MIME This document registers the application/sql media type to be used for the Structured Query Language (SQL).

The Structured Query Language (SQL) has been in use for over 30 years with various types of database technologies. However, there is no current media type registered for SQL. Therefore, this document seeks to formally register the application/sql media type to be used for SQL with IANA.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in when they appear in ALL CAPS. These words may also appear in this document in lowercase as English prose, absent of the normative meanings mentioned above.

This section provides the media type registration application for this media type (see , Section 5.6) Type name: application Subtype name: sql Required parameters: N/A Optional parameters: "charset" -- indicates the character set to be used. When not specified, a default value MUST NOT be assumed without inspection of the content. Implementors should be aware that SQL may carry character set information in-band. In such cases, the "charset" parameter MUST NOT be used in order to avoid conflict. In cases where no character set information is supplied in-band, and the character set is known, implementors SHOULD use the "charset" parameter. If no in-band or out-of-band character set information is available, implementors MUST NOT specify the "charset" parameter. Encoding considerations: If the "charset" parameter is used, the corresponding 7-bit, 8-bit, or binary encoding may be used. If the "charset" parameter is not used, binary encoding may be required. Security considerations: Being that SQL is a full-fledged programming language and may include embedded source code for other programming languages, there is a risk of it being used to transfer malware, viruses, and other malicious payloads. Implementors and users are encouraged only to exchange SQL files among trusted parties and utilize all available security measures, such as restricted access, virus scanners, etc., to minimize risk. Implementors should be aware that guessing character sets, encodings, and possible conflicts between in-band and out-of-band character set information may lead to the similar security issues as described above. Implementors should also be aware that SQL does not provide or guarantee any sort of confidentiality and integrity checking, and SQL files can expose account information or private information about database structure and contents. It is therefore important for applications to provide confidentiality and protection against modification by malicious third parties while in transit. Interoperability considerations: While a single standard exists (), vendor implementations of the standard vary significantly. Implementors and users should make sure that the exchanged SQL files match to the specific database/tool and version that they are using. Published specification: The most recent specification of SQL is available in . Applications that use this media type: Databases and related tools Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): sql Macintosh File Type Code(s): N/A Person & email address to contact for further information: Yakov Shafranovich <ietf@shaftek.org> Intended usage: COMMON Restrictions on usage: N/A Author: IESG Change controller: IESG Provisional registration? (standards tree only): N/A

IANA has registered "application/sql" in the standards tree of the "Application Media Types" registry, using the application provided in of this document.

See the Security Considerations item in the registration template in , above.

To LTS, thanks for everything. The author would also like to thank all of the folks at xml.resource.org for providing many of the tools used for preparing RFCs and Internet-Drafts. A word of thanks to all IETF members who provided feedback on this document.

Harvard University

1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu

Generalkeyword 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. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. 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. International Organization for Standardization