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 >>> ietf@ietf.org mailing lists by 2012-07-02. Exceptionally, comments >>> may be >>> sent to i...@ietf.org 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/ >>> >>> >>> >>> >>> >> >>
