[ietf-types] [Fwd: Possible IESG statement on IESG processing of MIME type registrations from other SDOs]

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 09 March 2011 11:46 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: ietf-types@core3.amsl.com
Delivered-To: ietf-types@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id D92103A6948 for <ietf-types@core3.amsl.com>; Wed, 9 Mar 2011 03:46:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.544
X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id CL9Pk2LJ5JKB for <ietf-types@core3.amsl.com>; Wed, 9 Mar 2011 03:46:26 -0800 (PST)
Received: from pechora1.lax.icann.org (pechora1.icann.org []) by core3.amsl.com (Postfix) with ESMTP id CAAB33A684A for <ietf-types@ietf.org>; Wed, 9 Mar 2011 03:46:26 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com []) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id p29Bl7ib008625 for <ietf-types@iana.org>; Wed, 9 Mar 2011 03:47:27 -0800
Received: from [] ((unknown) []) by rufus.isode.com (submission channel) via TCP with ESMTPA id <TXdouQADL5uz@rufus.isode.com>; Wed, 9 Mar 2011 11:47:05 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <4D776889.2010709@isode.com>
Date: Wed, 09 Mar 2011 11:46:17 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
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: ietf-types@iana.org
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------050907050905070900080906"
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org []); Wed, 09 Mar 2011 03:47:28 -0800 (PST)
Subject: [ietf-types] [Fwd: Possible IESG statement on IESG processing of MIME type registrations from other SDOs]
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-types>
List-Post: <mailto:ietf-types@ietf.org>
List-Help: <mailto:ietf-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Mar 2011 11:46:27 -0000

I already have some pending changes on this, but here is the original 
version I proposed.
To keep all discussions in one place, please send any comments to 
apps-discuss@ietf.org, or directly to me.


IETF Application Area Director, <http://www.ietf.org/iesg/members.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address

--- Begin Message ---
I am working with the rest of IESG on issuing the following IESG statement:


BCP 13 (currently RFC 4288) specifies that Media Type registrations
from other Standards Organizations (SDOs) can be submitted directly to
IESG for approval, without a need to submit an Internet Draft and to ask
an Area Director to shepherd its publication.

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.

IESG would also like to remind that as per BCP 13, other SDOs are not
excluded from the requirement to post their Media Type registrations
for 2 weeks review on the ietf-types@iana.org mailing list.

When reviewing Media Type registrations IESG checks that the Media
Type registration template is correct and reasonably complete.

When reviewing Media Type registrations (including those from other SDOs) IESG also
checks that references to documents describing details of the Media
Type format are stable, i.e.
- a) the references are reasonably long lived


- b1) the document pointed to by the reference is either immutable
(i.e. if an updated document is approved for publication by the SDO,
then it will be posted at a different URI) or can only change in
insignificant ways (e.g. to correct typos, clarify text without
changing the media type format, etc.)

- b2) the media type format contains some internal fields for
versioning that can be used to distingiush 2 incompatible versions of
the Media Type format

- b3) there is some guaranty that future revisions of the format are
going to be backward compatible

Note that the choices b1, b2 and b3 are not mutually exclusive.

If the Media Type format specification has licensing restrictions, the
Internet Assigned Numbers Authority (IANA) must be granted express
permission to make archival copies of the Media Type format
specification, and to redistribute such a copy in the event that the
link to the format specification becomes inoperative and it is
determined that it will not be repaired.


Please let me know if you have any corrections or major objections to 
this before March 17th.


--- End Message ---