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

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

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.


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


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