# Re: Single protocol for UR*?

Peter Deutsch (peterd@bunyip.com)
Fri, 29 Oct 1993 13:01:59 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Mitra: "Changes to URI doc"
- Previous message: Mitra: "Re: Single protocol for UR*?"
- Maybe in reply to: Peter Deutsch: "Single protocol for UR*?"
- Next in thread: Fred Swartz: "Re: Single protocol for UR*?"
- Reply: Fred Swartz: "Re: Single protocol for UR*?"

    Message-Id: <9310291702.AA05847@expresso.bunyip.com>

    From: Peter Deutsch <peterd@bunyip.com>

    Date: Fri, 29 Oct 1993 13:01:59 -0400

    In-Reply-To: "Fred Swartz"'s message as of Oct 29, 12:14

    To: "Fred Swartz" <fred.swartz@umich.edu>

    Subject: Re: Single protocol for UR*?

[ Fred wrote: ]

> > From: Peter Deutsch <peterd@bunyip.com>
. . .
> I like the idea of using the whois++ protocol (at least I assume so,
> I'll have to look at it when I have time) , BUT I'd like the URN
> protocol to be only a _subset_ of whois++. A conforming URN server
> would then only require support for those operations which are relevant
> to URNs. . . .

I'm not sure what's in WHOIS++ that you'd want to leave
out. There are a number of options that a conformant
server is not obliged to support, but the core set of
functionality is pretty "austure" (by design). There is a
mechanism specifying a search that is based up a template
oriented data model, plus a small set of system commands
which provide mechanisms for such things as locating
related servers, examining the list of supported template
types and fetching blank templates to allow the user to
see what attributes are supported. Given that I think we
would need all of these when using this for the URN->URL
task, I'm not sure what we'd want to leave out?

> . . . Full whois++ servers would naturally be conformant. This may
> seem like a small point, but I think it may be important in the
> future.

The problem I see with this (other than the fact that I
don't identify a lot of fat to trim) is that general
WHOIS++ clients might break if they assume some specific
function is available and it's not. We'd then see pressure
for two types of client and corresponding user confusion
that is the argument for choosing a single URN protocol.

Eeewww...

> ...
> >There is a write option in WHOIS++ but if someone wanted
> >to put in a record in _our_ server, it would be done by
> >editing the file of templates and then reindexing the file
> >with the wais indexer. Still, this is an implementation
> >issue, not a limitation of the protocol, which does
> >support writes as an option.
>
> It's probably too early to discuss the protocol details,
> but it should support messages saying "Add/remove
> URL x for URN y". This may not be relevant in your more
> controlled environment, but it's necessary for an environment
> where services are very dynamic. It also raises some
> permission issues.

The ability to do this (that is, to write to records or
specific attributes of records, plus the ability to support
authentication, are both available as options. I don't
think anyone's server currently supports them, but we do
plan to add these to ours as time and resources permit. In
the meantime, the ability to support this is there in the
protocol.

- peterd

    --

- Next message: Mitra: "Changes to URI doc"
- Previous message: Mitra: "Re: Single protocol for UR*?"
- Maybe in reply to: Peter Deutsch: "Single protocol for UR*?"
- Next in thread: Fred Swartz: "Re: Single protocol for UR*?"
- Reply: Fred Swartz: "Re: Single protocol for UR*?"