Re: [apps-discuss] Possible IESG statement on IESG processing of MIME type registrations from other SDOs

Alexey Melnikov <> Sun, 20 March 2011 15:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 523F428C0DF for <>; Sun, 20 Mar 2011 08:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.517
X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sBRypqBF5+1C for <>; Sun, 20 Mar 2011 08:27:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EBEE928C0D8 for <>; Sun, 20 Mar 2011 08:27:21 -0700 (PDT)
Received: from [] ((unknown) []) by (submission channel) via TCP with ESMTPA id <>; Sun, 20 Mar 2011 15:28:50 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <>
Date: Sun, 20 Mar 2011 15:28:02 +0000
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Larry Masinter <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [apps-discuss] Possible IESG statement on IESG processing of MIME type registrations from other SDOs
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 20 Mar 2011 15:27:24 -0000

Hi Larry,

Larry Masinter wrote:

>This proposed IESG statement fails to address any of the significant difficulties:
...because it was not planning to address them. There are multiple 
related discussions going on at the moment. This particular statement 
proposal originated from an internal IESG discussion about stability of 
references in registrations from other SDOs.

>Registering MIME types is an activity that has high cost and little benefit.  Cost in terms of learning the process (poorly documented, inconsistent, hard to follow) and following it (responding to reviewer comments). Little benefit, in that the registry plays little or no role in the actual implementation and deployment cycle for new values.

>This issue applies also to URI schemes, and to some degree to other (web-) and perhaps (application-level) parameters.
>The high cost and low benefit holds in general for any organization deploying a new or updated content type. While it is also true for other SDOs, the proposed statement does not address the general problem, and might even make the situation worse, by making the SDO process even more different from the non-SDO problem.
I don't think it does, but I am happy to discuss.

>(It does not address the cost/benefit tradeoff for SDOs either, except perhaps to trade off one cost -- cost of learning a cumbersome and poorly documented process -- with another.)
>With MIME types and charset values, there are additional consequences:
>Because some organizations and implementations originally did not supply the correct registered values, many implementations override the provided MIME types and character encoding assertions (use of registered values) by "sniffing"  see also
> .
I agree that this is worth addressing, but addressing this particular 
problem wasn't a goal.

>More problematic is when the "ownership" of a MIME registration is in dispute, for example when there are multiple, different specifications which claim to be the authority on a registered value, e.g., the two registries for the same MIME value vs.  pointing to substantially different specifications. 
What is your proposal here?
I think this issue is quite rare and the only cases I've seen all 
originate from WHATWG/W3C.

As far as IANA (or IESG) is concerned, there is only one true 
registration in each case, so there is no dispute.

>The proposed IESG statement does not address this issue, and, in fact might exacerbate it, by making the registration process for SDOs more difficult than the non-registration-process for non-SDOs.
> (Too bad the IAB document on "Design Considerations for Protocol Extensions"   doesn't take on these issues).