Discussion List for Freenum/ITAD Subscriber Number (ISN) Project

["Ben Teitelbaum" <>]

ISN, as originally conceived, was to be an interim solution on the road to a glorious future of fully alphanumeric SIP URIs (where "interim" might be a decade or two).

Here's a nutty idea: make it possible to derive an ISN from a known email address.

How would this work?

  1) Add a number format TXT record (as suggested below) for each ITAD;

  2) Agree on a hash-based numbering convention (e.g. user "bob" would have a local number that's the first 5 digits of the base-10 SHA1 of "bob");

  3) Add an ITAD TXT record for each domain.

Given an email address (e.g. ""), an ISN for Bob could be derived like this (Perl-esque pseudo code follows):

  1) $itad = `dig +short TXT itad.info.foo.com.`; 

  2) $prefix = `dig +short TXT 
o.$itad.info.freenum.org.`;

  3) $isn = substr(hex2decimal(sha1("bob")), 0, $prefix) . '*' . $itad;

 It would then be possible to write a number of email->ISN resolvers--on web pages, integrated in devices, etc.

What do folks think?  Does this make sense?  Would it be useful?  Anyone interested in trying it out?

-- ben

On 11/29/07, John Todd < > wrote:

I agree with Peter that a "white pages" is needed.  There is actually
someone working on this right now, with an AJAX directory structure
that will take partial or fully qualified substrings and present a
reasonable directory reply.  Hopefully we'll be able to make this
into a small widget that can be embedded easily into other pages.

At 4:01 PM -0500 2007/11/29, John R Covert wrote:
>
>Well, of course it was intended for inter- not just intra-company
>communications, including international.
>
>And I agree that making it useful has been a bit of a problem.
>We have people whose gateways not yet fully installed or are very
>experimental and thus not very reliable.  We also have the problem
>that it's not clear what format to dial for the extension -- do you
>dial 3, 4, 5 digits for an extension, or the full local or national
>or even international number?  No standards exist, and maybe they
>shouldn't be required.

The intention was that extensions were completely open to the local
administrator for (almost) as many or as few (=>1) digits as they
wished.  This is because currently there are no standards within PBX
systems as far as digit length dialing, and it seems unnecessary to
enforce some type of localized digit length.  If your current phone
system uses 5 digit dialing, then instead of coming up with a new
plan, why not just use that 5 digit dialing pattern?  If you don't
use internal extensions but instead use fully-qualified E.164
numbers, then feel free to use that as well though of course that is
a bit unwieldy.

>I'd propose two things:
>1. a standard TXT entry in each ITAD's freenum.org entry which
>    points to a web directory of some sort giving information.

Already there, almost.  :-)

This isn't widely publicized yet, but there are meta-data in the DNS
records already for each ITAD.  For instance, this is the meta-data
for my ITAD (256):

$ORIGIN 256.info.freenum.org.
o                   IN  TXT "Hyjynx Technology Systems, Inc."
street              IN  TXT "14625 Baltimore Avenue, PMB 170"
localityName        IN  TXT "Laurel"
stateOrProvince     IN  TXT "MD"
postalCode          IN  TXT "20707"
c                   IN  TXT "US"
friendlyCountryName IN  TXT "United States"
tz                  IN  TXT "UTC-0800"
friendlyTimezone    IN  TXT "US/Pacific"
lang                IN  TXT "en"
friendlyLanguage    IN  TXT "English"
email               IN  TXT ""

So you get this on a dig:

[root@public asterisk]# dig +short TXT o.256.info.freenum.org.
"Hyjynx Technology Systems, Inc."
[root@public asterisk]#

We currently have a field that can be edited by the administrator of
each ITAD called "Directory URL", and we also have a larger free-form
field called "Number format".  Both of these could easily be
integrated in the same way as TXT records.  Please take a look at
your ITAD settings page on the freenum.org site for these fields.

Any suggestions as to what the identifier should be called?  I
suspect it will be difficult, if not impossible, to make a machine
readable version of "Number format" since REGEXPs are overkill and
frankly nobody will update them, given my experience with everything
else in the database.

>2. the standard that the "0" extension always gets you to some
>    sort of informational message about what to dial, or to an
>    IVR of some sort, or to a human attendant.

A "Best Common Practices" set of extensions is indeed something that
has been mentioned in the past.  Much like "postmaster", "webmaster",
etc. have from RFC2142 ( http://www.faqs.org/rfcs/rfc2142.html)
However, it is highly advised to avoid region-specific assumptions.
RFC2142 is biased towards English, which is a significant downside to
that RFC, IMO.  We have the luxury of being numeric-only, but I'd
hate to specify a set of numeric defaults that are region-biased.
For instance, "411" is not the number for directory assistance in
many nations.

What is the set of desirable extensions to have as suggested (but not
mandatory) destinations?  I agree that "0" is an obvious
directory/receptionist/IVR destination.  What others?

JT

>#2 is already the case at my ITAD, at MIT's, at NPR's, at Octothorp,
>and probably at many others.
>
>But of course, there's no way to enforce any such thing.
>
>/john

-- 
-- ben
http://ben.teitelbaum.us/