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

Sam Hartman <> Sat, 09 June 2012 00:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5645E11E81B4 for <>; Fri, 8 Jun 2012 17:43:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.258
X-Spam-Status: No, score=-103.258 tagged_above=-999 required=5 tests=[AWL=-0.993, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TUgY+W7GQWAU for <>; Fri, 8 Jun 2012 17:43:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E1A8411E816E for <>; Fri, 8 Jun 2012 17:43:51 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by (Postfix) with ESMTPS id 7825C20424; Fri, 8 Jun 2012 20:43:38 -0400 (EDT)
Received: by (Postfix, from userid 8042) id C0D444151; Fri, 8 Jun 2012 20:43:48 -0400 (EDT)
From: Sam Hartman <>
To: Stephen Farrell <>
Subject: Re: [decade] FW: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard
References: <> <> <> <>
Date: Fri, 08 Jun 2012 20:43:48 -0400
In-Reply-To: <> (Stephen Farrell's message of "Sat, 09 Jun 2012 01:06:33 +0100")
Message-ID: <>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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:43:52 -0000

Add me as a +1 for the idea that content-type is important for this.
I tend to agree with the arguments given so far. Namely, for some
important use cases you're going to want to know the content type and
guessing is  really a bad idea.

That said, there are security considerations associated with specifying
a content type too.  I'm particularly imagining a situation where some
sort of deep inspection security appliance uses a different procedure
for deciding what kind of foo it is than the ultimate application. One
guesses based on byte stream another looks at a content type.  This is
well known; it's not new; it's probably even so documented that any
reasonably current set of MIME security considerations already includes
a reference.

I agree that your draft does not use the authority portion of a URI
consistent with section 3.2 of RFC 3986. The authority separates the
namespace exactly the way it doesn't in your scheme. It's a naming
hierarchy.  My main concern is whether the relative reference algorithm
described in section 5/4.2 of RFC 3986. In particular take a look at the
last part of section 1.2 of RFC 3986 regarding the disallowing of
/. Consider how you want relative references in an HTML document
resolved through a ni: URI to work.  I don't think your use of authority
provides good results. However I'm not sure that better results would be
achieved without hierarchy.  I hope though that these comments will help
inject some ways of reasoning about authority that are less mystical and
that lead to more practical discussion.