Subject: Status update, moving forward

From: Leslie Daigle <[email-masked]>
Date: Wed, 16 Feb 2000 11:29:34 -0500

Hi all,

As promised, a recap of where we are, and where we should go from
here.  Executive summary:  we're getting close to done, so barring
anyone flagging serious oversights, we'll be in "wrap up mode"
soon.

In terms of documents/our charter obligations, we have:

        On deck:
                . draft-ietf-cnrp-01.txt -- to be discussed
                . Ben Schepens' scenarios proposals (reposted
                  below sig line, from his mail of Dec 20/99)

        In transition:
                . draft-ietf-cnrp-goals-00.txt -- submitted to
                  IESG for publication as Information RFC after
                  WG last call, in December

        Remaining:
                . CNRP URI document -- Michael Mealling to circulate
                  draft Real Soon Now ;-)

What now:

We have, or will soon have, reasonable versions of all our documents.
We need, therefore, to be reviewing the protocol document and
the URI document (when available) carefully in the light of what
we set out to do.

My expectation is to use the Adelaide meeting (requested, but I don't
yet know the timeslot) to flush out remaining issues in the
penultimate versions of the documents, see what we want to do with
the scenarios.  I don't currently see any reasons to expect to do
anything other than circulate any so-identified-issues & conclusions on
the mailing list, revise the documents a couple of weeks after Adelaide,
and do last calls.

I'm spelling this out because I need to know if the quiet on the
list is because the authors are doing a great job (they are ;-)
or because people haven't gotten around to voicing any issues
(or better:  contributions!) they may have.  Now's the chance.
Going, going...

Leslie.

--

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

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

Ben Schepens, [email-masked], wrote:

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.