Re: Send-N draft: draft-bellis-enum-send-n-02 published

In your example, the enum client is in a proxy server.  The proxy server is
trying to route a call.  Your solution is to hit enum with some query (not
clear to me how you decide when to start trying, since you at least need to
decode the country code, and may be decoding more than that).  You then get
back send-n.  That tells you how many digits to get, but it's very likely
that you will have to repeat it i.e., you start with the country code, you
get back the minimum number of digits.  You query again, and you probably
get back the right number.

Worst case is you are really dumb and you send a single digit.  You get back
"send 10" for CC1 or send 1 for nearly every other case.  You then send 2
digits and then you would get some number of digits for a minimal TN in a 2
digit country code, or you would get send 1 (for a 3 digit country code).
For the 3 digit case, you query again with one more digit and you get the
minimum number of digits (as with the second call in the 2 digit CC).  You
query again with that number of digits and you either get an answer or some
more send-n.  This continues, each time you have to query the database.

I claim there is no significant difference between the two solutions for an
overlapped dialing device.  They get to the same result with about the same
amount of effort.  Probably my solution uses more memory, but so what.  I
claim that my solution is much better for a non-overlapped dialing device.

You came here with a problem many of us recognize as a real problem: how
does any entity know how many digits it takes to get a routable TN?  We
agree; that's a problem worth solving.  You have a solution in mind to that
problem.  I'm arguing it's not a good solution for everyone with the
problem.  You seem to agree, but you like your solution for the overlapped
dialing case.  I'm suggesting that we are better off solving this problem
for both overlapped and non-overlapped dialing devices using one mechanism.

Brian

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Tuesday, June 24, 2008 12:39 PM
> To: Brian Rosen
> Cc: [email protected]
> Subject: RE: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published
> 
> > Send-n is not implemented in the enum client.
> 
> Not in an end-user client, no.
> 
> > Implement something else (i.e. a client to another database which has
> length
> > information) in the same server.
> 
> When devising this at NICC we did consider several alternatives.
> 
> Using NAPTR records in DNS was ultimately chosen for several reasons, the
> most compelling of which is because it's simply optimally efficient if
> you're already doing a DNS lookup for NAPTR records in an ENUM-like tree
> to get back a Send-N record immediately rather than have to issue a second
> lookup request (whether that request be another protocol or a DNS query
> with a different QTYPE).
> 
> Granted this isn't faithful to the public ENUM dogma that says that
> lookups should only be done on full numbers.  However this isn't intended
> for public ENUM.
> 
> Ray