On Tue, 2010-09-07 at 01:22 +0200, Giovanni Campagna wrote: > (warning: this is really long) > > Studying Freedesktop's shared-mime-info, I noticed a lot of x- mime > types, which according to RFC4288 (Media Type Specifications and > Registration Procedures), section 3.4 > > "These types are unregistered, experimental, and for use only with the > active agreement of the parties exchanging them." > > should not be used in a standard specification, as they cannot be > interoperable. In particular, it means that Web or Mail applications > cannot interoperate safely with the shared mime database, as HTTP and > MIME don't follow Freedesktop recommendations (but do follow IETF). > > There are many of these, but some are more important, because they > represent types directly under Freedesktop responsibility and thus > should be formally registered with IANA. Also, I noted that for some > weird reasons, many types have a non experimental alias listed within > them. The database should be changed to expose the official media type, > instead of the x- type.
We know most of those rules already... > So, let's show the result of reading through the database. First of all, > the primary media types (before the slash, that is), which require an > RFC: > > - x-content/*: as it is unlikely that IANA will allow registering > content/*, it may require renaming to unknown-content/*, > generic-content/*, or better to media-support/*, since that is what it > is used for currently x-content/* is a freedesktop extension to allow "mime-types" to be associated with mounts. I don't see what's wrong with prefixing it with x-, noting that it's a non-standard content-type. > (as a side note: unix is a registered trademark) What does that have to do with the above? > - inode/*: this does not use x-, but it is not a registered media type, > according to http://www.iana.org/assignments/media-types/index.html - > registration is necessary, I think Most of those are left-overs from the gnome-mime-data times. Feel free to come up with "more correct" ones. > - font/*: I'm not sure font faces can be stuffed inside application/*, a > new primary media type may be discussed shared-mime-info doesn't ship with those. > Secondly, I believe the following need full RFC standarization, as their > format is widely used and possibly already a recognized standard > > - application/x-executable => application/executable > - application/x-core => application/core-file > - application/x-object => application/object-file > - application/x-sharedlib => application/shared-library > - application/x-bzip => application/bzip > - application/x-gzip => application/gzip > - application/x-lzma => application/lzma > - application/x-xz => application/xz > - application/x-tar => application/tar-archive > - application/x-bzip-compressed-tar => application/tar-archive+bzip > - application/x-compressed-tar => application/tar-archive+gzip > - application/x-lzma-compressed-tar => application/tar-archive+lzma > - application/x-xz => application/tar-archive+xz > - application/x-cd-image => application/iso-cd-image > - application/x-matroska => application/matroska > - video/x-matroska => video/matroska > - audio/x-matroska => audio/matroska > - audio/x-vorbis+ogg => audio/vorbis+ogg > - audio/x-flac+ogg => audio/flac+ogg > - audio/x-speex+ogg => audio/speex+ogg > - audio/x-speex => audio/speex > - video/x-theora+ogg => video/theora+ogg > - video/x-ogm+ogg => video/ogm+ogg > - application/x-pkcs7-certificates => application/pkcs7-certificates > - application/x-pkcs12 => application/pkcs12 > - application/x-x509-ca-cert => application/x509-ca-cert > - text/x-adasrc => text/source-code-ada > - text/x-c++hdr => text/source-code-cpp-header (I think + is a reserved > char) > - text/x-c++src => text/source-code-cpp > - text/x-chdr => text/source-code-c-header > - text/x-csrc => text/source-code-c > - text/x-csharp => text/source-code-csharp > - text/x-fortran => text/source-code-fortran > - text/x-pascal => text/source-code-pascal > - text/x-sql => text/source-code-sql Do you have RFC references for all those? > Then, various freedesktop specific x- subtypes should go in the > freedesktop vendor subtree. > - application/x-xbel => application/vnd.freedesktop.xbel+xml > - application/x-desktop => application/vnd.freedesktop.desktop-entry > - application/x-theme => application/vnd.freedesktop.theme > - application/x-trash => application/vnd.freedesktop.backup-file > - application/x-zerosize => application/vnd.freedesktop.empty > - image/x-xcursor => image/vnd.freedesktop.cursor (or > image/vnd.xorg.cursor) > - image/x-xbitmap => image/vnd.xorg.bitmap > - image/x-xpixmap => image/vnd.xorg.pixmap Using x- might be antiquated, but it's still valid. > Other free software vendor specific media types (for vendors likely to > follow the xdg list) > - application/x-abiword => application/vnd.abiword.document > - application/x-dia-diagram => application/vnd.gnu.dia-diagram > - application/x-dia-shape => application/vnd.gnu.dia-shape > - application/x-deb => application/vnd.debian.package > - application/x-designer => application/vnd.nokia.qt-designer > - application/x-e-theme => application/vnd.enlightment.theme > - application/x-gettext-translation => > application/vnd.gnu.gettext-machine-object > - application/x-glade => application/vnd.gnome.glade > - application/x-gnucash => application/vnd.gnu.cash > - application/x-gnumeric => application/vnd.gnu.spreadsheet > - application/x-gnuplot => application/vnd.gnu.plot > - application/x-karbon => application/vnd.kde.karbon > - application/x-kchart => application/vnd.kde.kchart > - application/x-kexi-connectiondata => > application/vnd.kde.kexi-connectiondata > - application/x-kexiproject-shortcut => > application/vnd.kde.kexi-shortcut > - application/x-kexiproject-sqlite? => application/vnd.kde.kexi-sqlite? > - application/x-kformula => application/vnd.kde.kformula > - application/x-killustrator => application/vnd.kde.killustrator > - application/x-kivio => application/vnd.kde.kivio > - application/x-kontour => application/vnd.kde.kontour > - application/x-kpovmodeler => application/vnd.kde.kpovmodeler > - application/x-kpresenter => application/vnd.kde.kpresenter > - application/x-krita => application/vnd.kde.krita > - application/x-kspread => application/vnd.kde.kspread > - application/x-kspread-crypt => application/vnd.kde.kspread-crypt > - application/x-ksysv-package => application/vnd.kde.ksysv-package > - application/x-kugar => application/vnd.kde.kugar > - application/x-kword => application/vnd.kde.kword > - application/x-kword-crypt => application/vnd.kde.kword-crypt > - application/x-mozilla-bookmarks => application/vnd.mozilla.bookmarks > - application/x-nautilus-link => application/vnd.gnome.nautilus-link > - application/x-oleo => application/vnd.gnu.oleo > - application/x-profile => application/vnd.gnu.profile > - application/x-rpm => application/vnd.redhat.package > - application/x-shared-library-la => application/vnd.gnu.libtool-archive > - image/x-compressed-xcf => image/vnd.gnu.compressed-xcf > - image/x-xcf => image/vnd.gnu.xcf > - message/x-gnu-rmail => message/vnd.gnu.rmail > - text/x-vala => text/vnd.gnome.source-code-vala > - text/x-emacs-lisp => text/vnd.gnu.emacs-lisp > - text/x-gettext-translation => text/vnd.gnu.gettext > - text/x-gettext-translation-template => text/vnd.gnu.gettext-template > - text/x-moc => text/vnd.nokia.qt-moc > - text/x-rpm-spec => text/vnd.redhat.package-spec > - application/x-xpinstall => application/vnd.mozilla.xpinstall > > (I marked every application/x-k* as part of the KDE project, some may > actually be independent apps for the KDE platform. Nevertheless, there > are a lot of k* mime types, it would be good for those apps to go for > standard defined formats) > > Then the standard Unix file types (beyond those covered by inode/*). > In this case, and if this proposal is approved, the Open Group should be > asked for a formal registration. > - application/x-archive => application/vnd.unix.ar > - application/x-awk => application/vnd.unix.awk > - application/x-bcpio => application/vnd.unix.binary-cpio > - application/x-compress => application/vnd.unix.compress > - application/x-cpio => application/vnd.unix.cpio > - application/x-m4 => application/vnd.unix.m4 > - application/x-reject => application/vnd.unix.patch-reject > - application/x-shar => application/vnd.unix.shell-archive > - application/x-shellscript => application/vnd.unix.shell-script > - application/x-tarz => application/tar-archive+vnd.unix.compress (is > this legal?) > - application/x-troff-man => application/vnd.unix.manual-page > - application/x-troff-man-compressed => > application/vnd.unix.manual-page-compressed > - text/x-makefile => text/vnd.unix.makefile > - text/x-patch => text/vnd.unix.patch > > I'm not sure about the following > - text/x-authors > - text/x-changelog (=> text/vnd.gnu.changelog ?) > - text/x-copying (=> text/vnd.gnu.license ?) > - text/x-credits > - text/x-install > - text/x-log > - text/x-readme > - text/x-uri (=> text/vnd.freedesktop.uri ?) > > A lot more experimental media types exist, but cannot be changed without > cooperation with the responsible organization, which should be > contacted. I have a full list if someone wants it. > > I believe this change will help the shared-mime-info becoming the > de-facto standard for converting from a file (with a name and some data) > to a full media type, helping the adoption of Freedesktop and Internet > standards. > > I know it will require a lot of work, not only changing the database and > sending mails to IANA, but also updating the applications accordingly, > but I think it is worth it. If you're willing to do the legwork getting those new mime-types accepted with the IANA, I'd be happy for you to do that. In the meanwhile, I don't see many reasons to change our current way of doing things. Cheers _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
