[Tfug] Naming scheme

[Bexley Hall]

Hi, Stephen,

> So... if I call my PDA "Foobar" then just send that
> along with the id number of the device.

The scheme I mentioned (i.e. name in a file under the
exported "root" for each device) makes the information
available "on demand" instead of requiring it to be
announced when a node joins the cell/network.
6 of one; half dozen of another.  I try to provide
handles and let other layers retrieve what additional
information they want *from* that.  The presentation
layer can present just the name to the user (hiding
the mechanics of all this)

> If there are two "Foobar's" then you can make the
> decision to either
> give more identifying information by marking the
> differently (color,
> sound, appending a number, etc.):
> 
> /users/Foobar (1)
> /users/Foobar (2)

But, then user 'Foobar' has no way of being able
to tell user 'Bob' that "I am Foobar (1)" -- since,
presumably, the (1) and (2) modifiers were created
locally by Bob's device and may differ from what
some other user (in the same network) sees *this*
'Foobar' user as (clumsy sentence).  Since the
"unique (albeit unfriendly) identifier" *is* unique,
it lets Bob ask Foobar, "Hey, I see two Foobar's
here.  Which one are you?"

> > Unfortunately, this is not the *intuitive* way of
> > doing it.  People would rather see the *names* of
> > these people instead of some obscure "identifier".
> > E.g., I would rather find /users/Stephen.Hooper
> > than /users/12884353 (though one could always
> adopt
> > a convention of putting the user's "name" *under*
> > the identifier in terms of the hierarchy.  I.e.
> > /users/12884353/identification would contain
> > the string "Stephen Hooper").
> 
> I don't see you would need to present the number at
> all...  just choose a different way of presenting
> your information.

You still need *some* way for Foobar A to know that
on Bob's device he is "Foobar (1)" while on Tom's
device he may be "Foobar (3)"  (think about it)
You need some way that each Foobar can clarify
their identities to interested parties.

> > The problem is, if you do things the user friendly
> > way, then you can end up with lots of conflicts in
> > the name space.  I.e. all the users who decide
> they
> > just want to identify themselves as "Bob", etc.
> 
> Rely on information that you can insure is unique. 
> If you can't
> insure uniqueness of  user supplied nformation, then
> don't rely on the user supplied information.

You want to be *friendly*.  If most interactions are
small and with known individuals, then the human
readable identifier is the friendliest approach.
So, don't encumber the typical use.  It's only
when you are in larger/unknown groupings that the
probability of namespace conflicts becomes
problematic.
So, let those interactions pay the price.  And, only
for those names which are conflicting.

> > The problem is there is no naming authority that
> > ensures the uniqueness of names (other than
> relying
> > on some hardware-specific mechanism like a MAC
> > address, etc.)
> >
> > Hence, I don't think it *is* "solvable" by its
> > very nature.  The best approach I can come up with
> > is the indirect scheme -- register the device in
> > the namespace using it's unique identifier (e.g.,
> MAC)
> > and then put the "user defined" identification
> > *under* (subservient) this for perusal.  There,
> > conflicts are avoided since this is now the user's
> > own *personal* namespace...
> 
> Are you sure that the MAC address is a good way of
> ensuring
> uniqueness?  What will these devices cost?  What
> happens if I want to
> upgrade my device, or the network card breaks?  Will
> you scrap the
> device?  If not, what happen's to all the people who
> are using it to
> give me permissions to see their stuff?

This scheme only applies to "public" interaction.
I use secure keys for "trusted" exchanges.  I.e. if
you and I have already set up certificates, then I
don't *care* what you are calling yourself
*publicly* -- since we already have a rapport
and channel for exchanging data (beyond that which
is public).

(But, yes, the "MAC" *is* guaranteed unique.  You
can change it if you can disassemble the product,
find it's location in the ROM, burn a new ROM, etc.
I.e. if you want to do it as an academic exercise,
you can.  But, it won't *give* you anything more
than simply changing your public name to "Bill
Clinton" would, etc.)

> That question asked, I think your problem is
> solvable.  I think
> attempting to build a free-for-all global namespace
> is not solvable...
> at least no one has ever solved it.

Hence the desire not to rely solely on that single,
untrustworthy means of identification/interaction.
But, rather, use it solely for the ad hoc interactions
of "strangers" (which can be burdened if necessary)

> You will always end up with two John Smith's living
> in the same
> country, same internal political division, same
> city, same, same
> street, same curb number, same apartment number.

Exactly.  I know 3 "David Taylors", etc.
 
> That is why they have to collect all this
> information (year of birth,
> Junior, Senior), and ultimately rely on unique
> numbers to identify
> ourselves (social security in the USA). Until you
> hit the number you can't make any guarantees.

Yes, hence the reliance on the "MAC".  But, there
is no need to rely on it "unadorned" since many
interactions will not need that level of unambiguity
(i.e. names *will* be unique in many exchanges)

> I was trying to point out solutions to your problem,
> and not
> suggesting you could make a non-central unique
> namespace work for you.
>  I thought that was clear by my suggestions.

Understood.  The mechanics are easy to implement
but the underlying problem is where the inherent
"insoluability" (?) lies.  Trying to pretty-it-up
to make it less technical (to average user's) is
where the engineering comes in.

Thanks!
--don

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com