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