Subject: Re: Solicitation for a discussion on Keyword-based addressing

From: "张国强" <[email-masked]>
Date: Tue, 07 Apr 2009 09:42:00 +0800

�����������������ᵽ:
>From: Stephane Bortzmeyer <[email-masked]>
>Reply-To: 
>To: zhangguoqiang <[email-masked]>
>Subject: Re: Solicitation for a discussion on Keyword-based addressing
>Date:Fri, 3 Apr 2009 17:38:29 +0200
>
>On Wed, Apr 01, 2009 at 11:16:36AM +0800,
>  zhangguoqiang <[email-masked]> wrote 
>  a message of 156 lines which said:
> 
> > Our keyword-based addressing draft is available at
> > http://tools.ietf.org/html/draft-zhang-keyword-ddds-00, which
> > specifies keyword-based addressing as a DDDS application.
> 
> OK, I've read the draft and here are my remarks.
> 
> First, the way I understand section 3.1, the fully-qualified keyword
> will be something like cn:+huawei or cn:=li Correct?

Yes, in the current version draft, the fully-qualified keyword is in this form. 

> If so, I seriously doubt it is simpler for users to type cn:+huawei
> than huawei.cn. The draft seems to imply that country-codes could be
> omitted when in a given country but the corean travelling to China
> will have to remember to add kr: in front on every keyword he's used
> to. It does not seem very convenient to me. Frankly, I do not see the
> advantage over domain names.

Your doubts make sense. There is debate on the classifier, i.e, "+","@"... Some
strongly suggests total removal of the classifier. For the country code, however,
the users do not need to type it each time. It can be some form of the user's
settings, for example, the browser's setting. So when a korean travel's to China,
he don't have to add kr: in front on every keyword he's used. 
If the classifier is removed, the user only need to type "huawei", which is also
our ultimate goal.   

> There is a policy issue with the organization stricly by country: some
> countries may wish to decline participation. And some people may wish
> to use a system different than their national one.

Policy issues are inevitable for registration-based services. However, as I said,
keyword is not intended to replace DNS, It is a useful technique especially
favored by non-english speaking countries and with customized writing habits.  

> Now, about the use of the DNS, guidance like "Clients are encouraged
> to check for additional information but are not required to do so."
> seem to contradict RFC 2181, section 5.4.1. Sentences like "Until all
> resolvers can handle larger responses" are incorrect (the problem is
> typically not in resolvers but in middleboxes, see the Nominet report,
> for instance).
Thanks for these comments, I will check them carefully.

> A nit: RFC 2396 has been replaced by RFC 3986.

Yes.

---

From: Stéphane Bortzmeyer <[email-masked]>
Date: Wed, 8 Apr 2009 08:23:25 +0200

On Tue, Apr 07, 2009 at 09:42:00AM +0800,
 <[email-masked]> wrote 
 a message of 66 lines which said:

> It can be some form of the user's settings, for example, the
> browser's setting. So when a korean travel's to China, he don't have
> to add kr: in front on every keyword he's used.

If he has his own machine (or if he remembers to configure it for
korean keywords). With domain names, I can work in a cyber-cafe or
with the machine of a friend and it works just fine.

Also, the same trick is possible with domain names. A browser
configured in France could certainly add '.fr' at te end of each
domain name.

> If the classifier is removed, the user only need to type "huawei",
> which is also our ultimate goal.

Creating a flat namespace does not seem a way forward.

> It is a useful technique especially favored by non-english speaking
> countries

So, it seems the real reason is the delay in IDN deployment. If IDN
were to be deployed in the root (something that should have been done
years ago), I do not think there would be any reason to keep keywords.

---

From: "zhangguoqiang" <[email-masked]>
Date: Wed, 8 Apr 2009 14:59:18 +0800

Before any further arguments on whether it is necessary to introduce keywords and the detailed solution. Let me list some usage scenarios and requirements of Keywords, which accomodates the suggestions proposed by John.

(1) A keyword can be associated with more than one URI, but typically is associated with only one URI.
(2) Users in most cases(or by default) only need to access keywords in their own countries, but the system should provide mechanisms to allow users to access keywords across national boundaries.
(3) Keywords should be simple but without losing usability. A single level of keywords is common, but there are increasing demands for two level keywords. For example, a blogger publishing its blog to others will use the keywords formatted like "yahooblog:bob". So as a compromise between simplicity and practicability, keywords can have at most two levels. 
(4) Keywords system should respect cultural writing conventions. For two level keywords, different countries may have different writing conventions. Western people often write the most significant part in the rightmost portion, while in other countries, for example China, favors writing the most significant part in the leftmost portion. Keyword systems should enable various writing conventions. 
(5)Keywords system should enable server-side matching rules that could apply Unicode normalization, CaseFolding, etc. 
(6)Keywords system should enable different matching rules for different keyword regions.
(7)Keywords system should allow multiple names at a given node, rather than CNAME-like alias function that points between nodes.

2009-04-08 

zhangguoqiang 

发件人： St閜haneBortzmeyer 
发送时间： 2009-04-08  14:35:05 
收件人： [email-masked] 
抄送： [email-masked]; [email-masked] 
主题： Re: Solicitation for a discussion on Keyword-based addressing 
 
On Tue, Apr 07, 2009 at 09:42:00AM +0800,
  <[email-masked] > wrote

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Apr 2009 16:26:47 -0700

Hi -

> From: "zhangguoqiang" <[email-masked]>
> To: "St閜haneBortzmeyer" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Tuesday, April 07, 2009 11:59 PM
> Subject: Re: Re: Solicitation for a discussion on Keyword-based addressing
...
> For two level keywords, different countries may have different writing
> conventions. Western people often write the most significant part in
> the rightmost portion,

This is the second time I've seen this assertion.
It rings false, so I'd like to know just what is
being claimed here.

The existence of "Western" languages in which adjectives follow
nouns (e.g. Spanish), precede them (e.g. German) and occur on
both sides (e.g. French), as well as the widespread convention
of writing numbers most-significant portion first, all seem
to contradict the assertion that there is some sort of "western bias"
towards putting the most significant part rightmost.

Randy

---

From: John C Klensin <[email-masked]>
Date: Sat, 11 Apr 2009 13:02:23 -0400

--On Wednesday, April 08, 2009 14:59 +0800 zhangguoqiang
<[email-masked]> wrote:

> Before any further arguments on whether it is necessary to
> introduce keywords and the detailed solution. Let me list some
> usage scenarios and requirements of Keywords, which
> accomodates the suggestions proposed by John.

This material should be in the document.  I suggest it would be
worth your revising it to accommodate this material and your
responses to the other suggestions that have been made before
the discussion proceeds much further.

> (1) A keyword can be associated with more than one URI, but
> typically is associated with only one URI.

I can see advantages to allowing this, but also disadvantages of
needing a potential resolver for ambiguity.   If it is
"different URIs, but pointing to identical copies of the same
object" it would be, IMO, fine.  But note, for example, that
equivalent copies of the same object are different from
identical ones.  "Equivalent" is often what is most desirable,
but then you have to define "equivalent" unless you think that
is best left to operators of keyword systems... in which case
the document needs to say that and to sketch out how things
would work in practice.

> (2) Users in most
> cases(or by default) only need to access keywords in their own
> countries, but the system should provide mechanisms to allow
> users to access keywords across national boundaries.

See comments in my last note.  I'd also encourage you to think
really carefully about "country" and "national".  It sets off
all of the problems about internationally-standardized country
codes versus the many names by which a country can be called (or
might call itself), how those names are written, and how to
avoid conflicts between preferred names that are problematic in
ICANN these days, it may deprive you of the ability to do
language-sensitive things (again, see previous note).  And it
means that governments will end up having to choose a single
keyword operator per-country, which may not be wise in some
places either.  If one is going to go to the trouble of
inventing a new naming system, one should try to learn as much
as possible from the areas in which the DNS has not worked.  I
suggest that evolving into something that needs a system the
size of ICANN to administer a single level of the hierarchy is
something that one should strive to avoid, not re-invent.

> (3)
> Keywords should be simple but without losing usability. A
> single level of keywords is common, but there are increasing
> demands for two level keywords. For example, a blogger
> publishing its blog to others will use the keywords formatted
> like "yahooblog:bob". So as a compromise between simplicity
> and practicability, keywords can have at most two levels.

While I understand the principle of compromise, prior experience
with naming systems strongly suggests that, if one needs three
levels, then one is certainly likely to discover that one needs
four or more.  Maybe one can draw the line at two, but the above
doesn't suggest two but three (it is really "[cn]yahooblog:bob"
(see that previous note about this notation).

>  (5)Keywords system
> should enable server-side matching rules that could apply
> Unicode normalization, CaseFolding, etc.  

The most important server-side matching operations aren't these
simple Unicode operations which, being Unicode operations, are
more or less globally applicable.  Think rather about being able
to match Simplified and Traditional Chinese without resort to
rather complex variant systems, being able to apply matching
rules for Swedish and Norwegian that are sensitive to the same
characters being written differently, to rules for French that
are slightly case-sensitive but not entirely so, to rules for
Greek that could ignore Tonos when appropriate but not when it
is not, to rules for Arabic and Hebrew Scripts that would handle
Harakat and "vowel points" in appropriate ways, and so on... for
a rather long list of things that Unicode operations cannot
provide.  Certainly the Unicode matching operations should be
considered as well, but we know how to fake those, more or less.

> (6)Keywords system
> should enable different matching rules for different keyword
> regions. 

See above and note that your proposal (at -00) has no provision
for this.

> (7)Keywords system should allow multiple names at a
> given node, rather than CNAME-like alias function that points
> between nodes.

Also see above and note that your proposal (at -00) has no
provision for this.

To repeat what I said above, I'd really like to see a new draft
that addresses these many issues.

    john