Also ftp://ftp.ietf.org/rfc/rfc2046.txt gives
MIME registration procedures and http://www.iana.org/assignments/media-types/ gives
an overview and other pointers about mime type registration.
paul
From: Grosso, Paul [mailto:]
Sent: Saturday, 2008 April 19 8:44
To: Erik Hennum;
Subject: RE: [dita] mime type for
DITA
See also RFC 3023 at ftp://ftp.ietf.org/rfc/rfc3023.txt.
paul
From: Erik Hennum
[mailto:]
Sent: Friday, 2008 April 18
19:57
To:
Subject: [dita] mime
type for DITA
Hi, DITA-Minded Technical Committee:
I thought it might be useful
to refresh the thread about mime types with a summary of the proposal prior
to the meeting.
This proposal is really a light modification on
Jeff's analysis. (Jeff, do you have an RFC reference for the format and type
mimetype keywords? I could swear I've seen them but can't find it for the
life of me.)
Please note the DISCUSSION item below about the
type.
Thanks,
Erik
Hennum
======================
= A mime
type for DITA
======================
MOTIVATION:
Where
client tools needs to download documents from a CMS (potentially via WebDAV)
and route requests to open those documents to the desktop editor that
understands DITA specialization.
Such client tools needs to
distingish DITA topics and maps (with base or specialized vocabularies) from
other XML documents (XMI, SVG, what have you) provided by the CMS system.
The CMS typically stores the document without an extension, so the tool
can't rely on file-system mechanisms for recognizing DITA vocabularies. If
the tool simply passes through the document from the CMS to the client
Operating System, the web brower might open the XML topic instead of the
DITA-aware editor. Without a MIME type, the tool will have to open and parse
the initial part of the file to recognize DITA topics and maps, which will
be very inefficient.
PROPOSAL:
The mime type record (such
as an HTTP header) has the following fields:
* The
application/dita+xml mime type identifies any document that use DITA
specialization.
* The format property identifies the base vocabulary for
the specialized document (in particular, topic or map).
* The type
property identifies the specialized vocabulary.
The character set
and encoding fields have no DITA-specific considerations.
NOTE:
Topics of ditabase don't have a separate format because they are just topic
documents with a list of topics rather than a single topic.
NOTE:
Because it doesn't have specialization, the DITA values file requires a
separate mime type of application/ditaval+xml. If it ever becomes
specialized, the mime type of application/dita+xml and format of ditaval
would be applicable.
DISCUSSION: The type property could reflect
either:
* The type of the root topic, first topic (for ditabase), or
map by using the class attribute (replacing spaces with a legal separator
character)
* The name of the shell
The case for using the topic
type: Fallback processing becomes possible for the root type prior to
opening the document. If the document is declared as javaClass and the
receiver understands apiClassifier, the receiver knows that it can process
the vocabulary before opening the document. If the receiver cares about
domains or subtopics, however, the receiver must open the topic to detect
them.
The case for declaring the shell: If the receiver knows the
shell, the receiver understands everything about the document without
opening it including the root type, nested topics or topics after the first
for ditabase as well as domains in either topic or map. If the receiver
doesn't know the shell identifier, however, the receiver would have to open
the document to determine fallback processing.
REFERENCE:
http://en.wikipedia.org/wiki/MIME
http://tools.ietf.org/html/rfc2046
http://tools.ietf.org/html/rfc3023
