Subject: Re: Service, Server, Dataset

From: Nicolas Popp <[email-masked]>
Date: Thu, 8 Jun 2000 10:05:44 -0700

Marshall.

The only reason I conceded on the notion of dataset, is that it could simply
be ignored by implementors if their service only deals with one dataset (99%
of the first implementations I presume) .
Since that whole notion can be ignored if you are only dealing with one
namespace and not doing referral,  implementations can remain simple while
maintaining CNRP compliance.

Also note that since the dataset is a base property, even if it shows up in
a query, technically, it can be ignored by the server (it is a hint and does
not not have to be understood...It is like geography, category, etc...)...

On the other hand, I believe that our prior discussion proved the concept
useful for the future. Since it does not impact the fist level
implementation, I don't think that the added complexity is a big deal (it
just makes our protocol document a little bit longer and harder to read...).

-Nico

-----Original Message-----
From: Marshall L. Moseley [mailto:[email-masked]]
Sent: Thursday, June 08, 2000 9:21 AM
To: [email-masked]
Subject: Re: Service, Server, Dataset

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

----- Original Message -----
From: Nicolas Popp <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, June 06, 2000 11:10 PM
Subject: Re: Service, Server, Dataset

> >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: Thu, 8 Jun 2000 14:25:21 -0400

Nicolas Popp wrote:
> (it

Arguably, it will make it easier to understand -- as these are
questions that people would have had anyway in reading it.

IMHO

:-)

Leslie.

--

Leslie Daigle
[email-masked]