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

"Martin J. Dürst" <> Tue, 26 June 2012 11:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F6F121F857D for <>; Tue, 26 Jun 2012 04:12:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.608
X-Spam-Status: No, score=-99.608 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A3UMRYMinchu for <>; Tue, 26 Jun 2012 04:12:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9774321F8568 for <>; Tue, 26 Jun 2012 04:12:01 -0700 (PDT)
Received: from ([]) by (secret/secret) with SMTP id q5QBBoDO013850 for <>; Tue, 26 Jun 2012 20:11:50 +0900
Received: from (unknown []) by with smtp id 5ac2_00be_ba2e64a4_bf7f_11e1_8a73_001d096c5782; Tue, 26 Jun 2012 20:11:49 +0900
Received: from [IPv6:::1] ([]:42582) by with [XMail 1.22 ESMTP Server] id <S15D7C9E> for <> from <>; Tue, 26 Jun 2012 20:11:54 +0900
Message-ID: <>
Date: Tue, 26 Jun 2012 20:11:37 +0900
From: "\"Martin J. Dürst\"" <>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Stephen Farrell <>
Subject: Re: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: Graham Klyne <>,
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: Tue, 26 Jun 2012 11:12:06 -0000

Hello Stephen,

On 2012/06/25 21:05, Stephen Farrell wrote:

> On 06/25/2012 11:35 AM, "Martin J. Dürst" wrote:

>> Unfortunately, what I find is the following:
>>> The justification for using a URI scheme for this is that that might
>>> help a user agent for the speaker to better display the value, or
>>> perhaps if there was some use-case for a machine to speak the value.
>> So we are creating a new URI scheme because *perhaps* there is a use
>> case? Or because it *might* help? In the whole discussion, I was always
>> ready to accept that there are different use cases, assuming that they
>> could be clearly explained. I'm really wondering why this is so
>> difficult. If these use cases really exist, it shouldn't be that
>> difficult, and it shouldn't sound so vague, or should it? I'm not
>> necessarily blaming you, but between you, your coauthors, and the WG
>> that apparently proposed this, it shouldn't be that hard to come up with
>> a better and more definite explanation than the sentence above.
> IMO the use-case is clear, and is stated in the first sentence
> of section 7.

That sentence reads:

   "Sometimes a name may need to be referred to in a format that is easy
    or unambiguous for humans to read out, for example, over the phone."

I continue to be convinced that this is not a separate use case. URIs 
are not a priori separable into those that are written down on napkins 
(or copy-pasted into emails,...) and those that are spoken over the phone.

If I send you an URI with a hash, I don't know whether you read your 
mail with your eyes (for which ni: seems appropriate) or whether you 
have a screen reader that does a text-to-speech conversion (for which 
nih: seems to be appropriate).

> I believe that Graham got the use-case, and accepted that its
> different from ni URIs, but was questioning the need for nih to
> be a uri scheme. He can confirm or refute that himself I guess,
> but quoting his mail [1] (just before the one you reference):
> "I can see that there are distinct use-cases here, and I
> think you have reasonable grounds for not wanting to combine
> them."
>     [1]

I think what Graham refers to as the "distinct use-cases" is identified 
in the second-to-last sentence of his mail:

     "I think you said somewhere in this exchange, nih: is intended to
      be used to confirm some information that you already have."

For all that I know about URIs, that would be consistent with Graham's 
questioning of the need for an URI scheme (because a resource is only 
confirmed, not identified). It would also be supported by the fact that 
the examples for "nih:" show only shortened hashes (which, as far as I 
understand, are okay for confirmation but not for search).

[One of my editorial comments was to streamline the examples so that the 
examples for ni: and nih: would appear with the same truncation lengths, 
in pairs. When I wrote that comment, I didn't realize that there might 
be a deeper reason for having different truncation lengths for ni: and 
nih:, mostly because that wasn't really very much explained in the draft.]

So the question is really, what's the use case, and what's just a 
consequence of that use case. If confirmation of already available 
resources (e.g. like a fingerprint) is the (main?) use case, and the 
greater weight on "speakability" just a design consequence, then it 
makes sense to have two separate things. If identification is the main 
purpose in both cases, then two separate schemes don't make sense.

> Maybe the language I added for why we want nih as a uri
> scheme is not sufficiently clear, or isn't convincing, but
> that's a different argument.

Let's for a moment concentrate on what is use case, and what are the 
design properties that follow from that. We can go back to language once 
we have made some progress on substance.

Regards,    Martin.