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

Peter Saint-Andre <stpeter@stpeter.im> Wed, 09 March 2011 03:58 UTC

Return-Path: <stpeter@stpeter.im>
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 285963A6802 for <apps-discuss@core3.amsl.com>; Tue, 8 Mar 2011 19:58:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.624
X-Spam-Level:
X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 tycjEwEa9Xka for <apps-discuss@core3.amsl.com>; Tue, 8 Mar 2011 19:58:07 -0800 (PST)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E658B3A67B5 for <apps-discuss@ietf.org>; Tue, 8 Mar 2011 19:58:06 -0800 (PST)
Received: from squire.local (dsl-251-69.dynamic-dsl.frii.net [216.17.251.69]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 420AB4011B; Tue, 8 Mar 2011 21:19:19 -0700 (MST)
Message-ID: <4D76FB18.1040304@stpeter.im>
Date: Tue, 08 Mar 2011 20:59:20 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Ted Hardie <ted.ietf@gmail.com>
References: <4D6FBE4D.10602@isode.com> <6.2.5.6.2.20110308164758.0be3c0a8@resistor.net> <AANLkTinKPGRPOCb_7wai6Rq0tKdop0yGb7UfHuzUkpXu@mail.gmail.com>
In-Reply-To: <AANLkTinKPGRPOCb_7wai6Rq0tKdop0yGb7UfHuzUkpXu@mail.gmail.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms050706010303010107010505"
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: Wed, 09 Mar 2011 03:58:08 -0000

On 3/8/11 6:34 PM, Ted Hardie wrote:
> On Tue, Mar 8, 2011 at 5:13 PM, SM <sm@resistor.net> wrote:
>> Hi Alexey,
> 
>>> 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.
>>
> <snip>
> 
>>  "The media type registration procedure is not a formal standards
>>   process, but rather an administrative procedure intended to allow
>>   community comment and sanity checking without excessive time delay."
>>
>> The proposed IESG statement will end up turning "the posting of an Internet
>> Draft [into] a necessary first step".  Martin Dürst mentioned that it is not
>> always easy for people outside the IETF to write an I-D [1].  "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" [2].  This has the makings of turning the registration
>> procedure into a formal standards process.
>>
> 
> I'm not sure I agree that it turns into a formal standards process,
> but I definitely agree that it's going to be very hard for outsiders
> to find this statement and do the right thing, absent additional clue.

Currently folks working within other SDOs ping one or both of the
Applications Area Directors, who usually say "we know it's not
mandatory, but it would be helpful if you could write a brief
Internet-Draft defining your registration request". So outsiders don't
need to find this statement and do the right thing from the start, and I
don't think the Apps ADs (or IESG in general) expect that they would.

>  The BCP will say "not needed" and the IESG statement will say
> "encouraged".  I'd say if the IESG ever plans to point to the
> statement after receiving one in another format, it should update the
> BCP instead.

Yes, it's always good to align our procedural BCPs with the practices we
actually follow (if they're "best", at least).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/