Subject: Re: Some open questions

From: Nicolas Popp <[email-masked]>
Date: Sat, 15 Apr 2000 18:56:19 -0700

CNRP already asks the resolution services to deal with string normalization
and equivalence issues on a language basis (e.g. do accents or punctuation
matter for French common names). Therefore, it makes sense to ask them to
deal with the fact that different clients may use different UNICODE
canonicalization rules. As Leslie put it, these will be important service
differentiators.

So, to re-iterate Michael's initial proposal:

1. CNRP knows only one encoding: UTF-8 (hex-encoded UTF-8 for the URI)

2. The client must handle encoding translations to accomodate the user
language needs and the fact that CNRP only deals with UTF-8

3. CNRP services are responsible for dealing with string equivalence issues.

These have the merit to keep the protocol very simple which was our goal all
along...

-Nico

-----Original Message-----
From: Patrik Fältström
To: [email-masked]
Sent: 15/04/00 16:26
Subject: Re: Some open questions

At 3:10 PM -0400 4/15/00, Leslie Daigle wrote:
>James Seng wrote:
>>  However, this would also mean interoperability between different
I18N CNRP
>>  clients to be quite challenging since it is different clients may
use
>>  different canonicalization rules and thus the common name queries
may be
>>  different.
>
>It is true that different clients might put different bits on the
>wire as a result of doing different UTF-8 encodings.

Martin do have a draft out talking about _one_ canonicalization, and
one can either:

(1) Specify exactly what canonicalization should be done before a
request is issued

or

(2) Ask everyone which registers a name do it in whatever UTF-8 byte
streams he wants, which include canonicalization permutations.

I am personally more and more leaning towards (2)...

    paf

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 16 Apr 2000 09:52:00 +0200

>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.

The whole idea is that the one using the service (the one sending the
query to the CNRP server) is not to be confused or surprised.

So, to conclude, I think this is a strategy as good as any -- and
most important, it IS a strategy.

    paf

---

From: Leslie Daigle <[email-masked]>
Date: Sun, 16 Apr 2000 14:15:17 -0400

Howdy,

> 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]
-------------------------------------------------------------------