Hello Stephen,
On 2012/06/25 21:05, Stephen Farrell wrote:
On 06/25/2012 11:35 AM, "Martin J. Dürst" wrote:
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.
That sentence reads:
"Sometimes a name may need to be referred to in a format that is easy
or unambiguous for humans to read out, for example, over the phone."
I continue to be convinced that this is not a separate use case. URIs
are not a priori separable into those that are written down on napkins
(or copy-pasted into emails,...) and those that are spoken over the phone.
If I send you an URI with a hash, I don't know whether you read your
mail with your eyes (for which ni: seems appropriate) or whether you
have a screen reader that does a text-to-speech conversion (for which
nih: seems to be appropriate).
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
them."
[1] http://www.ietf.org/mail-archive/web/ietf/current/msg73758.html
I think what Graham refers to as the "distinct use-cases" is identified
in the second-to-last sentence of his mail:
"I think you said somewhere in this exchange, nih: is intended to
be used to confirm some information that you already have."
For all that I know about URIs, that would be consistent with Graham's
questioning of the need for an URI scheme (because a resource is only
confirmed, not identified). It would also be supported by the fact that
the examples for "nih:" show only shortened hashes (which, as far as I
understand, are okay for confirmation but not for search).
[One of my editorial comments was to streamline the examples so that the
examples for ni: and nih: would appear with the same truncation lengths,
in pairs. When I wrote that comment, I didn't realize that there might
be a deeper reason for having different truncation lengths for ni: and
nih:, mostly because that wasn't really very much explained in the draft.]
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. If identification is the main
purpose in both cases, then two separate schemes don't make sense.
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.
Let's for a moment concentrate on what is use case, and what are the
design properties that follow from that. We can go back to language once
we have made some progress on substance.
Regards, Martin.