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

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Mon, 02 July 2012 11:07 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721E021F8ADF for <ietf@ietfa.amsl.com>; Mon, 2 Jul 2012 04:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.565
X-Spam-Level:
X-Spam-Status: No, score=-99.565 tagged_above=-999 required=5 tests=[AWL=0.225, 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kY+VM5k5XKos for <ietf@ietfa.amsl.com>; Mon, 2 Jul 2012 04:07:08 -0700 (PDT)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id C325421F8A59 for <ietf@ietf.org>; Mon, 2 Jul 2012 04:07:07 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q62B7BX8031238 for <ietf@ietf.org>; Mon, 2 Jul 2012 20:07:11 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 5310_211e_125f969c_c436_11e1_b6f9_001d096c5782; Mon, 02 Jul 2012 20:07:10 +0900
Received: from [IPv6:::1] ([133.2.210.1]:47255) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S15DAEAB> for <ietf@ietf.org> from <duerst@it.aoyama.ac.jp>; Mon, 2 Jul 2012 20:07:11 +0900
Message-ID: <4FF180DC.3090003@it.aoyama.ac.jp>
Date: Mon, 02 Jul 2012 20:07:08 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard
References: <20120604141804.23098.42455.idtracker@ietfa.amsl.com> <4FE4E19F.2050400@cs.tcd.ie> <4FE83EF5.1050000@it.aoyama.ac.jp> <4FE85424.9000409@cs.tcd.ie> <4FE998E9.9010809@it.aoyama.ac.jp> <4FE99C75.9010309@cs.tcd.ie>
In-Reply-To: <4FE99C75.9010309@cs.tcd.ie>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Graham Klyne <GK@ninebynine.org>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Jul 2012 11:07:11 -0000

Hello Stephen,

On 2012/06/26 20:26, Stephen Farrell wrote:
>
> Hi again Martin,
>
> On 06/26/2012 12:11 PM, "Martin J. Dürst" wrote:
>> 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.
>
> Yes, confirmation is the main current use-case for nih as I understand
> it and have said previously.

I sincerely wish you had said this so clearly much, much earlier, or 
even better that it had been in the draft in cristal clear language. We 
could have avoided a lot of useless discussion.

> (Of course the resource might not yet
> be present, so "already available" isn't quite right, but that's a
> nit.)
>
> Have we beaten this to death sufficiently now? I hope so;-)
>
> If you want to suggest a sentence that says that, feel free.

I really don't think it should be my job to explain this. There are 
enough coauthors on the draft who should be in a much better position 
than myself to write such text :-(.

Anyway, here is a try:

- In the abstract, replace "and binary and human "speakable" formats for 
these names" by ", a binary form, and a form for confirming the presence 
(or absence) of resources".

- In the introduction, replace "and a
    human-speakable text form that could be used, e.g. for reading out
    (parts of) the name over a voice connection." with
    "and a form optimized for confirming the presence (or absence) of
    resources by humans.".

- Change the title of Section 7 from "Human-speakable Format" to "Format 
for Resource Confirmation"

- Replace the first sentence at the start of Section 7 to say:
There is often a need for humans to confirm that a particular resource, 
e.g. a public key, is already present, or to discover its absence.

- Change "("speaking" the value of an ni URI)" to "confirm the presence 
or absence of a resource")

- Nuke the second paragraph of section 7 (the one that starts with "The 
justification for using a URI"). The stuff it says about IDNs, for 
example, isn't really appropriate for IETF standardization.

- In the example section, change "Human-speakable form of a name" to
"Form for resource confirmation" (three occurrences).


I'd also change the "nih:" scheme to something like "fingerprint:", and 
allow the insertion of delimiter characters (allowing e.g. 
nih:3;5326-9057-e12f-e2b7-4ba0-7c89-2560a2;f instead of 
nih:3;53269057e12fe2b74ba07c892560a2;f because the former should be much 
easier to manipulate by humans), but I guess I'd again be shot down for 
"proposing something like this at such a late date" (I note we are still 
in IETF Last Call).


Regards,   Martin.