Subject: Protocol discussion

From: Leslie Daigle <[email-masked]>
Date: Tue, 2 Nov 1999 14:57:17 -0500

Howdy,

Taking the relative silence on the list (thanks, Terry!) as tacit
acceptance of the goals document, let's move on to the issue
of the CNRP protocol itself.

As you are aware, there is a draft document,

        http://www.ietf.org/internet-drafts/draft-popp-cnrp-00.txt

that Nico Popp and Michael Mealling put together some months ago.

Apart from any comments people may have on that document (i.e., before
we bring in a revision of it as a WG document), the Nico has provided
a list of questions he'd like to see addressed before we update it.
I've attached them below the sig line.

Let's start the discussion on the list, and we can see which issues
are relevant to pursue face to face in Washington next week.

Leslie.

--

------------------------------------------------------------------------

"Newton's 3rd law of (e)motion, applied:         Leslie Daigle
   It's impossible to touch without              [email-masked]
             being touched."
                       -- ThinkingCat

------------------------------------------------------------------------

Questions/issues for CN-Resolution Protocol:

1.Schema: what are the core objects and attributes to be standardized?
Request : common name, UID, [category, country, language, ...]
Response: common name, UID, URI, error parameters[description, category,
...]
Controls: messageID, operation, charset, range, [retrieved
parameters...]

2. What is the proper mechanism to discover new input and output
parameters
(extensibility)?
It could be declarative (the old draft uses an RDF file, we could use
XML
schemas)
It may be simpler if the protocol defined  a specialized query to
discover
the supported interface (attribute names and types) of a given service.

3. What are the supported attribute types? Suported logical operators
(and,
or, not, =, <, >...), supported string filters (contains, ...)?

4. Referal. Should it just be one specialized type of response?

5. Authentication between the client and the server. How do the client
and
the server exchange authentication information (specialized request and
response)? What type of authentication do we want to support (pasword
based,
SSL).

6. Information encoding and transport. Should CNRP be defined in terms
of
abstract messages (request/response) that can be encoded and transported
inmanyways (UDP for efficiency, HTTP for ease of implementation, LDAP
for
directory service access...) or should it be constrained to one
transport?

7.  String equivalence. How much do we need to specify since equivalence
rules are language dependent?

8. It has been said that we need a mechanism to drill down to a specific
entry in large namespaces. Is category keywords the proper solution?

9. Specific client and server implementations considerations?

---

From: Michael Mealling <[email-masked]>
Date: Wed, 3 Nov 1999 12:27:33 -0500

Leslie Daigle said this:
> Response: common name, UID, URI, error parameters[description,
> category, ...]

Should we make certain things like a description of the CN part
of the mandatory returned parameters? Other parameters like
category, etc are going to be service specific. A generic description
value in all responses seems to be to greatly facilitate
interoperability without affecting extensibility.

> XML schemas)

Just from some earlier conversations it seemed like everyone liked
specialized queries for that type thing. It was in the context
of a special query for actually getting the entire categorization
scheme used by the service.

> (and, or, not, =, <, >...), supported string filters (contains, ...)?

Logical operators are a dangerous thing. IMHO, logical operators
may be avalable for parameters but must not be applied to
actual common-names since that turns the system into a general
search service instead of a parameterized lookup. I can see the
value of saying something like "CN=bmw in the US and Europe but not France"
but being able to say things like "Network and Solutions not Associates"
scares me.

> 4. Referal. Should it just be one specialized type of response?

Yep.

> and the server exchange authentication information (specialized request and
> based, SSL).

#5 kind of depends on whether or not we use those services that the
transport (#6) may provide.

> of abstract messages (request/response) that can be encoded and transported
> for directory service access...) or should it be constrained to one
> transport?

Allow others, make one mandatory to implement. You have to decide if
the required services in #5 mandate a particular set of transports in #6.

> rules are language dependent?

Time to go read up on my Unicode stuff...

> entry in large namespaces. Is category keywords the proper solution?

(I know I asked before but not on the list). Can you elaborate on this
question?

> 9. Specific client and server implementations considerations?

Do we make it a requirement that it mus tbe able to be implemented via UDP?

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