Re: list of user-visible goals

----- Original Message ----- 
From: "Iljitsch van Beijnum" <[email protected]>
To: "Hector Santos" <[email protected]>
Cc: <[email protected]>
Sent: Friday, February 06, 2004 8:28 AM
Subject: Re: list of user-visible goals

> On 6-feb-04, at 13:25, Hector Santos wrote:
>
> > In other words, the translated lookup user id for the MAIL FROM
> > address must match the authenticated user's account user id.
>
> The problem here is that we tend to think around existing mechanisms,
> or possibly new mechanisms.
>
> [clip]
>
> But if we want to identify people for the purpose of sending email,
> what should this identifier be? Some change their email address on a
> continuous basis while very few of us use the same email address as 10
> years ago. Names just aren't unique. So what then? Social security
> number? GPS coordinates? PGP key or certificate?

Right.   Or maybe your phone (cell?) number?   The US has now made it
possible for you to own your Cell Phone number so I could see this being a
"mail-ng" primary or secondary user key index.

All I can suggest or share is based on my past experiences in similar
situations. Unless the user owns his own domain, it can't be done within the
current infrastructure unless we allow for direct connections which is one
of the items I proposed as a consideration.  Dialup will be commonplace with
VOIP down the road.  Dialup is part of our business today and many of our
customers use it within a "intranet" relationship. It also has a major cost
savings today.  In the past, internet was "cheaper" for the user.  Today,
dialup maybe cheaper than having an DSL,  ISDN or T1 line if you have a low
load requirement.

Whatever it is, it has two attributes:

1) It will have to identify your (the user's) home base, and more
importantly,

2) it will have to be a shared central or distributed registry system or
something that is common to a mail-ng "network" of compliant systems.

My point in my previous message was that it used a specific non-internet
user index association even within an the whelm of an internet protocol.

Essentially what we are talking about here is a "user data base system" and
more importantly, it is shared as a network.  That's the only way possible,
IMO, it can be done.  Whatever it is, whether some external independent
global registry or some new shared, distributed database/registry system, it
can only work if you used the mail-ng lookup query format that touch base
with this new "database" system. Obviously, it (contact location) isn't
going to just come out of the blue :-)

[Extra On - You may Skip This]

Just a FYI, and older network  I am familiar with call Fidonet used the
following format for addressing:

        zone:net/node[.point];

Zone identified a geographic area such as continent, country or nation.

Net identifies a region in the zone.

Node identified the machine/host

Point identified the unique user within the node.

I'm not advocating this format, but it offered much more than just
identifying a node or person. The FidoNet address scheme solved or address
many other issues, some of which are being contemplated here in one way or
another:

o Offer Server attributes [Private, Open, No Files, Netmail Only,  No
Direct, Hours, Protocols etc]

o Offer a level of security due to "membership or registration" requirement

o Offer direct and path routing with optional cost, time restrictions

Server Attributes

Basically a big time overhead saver for clients to know upfront what it can
or can not do when connecting to a server.

Membership

Well, it goes without saying what this means.  It has a bad connotation
today.  But like it or not, it is the direction of the market place. Just
like it was in the BBS days with "localized" membership, this concept is
coming back with many new strategic business models being based on a
"Personalized Network of Trusted Friends."

Since I was in the business since day one, what was ALWAYS missing was a
"global standard" way of sharing the personalized networks.  Some systems
started it in some way or another, but it never took off probably because we
got into this "open wild wild west" of free access, anonymous
communications, etc.  But the internet is most definitely leaning towards
the extra-value of offing a "Login option" for offer "more value" to the
"subscribed" user.   It is the BBS coming back in full circle. :-)

Just the other day we had a customer ask the question: "I wish I can share
the anti-spam filter tables with other wildcat systems."  Well, that can
only happen if we "network" them and when we do that, it means that there
will have to be some sort of "common" authentication/trust relationship
negotiation.

Anyway,  Fidonet offered a capability to network a heterogeneous group of
systems because it was a generic two-way transport protocol for mail and
files. Each system had its own "fido-gateway" system.   It was great during
the "hobbyist" days. It wasn't so great during the transition as people
moved to the internet and were less concern with "membership" systems.

But I always knew that eventually it (in some form or another) would all be
come back again.   People want to Network. It was great to do it a
"free-for-all" internet boom, but now they want to "network" or control
their users again.

Direct/Path Routing

A direct contact was usually reserved for email only (called netmail) and
due to the modem days costing issues, usually prohibited by event
scheduling.   Otherwise routing was used and it followed the address format:

       Source:  Zone1:Net1/Node1
       Target:  Zone2:Net2/Node2

Here was the path:

       Zone1:Net1/Node1
       Zone1:Net1/1             (Net Hub akin to ISP)
       Zone1:1/Net1
       Zone1:1/1
       Zone2:1/1
       Zone2:1/Net2
       Zone2:Net2/1
       Zone2:Net2/Node2

If it was a intrazone route, then it reduced to:

       Zone1:Net1/Node1
       Zone1:Net1/1
       Zone2:Net2/1
       Zone2:Net2/Node2

Of course, a direct contact would be:

       Zone1:Net1/Node1
       Zone2:Net2/Node2

When distributing public mail (i.e. news) or files, it used a seen-by
concept which recorded the path. This is similar to the "Received: lines"
But since it was a number format, it has a "Smart Format" where it only
recorded the change in the zone, net or node numbering.

Seen by:  10:10/1, 2 ,3 ,4 ,5 ,6, 7,  11/2003, 2004,  305/128, 129,
13:4005/222, 233

It was also coupled with a Path: statement which defined the route order.

Also, points are optional.  That means that the host is just a server or
passthru system.

Of course, I think a current email address will work in the same manner.
But the key point here is that no matter what is the format, it will need to
be something that identifies a "home base," sharable within a "network"
concept and also allows for a decoupling concept.

[/Extra Off]