February 2004 - Ietf-types

dns media type registration tree
by Mark Baker 02 Mar '04

02 Mar '04

Hi, I wanted to express my *strong* support for the recently published draft about the "dns" media type registration tree[1]. I think this is long overdue, and I thank Mark for devising such a straightforward mechanism for decentralizing the media type assignment process (you don't want to know what I was going to propose 8-). I would like to propose one substantive change to the document though. As I see it, there are two objectives that we'd really like to achieve; a decentralized namespace, and dereferenceable identifiers (for all the reasons in [2]). Mark's draft ably addresses the former, but doesn't seem to treat the latter as an objective, although the "doc" parameter is a step in that direction. I think a fairly small tweak can give us both. What I propose is that the doc parameter be replaced by a "base" parameter whose value is a URI that is intended to permit the media type name itself to be used as a relative URI. For example, if we had the media type "text/dns.foo.example.com", with a base parameter value of "http://example.com/mtype/" then the authoritative URI for the media type would be "http://example.com/mtype/text/dns.foo.example.com" (see the discussion[3] about the relative URI approach by the W3C TAG). The document should be clear that the resultant URI is the authoritative URI for the media type. It would still be optional, though I'd like to say that we recommend that it SHOULD be used, and SHOULD be dereferenceable using currently ubiquitous technologies. Thoughts? [1] http://www.ietf.org/internet-drafts/draft-nottingham-dns-media-tree-00.txt [2] http://www.ietf.org/internet-drafts/draft-connolly-w3c-accessible-registrie… [3] http://www.w3.org/2003/12/15-tag-summary.html#uriMediaType-9 Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca

5 11

text/wiki vs dozens of text/vnd.*.wiki
by Mario Salzer 01 Mar '04

01 Mar '04

There exists an application on top of WWW, which is known as WikiWikiWeb. It enables users to contribute to sites (without blinking 'free registration' buttons) almost like TBLs original idea of the web. Currently users are presented <textareas> where to insert text in a text format enriched with (often so called) WikiMarkup (bold text, lists, links and so on). It looks much like text/plain, and in fact is. My impression of it however is, that it also would make a good hypertext format, eventually capable of replacing text/html in a few places (though there is yet no browser support). Additionally there is also the idea of a global "InterWiki" connecting the various Wiki installations - currently it's only made up of a few links between them, but there are plans to interchange pages and so on. And then there likely comes the need for yet another MIME type. The story gets a bit more complicated by the fact, that the various incarnations of Wiki implement (almost all) slightly different WikiMarkups. Convertion between them was probably possible by a gateway, but then there still was a need for correctly identifying them, which is only possible with using MIME types (because there are no integrated document type tags or such a thing). However, because there is already a large number of variants, the list of MIME types could eventually grow very long, and may get far more than a few dozens: - text/prs.cunningham.wiki - text/vnd.usemod.wiki - text/vnd.usemod.wiki; version=1.2 - text/vnd.twiki.wiki - text/vnd.moinmoin.wiki - text/vnd.oddmuse.wiki - text/vnd.phpwiki.wiki - text/vnd.jspwiki.wiki - text/prs.coma.wiki - text/vnd.mediawiki.wiki - text/vnd.sourceforge.wiki My fear is, that there likely could be around 100 of them (there are at least that many different implementations) - rendering any registration senseless then. (But, btw, I'm not sure about the "/vnd." thing here, does it really require a $$$-commercial product behind - and is it really forbidden for non-profit organizations, like the RFC suggests?) So, in an ideal world, implementors would agree on a standard, or stick with a few less. However this is currently unlikely to happen and there wasn't even one successful standardization effort in the past. If there was an I-D attempting so, it could therefore NOT document an established standard (even though most deviations look alike), it could merely describe the most widespread notation standard for say bold and italic text and the currently most widely accepted notation for lists and tables or "free links". (The only thing that is really standardized are the WikiLinks and InterWiki:Links). Now the question: Does it make any sense on attempting standardization such an text/plain-alike "hypertext format" (would become text/wiki) or should the over-registration of MIME types (which only were minor variations of each other!) just happen? Regards, mario

3 3

Registration of MIME media type application/sema
by Peter Svensson 29 Feb '04

29 Feb '04

MIME media type name: --------------------- application MIME subtype name: ------------------ sema Required parameters: -------------------- none Optional parameters: -------------------- none Encoding considerations: ------------------------ SEMA files is the result of an encryption of an email and it consists of binary data. Security considerations: ------------------------ A SEMA file is the result of an encryption of an email (including additional attachments) and some of the security issues raised when dealing with email still remains. However, SEMA files requires password(s) to open the email, it uses internal security for creation of mail and makes it possible to securely identify senders, therefore it cannot be used as means to widely spread viruses and potential dangerous data. Published specification: ------------------------ Secured eMail is a system for encrypting/decrypting email. It consists of two parts; The Secured eMail "writer" which is a pice of software which is installed on the senders computer and is used to encrypt email; and a "reader" which is installed at the recipients computer to enable decryption of the email. The first implementation of the "writer" is distributed as an add-in to Microsoft Outlook on the Win32 platform but other implementations will follow. The first implementation of the "reader" is distributed both as an Microsoft Outlook add-in and as a standalone Win32 executable for recipients who do not use Microsoft Outlook. When an email is encrypted, it is transformed into a document with encrypted binary data called a Secured eMail Archive file and this registration is intended to register this document format as a mime type. Applications which use this media type: --------------------------------------- To this date (2004-02-11): Secured eMail Outlook Add-In Secured eMail Standalone Reader Additional information: ----------------------- Magic number(s): File extension(s): .SEMA Macintosh File Type Code(s): Person & email address to contact for further information: ---------------------------------------------------------- 1. Name : Peter Svensson 2. E-mail : peter.svensson(a)securedemail.se Intended usage: --------------- Common Author/Change controller: ------------------------- Secured eMail AB, Kungsporten 4e, 427 50 Billdal, Sweden http://www.securedemail.se

4 3

ID wcbpuam... thanks
by iana＠iana.org 17 Feb '04

17 Feb '04

Yours ID fcggnx -- Thank

1 0

ID wef... thanks
by iana＠iana.org 17 Feb '04

17 Feb '04

Yours ID aotfvydyx -- Thank

1 0

ID qsonrc... thanks
by iana＠iana.org 17 Feb '04

17 Feb '04

Yours ID lejwtatjedp -- Thank

1 0

ID noh... thanks
by iana＠iana.org 17 Feb '04

17 Feb '04

Yours ID ferq -- Thank

1 0