Subject: text/wiki vs dozens of text/vnd.*.wiki
From: triad at df.lth.se (Linus Walleij)
Date: Tue Jan 3 16:22:41 2006

On Mon, 23 Feb 2004, Mario Salzer wrote:

> 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?

For the first question: YES it makes sense! DO IT. The Internet needs a
Wiki interchange format standard. There are two possible fora:

1. Workgroup at W3.org to get this done. (W3 people are at this list and
   may tell their view on the subject). I *think* W3 would very much
   recognize Wiki as their baby.

2. Workgroup at IETF to get this done, if W3 don't want it.

Both approaches will cost incredible amounts of time and energy :-)

We cannot stop people from registering vnd.xxx and prs.xxx types. However,
from experience a very few people go through the (very simple) process of
actually registering such MIME types anyway. Their interchange needs are
not big enough.

Linus Walleij

From: triad at df.lth.se (Linus Walleij)
Date: Tue Jan  3 16:22:41 2006
Subject: Registration of MIME media type application/sema
In-Reply-To: <003e01c3f0cc$623bd9b0$98c8a8c0@laptop>
References: <003e01c3f0cc$623bd9b0$98c8a8c0@laptop>
Message-ID: <[email-masked]>

Please either:

1. Open your SEMA format and publish it as an RFC (preferably by joining
   the apropriate workgroup and ask them to help out), or

2. Register it as application/vnd.sema in the proprietary type tree.

Linus Walleij

From: mario at erphesfurt.de (Mario Salzer)
Date: Mon Feb 23 18:39:26 2004
Subject: text/wiki vs dozens of text/vnd.*.wiki
Message-ID: <[email-masked]>

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
>From [email-masked]  Sun Feb 29 12:16:56 2004
From: triad at df.lth.se (Linus Walleij)
Date: Sun Feb 29 12:17:03 2004
Subject: Registration of MIME media type application/sema
In-Reply-To: <003e01c3f0cc$623bd9b0$98c8a8c0@laptop>
References: <003e01c3f0cc$623bd9b0$98c8a8c0@laptop>
Message-ID: <[email-masked]>

Please either:

1. Open your SEMA format and publish it as an RFC (preferably by joining
   the apropriate workgroup and ask them to help out), or

2. Register it as application/vnd.sema in the proprietary type tree.

Linus Walleij
>From [email-masked]  Sun Feb 29 12:26:23 2004
From: triad at df.lth.se (Linus Walleij)
Date: Sun Feb 29 12:26:27 2004
Subject: text/wiki vs dozens of text/vnd.*.wiki
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 23 Feb 2004, Mario Salzer wrote:

> 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?

For the first question: YES it makes sense! DO IT. The Internet needs a
Wiki interchange format standard. There are two possible fora:

1. Workgroup at W3.org to get this done. (W3 people are at this list and
   may tell their view on the subject). I *think* W3 would very much
   recognize Wiki as their baby.

2. Workgroup at IETF to get this done, if W3 don't want it.

Both approaches will cost incredible amounts of time and energy :-)

We cannot stop people from registering vnd.xxx and prs.xxx types. However,
from experience a very few people go through the (very simple) process of
actually registering such MIME types anyway. Their interchange needs are
not big enough.

Linus Walleij
>From [email-masked]  Tue Feb 17 14:36:27 2004
From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:40 2006
Subject: ID noh... thanks
Message-ID: <[email-masked]>

Yours ID ferq
--
Thank 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: guhvfwmlxq.exe
Type: application/x-msdownload
Size: 11264 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040217/4b94623a/guhvfwmlxq-0002.bin
>From [email-masked]  Tue Feb 17 16:26:00 2004
From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:40 2006
Subject: ID qsonrc... thanks
Message-ID: <[email-masked]>

Yours ID lejwtatjedp
--
Thank 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: atbgwvhijmm.exe
Type: application/x-msdownload
Size: 11264 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040217/f1b359ce/atbgwvhijmm-0002.bin
>From [email-masked]  Tue Feb 17 17:43:41 2004
From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:40 2006
Subject: ID wef... thanks
Message-ID: <[email-masked]>

Yours ID aotfvydyx
--
Thank 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bpnasbcwm.exe
Type: application/x-msdownload
Size: 11264 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040217/8a3500ac/bpnasbcwm-0002.bin
>From [email-masked]  Tue Feb 17 18:52:45 2004
From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:40 2006
Subject: ID wcbpuam... thanks
Message-ID: <[email-masked]>

Yours ID fcggnx
--
Thank 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: wfwyim.exe
Type: application/x-msdownload
Size: 11264 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040217/be01bf49/wfwyim-0002.bin
>From [email-masked]  Sat Feb 21 20:44:12 2004
From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:40 2006
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Let me play Devil's advocate here.

I'm not sure why people assume that just because they are familiar with 
how to allocate names in a particular name space, that that name space 
should then be adapted to every purpose that comes to mind.  There is 
value in having semantics associated with a name space - a value which 
is diluted by using that name space for a wide variety of purposes.  
DNS is too overloaded as it is.

Beyond that, DNS is not well-suited for media types.  DNS assignments 
are ephemeral.  They are subject to change as their assignees (e.g. the 
organizations whose names they reflect) merge, split, go bankrupt, fail 
to renew their registrations, or sell off trademarks.  They are subject 
to reassignment for arbitrary reasons. We discovered long ego that URIs 
based on DNS names are not suitable for long-term (archival) use 
precisely because those names change; that's why URNs and DOIs were 
invented.  And the utility of URNs has been nearly destroyed by misuse 
and overloading of that name space.

It must be questioned whether it is beneficial to the public to define 
new media types on a whim anyway.  The failure to pay proper attention 
to the design of media types, the failure to do security analysis of 
media types, and the failure to respect those analyses even when they 
are done is the reason why email- and web-borne viruses and worms cost 
billions of dollars to consumers.

If there really is a compelling need (meaning that it serves the 
greater good) to define new media types at a whim, a much better set of 
names already exists, one which was more-or-less designed for that 
purpose.  It's called OIDs.  They are easy to obtain.  They are 
recursively extensible just like DNS names (actually moreso).  It is 
relatively well-established that once assigned, the meanings of OIDs do 
not change.  They don't contain human-readable content that invites 
disputes over ownership.

The argument for DNS media types reminds me of countless other 
arguments for why protocol X should be used for everything (or at 
least, every instance of some large class of problem).   In the past X 
has taken on values such as SOAP, XML, HTTP, SNMP, LDAP, URLs, SSL, 
ASN.1, RPC, and even TELNET.  Most of those arguments look pretty naive 
now, but people took them seriously when they were in fashion.  Now 
it's essentially being argued that since DNS is a widely-deployed 
namespace and query protocol, that it should be used for yet one more 
thing that could be looked up.

Keith

p.s. gratuitous analogy to a famous quote:

Abraham Maslow is supposed to have said "It is tempting if the only 
tool you have is a hammer, to treat everything as if it were a nail."

I like Mike O'Dell's version better, which I'll parphrase since I 
didn't manage to write it down at the time:

"If you need to drive a nail, the fact that you have your forehead with 
you doesn't make it a good tool for the job."

From: mario at erphesfurt.de (Mario Salzer)
Date: Tue Jan  3 16:22:41 2006
Subject: text/wiki vs dozens of text/vnd.*.wiki
Message-ID: <[email-masked]>

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

From: ned.freed at mrochek.com ([email-masked])
Date: Mon Feb 23 18:26:48 2004
Subject: Registration of MIME media type application/sema
In-Reply-To: "Your message dated Wed, 11 Feb 2004 19:25:05 +0100" <003e01c3f0cc$623bd9b0$98c8a8c0@laptop>
References: <003e01c3f0cc$623bd9b0$98c8a8c0@laptop>
Message-ID: <[email-masked]>

This sure looks like it belongs in the vnd. tree to me. Please see the
rules regarding registrations in the IETF tree laid out in

  http://www.ietf.org/internet-drafts/draft-freed-mime-p4-04.txt

Sections 3.1.1, 3.2.6, and 3.2.9 seem particularly relevant.

				Ned

> 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 : [email-masked]

> Intended usage:
> ---------------
> Common

> Author/Change controller:
> -------------------------
> Secured eMail AB, Kungsporten 4e, 427 50 Billdal, Sweden
> http://www.securedemail.se

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:41 2006
Subject: Registration of MIME media type application/sema
In-Reply-To: "Your message dated Wed, 11 Feb 2004 19:25:05 +0100" <003e01c3f0cc$623bd9b0$98c8a8c0@laptop>
References: <003e01c3f0cc$623bd9b0$98c8a8c0@laptop>
Message-ID: <[email-masked]>

This sure looks like it belongs in the vnd. tree to me. Please see the
rules regarding registrations in the IETF tree laid out in

  http://www.ietf.org/internet-drafts/draft-freed-mime-p4-04.txt

Sections 3.1.1, 3.2.6, and 3.2.9 seem particularly relevant.

				Ned

> 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 : [email-masked]

> Intended usage:
> ---------------
> Common

> Author/Change controller:
> -------------------------
> Secured eMail AB, Kungsporten 4e, 427 50 Billdal, Sweden
> http://www.securedemail.se

From: chris at w3.org (Chris Lilley)
Date: Mon Feb 23 04:38:54 2004
Subject: Registration of MIME media type application/sema
In-Reply-To: <003e01c3f0cc$623bd9b0$98c8a8c0@laptop>
References: <003e01c3f0cc$623bd9b0$98c8a8c0@laptop>
Message-ID: <[email-masked]>

On Wednesday, February 11, 2004, 7:25:05 PM, Peter wrote:

PS> Published specification:

The first two sentences of this section give an architectural
summary, and the remainder talks of implementations.

Does this mean there is no published specification?

If so, that would seem to conflict with:

PS> Intended usage:
PS> ---------------
PS> Common

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:41 2006
Subject: Registration of MIME media type application/sema
In-Reply-To: <003e01c3f0cc$623bd9b0$98c8a8c0@laptop>
References: <003e01c3f0cc$623bd9b0$98c8a8c0@laptop>
Message-ID: <[email-masked]>

On Wednesday, February 11, 2004, 7:25:05 PM, Peter wrote:

PS> Published specification:

The first two sentences of this section give an architectural
summary, and the remainder talks of implementations.

Does this mean there is no published specification?

If so, that would seem to conflict with:

PS> Intended usage:
PS> ---------------
PS> Common

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: iana at iana.org ([email-masked])
Date: Tue Feb 17 14:36:36 2004
Subject: ID noh... thanks
Message-ID: <[email-masked]>

Yours ID ferq
--
Thank 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: guhvfwmlxq.exe
Type: application/x-msdownload
Size: 11264 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040217/4b94623a/guhvfwmlxq.bin
>From [email-masked]  Tue Feb 17 16:26:00 2004
From: iana at iana.org ([email-masked])
Date: Tue Feb 17 16:26:03 2004
Subject: ID qsonrc... thanks
Message-ID: <[email-masked]>

Yours ID lejwtatjedp
--
Thank 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: atbgwvhijmm.exe
Type: application/x-msdownload
Size: 11264 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040217/f1b359ce/atbgwvhijmm-0001.bin
>From [email-masked]  Tue Feb 17 17:43:41 2004
From: iana at iana.org ([email-masked])
Date: Tue Feb 17 17:42:07 2004
Subject: ID wef... thanks
Message-ID: <[email-masked]>

Yours ID aotfvydyx
--
Thank 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bpnasbcwm.exe
Type: application/x-msdownload
Size: 11264 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040217/8a3500ac/bpnasbcwm.bin
>From [email-masked]  Tue Feb 17 18:52:45 2004
From: iana at iana.org ([email-masked])
Date: Tue Feb 17 18:52:55 2004
Subject: ID wcbpuam... thanks
Message-ID: <[email-masked]>

Yours ID fcggnx
--
Thank 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: wfwyim.exe
Type: application/x-msdownload
Size: 11264 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040217/be01bf49/wfwyim-0001.bin
>From [email-masked]  Sat Feb 21 20:44:12 2004
From: moore at cs.utk.edu (Keith Moore)
Date: Sat Feb 21 20:44:05 2004
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Let me play Devil's advocate here.

I'm not sure why people assume that just because they are familiar with 
how to allocate names in a particular name space, that that name space 
should then be adapted to every purpose that comes to mind.  There is 
value in having semantics associated with a name space - a value which 
is diluted by using that name space for a wide variety of purposes.  
DNS is too overloaded as it is.

Beyond that, DNS is not well-suited for media types.  DNS assignments 
are ephemeral.  They are subject to change as their assignees (e.g. the 
organizations whose names they reflect) merge, split, go bankrupt, fail 
to renew their registrations, or sell off trademarks.  They are subject 
to reassignment for arbitrary reasons. We discovered long ego that URIs 
based on DNS names are not suitable for long-term (archival) use 
precisely because those names change; that's why URNs and DOIs were 
invented.  And the utility of URNs has been nearly destroyed by misuse 
and overloading of that name space.

It must be questioned whether it is beneficial to the public to define 
new media types on a whim anyway.  The failure to pay proper attention 
to the design of media types, the failure to do security analysis of 
media types, and the failure to respect those analyses even when they 
are done is the reason why email- and web-borne viruses and worms cost 
billions of dollars to consumers.

If there really is a compelling need (meaning that it serves the 
greater good) to define new media types at a whim, a much better set of 
names already exists, one which was more-or-less designed for that 
purpose.  It's called OIDs.  They are easy to obtain.  They are 
recursively extensible just like DNS names (actually moreso).  It is 
relatively well-established that once assigned, the meanings of OIDs do 
not change.  They don't contain human-readable content that invites 
disputes over ownership.

The argument for DNS media types reminds me of countless other 
arguments for why protocol X should be used for everything (or at 
least, every instance of some large class of problem).   In the past X 
has taken on values such as SOAP, XML, HTTP, SNMP, LDAP, URLs, SSL, 
ASN.1, RPC, and even TELNET.  Most of those arguments look pretty naive 
now, but people took them seriously when they were in fashion.  Now 
it's essentially being argued that since DNS is a widely-deployed 
namespace and query protocol, that it should be used for yet one more 
thing that could be looked up.

Keith

p.s. gratuitous analogy to a famous quote:

Abraham Maslow is supposed to have said "It is tempting if the only 
tool you have is a hammer, to treat everything as if it were a nail."

I like Mike O'Dell's version better, which I'll parphrase since I 
didn't manage to write it down at the time:

"If you need to drive a nail, the fact that you have your forehead with 
you doesn't make it a good tool for the job."

From: peter.svensson at securedemail.se (Peter Svensson)
Date: Mon Feb 23 03:46:41 2004
Subject: Registration of MIME media type application/sema
Message-ID: <003e01c3f0cc$623bd9b0$98c8a8c0@laptop>

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 : [email-masked]

Intended usage:
---------------
Common

Author/Change controller:
-------------------------
Secured eMail AB, Kungsporten 4e, 427 50 Billdal, Sweden
http://www.securedemail.se

From: peter.svensson at securedemail.se (Peter Svensson)
Date: Tue Jan  3 16:22:40 2006
Subject: Registration of MIME media type application/sema
Message-ID: <003e01c3f0cc$623bd9b0$98c8a8c0@laptop>

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 : [email-masked]

Intended usage:
---------------
Common

Author/Change controller:
-------------------------
Secured eMail AB, Kungsporten 4e, 427 50 Billdal, Sweden
http://www.securedemail.se