From: "Ronald E. Daniel" <email@example.com> Message-Id: <9507061813.ZM23350@idaknow.acl.lanl.gov> Date: Thu, 6 Jul 1995 18:13:22 -0600 In-Reply-To: Leslie Daigle <firstname.lastname@example.org> To: Leslie Daigle <email@example.com>, firstname.lastname@example.org Subject: Re: Follow up on charter proposal On Jul 6, 4:00pm, Leslie Daigle jumped all over Ron's hot buttons by saying: > I specifically think it is premature to be picking implementations of > URCs before we have an appropriate view of how they fit in with the > rest of the URI structure. I disagree. Strongly. The URC Scenarios and Requirements document was intended to provide this view of how URCs fit in with the rest of the URI structure. At Danvers Mike and I both said that we want to to go to last call soon. There are two things left to change in that draft before I am ready to recommend it to the group for last call. The first is to get one of LANL's security consultants to review the tweaks I have made to the sections about veracity and digital signatures. Because of the blinding pace of our bureaucracy, the contract for that review will not be completed until next week. (As an aside, anyone care to guess when that contract was initiated? Hint - the last digit of the year was 4). The second tweak is to add some stuff to the searching scenarios. Neither of these makes a dramatic change in the overall thrust of the paper. Because the requirements draft is so close to last call status, members of this group are assumed to have a view of how URCs fit in with the rest of the URI architecture. Because of the breadth of scenarios considered, there were several requirements on the URC service that appear, at least initially, to be mutually exclusive. The draft URC spec was developed in light of those scenarios and contradictory requirements. There is certainly work to be done on that spec, but I think that it is flexible enough to meet the needs that will be placed upon it. If not, Terry and I want to know about it. That is why we are challenging people to provide substantive critiques. I reject your assertion that it is premature to start standardizing on how URCs will be implemented. Since URNs are useless without a resolver, which is supposed to be the URC service, we run the risk of being stuck with some half-baked de-facto standard if we don't push ahead on URCs so that they are mostly ready once the other arguments about URNs have been settled. > As a concrete example, my earlier message > exchange with Mark Madsen culminates with me having the impression that > his work is interpreting the _proposed SGML implementation_ of URC's, not > the URC concept in general. Mark's message talks about how his view of searching, which is quite general, can be accomodated using the draft URC spec. To that end, I regard it as an early indication that the draft spec has the sort of extensibility that I want it to have. I certainly never thought of embedding executable methods into the URC, but Mark showed us how it can be accomplished within both the letter and spirit of the draft spec. Certainly the example that was given was SGML-centric. However, the draft spec specifically allows other syntaxes. It even provides an escape hatch for people who want to define new attribute sets using an approach other than SGML DTDs. > Thus, when the rest of the URI work has > caught up with URC's, we'll be left with a legacy of an implementation AND > derivative work that was built before we'd nailed the basics of URNs > and URN resolution. I used to think that we had to have all the URN details settled before we could do URCs. I no longer think so. I think that we are close enough on URNs to make significant progress on URCs. There are disagreements over details of URN syntax and how to find resolvers. The draft URC spec is independent of those two issues. A third URN issue is how to talk with the resolver. HTTP, Whois++, and multiple protocols are the three main camps. The draft URC spec does take a strong stance on this issue, favoring HTTP for a variety of reasons. Ideally I would like to allow multiple protocols, but I have not made any progress on protocol-independent name resolution. People who disagree with this aspect of the draft spec are respectfully requested to make their opinions known. > > Hmmm. I really think that we should have a standard for URCs, since > > they are the means for mapping URNs to URLs and both of those are to > > be standardized. Since standardization is the goal, I don't want to > > put out a charter saying it is not. > > Agreed, we can't keep these things completely hypothetical and stall > out their development, particularly, as Ron points out, when they are > key to other work. I don't think it would be inappropriate to have > experimental specs for imlementation specifically for the purpose of > URN resolution. The current draft spec states that it is incomplete. It also states that we are working to make it a complete spec, in terms of meeting all the requirements set forth in the scenarios document, and that it is intended for the standards track once it is complete. This seems an appropriate level of experimental status to me (but then I would think that, wouldn't I :-) There are lots of experiments that I want to run with URCs. I want to look at using trigrams as the forward knowledge in a global indexing scheme. I am basically being forced into using the URC service to show how ratings info can be utilized to keep little Johnny safe from the depredations of the Internet. (BTW - I will be demoing such a filtering capability to anyone who cares to see it in Stockholm). I am looking at their use for a large metadata task in the DOE, and a similar one in the petroleum industry. I am very interested in Mark Madsen's notion of providing methods in the URC for searching. I would like to see them used to extend CORBA's object location capabilities beyond the current notion of IDL signatures. All of these, with the possible exception of the last, can be accomodated within the framework of the draft URC spec. (I think the last one can be handled as well, but have not sketched out the solution yet). > My point is that I don't believe it is time to base the entire URC > implementation on that one use of URCs; as an example, the Silk software is > already making use of things that we would _like_ to be able to call a type of > URC object, but URC's may be nailed shut before we get all of our > requirements shaken out. As the list of things above shows, URN resolution is far from the only use of URCs that is being considered. The spec would be about 1/10 its size if that were all we were trying to do. In fact, it is quite possible that URN resolution will not even be the killer application for URCs. This business about ratings does not require URNs, since the draft spec has the L2C method. Also, there are a lot of politicians in a panic over it, so it will get attention. I certainly didn't think of such an application while developing the spec, but I regard the fact that it can be accomodated easily is as another data point indicating that the spec has the necessary flexibility. Apologies if the tone of this message seems a little hot. I have acutally been looking forward to sitting down with you at Stockholm to talk about URAs and URCs. I think that the draft spec provides the flexability that you will need for Silk. If it doesn't I want to know ASAP because it should. I look forward to finding out what you want to do with URCs, and to helping figure out how that can be accomodated within the bounds of the draft spec. Regards, -- Ron Daniel Jr. email: email@example.com Advanced Computing Lab voice: (505) 665-0597 MS B-287 TA-3 Bldg. 2011 fax: (505) 665-4939 Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, 87545 tautology: "Conformity is very popular"