Subject: Some open questions

From: "Marshall L. Moseley" <[email-masked]>
Date: Thu, 13 Apr 2000 15:37:43 -0700

Here are some open questions resulting from Adelaide:

1.  What does the 'path' section of the CNRP URI denote?  What is it's
utility?  I believe the consensu was it enabled multiple CNRP databases on a
single server.  Does anyone disagree?  Have something to add?

2.  Originally comman names were to be express in hex-escaped UTF-8, but
Leslie pointed out to that's only necessary when they'll be encoded in URI.
Any reason we shouldn't use raw UTF-8 in the queries themselves?

--Marshall

---

From: "Martin J. Duerst" <[email-masked]>
Date: Fri, 14 Apr 2000 18:38:36 +0900

>Any reason we shouldn't use raw UTF-8 in the queries themselves?

In what place? Are queries HTTP headers, or are they sent inside some
XML? For the first case, I think you should give it a try, but there
might be some HTTP servers/proxies that choke. In XML, you should
use the native character encoding of the XML resource itself, which
can but doesn't have to be in UTF-8 (unless you restrict it that way).

If you are creating your own protocol, then definitely raw UTF-8
is the best thing to do.

Regards,   Martin.

---

From: Michael Mealling <[email-masked]>
Date: Fri, 14 Apr 2000 09:05:23 -0400

> can but doesn't have to be in UTF-8 (unless you restrict it that way).

The query is XML so it would be in that encoding. I think we talked
about restricting it to UTF-8 but I don't think that made it into
the document. I think we should but I can be persuaded either way.

> If you are creating your own protocol, then definitely raw UTF-8

Should we make the statement that, when outside the XML query it is always
treated as a raw UTF-8 string?

-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, 14 Apr 2000 09:40:32 -0400

Howdy,

> treated as a raw UTF-8 string?

I think we _should_ say that the characterset encoding of common
names is UTF-8.  Period.  Then,

        . within an XML query or response, the common name is
          represented in UTF-8, WITHOUT any hex-encodings

        . within a CNRP URI, the REPRESENTATION of the common name
          is hex-encoding of the UTF-8 common name -- because this is
          an issue for the CNRP URI, not the common name.

        . similarly, in other environments (e.g., particular
          display devices) the common name may be _presented_ in
          a different characterset, but that's a display/data entry
          issue -- it isn't a "common name" unless it's encoded in
          UTF-8.

That seems fairly clear to me, although I'm rather afraid it's because
I don't have a full enough grasp of the real issues in charsets
and encodings.

Leslie.

--

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

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

---

From: "Marshall L. Moseley" <[email-masked]>
Date: Fri, 14 Apr 2000 09:22:41 -0700

And so it shall be, unless someone objects?

--Marshall

---

From: "Martin J. Duerst" <[email-masked]>
Date: Sat, 15 Apr 2000 10:43:57 +0900

>the document. I think we should but I can be persuaded either way.

The pro is that it increases interoperability inside the protocol
itself. There is no chance that something doesn't interoperate
because the 'charset' isn't known.

The con is/may be that you push the conversion from legacy encodings
to UTF-8 to the boundary, where not everybody is equipped equally
well with the necessary tools.

The group should decide based on its understanding of where and
how the protocol will be used.

>treated as a raw UTF-8 string?

No. Outside XML potentially means 'anywhere', and then things
should depend on context.

Regards,   Martin.

---

From: James Seng <[email-masked]>
Date: Sat, 15 Apr 2000 13:31:28 +0800

I believe it is okay to push the conversion to the CNRP client because

1. The client would be able to know the details of the localization needs
   of the users much better than just a tag to the server.

2. There is no legacy CNRP client so it isnt so bad if we specify that the
   client has to do the conversion.

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.

On the URI side, if we standardised on hex-encoded UTF-8, then that would make
specification simple. Rendering of the hex-encoded UTF-8 URI should be left as
an excerise on the client.

-James Seng

---

From: Leslie Daigle <[email-masked]>
Date: Sat, 15 Apr 2000 15:10:38 -0400

Howdy,

> different canonicalization rules and thus the common name queries may be

It is true that different clients might put different bits on the
wire as a result of doing different UTF-8 encodings.  There's just
not a lot we can do to get around that.  However, it is also true
that we've said "matching is a server-side, service-differentiating"
implementation decision.  Different representations sent by the
clients (because of normalization choices) might be recognized as
matching the same thing by the server.

The point is -- we either go UTF-8 and recognize that there are
still some pretty general I18N issues out there, or we pick a single
charset and be able to claim deterministic behaviour for a restricted
set of "textual" input.  Overall, I believe the consensus is in
favour of the first.

Leslie.

--

Leslie Daigle
[email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 16 Apr 2000 01:26:39 +0200

At 3:10 PM -0400 4/15/00, Leslie Daigle wrote:
>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: James Seng <[email-masked]>
Date: Sun, 16 Apr 2000 09:45:47 +0800

> Martin do have a draft out talking about _one_ canonicalization, and

one canonicalization is not entire possible for all languages unfortunately.
At least not in the realm of name protection and keywords registration.

But I agreed that even tho (1) is a technically elegran, deterministic
solution, it is possible that the CNRP service provider still have to do (2).

-James Seng

---

From: "Martin J. Duerst" <[email-masked]>
Date: Mon, 17 Apr 2000 14:09:49 +0900

At 00/04/16 01:26 +0200, Patrik F $BgM (Btstr $B‹N (B wrote:
>Martin do have a draft out

That's http://www.ietf.org/internet-drafts/draft-duerst-i18n-norm-03.txt.

This is rather restricted, and is mainly intended for protocols
that don't want to do complicated things on the server side
(e.g. ftp/nntp/http/...).

As Nico and Leslie have pointed out, CNRP is of a bit of a different
nature, many more equivalences can be taken into account, to offer
more convenience (search instead of just location) to the user.
These have to be done on the server side.

>talking about _one_ canonicalization, and
>one can either:

The one canonicalization addressed in my draft is then just one
among many, and not overly relevant, except maybe because of
the following:

- It may be that despite the fact that CNRP is basically about search,
   in many cases the queries will match exactly (at least from an
   user perspective). If it is also expected that caching is relevant
   to improve performance, it may indeed make sense to say that
   clients have to use NFC (Normalization Form C) canonicalization
   as defined in my draft.

- It may be possible to give some advice to server implementers
   as to the minimum equivalences they should consider, and in
   that case, NFC would definitely be a candidate to be listed.

>streams he wants, which include canonicalization permutations.

This would lead to too many permutations, I'm affraid, in particular
in a searching context.

Regards,   Martin.