Subject: Re: final URI scheme question (non-trivial)

From: Nicolas Popp <[email-masked]>
Date: Mon, 29 May 2000 20:39:07 -0700

Michael.

To support different datasets, a service can always define a custom property
(suh as "datasetID"). Then, the client can use that property in the query to
restrict the results to a specific dataset.

An alternative for a CNRP service implementor with multiple datasets is to
define multiple services (a service for trademarks only, a service for
generice term only an possibly a third service encompassing both datasets).

Yet another way would be to simply use the "category" property.

In other words, there is enough flexibility in the exisiting mechanisms to
support the notions of datasets.

To keep things simple, I would therefore get rid of the PATH...

-Nico

-----Original Message-----
From: Michael Mealling
To: [email-masked]
Sent: 5/26/00 7:41 AM
Subject: final URI scheme question (non-trivial)

Ok, as far as I can tell this is the final question regarding the
CNRP URI scheme. If we can get this hammered out quickly then
I think we're done with that document:

In Adelaide there was some time spent on just what the PATH portion
of the URI meant. For some it was a convenience since it could
give them the ability to map a path to a CGI script on a web server.
With the decision to put CNRP on a different port this goes away.

For others it was for differentiating between something called a
'dataset'.
The argument goes like this: A Service can have multiple Servers which
can have multiple Datasets. For example, the RealNames Service may
have mutliple disjoint datasets such as Tradenames and Generic Names.
The problem is that this concept of datasets vs Services is
not mentioned in any of our other documents.

If we keep the PATH portion of the URI scheme and give it these
semantics
then we have to be clear in the protocol document what a dataset is and
why
it isn't just another property. We also have to be clear as to what
the "/" character means here since it specifically allows for
relative addressing according to RFC 2396.

_Please_ respond to this as soon as you can since our end of May
deadline
is quickly approaching...

-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: Michael Mealling <[email-masked]>
Date: Tue, 30 May 2000 12:14:47 -0400

> To keep things simple, I would therefore get rid of the PATH...

This is my point of view as well. This would leave us with a URI
that looks like this:

cnrp://[host:port]/?[<common-name>]*[;<attribute>=<value>]

Now, one question: RFC 2396 defines the slash after the port to be
part of the path which means we take it out leaving us with
something that usually looks like this:

cnrp://foo.com?Motorola;language=en
or
cnrp://foo.com:7654?Motorola;language=en

Is that ok? Its consistent and syntactically correct according to 2396...

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