RE: "so-called" keyword and layer 3

Yves Arrouye <> Thu, 06 December 2001 14:48 UTC

Return-Path: <>
Received: from by (PMDF V6.0-025 #44856) id <> (original mail from; Thu, 06 Dec 2001 09:48:28 -0500 (EST)
Received: from by (PMDF V6.0-025 #44856) id <> for (ORCPT; Thu, 06 Dec 2001 09:48:28 -0500 (EST)
Received: from by (PMDF V6.0-025 #44856) id <> for (ORCPT; Thu, 06 Dec 2001 09:48:27 -0500 (EST)
Received: from ( []) by (PMDF V6.0-025 #44856) with SMTP id <> for; Thu, 06 Dec 2001 09:48:27 -0500 (EST)
Received: (qmail 21549 invoked by uid 104); Thu, 06 Dec 2001 14:45:53 +0000
Received: from by with qmail-scanner-0.96 (. Clean. Processed in 0.825407 secs); Thu, 06 Dec 2001 14:45:53 +0000
Received: from ( by with SMTP; Thu, 06 Dec 2001 14:45:52 +0000
Received: From RINCON.INTERNAL.REALNAMES.COM ([ port:4062]) by Mail essentials (server 2.422) with SMTP id: <> for <>; Thu, 06 Dec 2001 06:42:23 +0000 (AM)
Received: by with Internet Mail Service (5.5.2653.19) id <XHJ5GWK2>; Thu, 06 Dec 2001 06:45:40 -0800
Date: Thu, 06 Dec 2001 06:44:21 -0800
From: Yves Arrouye <>
Subject: RE: "so-called" keyword and layer 3
Message-id: <>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
List-Owner: <>
List-Post: <>
List-Subscribe: <>, <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Help: <>, <>
List-Id: <>

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

(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