Re: [apps-discuss] URI registry

Graham Klyne <> Thu, 10 February 2011 11:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F2303A687C for <>; Thu, 10 Feb 2011 03:00:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.699
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ggUj+DAcz-Ys for <>; Thu, 10 Feb 2011 03:00:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9402B3A6974 for <>; Thu, 10 Feb 2011 03:00:09 -0800 (PST)
Received: from ([]) by with esmtp (Exim 4.71) (envelope-from <>) id 1PnUG0-0007UC-Bg; Thu, 10 Feb 2011 11:00:16 +0000
Received: from ([]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1PnUG0-0007x6-4C; Thu, 10 Feb 2011 11:00:16 +0000
Message-ID: <>
Date: Thu, 10 Feb 2011 10:34:48 +0000
From: Graham Klyne <>
User-Agent: Thunderbird (Macintosh/20100228)
MIME-Version: 1.0
To: "\"Martin J. Dürst\"" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <026901cbc781$a2724ee0$> <> <000901cbc867$7a9d31a0$> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Oxford-Username: zool0635
Subject: Re: [apps-discuss] URI registry
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 

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