Subject: [Fwd: more CNRP]

From: Leslie Daigle <[email-masked]>
Date: Sun, 7 May 2000 16:48:53 -0400

Howdy,

As noted in the attached, Roland initially sent this to me, but
I thought it would promote useful discussion on the list so I'm
following his permission and forwarding it.

My own perspective is that:

        . we have the service/server distinction currently, but
        . this is looking for an ability to acknowledge/express
          relationships between different services (administrative
          control) that cover the same space (dataset).

Answers for Roland?  Comments?

Leslie.

--

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

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

Subject: more CNRP
From: Roland Hedberg <[email-masked]>
To: [email-masked] (Leslie Daigle)
Date: Sun, 07 May 2000 22:38:48 +0200

Hi again,

Perhaps this should have been sent to the list instead of to you.
You can forwarded it if you want.

My problem is as follows:

If a CNRP server wants to return as a result for a query a set of sets
of referrals.

A example taken from the a LDAP environment ( but don't let that bother
you, read CNRP everywhere it says LDAP :-) ).

As a response to a LDAP query a server can return several 'groups' of
referrals. Where the underlying assumption is that all referrals within
one group are references to the same data ( masters and slaves ).

How would that be represented in a CNRP response ?

If I understand the CNRP DTD correctly, which I am not totally convinced of,
then the definition of 'service' doesn't allow you to have several
serviceURI's.
Which I take to mean that you can not handle the kind of situation that I have
described above.

-- Roland

---

From: Michael Mealling <[email-masked]>
Date: Mon, 8 May 2000 21:05:32 -0400

> Answers for Roland?  Comments?

Hmm... Of what use would such an expression of relationships be
to the client? With DNS for example the concept of primary vs
secondary only has meaning to the servers and isn't representable
in NS records. Do we need that in the client here or is it
enough to have a service/server distinction?

> How would that be represented in a CNRP response ?

By returning a referral that references a Service object that had
multiple Servers listed.
> Which I take to mean that you can not handle the kind of situation that I have

ServiceURI isn't really the URI of the actual server. ServiceURI is
an identifier only in that it allows you to differntiate one service (dataset)
from another. In the Service object there is only one ServiceURI but
multiple Server objects listed under the Servers tag.

The question becomes: is that sufficient for your needs? Are you
going to something more robust than master/slave that needs to be
expressed to the client?

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

---

From: Roland Hedberg <[email-masked]>
Date: Tue, 9 May 2000 15:04:23 +0200

> enough to have a service/server distinction?

It must be to the benefit of the client if it is told that a group of
servers all point to the same information, such that the client can choose
anyone of them when it wants to follow a referral.
And if the first choice is not reachable another from the group can be used.

> By returning a referral that references a Service object that had

Ah, your correct.
So the following construct would be used:

<service id="1" >
  <serviceURI="1.2.752.17.5.1">
  <servers>
    <server>
      <serverURI>ldap://ldap.umu.se/dc=umu,dc=se</serverURI>
    </server>
    <server>
      <serverURI>ldap://ldap.sunet.se/dc=umu,dc=se</serverURI>
    </server>
  </servers>
</service>

> multiple Server objects listed under the Servers tag.

Now, I'm lost. If the serviceURI is just a identifier and the collection
of characters has no intrinsic meaning. Then a construct
like this (extract from example 6.3 in cnrp-02.txt) must be rather useless:

<results>
  <service id="2">
    <serviceURI>"http://servers.acmecorp.co.uk</serviceURI>
  </service>
  <resource>
    <referral>
      <serviceRef id="2">
    </referral>
  </resource>
</results>

According to the text this piece should be a referral. But if it is
as you write, that the serviceURI is just a identifier and should not
be interpreted as a URI pointing to some information, then where is
the real referral.

Shouldn't it at least have been:

<results>
  <service id="2">
    <serviceURI>"http://servers.acmecorp.co.uk</serviceURI>
    <server>
       <serverURI>"http://servers.acmecorp.co.uk/</serverURI>
    </server>
  </service>
  <resource>
    <referral>
      <serviceRef id="2">
    </referral>
  </resource>
</results>

in order to be useful.

> going to something more robust than master/slave that needs to be

Well, it could be useful to be able to order the servers like in SRV records.
Perhaps 'property' could be used since it is already in the DTD.

<service id="1" >
  <serviceURI="1.2.752.17.5.1">
  <servers>
    <server>
      <serverURI>ldap://ldap.umu.se/dc=umu,dc=se</serverURI>
      <property name="priority">10</property>
    </server>
    <server>
      <serverURI>ldap://ldap.sunet.se/dc=umu,dc=se</serverURI>
      <property name="priority">100</property>
    </server>
  </servers>
</service>

-- Roland
------------------------------------------------
Roland Hedberg      phone     : +47 23 08 29 96
Dalsveien 53        mobile(NO): +47 90 66 44 52
No-0775 Oslo        mobile(SE): +46 70 520 420 3
Norway

---

From: Michael Mealling <[email-masked]>
Date: Tue, 9 May 2000 09:09:40 -0400

> And if the first choice is not reachable another from the group can be used.

Oh yes. That is useful. But what is not communicated to the client
is which one is the master and which one is hte slave. All the client
sees is multiple NS records with no ordering or any other semantics.
Let me clarify the question: of what use is it for the client to know
anything more than a list of servers all serving the same dataset equally?
Do you need to prioritize them (ala MX records)? Do you need to know
the master/slave relationship at the client level?

>       <serverURI>ldap://ldap.sunet.se/dc=umu,dc=se</serverURI>

Yep...

> be interpreted as a URI pointing to some information, then where is

In this case yes, it has no meaning. But there are others where it may
since the ServiceURI uniquely identifies the 'dataset' being talked about.
In some cases the involved parties may already know who the servers are
but they just need to know they're talking about the same service.
Its difficult to express this kind of semantic in the DTD....

>        <serverURI>"http://servers.acmecorp.co.uk/</serverURI>

For a referral, yes. But for other places where the Service object
is used, no....

> Perhaps 'property' could be used since it is already in the DTD.

Yep. This is the #1 reason why the Server tag is allowed to hold properties.
Neat, huh? You could also create other properties used here such as
saying things like "this server is for the pacific rim and this server is
for Europe" (although how you say that reliably is beyond me at this point).

>       <property name="priority">100</property>

Ywp..

-MM

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 9 May 2000 09:43:29 -0400

But, then, perhaps "serviceURI" is a little misleading.   You're using
it as a dataset identifier, here, but I'm willing to bet it will
be confused with a single point of administrative control.

I.e., if 2 organizations agree to mirror each other's data, is
the expectation that the mirror will have its server show up under
a serviceURI bearing the name of the originating service?  Will
that not make it look like a subordinate service?

Perhaps I'm splitting semantic hairs, but I think it's more accurate
to talk about "datasetURI" in this context.

And, if we really want it to be an _identifier_, not just a pointer
to a source for more information about the service, then I believe
it must explicitly be required to be a full URI -- i.e., not
a relative one (as it won't be clear relative to what, and the
"what" could vary in ways that precluded using the URI to determine
identity).

Leslie.

--

Leslie Daigle
[email-masked]

---

From: Michael Mealling <[email-masked]>
Date: Tue, 9 May 2000 10:03:38 -0400

> be confused with a single point of administrative control.

Yep. From a terminology standpoint service was equivalent to dataset...

> that not make it look like a subordinate service?

That is the case yes. How else will the client know the data is the
same?

> to talk about "datasetURI" in this context.

We could change our terminology to use 'dataset' instead of Service.
I don't have a problem with it (I prefer it in fact)...

> "what" could vary in ways that precluded using the URI to determine

Oh yes. All URIs in CNRP are full URIs. If that isn't in the document
then it should be...

-MM

---

From: Michael Mealling <[email-masked]>
Date: Wed, 31 May 2000 13:05:28 -0400

> I don't have a problem with it (I prefer it in fact)...

Point of information: are we just changing the tagname of serviceuri
to dataseturi or are we changing the entire Service object to be
a Dataset object?

-MM

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 31 May 2000 13:35:30 -0400

> to dataseturi or are we changing the entire Service object to be

I _think_ it's just the serviceURI that becomes the datasetURI.
If there is a serviceURI, it should point to some administrative
contact/page for the service.

IMHO.

Leslie.

--

Leslie Daigle
[email-masked]