RE: "so-called" keyword and layer 3

Yves Arrouye <yves@realnames.com> Fri, 07 December 2001 16:35 UTC

Return-Path: <ietf-irnss-errors@lists.elistx.com>
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GNZ00404FFB3N@eListX.com> (original mail from yves@realnames.com); Fri, 07 Dec 2001 11:35:35 -0500 (EST)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GNZ00401FFA3L@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 07 Dec 2001 11:35:34 -0500 (EST)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GNZ00401FF93K@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 07 Dec 2001 11:35:33 -0500 (EST)
Received: from friendly.realnames.com (friendly.realnames.com [63.251.238.102]) by eListX.com (PMDF V6.0-025 #44856) with SMTP id <0GNZ0025KFF9Z0@eListX.com> for ietf-irnss@lists.elistx.com; Fri, 07 Dec 2001 11:35:33 -0500 (EST)
Received: (qmail 20340 invoked by uid 104); Fri, 07 Dec 2001 16:32:59 +0000
Received: from yves@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.819515 secs); Fri, 07 Dec 2001 16:32:59 +0000
Received: from heaven.internal.realnames.com (10.1.5.39) by friendly.realnames.com with SMTP; Fri, 07 Dec 2001 16:32:58 +0000
Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:1857]) by heaven.internal.realnames.com Mail essentials (server 2.422) with SMTP id: <164605@heaven.internal.realnames.com> for <ietf-irnss@lists.elistx.com>; Fri, 07 Dec 2001 08:29:06 +0000 (AM)
Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19) id <XHJ5G7GZ>; Fri, 07 Dec 2001 08:32:23 -0800
Date: Fri, 07 Dec 2001 08:31:02 -0800
From: Yves Arrouye <yves@realnames.com>
Subject: RE: "so-called" keyword and layer 3
To: Nicolas Popp <nico@realnames.com>, 'John C Klensin' <klensin@jck.com>
Cc: ietf-irnss@lists.elistx.com
Message-id: <7FC3066C236FD511BC5900508BAC86FE4D7849@trestles.internal.realnames.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
List-Owner: <mailto:ietf-irnss-help@lists.elistx.com>
List-Post: <mailto:ietf-irnss@lists.elistx.com>
List-Subscribe: <http://lists.elistx.com/ob/adm.pl>, <mailto:ietf-irnss-request@lists.elistx.com?body=subscribe>
List-Unsubscribe: <http://lists.elistx.com/ob/adm.pl>, <mailto:ietf-irnss-request@lists.elistx.com?body=unsubscribe>
List-Archive: <http://lists.elistx.com/archives/ietf-irnss>
List-Help: <http://lists.elistx.com/elists/admin.shtml>, <mailto:ietf-irnss-request@lists.elistx.com?body=help>
List-Id: <ietf-irnss.lists.elistx.com>

> 4.	As suggested in John's draft, ALL layer 2 service will have to
> return tuples that contain all the standardized facets. However, specific
> layer two services that don't care about one or many standardized
facet(s),
> would still be allowed to return result tuples with blank or "missing"
> values for the facets that they want to disregard. For example, although
> RealNames would let registrants specify their category value at
> registration
> time (to be used in the context of discovery as a layer 3 service), as a
> layer 2 service, it would "blank" the category facet value of its results
> in
> order to enable "direct navigation" (as described by Mr Ko)

Or you could always return the category facet value, but not make it part of
the set of facets that are required for direct navigation. If we note
non-key facets as name*, we could have { common-name, geography, language,
category* }. The advantage of letting the application not use a facet,
rather than blank it out, is that it still enables someone to display and
peruse the category information from a result set, yet does not force them
to use it for querying.

YA