Subject: Updated CNRP Usage Scenarios

From: Ben Schepens <[email-masked]>
Date: Mon, 20 Dec 1999 10:49:16 -0500

Below are some updated usage scenarios for the CNRP protocol.  Please
review them for applicability, completeness, and any other issue you
can think of.
 
~Ben
 
========================================================================
====
Scenario 1)
 
Multiple CNRP servers are competing to provide results for the same
namespace.  
A CNRP client intends to submit the same query to all of these CNRP
servers. 
The result set it is interested is the union of the results from all the

servers.  Each server supports a different set of categories. Below are 
some possible approaches the client might take:
 
a) The client sends all servers the same query consisting of
intersection 
   of the categories they all share.
b) The client creates a single query contains a union of all the
categories 
   supported between the various servers. Each server ignores the 
   categories it does not support.
c) Separate, specific queries are sent to each server individually with 
   only the specific categories supported by that server.

Scenario 2)
 
A client wants to register a new CNRP server that provides data for a
namespace
that the client is interested in.  The first time a client communicates
with a 
CNRP server, it needs to know which categories that server supports.
Below are 
some possible approaches to handling this issue:
 
a) Severs could support a registration method to allow a client to
formally 
   ask details of the server about the namespace it supports, who 
   administers it, the categories it supports, etc.
b) The client could assume which categories that server supports, send a

   query and receive a descriptive error message detailing which
categories 
   are/are not supported along with any results the server could
provide.

Scenario 3)
 
This scenario is related to the previous.  A user hears about a new
CNRP server and believes that it might provide data for a namespace
that the user is interested in.  The user wants to determine for sure
if the CNRP server will provide information they want.  A client needs 
to know details about the namespace that a particular CNRP server 
implements. Below are some possible approaches to handling this issue:
 
a) A index exists that lists CNRP servers and the namespace they cover.
b) Each CNRP server provides a method where the client could formally 
   ask details of the server about the namespace it supports, who 
   administers it, the categories it supports, etc.
c) Certain descriptive data, i.e. namespace supported, administration 
   details, etc., would be sent back as part of the result set with each

   query the server processes.

Scenario 4)
 
This scenario is also related to the previous two.  A user has
intermittent
limited connection to the internet.  The user wants to send a Common
Name
request, but cannot wait for the answer.  Instead of using HTTP to 
interactively get results, the user would like to use SMTP to mail in a 
request and be mailed the results that he could check later.
A client needs to determine which communication protocols a CNRP server
supports? Below are some possible approaches to handling this issue:
 
a) A index exists that lists CNRP servers and describe and categorize 
   themselves with specific details of how they communicate, the 
   categories they support, the namespaces they implement, etc. 
b) Each CNRP server provides a method where the client could formally
ask 
   details of the server about the namespace it supports, who
administers 
   it, the categories it supports, how they communicate etc.
c) Each server is required to support a certain basic set of
communication 
   protocols.  The client may choose any of the protocols for
communication.

Scenario 5)
 
Multiple servers work together to increase the amount of data they can 
catalog within a single namespace.  They do this by segmenting the
namespace 
data among several sites.  This allows separate sub groups to help 
maintain data, focus on specific sub areas within a namespace, and
provide 
scalability of resources.  How are such referrals handled? Below are
some 
possible approaches to handling this issue:
 
a) The client receives a referral along with any other results that the 
   primary server is able to return.  The client this resubmits the
referral 
   to the appropriate server and receives its results.  The client
continues 
   the referral resolution until no more results are returned, a maximum

   number of results are returned, or a maximum number of referrals are 
   resolved.  
b) The server could chain the results of referrals together is a single 
   set of responses to the client.  The chaining would stop being 
   resolved when a maximum number of results or referrals had been 
   processed.  The client would specify these max values within the 
   initial query.
c) Referrals would merely let the client know that another server 
   contains similar or related data. The client would have to register 
   that other server and query it separately. 

Scenario 6)
 
This is related to Scenario 2.  A CNRP server receives a query with 
categories that it does not support.  The server is interested in
providing as many useful responses as possible. Below are some possible 
approaches to handling this issue:
 
a) The server could consider the entire query invalid and return and 
   error result only.
b) The server could ignore any categories it does not support, utilize 
   those it does support, and return the results it was able to resolve.
c) The server could ignore any categories it does not support, utilize 
   those it does support, and return the results it was able to resolve.

   Additionally, it could send back an error result, as well, detailing
the
   categories that it does not support.

Scenario 7)
NOTE: This scenario is only valid if the determination is made that more
than one URI may returned for each result from a given source.
 
The client is returned a list of Common Name results.  Each result 
includes a list of URI matches. These matches may include URLs, URNs, 
etc.  How does the client choose which of the values from the match 
list to pursue? Below are some possible approaches to handling this 
issue:
 
a) Each value in the list is assumed to be logically equivalent. For 
   simplicity, the client arbitrarily chooses the first value in the
list.
b) Each value in the list is assumed to be logically equivalent. To 
   aid in balancing server loads, the client randomly picks a value 
   from the match list to pursue.
c) Different types of URIs should be group.  For instances, URNs are 
   grouped together, URLs are grouped together, etc.  Each values is 
   considered to be logically equivalent.  The client decides which type

   of result it wishes to pursue first, i.e. URNs, URLs, etc.  Within
this 
   group, it picks one at random to assist in load balancing.

Scenario 8)
 
A user speaks English and is only interested in results represented in 
8-bit ASCII. A client sends a request to a CNRP server with this 
assertion.  Below is a list of approaches the servers could take
handling this issue:
a) The queried server does not use the same character set and/or 
language.  It chooses to consider the request an error and 
returns and error value.
b) The queried server does not use the same character set and/or 
language.  It chooses to attempt to coerce the query into its
native language and/or character set and sends its best
attempt for results.
c) The server uses the same language and/or character set.  It 
returns results or errors as normal.

Scenario 9)
 
A company is interested in creating a CNRP server; however, 
they have a need for a parameter specific to their industry that
does not currently exist.  Below are some approaches to handling
this issue:
 
a) The company defines what the parameter designation is and 
   the values it may take.  The company then creates a custom
   client to be used when resolving common names for the company.
b) The company defines what the parameter designation is and 
   the values it may take, so that, any client application could
   choose to support that parameter.  The company has the option
   of registering this new parameter type specification with IANA
   so that others may be able use this parameter.