Subject: Re: Service, Server, Dataset

From: Nicolas Popp <[email-masked]>
Date: Thu, 8 Jun 2000 21:39:22 -0700

This is very good.

The only thing I would object to is the last paragraph.
Since there is one and only one service, I would only allow one single
reference per service in the results set and let individual result/referral
disambiguate the dataset using the dataseturi property. In plain English,
this is what I mean:

   <?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>
                  <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" />
                       <property
name=dataseturi>urn:oid:1.2.3.4.666.5.4.3.1</property>
                       <description>This is ye olde Canadia
Fidonet</description>
             </resource>
             <resource>
                       <commonname>Fidonet</commonname>
                       <id>99836801</id>
                       <resourceuri>http://host:port/bla</resourceuri>
                       <serviceRef ref="2" />
             </resource>
             <referral>
                 <serviceRef ref="0" />
                 <property
name=dataseturi>urn:oid:1.2.3.4.666.10.9.8.7.6</property>
             </referral>
        </results>
   </cnrp>

-Nico

-----Original Message-----
From: Leslie Daigle
To: Nicolas Popp
Cc: [email-masked]
Sent: 6/8/00 8:35 PM
Subject: Re: Service, Server, Dataset

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]
>    2.  ID: an opaque string that serves as a unique identifier
>        (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.
--

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

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

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 9 Jun 2000 10:24:46 -0400

Howdy,

I do like this approach better, although it does mean changing the
definition of the referral object to admit properties.  I.e.,

  <!ELEMENT referral (serviceRef)>

becomes

  <!ELEMENT referral (serviceRef, property*)>

(Although, interestingly, this is what is already described in the
_text_, section 4.1.6, last sentence).

Leslie.

--

Leslie Daigle
[email-masked]