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(_at_)ietf(_dot_)org mailing lists by 2012-07-02. Exceptionally,
comments
may be
sent to iesg(_at_)ietf(_dot_)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/