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: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of "Martin J. Dürst"
Sent: Montag, 2. Juli 2012 13:07
To: Stephen Farrell
Cc: Graham Klyne; ietf(_at_)ietf(_dot_)org
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.