# Re: Single protocol for UR*?

Mitra (mitra@path.net)
Fri, 29 Oct 1993 10:13:07 PDT

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Peter Deutsch: "Re: Single protocol for UR*?"
- Previous message: Peter Deutsch: "Re: options, not nesting?"

    From: mitra@path.net (Mitra)

    Date: Fri, 29 Oct 1993 10:13:07 PDT

    In-Reply-To:  Peter Deutsch <peterd@bunyip.com>

    To: peterd@bunyip.com, marca@ncsa.uiuc.edu

    Subject: Re: Single protocol for UR*?

    Message-Id:  <9310291013.aa25431@pandora.sf.ca.us>

On Oct 28, 7:30pm, Peter Deutsch wrote:
} > 1) Is their software available to do this, (not a kit, but a real
} > peice of portable - publicly available code). Not that I'm asking you
} > to give away your code, but if its available it makes it a better contender :-)
}
} We released the first draft of _our_ server a couple of
} months ago, with full source, as have a couple of other
} people. We support the basic protocol, although not all the
} options, nor do we do centroids (yet). We use a modified
} WAIS search engine which allows separate attribute and
} value searches.
}
}
} Our code is freely available. The only restriction we
} place on this is that it not be used in commercial
} products without a release from us. We encourage people to
} use it and are not out to make any money off of it, we
} just don't want to make anyone else a lot of money without
} at least a nod in our direction. If you want to use any of
} it in a product, let us know and we'll work it out.

Peter - how do you define "commercial" - for example, of the three
following cases, which would be commercial by your current requirements.
1) A company integrating your work into a product and selling that.
2) A company offering the service of doing URN->URL lookup to paying
clients (either paying users, or people paying for stuff to be
registered)
3) A company using your code to register its own URN/URL's and offering
resolution of those URN/URLs for free on the net.
} > 2) Exactly what extensions to DNS would be needed to make this work, I'm
} > presuming it could be handled by C calls to DNS routines, since we cant
} > expect every client to implement the DNS. I dont quite understand your
} > detailed proposal, but it might be that we can do this by just adding
} > information to the DNS - and making standard "gethostbyname" calls.
}
} I'm not sure _any_ extensions are needed, since we might
} conceivable encode the needed information in a text
} record, or as subdomain names, but I do recall a posting
} from John Postel this week (Today? Blue? I've completely
} lost track) suggesting that additions to DNS should take
} the form of another type and this would probably the way
} to go.

This is kindof covered by my question about the detailed protocol, you
seem to imply asking more questions of the DNS, and I want to know if we
can just extend the data in the DNS, and if so how a program would use
it, I'm certainly not a DNS expert.

} Thus, we'd probably want to define some form of "URL" type
} or "Naming_authority" type, or some such that would encode
} the hostname, port and protocol type for further queries.
} If this is needed at all, I suspect it would be fairly
} simple to work up, and as I suggested it would encode
} something that looked like a URL pointing to the server to
} start asking questions. At this point, I cede the floor to
} somebody who actually knows something about DNS. Anybody?
}
}
} > 3) How would whois++ return something looking like either Mike, My, or
} > Ole's nested templates, Previous whois++ documents didnt look like
} > they could handle this.
}
} I must confess that I've lost track of the current URC/M/T
} proposals, but I don't think I've seen anything go by that
} we couldn't accomodate. After all, WHOIS++ assumes that
} data is a series of tagged attribute-value pairs. What I've
} seen of the URC thread seems to make similar assumptions.
} If there are deeper problems, you guys can point them out
} and we'll work on them.

All three format proposals (Mike's, mine, and Ole's) propose being able
to offer hierarchical information - at a minimum asking for hte template
of a URN needs to be able to return meta information on that URN. And a
list of URL's with meta-information on each. This has to be done in a
single query to avoid the session setup and take-down delays of asking
for meta-information on each URL.

} > It would be really good to see similar responses from Rob (DNS) and
} > Marca (HTTP), including a detailed example of a sample interaction
} > from the time a client receives a URN to the time it can call a
} > access library (e.g. a call to Prospero to return a gopher item).
}
} I can give you the protocol queries you'd need, they're
} trivial. If you want the specific C code I will take a
} step back here and go talk to Alan, Bill and maybe Kevin
} Gamiel, who worked on our server or its documentation. I
} seem to recall that somewhere in there is a routine that
} takes a valid query and returns the result, but I just
} asked Alan and he can't recall for sure, either. It
} certainly wouldn't be killer code to write if it doesn't
} already exist.

Peter, What I meant by protocol queries wasnt C-code, but something
like:
Xyz server sends a URN of the form urn:anamespace/pubid:123456
Client looks up "namespace.urn" in regular (unmodified) DNS
DNS returns ip address of the whois++ server for namespace.urn
lets assume this is urns.path.net
Client sends "Template=URM,URN=urn:anamespace/pubid:123456" to
urns.path.net on port 987 (registered as URN port with
iana)
urns.path.net sends back the following record (Using my
proposed URM format.)
URN: anamespace/pubid:123456
Author: mitra
URL: gopher://xyz.edu//1/Adocument
Cost: US$ 10.00
URL: http://xyz.edu/copys/of/everything/Adocument
Cost: 0

} I agree that gateways would be easy using the scheme I
} proposed, assuming you have a routine that can take a
} string and return a query. If there are no serious
} objections in the next week or so to this off-hand
} proposal, this may all come together faster than I thought.

I see two possible sets of objections
a) we shouldnt define a single protocol
b) we should define a single protocol - based on HTTP, or DNS or ...

} Wow!

Yes - lets have some more input ..... is this the kind of idea people
like or are Peter and I off base?

- Mitra

- Next message: Peter Deutsch: "Re: Single protocol for UR*?"
- Previous message: Peter Deutsch: "Re: options, not nesting?"