Subject: Re: Some open questions

From: Nicolas Popp <[email-masked]>
Date: Thu, 20 Apr 2000 15:11:51 -0700

Leslie.

You are right. Lookup and search are conceptually very different:

lookup: I already know the keyword, just give me the resource descriptors
associated with it (1 or many)
search: I have no idea what the keyword is, I am trying to find out what
keywords exist for the type of stuff I am looking for.

That would translate into supporting 2 types of query: LookupQuery and
SearchQuery.
Although, it is conceptually right, it would force implementers to
understand and support 2 concepts instead of one which I obviously do not
like much.
Furthermore, if a specific service needs to differentiate between the 2
types of queries(e.g. for performance/cost reason since a search query is
way more expensive than a lookup query), they can always define a property
that will be passed by clients that care about such nuance.

In other words, I don't think that the core protocol should distinguish
between these 2 types of queries.

-Nico

-----Original Message-----
From: Leslie Daigle [mailto:[email-masked]]
Sent: Sunday, April 16, 2000 11:15 AM
To: [email-masked]
Subject: Re: Some open questions

Howdy,

Patrik Fältström wrote:
> >(2) Ask everyone which registers a name do it in whatever UTF-8 byte
> >streams he wants, which include canonicalization permutations.
>
> ...which basically says that it is up to the one registering the name
> / running the CNRP server to see that given that UTF-8 strings goes
> to the server, the "correct" matching is done where "correct" is
> defined by the one owning the name.

I think this is true as far as defining what representations are
"the same as" the name registered -- necessary for lookup.  However,
that's slightly different than what CNRP is (currently) geared towards
(which is, essentially, search), as we have focused on saying that when
you specify a common name in a query, you will get back whatever records
the service deems has a common name "like" the one you specified.
"Like" is defined by the service, and is considered a service
differentiator.

I see two options here:

        . suggest that services _may_ elect to request this
          type of matching restrictions from registrants, if
          it fits with the kind of service they are aiming to
          provide

        . distinguish between lookup and search in CNRP

In either case, this is restricted to the common name -- i.e., does
not change the fact that it is the service's task to provide whatever
normalization equivalences for all other attributes.

Leslie.

--

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

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

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 21 Apr 2000 12:15:40 -0400

Howdy,

I don't disagree with your analysis of the impact, though I think
some further discussion about whether we should distinguish
lookups & searches might be in order (i.e., what do other people
think?).

One reason I push this a little further is that, from the ABNF
for the CNRP URI:

  form1    = "//" [server] "/" [path] "?" [ common-name ] [ id-req ]

what about

        cnrp://myhost.com:16230/?LeslieLDaigle

Is that/should that be just a shortform for a query with
"commonname=LeslieLDaigle" (i.e., a search), or is the expectation
going to be that this should be a lookup (i.e., more precise)?

Whichever way we decide is appropriate, I think some words will
be necessary in the URI document to make clear what the intention
is.

And, to come back to the original issue of registering normalization
equivalences for particular common names, as suggested by Patrik,

Leslie.

--

Leslie Daigle
[email-masked]

---

From: Michael Mealling <[email-masked]>
Date: Fri, 21 Apr 2000 12:46:55 -0400

> going to be that this should be a lookup (i.e., more precise)?

I think its a multi-valued lookup. There is no way to differentiate you from
any other "LeslieLDaigle" in the world. I.e. you can't a priori tell
if its going to result in something that looks more like a lookup
than a search. IMHO, both are still lookups since one just returns
more than one valid answer.

Is there some assumption tha a 'lookup' can only return one value?
That assumption isn't even valid for DNS....

-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: Fri, 21 Apr 2000 18:01:25 -0400

Howdy,

Just to be clear -- I wasn't assuming it would be a single value
returned, as the common-name is not a unique identifier.  But,
the distinction was:  should it return

        . only records with common name "exactly" (with
          registered equivalences) LeslieLDaigle, or

        . all records that (however the server decides) match
          LeslieLDaigle (e.g., also LeslieLDaigleSnow, to push
          the example to extremes).

Or, do we care.

Leslie.

--

Leslie Daigle
[email-masked]

---

From: Ben Schepens <[email-masked]>
Date: Fri, 21 Apr 2000 19:17:23 -0400

>           the example to extremes).

I was thinking we would just specify 'LeslieLDaigle' as the CN and let the
server decide how to match it up.  One way to let the server know
that you desire a specific match is to give it a query property like:

     MatchStrictness = Exact

or something like that.

Ben

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 22 Apr 2000 09:21:45 +0200

At 7:17 PM -0400 4/21/00, Ben Schepens wrote:
>server decide how to match it up.

My immediate reaction is that word boundaries is an important thing
which we should not throw away that easilly. I.e. the server should
get to know the word boundaries and use that information in the
decision.

   paf

---

From: "Marshall L. Moseley" <[email-masked]>
Date: Sat, 22 Apr 2000 09:20:03 -0700

Word boundries are very important.  For example, a word following the word
'to', that begins with 'o'.  How does the parser know what to make of it?
Is to 'To Oslo,' or 'Too slo?'

--Marshall

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 24 Apr 2000 12:42:03 -0400

Well, note that there were no word boundaries in the example
I used:

        LeslieLDaigle

was the common name string.  As opposed to (in URL-encoding, which was
the context it was in):

        Leslie%32L%32Daigle

which is entirely different (though some servers/ices might like to
match them).

The way I understand things is:

        1. a common name is a UTF-8 byte stream.

        2. individual service may im/explicitly register "clusters"
           of common names when a customer registers a name -- the
           cluster being composed of the strings that are considered
           "equivalent", by whatever local rules govern (e.g., the
           recognized canonicalization equivalents, or with/without
           word boundaries, etc)

        3. irrespective of how things are registered, a clever
           server will apply local heuristics to determine
           "matches" between the UTF-8 byte stream offered in the
           query by the client and the contents of its database
           (e.g., matching "Leslie L Daigle" against "Leslie Daigle").

IF(F) we do the "lookup" thing, only the common names (UTF-8 byte
streams) that are exactly the same as something from a "cluster" (#2)
are considered "hits".    It's not quite an exact match in the
traditional sense, but it's different than an all-out search.

But, I don't think that we, as definers of the CNRP, have anything
more to say about what is/is not considered "the same" or "important
features" in the byte stream -- including definitions of word
boundaries.

Leslie.

--

Leslie Daigle
[email-masked]

---

From: "Martin J. Duerst" <[email-masked]>
Date: Tue, 25 Apr 2000 09:14:42 +0900

Small nit:

At 00/04/24 12:42 -0400, Leslie Daigle wrote:
>which is entirely different

Extremely different indeed. It stands for

     Leslie2L2Daigle

If you want the spaces, that's

     Leslie%20L%20Daigle

Don't mix hexadecimal and decimal :-).   Regards,   Martin.

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 24 Apr 2000 21:56:33 -0400

:->>>>>

And now you know why I used LeslieLDaigle as the example -- I knew
I'd screw it up :->

Leslie.

--

Leslie Daigle
[email-masked]