Re: [apps-discuss] URI registry

Graham Klyne <GK-lists@ninebynine.org> Thu, 10 February 2011 11:00 UTC

Return-Path: <GK-lists@ninebynine.org>
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 0F2303A687C for <apps-discuss@core3.amsl.com>; Thu, 10 Feb 2011 03:00:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.699
X-Spam-Level:
X-Spam-Status: No, score=-7.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_48=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 ggUj+DAcz-Ys for <apps-discuss@core3.amsl.com>; Thu, 10 Feb 2011 03:00:09 -0800 (PST)
Received: from relay3.mail.ox.ac.uk (relay3.mail.ox.ac.uk [163.1.2.165]) by core3.amsl.com (Postfix) with ESMTP id 9402B3A6974 for <apps-discuss@ietf.org>; Thu, 10 Feb 2011 03:00:09 -0800 (PST)
Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay3.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from <GK-lists@ninebynine.org>) id 1PnUG0-0007UC-Bg; Thu, 10 Feb 2011 11:00:16 +0000
Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <GK-lists@ninebynine.org>) id 1PnUG0-0007x6-4C; Thu, 10 Feb 2011 11:00:16 +0000
Message-ID: <4D53BF48.1010804@ninebynine.org>
Date: Thu, 10 Feb 2011 10:34:48 +0000
From: Graham Klyne <GK-lists@ninebynine.org>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>
References: %3C4D26B005.2060909@gmail.com%3E <4D2C7755.5080908@gmail.com> <81F42F63D5BB344ABF294F8E80990C7902782BBA@MTV-EXCHANGE.microfocus.com> <4D455380.6040103@gmail.com> <3792F8F3-D01B-4B05-9E73-59228F09FE5C@gbiv.com> <4D464EA4.7090303@gmail.com> <7ED44745-7DBA-4372-BE39-22061DC26DF2@gbiv.com> <4D46CE52.6030503@vpnc.org> <4D47DD4A.7040503@gmail.com> <06BA884E-D1C7-4783-BBE6-A6B21DE013B7@niven-jenkins.co.uk> <4D482071.8050202@gmail.com> <CDAB7832-EBF9-4ECE-B8D1-09BA39BDF4B8@niven-jenkins.co.uk> <4D48267A.1030800@gmail.com> <96CC61EE-81BD-43CB-A83F-78E67B2DA7A5@niven-jenkins.co.uk> <C68CB012D9182D408CED7B884F441D4D058EEE61B9@nambxv01a.corp.adobe.com> <026901cbc781$a2724ee0$4001a8c0@gateway.2wire.net> <4D520AE6.8070502@it.aoyama.ac.jp> <000901cbc867$7a9d31a0$4001a8c0@gateway.2wire.net> <4D537E48.9030403@it.aoyama.ac.jp>
In-Reply-To: <4D537E48.9030403@it.aoyama.ac.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Oxford-Username: zool0635
Cc: public-iri@w3.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] URI registry
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, 10 Feb 2011 11:00:11 -0000

Martin J. Dürst wrote:
> [Responding one more time here because this is a metadiscussion]

[Ditto, and also maybe affects the header registry 
(http://tools.ietf.org/html/rfc3864)]

What happened to "rough consensus and running code"?

As a reviewer, I sometimes make a recommendation that is in the spirit of the 
proposal even if not explicitly covered by the letter, but also alerting the 
relevant IESG director if I do so.  I think this is very much in the IETF spirit 
of "do the right thing".

For the message header registry, there some "weasel words" to allow some 
flexibility in section 4.4 that were intended to help circumvent unnecessary 
process-wrangling, ending with "The IESG is the final arbiter of any objection."

It seems to me that if the IANA+reviewer make a visible disposition that nobody 
objects to, the easiest thing is to just do it.

I'm not sure if it's necessary, but one might consider a minor update up the 
registration RFC(s) to provide this lattitude more explicitly, with further 
effort to be expended only in the event of an objection.  At some point, we need 
to trust the process participants (reserving the option to verify), or we get 
nowhere.

#g
--