RE: "so-called" keyword and layer 3

[Yves Arrouye <yves@realnames.com>]

Given that I have been traveling today, I am sure there will be many answers
to this. See my comments to John below.

> * I have been trying to push keyword systems out to sublayer
> three of the model for two reasons, which should probably be in
> the "dns search" document.  Next time.
> 
> (i) I'm worried about scaling with them, and especially about
> creating yet another situation in which someone has to decide who
> is entitled ("has rights to", "has the best claim on", "most
> closely matches") some word or string.   In a way, that is
> another kind of economic constraint, but, if we can meet the
> technical and end-user requirements without having to implicitly
> write ICANN, WIPO, or the equivalent into the protocol, I think
> that is desirable.   I believe that the "no overseer" requirement
> is more easily satisfied with keywords at sublayer three than at
> two.

I am worried about having categories in the layer 2 for that reason. To me,
industry categories implicitely mean WIPO. As a matter of fact, the authors
of the SLS document explicitely refer to the Nice agreement:

   "The type of the category property is 'nice' which designates the
   classification of goods and services found in the Nice Agreement on
   International Classification of Products and Services [4].

   [...]

   [4]  World Intellectual Property Organization, "Nice Agreement
        concerning the International Classification of Goods and
        Services for the Purposes of the Registration of Marks", June
        1957."

(is it really 1957?!)

I know that the introduction of category helps widen the space of potential
common names for a given service type, but basically, it means IP lawyers
still decide who can get what.

> If a "keyword system" is structured as
>  (a)	{common name, country, language, service type},
> then it meets my criteria for a sublayer two system (although I'm
> still concerned about scaling).  It is only when we have
>  (b)	{{descriptive-keyword1, descriptive-keyword2,...},
> 	country, language, service type}
> or
>  (c)	{{common-name, descriptive-keyword1,
> 	descriptive-keyword2,...}, country, language, service
> 	type}
> that I start getting anxious and pushing toward sublayer three.

I see keywords systems, from a direct navigation standpoint, as (a). The
common name is the key (along with country, language, and service type) used
to get an object descriptor who contains a set of facets. The fact that this
descriptor may also hold other facets in order to help additional
applications on top of the layer 2 lookup system, is not really relevant to
the fact that it does behave properly with a set of key facets. We tried to
explain that, and the importance of having these facets that are part of a
key, in draft-arrouye-kls-00.txt. The fact that an implementation may want
to add non-key facets to directly support higher level services is more of
an implementation and ease of subscription issue than an acknowledgement
that this implementation does not want to participate in a layer 2 lookup
system.

YA