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

["Ben Teitelbaum" <>]

John,

These are fair criticisms.  A few brief responses inlined below:

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

Ben -
   I like this idea, but I have three areas of concern:

1) It is complex enough to not be well-understood by most
administrators in this space.  It's difficult enough to get many
sites to understand how the subscriber portion maps to an extension
on their pre-existing platform, much less creating a requirement to
have a totally new program requirement set that forces them to create
aliases for each username and then maps that somewhere else.   This
more-or-less forces an administrator to create an alias table, which
I can say from direct experience will not happen in >98% of the sites
that ever get connected.

Yup, it would forces the creation of an alias table. 

2) If standardized, it would quickly lead to number space conflict
between a 'standard' method and the local method.  Let's say for
"" that the SHA-derived extension (which is
obtainable externally) would be "12345".  Then let's say I had a
local extension here on my PBX that was 12345.  Which "wins"?

The way around this would be to honor the SHA mapping only if the call were received as an ISN invite. 

3) The first X digits of an SHA are not guaranteed to be unique, so
that would lead to possible conflict.

Sure.  That's would be a design consideration in selecting a prefix length and a constraint on usernames.  I concede that hearing: "I'm sorry, you can't have that username.  It's not taken, but another username has the same hash" might really annoy.  :-)
 

I do, however, really like the TXT record for a domain which points
to the ITAD for that domain - that's a great idea.  Once you have the
ITAD that is associated with a domain, then you can look up the
"searchdirectory" URL which then allows the user portion of the email
address to be looked up and the correct subscriber number returned.

I would probably use something other than a new zone trick to
identify this data.  How about coming up with some record that is
tied to the domain in question, using DNS-SD?

Fair 'nuff.  I would lean towards DNS-SD TXT records rather than SRVs since many domain hosting companies don't support SRV.

http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt
http://www.dns-sd.org/ServiceTypes.html


JT


At 3:46 PM -0800 2007/11/29, Ben Teitelbaum wrote:
>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. "<mailto:>"), an
>ISN for Bob could be derived like this (Perl-esque pseudo code
>follows):
>
>   1) $itad = `dig +short TXT
><http://o.256.info.freenum.org/ >itad.info.foo.com.`;
>
>   2) $prefix = `dig +short TXT <http://o.256.info.freenum.org/>
>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 < <mailto:>> 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
>< http://freenum.org>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 <http://256.info.freenum.org> 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 "<mailto:> "
>
>So you get this on a dig:
>
>[root@public asterisk]# dig +short TXT
>< http://o.256.info.freenum.org>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 <http://freenum.org>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>
>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/ > http://ben.teitelbaum.us/

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