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

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 02 Jul 2012 20:07:08 +0900

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.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 02 Jul 2012 12:26:42 +0100

Hi Martin,

> could have avoided a lot of useless discussion.

I agree this has been harder than it ought have been for some
reason. I guess that just happens sometimes.

> than myself to write such text :-(.

Well, you seemed motivated:-)

> "Form for resource confirmation" (three occurrences).

I could live with more-or-less all of that. Will check if coauthors
can similarly. I think "human-speakable" still needs to be mentioned
though, since that's why its designed as it is, but I like those
changes generally.

> easier to manipulate by humans), 

Would rather not change the uri scheme name at this point, unless
a load of people prefer it, but the idea of optional "-" delimiters
seems useful all right.

> but I guess I'd again be shot down for

Just:-) But improvements don't stop at the end of IETF LC and your
suggestions above are, I think, improvements.

Any other opinions before I go make changes along these lines?

Cheers,
S.

---

From: Dirk Kutscher <[email-masked]>
Date: Tue, 3 Jul 2012 12:04:24 +0000

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

Hello Stephen,

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

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

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