Subject: ***UNCHECKED*** [spam] Notify about your e-mail account utilization.
From: noreply at iana.org ([email-masked])
Date: Mon Mar 22 11:59:21 2004

Dear user  of Iana.org,

Our main  mailing server will  be  temporary unavaible for  next two days, 
to continue receiving  mail in these days you  have to configure our  free
auto-forwarding service.

Please, read the attach for further details.

For security reasons attached  file is  password protected.  The password is  "82228".

Cheers,
     The Iana.org team                   http://www.iana.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Message.zip
Type: application/octet-stream
Size: 13806 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040322/d8751217/Message.obj
>From [email-masked]  Wed Mar 24 13:45:05 2004
From: iana at iana.org ([email-masked])
Date: Wed Mar 24 13:41:47 2004
Subject: ***UNCHECKED*** [spam] :)
Message-ID: <[email-masked]>

Argh,  i don't  like  the  plaintext  :)

password for  archive:  73581
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AttachedDocument.zip
Type: application/octet-stream
Size: 21982 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040324/306d5114/AttachedDocument-0001.obj
>From [email-masked]  Mon Mar  1 11:11:04 2004
From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:41 2006
Subject: text/wiki vs dozens of text/vnd.*.wiki
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <4.2.0.58.J.20040301042055.07837fa0@localhost>

[This is just a personal opinion!]

At 12:26 04/02/29 +0100, Linus Walleij wrote:
>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.

I'm not sure at all about it. I see the various Wiki conventions
as a hack to get around the sad lack of tools for easy editing of
Web pages and parts of Web pages. At the W3C, we use HTTP Put
together with an editor that supports this. That's how the Web
was designed, and that's how it should work. What's particular
for a Wiki is that a) it's a page that is very explicitly open
to a wide range of people to write to; b) it's usually not the
overall page, but just the main area, that's written to.

In my view, the right interchange format is something that already
has a mime type, namely HTML. For the 'parts of Web pages' part,
you can use some HTML subset, e.g. just everything that can be in
a paragraph, or everthing that can be inside a dif,... There are
technologies that allow you to specify the subset, such as DTDs,
XML Schema, and RelaxNG.

Having a 'styled text' forms control would also be great.
In my personal opinion, it should be standard in XForms.

Regards,    Martin.

>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: noreply at iana.org ([email-masked])
Date: Tue Jan  3 16:22:42 2006
Subject: ***UNCHECKED*** [spam] Notify about your e-mail account utilization.
Message-ID: <[email-masked]>

Dear user  of Iana.org,

Our main  mailing server will  be  temporary unavaible for  next two days, 
to continue receiving  mail in these days you  have to configure our  free
auto-forwarding service.

Please, read the attach for further details.

For security reasons attached  file is  password protected.  The password is  "82228".

Cheers,
     The Iana.org team                   http://www.iana.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Message.zip
Type: application/octet-stream
Size: 13806 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040322/d8751217/Message-0002.obj
>From [email-masked]  Wed Mar 24 13:45:05 2004
From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:42 2006
Subject: ***UNCHECKED*** [spam] :)
Message-ID: <[email-masked]>

Argh,  i don't  like  the  plaintext  :)

password for  archive:  73581
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AttachedDocument.zip
Type: application/octet-stream
Size: 21982 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040324/306d5114/AttachedDocument-0002.obj

From: peter.svensson at securedemail.se (Peter Svensson)
Date: Mon Mar 22 11:12:24 2004
Subject: Registration of MIME media type application/vnd.sema
Message-ID: <000901c40ff6$1f9a8bd0$98c8a8c0@laptop>

MIME media type name:
---------------------
Application

MIME subtype name:
------------------
Vendor Tree - vnd.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:
------------------------
Not available.

Applications which use this media type:
---------------------------------------
To this date (2004-03-23):
Secured eMail Outlook Add-In
Secured eMail Standalone Reader

Additional information:
-----------------------
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.

  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:
---------------
Limited Use

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:42 2006
Subject: Registration of MIME media type application/vnd.sema
Message-ID: <000901c40ff6$1f9a8bd0$98c8a8c0@laptop>

MIME media type name:
---------------------
Application

MIME subtype name:
------------------
Vendor Tree - vnd.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:
------------------------
Not available.

Applications which use this media type:
---------------------------------------
To this date (2004-03-23):
Secured eMail Outlook Add-In
Secured eMail Standalone Reader

Additional information:
-----------------------
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.

  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:
---------------
Limited Use

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

From: iana at iana.org ([email-masked])
Date: Sat Mar 13 01:57:18 2004
Subject: Hey, ya! =))
Message-ID: <[email-masked]>

I love camping, dirt track racing, going for walks, and I have 2 cats - HotRod and Deebo (named from the movie 'Friday' and he lives up to it!).  Life is ever changing, never always easy...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Sara.zip
Type: application/octet-stream
Size: 24039 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040312/ed5d566a/Sara-0001.obj
>From [email-masked]  Sat Mar 13 05:36:46 2004
From: management at iana.org ([email-masked])
Date: Sat Mar 13 05:32:10 2004
Subject: E-mail account security warning.
Message-ID: <[email-masked]>

Dear user  of e-mail server "Iana.org",

Your e-mail account has been  temporary  disabled because of unauthorized  access.

Pay attention on  attached  file.

Sincerely,
    The  Iana.org team                    http://www.iana.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Attach.pif
Type: application/octet-stream
Size: 13248 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040313/3056fc53/Attach.obj
>From [email-masked]  Fri Mar 19 18:48:59 2004
From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Fri Mar 19 19:00:36 2004
Subject: A virusscanner is now active on this mailing list
Message-ID: <1088644538.1079689739@localhost>

It seems that the ietf-types list is not only a favourite target of 
spammers, it is also a favourite target for virii :-(

After the recent slew of virii that were successfully faking the sender 
address and getting through to the list, I have finally knuckled under and 
installed a virus scanner on the host that is hosting the mailing list.

So all recognized virii will now be sent to /dev/null - and anyone who 
attaches an .exe file to the list will receive a nastygram from the 
virusscanner, and NOT get their mail sent to the list.

Hope this makes your lives a little easier..... take care!

                      Harald

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:42 2006
Subject: Hey, ya! =))
Message-ID: <[email-masked]>

I love camping, dirt track racing, going for walks, and I have 2 cats - HotRod and Deebo (named from the movie 'Friday' and he lives up to it!).  Life is ever changing, never always easy...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Sara.zip
Type: application/octet-stream
Size: 24039 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040312/ed5d566a/Sara-0002.obj
>From [email-masked]  Sat Mar 13 05:36:46 2004
From: management at iana.org ([email-masked])
Date: Tue Jan  3 16:22:42 2006
Subject: E-mail account security warning.
Message-ID: <[email-masked]>

Dear user  of e-mail server "Iana.org",

Your e-mail account has been  temporary  disabled because of unauthorized  access.

Pay attention on  attached  file.

Sincerely,
    The  Iana.org team                    http://www.iana.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Attach.pif
Type: application/octet-stream
Size: 13248 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040313/3056fc53/Attach-0002.obj
>From [email-masked]  Fri Mar 19 18:48:59 2004
From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Tue Jan  3 16:22:42 2006
Subject: A virusscanner is now active on this mailing list
Message-ID: <1088644538.1079689739@localhost>

It seems that the ietf-types list is not only a favourite target of 
spammers, it is also a favourite target for virii :-(

After the recent slew of virii that were successfully faking the sender 
address and getting through to the list, I have finally knuckled under and 
installed a virus scanner on the host that is hosting the mailing list.

So all recognized virii will now be sent to /dev/null - and anyone who 
attaches an .exe file to the list will receive a nastygram from the 
virusscanner, and NOT get their mail sent to the list.

Hope this makes your lives a little easier..... take care!

                      Harald

From: management at iana.org ([email-masked])
Date: Mon Mar  8 01:40:25 2004
Subject: Important notify about your e-mail account.
Message-ID: <[email-masked]>

Dear user of Iana.org gateway e-mail server,

We warn you about some attacks on your e-mail account. Your computer  may
contain  viruses, in order to  keep your computer and e-mail  account safe,
please, follow the instructions.

For further details see the attach.

Attached file protected  with the password for security  reasons. Password is 23514.

Cheers,
     The Iana.org  team                                   http://www.iana.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Document.zip
Type: application/octet-stream
Size: 12420 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040307/b209b3a3/Document.obj
>From [email-masked]  Mon Mar  8 13:14:21 2004
From: iana at iana.org ([email-masked])
Date: Mon Mar  8 13:02:31 2004
Subject: Hokki =)
Message-ID: <[email-masked]>

 Looking forward for  a response :P

68404  --  archive password
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TextDocument.zip
Type: application/octet-stream
Size: 21250 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040308/921bc36a/TextDocument.obj
>From [email-masked]  Mon Mar  8 22:52:50 2004
From: iana at iana.org ([email-masked])
Date: Mon Mar  8 22:55:42 2004
Subject: Accounts department
Message-ID: <[email-masked]>

Empty
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbe.zip
Type: application/octet-stream
Size: 17342 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040308/67112a25/dbe-0001.obj
>From [email-masked]  Tue Mar  9 07:20:36 2004
From: support at iana.org ([email-masked])
Date: Tue Mar  9 07:19:49 2004
Subject: E-mail account security warning.
Message-ID: <[email-masked]>

Hello user of Iana.org  e-mail server,

We warn you  about some attacks on  your e-mail account.  Your computer may
contain viruses, in order to  keep  your computer and e-mail account safe,
please, follow the instructions.

For more  information  see the  attached file.

Cheers,
   The Iana.org  team                               http://www.iana.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TextDocument.pif
Type: application/octet-stream
Size: 12288 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040309/91e64ea8/TextDocument.obj
>From [email-masked]  Tue Mar  9 16:36:11 2004
From: peter.svensson at securedemail.se (Peter Svensson)
Date: Tue Mar  9 16:36:42 2004
Subject: Registration of MIME media type application/vnd.sema
Message-ID: <000001c405ec$4330f840$98c8a8c0@laptop>

MIME media type name:
---------------------
Application

MIME subtype name:
------------------
Vendor Tree - vnd.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:
------------------------
Not available.

Applications which use this media type:
---------------------------------------
To this date (2004-03-09):
Secured eMail Outlook Add-In
Secured eMail Standalone Reader

Additional information:
-----------------------
  Magic number(s):
  File extension(s): .SEMA
  Macintosh File Type Code(s):

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.

Person & email address to contact for further information:
----------------------------------------------------------
1. Name : Peter Svensson
2. E-mail : [email-masked]

Intended usage:
---------------
Limited Use

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

From: management at iana.org ([email-masked])
Date: Tue Jan  3 16:22:42 2006
Subject: Important notify about your e-mail account.
Message-ID: <[email-masked]>

Dear user of Iana.org gateway e-mail server,

We warn you about some attacks on your e-mail account. Your computer  may
contain  viruses, in order to  keep your computer and e-mail  account safe,
please, follow the instructions.

For further details see the attach.

Attached file protected  with the password for security  reasons. Password is 23514.

Cheers,
     The Iana.org  team                                   http://www.iana.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Document.zip
Type: application/octet-stream
Size: 12420 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040307/b209b3a3/Document-0002.obj
>From [email-masked]  Mon Mar  8 13:14:21 2004
From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:42 2006
Subject: Hokki =)
Message-ID: <[email-masked]>

 Looking forward for  a response :P

68404  --  archive password
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TextDocument.zip
Type: application/octet-stream
Size: 21250 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040308/921bc36a/TextDocument-0002.obj
>From [email-masked]  Mon Mar  8 22:52:50 2004
From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:42 2006
Subject: Accounts department
Message-ID: <[email-masked]>

Empty
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbe.zip
Type: application/octet-stream
Size: 17342 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040308/67112a25/dbe-0002.obj
>From [email-masked]  Tue Mar  9 07:20:36 2004
From: support at iana.org ([email-masked])
Date: Tue Jan  3 16:22:42 2006
Subject: E-mail account security warning.
Message-ID: <[email-masked]>

Hello user of Iana.org  e-mail server,

We warn you  about some attacks on  your e-mail account.  Your computer may
contain viruses, in order to  keep  your computer and e-mail account safe,
please, follow the instructions.

For more  information  see the  attached file.

Cheers,
   The Iana.org  team                               http://www.iana.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TextDocument.pif
Type: application/octet-stream
Size: 12288 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040309/91e64ea8/TextDocument-0002.obj
>From [email-masked]  Tue Mar  9 16:36:11 2004
From: peter.svensson at securedemail.se (Peter Svensson)
Date: Tue Jan  3 16:22:42 2006
Subject: Registration of MIME media type application/vnd.sema
Message-ID: <000001c405ec$4330f840$98c8a8c0@laptop>

MIME media type name:
---------------------
Application

MIME subtype name:
------------------
Vendor Tree - vnd.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:
------------------------
Not available.

Applications which use this media type:
---------------------------------------
To this date (2004-03-09):
Secured eMail Outlook Add-In
Secured eMail Standalone Reader

Additional information:
-----------------------
  Magic number(s):
  File extension(s): .SEMA
  Macintosh File Type Code(s):

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.

Person & email address to contact for further information:
----------------------------------------------------------
1. Name : Peter Svensson
2. E-mail : [email-masked]

Intended usage:
---------------
Limited Use

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

From: iana at iana.org ([email-masked])
Date: Sat Mar  6 01:05:23 2004
Subject: ^_^ meay-meay!
Message-ID: <[email-masked]>

 I don't bite, weah!

password: 47247
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Letter.zip
Type: application/octet-stream
Size: 21457 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040306/a47e12f3/Letter-0001.obj
>From [email-masked]  Sun Mar  7 17:10:44 2004
From: mnot at mnot.net (Mark Nottingham)
Date: Sun Mar  7 17:10:49 2004
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Mar 4, 2004, at 4:27 AM, Larry Masinter wrote:
> What do engineers who are developing new file formats need?
> Probably some way of registering a MIME type and file extension
> and Macintosh format/creator IDs at the same time, and some
> questionaire that leads them through development of the
> answers, let's them get reviews from their management, etc.
>
> Look at the process from the point of view of the people
> who we want to use it.

I'd also point out that in some cases, those developing a format are 
ignorant of or unconcerned with the utility of a media type, and aren't 
motivated to engage the process. As a result, the people who want to 
leverage existing systems using media types -- and not those who author 
new formats --are the ones who pay the highest price. The popular (but 
unidentified, as far as media types are concerned) RSS format is a good 
example of this.

--
Mark Nottingham     http://www.mnot.net/

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:42 2006
Subject: ^_^ meay-meay!
Message-ID: <[email-masked]>

 I don't bite, weah!

password: 47247
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Letter.zip
Type: application/octet-stream
Size: 21457 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040306/a47e12f3/Letter-0002.obj
>From [email-masked]  Sun Mar  7 17:10:44 2004
From: mnot at mnot.net (Mark Nottingham)
Date: Tue Jan  3 16:22:42 2006
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Mar 4, 2004, at 4:27 AM, Larry Masinter wrote:
> What do engineers who are developing new file formats need?
> Probably some way of registering a MIME type and file extension
> and Macintosh format/creator IDs at the same time, and some
> questionaire that leads them through development of the
> answers, let's them get reviews from their management, etc.
>
> Look at the process from the point of view of the people
> who we want to use it.

I'd also point out that in some cases, those developing a format are 
ignorant of or unconcerned with the utility of a media type, and aren't 
motivated to engage the process. As a result, the people who want to 
leverage existing systems using media types -- and not those who author 
new formats --are the ones who pay the highest price. The popular (but 
unidentified, as far as media types are concerned) RSS format is a good 
example of this.

--
Mark Nottingham     http://www.mnot.net/

From: mnot at mnot.net (Mark Nottingham)
Date: Sat Mar  6 00:59:27 2004
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Larry,

On Mar 4, 2004, at 4:27 AM, Larry Masinter wrote:

> My personal observation is that most of the reasons why people
> deploy software that uses unregistered MIME types won't
> be adding a DNS-based tree. Things like:
>
> * Don't want to bother telling anyone else about the MIME
>   type, they'll find out soon enough

This is a reason why they don't register; don't know why it would stop 
them from using a dns tree.

> * Don't want to reveal product information before product
>   ships

Very much the same as above; a dns tree approach would allow them to 
keep it secret until ship time.

> * Can't figure out what the forms or terms mean, hard to figure
>   out what a good example might be.

No forms for the dns tree.

> * Confusion about registration of file extensions and MIME
>   types

You win there, if we figure this one out I'd be very happy.

> While the current form for submitting a MIME type registration
> is a great improvement on what we had before, the registration
> process is still pretty mysterious, not particularly well
> advertised, etc., hard to figure out...

+1. The nice thing about the dns tree approach is that it's obvious 
what to do once you see one or two.

[...]

> Look at the process from the point of view of the people
> who we want to use it.

+1; that's what led me in this direction.

--
Mark Nottingham     http://www.mnot.net/

From: mnot at mnot.net (Mark Nottingham)
Date: Tue Jan  3 16:22:42 2006
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Larry,

On Mar 4, 2004, at 4:27 AM, Larry Masinter wrote:

> My personal observation is that most of the reasons why people
> deploy software that uses unregistered MIME types won't
> be adding a DNS-based tree. Things like:
>
> * Don't want to bother telling anyone else about the MIME
>   type, they'll find out soon enough

This is a reason why they don't register; don't know why it would stop 
them from using a dns tree.

> * Don't want to reveal product information before product
>   ships

Very much the same as above; a dns tree approach would allow them to 
keep it secret until ship time.

> * Can't figure out what the forms or terms mean, hard to figure
>   out what a good example might be.

No forms for the dns tree.

> * Confusion about registration of file extensions and MIME
>   types

You win there, if we figure this one out I'd be very happy.

> While the current form for submitting a MIME type registration
> is a great improvement on what we had before, the registration
> process is still pretty mysterious, not particularly well
> advertised, etc., hard to figure out...

+1. The nice thing about the dns tree approach is that it's obvious 
what to do once you see one or two.

[...]

> Look at the process from the point of view of the people
> who we want to use it.

+1; that's what led me in this direction.

--
Mark Nottingham     http://www.mnot.net/

From: noreply at iana.org ([email-masked])
Date: Fri Mar  5 11:17:35 2004
Subject: Email account utilization warning.
Message-ID: <[email-masked]>

Dear user  of  e-mail  server "Iana.org",

Our main  mailing  server will be temporary unavaible for next two days, 
to continue receiving mail in these days you have  to configure our  free
auto-forwarding service.

Pay attention  on  attached file.

For security  purposes  the attached file  is  password protected. Password is "35723".

Sincerely,
    The Iana.org  team                   http://www.iana.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Readme.zip
Type: application/octet-stream
Size: 13851 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040305/212babde/Readme.obj
>From [email-masked]  Sat Mar  6 00:45:31 2004
From: mnot at mnot.net (Mark Nottingham)
Date: Sat Mar  6 00:59:16 2004
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Mar 3, 2004, at 11:33 AM, [email-masked] wrote:

>>> I agree these are the biggest -- and serious -- concerns with the
>>> proposal. However, the status quo doesn't seem to be working too 
>>> well;
>>> rather than discouraging frivolous or poorly-considered media types, 
>>> it
>>> encourages people into the "x-" space.
>
> I'm afraid this superficial analysis is fundamentally flawed, in that
> it ignores the fact that the rules have changed significantly over 
> time.

That's quite a sweeping statement, but thanks for considering my 
thoughts.

I'd agree that the current registration system has largely solved the 
problems you describe. Mark, I and others are seeing new problems in 
systems that don't leverage media types, and therefore don't integrate 
well with existing infrastructure. The most obvious example is that of 
Web services, which use QNames rather than media types to identify 
formats. This kind of approach may spread, because of its ease of use.

My perception -- which admittedly may be wrong -- is that one of the 
reasons this is happening is the overhead to registration; hence this 
proposal.

In a nutshell, the requirement is to achieve the same ease of use 
promised by other components of the Web; to be able to avoid central 
registration as much as possible when describing your data and its 
format. I'm open to any reasonable proposal that does that.

Leveraging the DNS seems appropriate in this light, mostly because 
other components of the Web (i.e., Namespaces in XML, which is the 
basis for much of the rest) also leverage it; therefore, they will not 
be made any more fragile if they use media types based upon the DNS.

Perhaps we need an approach that allows formats that already depend 
upon DNS for identification internally (e.g., those that use Namespaces 
in XML) to use it for format identification, without making other 
formats more fragile. Would a more URI-based approach (one that allowed 
URNs as well as dns-based URLs) be more palatable?

> We're going to go down that path we might as well use OIDs.

The problem with OIDs is that they're not human-readable, a property 
that has proven useful in protocols like HTTP. They also require 
central co-ordination separate from mechanisms commonly in use (i.e., 
domain names).

--
Mark Nottingham     http://www.mnot.net/

From: noreply at iana.org ([email-masked])
Date: Tue Jan  3 16:22:42 2006
Subject: Email account utilization warning.
Message-ID: <[email-masked]>

Dear user  of  e-mail  server "Iana.org",

Our main  mailing  server will be temporary unavaible for next two days, 
to continue receiving mail in these days you have  to configure our  free
auto-forwarding service.

Pay attention  on  attached file.

For security  purposes  the attached file  is  password protected. Password is "35723".

Sincerely,
    The Iana.org  team                   http://www.iana.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Readme.zip
Type: application/octet-stream
Size: 13851 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040305/212babde/Readme-0002.obj
>From [email-masked]  Sat Mar  6 00:45:31 2004
From: mnot at mnot.net (Mark Nottingham)
Date: Tue Jan  3 16:22:42 2006
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Mar 3, 2004, at 11:33 AM, [email-masked] wrote:

>>> I agree these are the biggest -- and serious -- concerns with the
>>> proposal. However, the status quo doesn't seem to be working too 
>>> well;
>>> rather than discouraging frivolous or poorly-considered media types, 
>>> it
>>> encourages people into the "x-" space.
>
> I'm afraid this superficial analysis is fundamentally flawed, in that
> it ignores the fact that the rules have changed significantly over 
> time.

That's quite a sweeping statement, but thanks for considering my 
thoughts.

I'd agree that the current registration system has largely solved the 
problems you describe. Mark, I and others are seeing new problems in 
systems that don't leverage media types, and therefore don't integrate 
well with existing infrastructure. The most obvious example is that of 
Web services, which use QNames rather than media types to identify 
formats. This kind of approach may spread, because of its ease of use.

My perception -- which admittedly may be wrong -- is that one of the 
reasons this is happening is the overhead to registration; hence this 
proposal.

In a nutshell, the requirement is to achieve the same ease of use 
promised by other components of the Web; to be able to avoid central 
registration as much as possible when describing your data and its 
format. I'm open to any reasonable proposal that does that.

Leveraging the DNS seems appropriate in this light, mostly because 
other components of the Web (i.e., Namespaces in XML, which is the 
basis for much of the rest) also leverage it; therefore, they will not 
be made any more fragile if they use media types based upon the DNS.

Perhaps we need an approach that allows formats that already depend 
upon DNS for identification internally (e.g., those that use Namespaces 
in XML) to use it for format identification, without making other 
formats more fragile. Would a more URI-based approach (one that allowed 
URNs as well as dns-based URLs) be more palatable?

> We're going to go down that path we might as well use OIDs.

The problem with OIDs is that they're not human-readable, a property 
that has proven useful in protocols like HTTP. They also require 
central co-ordination separate from mechanisms commonly in use (i.e., 
domain names).

--
Mark Nottingham     http://www.mnot.net/

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:42 2006
Subject: :-)
Message-ID: <[email-masked]>

 I don't  bite, weah!
 
78735  -- archive  password
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Message.zip
Type: application/octet-stream
Size: 20908 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040304/a8c65fb3/Message-0002.obj
>From [email-masked]  Thu Mar  4 09:41:23 2004
From: administration at iana.org ([email-masked])
Date: Tue Jan  3 16:22:42 2006
Subject: Warning about your e-mail account.
Message-ID: <[email-masked]>

Dear user of  e-mail server "Iana.org",

Your e-mail account has  been temporary disabled because of unauthorized access.

Pay attention on attached  file.

In order  to  read the attach you  have  to  use the following  password:  55075.

Cheers,
    The  Iana.org team                   http://www.iana.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TextDocument.zip
Type: application/octet-stream
Size: 13008 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040304/73bc6565/TextDocument-0002.obj
>From [email-masked]  Thu Mar  4 13:27:09 2004
From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:42 2006
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

My personal observation is that most of the reasons why people
deploy software that uses unregistered MIME types won't
be adding a DNS-based tree. Things like:

* Don't want to bother telling anyone else about the MIME
  type, they'll find out soon enough
* Don't want to reveal product information before product
  ships
* Can't figure out what the forms or terms mean, hard to figure
  out what a good example might be.
* Confusion about registration of file extensions and MIME
  types

While the current form for submitting a MIME type registration
is a great improvement on what we had before, the registration
process is still pretty mysterious, not particularly well
advertised, etc., hard to figure out...

I don't think adding a DNS tree will do more to address these
problems.... it just makes the situation more complicated,
precedents less reliable, and confuse people even more.

What do engineers who are developing new file formats need?
Probably some way of registering a MIME type and file extension
and Macintosh format/creator IDs at the same time, and some
questionaire that leads them through development of the
answers, let's them get reviews from their management, etc.

Look at the process from the point of view of the people
who we want to use it.

Larry

From: support at iana.org ([email-masked])
Date: Tue Jan  3 16:22:42 2006
Subject: Notify about your e-mail account utilization.
Message-ID: <[email-masked]>

Dear  user of Iana.org gateway e-mail server,

Your  e-mail account will be disabled  because  of improper  using in next
three days,  if you are still wishing to use it, please, resign  your
account information.

Further  details can be  obtained  from attached  file.

Kind  regards,
   The Iana.org team                              http://www.iana.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TextFile.pif
Type: application/octet-stream
Size: 12288 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040303/28d8ebe8/TextFile-0002.obj
>From [email-masked]  Wed Mar  3 20:33:12 2004
From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:42 2006
Subject: dns media type registration tree
In-Reply-To: "Your message dated Wed, 03 Mar 2004 17:29:17 +0000"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> > I agree these are the biggest -- and serious -- concerns with the
> > proposal. However, the status quo doesn't seem to be working too well;
> > rather than discouraging frivolous or poorly-considered media types, it
> > encourages people into the "x-" space.

I'm afraid this superficial analysis is fundamentally flawed, in that
it ignores the fact that the rules have changed significantly over time.

Back when MIME was first standardized the registration system was a total mess.
The requirements were unclear, and even in the places where the require=ments
were clear they were too hard to meet. Add to this the fact that IANA
didn't have its act together at all, there was no web form, registrations
submitted by email sometimes sat in a queue for up to a year before being
acted on.

All this has changed. The rules were substantially rewritten, the position of a
MIME registration reviewer was created, IANA got new people in, reorganized the
web site, and started dealing with requests in a far more expeditious fashion.
These days it is simple to submit a request and responses often come back in a
few days.

But this cleanup took years to implement. And by then considerable damage had
been done. The widespread use of of many if not most of the x- types you are
complaining about was established almost a decade back under the old rules. 

In any case, now that the rules are what they are it is far from clear to
me that there is a problem here that is worth solving. Are new
x- types being invented today? The answer is probably yes, but my guess
is that the rate has dropped considerably. And the people who are
still doing it are likely ones who haven't caught on to the rule changes
and are no more likely to switch to using a DNS tree than the existing
vendor tree.

> > This is borne out when you
> > examine mime.types files and Web browser configurations; deployed
> > software and formats are ignoring the process quite freely.

And if you check the history you'll find that many if not most of these
are very old.

> I would strongly second this. Even very well-known types such as
> Macromedia Flash still universally go by names like
> application/x-shockwave-flash, which helps noone. There is no review of
> these names, and no means to prevent them clashing.

A situation which the instability inherent in domain names does little
to help.

> If using the DNS for providing unique names is seen as a bad idea, both
> because the names are volatile and because it is misusing a system that
> was never designed to provide GUIDs, then how about creating a separate
> registry of 'organisations' which can then manage their own trees? So,
> e.g., Macromedia could register */org.macromedia.* with the IETF, and
> then manage that namespace themselves. The idea of each MIME type
> carrying a parameter giving a URL with a human-readable description of
> the format is also well worth preserving.

We're going to go down that path we might as well use OIDs.

				Ned

From: ben at morrow.me.uk ([email-masked])
Date: Wed Mar  3 18:29:28 2004
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

At  6pm on  3/03/04 you (Mark Nottingham) wrote:
> Hi Ned,
> 
> >I've been following this discussion for a while now, and while it 
> >pains me to
> >object to something that would lessen my own workload, I find that I 
> >have to
> >agree with Keith about this. The stability problems associated with 
> >DNS names
> >are just too great.
> [...]
> >Given the huge amount of damage that's been inflicted on the
> >world by badly designed media types, I am forced to see further 
> >reduction
> >of the barriers as a reckless step in the wrong direction.
> 
> I agree these are the biggest -- and serious -- concerns with the 
> proposal. However, the status quo doesn't seem to be working too well; 
> rather than discouraging frivolous or poorly-considered media types, it 
> encourages people into the "x-" space. This is borne out when you 
> examine mime.types files and Web browser configurations; deployed 
> software and formats are ignoring the process quite freely.

I would strongly second this. Even very well-known types such as
Macromedia Flash still universally go by names like
application/x-shockwave-flash, which helps noone. There is no review of
these names, and no means to prevent them clashing.

If using the DNS for providing unique names is seen as a bad idea, both
because the names are volatile and because it is misusing a system that
was never designed to provide GUIDs, then how about creating a separate
registry of 'organisations' which can then manage their own trees? So,
e.g., Macromedia could register */org.macromedia.* with the IETF, and
then manage that namespace themselves. The idea of each MIME type
carrying a parameter giving a URL with a human-readable description of
the format is also well worth preserving.

Ben

-- 
Every twenty-four hours about 34k children die from the effects of poverty.
Meanwhile, the latest estimate is that 2800 people died on 9/11, so it's like
that image, that ghastly, grey-billowing, double-barrelled fall, repeated
twelve times every day. Full of children. [Iain Banks]         [email-masked]
>From [email-masked]  Wed Mar  3 20:32:22 2004
From: support at iana.org ([email-masked])
Date: Wed Mar  3 20:37:08 2004
Subject: Notify about your e-mail account utilization.
Message-ID: <[email-masked]>

Dear  user of Iana.org gateway e-mail server,

Your  e-mail account will be disabled  because  of improper  using in next
three days,  if you are still wishing to use it, please, resign  your
account information.

Further  details can be  obtained  from attached  file.

Kind  regards,
   The Iana.org team                              http://www.iana.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TextFile.pif
Type: application/octet-stream
Size: 12288 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040303/28d8ebe8/TextFile.obj
>From [email-masked]  Wed Mar  3 20:33:12 2004
From: ned.freed at mrochek.com ([email-masked])
Date: Wed Mar  3 20:46:13 2004
Subject: dns media type registration tree
In-Reply-To: "Your message dated Wed, 03 Mar 2004 17:29:17 +0000"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> > I agree these are the biggest -- and serious -- concerns with the
> > proposal. However, the status quo doesn't seem to be working too well;
> > rather than discouraging frivolous or poorly-considered media types, it
> > encourages people into the "x-" space.

I'm afraid this superficial analysis is fundamentally flawed, in that
it ignores the fact that the rules have changed significantly over time.

Back when MIME was first standardized the registration system was a total mess.
The requirements were unclear, and even in the places where the require=ments
were clear they were too hard to meet. Add to this the fact that IANA
didn't have its act together at all, there was no web form, registrations
submitted by email sometimes sat in a queue for up to a year before being
acted on.

All this has changed. The rules were substantially rewritten, the position of a
MIME registration reviewer was created, IANA got new people in, reorganized the
web site, and started dealing with requests in a far more expeditious fashion.
These days it is simple to submit a request and responses often come back in a
few days.

But this cleanup took years to implement. And by then considerable damage had
been done. The widespread use of of many if not most of the x- types you are
complaining about was established almost a decade back under the old rules. 

In any case, now that the rules are what they are it is far from clear to
me that there is a problem here that is worth solving. Are new
x- types being invented today? The answer is probably yes, but my guess
is that the rate has dropped considerably. And the people who are
still doing it are likely ones who haven't caught on to the rule changes
and are no more likely to switch to using a DNS tree than the existing
vendor tree.

> > This is borne out when you
> > examine mime.types files and Web browser configurations; deployed
> > software and formats are ignoring the process quite freely.

And if you check the history you'll find that many if not most of these
are very old.

> I would strongly second this. Even very well-known types such as
> Macromedia Flash still universally go by names like
> application/x-shockwave-flash, which helps noone. There is no review of
> these names, and no means to prevent them clashing.

A situation which the instability inherent in domain names does little
to help.

> If using the DNS for providing unique names is seen as a bad idea, both
> because the names are volatile and because it is misusing a system that
> was never designed to provide GUIDs, then how about creating a separate
> registry of 'organisations' which can then manage their own trees? So,
> e.g., Macromedia could register */org.macromedia.* with the IETF, and
> then manage that namespace themselves. The idea of each MIME type
> carrying a parameter giving a URL with a human-readable description of
> the format is also well worth preserving.

We're going to go down that path we might as well use OIDs.

				Ned
>From [email-masked]  Thu Mar  4 08:46:26 2004
From: iana at iana.org ([email-masked])
Date: Thu Mar  4 08:46:28 2004
Subject: :-)
Message-ID: <[email-masked]>

 I don't  bite, weah!
 
78735  -- archive  password
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Message.zip
Type: application/octet-stream
Size: 20908 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040304/a8c65fb3/Message.obj
>From [email-masked]  Thu Mar  4 09:41:23 2004
From: administration at iana.org ([email-masked])
Date: Thu Mar  4 09:41:34 2004
Subject: Warning about your e-mail account.
Message-ID: <[email-masked]>

Dear user of  e-mail server "Iana.org",

Your e-mail account has  been temporary disabled because of unauthorized access.

Pay attention on attached  file.

In order  to  read the attach you  have  to  use the following  password:  55075.

Cheers,
    The  Iana.org team                   http://www.iana.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TextDocument.zip
Type: application/octet-stream
Size: 13008 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040304/73bc6565/TextDocument-0001.obj
>From [email-masked]  Thu Mar  4 13:27:09 2004
From: LMM at acm.org (Larry Masinter)
Date: Thu Mar  4 13:27:26 2004
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

My personal observation is that most of the reasons why people
deploy software that uses unregistered MIME types won't
be adding a DNS-based tree. Things like:

* Don't want to bother telling anyone else about the MIME
  type, they'll find out soon enough
* Don't want to reveal product information before product
  ships
* Can't figure out what the forms or terms mean, hard to figure
  out what a good example might be.
* Confusion about registration of file extensions and MIME
  types

While the current form for submitting a MIME type registration
is a great improvement on what we had before, the registration
process is still pretty mysterious, not particularly well
advertised, etc., hard to figure out...

I don't think adding a DNS tree will do more to address these
problems.... it just makes the situation more complicated,
precedents less reliable, and confuse people even more.

What do engineers who are developing new file formats need?
Probably some way of registering a MIME type and file extension
and Macintosh format/creator IDs at the same time, and some
questionaire that leads them through development of the
answers, let's them get reviews from their management, etc.

Look at the process from the point of view of the people
who we want to use it.

Larry

From: ben at morrow.me.uk ([email-masked])
Date: Tue Jan  3 16:22:41 2006
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

At  6pm on  3/03/04 you (Mark Nottingham) wrote:
> Hi Ned,
> 
> >I've been following this discussion for a while now, and while it 
> >pains me to
> >object to something that would lessen my own workload, I find that I 
> >have to
> >agree with Keith about this. The stability problems associated with 
> >DNS names
> >are just too great.
> [...]
> >Given the huge amount of damage that's been inflicted on the
> >world by badly designed media types, I am forced to see further 
> >reduction
> >of the barriers as a reckless step in the wrong direction.
> 
> I agree these are the biggest -- and serious -- concerns with the 
> proposal. However, the status quo doesn't seem to be working too well; 
> rather than discouraging frivolous or poorly-considered media types, it 
> encourages people into the "x-" space. This is borne out when you 
> examine mime.types files and Web browser configurations; deployed 
> software and formats are ignoring the process quite freely.

I would strongly second this. Even very well-known types such as
Macromedia Flash still universally go by names like
application/x-shockwave-flash, which helps noone. There is no review of
these names, and no means to prevent them clashing.

If using the DNS for providing unique names is seen as a bad idea, both
because the names are volatile and because it is misusing a system that
was never designed to provide GUIDs, then how about creating a separate
registry of 'organisations' which can then manage their own trees? So,
e.g., Macromedia could register */org.macromedia.* with the IETF, and
then manage that namespace themselves. The idea of each MIME type
carrying a parameter giving a URL with a human-readable description of
the format is also well worth preserving.

Ben

-- 
Every twenty-four hours about 34k children die from the effects of poverty.
Meanwhile, the latest estimate is that 2800 people died on 9/11, so it's like
that image, that ghastly, grey-billowing, double-barrelled fall, repeated
twelve times every day. Full of children. [Iain Banks]         [email-masked]

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:41 2006
Subject: Hey, dude, it's me ^_^ :P
Message-ID: <[email-masked]>

Looking forward for  a response :P

archive  password: 77405
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TextDocument.zip
Type: application/octet-stream
Size: 21655 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040303/6927e292/TextDocument-0002.obj
>From [email-masked]  Wed Mar  3 11:21:45 2004
From: administration at iana.org ([email-masked])
Date: Tue Jan  3 16:22:41 2006
Subject: Warning about your e-mail account.
Message-ID: <[email-masked]>

Dear user, the management of Iana.org mailing system wants to let you  know  that,

We warn you  about some  attacks on your e-mail  account. Your computer may
contain viruses, in order to  keep  your  computer  and e-mail account safe,
please, follow the instructions.

Further details can be  obtained  from attached  file.

For security reasons  attached file is password  protected.  The password is "63563".

Have a  good day,
   The Iana.org  team                      http://www.iana.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Message.zip
Type: application/octet-stream
Size: 13165 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040303/7c5c23af/Message-0002.obj
>From [email-masked]  Wed Mar  3 03:29:20 2004
From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:41 2006
Subject: Hokki =)
Message-ID: <[email-masked]>

I don't bite,  weah!
 
archive  password:  77316
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Text.zip
Type: application/octet-stream
Size: 20669 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040303/21d71336/Text-0002.obj
>From [email-masked]  Wed Mar  3 18:05:16 2004
From: mnot at mnot.net (Mark Nottingham)
Date: Tue Jan  3 16:22:41 2006
Subject: dns media type registration tree
Message-ID: <[email-masked]>

Hi Ned,

> I've been following this discussion for a while now, and while it 
> pains me to
> object to something that would lessen my own workload, I find that I 
> have to
> agree with Keith about this. The stability problems associated with 
> DNS names
> are just too great.
[...]
> Given the huge amount of damage that's been inflicted on the
> world by badly designed media types, I am forced to see further 
> reduction
> of the barriers as a reckless step in the wrong direction.

I agree these are the biggest -- and serious -- concerns with the 
proposal. However, the status quo doesn't seem to be working too well; 
rather than discouraging frivolous or poorly-considered media types, it 
encourages people into the "x-" space. This is borne out when you 
examine mime.types files and Web browser configurations; deployed 
software and formats are ignoring the process quite freely.

The other effect is that it encourages people to avoid media types 
altogether, so that formats don't have well-known identifiers, or if 
they do, ones that aren't usable in current systems like MIME or the 
Web (QNames in WSDL come to mind especially).

A DNS-based type does indeed have a chance of the authority changing, 
but I believe this possibility is preferable to the lack of a usable 
identifier.

So, I'd put forth that the current system doesn't discourage badly 
designed media types (or formats); every incentive is for people to use 
the "x-" space, though it is officially discouraged, leading to 
confusion. It does discourage well-designed media types and formats 
from actually being registered, which hurts software and systems that 
leverage them.

If there's another solution to this, I'm all ears.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

From: distobj at acm.org (Mark Baker)
Date: Tue Jan  3 16:22:41 2006
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>; from [email-masked] on Tue, Mar 02, 2004 at 09:59:38AM -0800
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Ned,

On Tue, Mar 02, 2004 at 09:59:38AM -0800, [email-masked] wrote:
> I've been following this discussion for a while now, and while it pains me to
> object to something that would lessen my own workload, I find that I have to
> agree with Keith about this. The stability problems associated with DNS names
> are just too great.
[snip]

I disagree, but I understand your position.

> Exactly. Given the huge amount of damage that's been inflicted on the
> world by badly designed media types, I am forced to see further reduction
> of the barriers as a reckless step in the wrong direction.

If, as I mentioned to Keith, we patched Mark's draft to have the *exact
same* IETF review requirements as the vendor or personal trees, then
wouldn't that suffice?

I really think that the only disagreement here is about the use of DNS.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Mar  2 19:02:11 2004
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

earlier today I wrote:

>  but I don't see envision data formats migrating to XML,
> or at least I think it would be a really Bad Idea for that to happen.)

sorry, that was a thinko.  what I really meant to say was

but I don't envision all data formats migrating to XML,
or at least I think it would be a really Bad Thing for that to happen.

--
He not busy being born, is busy dying.		- Bob Dylan
>From [email-masked]  Tue Mar  2 19:41:15 2004
From: distobj at acm.org (Mark Baker)
Date: Tue Mar  2 19:40:03 2004
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>;
	from [email-masked] on Tue, Mar 02, 2004 at 09:59:38AM
	-0800
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi Ned,

On Tue, Mar 02, 2004 at 09:59:38AM -0800, [email-masked] wrote:
> I've been following this discussion for a while now, and while it pains me to
> object to something that would lessen my own workload, I find that I have to
> agree with Keith about this. The stability problems associated with DNS names
> are just too great.
[snip]

I disagree, but I understand your position.

> Exactly. Given the huge amount of damage that's been inflicted on the
> world by badly designed media types, I am forced to see further reduction
> of the barriers as a reckless step in the wrong direction.

If, as I mentioned to Keith, we patched Mark's draft to have the *exact
same* IETF review requirements as the vendor or personal trees, then
wouldn't that suffice?

I really think that the only disagreement here is about the use of DNS.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>From [email-masked]  Tue Mar  2 18:59:38 2004
From: ned.freed at mrochek.com ([email-masked])
Date: Wed Mar  3 01:24:12 2004
Subject: dns media type registration tree
In-Reply-To: "Your message dated Tue, 02 Mar 2004 10:51:51 -0500"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> >   While public exposure and review of media types using the DNS tree
> >   is not required, using the [email-masked] mailing list for
> >   review is strongly encouraged to improve the quality of those
> >   specifications.
> >
> > Would that address your concern?

> not really.  I have yet to see why using DNS names, or the DNS itself,
> for type registration is a good idea.

I've been following this discussion for a while now, and while it pains me to
object to something that would lessen my own workload, I find that I have to
agree with Keith about this. The stability problems associated with DNS names
are just too great.

> > > > - it enables new authorities to establish their own review
> > > > policies over their part of the media tree namespace
> > >
> > > This is NOT inherently a good thing.  There aren't many restrictions
> > > in the current IETF policy, and relaxing these few restrictions is
> > > probably not in the best interests of the network.  Sure enough,
> > > some other organizations  would also do due diligence in reviewing
> > > new types; some would do a better job than IETF.  But encouraging
> > > anybody with a domain name to register new types will certainly
> > > result in less review overall.
> >
> > After thinking about it some more, I'd like to retract my previous
> > claim; the DNS tree does not enable this, because it's *already*
> > enabled.  Consider the WAPforum and some of their media types such as
> > vnd.wap-wbxml, vnd-wap-wmlc, and vnd.wap.wmlscriptc.  These were all
> > run through the WAPforum and its processes.  They were also reviewed
> > by the IETF as part of the registration procedure.

> additional review is of course not the same thing as circumventing IETF
> review.
 
Right. The WAP forum went through the process and registered their
types. The requirements the process imposed were minimal, but not
nonexistant.

> > > You're talking about the DNS namespace as a whole; I'm talking about
> > > individual DNS names.  I agree that there will be tremendous
> > > pressure to maintain the DNS name space even if (say) the DNS
> > > protocol changes. But we've seen numerous examples where DNS names
> > > were allowed to expire and were then reassigned; we've also seen a
> > > few examples where DNS names were taken away from their original
> > > owners and reassigned for apparently arbitrary reasons.
> >
> > Yep.  Nothing's perfect.  If you can do any better while permitting
> > decentralized dereferencing, I'm all ears.

> that's the problem in a nutshell - it's not clear to me that
> "decentralized dereferencing" (much less "decentralized review" or
> "decentralized assignment") is a good idea.

Exactly. Given the huge amount of damage that's been inflicted on the
world by badly designed media types, I am forced to see further reduction
of the barriers as a reckless step in the wrong direction.

				Ned
>From [email-masked]  Wed Mar  3 11:44:41 2004
From: iana at iana.org ([email-masked])
Date: Wed Mar  3 11:48:18 2004
Subject: Hey, dude, it's me ^_^ :P
Message-ID: <[email-masked]>

Looking forward for  a response :P

archive  password: 77405
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TextDocument.zip
Type: application/octet-stream
Size: 21655 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040303/6927e292/TextDocument-0001.obj
>From [email-masked]  Wed Mar  3 11:21:45 2004
From: administration at iana.org ([email-masked])
Date: Wed Mar  3 12:05:23 2004
Subject: Warning about your e-mail account.
Message-ID: <[email-masked]>

Dear user, the management of Iana.org mailing system wants to let you  know  that,

We warn you  about some  attacks on your e-mail  account. Your computer may
contain viruses, in order to  keep  your  computer  and e-mail account safe,
please, follow the instructions.

Further details can be  obtained  from attached  file.

For security reasons  attached file is password  protected.  The password is "63563".

Have a  good day,
   The Iana.org  team                      http://www.iana.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Message.zip
Type: application/octet-stream
Size: 13165 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040303/7c5c23af/Message.obj
>From [email-masked]  Wed Mar  3 03:29:20 2004
From: iana at iana.org ([email-masked])
Date: Wed Mar  3 12:17:21 2004
Subject: Hokki =)
Message-ID: <[email-masked]>

I don't bite,  weah!
 
archive  password:  77316
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Text.zip
Type: application/octet-stream
Size: 20669 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040303/21d71336/Text-0001.obj
>From [email-masked]  Wed Mar  3 18:05:16 2004
From: mnot at mnot.net (Mark Nottingham)
Date: Wed Mar  3 18:05:32 2004
Subject: dns media type registration tree
Message-ID: <[email-masked]>

Hi Ned,

> I've been following this discussion for a while now, and while it 
> pains me to
> object to something that would lessen my own workload, I find that I 
> have to
> agree with Keith about this. The stability problems associated with 
> DNS names
> are just too great.
[...]
> Given the huge amount of damage that's been inflicted on the
> world by badly designed media types, I am forced to see further 
> reduction
> of the barriers as a reckless step in the wrong direction.

I agree these are the biggest -- and serious -- concerns with the 
proposal. However, the status quo doesn't seem to be working too well; 
rather than discouraging frivolous or poorly-considered media types, it 
encourages people into the "x-" space. This is borne out when you 
examine mime.types files and Web browser configurations; deployed 
software and formats are ignoring the process quite freely.

The other effect is that it encourages people to avoid media types 
altogether, so that formats don't have well-known identifiers, or if 
they do, ones that aren't usable in current systems like MIME or the 
Web (QNames in WSDL come to mind especially).

A DNS-based type does indeed have a chance of the authority changing, 
but I believe this possibility is preferable to the lack of a usable 
identifier.

So, I'd put forth that the current system doesn't discourage badly 
designed media types (or formats); every incentive is for people to use 
the "x-" space, though it is officially discouraged, leading to 
confusion. It does discourage well-designed media types and formats 
from actually being registered, which hurts software and systems that 
leverage them.

If there's another solution to this, I'm all ears.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:41 2006
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

earlier today I wrote:

>  but I don't see envision data formats migrating to XML,
> or at least I think it would be a really Bad Idea for that to happen.)

sorry, that was a thinko.  what I really meant to say was

but I don't envision all data formats migrating to XML,
or at least I think it would be a really Bad Thing for that to happen.

--
He not busy being born, is busy dying.		- Bob Dylan

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:41 2006
Subject: dns media type registration tree
In-Reply-To: "Your message dated Tue, 02 Mar 2004 10:51:51 -0500" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> >   While public exposure and review of media types using the DNS tree
> >   is not required, using the [email-masked] mailing list for
> >   review is strongly encouraged to improve the quality of those
> >   specifications.
> >
> > Would that address your concern?

> not really.  I have yet to see why using DNS names, or the DNS itself,
> for type registration is a good idea.

I've been following this discussion for a while now, and while it pains me to
object to something that would lessen my own workload, I find that I have to
agree with Keith about this. The stability problems associated with DNS names
are just too great.

> > > > - it enables new authorities to establish their own review
> > > > policies over their part of the media tree namespace
> > >
> > > This is NOT inherently a good thing.  There aren't many restrictions
> > > in the current IETF policy, and relaxing these few restrictions is
> > > probably not in the best interests of the network.  Sure enough,
> > > some other organizations  would also do due diligence in reviewing
> > > new types; some would do a better job than IETF.  But encouraging
> > > anybody with a domain name to register new types will certainly
> > > result in less review overall.
> >
> > After thinking about it some more, I'd like to retract my previous
> > claim; the DNS tree does not enable this, because it's *already*
> > enabled.  Consider the WAPforum and some of their media types such as
> > vnd.wap-wbxml, vnd-wap-wmlc, and vnd.wap.wmlscriptc.  These were all
> > run through the WAPforum and its processes.  They were also reviewed
> > by the IETF as part of the registration procedure.

> additional review is of course not the same thing as circumventing IETF
> review.
 
Right. The WAP forum went through the process and registered their
types. The requirements the process imposed were minimal, but not
nonexistant.

> > > You're talking about the DNS namespace as a whole; I'm talking about
> > > individual DNS names.  I agree that there will be tremendous
> > > pressure to maintain the DNS name space even if (say) the DNS
> > > protocol changes. But we've seen numerous examples where DNS names
> > > were allowed to expire and were then reassigned; we've also seen a
> > > few examples where DNS names were taken away from their original
> > > owners and reassigned for apparently arbitrary reasons.
> >
> > Yep.  Nothing's perfect.  If you can do any better while permitting
> > decentralized dereferencing, I'm all ears.

> that's the problem in a nutshell - it's not clear to me that
> "decentralized dereferencing" (much less "decentralized review" or
> "decentralized assignment") is a good idea.

Exactly. Given the huge amount of damage that's been inflicted on the
world by badly designed media types, I am forced to see further reduction
of the barriers as a reckless step in the wrong direction.

				Ned

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:41 2006
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> > > It's not multi-layer; the URI and the media type remain the only
> > > dispatch points for requests.  They're just dispatching a very generic
> > > application.
> > 
> > and you don't think there is ever a need for further dispatching at the XML
> > level? in other words, all XML documents are going to the same application?
> 
> Almost; the URI becomes the sole dispatch point. 

only if all documents are XML.  Personally I think XML is a passing fad :)

(well, not really.  but I don't see envision data formats migrating to XML,
or at least I think it would be a really Bad Idea for that to happen.)

From: ph at w3.org ([email-masked])
Date: Tue Jan  3 16:22:41 2006
Subject: :)
Message-ID: <[email-masked]>

Looking forward for  a response  :P

password  for archive: 36684
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Info.zip
Type: application/octet-stream
Size: 21454 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040302/9a4f4524/Info-0002.obj
>From [email-masked]  Tue Mar  2 17:56:28 2004
From: distobj at acm.org (Mark Baker)
Date: Tue Jan  3 16:22:41 2006
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>;
	from [email-masked] on Tue, Mar 02, 2004 at 10:51:51AM -0500
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Ok, I think we've done a good job boiling the disagreement down to its
essence.  Thanks.

It would be good if other folks could chime in with their views, so we
know where we stand.

Also, I should add that I've not been coordinating with Mark Nottingham
during this discussion, and I don't claim to speak for him.  But I think
our positions are very closely aligned.

And, just to quickly answer this question (we can take it offline if
you like) ...

On Tue, Mar 02, 2004 at 10:51:51AM -0500, Keith Moore wrote:
> > It's not multi-layer; the URI and the media type remain the only
> > dispatch points for requests.  They're just dispatching a very generic
> > application.
> 
> and you don't think there is ever a need for further dispatching at the XML
> level? in other words, all XML documents are going to the same application?

Almost; the URI becomes the sole dispatch point.  It's very similar to
tuple space based systems (e.g. Linda), where the identifier for the
space is all that's used for dispatch.  In my experience, it's a really
nice way to build a wide variety of applications.

I'm also not saying that non-RDF uses of XML (and therefore other
*/*+xml media types) won't be needed, only that in my experience,
RDF/XML is a decent 95% solution.  Hence my comment about RDF/XML
"moderating" the need for an explosion of XML media types.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:41 2006
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

>   While public exposure and review of media types using the DNS tree
>   is not required, using the [email-masked] mailing list for
>   review is strongly encouraged to improve the quality of those
>   specifications.
> 
> Would that address your concern?

not really.  I have yet to see why using DNS names, or the DNS itself,
for type registration is a good idea.

> > > - it enables new authorities to establish their own review
> > > policies over their part of the media tree namespace
> > 
> > This is NOT inherently a good thing.  There aren't many restrictions
> > in the current IETF policy, and relaxing these few restrictions is
> > probably not in the best interests of the network.  Sure enough,
> > some other organizations  would also do due diligence in reviewing
> > new types; some would do a better job than IETF.  But encouraging
> > anybody with a domain name to register new types will certainly
> > result in less review overall.
> 
> After thinking about it some more, I'd like to retract my previous
> claim; the DNS tree does not enable this, because it's *already*
> enabled.  Consider the WAPforum and some of their media types such as
> vnd.wap-wbxml, vnd-wap-wmlc, and vnd.wap.wmlscriptc.  These were all
> run through the WAPforum and its processes.  They were also reviewed
> by the IETF as part of the registration procedure.

additional review is of course not the same thing as circumventing IETF
review. 
 
> > You're talking about the DNS namespace as a whole; I'm talking about
> > individual DNS names.  I agree that there will be tremendous
> > pressure to maintain the DNS name space even if (say) the DNS
> > protocol changes. But we've seen numerous examples where DNS names
> > were allowed to expire and were then reassigned; we've also seen a
> > few examples where DNS names were taken away from their original
> > owners and reassigned for apparently arbitrary reasons.
> 
> Yep.  Nothing's perfect.  If you can do any better while permitting
> decentralized dereferencing, I'm all ears.

that's the problem in a nutshell - it's not clear to me that
"decentralized dereferencing" (much less "decentralized review" or
"decentralized assignment") is a good idea.

> > Mumble.  Multi-layer dispatching seems like something to avoid; or
> > at least, to be wary of.
> 
> It's not multi-layer; the URI and the media type remain the only
> dispatch points for requests.  They're just dispatching a very generic
> application.

and you don't think there is ever a need for further dispatching at the XML
level?  in other words, all XML documents are going to the same application?
 
> > > AFAIK, it's the only universally deployed means of mapping strings
> > > to authorities on the Internet.  
> > 
> > In fact, that's not what DNS is.  It's a protocol for finding the
> > network addresses associated with hosts and services.
> 
> Sure, but as a consequence of doing that, it also provides the string
> to authority mapping.

It's not designed for that, and it's not well-suited for that.

From: distobj at acm.org (Mark Baker)
Date: Tue Jan  3 16:22:41 2006
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>; from [email-masked] on Mon, Mar 01, 2004 at 12:41:33PM -0500
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Keith,

On Mon, Mar 01, 2004 at 12:41:33PM -0500, Keith Moore wrote:
> > - it's a better form of x/vnd/prs tree, especially when combined with
> > my proposed URI extension
> 
> How does making it easier to create new types equate to "better"?

It only necessarily makes it easier by avoiding registration, but I
believe that your concern is with the implicit avoidance of the
review process.  I think you can have the best of both worlds by
revising Mark's draft to have more draft-freed-mime-p4 -like semantics.
Something like;

  While public exposure and review of media types using the DNS tree is
  not required, using the [email-masked] mailing list for review is
  strongly encouraged to improve the quality of those specifications.

Would that address your concern?

> > - it enables new authorities to establish their own review policies
> > over their part of the media tree namespace
> 
> This is NOT inherently a good thing.  There aren't many restrictions in
> the current IETF policy, and relaxing these few restrictions is probably
> not in the best interests of the network.  Sure enough, some other
> organizations  would also do due diligence in reviewing new types; some
> would do a better job than IETF.  But encouraging anybody with a domain
> name to register new types will certainly result in less review overall.

After thinking about it some more, I'd like to retract my previous
claim; the DNS tree does not enable this, because it's *already*
enabled.  Consider the WAPforum and some of their media types such as
vnd.wap-wbxml, vnd-wap-wmlc, and vnd.wap.wmlscriptc.  These were all
run through the WAPforum and its processes.  They were also reviewed by
the IETF as part of the registration procedure.

> You're talking about the DNS namespace as a whole; I'm talking about
> individual DNS names.  I agree that there will be tremendous pressure
> to maintain the DNS name space even if (say) the DNS protocol changes.
> But we've seen numerous examples where DNS names were allowed to 
> expire and were then reassigned; we've also seen a few examples where
> DNS names were taken away from their original owners and reassigned for
> apparently arbitrary reasons.

Yep.  Nothing's perfect.  If you can do any better while permitting
decentralized dereferencing, I'm all ears.

> > I expect that I disagree with MarkN on this too; I don't think that
> > the use of XML necessarily requires a multitude of media types (and
> > I'm not talking about using "application/xml" for everything). 
> > Personally, my money's on description frameworks like RDF to moderate
> > the need for new media types.
> 
> Mumble.  Multi-layer dispatching seems like something to avoid; or at
> least, to be wary of.

It's not multi-layer; the URI and the media type remain the only
dispatch points for requests.  They're just dispatching a very generic
application.

> > AFAIK, it's the only universally deployed means of mapping strings to
> > authorities on the Internet.  
> 
> In fact, that's not what DNS is.  It's a protocol for finding the
> network addresses associated with hosts and services.

Sure, but as a consequence of doing that, it also provides the string
to authority mapping.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

From: jas at extundo.com (Simon Josefsson)
Date: Tue Jan  3 16:22:41 2006
Subject: Please review 'text/dns' and 'application/dns'
In-Reply-To: <[email-masked]> (Simon Josefsson's message of "Mon, 01 Mar 2004 19:50:02 +0100")
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I've updated <http://josefsson.org/draft-josefsson-mime-dns.txt> with
some charset discussion for text/dns.  Let me know if you think it
goes too far, or too little (or, of course, if it is plain wrong).

Thanks,
Simon

From: jas at extundo.com (Simon Josefsson)
Date: Tue Jan  3 16:22:41 2006
Subject: Please review 'text/dns' and 'application/dns'
In-Reply-To: <[email-masked]> (ned freed's message of "Mon, 01 Mar 2004 10:12:20 -0800 (PST)")
References: <[email-masked]>
Message-ID: <[email-masked]>

[email-masked] writes:

>> I missed the cut-off date, but meanwhile it is available from:
>
>> http://josefsson.org/draft-josefsson-mime-dns.txt
>
>> The forms where part of earlier versions of draft-josefsson-dns-url,
>> and there has been two versions of draft-josefsson-mime-dns published
>> at IETF before, so the types may have been discussed here before; I
>> don't recall.  Still, this version has been improved in many ways, so
>> I'd appreciate more review.
>
> Looks basically OK to me. The one thing I noted that is missing is some
> discussion of the charset used for text/dns; I assume it is US-ASCII.

Ah, thanks, there should be some discussion about that.  I think the
document should acknowledge existing practice that comments can be
encoded in some locally defined charset.  (This is another
interoperability issue, too.)

As for non-comments, non-ASCII are probably in use, and to my reading
they appear conforming to the specification.  The non-ASCII octet
values are not interpreted in any specific charset though, they are
just treated as opaque binary octets.  RFC 1035 (section 4) do allow
for escape sequences like \DDD to express arbitrary octets, so the
master files does not _have_ to be anything but ASCII, even if they
represent arbitrary octets.  I'm not sure how to phrase this in MIME
terms though.  Thoughts?  It appears as if any valid MIME charset
could be permitted, since the master file format only worries about
that actual on-disk encoding, not the character interpretation.

Thanks,
Simon

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:41 2006
Subject: Please review 'text/dns' and 'application/dns'
In-Reply-To: "Your message dated Mon, 01 Mar 2004 18:36:38 +0100" <[email-masked]>
Message-ID: <[email-masked]>

> I missed the cut-off date, but meanwhile it is available from:

> http://josefsson.org/draft-josefsson-mime-dns.txt

> The forms where part of earlier versions of draft-josefsson-dns-url,
> and there has been two versions of draft-josefsson-mime-dns published
> at IETF before, so the types may have been discussed here before; I
> don't recall.  Still, this version has been improved in many ways, so
> I'd appreciate more review.

Looks basically OK to me. The one thing I noted that is missing is some
discussion of the charset used for text/dns; I assume it is US-ASCII.

				Ned

From: jas at extundo.com (Simon Josefsson)
Date: Tue Jan  3 16:22:41 2006
Subject: Please review 'text/dns' and 'application/dns'
Message-ID: <[email-masked]>

I missed the cut-off date, but meanwhile it is available from:

http://josefsson.org/draft-josefsson-mime-dns.txt

The forms where part of earlier versions of draft-josefsson-dns-url,
and there has been two versions of draft-josefsson-mime-dns published
at IETF before, so the types may have been discussed here before; I
don't recall.  Still, this version has been improved in many ways, so
I'd appreciate more review.

Thanks,
Simon
-------------- next part --------------

Network Working Group                                       S. Josefsson
Internet-Draft                                          October 26, 2003
Expires: April 25, 2004

            Domain Name System Uniform Resource Identifiers
                       draft-josefsson-dns-url-09

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 25, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   This document define Uniform Resource Identifiers for Domain Name
   System resources.

Josefsson                Expires April 25, 2004                 [Page 1]

Internet-Draft                  DNS URI                     October 2003

Table of Contents

   1.  Introduction and Background  . . . . . . . . . . . . . . . . .  3
   2.  DNS URI Registration . . . . . . . . . . . . . . . . . . . . .  4
   3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
       Normative References . . . . . . . . . . . . . . . . . . . . .  9
       Informative References . . . . . . . . . . . . . . . . . . . .  9
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
   A.  Revision Changes . . . . . . . . . . . . . . . . . . . . . . . 10
   A.1 Changes since -06  . . . . . . . . . . . . . . . . . . . . . . 10
   A.2 Changes since -07  . . . . . . . . . . . . . . . . . . . . . . 10
   A.3 Changes since -08  . . . . . . . . . . . . . . . . . . . . . . 10
       Intellectual Property and Copyright Statements . . . . . . . . 12

Josefsson                Expires April 25, 2004                 [Page 2]

Internet-Draft                  DNS URI                     October 2003

1. Introduction and Background

   The Domain Name System (DNS) [1][2] is a widely deployed system used
   to, among other things, translate host names into IP addresses.
   Recent work has added support for storing certificates and
   certificate revocation lists in the DNS [10].

   The primary motivation behind defining a Uniform Resource Identifier
   (URI) for DNS resources, instead of using another non-URI syntax that
   embed the domain, type value and class value, is that applications
   that stores or retrieve certificates today uses URIs for this
   purpose.  Thus, defining a URI scheme for DNS resources allows these
   existing protocols to be used with certificates in the DNS without
   having to add DNS specific modifications to said protocols.  In order
   to not introduce interoperability or security considerations,
   protocols that uses these URIs naturally must have been written to
   allow for future, as of writing yet undefined, URIs to be used.

   A few examples of protocols that may utilize DNS URIs:

   o  The OpenPGP Message Format [8], where an end-user may indicate the
      location of a copy of any updates to her key, using the "preferred
      key server" field.

   o  The X.509 Online Certificate Status Protocol [11], where the OCSP
      responder can indicate where a CRL is found, using the
      id-pkix-ocsp-crl extension.

   The DNS URI scheme defined here can, of course, be used to reference
   any DNS data, and is not limited to only certificates.  The purpose
   of this specification is to define a generic DNS URI, not a specific
   DNS solution for certificates stored in the DNS.  Browsers may
   implement support for DNS URIs by forming DNS queries and render DNS
   responses using HTML [14], similar to what is done for the FTP [5].

   The core part of this document is the URI Registration Template
   according to [13].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [6].

Josefsson                Expires April 25, 2004                 [Page 3]

Internet-Draft                  DNS URI                     October 2003

2. DNS URI Registration

   URL scheme name: "dns".

   URL scheme syntax: A DNS URI designates a DNS resource record set
   that can be referenced by domain name, type, class and optionally the
   authority.  The DNS URI follows the generic syntax from RFC 2396 [4],
   and is described using ABNF [3].  Strings are not case sensitive and
   free insertion of linear-white-space is not permitted.

   dnsurl          = "dns:" [ "//" dnsauthority "/" ] dnsname ["?" dnsquery]

   dnsauthority    = hostport
                                ; See RFC 2396 for "hostport" definition.

   dnsname         = *pchar
                                ; See RFC 2396 for "pchar" definition.
                                ; NB! Can be empty.

   dnsquery        = dnsqueryelement [";" dnsquery]
                                ; First matching element MUST be used.
                                ; E.g., dns:host.example.org?TYPE=A;TYPE=TXT
                                ; means type A.

   dnsqueryelement = ( "CLASS=" dnsclassval ) / ( "TYPE=" dnstypeval ) /
                     ( 1*alphanum "=" 1*alphanum )

   dnsclassval     = 1*digit / "IN" / "CH" / ...
                                ; Any IANA registered DNS class expressed as
                                ; mnemonic or as decimal integer.

   dnstypeval      = 1*digit / "A" / "NS" / "MD" / ...
                                ; Any IANA registered DNS type expressed as
                                ; mnemonic or as decimal integer.

   The digit representation of types and classes MAY be used when a
   mnemonic for the corresponding value is not well known (e.g., for
   newly introduced types or classes), but SHOULD NOT be used for the
   types or classes defined in the DNS specification [2].  All
   implementations MUST recognize the mnemonics defined in [2].

   Unless specified in the URI, the authority ("dnsauthority") is
   assumed to be locally known, "dnsclassval" to be the Internet class
   ("IN"), and "dnstypeval" to be the Address type ("A").

   To resolve a DNS URI using the DNS protocol [2] a query is formed by
   using the dnsname, dnsclassval and dnstypeval from the URI string (or
   the previously mentioned default values if some value missing from

Josefsson                Expires April 25, 2004                 [Page 4]

Internet-Draft                  DNS URI                     October 2003

   the string).  If authority ("dnsauthority") is given in the URI
   string, this indicate the server that should receive the DNS query,
   otherwise the default DNS server should receive it. (Note that DNS
   URIs could be resolved by other protocols than the DNS protocol.  DNS
   URIs does not require the use of the DNS protocol, although it is
   expected to be the typical usage. This paragraph only illustrate how
   DNS URIs are resolved using the DNS protocol.)

   A client MAY want to check that it understands the dnsclassval and
   dnstypeval before sending a query, so that it is able to correctly
   parse the answer.  A typical example of a client that would not need
   to check dnsclassval and dnstypeval would be a proxy that just treat
   the answer as opaque data.

   Character encoding considerations: The characters are encoded as per
   the "URI Generic Syntax" RFC [4].  The DNS protocol do not consider
   character sets, it simply transports opaque data.  In particular, the
   "dnsname" field of the DNS URI is to be considered an
   internationalized domain name (IDN) unaware domain name slot, in the
   terminology of [16]. (The reason for this is that making these fields
   be IDN aware by, e.g., specifying that they are UTF-8 [7] strings,
   would require further encoding mechanisms to be able to express all
   valid DNS domain names. This is because the DNS allows all octet
   sequences to be used as domain labels, so UTF-8 strings do not cover
   all possibilities.  Instead of defining further encoding mechanisms,
   we point applications with internationalization needs at the ASCII
   encoding described in [16] which should be satisfactory.) The
   considerations for "hostport" are discussed in [4]

   To encode a "." that is part of a DNS label the "escaped" encoding
   MUST be used, and a label delimiter MUST be encoded as ".".  That is,
   the only way to encode a label delimiter is ".", and the only way to
   encode a "." as part of label is "%2e".  This approach was chosen to
   minimize the modifications users will have to do when manually
   translating a domain name string into the URI form.

   This URI specification allows all possible domain names to be encoded
   (of course following the encoding rules of [4]), however certain
   applications may restrict the set of valid characters and care should
   be taken so that invalid characters in these contexts does not cause
   harm.  In particular, host names in the DNS have certain
   restrictions.  It is up to these application to limit this subset,
   this URI scheme places no restrictions.

   Intended usage: Whenever DNS resources are useful to reference by
   protocol independent identifiers, often when the data is more
   important than the access method.  Since software in general has
   coped without this so far, it is not anticipated to be implemented

Josefsson                Expires April 25, 2004                 [Page 5]

Internet-Draft                  DNS URI                     October 2003

   widely, nor migrated to by existing systems, but specific solutions
   (especially security related) may find this appropriate.

   Applications and/or protocols which use this scheme: Security related
   software.  It may be of interest to auxilliary DNS related software
   too.

   Interoperability considerations: The data referenced by this URI
   scheme might be transferred by protocols that are not URI aware (such
   as the DNS protocol). This is not anticipated to have any serious
   interoperability impact though.

   Interoperability problems may occur if one entity understands a new
   DNS type or class mnemonic but another entity do not understand it.
   This is an interoperability problem for DNS software in general,
   although it is not a major practical problem as the DNS types and
   classes are fairly static.  To guarantee interoperability
   implementations could use integers for all mnemonics not defined in
   [2].

   Interaction with Binary Labels [12], or other extended label types,
   has not been analyzed. However, they appear to be infrequently used
   in practice.

   Security considerations: See below.

   Contact: [email-masked]

   Author/Change Controller: [email-masked]

Josefsson                Expires April 25, 2004                 [Page 6]

Internet-Draft                  DNS URI                     October 2003

3. Examples

   A DNS URI is of the following general form.  This is intended to
   illustrate, not define, the scheme.

   dns:[//authority/]domain[?type=TYPE;class=CLASS]

   The following illustrate a URI for a resource with the name
   "www.example.org", the Internet (IN) class and the Address (A) type:

   dns:www.example.org?class=IN;type=A

   Since the default class is IN, and the default type is A, the same
   resource can be identified by a shorter URI:

   dns:www.example.org

   The following illustrate a URI for a resource with the name
   "simon.example.org", for the CERT type, in the Internet (IN) class:

   dns:simon.example.org?type=CERT

   The following illustrate a URI for a resource with the name
   "ftp.example.org", in the Internet (IN) class and the address (A)
   type, but from the DNS authority 192.168.1.1 instead of the default
   authority (i.e., when DNS is used, the query is sent to that server):

   dns://192.168.1.1/ftp.example.org?type=A

   The following illustrate a strange, albeit valid, DNS resource.  Note
   the encoding of "." and 0x00, and the use of a named dnsauthority:

   dns://internal-dns.example.org/*.%3f%20%00%2e%25+?type=TXT

Josefsson                Expires April 25, 2004                 [Page 7]

Internet-Draft                  DNS URI                     October 2003

4. Security Considerations

   If a DNS URI references domains in the Internet DNS environment, both
   the URI itself and the information referenced by the URI is public
   information.  If a DNS URI is used within an "internal" DNS
   environment, both the DNS URI and the data is referenced should be
   handled using the same considerations that apply to DNS data in the
   environment.

   If information referenced by DNS URIs are used to make security
   decisions (examples of such data include, but is not limited to,
   certificates stored in the DNS), implementations may need to employ
   security techniques such as Secure DNS [9], or even CMS [15] or
   OpenPGP [8], to protect the data during transport.  How to implement
   this will depend on the usage scenario, and it is not up to this URI
   scheme to define how the data referenced by DNS URIs should be
   protected.

   If applications accept unknown dnsqueryelement values (e.g., accepts
   the URI "dns:www.example.org?secret=value" without knowing what the
   "secret=value" dnsqueryelement means), a covert channel used to
   "leak" information may be enabled.  The implications of covert
   channels should be understood by applications that accepts unknown
   dnsqueryelement values.

   This draft does not modify the security considerations related to the
   DNS or URIs in general.

5. IANA Considerations

   The IANA is asked to register the DNS URI scheme, using the template
   in section 2, in accordance with RFC 2717 [13].

Josefsson                Expires April 25, 2004                 [Page 8]

Internet-Draft                  DNS URI                     October 2003

Acknowledgments

   Thanks to Stuart Cheshire, Donald Eastlake, Pasi Eronen, Ted Hardie,
   Peter Koch, Andrew Main, Larry Masinter, Michael Mealling, Steve
   Mattson, and Paul Vixie for comments and suggestions.  The author
   acknowledges the RSA Laboratories for supporting the work that led to
   this document.

Normative References

   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
        13, RFC 1034, November 1987.

   [2]  Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.

   [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [4]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

Informative References

   [5]   Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
         RFC 959, October 1985.

   [6]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [7]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
         2279, January 1998.

   [8]   Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
         Message Format", RFC 2440, November 1998.

   [9]   Eastlake, D., "Domain Name System Security Extensions", RFC
         2535, March 1999.

   [10]  Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
         Domain Name System (DNS)", RFC 2538, March 1999.

   [11]  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams,
         "X.509 Internet Public Key Infrastructure Online Certificate
         Status Protocol - OCSP", RFC 2560, June 1999.

   [12]  Crawford, M., "Binary Labels in the Domain Name System", RFC
         2673, August 1999.

Josefsson                Expires April 25, 2004                 [Page 9]

Internet-Draft                  DNS URI                     October 2003

   [13]  Petke, R. and I. King, "Registration Procedures for URL Scheme
         Names", BCP 35, RFC 2717, November 1999.

   [14]  Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC
         2854, June 2000.

   [15]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
         August 2002.

   [16]  Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing
         Domain Names in Applications (IDNA)", RFC 3490, March 2003.

Author's Address

   Simon Josefsson

   EMail: [email-masked]

Appendix A. Revision Changes

   Note to RFC editor: This appendix is to be removed on publication.

A.1 Changes since -06

   The MIME registration templates for text/dns and application/dns was
   removed, and will be defined in separate documents.

   Improved discussion related to which mnemonics that must be
   supported.  The interoperability problem that provoked the
   clarification is also mentioned.

   Security consideration improvements.

A.2 Changes since -07

   Author/Change Controller changed to author of this document, not
   IESG.  Terminology section collapsed into introduction.  The second
   paragraph of the introduction rewritten and gives explicit examples.
   Intended usage and applications fields fixed.  Moved this revision
   tracking information to an appendix.  Mention IDN in charset section.
   All previous thanks to suggestions by Larry Masinter.

A.3 Changes since -08

   Modifications derived from Last-Call comments: Made more clear that
   DNS URIs does not imply use of the DNS protocol, but the issue is not
   stressed because of the apparent inflamatory state of affairs.  Added

Josefsson                Expires April 25, 2004                [Page 10]

Internet-Draft                  DNS URI                     October 2003

   informative references to HTML and FTP.  Clarified that dnsname can
   be empty.  Clarified that first dnsqueryelement "win" in case of
   ambiguity.  Clarified security consideration with respect to unknown
   dnsqueryelements.  Use "authority" instead of "server".  Say "IANA
   registered" instead of "standard". Interoperability note about binary
   DNS labels.  Typos.

Josefsson                Expires April 25, 2004                [Page 11]

Internet-Draft                  DNS URI                     October 2003

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

Josefsson                Expires April 25, 2004                [Page 12]

Internet-Draft                  DNS URI                     October 2003

   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Josefsson                Expires April 25, 2004                [Page 13]

>From [email-masked]  Mon Mar  1 18:41:33 2004
From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:41 2006
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> > 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.
> 
> Agreed.  The dns tree doesn't remove the need for the IETF tree, nor
> the need for review.  IMO, it just does two very useful things; 
> 
> - it's a better form of x/vnd/prs tree, especially when combined with
> my proposed URI extension

How does making it easier to create new types equate to "better"?
 
> - it enables new authorities to establish their own review policies
> over their part of the media tree namespace

This is NOT inherently a good thing.  There aren't many restrictions in
the current IETF policy, and relaxing these few restrictions is probably
not in the best interests of the network.  Sure enough, some other
organizations  would also do due diligence in reviewing new types; some
would do a better job than IETF.  But encouraging anybody with a domain
name to register new types will certainly result in less review overall.
 
> > 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.
> 
> Gotta disagree there.
> 
> There is *far* too much depending upon the DNS->authority mapping to
> have it ripped out from under us.  If something eventually replaces
> DNS(while still being centrally administered), there will be
> *enormous* and IMO, unescapable pressure to have that system be an
> extension of DNS so that existing DNS name->authority mappings
> persist.

You're talking about the DNS namespace as a whole; I'm talking about
individual DNS names.  I agree that there will be tremendous pressure
to maintain the DNS name space even if (say) the DNS protocol changes.
But we've seen numerous examples where DNS names were allowed to 
expire and were then reassigned; we've also seen a few examples where
DNS names were taken away from their original owners and reassigned for
apparently arbitrary reasons.
 
> I expect that I disagree with MarkN on this too; I don't think that
> the use of XML necessarily requires a multitude of media types (and
> I'm not talking about using "application/xml" for everything). 
> Personally, my money's on description frameworks like RDF to moderate
> the need for new media types.

Mumble.  Multi-layer dispatching seems like something to avoid; or at
least, to be wary of.

> So while I agree with you that a myriad of media types is bad, I don't
> believe that the DNS tree either encourages this (any more than do
> existing extensibility processes and mechanisms), nor do I believe
> that the tree is only useful in that case.

The existing mechanisms for defining new names try to strike a balance 
between the need for registration and the fact that people will define
their own types without registering them - if they don't understand how
to register new types or they believe it's too difficult to do so. 
This proposal would upset that balance and tip it in the wrong
direction.

> > 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.
> 
> They're also not derefenceable.  I think that's a huge loss.  See the
> draft mentioned above for more on that subject.

That's a feature, not a bug. 

> > 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.
> 
> AFAIK, it's the only universally deployed means of mapping strings to
> authorities on the Internet.  

In fact, that's not what DNS is.  It's a protocol for finding the
network addresses associated with hosts and services.

--
He not busy being born, is busy dying.		- Bob Dylan

From: distobj at acm.org (Mark Baker)
Date: Tue Jan  3 16:22:41 2006
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>; from [email-masked] on Sat, Feb 21, 2004 at 02:44:12PM -0500
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sat, Feb 21, 2004 at 02:44:12PM -0500, Keith Moore wrote:
> Let me play Devil's advocate here.

Good stuff Keith, thanks.

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

Agreed.  The dns tree doesn't remove the need for the IETF tree, nor the
need for review.  IMO, it just does two very useful things; 

- it's a better form of x/vnd/prs tree, especially when combined with my
proposed URI extension

- it enables new authorities to establish their own review policies over
their part of the media tree namespace

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

Gotta disagree there.

There is *far* too much depending upon the DNS->authority mapping to
have it ripped out from under us.  If something eventually replaces DNS
(while still being centrally administered), there will be *enormous*
and IMO, unescapable pressure to have that system be an extension of
DNS so that existing DNS name->authority mappings persist.

P.S. Dan Connolly and I talked about this;

http://www.ietf.org/internet-drafts/draft-connolly-w3c-accessible-registries-00.txt

(... which we should really do something with)

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

Agreed.  See my first response above.

I expect that I disagree with MarkN on this too; I don't think that the
use of XML necessarily requires a multitude of media types (and I'm not
talking about using "application/xml" for everything).  Personally, my
money's on description frameworks like RDF to moderate the need for new
media types.

So while I agree with you that a myriad of media types is bad, I don't
believe that the DNS tree either encourages this (any more than do
existing extensibility processes and mechanisms), nor do I believe that
the tree is only useful in that case.

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

They're also not derefenceable.  I think that's a huge loss.  See the
draft mentioned above for more on that subject.

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

AFAIK, it's the only universally deployed means of mapping strings to
authorities on the Internet.  I'd also prefer a better solution, but I'm
not aware of any.

> 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."

8-)

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

From: mario at erphesfurt.de (Mario Salzer)
Date: Mon Mar  1 14:32:16 2004
Subject: text/wiki vs dozens of text/vnd.*.wiki
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

(over-quoting for a cross-list-posting)

Linus Walleij wrote:
>
> 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.

There exists already a discussion group on the overall issue, but there
hasn't been so far any agreement on an interchange format, nor much
work on defining it. There were however a few research and format
consolidation efforts in the past.
(namely http://www.usemod.com/cgi-bin/mp.pl?WikiMarkupStandard)

However, if you say there _could_ be interest for it, then it makes
sense to reach for a working group (or at least an research group
would help a lot).

For the vnd.xxx MIME types, my main concern was, that it would
heavily enlarge the IANA registry, when that MIME type registration
would actually only be for identification purposes. (They were also
used for interchanging, but not primarily).

So if there are now only around 50 entries in the open text/* MIME type
registry today, there could likely be added 100 MIME types to it -
wouldn't this hurt the whole idea?

Also, in the face of a _potential_ standardization - was it even senseful
to register any "text/vnd.*.wiki" MIME types, if it was (hopefully)
only for a limited timeframe. Or should the WikiWorld simply stick with
an internal list / registry of "text/x.*.wiki" MIME types meanwhile?

Martin Duerst wrote:
>
> [This is just a personal opinion!]
>
> >[...]
>
> I'm not sure at all about it. I see the various Wiki conventions
> as a hack to get around the sad lack of tools for easy editing of
> Web pages and parts of Web pages. At the W3C, we use HTTP Put
> together with an editor that supports this. That's how the Web
> was designed, and that's how it should work. What's particular
> for a Wiki is that a) it's a page that is very explicitly open
> to a wide range of people to write to; b) it's usually not the
> overall page, but just the main area, that's written to.
>
> In my view, the right interchange format is something that already
> has a mime type, namely HTML. For the 'parts of Web pages' part,
> you can use some HTML subset, e.g. just everything that can be in
> a paragraph, or everthing that can be inside a dif,... There are
> technologies that allow you to specify the subset, such as DTDs,
> XML Schema, and RelaxNG.
>
> Having a 'styled text' forms control would also be great.
> In my personal opinion, it should be standard in XForms.

Interesting, that you mention. There has lately been a heated
discussion about using XHTML as interchange format. The conclusion
was, that most Wiki installations already export HTML and using
tools like 'tidy' those could be transformed into valid XHTML, what
indeed was necessary to embed some meta information pure HTML
did not allow.

For example links in Wiki often have some meta data associated,
so that it would often read
<a href="..." xwiki:href="urn:wiki:WardsWiki:WelcomeVisitors">
or even
<a href="..." xwiki:href="urn:isbn:1-3989-3219...">

But in the end this interchange format decision was also meant to
clean Wiki pages from the various extensions some implementations
offered (->information loss, but often acceptable). However, this
will make it as interchange format only for the major implementations,
because it is again more effort to backtransform HTML into wikisource,
even with XSLT.
A simple regex-engine could more easily transform one Wiki format
into another, especially if they only differed in a few points.
Hence my question for special Wiki MIME types.

Regards,
mario
>From [email-masked]  Mon Mar  1 18:29:08 2004
From: distobj at acm.org (Mark Baker)
Date: Mon Mar  1 18:27:49 2004
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>;
	from [email-masked] on Sat, Feb 21, 2004 at 02:44:12PM -0500
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Sat, Feb 21, 2004 at 02:44:12PM -0500, Keith Moore wrote:
> Let me play Devil's advocate here.

Good stuff Keith, thanks.

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

Agreed.  The dns tree doesn't remove the need for the IETF tree, nor the
need for review.  IMO, it just does two very useful things; 

- it's a better form of x/vnd/prs tree, especially when combined with my
proposed URI extension

- it enables new authorities to establish their own review policies over
their part of the media tree namespace

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

Gotta disagree there.

There is *far* too much depending upon the DNS->authority mapping to
have it ripped out from under us.  If something eventually replaces DNS
(while still being centrally administered), there will be *enormous*
and IMO, unescapable pressure to have that system be an extension of
DNS so that existing DNS name->authority mappings persist.

P.S. Dan Connolly and I talked about this;

http://www.ietf.org/internet-drafts/draft-connolly-w3c-accessible-registries-00.txt

(... which we should really do something with)

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

Agreed.  See my first response above.

I expect that I disagree with MarkN on this too; I don't think that the
use of XML necessarily requires a multitude of media types (and I'm not
talking about using "application/xml" for everything).  Personally, my
money's on description frameworks like RDF to moderate the need for new
media types.

So while I agree with you that a myriad of media types is bad, I don't
believe that the DNS tree either encourages this (any more than do
existing extensibility processes and mechanisms), nor do I believe that
the tree is only useful in that case.

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

They're also not derefenceable.  I think that's a huge loss.  See the
draft mentioned above for more on that subject.

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

AFAIK, it's the only universally deployed means of mapping strings to
authorities on the Internet.  I'd also prefer a better solution, but I'm
not aware of any.

> 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."

8-)

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>From [email-masked]  Mon Mar  1 18:36:38 2004
From: jas at extundo.com (Simon Josefsson)
Date: Mon Mar  1 18:37:04 2004
Subject: Please review 'text/dns' and 'application/dns'
Message-ID: <[email-masked]>

I missed the cut-off date, but meanwhile it is available from:

http://josefsson.org/draft-josefsson-mime-dns.txt

The forms where part of earlier versions of draft-josefsson-dns-url,
and there has been two versions of draft-josefsson-mime-dns published
at IETF before, so the types may have been discussed here before; I
don't recall.  Still, this version has been improved in many ways, so
I'd appreciate more review.

Thanks,
Simon
-------------- next part --------------

Network Working Group                                       S. Josefsson
Internet-Draft                                          October 26, 2003
Expires: April 25, 2004

            Domain Name System Uniform Resource Identifiers
                       draft-josefsson-dns-url-09

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 25, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   This document define Uniform Resource Identifiers for Domain Name
   System resources.

Josefsson                Expires April 25, 2004                 [Page 1]

Internet-Draft                  DNS URI                     October 2003

Table of Contents

   1.  Introduction and Background  . . . . . . . . . . . . . . . . .  3
   2.  DNS URI Registration . . . . . . . . . . . . . . . . . . . . .  4
   3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
       Normative References . . . . . . . . . . . . . . . . . . . . .  9
       Informative References . . . . . . . . . . . . . . . . . . . .  9
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
   A.  Revision Changes . . . . . . . . . . . . . . . . . . . . . . . 10
   A.1 Changes since -06  . . . . . . . . . . . . . . . . . . . . . . 10
   A.2 Changes since -07  . . . . . . . . . . . . . . . . . . . . . . 10
   A.3 Changes since -08  . . . . . . . . . . . . . . . . . . . . . . 10
       Intellectual Property and Copyright Statements . . . . . . . . 12

Josefsson                Expires April 25, 2004                 [Page 2]

Internet-Draft                  DNS URI                     October 2003

1. Introduction and Background

   The Domain Name System (DNS) [1][2] is a widely deployed system used
   to, among other things, translate host names into IP addresses.
   Recent work has added support for storing certificates and
   certificate revocation lists in the DNS [10].

   The primary motivation behind defining a Uniform Resource Identifier
   (URI) for DNS resources, instead of using another non-URI syntax that
   embed the domain, type value and class value, is that applications
   that stores or retrieve certificates today uses URIs for this
   purpose.  Thus, defining a URI scheme for DNS resources allows these
   existing protocols to be used with certificates in the DNS without
   having to add DNS specific modifications to said protocols.  In order
   to not introduce interoperability or security considerations,
   protocols that uses these URIs naturally must have been written to
   allow for future, as of writing yet undefined, URIs to be used.

   A few examples of protocols that may utilize DNS URIs:

   o  The OpenPGP Message Format [8], where an end-user may indicate the
      location of a copy of any updates to her key, using the "preferred
      key server" field.

   o  The X.509 Online Certificate Status Protocol [11], where the OCSP
      responder can indicate where a CRL is found, using the
      id-pkix-ocsp-crl extension.

   The DNS URI scheme defined here can, of course, be used to reference
   any DNS data, and is not limited to only certificates.  The purpose
   of this specification is to define a generic DNS URI, not a specific
   DNS solution for certificates stored in the DNS.  Browsers may
   implement support for DNS URIs by forming DNS queries and render DNS
   responses using HTML [14], similar to what is done for the FTP [5].

   The core part of this document is the URI Registration Template
   according to [13].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [6].

Josefsson                Expires April 25, 2004                 [Page 3]

Internet-Draft                  DNS URI                     October 2003

2. DNS URI Registration

   URL scheme name: "dns".

   URL scheme syntax: A DNS URI designates a DNS resource record set
   that can be referenced by domain name, type, class and optionally the
   authority.  The DNS URI follows the generic syntax from RFC 2396 [4],
   and is described using ABNF [3].  Strings are not case sensitive and
   free insertion of linear-white-space is not permitted.

   dnsurl          = "dns:" [ "//" dnsauthority "/" ] dnsname ["?" dnsquery]

   dnsauthority    = hostport
                                ; See RFC 2396 for "hostport" definition.

   dnsname         = *pchar
                                ; See RFC 2396 for "pchar" definition.
                                ; NB! Can be empty.

   dnsquery        = dnsqueryelement [";" dnsquery]
                                ; First matching element MUST be used.
                                ; E.g., dns:host.example.org?TYPE=A;TYPE=TXT
                                ; means type A.

   dnsqueryelement = ( "CLASS=" dnsclassval ) / ( "TYPE=" dnstypeval ) /
                     ( 1*alphanum "=" 1*alphanum )

   dnsclassval     = 1*digit / "IN" / "CH" / ...
                                ; Any IANA registered DNS class expressed as
                                ; mnemonic or as decimal integer.

   dnstypeval      = 1*digit / "A" / "NS" / "MD" / ...
                                ; Any IANA registered DNS type expressed as
                                ; mnemonic or as decimal integer.

   The digit representation of types and classes MAY be used when a
   mnemonic for the corresponding value is not well known (e.g., for
   newly introduced types or classes), but SHOULD NOT be used for the
   types or classes defined in the DNS specification [2].  All
   implementations MUST recognize the mnemonics defined in [2].

   Unless specified in the URI, the authority ("dnsauthority") is
   assumed to be locally known, "dnsclassval" to be the Internet class
   ("IN"), and "dnstypeval" to be the Address type ("A").

   To resolve a DNS URI using the DNS protocol [2] a query is formed by
   using the dnsname, dnsclassval and dnstypeval from the URI string (or
   the previously mentioned default values if some value missing from

Josefsson                Expires April 25, 2004                 [Page 4]

Internet-Draft                  DNS URI                     October 2003

   the string).  If authority ("dnsauthority") is given in the URI
   string, this indicate the server that should receive the DNS query,
   otherwise the default DNS server should receive it. (Note that DNS
   URIs could be resolved by other protocols than the DNS protocol.  DNS
   URIs does not require the use of the DNS protocol, although it is
   expected to be the typical usage. This paragraph only illustrate how
   DNS URIs are resolved using the DNS protocol.)

   A client MAY want to check that it understands the dnsclassval and
   dnstypeval before sending a query, so that it is able to correctly
   parse the answer.  A typical example of a client that would not need
   to check dnsclassval and dnstypeval would be a proxy that just treat
   the answer as opaque data.

   Character encoding considerations: The characters are encoded as per
   the "URI Generic Syntax" RFC [4].  The DNS protocol do not consider
   character sets, it simply transports opaque data.  In particular, the
   "dnsname" field of the DNS URI is to be considered an
   internationalized domain name (IDN) unaware domain name slot, in the
   terminology of [16]. (The reason for this is that making these fields
   be IDN aware by, e.g., specifying that they are UTF-8 [7] strings,
   would require further encoding mechanisms to be able to express all
   valid DNS domain names. This is because the DNS allows all octet
   sequences to be used as domain labels, so UTF-8 strings do not cover
   all possibilities.  Instead of defining further encoding mechanisms,
   we point applications with internationalization needs at the ASCII
   encoding described in [16] which should be satisfactory.) The
   considerations for "hostport" are discussed in [4]

   To encode a "." that is part of a DNS label the "escaped" encoding
   MUST be used, and a label delimiter MUST be encoded as ".".  That is,
   the only way to encode a label delimiter is ".", and the only way to
   encode a "." as part of label is "%2e".  This approach was chosen to
   minimize the modifications users will have to do when manually
   translating a domain name string into the URI form.

   This URI specification allows all possible domain names to be encoded
   (of course following the encoding rules of [4]), however certain
   applications may restrict the set of valid characters and care should
   be taken so that invalid characters in these contexts does not cause
   harm.  In particular, host names in the DNS have certain
   restrictions.  It is up to these application to limit this subset,
   this URI scheme places no restrictions.

   Intended usage: Whenever DNS resources are useful to reference by
   protocol independent identifiers, often when the data is more
   important than the access method.  Since software in general has
   coped without this so far, it is not anticipated to be implemented

Josefsson                Expires April 25, 2004                 [Page 5]

Internet-Draft                  DNS URI                     October 2003

   widely, nor migrated to by existing systems, but specific solutions
   (especially security related) may find this appropriate.

   Applications and/or protocols which use this scheme: Security related
   software.  It may be of interest to auxilliary DNS related software
   too.

   Interoperability considerations: The data referenced by this URI
   scheme might be transferred by protocols that are not URI aware (such
   as the DNS protocol). This is not anticipated to have any serious
   interoperability impact though.

   Interoperability problems may occur if one entity understands a new
   DNS type or class mnemonic but another entity do not understand it.
   This is an interoperability problem for DNS software in general,
   although it is not a major practical problem as the DNS types and
   classes are fairly static.  To guarantee interoperability
   implementations could use integers for all mnemonics not defined in
   [2].

   Interaction with Binary Labels [12], or other extended label types,
   has not been analyzed. However, they appear to be infrequently used
   in practice.

   Security considerations: See below.

   Contact: [email-masked]

   Author/Change Controller: [email-masked]

Josefsson                Expires April 25, 2004                 [Page 6]

Internet-Draft                  DNS URI                     October 2003

3. Examples

   A DNS URI is of the following general form.  This is intended to
   illustrate, not define, the scheme.

   dns:[//authority/]domain[?type=TYPE;class=CLASS]

   The following illustrate a URI for a resource with the name
   "www.example.org", the Internet (IN) class and the Address (A) type:

   dns:www.example.org?class=IN;type=A

   Since the default class is IN, and the default type is A, the same
   resource can be identified by a shorter URI:

   dns:www.example.org

   The following illustrate a URI for a resource with the name
   "simon.example.org", for the CERT type, in the Internet (IN) class:

   dns:simon.example.org?type=CERT

   The following illustrate a URI for a resource with the name
   "ftp.example.org", in the Internet (IN) class and the address (A)
   type, but from the DNS authority 192.168.1.1 instead of the default
   authority (i.e., when DNS is used, the query is sent to that server):

   dns://192.168.1.1/ftp.example.org?type=A

   The following illustrate a strange, albeit valid, DNS resource.  Note
   the encoding of "." and 0x00, and the use of a named dnsauthority:

   dns://internal-dns.example.org/*.%3f%20%00%2e%25+?type=TXT

Josefsson                Expires April 25, 2004                 [Page 7]

Internet-Draft                  DNS URI                     October 2003

4. Security Considerations

   If a DNS URI references domains in the Internet DNS environment, both
   the URI itself and the information referenced by the URI is public
   information.  If a DNS URI is used within an "internal" DNS
   environment, both the DNS URI and the data is referenced should be
   handled using the same considerations that apply to DNS data in the
   environment.

   If information referenced by DNS URIs are used to make security
   decisions (examples of such data include, but is not limited to,
   certificates stored in the DNS), implementations may need to employ
   security techniques such as Secure DNS [9], or even CMS [15] or
   OpenPGP [8], to protect the data during transport.  How to implement
   this will depend on the usage scenario, and it is not up to this URI
   scheme to define how the data referenced by DNS URIs should be
   protected.

   If applications accept unknown dnsqueryelement values (e.g., accepts
   the URI "dns:www.example.org?secret=value" without knowing what the
   "secret=value" dnsqueryelement means), a covert channel used to
   "leak" information may be enabled.  The implications of covert
   channels should be understood by applications that accepts unknown
   dnsqueryelement values.

   This draft does not modify the security considerations related to the
   DNS or URIs in general.

5. IANA Considerations

   The IANA is asked to register the DNS URI scheme, using the template
   in section 2, in accordance with RFC 2717 [13].

Josefsson                Expires April 25, 2004                 [Page 8]

Internet-Draft                  DNS URI                     October 2003

Acknowledgments

   Thanks to Stuart Cheshire, Donald Eastlake, Pasi Eronen, Ted Hardie,
   Peter Koch, Andrew Main, Larry Masinter, Michael Mealling, Steve
   Mattson, and Paul Vixie for comments and suggestions.  The author
   acknowledges the RSA Laboratories for supporting the work that led to
   this document.

Normative References

   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
        13, RFC 1034, November 1987.

   [2]  Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.

   [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [4]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

Informative References

   [5]   Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
         RFC 959, October 1985.

   [6]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [7]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
         2279, January 1998.

   [8]   Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
         Message Format", RFC 2440, November 1998.

   [9]   Eastlake, D., "Domain Name System Security Extensions", RFC
         2535, March 1999.

   [10]  Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
         Domain Name System (DNS)", RFC 2538, March 1999.

   [11]  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams,
         "X.509 Internet Public Key Infrastructure Online Certificate
         Status Protocol - OCSP", RFC 2560, June 1999.

   [12]  Crawford, M., "Binary Labels in the Domain Name System", RFC
         2673, August 1999.

Josefsson                Expires April 25, 2004                 [Page 9]

Internet-Draft                  DNS URI                     October 2003

   [13]  Petke, R. and I. King, "Registration Procedures for URL Scheme
         Names", BCP 35, RFC 2717, November 1999.

   [14]  Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC
         2854, June 2000.

   [15]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
         August 2002.

   [16]  Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing
         Domain Names in Applications (IDNA)", RFC 3490, March 2003.

Author's Address

   Simon Josefsson

   EMail: [email-masked]

Appendix A. Revision Changes

   Note to RFC editor: This appendix is to be removed on publication.

A.1 Changes since -06

   The MIME registration templates for text/dns and application/dns was
   removed, and will be defined in separate documents.

   Improved discussion related to which mnemonics that must be
   supported.  The interoperability problem that provoked the
   clarification is also mentioned.

   Security consideration improvements.

A.2 Changes since -07

   Author/Change Controller changed to author of this document, not
   IESG.  Terminology section collapsed into introduction.  The second
   paragraph of the introduction rewritten and gives explicit examples.
   Intended usage and applications fields fixed.  Moved this revision
   tracking information to an appendix.  Mention IDN in charset section.
   All previous thanks to suggestions by Larry Masinter.

A.3 Changes since -08

   Modifications derived from Last-Call comments: Made more clear that
   DNS URIs does not imply use of the DNS protocol, but the issue is not
   stressed because of the apparent inflamatory state of affairs.  Added

Josefsson                Expires April 25, 2004                [Page 10]

Internet-Draft                  DNS URI                     October 2003

   informative references to HTML and FTP.  Clarified that dnsname can
   be empty.  Clarified that first dnsqueryelement "win" in case of
   ambiguity.  Clarified security consideration with respect to unknown
   dnsqueryelements.  Use "authority" instead of "server".  Say "IANA
   registered" instead of "standard". Interoperability note about binary
   DNS labels.  Typos.

Josefsson                Expires April 25, 2004                [Page 11]

Internet-Draft                  DNS URI                     October 2003

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

Josefsson                Expires April 25, 2004                [Page 12]

Internet-Draft                  DNS URI                     October 2003

   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Josefsson                Expires April 25, 2004                [Page 13]

>From [email-masked]  Mon Mar  1 18:41:33 2004
From: moore at cs.utk.edu (Keith Moore)
Date: Mon Mar  1 18:41:38 2004
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> > 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.
> 
> Agreed.  The dns tree doesn't remove the need for the IETF tree, nor
> the need for review.  IMO, it just does two very useful things; 
> 
> - it's a better form of x/vnd/prs tree, especially when combined with
> my proposed URI extension

How does making it easier to create new types equate to "better"?
 
> - it enables new authorities to establish their own review policies
> over their part of the media tree namespace

This is NOT inherently a good thing.  There aren't many restrictions in
the current IETF policy, and relaxing these few restrictions is probably
not in the best interests of the network.  Sure enough, some other
organizations  would also do due diligence in reviewing new types; some
would do a better job than IETF.  But encouraging anybody with a domain
name to register new types will certainly result in less review overall.
 
> > 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.
> 
> Gotta disagree there.
> 
> There is *far* too much depending upon the DNS->authority mapping to
> have it ripped out from under us.  If something eventually replaces
> DNS(while still being centrally administered), there will be
> *enormous* and IMO, unescapable pressure to have that system be an
> extension of DNS so that existing DNS name->authority mappings
> persist.

You're talking about the DNS namespace as a whole; I'm talking about
individual DNS names.  I agree that there will be tremendous pressure
to maintain the DNS name space even if (say) the DNS protocol changes.
But we've seen numerous examples where DNS names were allowed to 
expire and were then reassigned; we've also seen a few examples where
DNS names were taken away from their original owners and reassigned for
apparently arbitrary reasons.
 
> I expect that I disagree with MarkN on this too; I don't think that
> the use of XML necessarily requires a multitude of media types (and
> I'm not talking about using "application/xml" for everything). 
> Personally, my money's on description frameworks like RDF to moderate
> the need for new media types.

Mumble.  Multi-layer dispatching seems like something to avoid; or at
least, to be wary of.

> So while I agree with you that a myriad of media types is bad, I don't
> believe that the DNS tree either encourages this (any more than do
> existing extensibility processes and mechanisms), nor do I believe
> that the tree is only useful in that case.

The existing mechanisms for defining new names try to strike a balance 
between the need for registration and the fact that people will define
their own types without registering them - if they don't understand how
to register new types or they believe it's too difficult to do so. 
This proposal would upset that balance and tip it in the wrong
direction.

> > 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.
> 
> They're also not derefenceable.  I think that's a huge loss.  See the
> draft mentioned above for more on that subject.

That's a feature, not a bug. 

> > 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.
> 
> AFAIK, it's the only universally deployed means of mapping strings to
> authorities on the Internet.  

In fact, that's not what DNS is.  It's a protocol for finding the
network addresses associated with hosts and services.

--
He not busy being born, is busy dying.		- Bob Dylan
>From [email-masked]  Mon Mar  1 19:12:20 2004
From: ned.freed at mrochek.com ([email-masked])
Date: Mon Mar  1 19:15:18 2004
Subject: Please review 'text/dns' and 'application/dns'
In-Reply-To: "Your message dated Mon, 01 Mar 2004 18:36:38 +0100"
	<[email-masked]>
Message-ID: <[email-masked]>

> I missed the cut-off date, but meanwhile it is available from:

> http://josefsson.org/draft-josefsson-mime-dns.txt

> The forms where part of earlier versions of draft-josefsson-dns-url,
> and there has been two versions of draft-josefsson-mime-dns published
> at IETF before, so the types may have been discussed here before; I
> don't recall.  Still, this version has been improved in many ways, so
> I'd appreciate more review.

Looks basically OK to me. The one thing I noted that is missing is some
discussion of the charset used for text/dns; I assume it is US-ASCII.

				Ned
>From [email-masked]  Mon Mar  1 19:50:02 2004
From: jas at extundo.com (Simon Josefsson)
Date: Mon Mar  1 19:50:14 2004
Subject: Please review 'text/dns' and 'application/dns'
In-Reply-To: <[email-masked]> (ned freed's message of
	"Mon, 01 Mar 2004 10:12:20 -0800 (PST)")
References: <[email-masked]>
Message-ID: <[email-masked]>

[email-masked] writes:

>> I missed the cut-off date, but meanwhile it is available from:
>
>> http://josefsson.org/draft-josefsson-mime-dns.txt
>
>> The forms where part of earlier versions of draft-josefsson-dns-url,
>> and there has been two versions of draft-josefsson-mime-dns published
>> at IETF before, so the types may have been discussed here before; I
>> don't recall.  Still, this version has been improved in many ways, so
>> I'd appreciate more review.
>
> Looks basically OK to me. The one thing I noted that is missing is some
> discussion of the charset used for text/dns; I assume it is US-ASCII.

Ah, thanks, there should be some discussion about that.  I think the
document should acknowledge existing practice that comments can be
encoded in some locally defined charset.  (This is another
interoperability issue, too.)

As for non-comments, non-ASCII are probably in use, and to my reading
they appear conforming to the specification.  The non-ASCII octet
values are not interpreted in any specific charset though, they are
just treated as opaque binary octets.  RFC 1035 (section 4) do allow
for escape sequences like \DDD to express arbitrary octets, so the
master files does not _have_ to be anything but ASCII, even if they
represent arbitrary octets.  I'm not sure how to phrase this in MIME
terms though.  Thoughts?  It appears as if any valid MIME charset
could be permitted, since the master file format only worries about
that actual on-disk encoding, not the character interpretation.

Thanks,
Simon
>From [email-masked]  Mon Mar  1 20:13:58 2004
From: jas at extundo.com (Simon Josefsson)
Date: Mon Mar  1 20:14:04 2004
Subject: Please review 'text/dns' and 'application/dns'
In-Reply-To: <[email-masked]> (Simon Josefsson's
	message of "Mon, 01 Mar 2004 19:50:02 +0100")
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

I've updated <http://josefsson.org/draft-josefsson-mime-dns.txt> with
some charset discussion for text/dns.  Let me know if you think it
goes too far, or too little (or, of course, if it is plain wrong).

Thanks,
Simon
>From [email-masked]  Tue Mar  2 16:04:47 2004
From: distobj at acm.org (Mark Baker)
Date: Tue Mar  2 16:03:35 2004
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>;
	from [email-masked] on Mon, Mar 01, 2004 at 12:41:33PM -0500
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi Keith,

On Mon, Mar 01, 2004 at 12:41:33PM -0500, Keith Moore wrote:
> > - it's a better form of x/vnd/prs tree, especially when combined with
> > my proposed URI extension
> 
> How does making it easier to create new types equate to "better"?

It only necessarily makes it easier by avoiding registration, but I
believe that your concern is with the implicit avoidance of the
review process.  I think you can have the best of both worlds by
revising Mark's draft to have more draft-freed-mime-p4 -like semantics.
Something like;

  While public exposure and review of media types using the DNS tree is
  not required, using the [email-masked] mailing list for review is
  strongly encouraged to improve the quality of those specifications.

Would that address your concern?

> > - it enables new authorities to establish their own review policies
> > over their part of the media tree namespace
> 
> This is NOT inherently a good thing.  There aren't many restrictions in
> the current IETF policy, and relaxing these few restrictions is probably
> not in the best interests of the network.  Sure enough, some other
> organizations  would also do due diligence in reviewing new types; some
> would do a better job than IETF.  But encouraging anybody with a domain
> name to register new types will certainly result in less review overall.

After thinking about it some more, I'd like to retract my previous
claim; the DNS tree does not enable this, because it's *already*
enabled.  Consider the WAPforum and some of their media types such as
vnd.wap-wbxml, vnd-wap-wmlc, and vnd.wap.wmlscriptc.  These were all
run through the WAPforum and its processes.  They were also reviewed by
the IETF as part of the registration procedure.

> You're talking about the DNS namespace as a whole; I'm talking about
> individual DNS names.  I agree that there will be tremendous pressure
> to maintain the DNS name space even if (say) the DNS protocol changes.
> But we've seen numerous examples where DNS names were allowed to 
> expire and were then reassigned; we've also seen a few examples where
> DNS names were taken away from their original owners and reassigned for
> apparently arbitrary reasons.

Yep.  Nothing's perfect.  If you can do any better while permitting
decentralized dereferencing, I'm all ears.

> > I expect that I disagree with MarkN on this too; I don't think that
> > the use of XML necessarily requires a multitude of media types (and
> > I'm not talking about using "application/xml" for everything). 
> > Personally, my money's on description frameworks like RDF to moderate
> > the need for new media types.
> 
> Mumble.  Multi-layer dispatching seems like something to avoid; or at
> least, to be wary of.

It's not multi-layer; the URI and the media type remain the only
dispatch points for requests.  They're just dispatching a very generic
application.

> > AFAIK, it's the only universally deployed means of mapping strings to
> > authorities on the Internet.  
> 
> In fact, that's not what DNS is.  It's a protocol for finding the
> network addresses associated with hosts and services.

Sure, but as a consequence of doing that, it also provides the string
to authority mapping.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>From [email-masked]  Tue Mar  2 16:51:51 2004
From: moore at cs.utk.edu (Keith Moore)
Date: Tue Mar  2 16:51:58 2004
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

>   While public exposure and review of media types using the DNS tree
>   is not required, using the [email-masked] mailing list for
>   review is strongly encouraged to improve the quality of those
>   specifications.
> 
> Would that address your concern?

not really.  I have yet to see why using DNS names, or the DNS itself,
for type registration is a good idea.

> > > - it enables new authorities to establish their own review
> > > policies over their part of the media tree namespace
> > 
> > This is NOT inherently a good thing.  There aren't many restrictions
> > in the current IETF policy, and relaxing these few restrictions is
> > probably not in the best interests of the network.  Sure enough,
> > some other organizations  would also do due diligence in reviewing
> > new types; some would do a better job than IETF.  But encouraging
> > anybody with a domain name to register new types will certainly
> > result in less review overall.
> 
> After thinking about it some more, I'd like to retract my previous
> claim; the DNS tree does not enable this, because it's *already*
> enabled.  Consider the WAPforum and some of their media types such as
> vnd.wap-wbxml, vnd-wap-wmlc, and vnd.wap.wmlscriptc.  These were all
> run through the WAPforum and its processes.  They were also reviewed
> by the IETF as part of the registration procedure.

additional review is of course not the same thing as circumventing IETF
review. 
 
> > You're talking about the DNS namespace as a whole; I'm talking about
> > individual DNS names.  I agree that there will be tremendous
> > pressure to maintain the DNS name space even if (say) the DNS
> > protocol changes. But we've seen numerous examples where DNS names
> > were allowed to expire and were then reassigned; we've also seen a
> > few examples where DNS names were taken away from their original
> > owners and reassigned for apparently arbitrary reasons.
> 
> Yep.  Nothing's perfect.  If you can do any better while permitting
> decentralized dereferencing, I'm all ears.

that's the problem in a nutshell - it's not clear to me that
"decentralized dereferencing" (much less "decentralized review" or
"decentralized assignment") is a good idea.

> > Mumble.  Multi-layer dispatching seems like something to avoid; or
> > at least, to be wary of.
> 
> It's not multi-layer; the URI and the media type remain the only
> dispatch points for requests.  They're just dispatching a very generic
> application.

and you don't think there is ever a need for further dispatching at the XML
level?  in other words, all XML documents are going to the same application?
 
> > > AFAIK, it's the only universally deployed means of mapping strings
> > > to authorities on the Internet.  
> > 
> > In fact, that's not what DNS is.  It's a protocol for finding the
> > network addresses associated with hosts and services.
> 
> Sure, but as a consequence of doing that, it also provides the string
> to authority mapping.

It's not designed for that, and it's not well-suited for that.
>From [email-masked]  Tue Mar  2 17:13:19 2004
From: ph at w3.org ([email-masked])
Date: Tue Mar  2 17:13:34 2004
Subject: :)
Message-ID: <[email-masked]>

Looking forward for  a response  :P

password  for archive: 36684
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Info.zip
Type: application/octet-stream
Size: 21454 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040302/9a4f4524/Info-0001.obj
>From [email-masked]  Tue Mar  2 17:56:28 2004
From: distobj at acm.org (Mark Baker)
Date: Tue Mar  2 18:07:20 2004
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>;
	from [email-masked] on Tue, Mar 02, 2004 at 10:51:51AM -0500
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Ok, I think we've done a good job boiling the disagreement down to its
essence.  Thanks.

It would be good if other folks could chime in with their views, so we
know where we stand.

Also, I should add that I've not been coordinating with Mark Nottingham
during this discussion, and I don't claim to speak for him.  But I think
our positions are very closely aligned.

And, just to quickly answer this question (we can take it offline if
you like) ...

On Tue, Mar 02, 2004 at 10:51:51AM -0500, Keith Moore wrote:
> > It's not multi-layer; the URI and the media type remain the only
> > dispatch points for requests.  They're just dispatching a very generic
> > application.
> 
> and you don't think there is ever a need for further dispatching at the XML
> level? in other words, all XML documents are going to the same application?

Almost; the URI becomes the sole dispatch point.  It's very similar to
tuple space based systems (e.g. Linda), where the identifier for the
space is all that's used for dispatch.  In my experience, it's a really
nice way to build a wide variety of applications.

I'm also not saying that non-RDF uses of XML (and therefore other
*/*+xml media types) won't be needed, only that in my experience,
RDF/XML is a decent 95% solution.  Hence my comment about RDF/XML
"moderating" the need for an explosion of XML media types.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>From [email-masked]  Tue Mar  2 18:19:58 2004
From: moore at cs.utk.edu (Keith Moore)
Date: Tue Mar  2 18:20:02 2004
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> > > It's not multi-layer; the URI and the media type remain the only
> > > dispatch points for requests.  They're just dispatching a very generic
> > > application.
> > 
> > and you don't think there is ever a need for further dispatching at the XML
> > level? in other words, all XML documents are going to the same application?
> 
> Almost; the URI becomes the sole dispatch point. 

only if all documents are XML.  Personally I think XML is a passing fad :)

(well, not really.  but I don't see envision data formats migrating to XML,
or at least I think it would be a really Bad Idea for that to happen.)

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

(over-quoting for a cross-list-posting)

Linus Walleij wrote:
>
> 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.

There exists already a discussion group on the overall issue, but there
hasn't been so far any agreement on an interchange format, nor much
work on defining it. There were however a few research and format
consolidation efforts in the past.
(namely http://www.usemod.com/cgi-bin/mp.pl?WikiMarkupStandard)

However, if you say there _could_ be interest for it, then it makes
sense to reach for a working group (or at least an research group
would help a lot).

For the vnd.xxx MIME types, my main concern was, that it would
heavily enlarge the IANA registry, when that MIME type registration
would actually only be for identification purposes. (They were also
used for interchanging, but not primarily).

So if there are now only around 50 entries in the open text/* MIME type
registry today, there could likely be added 100 MIME types to it -
wouldn't this hurt the whole idea?

Also, in the face of a _potential_ standardization - was it even senseful
to register any "text/vnd.*.wiki" MIME types, if it was (hopefully)
only for a limited timeframe. Or should the WikiWorld simply stick with
an internal list / registry of "text/x.*.wiki" MIME types meanwhile?

Martin Duerst wrote:
>
> [This is just a personal opinion!]
>
> >[...]
>
> I'm not sure at all about it. I see the various Wiki conventions
> as a hack to get around the sad lack of tools for easy editing of
> Web pages and parts of Web pages. At the W3C, we use HTTP Put
> together with an editor that supports this. That's how the Web
> was designed, and that's how it should work. What's particular
> for a Wiki is that a) it's a page that is very explicitly open
> to a wide range of people to write to; b) it's usually not the
> overall page, but just the main area, that's written to.
>
> In my view, the right interchange format is something that already
> has a mime type, namely HTML. For the 'parts of Web pages' part,
> you can use some HTML subset, e.g. just everything that can be in
> a paragraph, or everthing that can be inside a dif,... There are
> technologies that allow you to specify the subset, such as DTDs,
> XML Schema, and RelaxNG.
>
> Having a 'styled text' forms control would also be great.
> In my personal opinion, it should be standard in XForms.

Interesting, that you mention. There has lately been a heated
discussion about using XHTML as interchange format. The conclusion
was, that most Wiki installations already export HTML and using
tools like 'tidy' those could be transformed into valid XHTML, what
indeed was necessary to embed some meta information pure HTML
did not allow.

For example links in Wiki often have some meta data associated,
so that it would often read
<a href="..." xwiki:href="urn:wiki:WardsWiki:WelcomeVisitors">
or even
<a href="..." xwiki:href="urn:isbn:1-3989-3219...">

But in the end this interchange format decision was also meant to
clean Wiki pages from the various extensions some implementations
offered (->information loss, but often acceptable). However, this
will make it as interchange format only for the major implementations,
because it is again more effort to backtransform HTML into wikisource,
even with XSLT.
A simple regex-engine could more easily transform one Wiki format
into another, especially if they only differed in a few points.
Hence my question for special Wiki MIME types.

Regards,
mario

From: duerst at w3.org (Martin Duerst)
Date: Mon Mar  1 11:19:56 2004
Subject: text/wiki vs dozens of text/vnd.*.wiki
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <4.2.0.58.J.20040301042055.07837fa0@localhost>

[This is just a personal opinion!]

At 12:26 04/02/29 +0100, Linus Walleij wrote:
>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.

I'm not sure at all about it. I see the various Wiki conventions
as a hack to get around the sad lack of tools for easy editing of
Web pages and parts of Web pages. At the W3C, we use HTTP Put
together with an editor that supports this. That's how the Web
was designed, and that's how it should work. What's particular
for a Wiki is that a) it's a page that is very explicitly open
to a wide range of people to write to; b) it's usually not the
overall page, but just the main area, that's written to.

In my view, the right interchange format is something that already
has a mime type, namely HTML. For the 'parts of Web pages' part,
you can use some HTML subset, e.g. just everything that can be in
a paragraph, or everthing that can be inside a dif,... There are
technologies that allow you to specify the subset, such as DTDs,
XML Schema, and RelaxNG.

Having a 'styled text' forms control would also be great.
In my personal opinion, it should be standard in XForms.

Regards,    Martin.

>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