Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Mon, 14 November 2011 07:09 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253D911E8240 for <apps-discuss@ietfa.amsl.com>; Sun, 13 Nov 2011 23:09:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.599
X-Spam-Level:
X-Spam-Status: No, score=-99.599 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSmfdb-8tIaA for <apps-discuss@ietfa.amsl.com>; Sun, 13 Nov 2011 23:09:24 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id E356F11E823D for <apps-discuss@ietf.org>; Sun, 13 Nov 2011 23:09:20 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAE79K3C007430 for <apps-discuss@ietf.org>; Mon, 14 Nov 2011 16:09:20 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 73ad_1cc7_9299c4b6_0e8f_11e1_aa25_001d096c566a; Mon, 14 Nov 2011 16:09:20 +0900
Received: from [IPv6:::1] ([133.2.210.1]:44953) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S156CFD4> for <apps-discuss@ietf.org> from <duerst@it.aoyama.ac.jp>; Mon, 14 Nov 2011 16:09:19 +0900
Message-ID: <4EC0BE9E.8020702@it.aoyama.ac.jp>
Date: Mon, 14 Nov 2011 16:09:18 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Larry Masinter <masinter@adobe.com>
References: <C68CB012D9182D408CED7B884F441D4D0611DABF22@nambxv01a.corp.adobe.com>
In-Reply-To: <C68CB012D9182D408CED7B884F441D4D0611DABF22@nambxv01a.corp.adobe.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Roy Fielding <fielding@adobe.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] A modest proposal for MIME types (and URI schemes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Nov 2011 07:09:25 -0000

Hello Larry,

On 2011/11/14 3:59, Larry Masinter wrote:
> I'd like to discuss the proposal for MIME registrations from Roy Fielding in http://www.ietf.org/mail-archive/web/happiana/current/msg00187.html
> and the possibility that such changes should also apply to URI schemes.
>
> You can read Roy's rationale, which makes sense to me,

Some of it makes quite a bit of sense to me, but the first thing that 
doesn't make sense to me is the title of your mail. The proposal seems 
rather radical, not modest.

> but my summary is:
>
> * Eliminate standards, vendor, personal trees distinction for MIME types (For URI schemes, eliminate distinction between provisional and permanent schemes)
> * ENCOURAGE vendors to ship with vendor-neutral short-named types regardless of whether they have been registered yet or not;

I think that makes sense for something widely known and used (e.g. 
application/pdf), but not necessarily for some really company-specific 
type. (Of course, we don't know in advance which way something may go in 
the end, but we could use this rule at least for when the company e.g. 
wants to express that a type is NOT intended for general use).

>     ENCOURAGE the public to register any names that they have seen in deployed software. (same for URI schemes)

I think third-party registration is indeed something we should encourage 
more.

> * DO NOT try to avoid duplicates

I'm not sure this makes sense. I think it would make sense if it read 
"give up on trying to avoid duplicates at all cost". But it almost reads 
like "let's have many duplicates, this will be fun".

> * EXPERT REVIEW for updates to existing registrations
> * Eliminate any IESG or consensus review requirement
>
> "There is absolutely no need to prevent name collisions in the registry itself because those collisions are irrelevant -- what matters is how the names are interpreted by recipients of messages."

Well, but isn't one goal of the effort to get the registry to (more 
closely) reflect reality? In this case, if there are two 
application/foo, and applications recognize one and not the other, then 
there's a disconnect.

Regards,   Martin.

> "There is absolutely no need to prevent people who are not the owners of a media type from registering that type without any prefixes."
> "The registry is not operable -- it is just documentation of how the Internet is operating, and it should reflect the reality of that operation even if that means we have multiple definitions per registered type."
>
> I find this perspective appealing, and can't find anything wrong with it except that it's a break with tradition. If you're at IETF this week and want to talk about it, find me.
>
> Larry
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>