Mimetype names (Re: mimetypes for zipped files)

[Marc Mutz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 08 April 2002 14:56, David Faure wrote:
> > [1] Unfortunately, last time I looked (a few months ago), the KOffice
> > DTD's were not properly namespaced with something like
> > xmlns:kword="http://www.kde.org/DTD/2001/koffice/kword-1.1.1.dtd",
>
> That's about adding one line at the top of the DTD, isn't it ?

Not really. My complaint about the use of XML in KOffice from back then still 
holds, I guess. It's about first defining a location on www.kde.org where the 
dtd's of releases can be kept. That one must not change in the forseeable 
future. The above URN is just an example. The dirs should actually exist, 
since it's common that the namespace URN is actually a URL where the DTD can 
be fetched from.

A .kwd that I have here expands to maindoc.xml and documentinfo.xml.
documentinfo.xml reads:
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE document-info ><document-info>
 <log>
  <text></text>
 </log>
...

First, the DOCTYPE has neither SYSTEM nor PUBLIC specifiers in it. I think 
this is not even well-formed XML, much less valid. I'd suggest PUBLIC 
specifiers like:
<!DOCTYPE document-info PUBLIC "-KDE//DTD document-info 1.1.1//EN"
  "http://www.kde.org/DTD/2001/koffice/document-info-1.1.1.dtd">


Then the document-info element misses namespacing. Using common tag names like 
<text> without putting them into namespaces is just like defining a global 
text() function in a c library. So there should be:
<document-info xmlns="http://www..kde.org/DTD/2001/koffice/document-info">
...
</document-info>


> In that case it's rather easy to do, please provide patch or detailed
> instructions ;)

Detailed instructions are above. ;-)

> > so registering a mimetype with IANA against a moving and undocumented (in
> > the above sense) DTD would just result in the world laughing at us, so I
> > gave up on it for the moment.
>
> "Moving" is always going to be the case.

Well, that's what the version information in the DOCTYPE is actually for, no?

> Unless someone can tell in advance which features are going to go into
> KWord for the next 15 years...

That's not neccessary. Look what W3C does with XHMTL and you know what KDE 
should do with the XML formats it defines. Just adjust the version number in 
the DOCTYPES of generated files and respect them on reading files, so you can 
be backwards-compatible without guessing. ;-) And upload the DTDs of released 
software.

> > Seeing the vast number of obsolete (since at least
> > 1996) "x-" mimetypes being added to kdelibs/mimetypes, I also get the
> > impression that the KDE project isn't interested in registering it's
> > mimetypes with IANA under e.g. the vnd.kde.* tree.
>
> Right (see my last answer on the xdg-list, BTW I think you should subscribe
> there if you're not, since mimetype stuff was recently discussed there).
> Even though vnd.*.* is what the iana recommends, everyone (and by that I
> also mean apache, gnome, etc.) still uses x-. I'm not only talking about
> the KDE mimetypes, but also about image formats, text formats etc.

Yes, and only because we are Open Source, we are allowed to ignore and break 
the standards, yes? Are we Microsoft or what? RFC 2048:

   For convenience and symmetry with this registration scheme, media
   type names with "x." as the first facet may be used for the same
   purposes for which names starting in "x-" are normally used.  These
   types are _unregistered, experimental_, and should be used only with
   the active agreement of the parties exchanging them.

   However, with the simplified registration procedures described above
   for vendor and personal trees, it should _rarely, if ever_, be
   necessary to use unregistered experimental types, and as such use of
   both "x-" and "x." forms is _discouraged_.

Getting our stuff registered with IANA is not only for the record, but also a 
sign of professionalism. Since 1996, registering mimetypes under vnd. is so 
dead easy that there is _no_ excuse to proceed with using x-. It's not about 
the x- in particular that I keep on ranting here, but simply the fact that x- 
mimetypes cannot be registered with IANA and vnd. namespaced types have the 
lowest barrier to registration (ie. they will _always_ registered in 
practice). We could also try to get application/koffice, but that needs a 
full-blown rfc being written.

> Changing
> this now, and in KDE only, would bring much trouble (user configuration,
> compat issues, etc.).

See that idea about aliases in my last post to this thread. They're needed 
anyway.

> And also, this vendor-based approach doesnt' really
> work in the opensource world. Who's going to be the "vendor" for
> application/x-dvi

vnd.knuth.dvi ;-)
But I see no problem to get this registered as app/dvi, though it needs 
someone familiar with the format to assess the security considerations.

> ? For application/x-tar?

I think IETF will have nothing against registering this as app/tar if someone 
writes a RFC about it.

> eps?

application/encapsulated-postscipt. app/postscript was registered in rfc2046 
without Adobe.

> cpio? xpm? etc. IMHO it's
> much more practical to keep using x- stuff in the opensource world, and let
> commercial people register their vendor-namespaced mimetypes. For KDE/Gnome
> specific mimetypes this argument doesn't apply, obviously, we could use
> vnd.kde.*, but for consistency everything uses x- currently.
<snip>

Not for consistency, but for saving five minutes of work (for filling out the 
IANA template) and a bit of thinking when choosing a new mimetype.

I thought the standards compliance of OSS was higher than that of proprietary 
software. :-(

Ah, CUPS is a light in the dark (see attachment).

> > E.g. KWord's mimetype should have been application/x-vnd.kde.kword+xml
> > from the moment on where it was first used, and after registration with
> > IANA and _before_ the first stable release,
> > application/vnd.kde.kword+xml. See rfc2048 and rfc3023 for more.
>
> Except that a KWord document was a tar.gz, and is very soon going to be
> a zip file. It's not a raw XML file. Are you sure the +xml applies?

It applies for the maindoc.xml file, not for the tar/zip archive, yes. The 
latter should probably simply be application/vnd.kde.koffice.

Marc

- -- 
Marc Mutz <mutz at kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8sdqw3oWD+L2/6DgRAo/nAKDF/l/AmQH9chtWFe5vS2DSikueKwCgvPUZ
ugEkuiv9PE2LYEHk/bi5WiM=
=DlIQ
-----END PGP SIGNATURE-----
-------------- next part --------------
>From web-usrn at ISI.EDU  Tue May 18 08:07:15 1999
Date: Tue, 18 May 1999 08:07:10 -0700 (PDT)
From: Michael Sweet <mike at easysw.com>
To: iana at iana.org, mike at easysw.com
Reply-To: mike at easysw.com
Sender: mike at easysw.com
Subject: Request for MIME media type Application/Vendor Tree - vnd.cups-postscript


Name : Michael Sweet

E-mail : mike at easysw.com

MIME media type name : Application

MIME subtype name : Vendor Tree - vnd.cups-postscript

Required parameters : None

Optional parameters :
None

Encoding considerations :

PostScript data of this format must consist only of characters in the
ASCII character set. 8-bit or "binary" data is not acceptable due to
the poor support over parallel and serial interfaces.  In addition,
PostScript files tagged with this format MUST conform to the Adobe
Document Structuring Conventions, Version 3.0.

Security considerations :

See RFC 2046, section 4.5.2.

Also see the encoding considerations for additional restrictions on
the accepted PostScript data.

Interoperability considerations :

Used by the Common UNIX Printing System ("CUPS").  May be used by CUPS
or Internet Printing Protocol ("IPP") clients to send printer-specific
PostScript files to a server.


Published specification :
CUPS-IDD-1.0: Common UNIX Printing System Interface Design
Description.

Available at "http://www.cups.org/documentation.html".


Applications which use this media :

Common UNIX Printing System ("CUPS") servers and clients.
Internet Printing Protocol ("IPP") clients.



Additional information :

1. Magic number(s) :
2. File extension(s) :
3. Macintosh file type code :
This format is provided primarily to tell the CUPS/IPP server that the
PostScript file contains printer-specific configuration commands and
that it conforms to the encoding considerations outlined above.

This format is required to support some types of clients running from
Microsoft Windows as well.

Person to contact for further information :

1. Name : Michael Sweet
2. E-mail : mike at easysw.com

Intended usage : Limited Use


Author/Change controller : Michael Sweet
Easy Software Products
44141 Airport View Drive Suite 204
Hollywood, Maryland 20636-3111 USA
+1.301.373.9600

-------------- next part --------------
From: mike at easysw.com [mailto:mike at easysw.com] 
Sent: Friday, June 18, 1999 11:30 AM
To: iana at iana.org; mike at easysw.com
Subject: Request for MIME media type Application/Vendor Tree - vnd.cups-raster

Name : Michael Sweet

E-mail : mike at easysw.com

MIME media type name : Application

MIME subtype name : Vendor Tree - vnd.cups-raster

Required parameters : NONE

Optional parameters : 
NONE

Encoding considerations : 
8-bit (raw) binary data.



Security considerations : 
Raster data can be very large, which could fill a filesystem and
cause a denial of service or system failure.

Raster data contains no executables or macros. Authentication and
access control are normally handled by the Internet Printing Protocol
and Hyper-Text Transport Protocol.


Interoperability considerations : 
NONE

Published specification : 
http://www.cups.org/idd.html
http://www.cups.org/idd.pdf


Applications which use this media : 
Common UNIX Printing System
ESP Print

Additional information :

1. Magic number(s) : 
2. File extension(s) : 
3. Macintosh file type code : 


Person to contact for further information :

1. Name : Michael Sweet
2. E-mail : mike at easysw.com

Intended usage : Common 
Used for printing "raw" image data in formats acceptable to printer
drivers.

Author/Change controller : Easy Software Products
44141 Airport View Drive
Suite 204
Hollywood, Maryland 20636-3111 USA
+1.301.373.9600
cups-support at cups.org