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

[Dirk Kutscher <[e-mail]>]

Hi Martin,

thanks for the review and advice.

I'd agree that the "confirmation use case" should be highlighted (described better) . Will do that by adding some text along the lines you mentioned to the intro.

How about this:
----
In addition, we also define a ".well-known" URL equivalent, and a way to include a hash as a segment of an HTTP URL, as well as a binary format for use in protocols that require more compact names.  Moreover, we define a human-speakable text form that allows for reading out (and understanding) names so that they can be transferred over voice connections, which can be used for verifying the presence of an adequate hash or key information.
----

As to the detailed suggestions, I don't think it is really necessary to rename 'nih' to 'fingerprint' and to get rid of "Human-speakable" as a description for it. In the end, those URIs are essentially "human-speakable" -- so that they can be used for confirming the presence/absence of resources.

I don’t like 'fingerprint' as a scheme identifier, because a) those URIs, unlike PK fingerprints, actually contain the complete hash information and b) because it does not convey the relationship to 'ni'. I think it's fine to stick to 'nih' here.

I agree that the nid separators can be useful. Would be OK for me to still add them.

Thanks,
Dirk


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of "Martin J. Dürst"
Sent: Montag, 2. Juli 2012 13:07
To: Stephen Farrell
Cc: Graham Klyne; [e-mail]
Subject: Re: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard

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.