Subject: Draft minutes from IETF meeting

From: Leslie Daigle <[email-masked]>
Date: Tue, 16 Nov 1999 12:26:25 -0500

Howdy,

Thanks again to all who made it to the WG meeting last week in
Washington -- a very lively and productive session!

I've attached draft minutes from the meeting -- I would appreciate
it if those who were there could review them and indicate any omissions
or areas where clarification is warranted.  I'll ship them to the
IETF minutes manager after Friday at 5pm ET.

For those who were not able to join us, here's a brief synopsis
from the Chair's-eye-view:

        We focussed primarily on the protocol proposal.  Nico
        will send around detailed notes re. the outcome of that
        in the next couple of weeks.  The key element that seemed
        to come out of the meeting was that we have to stay focused
        on CNRP as a particular service type, not a full-blown
        search protocol.  Users can select different services
        based on advertized capabilities, clients will express
        a description of their current state (common name sought,
        language, location, etc) and the service will produce results
        that it determines are meaningful to that statement.  We have
        to weigh this against the need for a clear definition of
        "interoperability" of client and server software -- which boils
        down to focussing on the protocol interactions, not the results
        lists.

I would ask everyone to review the current Goals document to ensure
that it adequately reflects this sentiment in its presentation.

As always, comments welcome, and I anticipate we'll have more discussion
when details re. the proposed protocol are circulated.

Leslie.

--

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

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

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

Common Name Resolution Protocol WG

Chair:  Leslie Daigle ([email-masked])

Minutes courtesy of:  Larry Masinter ([email-masked])

Meeting agenda:

  1. Intro/Agenda review
  2. Remaining issues in resolution protocol for Common Names (Nico Popp)
  3. What's next
  4. 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
|  * QUERY, RESULT = PROPERTY list
|  * 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....)
|  * LANGUAGE (ISO)
|  * 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)
+---

Comments: 

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)
| CONTROL PARAMETERS
|  * 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)
| * REFERRAL versus CHAINING
|   * 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
cotntain 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.