Re: Send-n, rat holes and real issues

> Doesn't a regular SIP UA have the same issue - knowing when it's got
> sufficient digits to get a final URI?  Send-n can work in that case also.
> Surely it's not all about carriers?
No, Send-N cannot work in those cases.  First of all, that would mean that
the UA is doing repeated ENUM dips, and except in the case of User ENUM
(which doesn't seem to have much traction), is not possible.  It's also, for
intelligent SIP UAs the wrong mechanism because they use something akin to
an MGCP digit map to interpret user GUI interactions.  

Think of a device which knows when it has enough digits that behaves as if
it had a SEND button, but actually the call is automatically placed when the
terminal digit is dialed.  Regardless, the UA wants to have the dialing
plan, not send-n.

> 
> > Other examples I have given include:
> > 1. Validating the shape of an ENUM tree by the ENUM operator.
> 
> How does your web service proposal improve on this?
> 
> Presumably this is mainly a problem when an ENUM operator delegates a
> number
> range to a customer.  Is it the ENUM operators responsibility to monitor
> that tree any more than it is ICANN's (or is it Versign or someone)
> responsibility to monitor the shape of the .com tree?
No.  As an example, the ENUM operator would wish to validate that a number
is a good number before allowing provisioning on the number.

I can speak from some level of experience here, and having good number
length data is very useful when you are operating an ENUM database.

> 
> > 2. Intelligent end devices with SEND buttons and clever GUIs that react
> > well
> 
> Since such devices are relying on a user to tell them the length of a
> number
> I don't see that this needs solving.
I think this is incorrect.  You are repeating the current mobile experience,
where it is entirely the user's responsibility to know when enough digits
have been dialed, and the system's only response is an error tone or
announcement which, typically, is not helpful.  If the device knows that the
number so far entered is not yet complete, it can alert the user of that
fact, either before or after SEND is pressed.

> 
> > 3. Proxy servers and other systems validating numbers before attempting
> to
> > route
> 
> Why can't Send-n do this?  Surely you just do the relevant DNS query?
Because the entity with ENUM access is typically not the entity doing the
validation.  Typically, the ENUM query is at a border element, whereas the
validation function is closer to the user.

> 
> > 4. Routing and rating systems diagnosing problems
> 
> How does the web service solution improve this?
Because the mechanism tells you how long a number is.  It tells you what
good numbers look like.  It gives you the whole picture.
If you have a number, and it fails to route, you can easily determine what
is wrong if the problem is too many or too few digits.  Send-N couldn't do
that, at least easily.

> 
> > The general problem of determining the length of a TN is a good problem.
> > I
> > think we should solve it.  Solving overlapped dialing by emulating how
> the
> > PSTN does it is, in my opinion, a poor choice of solution.
> 
> I'm just not seeing how your web service proposal offers anything that
> Send-n doesn't.  They both allow you to find out how many digits you have
> to
> dial to get an end device.
In the end, you can, by doing enough queries, determine the shape of the
tree, so yes, send-n can be used for everything but validating the enum
database shape (which is a chicken and egg problem for send-n).  On the
other hand, it's pretty darn inefficient to figure out a dialing plan by
doing a bunch of enum queries to get the shape of the number plan.  Think
about how you would go about creating an MGCP style digit map using send-n.
> 
> > And, echoing Peter Koch, enum may not be the appropriate work group to
> > solve
> > the problem.
> 
> That may be.
> 
> I'm coming from a position of a UK user that doesn't want their (or their
> mum's) dialling experience to suffer when the future finally arrives.  My
> perception is that many in the US and other parts of the world don't
> consider variable length numbers an issue, and it's gnarly details
> shouldn't
> contaminate their beautiful technology.
On the contrary, no one is arguing that we shouldn't have a solution that
allows overlapped dialing using black phones but ENUM routing to work. What
I'm saying is that it should be possible to improve user experiences with
newer devices, and other parts of the solution space need number length
data.
> 
> We also have to bear in mind that mobile phones are no longer (well,
> probably never have been) the smallest devices to connect to the internet.
> Why should your fridge download a megabyte table just to be able to tell
> you
> it needs defrosting.  There are also very small IP enabled ZigBee devices
> that we shouldn't prevent from using ENUM.
Then keep the data at the proxy and let the user device do something
simpler.  The end device doesn't do ENUM, although I agree we don't prohibit
that and shouldn't.  Since it seems to be a fact that they don't, perhaps a
different solution is better.

> 
> On that note, we shouldn't assume that such devices are always on either.
> I
> turn off my PCs at night to do my bit to help save the planet.  (I hope
> everyone reading this does also!)  To me that suggests that a push update
> system is not appropriate.
Not sure who is promoting push update.

> 
> I personally wouldn't care whether the whole solution is turned over to a
> web service type solution as long as satisfactory user experience was
> there.
> I find it difficult to think that a system that starts out doing web
> service
> queries, and then switches over to doing DNS queries is sensible.  It
> should
> be all web service, or all DNS.  Not only does that seem aesthetically
> more
> pleasing to me, I would have thought it would make it easier to maintain
> coherency of the data.
Well, I suppose it's the notion that if we are talking about an intelligent
device, first they do some kind of digit map thing, then they do some kind
of routing thing.

They aren't the same thing.  ENUM is a routing database.  This isn't a
routing problem.  It's actually a UI problem, at least the part you are
working on.

Brian