Re: Name lookup service

[John C Klensin <klensin@jck.com>]

Hi.

I found this very helpful.  I would like to see something of
this type made more widely available.  A few general
observations follow.  I assume you have looked at the long note
with subject "Keywords, direct navigation, and search layer
2..." I just sent to Yves -- it covers some of the same ground
and I should not repeat myself.  And I will use the notation I
introduced there (although I may change my mind about notation
by Monday).

As far as Monday is concerned, the policy remains "no
presentations or extended document reviews".  If, after reading
what follows, you think it would be useful to introduce a
specific discussion on this topic, I will give you time, but on
the two conditions discussed earlier: 

	(i) you should assume in your presentation that the
	people in the audience have read these notes and any
	updated documents you post in the meantime.  Anyone who
	comes unprepared is going to be lost in this BOF, and
	that is, as we say, considered a feature.   
	
	(ii) the document needs to be revised into
	Internet-Draft format and made available so that it can
	be posted as an I-D immediately after IETF.  In
	practice, that means I need it in my hands this weekend.

But my impression is that you will be able to help us understand
things as well by commenting on Yves' discussion, and that will
require less short-notice preparation on your part.

General suggestion about the document.  As I read it, I see
several things that appear to me to be user interface design
issues and others that are clear, on-the-wire, protocol issues.
It would be useful --to the IETF and, I believe, in your own
context--  if you would separate the two.  If nothing else,
putting them together results in document that is an odd mix
between a statement of "requirements" and a description of a
particular system design.

Also, please look at "dns-search-02".   I have changed my mind
about many things since -00 was written, and several of those
changes have been motivated by comments from your colleagues in
Korea.   -02 also has much better explanations of some of the
concepts although, as Nico, Yves, and I have been finding out,
it still is not good enough.

Specific comments below.

--On Friday, 07 December, 2001 01:46 +0900 YangWoo Ko
<newcat@spsoft.co.kr> wrote:

> Requirements for Name Lookup Service - Draft
> 
> MINC-KR Meeting 
> July 16, 2001

[...]

> Internet address has been evolved in a way that users can use
> it  conveniently. The IP address is the first implementation
> of the Internet  address. Raw numbers are used to represent
> subnets and hosts in which  they are separated by dots. The
> DNS and IDN replaced the numbers of the  IP address with
> character strings in which they are more easily  identifiable
> by users. 

I think it would be helpful were you a bit more precise here.
It was recognized early in the ARPANET period that we needed to
give things names, and that those names would accomplish (at
least) two separate purposes -- ease of use by people and some
reference portability as network topology changed and hosts were
renumbered.  That portability issue makes it incorrect to refer
to DNS names (internationalized or otherwise) as "addresses".
They are really a reference to an address (or other resource or
target).

For this reason, I would strongly advise you against _storing_
IP addresses in your databases.  The ability of the DNS to
support a constant name or URL even while the underlying address
changes, and to do so with appropriate data lifetime mechanisms,
is very important to Internet operations.  Of course, what is
cached (consistent with DNS TTL rules) and what is delivered to
the user (see the discussion in "dns search" about whether the
user-level applicatio should call the search mechanism and then
the DNS, or whether the DNS name should be resolved by the
search mechanism) is another issue, one that should be
determined by your requirements and design.

> Despite the convenience of DNS and IDN, there are still needs
> to identify  or "lookup" the Internet object by "name". The
> names include domain names,  common names such as personal
> names and business names, for examples. A  context dependent
> name identifies uniquely only one Internet resource.  Name
> lookup service returns just one result for one query.
> 
> CNRP and directory system were also developed to support
> various needs  on domain names. However, they are NOT regarded
> as a name lookup service  because they are designed to return
> multiple returns for one input.    

I am trying to drop the word "directory" from my vocabulary in
this context, since it means so many different things to
different people.   And you have just identified one of the
reasons why I'm not sure that CNRP, as now defined, is really
the right model for the functions defined in "dns-search".

[...]

> 3.1 Return 0 or 1 result
> 
> Since the name lookup service is based on the lookup
> repository that  is defined in [1], the result to a successful
> lookup is a single group  of information. That lookup
> repository contains many types of address  information. The
> group of information, the result of the lookup operation, 
> includes IP address, domain name, URL, e-mail address and so
> on. It needs  more discussion about which attributes should be
> included. It also needs  more discussion whether the result is
> one specific attribute or multiple  attributes of the target
> Internet object.  

I would like to understand this, and your evolving thinking,
better.  But my note to Nico explained (I hope) how one can
model lookup systems of this variety within the sublayer 2 "dns
search" model.

> 3.2 Input is a word or a phrase
> 
> One of the main purposes of the name lookup services is to
> allow users  to use more intuitive and familiar names. In this
> sense, the services  should permit the use of phrases as well
> as the words. These names can  be in all languages. Further
> discussion includes the maximum words in  a phrase, the length
> of a phrase, whether permitting special characters  (i.e.,
> slash, comma, blank space, parenthesis, and so on) as part of 
> the input.  

Yes.  Once the DNS constraints are removed, all of this becomes
easier to think about.  Or, more specifically, we can focus more
on what is needed, rather than on what the DNS (reasonably)
permits.

> 3.3 No explicit attribute
> 
> Users provide only the naming attribute of the object that
> they want to  find. No other attributes of the object are
> required explicitly from  users. Instead, the implicit use of
> attributes of the name is permitted  for the sake of
> efficiency and flexibility. This will be discussed in  Section
> 3.4.
> 
> 3.4 User profile may be provided (optional)
> 
> As mentioned in Section 3.2, some attributes are used to
> efficiently  handle the name lookup services. For instance,
> the following attributes  could be used in user's profile.  
> 
> * The language 
> * The locality (or preference location) 
> * The name lookup service provider 

I think this is a user interface issue.  Certainly, nothing in
the "dns search" model requires that all of the information
specified in a query to the system be supplied by the user (each
time, or at any time).  Whereever the inforation comes from,
unconstrainted database search is typically slow and expensive,
unless the database is somewho kept small.  Your "DoS attack"
notes pointed this out very well.

> In addition to the attributes listed above, the current
> location of  mobile terminal might be an important attribute
> in mobile Internet  environments.

I agree, although the "location" of a roaming mobile device is a
bit of a nightmare with regard to both granularity and the way
in which location is expressed.  I still hope that someone
--smarter than I am-- will fill in enough of the hints about
"network location" in the "dns search" document to make that
idea viable.

> Consequently, the name
> lookup services can provide a  context-sensitive service that
> can enhance user's convenience. Moreover  the name lookup
> services can enlarge the limitation of the DNS naming  space
> by using context-sensitive naming scheme. 

Again, I think we are in general agreement, but that it would be
helpful to explore the details of these notions, especially with
regard to scaling to large-scale databases and operations.

> 3.5 Auto completion (optional)
> 
> In order to reduce the query error by typing incorrect names,
> the service  can complete the full names by matching them
> partially even before  finishing typing while users type names.

From the standpoint of the "dns search" model, this is just
another kind of fuzzy matching.  But, as I am sure you know,
wildcard and completion searches are the enemies of the
otherwise-most efficient search techniques we know of for very
large databases.  So, it would be good to think about precisely
what is needed here, e.g., whether caching of previous searches
and completion on the cache contents only would be an adequate
mechanism.

> 3.6 Optional link to keyword search
> 
> The keyword search [3], CNRP[5] and Directory systems [6] are
> different  from the name lookup service in that the former
> three schemes return 0  or more results while the last one
> returns 0 or 1 result. The keyword  search can be effectively
> used with the name lookup in cases that the  name lookup fails
> to find the name or user wants to see different results.

Just to be sure, you are now talking about "my" sort of keyword
search, rather than the "direct navigation" one discussed by
Yves and Nico.  Assuming that is correct, this might be
accomplished in the model by either expanding the referral scope
beyond your own database or expanding the "fuzziness" within it
or outside.  see the note to Nico.

[...]

> 3.8 Input
> 
> The name lookup service allows such inputs as business names,
> brand names,  personal names, telephone numbers, or even
> barcodes. It should include as  many forms as possible for the
> input.

That seems right, although I would suggest, based on experience,
that you would want to have some type of attribute available
that could be used to identify which of these things a
particular name-string represented (the current "dns search"
model does _not_ support that, partially because I couldn't
think through the category list).   You might not want to
present that attribute to the user, whether it was available or
not.

Do you see a barcode as anything different than a presentation
form for a string of digits?

[...]

regards,
    john