Re: APPSDIR review of draft-farrell-decade-ni-07, major design issue (one or two URI schemes)

Graham Klyne <GK@ninebynine.org> Fri, 15 June 2012 17:37 UTC

Return-Path: <GK@ninebynine.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2E321F8673 for <ietf@ietfa.amsl.com>; Fri, 15 Jun 2012 10:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.116
X-Spam-Level:
X-Spam-Status: No, score=-5.116 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DATE_IN_PAST_06_12=1.069, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Xos4gohsZpd for <ietf@ietfa.amsl.com>; Fri, 15 Jun 2012 10:37:19 -0700 (PDT)
Received: from relay9.mail.ox.ac.uk (relay9.mail.ox.ac.uk [163.1.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC6F21F8672 for <ietf@ietf.org>; Fri, 15 Jun 2012 10:37:18 -0700 (PDT)
Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay9.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from <GK@ninebynine.org>) id 1SfaSN-0003Aj-T5; Fri, 15 Jun 2012 18:37:11 +0100
Received: from arl-d-234.arl.org ([192.100.21.234] helo=Eskarina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <GK@ninebynine.org>) id 1SfaSM-0005jP-4E; Fri, 15 Jun 2012 18:37:10 +0100
Message-ID: <4FDB1319.7040501@ninebynine.org>
Date: Fri, 15 Jun 2012 11:48:57 +0100
From: Graham Klyne <GK@ninebynine.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: APPSDIR review of draft-farrell-decade-ni-07, major design issue (one or two URI schemes)
References: <4FCDD499.7060206@it.aoyama.ac.jp> <4FCDE96E.5000109@cs.tcd.ie> <4FD7083A.6080502@it.aoyama.ac.jp> <4FD712E8.7010506@cs.tcd.ie> <4FD73E76.7050105@it.aoyama.ac.jp> <4FD74D94.4020408@cs.tcd.ie>
In-Reply-To: <4FD74D94.4020408@cs.tcd.ie>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Oxford-Username: zool0635
X-Mailman-Approved-At: Mon, 18 Jun 2012 05:41:05 -0700
Cc: IETF discussion list <ietf@ietf.org>, "draft-farrell-decade-ni@tools.ietf.org" <draft-farrell-decade-ni@tools.ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jun 2012 17:37:22 -0000

Stephen,

(Personal hat on)

I've followed elements of this exchange.  I must confess that when I read 
through the draft previously, I didn't really pay attention to the nih: parts.

I can see that there are distinct use-cases here, and I think you have 
reasonable grounds for not wanting to combine them.

What I can't see is why the speakable form (nih:) needs to be a URI scheme - 
what are the envisaged contexts of use where the information provided by an nih: 
URI actually needs to be a URI, as opposed to just, say, a simple string?

In all the uses I can think of for ni:, I don't see a corresponding use for a 
speakable form.  I think you said somewhere in this exchange, nih: is intended 
to be used to confirm some information that you already have.  As such, I'm not 
seeing how it can be said to identify a resource.

#g
--

On 12/06/2012 15:09, Stephen Farrell wrote:
>
> Martin,
>
> I honestly don't think this exchange is going
> anywhere new so I've not provided blow-by-blow
> answers below.
>
> We (the authors) think ni and nih are better
> kept separate because the use-cases and
> requirements differ. And that's what the
> limited amount of running code does.
>
> I think I've explained that, and I have no
> intention whatsoever of getting into the "write
> up the use-cases and requirements" game that
> too-often happens in the IETF when its neither
> needed nor productive. (Regardless of whether
> the game is played with I-Ds or email.)
> Sometimes that is useful, but not here IMO.
>
> You disagree, which is fine. You think ni and nih
> should be merged because they don't differ
> sufficiently, (I think), and (I guess) because
> you think that new URI schemes are more expensive
> than what you see as the differences between
> these two proposed schemes warrant.
>
> I suggest we see if anyone else chimes in on
> this aspect (so far nobody has, despite a quite
> active IETF LC:-) and if not leave it to the
> sponsoring AD to figure out what, if anything,
> needs doing at the end of IETF LC.
>
> Cheers,
> S.
>
> PS: Many thanks for all the other good comments,
> though we disagree on this one, you've helped
> make the draft better for sure.
>
>
> On 06/12/2012 02:04 PM, "Martin J. Dürst" wrote:
>> Hello Stephen,
>>
>> On 2012/06/12 18:59, Stephen Farrell wrote:
>>>
>>> Hi Martin,
>>>
>>> On 06/12/2012 10:13 AM, "Martin J. Dürst" wrote:
>>>> Hello Stephen,
>>>>
>>>> This mail responds to your points on the main technical issue that I
>>>> have identified.
>>>>
>>>> On 2012/06/05 20:11, Stephen Farrell wrote:
>>>>
>>>>> On 06/05/2012 10:42 AM, "Martin J. Dürst" wrote:
>>>>>> Hello everybody,
>>
>>>>> Major design issue:
>>>>>>
>>>>>> The draft defines two schemes, which differ only slightly, and mostly
>>>>>> just gratuitously (see also editorial issues).
>>>>>> These are the ni: and the nih: scheme. As far as I understand, they
>>>>>> differ as follows:
>>>>>>                                        ni:                nih:
>>>>>> authority:                          optional           disallowed
>>>>>> ascii-compatible encoding:          base64url          base16
>>>>>> check digit:                        disallowed         optional
>>>>>> query part:                         optional           disallowed
>>>>>> decimal presentation of algorithm:  disallowed         possible
>>>
>>> I'll note in passing that the two schemes differ in all those
>>> respects. You may disagree with our design, but basically you're
>>> showing that the two differ in pretty much all possible ways
>>> other than that both include a hash value.
>>>
>>>>>>
>>>>>> The usability of URIs is strongly influenced by the number of
>>>>>> different
>>>>>> schemes, with the smaller a number, the better. As a somewhat made-up
>>>>>> example, if the original URIs had been separated into httph: for HTML
>>>>>> pages and httpi: for images, or any other arbitrary subdivision
>>>>>> that one
>>>>>> can envision, that would have hurt the growth and extensibility of the
>>>>>> Web. Creating new URI schemes is occasionally necessary, and the ideas
>>>>>> that lead to this draft definitely seem to warrant a new scheme
>>>>>> (*), but
>>>>>> there's no reason for two schemes.
>>>>>> [(*) I know people who would claim the the .well-formed http/https
>>>>>> thing
>>>>>> is completely sufficient, no new scheme needed at all.]
>>>>>>
>>>>>> More specifically, if the original URIs had been separated into httpm:
>>>>>> (for machines) and httph: (for humans), the Web for sure wouldn't have
>>>>>> grown at the speed it did (and does) grow. In practice, there are huge
>>>>>> differences in human 'speakability' for URIs (and IRIs, for that
>>>>>> matter); compare e.g. http://google.com with
>>>>>> http://www.google.co.jp/#sclient=psy-ab&hl=en&site=&source=hp&q=hash&oq=hash&aq=f&aqi=g4&aql=
>>>>>>
>>>>>>
>>>>>>
>>>>>> (which I have significantly shortened to hopefully eliminate potential
>>>>>> privacy issues), or compare the average mailto: URI with the average
>>>>>> data: URI. However, what's important is that there never has been a
>>>>>> strong dividing line between machine-only and human-only URIs or
>>>>>> schemes, the division has always been very gradual. Short and mainly
>>>>>> human-oriented URIs have of course been handled by machines, and on
>>>>>> the
>>>>>> other hand, very long URIs have been spoken when really necessary.
>>>>>> "Speakability" has been maintained to some extent by scheme designers,
>>>>>> and to some extent by "survival of the fittest" (URIs that weren't
>>>>>> very
>>>>>> speakable (or spellable/memorizable/guessable/...), and their Web
>>>>>> sites,
>>>>>> might just die out slowly).
>>>>>>
>>>>>> It should also be noted that the resistance against multiple URI
>>>>>> schemes
>>>>>> may have been low because there are so many different ways to express
>>>>>> hashes in the draft anyway, and one more (the nih: section is the last
>>>>>> one before the examples section) didn't seem like much of a deal
>>>>>> anymore. But when it comes to URIs, one less is a lot better than one
>>>>>> more.
>>>>>>
>>>>>> In the above ni:/nih: distinction, nih: seems to have been added as an
>>>>>> afterthought after realizing that reading an ni: URI aloud over the
>>>>>> phone may be somewhat suboptimal because there is a need for repeated
>>>>>> "upper case" - "lower case" (sure very quickly shortened to "upper" -
>>>>>> "lower" and then to "up" - "low" or something similar). It is not a
>>>>>> bad
>>>>>> idea to try to make sure that IETF technology, and URIs in particular,
>>>>>> are accessible to people with certain kinds of dislexya. (There are
>>>>>> indeed people who have tremendous difficulties with distinguishing
>>>>>> upper- and lower-case letters, and this may or may not be connected
>>>>>> with
>>>>>> other aspects of dislexya.) It is however totally unclear to this
>>>>>> reviewer why this has to lead to two different URI schemes with other
>>>>>> gratuitous differences.
>>>>>>
>>>>>> Finding a solution is rather easy (of course, other solutions may also
>>>>>> be possible): Merge the schemes, so that authority, check digit, and
>>>>>> query part are all optional (an authority part and/or a query part may
>>>>>> very well be very useful in human communication, and a check digit
>>>>>> won't
>>>>>> hurt when transmitted electronically) and the decimal presentation of
>>>>>> the algorithm is always allowed, and use base32
>>>>>> (http://tools.ietf.org/html/rfc4648) as the encoding. This leads to a
>>>>>> 16.6% less efficient encoding of the value part of the ni: URI, but
>>>>>> given that other URI-related encodings, e.g. the %-encoding resulting
>>>>>> when converting an IRI to an URI, are much less efficient, and that
>>>>>> URI
>>>>>> infrastructure these days can handle URIs with more than 1000 bytes,
>>>>>> this should not be a serious problem. Also, there's a separate binary
>>>>>> format (section 6) that is more compact already.
>>>>>
>>>>> I strongly disagree with merging ni&    nih. Though that clearly
>>>>> could be done, it would be an error.
>>>>>
>>>>> There was no such comment on the uri-review list and the designated
>>>>> expert was happy. That review was IMO the time for such comments
>>>>> and second-guessing the designated expert at this stage seems
>>>>> contrary to the registration requirements. So process-wise I
>>>>> think your main comment is late.
>>>>
>>>> First, if IETF Last Call is too late to make serious technical comments
>>>> on drafts, then I think we have to rename it to IETF Too-Late Call.
>>>>
>>>> Second, designated experts are there to check for minimum requirements
>>>> for a registration, and to give advice as they see fit (and have time).
>>>> I'm myself a designated expert on "Character Sets", and I have
>>>> definitely in the past approved, and would again in the future approve,
>>>> registrations for stuff on which I would complain strongly if the
>>>> question was "is this a good technical solution".
>>>>
>>>> Graham Klyne, the designated expert for URI scheme registrations, has
>>>> confirmed offline that he does not see his role as "expert reviewer" as
>>>> judging the technical merit of a URI scheme proposal.
>>>
>>> While that's fair enough. Its also fair to note that there was
>>> discussion of the this document on the uri-review list but this
>>> aspect was not raised at all. That list is called "uri-review"
>>> and from its archives it does seem to frequently do more than
>>> just check the paperwork (including quite a few mails from you:-).
>>
>> Oh well. I'm not sure how familiar you are with the IETF :-), but it's
>> basically all a volunteer organization. So even more than in an
>> organization where people are getting paid, some things happen to get a
>> lot of attention and other things happen to get less attention than
>> maybe they would deserve. And most people have their day jobs, and
>> occasionally miss a mail or two, or even a few more. And many people are
>> on many lists and just skim them until something catches their eye, and
>> ignore many threads. If you don't do anything like this and survive, I'd
>> like to know how :-).
>>
>> So the uri-review list, like any other IETF (or other) list, can get
>> excited about stuff, sometimes for good reasons, or can just ignore some
>> aspects of some proposal. It's unfortunate, but it's something we have
>> to live with. You can't ask everybody on that list to take the same
>> amount of time to look at all the proposals that e.g. a Security
>> Directorate or Apps Area Directorate reviewer is using.
>>
>>
>>>>> But in any case, I also think you're wrong technically in this>>   case.
>>>>
>>>> Let's see. I hope we agree that we should come to a conclusion on this
>>>> issue on technical merits, rather than on process details.
>>>
>>> Sure.
>>
>> Good.
>>
>>>>> nih *is* intended for a corner case,
>>>
>>> Let me emphasise the above. nih is not intended to be used
>>> broadly, nor often. If you want a hash-based URI scheme for
>>> users to speak that is for broad frequent use then I think
>>> you are free to try design one. But nih is not that and is
>>> not intended to be that.
>>
>> Then, at the barest minimum, don't sell it as that. The only thing the
>> draft essentially says is "use this if you want to read/speak it". Now
>> you are saying "don't use that for users to speak, unless in specific
>> corner cases", but you still haven't told me or the readers of the draft
>> what these corner cases are, and why the SHOULD/MUST not use it
>> otherwise even if they might think it makes sense.
>>
>> The second, more general advice is of course to not design URIs for
>> corner cases, because URIs work best if they are used widely. (There may
>> be a very tiny chance that your case is different, but even after
>> reading all your mail, I haven't understood that.)
>>
>>
>>> (And I'm not sure such a beast
>>> could really be done well.)
>>
>> Speaking 256 or so bits of random data aloud is in no way going to be
>> terribly easy :-).
>>
>>
>>>>> where humans need to speak these
>>>>> URIs and was added as a direct result of requirements from the core
>>>>> WG and not as an afterthought. ni URIs are not intended for that
>>>>> and so there really are IMO different requirements, (esp. e.g.
>>>>> checkdigit) that are best met with different schemes.
>>>>
>>>> I agree that the value of a checkdigit is very limited for communication
>>>
>>> s/very limited/useless/
>>>
>>>> among machines (and for communication among humans with the help of
>>>> machines, such as in the case of email).
>>>>
>>>> On the other hand, I can't understand why (even assuming we needed a
>>>> separate scheme) there is no authority and no query part on nih.
>>>
>>> The main intent of nih is to allow entry of something that
>>> confirms something else (e.g. a public key) that is already
>>> present.
>>
>> At least a little bit of information about the "use case", but this just
>> leads to more questions:
>>
>> Do you need an URI for that? (Isn't that what people are supposed to do
>> with fingerprints these days?)
>>
>> How/where would a user input that URI e.g. in a browser?
>>
>> Would copy/paste from an email or a Web page be fine?
>>
>> Would entry be needed, or could it just be checked? (I understand that
>> forcing a user to enter the data is way safer than believing her that a
>> check was made, but then it's also way more tedious, and many users will
>> just switch to different software.)
>>
>> Can ni: URIs also be used for the same purpose? If not, why not (they
>> essentially contain the same information)?
>>
>> What about other URIs, starting e.g. with http:?
>>
>> I won't claim that this list of questions is exhaustive, but I hope it's
>> a good start.
>>
>>
>>> There is no need for an authority for that, for
>>> the use-cases we have. We could speculate about other potential
>>> use-cases but we'd rather not speculate like that when there's
>>> no need to.
>>
>> There was a lot of stuff that we take for granted today that Tim
>> Berners-Lee didn't speculate when he designed the first URI schemes. But
>> if he had designed these schemes with only corner cases in mind, he
>> wouldn't have invented the Web :-). (sorry about an analogy again)
>>
>>
>>>> For the authority, I'd assume that it would be as useful when the URI is
>>>> transmitted e.g. over the phone as when it is transmitted e.g. over
>>>> email.
>>>
>>> We don't have a use for that that I know about.
>>
>> Do you mean the "over the phone" part or the authority part? (assuming
>> the later below)
>>
>>> I agree
>>> it could be done, but then I think it'd also impact on
>>> usability, which will be pretty crap no matter what's
>>> done.
>>
>> Reading "example.com" or some equivalent domain name in addition to a
>> long hex string shouldn't really make matters much worse.
>>
>>> But making usability worse also seems wrong.
>>
>> My understanding is that there are some cases where things will be found
>> with authority, but not without. If that's right, then I'm sure users
>> will prefer to find what they are looking for, after aurally
>> transmitting 256 or thereabout bits, even at the cost of an additional
>> domain name (and a few slashes), which are the easiest parts to get
>> across the line quickly and correctly.
>>
>>
>>> Not
>>> having an authority also seems to work fine for PGP keys
>>
>> That the lack of authority works in some cases is perfectly okay. But
>> it's not an argument for not allowing authority for cases (even those
>> that maybe you're not seeing yet) where it is or will be useful.
>>
>>
>>> and the lack of an authority does get rid of some threats,
>>> if the nih URI is used for something security-sensitive.
>>
>> Which would mean that ni: has these threats, yes? Where are they
>> described? I don't remember seeing them in the security section.
>>
>>
>>>> For the query part, there are already various ideas and proposals
>>>> floating around,
>>>
>>> Where? If you mean draft-hallambaker-decade-params
>>
>> Correct.
>>
>>> then
>>> we (the authors of that) don't think those are useful for
>>> nih names.
>>
>> Why not? And what if others think they would be useful?
>>
>>
>>>> and at least some of them would be of interest for when
>>>> the URI is transmitted e.g. over the phone. Also, even if we currently
>>>> didn't have any actual proposals for query parameters, I think it would
>>>> be a very bad idea to exclude them a priori for transmission e.g. over
>>>> the phone.
>>>
>>> I disagree that there is any "very bad idea" here.
>>>
>>>>> Merging ni/nih would also add more complexity for no benefit,
>>>>> which would be a bad idea.
>>>>
>>>> Can you please explain what kind of complexity would have to be added?
>>>
>>> I think its obvious actually. In your table above you highlighted
>>> 5 ways in which ni and nih differ. Merging all those yields loads
>>> of combinations, which makes for complexity.
>>
>> Well, if your implementation is a big switch with 32 cases, one for each
>> combination, with no code sharing, then indeed you get complexity. But I
>> hope we agree that that's very bad design, and totally unnecessary. It's
>> very straightforward to go through the components one-by-one and deal
>> with them (hint: I'd start with the check digit).
>>
>> On the other hand, the complexity you get from query parameters is
>> potentially huge, because, contrary to the basic syntax, we don't know
>> for sure what combinations of parameters people will dream up, and how
>> these will interact.
>>
>>
>>>> In terms of specification, merging the two schemes doesn't seem to be
>>>> difficult or complex at all. Also, in terms of implementation, the only
>>>> additions to the ni: scheme that become necessary are the check digit
>>>> and the expression of the "suite id" as a decimal. It's very difficult
>>>> for me to imagine that this would add significant complexity to an
>>>> implementation; if code for nih: exists, that can mostly just be moved
>>>> over.
>>>
>>> Feel free to look at our code. (With the caveat that I'm a crap
>>> programmer so close your eyes a bit when you look at the 'C' code:-)
>>>
>>>>> Your analogy about httpm/h may appear reasonable, but it is always
>>>>> unreasonable to draw conclusions from analogies. It is also unwise
>>>>> to reason from counterfactuals, which we'd also be doing if we
>>>>> accepted your argument. So I find that speculation utterly useless
>>>>> to be honest.
>>>>
>>>> It is definitely unreasonable to draw conclusions from analogies *only*.
>>>
>>> I only saw the analogy. What in your httpm/h argument is not
>>> couterfactual analogy?
>>
>> Do you claim that it's not true that URIs are often transferred
>> electronically, often transferred on paper, and often spoken, and that
>> these sets for which these activities happen overlap? If you think that
>> has to be different for ni:/nih:, you have to convince me, not the other
>> way round.
>>
>>
>>>> But if you think that the httpm/h analogy is wrong, and that ni/nih is
>>>> different, could you please explain *what* is different?
>>>
>>> We have real use cases for ni and nih and we think they differ.
>>> I'd be repeating myself to say why again.
>>
>> You're still very vague on these "real use cases". Confirmation of PGP
>> keys by speaking the URI aloud seems to be your main/only use case for
>> nih:. But I'm only guessing, because you haven't really explained this yet.
>>
>>>>> In this case, we are dealing with different requirements so this
>>>>> should stay as-is.
>>>>
>>>> If "different requirements" is your main (or only) real argument,
>>>
>>> That would be a valid argument.
>>
>> It would only be a valid argument if these are requirements that can't
>> be consolidated.
>>
>>
>>>> could
>>>> you at least explain exactly how they are different?
>>>
>>> I did that above. Asking for an "exact" explanation seems
>>> like asking the same thing again.
>>
>> Here are the pieces of text from above that I can at least in some way
>> link to actual requirements:
>> "nih is not intended to be used broadly, nor often."
>> "The main intent of nih is to allow entry of something that
>> confirms something else (e.g. a public key) that is already
>> present."
>>
>> Is that all there is? Or did I miss something? Maybe it would help this
>> discussion if you wrote a few paragraphs of free-standing text
>> explaining the use cases (and restrictions, and reasons for these) for
>> both schemes. It may turn out to be a valid addition to the document at
>> the very minimum. (I'm not asking for an independent "use cases and
>> requirements" draft :-)
>>
>>
>>>> Just that one
>>>> requirement came from the core WG and others from other WGs or other
>>>> parties doesn't help me to understand how the actual requirements
>>>> differ. (Please note that even if the requirements differ, that doesn't
>>>> mean that we need different technology to address them.)
>>>
>>> Perhaps not. But that was the design choice we made and its
>>> a valid one.
>>
>> Given the more than 20 years of experience we have of how URIs are
>> handled on the Web and around it, I have very good reasons to strongly
>> doubt that this is a good design choice.
>>
>>
>>>> Why do you say that ni: URIs are not intended for humans to speak?
>>>
>>> So phone me up and say this:
>>>
>>>     ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q
>>
>> So apart from the upper/lower problem, would the equivalent nih: URI be
>> any better?
>>
>>>> What
>>>> am I supposed to do if I got an ni: URI in a mail message and call you
>>>> on the phone to tell you about that?
>>>
>>> Not my problem actually, but I guess most people might
>>> say "remember that mail you sent me with all that gobbledygook
>>> nonsense - what the hell was that about?" :-)
>>
>> I think "tell you about it" should have been "speak it out to you".
>>
>>
>>>>    If I want to send somebody the
>>>> information in an ni: URI by mail, should I use only the ni: version or
>>>> only the nih: version, or both, if I can't exclude that the recipient
>>>> may want to relay this information via voice?
>>>
>>> You can try either and let me know what works. This seems like
>>> a very artificial use-case for ni.
>>
>> Why artificial? Long URIs get spoken over the phone once in a while. And
>> I really don't understand why this is "very artificial" for ni:, but
>> "indispensable" for nih:.
>>
>>
>>>>> Finally, we have (some, early,) running code that matches the
>>>>> current draft and that ought also count for something
>>>>
>>>> How much?
>>>
>>> Feel free to go look and see. [1] I've not counted lines of
>>> code, but we have c, python, ruby and clojure library
>>> implementations and some apps and other bits and pieces.
>>>
>>>      [1] http://sourceforge.net/projects/netinf/
>>>
>>>> The boiler plate on every ID is pretty clear that they are not
>>>> set in stone. Also, the changes needed to merge the two schemes are not
>>>> rocket science, quite to the contrary. (I herewith volunteer to fix the
>>>> Ruby version, just to show)
>>>
>>> I didn't say our code is set in stone. I said that running code
>>> counts.
>>>
>>> I didn't say a merge would require rocket science.
>>
>> It somehow sounded like this.
>>
>>> I said it'd be
>>> a bad idea and would produce a worse result.
>>
>> Can you substantiate that? The discussion on use cases is still open,
>> and the argument with all the 32 combinations also didn't fly.
>>
>>>>> when compared
>>>>> to a change that would be a gratuitous dis-improvement
>>>>
>>>> In what sense would merging the two schemes be a dis-improvement? Can
>>>> you please explain?
>>>
>>> I believe I did that above.
>>
>> Very marginally, perhaps. More information would definitely help.
>>
>>>>> based it
>>>>> seems upon dubious argument
>>>>
>>>> If you think that my arguments are dubious, please explain exactly why.
>>>
>>> I believe I did that above. (To be clear: not all your argument is
>>> dubious
>>
>> Thanks for some encouragement :-).
>>
>>
>>> but the httph/m part is IMO.)
>>
>> I'm sorry that I started out with that analogy, but I thought it would
>> be easy to understand. You seem to be caught in the specific use/corner
>> cases, but I'm trying to look at the long term big picture.
>>
>>
>>>>> that is also offered at the wrong
>>>>> point in the process.
>>>>
>>>> See above. If there's something wrong with IETF Last Call, or with the
>>>> fact that the Apps Area Directorate does reviews (which I don't think),
>>>> then that should be addressed separately. For this discussion, I hope we
>>>> can concentrate on technical issues.
>>>
>>> Right. But let's not ignore the fact that the uri-review
>>> list had sight of this at the end of April.
>>
>> [If you keep insisting, why don't you check your MUA and look at all the
>> messages I sent on the draft. You may be surprised, but I seriously hope
>> you will stop bringing up "uri-review" again.]
>>
>>
>>> Bottom line - we have use-cases and a valid design and running
>>> code that as far as we know works and I see no reason to make
>>> the change you'd like, which would make thing worse IMO.
>>
>> It may look like some more work in the short time, but it will make
>> things more general and create more potential for the future.
>>
>>
>> Regards,    Martin.
>>
>>
>