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

[John Todd <>]

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.

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"?

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


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?

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/