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

["Martin J. Dürst" <[e-mail]>]

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.