Subject: Re: Sub-Names

From: Nicolas Popp <[email-masked]>
Date: Tue, 18 Jul 2000 19:06:43 -0700

Adam.

>great about cnrp supporting any type of syntax structure. are the servers
>able to interpret different characters different ways? so it would be
>possible for a service to define the '@' character as purely a seperator
>between a main-name and a sub-name?

There are no specified rules on how common names strings should be
interpreted by a CNRP service. So CNRP services are free to create any kind
of rules that they deem valuable from a user experience standpoint. These
rules are considered as service differentiators and are not standardized by
CNRP. Personally, I think that introducing a syntax that moves away from the
natural language interface is a bad idea as it brings us back to the URL
world...

>and also, i'm afraid i must have been a bit unclear in my original email.
>i never intended to directly translate domain names and the domain name
>structure over to the CN namespace (search.yahoo, something.msn, etc.).
>i was merely using the domain name examples to better convey how my idea
>worked. i hate the dots-with-run-on-words syntax of the domain name space
>for any type of consumer- or general public-based navigation system.
>i was only trying to explain that the 'idea' of sub-domain names should
>be implemented in the common name system (which i now find out it already
>can, correct?).

 I think we understood that. The notion of prefix (not a CNRP notion anyway)
can be any string. It does not have to be a domain name.

>also, the reason i emphesize the seperating character (@, >>, or whatever),
>is because if a CN service uses or allows eBay to use something along
>the lines of 'eBay [item to search]', what happens if someone comes along
>trying to register an actual CN of 'eBay Books'? do i make any sense?
>how is the server able to differentiate between a sub-name with main-name
>between just simply a multiple-word main-name?

By applying some resolution precedence rules when you are matching the query
string against your database of common names. So, if 'ebay collector books'
exists as a mapping to a static link in your CNRP database, you just resolve
to that static URL. If it does not you may want to check whether you have
the prefix 'ebay collector' and map it the corresponding dynamic URL (search
+ query). If it does not, then you try just 'ebay" as a prefix...

To summarize my point, there is nothing in CNRP that prohibits a service to
introduce a natural language syntax (or a non natural one, but it would
kinda violate the spirit of CNRP). Even something like "macy's in palo alto"
could be interpreted as:

<commonname>macy's</commonname>
<property name="geography">palo-alto</property>

Although these things are very interesting (to me at least!), it is also
worth noting that there are not part of the protocol at all...

Cheers.

-Nico

-----Original Message-----
From: Adam Theo [mailto:[email-masked]]
Sent: Tuesday, July 18, 2000 5:48 PM
To: [email-masked]
Subject: Re: Sub-Names

Hello, Adam Theo here

great about cnrp supporting any type of syntax structure. are the servers
able to interpret different characters different ways? so it would be
possible for a service to define the '@' character as purely a seperator
between a main-name and a sub-name?

and also, i'm afraid i must have been a bit unclear in my original email.
i never intended to directly translate domain names and the domain name
structure over to the CN namespace (search.yahoo, something.msn, etc.).
i was merely using the domain name examples to better convey how my idea
worked. i hate the dots-with-run-on-words syntax of the domain name space
for any type of consumer- or general public-based navigation system.
i was only trying to explain that the 'idea' of sub-domain names should
be implemented in the common name system (which i now find out it already
can, correct?).

ie: [sub-name] [seperating character] [main-name] (or in reversed order
for many non-english languages).

ie: Shop @ Yahoo! would take the browser directly to Yahoo!'s shop section,
instead of the user having to type in the CN of Yahoo!, then follow links
to get to Yahoo!'s shop section. and also instead of Yahoo! having to
register/buy a whole 'nother CN solely for the purpose of directing users
to their shop section. they can instead just make use of their existing
CN they already have.

also, the reason i emphesize the seperating character (@, >>, or whatever),
is because if a CN service uses or allows eBay to use something along
the lines of 'eBay [item to search]', what happens if someone comes along
trying to register an actual CN of 'eBay Books'? do i make any sense?
how is the server able to differentiate between a sub-name with main-name
between just simply a multiple-word main-name?

--
Adam Theo
[email-masked] - EMail
3617306 (Adam Theo) - ICQ
1 (404) 978 1263 x2974 - VoiceMail/Fax
Proudly Running Linux!

___________________________________________________________________
To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax,
all in one place - sign up today at http://www.zdnetonebox.com

---

From: James Seng <[email-masked]>
Date: Wed, 19 Jul 2000 13:53:10 +0800

I think what Adam has in mind is some sort of 'hierarchy' convention in
the CNRP system, like DNS, but instead use '@'.

For example, a Common Name like "Shopping @ Yahoo", the CNRP server
which receives it may then refer the query "Shopping" common name
request to cnrp.yahoo.com, thus forming a chain, and specific query
system.

IMHO, it is not generic enough to handle all cases..certainly, you do
not want to type in "Learning XML @ Bookstore @ Amazon" to look for a
book. Worst, you will be forced to remember the hierarchy which defends
the purposes of the common name in the first place, ie just plainly
"Learning XML". And of course, if you are looking for a hierarchy
system, then the question you should ask is why not just DNS?

-James Seng