Subject: Re: Service, Server, Dataset

From: Nicolas Popp <[email-masked]>
Date: Tue, 6 Jun 2000 23:10:15 -0700

>role, then, does a service play?  Is it an administrative entity?

The service object identifies the resolution service provider (which entity
operates the resolution servers and will be "responsible" for translating
the commonname into a URI). That's actually what I like about the notion of
service versus dataset. It allows the separation between the data (a set of
names and associations) and the resolution service. So for instance, AOL may
want the acme.com service to resolve the AOL keywords because AOL want to
leverage acme.com's network of servers and technology instead of having to
duplicate that infrastructure on their own. In that case, the service would
tell the client that the resolution service is operated by acme.com, but the
names being resolved are the AOL keywords.

>Does it define how queries are matched (i.e., all that we've said about
>services distinguishing themselves), so that all servers of one
>service will (whatever their dataset) apply the same rules for
>matching charactersets, etc?

It does not define how queries are matched , but since it is the same
resolution provider, you can reasonably expect the same matching rules and
"quality of service" across servers...It is a big hint, not a certainty. I
can imagine that some namespaces would require stricter matching rules than
other...

>If services can have servers with different data, then a referral has
>to be to a server/set of servers, not a service...
>.........................
>If all of a service's servers serve the same data (and how much
>wood CAN a woodchuck chuck?!), then a referral is to a service,
>and the servers simply provide load-balancing (mirroring).  Again,
>though, do all the same matching rules apply across all servers?

Even if all the servers within the same service do not serve the very same
data, it is still logical for the referral to point to the resolution
service (the client still wants to know which entity will be responsible for
the resolution). At the same time, the referral can now specify which
dataset the client should really query (eh, I think that the AOL keywords
dataset is relevant to your query, why don't you ask the acme.com service to
process that same query within the AOL keywords dataset). It also makes
sense for the referall (within the service object that it embeds) to return
the list of servers from that service that can resolve names within the
dataset so that the client can load balance among these servers (and not the
other servers that are irrelevant to that referral).  In any case, I cannot
see why all the acme.com servers should all have to carry the AOL
keywords...

-Nico

-----Original Message-----
From: Leslie Daigle
To: [email-masked]
Sent: 6/6/00 3:05 PM
Subject: Re: Service, Server, Dataset

Actually, forget datasets for the minute.

If services can have servers with different data, then a referral has
to be to a server/set of servers, not a service.   What role, then,
does a service play?  Is it an administrative entity?  Does it
define how queries are matched (i.e., all that we've said about
services distinguishing themselves), so that all servers of one
service will (whatever their dataset) apply the same rules for
matching charactersets, etc?

If all of a service's servers serve the same data (and how much
wood CAN a woodchuck chuck?!), then a referral is to a service,
and the servers simply provide load-balancing (mirroring).  Again,
though, do all the same matching rules apply across all servers?

Leslie.

Nicolas Popp wrote:
>
> It seems to me that once we have introduced the dataset properties, we
must
> go all the way and support the general case.
>
> that is:
>
> . a service can support multiple datasets (can contain  multiple
dataseturi
> properties).
> . a server can serve one or many datasets (can can contain multiple
> dataseturi properties)
>
> So, this should be valid:
>
> <service>
>   <serviceuri>http://acmecorp.com</serviceuri>
>   <property name="dataseturi">http://companies.acmecorp.com</property>
>   <property name="dataseturi">http://products.acmecorp.com</property>
>   <servers>
>         <server>
>
> <serveruri>http://www.companies.acmecorp.com:8888/cnrp?</serveruri>
>             <property
> name="dataseturi">http://companies.acmecorp.com</property>
>         </server>
>         <server>
>
> <serveruri>http://www.products.acmecorp.com:8888/cnrp?</serveruri>
>             <property
> name="dataseturi">http://products.acmecorp.com</property>
>         </server>
>         <server>
>             <serveruri>http://www.acmecorp.com:8888/cnrp?</serveruri>
>             <property
> name="dataseturi">http://companies.acmecorp.com</property>
>             <property
> name="dataseturi">http://products.acmecorp.com</property>
>         </server>
>    </servers>
> </service>
>
> -Nico
>
> -----Original Message-----
> From: Michael Mealling [mailto:[email-masked]]
> Sent: Tuesday, June 06, 2000 11:26 AM
> To: [email-masked]
> Subject: Re: Service, Server, Dataset
>
> On Tue, Jun 06, 2000 at 11:10:57AM -0400, Leslie Daigle wrote:
> > Michael Mealling wrote:
> > > Some clarificatiosn are needed:
> > > Are IDs unique to a dataset or a Service?
> >
> > Yes, clarification is needed.  Having thought about it for a day,
> > here's a counter question:
> >
> > What's the relationship between a service and servers?  I.e.,
> > must all servers for a given service serve the same data?
> > If they do not, are they a different service offered by the same
> > organization?
>
> IMHO, all servers cooperating in providing a Service have to be
identical
> or else its more than one Service....
>
> Again, IMHO....
>
> hmm....the potential for getting quite nutty is very near the surface
of
> this one....
> -MM
> --
------------------------------------------------------------------------
----
> ----
> Michael Mealling        |      Vote Libertarian!       |
> www.rwhois.net/michael
> Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:
> 14198821
> Network Solutions       |          www.lp.org          |
> [email-masked]

--

-------------------------------------------------------------------
"My body obeys Aristotelian laws of physics."
   -- ThinkingCat

Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 7 Jun 2000 21:54:34 -0400

Okay, but I think it means that if different servers for one service
are serving different data, we should (have to?) use the concept of
dataset in order to be able to distinguish which server(s) of a service
can validly service a referral.  Without it, it becomes difficult
for the index server to be able to figure out which servers are
relevant, which are not, when generating the referral.

And, ACME.com may not be the only service serving the AOL keywords --
there may be mci-portal.com also serving it to wireless devices, for
e.g., so a single dataset may appear in different services.

Now, to come back to Michael's question:  are ID's unique to
services or to datasets?

The larger question is:  are IDs unique over time (i.e., non-reusable)?
And there is a companion question, about the persistence of IDs
(whether the "same" record always has the same ID, never a new one).

[From the current draft of the cnrp protocol document:]
>    2.  ID: an opaque string that serves as a unique identifier
>        (typically a database ID)

I presume the original intention was that, within a given service,
ID's would be unique, so that any 2 records from 2 different
servers of the same service, with the same ID, were the "same thing".
Do we require that to hold over time?   That puts a significant
requirement on CNRP services to do proper accession numbering,
makes it difficult to merge databases, etc.  It strikes me as
being fairly "brittle", in the same way file pathnames are in
URLs.  If IDs do not hold over time, then the value of using "id=" in a
query is not guaranteed to produce the expected results.

Because, the question is:  should the same "record" have the same
ID in the AOL keyword dataset whether it's being served from
acme.com service or mci-portal.com service?

My "gut feel" is that the ID should be unique to a service, but
that means the service is responsible for assigning IDs, and
the same record may have different IDs if 2 different services
are serving the same dataset.  I.e., you can't use the ID string
to figure out if you've got the same data from 2 different sources.

Leslie.

--

Leslie Daigle
[email-masked]

---

From: "Marshall L. Moseley" <[email-masked]>
Date: Thu, 8 Jun 2000 09:20:32 -0700

I think we are going far afield with discussion of differentiating between
servers and datasets.  It conveys a level of indirection that can be
powerful, but it also raises the complexity.  Until this point we were
discusing servers/services in the same breath and they were essentially
identical.  PATH allowed multiple servers from the same service, but the
necessity for unique DTD per-server remained, and here we are.

Let's remove path and simply enable CNRP on a per-server/single service
connection.  If the service provider wants to do spoofing and the like with
datasets and multiple servers, let that be a service differentiator.  Let's
keep CNRP relatively simple so it can be implemented relatively simply.

--Marshall

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 8 Jun 2000 12:50:12 -0400

Howdy,

I appreciate the (renewed) call to simplicity.  However, the key
thing to get/have gotten out of this exchange is some definitions
of what we do expect each term to mean.  I.e., if we have an opinion
as to what service/server relationship is, then we should express it
in the documentation.  If we haven't got one, we must express that,
so that no one can claim one in an a posteriori fashion.

I think what I've been getting towards/Nico is describing is not as
complex as it sounds in illustration.  I intend, by the end of today,
to try to write up the words that would convey what we mean, what
services/servers MUST or SHOULD do.  I believe at the end of that
it should be clear that we can have simple implementations easily,
but more complex things are possible for those that want them -- WITHOUT
(and this is what I think is important) causing confusion with
services that don't care to use them.

So, let's give it one more round to coalesce before punting it?

Leslie.

--

Leslie Daigle
[email-masked]