Re: [decade] FW: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard

Stephen Farrell <> Sat, 09 June 2012 00:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13E0411E80E2 for <>; Fri, 8 Jun 2012 17:06:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.491
X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ckZYGlN8EO4o for <>; Fri, 8 Jun 2012 17:06:36 -0700 (PDT)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id 4E90311E80DF for <>; Fri, 8 Jun 2012 17:06:36 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7DBF154252; Sat, 9 Jun 2012 01:06:34 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1339200394; bh=jFkZqGUUg7TmLb mZZjFseAcMyxxnOgYrhxyxNlVR+P8=; b=2cts98cWV7hfv4TGVOOaXPVyTapJuA tFgmC9wOYRC3PMH0+MH+1VZvIHW1Pwg1HqcUhoKyvkRzv2MpRx664IBJmG2B48wE SJ6nQhyDVZ9DXhJZ0QRVzPqpTPqeD20NIh1k9hnrQ2VnVbmQ/McXeNHcCNSTwWxj y0T3Zgg8gTA7SwHX3EA4z0Xe9FpfN+pup4XQ/li5q8q7ZuaTBBjPhjeobpceSOBD zOhozd9B5zAEuwAkb3LMP4YEjQPVlHbqp8qaZmTjom8EjMYw5JYFcJgK9eoBW6wb 0wUU/01qYkPxGDHs++d2c3gAHTbOdDnceTHx4DKAWdlsvpsrGUVVOS9A==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id wAr1sTen3K33; Sat, 9 Jun 2012 01:06:34 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id CDDD8154251; Sat, 9 Jun 2012 01:06:33 +0100 (IST)
Message-ID: <>
Date: Sat, 09 Jun 2012 01:06:33 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Martin Thomson <>
Subject: Re: [decade] FW: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Jonathan A Rees <>,
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 09 Jun 2012 00:06:45 -0000

Hi Martin,

On 06/08/2012 10:54 PM, Martin Thomson wrote:
> One small comment, that I know the authors are aware of...
> On 6 June 2012 13:33, Jonathan A Rees <> wrote:
>> I think using .well-known is a good idea.
> I think that using .well-known is a bad idea.

Ok. Opinions vary.

> This imposes an unnecessary restriction on the deployment of
> resources.  /.well-known/ is a space that can only be deployed to by
> an administrator of the system.  By identifying specifically where the
> resource might live (potentially with more than one URL), this avoids
> the deployment issue.
> Yes, I am aware of the "extensions".

I don't get what you mean above. If its something that
implies a change, I don't know what change.

> And:
>> (a lot of other things)
> I agree with all of this, the authority thing, the content-type thing.
>  All of it.  (And none of the rebuttal.)

So the probability of us being completely correct in all this is
probably infinitesimally small, but equal to the probability
of us being completely wrong. That would imply that our rebuttals
are not completely wrong and hence you are equally wrong in
saying "all" and "none" above. (Isn't sophistry great:-)

Anyway, I take that as another +1 for adding ct= to this draft
which is fine. I'm starting to think that might be a good plan.
Let's see if others (dis)agree during the rest of IETF LC.

I also take that as another claim that our use of the
authority field is somehow "wrong" for what seem to me to
be near-mystical reasons, with no compelling argument offered
as to any bad effects at all ensuing. I'm still entirely happy
that our current design is good enough as-is. For me, running
code is a winner in that part of the argument.

> Nit:
> The draft makes some strange statements about redirects.
>    Put another way, a server SHOULD return a 30x response when a .well-
>    known/ni URL is de-referenced.
> Requiring a compliant HTTP implementation that follows redirects is
> sufficient.  What the server does to serve this request is the
> server's business.  Redirects seem likely, but 2119 language for the
> server is not necessary for interoperation.

Good point. I've tweaked that a bit in response to Bjoern's
comments, but your suggestion above is better than what I
have now so I'll work that in. (Actually, is client support
for 3xx mandatory according to 2616? Not sure myself.)