Subject: (ION) Portable unique identifiers

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 29 Feb 2000 17:03:33 -0500

A short time ago, the topic of how to formulate portable identifiers
relating to E.164 numbers was broached, and someone mentioned using RFC 2486
for this purpose. RFC 2486 seems appropriate at first glance, because it
addresses a similar problem, for roaming terminals. But I don't think it is
the right approach for this application.

RFC 2486 defines something called Network Access Identifier (NAI), which is
a location-independent unique ID for a user. And the NAI makes use of the
same naming convention used in e-mail addressing: username@realm. This is
nice because it's a familiar and user-friendly format, but it has two
drawbacks for our purposes:

1. It is next to impossible to use such a scheme from a small appliance,
provided with keypad entry only (e.g. cell phone), and

2. The realm part of the unique ID ties the user to some service provider,
making the scheme less than totally portable.

Instead, I propose that a number, perhaps 15 digits long, identified by a
unique prefix, would be about right. This would work with the enum scheme
already scoped out. It could even more easily work with the existing ATM End
System Identifier (AESA) scheme defined in ATM.

In the enum world, one might use a domain other than e164.int. This is not,
after all, an E.164 number.

In the AESA world, one could either define a specific Address and Format
Identifier (AFI) prefix for these AESAs, _or_ one can use the AFI for the
existing embedded E.164 format, and then make use of parts of that 20-byte
frame that are currently unused (the HO-DSP and ESI, for example).

It seems possible to give these portable numbers some sort of hierarchy that
is not geographically based, so as to even the load among several servers.
Not unlike what happens now with E.164. As you go down the digits, the
search is sent off to different servers.

For fancy IP appliances that have a keyboard, RFC 2486 would still be
usable, of course. But there must also be a solution for the smaller
appliance, I think.

Bert
[email-masked]

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.