Subject: Re: Service, Server, Dataset

From: Nicolas Popp <[email-masked]>
Date: Wed, 7 Jun 2000 21:00:51 -0700

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

Definitely. As soon, as a service deals with many datasets, each defined
server should use the dataset property to indicate which datasets they can
serve (I thought that was clear from the example that showed how to use the
dataset property within the service object).

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

Yes again. Going back on your question about the true meaning of service,
you could even envision that a service would return 2 referrals within the
same dataset (one for the dataset aol keywords served by acme.com and one
for aol keywords served by mci-portal.com) and let the client decide which
on it elects to follow..

I think that there is still consistency in our model....

As far as IDs:

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

I totally agree. There is no way that we can synchronize IDs across multiple
services.
To go one step further, I think that we SHOULD NOT even require IDs to be
persistent within a (service, dataset) pair. The "raison d'etre" of the ID
property is to pinpoint a specific result from a query result set. For that,
we don't need a high level of persistence. The persistence problem and the
broken URI issues is not something that CNRP should try to address (that's
what URNs are about right?). If some services decide that to make their IDs
truely persistent as a value add for users who want to embed CNRP URIs
within Web pages instead of URLs, fine, but to me, that's just a service
differentiator, not a CNRP requirement...

>If IDs do not hold over time, then the value of using "id=" in a
>query is not guaranteed to produce the expected results.

And I think that's ok. The value of common names is to simplify navigation
not to enable a more persistent URIs...

-Nico

-----Original Message-----
From: Leslie Daigle [mailto:[email-masked]]
Sent: Wednesday, June 07, 2000 6:55 PM
To: [email-masked]
Subject: Re: Service, Server, Dataset

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.

Nicolas Popp wrote:
>
> >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]
> -------------------------------------------------------------------

--

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

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

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 8 Jun 2000 23:35:43 -0400

Well, here's a first cut at specific proposed changes to the CNRP
protocol document:

We go back to "serviceuri" where it used to be (i.e., what the
current rev. says is "dataseturi").

In,

> 4.1.1 Core properties
[snip]
>        (typically a database ID)

becomes:

        2. ID: an opaque string that serves as a unique identifier
           for a result from a service (typically a database ID).
           The ID is not globally unique, nor necessarily persistent
           (e.g., between queries at a given service).

In

> 4.1.3 Base properties

we add:

"6.  dataseturi:  An absoluteURI (as defined in RFC2396[3]) that
     identifies a defined set of Common Names and associated data."

And somewhere, we need to slip in the paragraph/section:

A "service" provides common name resolution at one or more "servers".
If the data contained in all its servers is identical (mirrors), the
service need not identify any particular dataset in its service
object, with returned results, etc.  If, however, the service
provides different collections of data through different
servers (e.g., subsets, specialized collections, etc), it MUST
indicate what datasets each server offers through appropriate
dataseturi's.  If the service offers a copy of a collection of data
on agreement with a foreign service,  the foreign service MUST provide a
dataseturi to allow the collection to be identified as related to its
own offerings. Referrals to a service SHOULD indicate the particular
dataseturi that triggered the referral, if it is known.

Note that this means that results MAY contain more than one service
object for a single service, so that individual service<->dataseturi
bindings can be referenced in results and referral objects.
Also, if the service object identified in a referral object contains
more than one dataseturi, the client MUST NOT assume that the hit was
in both datasets -- it could have been in one or the other.

For example:

   <?xml version="1.0"?>
   <!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN">
   <cnrp>
        <results>
             <service id="0">
                  <serviceuri>http://acmecorp.com</serviceuri>
                  <property
name=dataseturi>urn:oid:1.2.3.4.666.5.4.3.1</property>
             </service>
             <service id="1">
                  <serviceuri>http://acmecorp.com</serviceuri>

<property name=dataseturi>urn:oid:1.2.3.4.666.10.9.8.7.6</property>

             </service>
             <service id="2">

<serviceuri>http://servers.anothercorp.co.uk</serviceuri>
                  <property
name=dataseturi>urn:oid:1.2.3.4.666.5.4.3.1</property>

             </service>
             <resource>
                       <commonname>Fidonet</commonname>
                       <id>1333459455</id>
                       <resourceuri>http://www.fidonet.ca</resourceuri>
                       <serviceref ref="0" />
                       <description>This is ye olde Canadian
                          Fidonet</description>
             </resource>
             <resource>
                       <commonname>Fidonet</commonname>
                       <id>99836801</id>
                       <resourceuri>http://host:port/bla</resourceuri>
                       <serviceRef ref="2" />
             </resource>
             <referral>
                 <serviceRef ref="1" />
             </referral>
        </results>
   </cnrp>

Does this sound reasonable?

Leslie.
--

Leslie Daigle
[email-masked]