From kde-core-devel Mon Apr 08 18:00:15 2002 From: Marc Mutz Date: Mon, 08 Apr 2002 18:00:15 +0000 To: kde-core-devel Subject: Re: Mimetype names (Re: mimetypes for zipped files) X-MARC-Message: https://marc.info/?l=kde-core-devel&m=101828956908163 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--Boundary_(ID_TU5T+OPW6nuBgcaWobuGDA)" --Boundary_(ID_TU5T+OPW6nuBgcaWobuGDA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT -----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: ... 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: Then the document-info element misses namespacing. Using common tag names like without putting them into namespaces is just like defining a global text() function in a c library. So there should be: ... > 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. 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 -----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----- --Boundary_(ID_TU5T+OPW6nuBgcaWobuGDA) Content-type: text/plain; name=vnd.cups-postscript; charset=us-ascii Content-description: Complete registration of a mimtype by the CUPS team. Content-disposition: inline; filename=vnd.cups-postscript Content-transfer-encoding: 7BIT From web-usrn@ISI.EDU Tue May 18 08:07:15 1999 Date: Tue, 18 May 1999 08:07:10 -0700 (PDT) From: Michael Sweet To: iana@iana.org, mike@easysw.com Reply-To: mike@easysw.com Sender: mike@easysw.com Subject: Request for MIME media type Application/Vendor Tree - vnd.cups-postscript Name : Michael Sweet E-mail : mike@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@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 --Boundary_(ID_TU5T+OPW6nuBgcaWobuGDA) Content-type: text/plain; name=vnd.cups-raster; charset=us-ascii Content-disposition: inline; filename=vnd.cups-raster Content-transfer-encoding: 7BIT From: mike@easysw.com [mailto:mike@easysw.com] Sent: Friday, June 18, 1999 11:30 AM To: iana@iana.org; mike@easysw.com Subject: Request for MIME media type Application/Vendor Tree - vnd.cups-raster Name : Michael Sweet E-mail : mike@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@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@cups.org --Boundary_(ID_TU5T+OPW6nuBgcaWobuGDA)--