Subject: new drafts....

From: Michael Mealling <[email-masked]>
Date: Wed, 14 Jun 2000 10:39:23 -0400

Hi all,
  I have updated the protocol draft to include the edits concerning
dataseturis and Services. I created a new section that discussed
the Service Model which is that set of paragraphs from Leslie. I still
need to add the SRV stuff but I need to double check some stuff first.
I've also changed the URI draft to show the use of the 'go:' scheme name.
  Both are available at:
http://www.usrlocalsrc.org/CNRP/cnrp/docs/drafts/

I would like to get comments on these changes ASAP as we would like
to send them to the repository by close of business today.

-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: Leslie Daigle <[email-masked]>
Date: Wed, 14 Jun 2000 17:26:31 -0400

As a frustrated WG participant, I'm soon going to have to ask the
WG chair (:-)  why the authors have still not addressed one of
my most basic issues with the -00 version of the protocol doc:

The Abstract isn't; it's longer than the Introduction.

I've suggested alternate text -- could you please either make the
change or speak to why it's better to leave it as it is?

Looking a little closer, it seems that none of my comments from
Jan 17, 2000, many of which still apply, have been addressed.  I'm
attaching them below.

Additionally, I think that section 5.1.3 needs to be changed back
so that "dataseturi" reads "serviceuri".

Leslie.

--

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

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

[On Jan 17, 2000, LLD wrote:]

Some general comments:

        . need to define "namespace"
        . need to make clear that XML is being used to define and
          express the objects
        . need to replace all instances of "parameter" with "property"
        . need to be clear whether <language> is defined or if
          it's got to be <property name=language>, and then make
          everything concord with that...
        . need more forward references to the XML DTD at the end
          -- i.e., that it is definitive, and that all the snippets
          of XML presented in the running text are illustrative
          examples only

> 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).

> language is "German" can be expressed as:
>
>         <query>
>                 <commonname>bmw</commonname>
>         <language>de-DE</language>
>         </query>

Indent and this is one of the places where it looks like it
should be

        <property name=language type=mumble>de-DE</property>

> 5.3.2     Service
>
>        <service>
>                <serveruri>http://cnrp.us.foo.com:8081</serveruri>
>                <serviceuri>http://cnrp.foo.com</serviceuri>
>                <description>foo.com is a CNRP service specialized
>                   on cocktail recipes</description>
>        </service>

It may be just my reading of it, but it strikes me that _none_
of the examples in this section actually concord with the DTD.
At least, I hope they don't, because the DTD makes sense, and the
examples don't ;-)  (e.g., floating serverURIs, serviceURIs, etc).

Furthermore:

>         <service>
>                <serveruri>http://cnrp.us.foo.com:8081</serveruri>
>                <serviceuri>http://cnrp.foo.com</serviceuri>
>                <property name="category" type="freeform">companies
>                   </description>
>                <property name="geography" type="ISO3166-1">FR
>                   </description>
>        </service>

I think the two "</description>"s should be "</property>".

> 5.3.5     ServiceQuery & schema:
>
> A subclass of Query, the ServiceQuery object supports the
> dynamic discovery of a specific CNRP service's
> characteristics. The response to a ServiceQuery returns the
> Service object described in section 5.3.2.

I don't know what to say about this section, except that it
seems to be a little out of synch with the preceeding ones, and
it didn't make much sense to me until I'd read the DTD.  Maybe
that's just the way it has to be.  Maybe it would sit well if
the preceeding section's "server" and "service" examples were
clearer.

But note, for example:

> And for a CNRP service for cocktail recipes in French, the
> corresponding response would be:
>
>         <service>
>              <propertySchema id="1">
>                   <propertyName>cocktailrecipe</ propertyName >
>                   <propertyType>freeForm< propertyType >
>              </propertySchema>
>              <querySchema>
>                   <propertyReference required="yes">language
>                   </propertyReference >
>              </querySchema>
>              <rsourceSchema>
spelling-------^^^^^^-- and isn't it supposed to be "resultschema"?
>                   < propertyReference required="no" idref="1"/>
>              </resourceSchema>
>         </service>

Are the "ServiceURI", "servers", "description", and "ServiceSchema"
not required, too?

> 6.2  Service Description Request
<snip>
> <ServerURI>http://host1.acmecorp.com:4321/foo?</ServerURI>
>      <Priority>1</Priority>

"Priority"?

>   <property name="category" type="naics">544554</property>
>   <propertyname="BannerAdServer"type="uri">http://adserver.acmecorp.com/
>      </property>

Spacing problems in the second line.

> 8    Security Considerations
>
> This is where we talk about the various security threats.
> Two that need to be addressed are Man in the Middle attacks
> and possing as a service by spoofing a Service object.
      ^^^^^^^

"posing"

> 10   Appendix A: Well Known Parameter and Type Registration Templates
                              ^^^^^^^^^

"Property".

> Parameter Name: Geography

"Property" -- and for each one of them.

> Type: freeform
> Parameter: ALL

Again...  "property".