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

Stephen Farrell <> Mon, 25 June 2012 12:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 77BB721F8532 for <>; Mon, 25 Jun 2012 05:06:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.292
X-Spam-Status: No, score=-102.292 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F-mzWdxabYF3 for <>; Mon, 25 Jun 2012 05:06:09 -0700 (PDT)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id 3912621F851C for <>; Mon, 25 Jun 2012 05:06:06 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC896171474; Mon, 25 Jun 2012 13:06:04 +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=1340625960; bh=A0pBbjysOz/5hj FcvbiDNzwKqBTqcb5N/N22H8W+asY=; b=TXQxqwJ74UNwvBnJx7DK0OZL2s6ibF QhBfxy5A6Cm2qyj6g+uR5Mx+CrXaEewNpi3+Zd4ICZZYxe3Iv43EGy2BtNpbUD0w q81m+zv1lu613qfK+LvMKYAxnh5Amfnn/kqo2V7OYGlpeHEE1/z510c0hrWaz328 sPWAKhTMlduyXw89qH17gUQK3ekJikqF0pwqPQzeDgNparbSnl4PK0nHo8UmjWRL G2zqfqjhlGsVTf7F6wocAgeKO68MVDHaqi/E3oyBMmGyCKEq7P7Q12/jQy7lL8Zc 0n7YX4rM9U3TemrhNngmOL7/Us7ZWhOI3OlMvbZUmSi81eT0y1f/L6cw==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id GzHW-UrgpvEY; Mon, 25 Jun 2012 13:06:00 +0100 (IST)
Received: from [IPv6:2001:770:10:203:d86f:8845:f318:4fa9] (unknown [IPv6:2001:770:10:203:d86f:8845:f318:4fa9]) by (Postfix) with ESMTPSA id 2C4E1171523; Mon, 25 Jun 2012 13:05:55 +0100 (IST)
Message-ID: <>
Date: Mon, 25 Jun 2012 13:05:56 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: "\"Martin J. Dürst\"" <>
Subject: Re: 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: 8bit
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: Mon, 25 Jun 2012 12:06:13 -0000

Hi Martin,

On 06/25/2012 11:35 AM, "Martin J. Dürst" wrote:
> Hello Stephen, others,
> On 2012/06/23 6:20, Stephen Farrell wrote:
>> Hi All,
>> I went back through the IETF LC comments and think that we've
>> resolved them all on the list and have the changes in this
>> version [1] of the draft, with the possible exception of those
>> below.
>> The issues raised but not so far obviously resolved on the
>> list were I think:
>> 1) inclusion of content type
>> 2) nih as a URI scheme or not
>> For (1) this version includes ct= in draft-farrell-decade-ni
>> (the only changes to draft-hallambaker-decade-ni-params [2]
>> made so far are those that flow from moving that text), so
>> I'd hope that this version resolves that but would welcome
>> feedback on the new text from folks who commented. I'd hope
>> it should be ok, modulo some text tweaks.
>> For (2) we've left nih in as a URI scheme in this version.
>> We're still in favour of keeping it that way and have added
>> some language about why its there and is done like that. I'm
>> guessing that Martin at least won't be happy (but who knows;-),
>> so again comments are welcome as to whether the new text helps
>> or not.
> When reading your explanations, I had hoped that there would be some
> text along the lines of "different use case" that would really explain
> why two separate schemes are necessary. For example something similar to
> what Graham was mentioning at
>, which I
> understand is similar to what I mentioned as fingerprints in our
> discussion.
> 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.

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


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.

>> We do not include the query string since there is no way to ensure
>> that its value might be spoken unambiguously, and similarly for the
>> authority, where e.g. internationalised forms of domain name could
>> not be usefully spoken.  This leaves the hash value as the only part
>> of the ni URI that we feel can be usefully included.  But since
>> speakers or listeners (or speech recognition) may err, we also
>> include a check-digit to catch common errors.
> It is really strange to assume that text-to-speech software would work
> for English (or ASCII in general), but not for other scripts or
> languages. Sure, the level of text-to-speech software may not be exactly
> the same for each script and each language, but that's no reason to
> prohibit a domain name. There are definitely millions of domain names in
> e.g. Chinese or Japanese or Russian,... that can be spoken and re-typed
> quite unambiguously, and that users would have much less problems with
> than a long string of hex digits. (And we would still have the check
> digit, anyway.) On the other hand, it is quite possible to create domain
> names with ASCII/English that neither humans nor text-to-speech engines
> will be able to pronounce right.

The point is that we only leave in the ascii-hex. The
goal being to reduce this to something that can be
unambiguously spoken, and I think ascii-hex is about
as close as one can get to that. Anything else brings
additional ambiguity and hence is left out.

Its true that the machine-reading/recognition bit is
speculative though, but I don't think its much of a leap,
nor is it really crucial to the argument.


> Regards,   Martin.
>> But in the end we'll go with Barry's consensus call
>> on this if he judges that we're in the rough, rather than the
>> folks who've commented on this topic. In that case I'll put
>> out a version with no nih scheme and the "human speakable"
>> format as just a textual convention (with a check-digit,
>> which'd be plain odd IMO, the uri scheme is the right idea
>> really:-)
>> Please let me know if I've missed addressing anything else
>> or if you have any other comments.
>> Cheers,
>> S.
>> [1]
>> [2]
>> (Note: only [1] is in IETF LC...just in case someone's
>> confused about that:-)
>> On 06/04/2012 03:18 PM, The IESG wrote:
>>> The IESG has received a request from an individual submitter to consider
>>> the following document:
>>> - 'Naming Things with Hashes'
>>>    <draft-farrell-decade-ni-07.txt>  as Proposed Standard
>>> The IESG plans to make a decision in the next few weeks, and solicits
>>> final comments on this action. Please send substantive comments to the
>>> mailing lists by 2012-07-02. Exceptionally, comments
>>> may be
>>> sent to instead. In either case, please retain the
>>> beginning of the Subject line to allow automated sorting.
>>> Abstract
>>>     This document defines a set of ways to identify a thing using the
>>>     output from a hash function, specifying URI, URL, binary and human
>>>     "speakable" formats for these names.  The various formats are
>>>     designed to support, but not require, a strong link to the
>>> referenced
>>>     object such that the referenced object may be authenticated to the
>>>     same degree as the reference to it.
>>> The file can be obtained via
>>> IESG discussion can be tracked via
>>> The following IPR Declarations may be related to this I-D: