Re: Follow up on charter proposal

Ronald E. Daniel (rdaniel@acl.lanl.gov)
Thu, 6 Jul 1995 18:13:22 -0600


From: "Ronald E. Daniel" <rdaniel@acl.lanl.gov>
Message-Id: <9507061813.ZM23350@idaknow.acl.lanl.gov>
Date: Thu, 6 Jul 1995 18:13:22 -0600
In-Reply-To: Leslie Daigle <leslie@bunyip.com>
To: Leslie Daigle <leslie@bunyip.com>, uri@bunyip.com
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: rdaniel@acl.lanl.gov
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"