|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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  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  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.
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.  http://tools.ietf.org/html/draft-farrell-decade-ni  http://tools.ietf.org/html/draft-hallambaker-decade-ni-params (Note: only  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@xxxxxxxx mailing lists by 2012-07-02. Exceptionally, comments may be sent to iesg@xxxxxxxx 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/