Re: [apps-discuss] Possible IESG statement on IESG processing of MIME type registrations from other SDOs
"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Tue, 08 March 2011 08:03 UTC
Return-Path: <duerst@it.aoyama.ac.jp>
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 793443A68EA for <apps-discuss@core3.amsl.com>; Tue, 8 Mar 2011 00:03:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.843
X-Spam-Level:
X-Spam-Status: No, score=-99.843 tagged_above=-999 required=5 tests=[AWL=-0.053, 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOiJZDcPsCSl for <apps-discuss@core3.amsl.com>; Tue, 8 Mar 2011 00:03:40 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by core3.amsl.com (Postfix) with ESMTP id 8BD943A68AB for <apps-discuss@ietf.org>; Tue, 8 Mar 2011 00:03:39 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p2884itD007426 for <apps-discuss@ietf.org>; Tue, 8 Mar 2011 17:04:44 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 424a_364c_ba5297da_495a_11e0_bde9_001d096c566a; Tue, 08 Mar 2011 17:04:44 +0900
Received: from [IPv6:::1] ([133.2.210.1]:49919) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S14E293F> for <apps-discuss@ietf.org> from <duerst@it.aoyama.ac.jp>; Tue, 8 Mar 2011 17:04:43 +0900
Message-ID: <4D75E305.2060600@it.aoyama.ac.jp>
Date: Tue, 08 Mar 2011 17:04:21 +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.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>
References: <4D6FBE4D.10602@isode.com>
In-Reply-To: <4D6FBE4D.10602@isode.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: apps-discuss@ietf.org
Subject: Re: [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: Tue, 08 Mar 2011 08:03:43 -0000
Hello Alex, I support most of the comments from Björn. Some additional comments below. On 2011/03/04 1:14, Alexey Melnikov wrote: > I am working with the rest of IESG on issuing the following IESG statement: First, I'm worried that an IESG statement (of whatever content) will only complicate things for applicants and reviewers/commenters. IESG statements seem to work well for things that affect people who are already in the know, insiders,..., but not for outsiders. > ------------------------ > > 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, I don't understand what's the purpose of this. One of the main changes in RFC 4288 was to get away from the fact that every type in the standards tree had to be an RFC. This was discussed e.g. with W3C, and made it considerably more straightforward to register types from W3C. For details, please see http://www.w3.org/2002/06/registering-mediatype. It could easily be seen as a step back. Also, please very strongly consider that while for somebody on the IESG, writing an ID, in particular if it only contains the template, is something they can easily do before breakfast, for people from the outside, it's something where they have no idea where to start, which often means they don't start at all. > as this tends to improve quality of final registrations, Can you give any examples? I don't say there are none, but I couldn't come up with one myself. > and sometimes > even improves quality of the underlying format itself. Does that imply that the underlying format should be included in the ID? That would definitely deviate from BCP 13. Anyway, giving clearer explanations (and probably discussion) about when exactly and what for an ID makes sense seems to be much needed, and the actual need should not be just because the datatracker cannot handle anything else than drafts. > 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. That's true, and doesn't hurt mentioning. If we say something about this, please include a line or so saying that the post should contain an actual copy of the registration template (not just "it's over there") because that makes it much easier to comment. Regards, Martin. > 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 > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
- [apps-discuss] Possible IESG statement on IESG pr… Alexey Melnikov
- Re: [apps-discuss] Possible IESG statement on IES… Bjoern Hoehrmann
- Re: [apps-discuss] Possible IESG statement on IES… Martin J. Dürst
- Re: [apps-discuss] Possible IESG statement on IES… SM
- Re: [apps-discuss] Possible IESG statement on IES… Ted Hardie
- Re: [apps-discuss] Possible IESG statement on IES… Peter Saint-Andre
- Re: [apps-discuss] Possible IESG statement on IES… Martin J. Dürst
- Re: [apps-discuss] Possible IESG statement on IES… Alexey Melnikov
- Re: [apps-discuss] Possible IESG statement on IES… Bjoern Hoehrmann
- Re: [apps-discuss] Possible IESG statement on IES… Larry Masinter
- Re: [apps-discuss] Possible IESG statement on IES… Alexey Melnikov