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

[Stephen Farrell <[e-mail]>]

Hi Martin,

On 06/25/2012 11:35 AM, "Martin J. Dürst" wrote:
> Hello Stephen, others,
> 
> On 2012/06/23 6:20, Stephen Farrell wrote:
>>
>> Hi All,
>>
>> I went back through the IETF LC comments and think that we've
>> resolved them all on the list and have the changes in this
>> version [1] of the draft, with the possible exception of those
>> below.
>>
>> The issues raised but not so far obviously resolved on the
>> list were I think:
>>
>> 1) inclusion of content type
>> 2) nih as a URI scheme or not
>>
>> For (1) this version includes ct= in draft-farrell-decade-ni
>> (the only changes to draft-hallambaker-decade-ni-params [2]
>> made so far are those that flow from moving that text), so
>> I'd hope that this version resolves that but would welcome
>> feedback on the new text from folks who commented. I'd hope
>> it should be ok, modulo some text tweaks.
>>
>> For (2) we've left nih in as a URI scheme in this version.
>> We're still in favour of keeping it that way and have added
>> some language about why its there and is done like that. I'm
>> guessing that Martin at least won't be happy (but who knows;-),
>> so again comments are welcome as to whether the new text helps
>> or not.
> 
> When reading your explanations, I had hoped that there would be some
> text along the lines of "different use case" that would really explain
> why two separate schemes are necessary. For example something similar to
> what Graham was mentioning at
> http://www.ietf.org/mail-archive/web/ietf/current/msg73760.html, which I
> understand is similar to what I mentioned as fingerprints in our
> discussion.
> 
> 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.

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

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.

>> We do not include the query string since there is no way to ensure
>> that its value might be spoken unambiguously, and similarly for the
>> authority, where e.g. internationalised forms of domain name could
>> not be usefully spoken.  This leaves the hash value as the only part
>> of the ni URI that we feel can be usefully included.  But since
>> speakers or listeners (or speech recognition) may err, we also
>> include a check-digit to catch common errors.
> 
> It is really strange to assume that text-to-speech software would work
> for English (or ASCII in general), but not for other scripts or
> languages. Sure, the level of text-to-speech software may not be exactly
> the same for each script and each language, but that's no reason to
> prohibit a domain name. There are definitely millions of domain names in
> e.g. Chinese or Japanese or Russian,... that can be spoken and re-typed
> quite unambiguously, and that users would have much less problems with
> than a long string of hex digits. (And we would still have the check
> digit, anyway.) On the other hand, it is quite possible to create domain
> names with ASCII/English that neither humans nor text-to-speech engines
> will be able to pronounce right.

The point is that we only leave in the ascii-hex. The
goal being to reduce this to something that can be
unambiguously spoken, and I think ascii-hex is about
as close as one can get to that. Anything else brings
additional ambiguity and hence is left out.

Its true that the machine-reading/recognition bit is
speculative though, but I don't think its much of a leap,
nor is it really crucial to the argument.

Cheers,
S.


> 
> 
> Regards,   Martin.
> 
> 
>> But in the end we'll go with Barry's consensus call
>> on this if he judges that we're in the rough, rather than the
>> folks who've commented on this topic. In that case I'll put
>> out a version with no nih scheme and the "human speakable"
>> format as just a textual convention (with a check-digit,
>> which'd be plain odd IMO, the uri scheme is the right idea
>> really:-)
>>
>> Please let me know if I've missed addressing anything else
>> or if you have any other comments.
>>
>> Cheers,
>> S.
>>
>> [1] http://tools.ietf.org/html/draft-farrell-decade-ni
>> [2] http://tools.ietf.org/html/draft-hallambaker-decade-ni-params
>>
>> (Note: only [1] is in IETF LC...just in case someone's
>> confused about that:-)
>>
>> On 06/04/2012 03:18 PM, The IESG wrote:
>>>
>>> The IESG has received a request from an individual submitter to consider
>>> the following document:
>>> - 'Naming Things with Hashes'
>>>    <draft-farrell-decade-ni-07.txt>  as Proposed Standard
>>>
>>> The IESG plans to make a decision in the next few weeks, and solicits
>>> final comments on this action. Please send substantive comments to the
>>> [e-mail] mailing lists by 2012-07-02. Exceptionally, comments
>>> may be
>>> sent to [e-mail] instead. In either case, please retain the
>>> beginning of the Subject line to allow automated sorting.
>>>
>>> Abstract
>>>
>>>
>>>     This document defines a set of ways to identify a thing using the
>>>     output from a hash function, specifying URI, URL, binary and human
>>>     "speakable" formats for these names.  The various formats are
>>>     designed to support, but not require, a strong link to the
>>> referenced
>>>     object such that the referenced object may be authenticated to the
>>>     same degree as the reference to it.
>>>
>>>
>>>
>>>
>>> The file can be obtained via
>>> http://datatracker.ietf.org/doc/draft-farrell-decade-ni/
>>>
>>> IESG discussion can be tracked via
>>> http://datatracker.ietf.org/doc/draft-farrell-decade-ni/ballot/
>>>
>>>
>>> The following IPR Declarations may be related to this I-D:
>>>
>>>     http://datatracker.ietf.org/ipr/1773/
>>>     http://datatracker.ietf.org/ipr/1775/
>>>
>>>
>>>
>>>
>>>
>>
>>