# Re: Single protocol for UR*?

Peter Deutsch (peterd@bunyip.com)
Fri, 29 Oct 1993 14:41:55 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Fred Swartz: "Re: Thumbnail Sketch of the UR* Arena"
- Previous message: Peter Deutsch: "Re: options, not nesting?"
- Maybe in reply to: Peter Deutsch: "Single protocol for UR*?"
- Next in thread: Peter Deutsch: "Re: Single protocol for UR*?"

    Message-Id: <9310291841.AA06025@expresso.bunyip.com>

    From: Peter Deutsch <peterd@bunyip.com>

    Date: Fri, 29 Oct 1993 14:41:55 -0400

    In-Reply-To: Mitra's message as of Oct 29, 10:13

    To: mitra@path.net (Mitra), marca@ncsa.uiuc.edu

    Subject: Re: Single protocol for UR*?

[ Mitra wrote: ]

> On Oct 28, 7:30pm, Peter Deutsch wrote:
. . .
> Peter - how do you define "commercial" - for example, of the three
> following cases, which would be commercial by your current requirements.

Our intention is _not_ to try and make money off this
code, it's to ensure it's wide availability while not
seeing someone else become rich off our work. I hope
nobody objects to this policy too much and of course we're
open to suggestions on how to achieve these fairly simple
goals.

Let's take each of your examples in turn:

> 1) A company integrating your work into a product and selling that.

Provided that our code is not a "significant" part of the
product (let's say greater than 25 or 30 percent of the
code), we'd send a letter waiving our rights. If the
percentage is much Beyond that, we might ask for a small
royalty (a couple of percent). Basically, I don't see our
code becoming a product on its own, but if it did we'd
want to discuss things with whoever was doing it.

If this policy causes someone a financial hardship (eg.
because projections are for limited sales) we'd be happy
to negotiate a waiver, although if there is money to be
made from a commercially supported version of this code
I'd like to see Bunyip share in it. Also, we're happy to
waive our rights when it's used by not-for-profits and
educational sites, provided the work is redistributed with
these same conditions transfered to the recipient. We
_want_ this stuff widely used, if it's appropriate. That's
all.

> 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)

We'd have no problem here. Anybody can operated the code
free and clear. On the other hand, if someone wants a
commerial quality release, with support and so on, they
should talk to us about a support contract. This first
release is really only a proof of concept and it needs a
lot more work. We'd be happy to do it, but there's really
only one way to catch our attention... ;-)

> 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.

Definitely no problem. We encourage everyone to operate a
WHOIS++ server and if ours satisfies your needs, all we
ask is a thank you (and perhaps that you let others know
that it's ours, but that's not a requirement).

> } > 2) Exactly what extensions to DNS would be needed to make this work . .
. . .
> } 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.

Nor am I, my half-baked idea is based upon a few
conversations with people more familiar with it and I'm
more than willing to be lectured on this part of things.

The way I see it, we are going to have some kind of
hierarchially structured system for resolution of the URI
family, and to make this work the first task is finding
the top of the authority tree (ie. the server for the top
level naming authority). I think probably the easiest way
to do this is to use DNS and suspect all we need to do to
accomplish this is to define a new domain (eg. URN for
now, and later probably a URC, or perhaps a URI, with URN
and URC as subdomains). Then, we can create new subdomains
for each new naming authority under these as they appear.

The only open question then is how to define a means of
encoding responses to the question of "where are you"?

Even if we agree on a single protocol for subsequent
steps, I think I'd still like the response from DNS to the
question of "where are you" to be include host, port and
protocol for flexibility. I suspect we'll want to build on
this over time, and thus having the ability to say "WHOIS^3"
instead of "WHOIS++" might be of use in 1998, and
certainly the ability to say "port 987" instead of "port
43" could be of use today.

Sooo, I think defining a new DNS record type with this info
would be the way to go. I don't think there should be
any major objections (I said with a silly grin on my
face), except perhaps the sim-ple "it's not needed". If
that's the consensus, I'd be happy to live with it for
now, since we could always go back and add it later, if
it's really wanted.

. . .
> } 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.

Again, apologies for missing this (I really did loose
about 5 meg of mail last week). Let's try for a short
resume of the proposals - have you all decided whether
this is nested attributes, or structured in parts a la
MIME? WHOIS++ is pretty simple, so supporting either
should be possible but if you have a clearly defined
format which is not supported by one of the current
formats, I'd suggest that we could merely make what you
need another WHOIS++ output format and we're done.
Because WHOIS++ has a mechanism for querying for supported
formats and options, specifying the output format and
defaults etc this should be trivial to fit in, if it
doesn't already work (We aimed for modularity from the
start to allow just this sort of extensibility).

. . .
> Peter, What I meant by protocol queries wasnt C-code, but something
> like:

The following looks pretty good to me, although I'd add
one more step to separate the naming authority server from
the specific pubid server (I'm sure ISOC doesn't want to
run a service for every member, although they might be
willing to run a server pointing to each member's server).

> 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

Your approach has the advantage that there is essentially
no change to DNS, but does require universal acceptance of
the WHOIS++ protocol for this task (stranger things have
happened) so it might be okay.

Perhaps more serious, this approach means there is no way
to put a WHOIS++ URN server on anything except the default
port. I think the ability to do this might be of use, so I
suggest we consider the addition of a new DNS data type,
which would allow us a bit more flexibility.

> Client sends "Template=URM,URN=urn:anamespace/pubid:123456" to
> urns.path.net on port 987 (registered as URN port with
> iana)

Hmmm, interesting idea - we register a new port for URN
work, but have it use the same protocol as on port 43. I
don't object to this in principle, but do we then use the
same port for URCs, or ask for yet another? I'm not sure
IANA would want to see the same protocol on several ports.
Also, some people do run services on the nonpriviledged
ports for a variety of reasons.

Anybody else care to comment on this approach?

BTW, here's where I think you skipped a step, since you
assume that the server for "namespace" is also the server
for "pubid". We probably want to separate these into two
queries (and perhaps allow a shortcut mechanism where the
two servers are one and the same).

> 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

This format looks fine to me, although just as an aside
I've been thinking for a while now that we might want to
consider tokenizing attribute names for all these new
records, to allow easier conversion into local languages.
This does make them less human readable, so it might not
be such a hot idea, but we could go for a hybrid approach,
such as:

1:URN: anamespace/pubid:123456
2:Author: mitra
3:URL: gopher://xyz.edu//1/Adocument
4:Cost: US$ 10.00
3:URL: http://xyz.edu/copys/of/everything/Adocument
4:Cost: 0

Here, clever clients could pick up the token (the first
number) and convert the name field into the local
language.

Some may see this as an unneeded distraction, but I know
there's a lot of people who'd appreciate it and I'm sorry
I didn't have this idea in time for the original IAFA
work. Who knows, it might find its way into the output of
the "mythical data elements working group" (to borrow
someone else's phrase... :-)

I'd like to see the idea discussed, assuming that it wont
break the rapidly building consensus on the URN->URL
deferencing work...

. . .
> 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 ...

As the person who first suggested multiple protocols, I'm
prepared to withdraw my suggestion, provided there is
consensus on the single protocol replacement (Simon,
please consult Roberts and let me know about the procedure
for withdrawing a suggestion... :-)

If there are serious objections to WHOIS++ or several
other candidates are put forward, I'd like to hear the
proposals before I decide to return to my first suggestion,
argue for WHOIS++ or whatever. I'm keeping an open mind to
this problem and just want consensus quickly...

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

Good question. I've received several supportive notes from
people who identified with my "let's just do it" approach,
but none from developers of other systems or protocols yet.
Does this approach sound like it will fly, or should we
kick it around some more?

- peterd

    --

- Next message: Fred Swartz: "Re: Thumbnail Sketch of the UR* Arena"
- Previous message: Peter Deutsch: "Re: options, not nesting?"
- Maybe in reply to: Peter Deutsch: "Single protocol for UR*?"
- Next in thread: Peter Deutsch: "Re: Single protocol for UR*?"