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

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 03 March 2011 16:13 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5BE3A6A06 for <apps-discuss@core3.amsl.com>; Thu, 3 Mar 2011 08:13:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMab-KFB-Fvk for <apps-discuss@core3.amsl.com>; Thu, 3 Mar 2011 08:13:56 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 80D5C3A69ED for <apps-discuss@ietf.org>; Thu, 3 Mar 2011 08:13:56 -0800 (PST)
Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <TW--hwADL1lr@rufus.isode.com>; Thu, 3 Mar 2011 16:15:03 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <4D6FBE4D.10602@isode.com>
Date: Thu, 03 Mar 2011 16:14:05 +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: apps-discuss@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] Possible IESG statement on IESG processing of MIME type registrations from other SDOs
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 03 Mar 2011 16:13:57 -0000

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

and

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

Thanks,
Alexey