Subject: Comments & work to do on protocol draft

From: Leslie Daigle <[email-masked]>
Date: Fri, 24 Mar 2000 23:23:53 -0500

Howdy,

First, let me say that (barring other input from the WG), the
protocol itself seems pretty well settled out.  The remaining work,
then, is in the details & clarification of the document.

There are 4 categories of comments here:

        1. general statement about the structure & organization
           of the document
        2. details yet to be addressed -- needed for completion
        3. editorial comments on the -02 draft
        4. editorial comments left over from the -00 draft, not
           yet addressed...

1. Structure & Organization

I think the document is getting to be a pretty good record of the
state of thinking of the WG.  However, I have the impression that it's
a difficult read for anyone wanting to pick up and learn what
CNRP is/is not.  Paying a bit more attention to introducing the
concepts in an overview before launching into detailed definition
would help a lot, for example.

2. Remaining Details

(Re)definition of properties:  (This is somewhat dependent on the
IANA question below).  Can a service redefine a property (i.e.,
in the properties it declares to be local to itself)?  Can a service
extend a property by allowing different property value types?

Security threats:
        . what ones will be addressed
        . how are the addressed
        . signed XML?

Errors:  what are the error codes? what is the numbering "scheme"
(e.g., 500-level are fatal, etc).  Are they result-set level only,
or can there be errors offered per-result (e.g., "hints ignored").

Result set ordering:  are results presented in some kind of an
ordered list?  (would facilitate presenting per-result errors).

Property/type registrations:  Assuming we really do want to do this
through IANA (and if not...?) we need a clearly defined registration
procedure, including:  who can redefine a property, or extend a
property to encompass new property value types?  (E.g., extending
the "geography" property to have some new geographic classification
as a valid type).  Also, are types defined on a per-property basis,
or are they valid across all types? How/where is the relationship
expressed.

3. Editorial comments -- 02

> common name and a resource.  (Note:  common names may be
> expressed in a URI, the syntax for which is described
> herein.)

No -- it's described in a separate document.

> 4.1  Hints
> A hint is an assertion by the user about him or her self and
> the context in which he/she is operating.  There is no data
> type `hint'; a hint is expressed within the structure of the
> query itself and is limited or enabled by the richness of
> the defined query namespace.  In effect, a query and any
> property within it is a hint.
>
> An example of this would be the required property
                                  ^^^^^^^^
> "language", in which a query might be created that specifies
> the primary language in which you want to see results, the

Required by what?
        . server support
        . included in client query
        . included in return data

> 5.1 Properties:
> 5.1.1 Base properties
<snip>

A table, showing base properties (core & optional) and their
definitions/applicable types would be very useful in this section,
I think.

> 5.1.2.3   Common name - String encoding and equivalence rules
> CNRP specifies that common name strings should be encoded
> using UTF-8. CNRP does not specify any string equivalence
> rules for matching a common name in the query against a
> common name of a Resource. String equivalence rules are

I believe this is the first mention of "Resource".  First of all,
to use it, it should be defined (particularly as it is easily
confused with the end-thing that the CommonName is associated with,
should that actually be a web page...).  Secondly, it may be a poor
word to use.  In the context of much of this work, "Record" would
perhaps be a much clearer term to use -- I strongly advocate a
global search & replace...

To wit:

> 5.3.1 Resource
> A Resource object describes a resource (e.g. a Web page, a
> person, an object identified by a URI).

This is tripping into a whole other space of "what is metadata"
that we really don't need to get mired in.  The "resource/record"
object may well do no such job of description.  It is a record
that contains certain pieces of data, which has (for whatever
reason -- descriptive or otherwise) been associated with a CommonName.
Period.  Whether it describes a web page, a service, a human
being or a hunan dumpling is irrelevant to our purposes.

> The Resource object
> can contain the commonname, URI, ID, description, language,
> geography, and category of the resource. A Resource can also
> be augmented using custom properties. Lastly, a Resource can
> also reference a service object to indicate its origin.

"The Record object contains a CommonName, and may contain a URI,
 ID, description, language, geography and category data -- e.g.,
 describing a particular web resource.  A Record can also be
 augmented using custom properties.  Lastly, a Record can also
 reference a service object to indicate its origin."

As in -- the Record's origin, not some resource's origin.

> 5.3.2 Service
> The Service object provides an encapsulation of an instance
> of a CNRP service. A service is uniquely identified through
> the ServiceURI property. Services can also include a
> description, a brief textual description of the service.
>
> <service>
>      <serviceuri>http://cnrp.foo.com</serviceuri>

It wasn't clear to me if this was meant to be a URI for an actual
CNRP server, or  (e.g.) a page describing the service.  If not
explicitly a CNRP server, then I would suggest making that
clearer, and illustrated in the example.  E.g.,

        http://www.foo.com/cnrp/intro.html

> <!-- The `source' of the data. This means whether or not it came     -->
> <!-- from the entity doing the request or from some other default    -->
> <!-- source. This could also be considered a rudimentary weighting   -->
> <!-- mechanism.                                                      -->

I believe the above section is anachronistic and should be deleted.

> 6.3 Sending A Query and Getting A Response
>
> This is the query that is sent from the client to the
> server:
>
> <?xml version="1.0"?>
> <!DOCTYPE cnrp SYSTEM
> "D:\WINNT\Profiles\Administrator\Desktop\CNRPDTD.xml">
> <cnrp>
>  <query>
>     <commonName>Fido</commonName>
>     <property name="geography" type="iso3166-2" source="default">
>        CA-QC</property>
>     <property name="geography" type="iso3166-1"
> source="explicit">CA</property>
  ^^^^^^^^^^^^^^^^^

Ditto.

> This is the result set. It is sent back in response to the
> query. This result set includes a referral and a non-fatal
> error.

I didn't see any error, fatal or otherwise...

4. Editorial comments -- 00

The following comments were made in reviewing the -00 draft.  Looking
over them, they appear to all still be unaddressed by the -02 draft,
although some of the exact quoted wording may have changed.  These
need to be addressed (i.e., done or counter reasons given).

> 2. Abstract

This isn't.  I suggest stripping the Abstract section down and
pushing more into the Introduction:

--> begin LLD proposes:

2. Abstract

People often refer to things in the real world by a common
name or phrase, e.g., a trade name, company name, or a book
title. These names are sometimes easier for people to
remember  and type than URLs.  Furthermore, because of the
limited syntax of URLs, companies and individuals are
finding that the ones that might be most reasonable for
their resources are being used elsewhere and so are
unavailable. For the purposes of this document, a "common name"
is a word or a phrase, without imposed syntactic structure, that
may be associated with a resource.

This effort is about the creation of a protocol for client
applications to communicate with common name resolution
services, as exemplified in both the browser enhancement and
search site paradigms. Although the protocol's primary
function is resolution, it is intended to address the issues
of internationalization and privacy as well. Name resolution
services are not generic search services and thus do not
need to provide complex Boolean query, relevance ranking or
similar capabilities. The protocol is a simple, minimal
interoperable core. Mechanisms for extension are provided,
so that additional capabilities can be added.

3. Introduction

Services are arising that offer a mapping from common names
to Internet resources (e.g., as identified by a URI). These
services often resolve common name categories such as
company names, trade names, or common keywords. Thus, such a
resolution service may operate in one or a small number of
categories or domains, or may expect the client to limit the
resolution scope to a limited number of categories or
domains. For example, the phrase "Internet Engineering Task
Force" is a common name in the "organization" category, as
is "Moby Dick" in the book category.

Two classes of clients of such services are being built,
browser improvements and web accessible front-end services.
Browser enhancements modify the "open" or "address" field of
a browser so that a common name can be entered instead of a
URL. Internet search sites integrate common name resolution
services as a complement to search. In both cases, these may
be clients of back-end resolution services. In the browser
case, the browser must talk to a service that will resolve
the common name. The search sites are accessed via a
browser. In some cases, the search site may also be the back-
end resolution service, but in others, the search site is a
front-end to a collection of back-end services.

This effort is about the creation of a protocol for client
applications to communicate with common name resolution
services, as exemplified in both the browser enhancement and
search site paradigms. Although the protocol's primary
function is resolution, it is intended to address the issues
of internationalization and privacy as well. Name resolution
services are not generic search services and thus do not
need to provide complex Boolean query, relevance ranking or
similar capabilities. The protocol is a simple, minimal
interoperable core. Mechanisms for extension are provided,
so that additional capabilities can be added.

Several other issues, while of importance to the deployment
of common name resolution services, are outside of the
resolution protocol itself and are not in the initial scope
of the proposed effort. These include discovery and
selection of resolution service providers, administration of
resolution services, name registration, name ownership, and
methods for creating, identifying or insuring unique common
names.

For the purposes of this document, a "common name" is a word
or a phrase, without imposed syntactic structure, that may
be associated with a resource.  These common names will 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.  (Note:  common names may be
expressed in a URI, the syntax for which is described
herein.)

This document 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-property
descriptor.  Descriptors are not required to provide unique
identification, therefore 0 or more records may be returned
to meet a specific input query.

end LLD proposes <--

Note that I changed the "multi-component" to "multi-property"
in the last paragraph above -- as a segue into using "property"
instead of "parameter" from now on.

> 4. Basic object model

This is, or should be, the "Basic Interaction Model".  Then, I think
there needs to be a paragraph of (gentle) introduction saying what that
model is, in the broadest of terms:

        . the protocol is based on a simple request/response model
        . requests are objects, defined and expressed in XML, see
          below; requests are made as "assertions", rather than
          detailed instructions for the server to carry out
        . responses are also objects, defined and expressed in XML

>   2. A `standard' query, which is the submission of the common
>      name along with parameters.
>
> search string to the database.  The query will conform to
> the previously established schema.

The last 2 lines seem to be trailing edit doots.

> result set).  CNRP allows database service providers to
> create unique data types and surface them to any CNRP client
> via the CNRP schema XML documents.

"surface"?  perhaps "expose"?

> Discovery of the transport associated with a CNRP database
> is accomplished through DNS.  The syntax for a CNRP URI is:
>
>         CNRP:<[host]>:<[port]>/path/<common name>;
>            paraname=value,paraname=value,...
>
> "CNRP", in conjunction, with the URI content, denotes a DNS
> entry containing a Naming Authority Pointer (NAPTR).  The
> NAPTR specifies how a CNRP URI is dynamically rewritten by
> the client to adhere to some transport (HTTP, GOPHER, etc.)
> Because this rewrite can be a URL, a CNRP URI can thus be
> cached and assigned a time-to-live (TTL).

I think the above should be cut -- insofar as it is covered, it
is covered in the CNRP URI document.

> that many services, especially large one, will implement

"ones", not "one"

>       1. Language: The language of a resource associated
>           with a resource.

Eeuhh?!  "Which which is which?"!

And there should be a reference to Appendix "A", which defines
the base properties.

The language property is expressed using language values as
defined by ISO-3166.

> The multi-type properties and the main types are defined

Perhaps "their main" instead of "the main"?

For the following, clarify if this is true for all properties,
or just "category":

>      When the "type" is unspecified, the value defaults to
>      "free form". The free form type is important because it
>      allows very simple user interface where the user can
>      enter a value in a text field. It is up to the serviced
>      to interpret the value correctly and take advantage of
>      it to increase the relevance of results (using
>      specialized dictionaries for instance).

Leslie.

--

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

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

---

From: Michael Mealling <[email-masked]>
Date: Sun, 26 Mar 2000 22:27:02 -0500

> extend a property by allowing different property value types?

After thinking about edge conditions I think that
1) A service cannot redefine a property. It can define a new type
but not a new definition for a registered property.
2) A service can extend a property by allowing new property value
types if the property definition allows it.

>         . what ones will be addressed

Yes. This is on my list to do. I would appreciate some ideas for
possible security threats. I'll fill them out if you want to
just forward brief descriptions.

> or can there be errors offered per-result (e.g., "hints ignored").

Ahh, yes. Since we assume that a given set of results may have a
records from different servers then how do we associate an error
with a given set of records.

> ordered list?  (would facilitate presenting per-result errors).

If I remember corectly we simply said that it was ordered but
didn't say what that meant.

> or are they valid across all types? How/where is the relationship

In the document I did allow for a property type to say it was
valid for all properties but that sounds problematic.

More to come when I have better connectivity...

-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: Ben Schepens <[email-masked]>
Date: Mon, 27 Mar 2000 10:24:23 -0500

Mealling > Ahh, yes. Since we assume that a given set of results may have a
Mealling > records from different servers then how do we associate an error
Mealling > with a given set of records.

Could we add a ServiceRef to each error so that the errors
could be related to a Service source the same way that Resources are?

> ordered list? (would facilitate presenting per-result errors).

Formally speaking, as the DTD is defined, 'Errors' are grouped
per 'Result'.  If you meant to say per-'Resource' errors, I am
not sure how that would be useful.  It seems to me that a 'Resoure'
returned in the Result represents a successful answer.  If there
were a problem, an 'Error' element would have been returned in the
'Result' INSTEAD of a 'Resource'.

----------------------------------------------------------------------------
Ben Schepens                         [email-masked]
Sr. Research Engineer
Network Solutions

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 27 Mar 2000 18:03:09 -0500

Howdy,

> per 'Result'.  If you meant to say per-'Resource' errors, I am

Gee, Ben, if you're going to be snooty about splitting a semantic hair
with me, get it right!  The element is "Results", not "Result".  The
further point being that I wasn't speaking in DTD elements, but rather
general terminology -- "result" being one thing in a "result set".

> 'Result' INSTEAD of a 'Resource'.

To explain a bit further:

        In the case of non-fatal errors, e.g., hints ignored.

        In the general case of system messages, can also include
        informational messages.

        Thinking ahead, perhaps, there's also the issue of what happens
        if the service you're connected to is in fact fronting for a
        number of services or namespaces; having only "failed" or
        "succeeded" as report codes for the entire result set is pretty
        much lame.  (This is the part that Michael referred to).

The most important thing to get resolved in the CNRP document is
whether or not the client should expect the components of the "Results"
to be ordered for any reason.

Next, do we want to impose any semantics on the ordering (if they
are ordered) -- e.g., error messages that apply only to the
resource/record element that follows, etc.  This may make more sense
in the context of messages that are "system messages including
error messages", as opposed only to fatal/non-fatal error messages.

It may well be the case that we don't want to impose such an ordering
 -- but we need to be clear either way.

> could be related to a Service source the same way that Resources are?

This works to the granularity of per-service errors/system messages.
It doesn't work within a given service.

Leslie.

--

Leslie Daigle
[email-masked]

---

From: Ben Schepens <[email-masked]>
Date: Mon, 27 Mar 2000 19:03:34 -0500

> general terminology -- "result" being one thing in a "result set".

Sorry... not trying to be snooty.  I was just trying to be specific...
and yet I still didn't get it quite right ;-)

>         much lame.  (This is the part that Michael referred to).

I have a question.  Isn't it possible for a Result Set to contain both
Resources
that could represent successful results and Errors that could be fatal or
non-fatal
error values?  If so, given the possible scenario where one service fronts
for
others, could we not represent problems with some services mixed in with the
successful results of others in a single result set?
Or am I looking at the problem too simplisitcally?
Or am I off track completely?

If it is more complicated, would adding an Error/Info element list to each
Resource be a valid way to increase the specific details we can send
back for each Resource?

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 27 Mar 2000 19:30:28 -0500

Howdy,

> Or am I off track completely?

To this extent, I think we are in agreement, violent or otherwise.
(My comment was trying to respond to what I thought was your question
about why this might be useful...).  So, the "serviceref" suggestion
works for this, I think.

> Resource be a valid way to increase the specific details we can send

... and we could do this if we want to get to the level of
per-result/record/resource information.  I _was_ alluding to that --
I think it's useful, but I have concerns that it would be making
things too complex.  Working group thoughts?

No matter what we do, and how we do it, we do need to say whether
things are ordered or not...

Leslie.

--

Leslie Daigle
[email-masked]

---

From: Michael Mealling <[email-masked]>
Date: Mon, 27 Mar 2000 19:51:17 -0500

> things are ordered or not...

I think we do need to say that. If its not in the document already then
it should be...

-MM