This page describes a proposal by MurrayAltheim (a more actionable version of WikiTextMimeType) to submit a registration to IANA for a MIME type for wiki text. Now, this is to fully acknowledge that there isn’t one wiki text syntax, and this proposal isn’t intended to try to advocate just one syntax. The idea here is to continue to let a thousand flowers bloom, with the MIME registration just a way to identify them as flowers, i.e., as wiki documents. To do this we need to simply add a single line at the beginning of a wiki text document, just as one would find at the beginning of a perl or shell script. The line at minimum would contain an unambiguous token (sometimes called a magic number) that computers would understand as an identifier for a wiki text document:
Now, there’s still one problem. There are a thousand flowers. We’d like to be able to identify which flower. We need to do this for the use of a computer, but it’s also a good idea to provide a human-readable text too. So, these are provided as in the following example, for the wiki language “Ceryle Wyki”:
#!wiki "Ceryle Wyki" http://purl.org/ceryle/wyki/1.0/
Both of these are optional, but both are a Good Idea. The quoted string is for humans, the URL for computers. A processor could receive a text file, sniff the first line, and identify the document as (in theory, at least) conforming to a particular wiki text syntax. Related to this is the idea of creating a registry (informal, not part of IANA or any other formal registration authority) for wiki syntaxes. There’s a beginning at WikiSyntaxRegistry.
To register a new MIME type, the first thing we need to do fill out a form. I think that since this proposal would be considered “in the IETF tree” we’d need to submit an RFC (Request For Comments). I’m willing to do that, basing its contents on the form contents. The original for the form is IANA | Application for MIME Media Type. I’ve taken the form fields and recreated them below so we can discuss and fill it out together. I’m currently putting my name on the form as contact person, but I certainly am willing to have someone else take the lead if they want. I’m not a control freak about this kind of thing (which I suppose is one reason I find wikis appealing). And if this gets published as an RFC, they can have more than one name. Everybody gets credit.
Now, one thing I’d like to ask, is that if anyone wants to contribute to filling out the form, please do so. But if you have comments or commentary that aren’t part of the form, please add those outside of the area of the form itself. I’m going to take the liberty of removing comments put into the form, in the interest of keeping the content we’re working on separate from the discussion about it. Thanks!
We recommend that you read the following RFCs before proceeding with this application. It is important that you understand the application process and requirements completely. These RFCs are the standards for MIME Media Types.
Your Name: Murray Altheim
Your Email Address: m.altheim (at) open.ac.uk
2. MIME subtype name wiki
(See Existing subtype names)
See also RFC 2046, and RFC 2048, section 2.
Note: Registrations in the IETF tree must be approved by the IESG and normally are published in an RFC.
IETF Tree - (always requires RFC)
3. Required Parameters
''variant'' The "variant" parameter identifies the specific Wiki markup syntax used in the document, as discussed in this document.
''charset'' The optional parameter "charset" refers to the character encoding used to represent the Wiki document as a sequence of bytes. See Section 5. "Encoding considerations" for details.
5. Encoding considerations
See RFC 2046 section 6.
Character encodings supportive of localized content outside of ASCII are required for internationalization. For this reason, 8 bit text is the minimally-supported encoding for wiki text documents. The text/wiki media type may therefore require encoding on transports not capable of handling 8 bit text. Values for the “charset” parameter and application behaviour are as defined for EncName? (Production 81 in Section 4.3.3 of XML). In the absence of an encoding parameter, UTF-8 is assumed.
See RFC 2048, section 2.2.6
Note that discussion of security considerations is required.
In unprocessed form, wiki text documents have the same security considerations as text/plain. Typically, wiki text documents are processed to create HTML or XHTML documents. During that processing, transclusions and other forms of linking may occur (discuss). The final product as an HTML or XHTML document has the same security considerations as those types, as described in [HTML401] and [XHTML1].
See RFC 2048, section 2.2.5
blah, blah, blah
See RFC 2048, section 2.2.8
blah, blah, blah
Applications which use this media type
[[CeryleWiki:]], ... <br> (There should at least be two or three, before sending in this draft.)
See RFC 2048, section 2.2.9
There is no single initial string that is always present for wiki text documents. This RFC proposes that the token ”#!wiki” occur beginning in column one of the first line of a text document intending to be identified as a wiki text document.
No specific file extensions reliably identify wiki text documents. This document however recommends using a file name extension of either ”.txt” or ”.wik” for storage of entities with the given MIME type, the latter in cases where it is important to be able to identify files via extension. In many contexts this is not important, and ”.txt” would suffice.
Other Information/General Comment
blah, blah, blah
Person to contact for further information
See RFC 2048, section 2.2.7
Please check once again to be sure that all required fields are present.
Moved to WikiMimeComments