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

Stephen Farrell <> Sat, 09 June 2012 01:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD08211E809C for <>; Fri, 8 Jun 2012 18:45:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.545
X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VeW8b6CgT70C for <>; Fri, 8 Jun 2012 18:45:29 -0700 (PDT)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id DE6CF11E8079 for <>; Fri, 8 Jun 2012 18:45:28 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B0AB154252; Sat, 9 Jun 2012 02:45:28 +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=1339206327; bh=IR2XYEwxzS7qVo Scn1kyqc7/Icn8OJqjtJaUzHdK2j8=; b=o+W5eMki1AKOwHbQdxbIHHa1r766EA Hfue6ytm8vUxL9PfydTi6uAHZWezKWsoEL0I5NQ8xOdyLwrmkKkkFZUPpfYyPkaE 4JPhl462zXLdokH6lCHX9R8Z8SHY+u8SDZg15NgL4xPLW0quo0kZCCROL45N6Vy8 zOKWgwkVZLC1TtB1agHDEGgUJcH0+9VXc1Qp81d0NG2qBdygABwQNwyGtsHQqBiw llolsgqbV/EwL+enImC4sShe3JHE6As6aHqFTySwwE9vvq7kpcGD+KELojypMrXm PqXZW0WCfHR1zLalEtajtPxJ7NS8fU/5mDa6zCzC7E88H7KL7Pl5XjbA==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id XMYz8auwxIaE; Sat, 9 Jun 2012 02:45:27 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id A8E4B154251; Sat, 9 Jun 2012 02:45:23 +0100 (IST)
Message-ID: <>
Date: Sat, 09 Jun 2012 02:45:23 +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: Sam Hartman <>
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 01:45:30 -0000

Hi Sam,

On 06/09/2012 01:43 AM, Sam Hartman wrote:
> 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.

Thusly counted:-)

> 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.

My only real concern with adding this is the issue of complexity
related to c14n of input to the hash function. While CMS does (I
think) define that well, imposing that burden on anyone that might
want to write code that validates name-data integrity is an issue.
Anyway, if we want to add it we'll look that over and figure how
it might best be done.

> I agree that your draft does not use the authority portion of a URI
> consistent with section 3.2 of RFC 3986. 

I honestly don't get that. I think we are "consistent" with 3986
(there being no MUST/SHOULD with which we're in conflict afaik)
but the authority field here is not identical to that for HTTP
URLs. And that's ok.

> The authority separates the
> namespace exactly the way it doesn't in your scheme. 

Yes there are differences and maybe we ought try describe that

> 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.


I think your comment about relative URIs is fair and we maybe ought
say there are no such things for ni URIs. (Or however that kind of
thing is stated best).

I guess a sentence or two about relative URIs would be worthwhile
and I'll ponder that.