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

Bjoern Hoehrmann <> Sun, 06 March 2011 23:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF94A28C0DD for <>; Sun, 6 Mar 2011 15:56:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.838
X-Spam-Status: No, score=-2.838 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_00=-2.599, J_CHICKENPOX_35=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HbLKNydI8f2Q for <>; Sun, 6 Mar 2011 15:56:56 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 61DCD28C0CF for <>; Sun, 6 Mar 2011 15:56:55 -0800 (PST)
Received: (qmail invoked by alias); 06 Mar 2011 23:58:06 -0000
Received: from (EHLO HIVE) [] by (mp007) with SMTP; 07 Mar 2011 00:58:06 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1+gUS0eRb+gGRlwch0JNTQ9Af0bD1beNcaya0sA6q bJCCdb58SMdKX3
From: Bjoern Hoehrmann <>
To: Alexey Melnikov <>
Date: Mon, 07 Mar 2011 00:58:12 +0100
Message-ID: <>
References: <>
In-Reply-To: <>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
X-Mailman-Approved-At: Mon, 07 Mar 2011 08:17:38 -0800
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, 06 Mar 2011 23:56:58 -0000

* Alexey Melnikov wrote:
>I am working with the rest of IESG on issuing the following IESG statement:

It would probably be a good idea to point ietf-types subscribers to your
message, they are the most likely to have opinions on this matter.

>While this IESG statement doesn't change that, IESG would like to
>encourage other SDOs to submit their registriation as Internet Drafts,
>as this tends to improve quality of final registrations, and sometimes
>even improves quality of the underlying format itself.

The IESG's workflow is probably optimized for Internet-Drafts, so it's
easy to see how this might improve things for the IESG, with requests
ending up in the right tracking systems and such, but it would seem the
idea would be to actually advance these Internet-Drafts to RFC status,
but RFCs that contain little more than the media type registration tem-
plates are not very useful. Nobody would look at the text/css RFC for
instance to learn about CSS syntax, character encodings in CSS, or re-
lated issues, for instance.

So if you really mean they should go the I-D -> RFC route, then I'm not
sure this is a good idea. If the idea is just to have something better
on record than, say, review requests in the ietf-types list archives,
then I doubt a bit that this would really help quality, even if you post
an I-D you'd still request ietf-types review and as far as I can tell
the "quality" issues usually get fixed there, if they get fixed at all.

A bigger problem to me is that there are many entry points. If you want
to register a type, do you contact IANA, do you contact ietf-types, do
you contact the IESG, or someone else, in what order, and so on. If the
process was "post registration information to ietf-types, fix issues
raised there, then the media type reviewers will guide you through the
next steps" that would be much simpler. Some people for instance think
by posting to ietf-types they are asking the IESG to register a type.

Another problem seems to be that after ietf-types review the process is
intransparent. It seems to me that people are to contact the IESG se-
parately and then the IESG may announce a decision sooner or later, but
what happens inbetween does not seem to be easily publically accessible.

Those two problems would be addressed by using I-Ds, but see above.

As for the points on format evolution and licensing, instead of listing
rather onerous requirements that I am not sure are fully supported by
RFC 4288, it might be better to say that, if a format does not meet some
reasonable stability and availability requirements, it is better to re-
gister types in other trees than the standards tree. OASIS registering
types under vnd.oasis rather than in the standards tree seems quite okay

Personally, I think we might do just fine having just a "specification
available" policy for media types with little regard for immutability or
availability of specifications, or whether registrations use one version
of the registration template or another, or getting some weird "Mac"
codes right. We have more of a problem with many dozens of common types
that are not registered at all.
Björn Höhrmann · ·
Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·