2.1.2 Common Name Resolution Protocol (cnrp)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 18-Oct-99


Leslie Daigle <leslie@thinkingcat.com>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>

Applications Area Advisor:

Patrik Faltstrom <paf@swip.net>

Mailing Lists:

General Discussion:cnrp-ietf@lists.internic.net
To Subscribe: cnrp-ietf-request@lists.internic.net
In Body: subscribe
Archive: http://lists.internic.net/archives/cnrp-ietf.html

Description of Working Group:

For the purposes of this working group, a "common name" is a word or a phrase, without imposed syntactic structure, that may be associated with a resource. These common names are expected to be used primarily by humans (as opposed to machine agents). A common name "resolution service" handles these associations between common names and data (resources, information about resources, pointers to locations, etc). A single common name may be associated with different data records, and more than one resolution service is expected to exist. Any common name may be used in any resolution service. Common names are not URIs (Uniform Resource Identifiers) in that they lack the syntactic structure imposed by URIs; furthermore, unlike URNs, there is no requirement of uniqueness or persistence of the association between a common name and a resource.

The working group will define a protocol for the parameterized resolution necessary to make common names useful. "Resolution" is defined as the retrieval of data associated (a priori) with descriptors that match the input request. "Parameterized" means the ability to have a multi-component descriptor. Descriptors are not required to provide unique identification, therefore 0 or more records may be returned to meet a specific input query.

Specific design considerations include

o ensuring applicability across languages and charactersets ("I18N")

o support for federated services: query referral

o facilitating interoperability of CNRP services: e.g., providing base query parameters needed to support common name resolution, as well as the ability to introduce others (and standardize them)

o security: authority, tracking origin of name

The protocol will define:

o client requests/server responses to identify the specific parameters accepted and/or required on input requests

o client request/server responses to identify properties to be returned in the result set

o expression of parameterized input query

o expression of result sets

o standard expression of error conditions


o Document outlining the goals of common name resolution

o Document specificying a protocol for common name resolution

o Document defining a URI scheme for allowing common names to be embedded in documents

Input documents:

draft-popp-cnrp-00.txt, "A resolution protocol for Common Name Namespaces", Nicolas Popp and Michael Mealling, February 1999.

draft-popp-cnrp-goals-00.txt, "Context and Goals for Common Name Resolution", Larry Masinter, Michael Mealling, Nicolas Popp, Karen Sollins, June 1999.

Goals and Milestones:

Sep 99


Submit Context and Goals for Common Name Resolution as an Informational RFC.

Jan 00


Submit Resolution Protocol for Common Name Namespaces as a Proposed Standard.

Jan 00


Draft of common name (resolution protocol) URI scheme

Mar 00


Submit common name URI scheme as Proposed Standard

Apr 00


Close working group.


No Request For Comments

Current Meeting Report

Common Name Resolution Protocol WG

Chair: Leslie Daigle (leslie@thinkingcat.com)

Minutes courtesy of: Larry Masinter (masinter@parc.xerox.com)

Meeting agenda:

- Intro/Agenda review
- Remaining issues in resolution protocol for Common Names (Nico Popp)
- What's next
- CNRP URI scheme (Michael Mealling)

1. Intro:

As half the room signalled that they hadn't been to either of the previous BOFs on the subject, Leslie put up slides of the group's charter and went over the primary charter statements.

2. Remaining issues in Common Name resolution protocol

Review of protocol document: Nico Popp's slides reviewed the protocol. Nico reviews some of the issues that were raised on the mailing list. Raise issues, decide which things we can converge on.

Nico started with a reminder to all:

"In design, perfection is achieved not when there is nothing more to add, but rather when there is nothing more to take away"

- Antoine de Saint-Exupéry (An aircraft design guide),
- Larry Masinter (Mexican Restaurant)

Editor's note:
denotes overhead slide content

|Client examples: web browser, search engine, mail client, chat client, wireless device...
|* One simple model: QUERY, RESULT, PROPERTY
| * QUERY and List of RESULTS
| * PROPERTIES: standard, extensible
| * Everything must fit the model: Error, schema, discovery, referral

|Standard properties for interoperability
|* COMMON NAME, URI, UID (unique identifier) one URI or many, more attributes,
|* Do we need more?
| * Drill down capabilities and real need v.s. complexity
|* Candidates:
| * GEOGRAPHY (country code, coordinates, postal code....)
| * CATEGORY (free form keywords)
|* Single property with extensible types (default type + extensible type) VERSUS many properties of a single type (default + extended properties: countrycode, coordinates, postalCode)


RFC 2483 elaborates some kinds of resolution services for URIs that would also apply to Common Names -- e.g., I2L for "URI to URL" might have an analog in a "Common Name to URL" service.

Note: in geography, "something that is Near X" while in language, "Near" isn't meaningful.

Nico: The properties add complexity, but they are really useful, enable lots of applications.

Leslie: it is important to think about the breadth of possibilities, but we have a specific purpose, need to pare out the things that are fun to do, but that don't serve the core purpose.

Opens question: if a server doesn't specify a language, and the client specifies "English", is it a match?

Leslie: needs to define default behavior.

Nico: it is up to the service... it isn't part of the protocol.

[[is this satisfactory?]]

| 1. Errors & control parameters
| ERROR is a typed RESULT
| (error number, description)
| (category, severity, description)
| * Range (result set start and length)

| 2. Extensibility
| Special QUERY type (service characteristics)
| * QUERY schema (Query-able properties)
| * RESULT Schema (Response properties)
| * Other (Service scope, implementation, ...)
|* Leverages XML SCHEMAS

| 3. Operators & string equivalence
| * One type: string
| * Two logical operators: OR, AND across query property (not within a
| property value)
| * One string operator: =
| * What does it mean? Do we care about uniformity?
| * Match type: exact, partial
| * String equivalence
| * Byte comparison
| * Normalized string comprison? (language dependent)
| * Result must return normalized match

Michael Mealling: Just for keeping the service constrained, is it valid to constrain these so they don't apply to the common name property.

Don't restrict the common name itself, but logical operators can act on the properties that are attributed to it. The "=" operator.

Generally, is this an area where there is a strong contractual relationship between the client & server, or are we going to allow local intellegicne?

Question about phonetic matching, client should get what it expects, then we have to define what a fuzzy match is, and matching outside of the server, if we are going for ineroperability.

Don't use "=" ...

Caution, we're on the edge of a big tarpit... the point is that it isn't dealing with exact specification... these are common names and linguistic terms that humans are always imprecise, but didn't try to formally specify what these names were, and what constitutes two names that specify the same object.

Dirk van Gulik: Once the data is in the server's datastore, some localized normalization has already been done. I.e., it's not possible to negotiate a full range of possible language matchings against any service anyway.

Discussion thrashed around in the various issues of trying to specify precisely what is desired as a result (language of query, language of results (desired), type of matching to be applied, etc). In the end, the direction picked included:

- Allowing services to advertise their capabilities (e.g., "I provide German-language matching"). This allows service differentiation.
- The query is something presented to a server which does its best to provide a match based on what it recognizes in the query (and e.g., applying local language matching rules)

Leslie summarizes: urge for simplicity of the service -- don't want to find ourselves in really dealing with the logic of full-blown search services, but cautions against an alternative of seemingly random behavior when you go to do a match.

This leaves the question of "interoperability" -- what does it mean to demonstrate 2 interoperable CNRP implementations, if there is local intelligence in the servers?

- One client able to connect to, query, and receive results from 2 different servers
- Client interoperating with two servers *at the same time* isn't something we're doing[
- Two servers interacting isn't an interoperability issue.

There is still a "security" issue -- generally speaking, the question becomes "can I get the same answer repeatedly and reliably, given the same data are entered in the same data base."

Karen Sollins: different topic: in the list of properties in a query, are we interested in grouping in some way; may care about ranges of properties or qualifiers of properties.

| Referrals: Federated/Cascading hook
| * A typed resulted (intermixed with other results)
| * CLIENT CONTROL: useful (wireless) but complex & there is a
| workaround (proxy server queries in parallel and aggregates
| results for the client)
| * CLIENT VISIBILITY: introuce a namespace UID (UID across hybrid
| result set) or a mechanism for resolution service to generate
| a globally unique ID (namespace UID + unique ID within the
| service DB).

Summing up the sense of the room: it is allowable for the result to contain referrals, and we will provide in the query some indication of whether the client likes them or is willing to accept them.

| CNRP: simple Query/Result Model that can be implement
| by multiple transports (e.g.., HTTP and LDAP).
| Pragmatic choice: HTTP for simplicity, LDAP to fit existing Directory
| services, UDP for performance, etc...
| WG will provide an HTTP implementation
| Consequence: Authentication/security is a function of the service
| needs and the underlying transport (HTTPS, SSL, ...).

Leslie urges everyone to go back to the goals document and the terminology used in it, in particular to be sure it reflects this view of presenting query characteristics to a server, and the server applying local/service intelligence to produce result.

3. What's next

In the light of the afternoon's discussion, all participants are strongly urged to review the Goals document and make sure it adequately captures consensus. Will then last call Goals document & put it out as RFC.

Draft new protocol document (by Dec 1)

URI Scheme -- theory (by Jan 1)
Leslie wants a plan before end of year

4. URI Scheme Discussion

Punted to the mailing list -- the group felt that more of the resolution protocol had to get nailed first, then the URI scheme should fall out naturally.


None received.