Re: Send-n, rat holes and real issues

- Original Message From: "Brian Rosen"

> Please read the thread.

I have been.  I might have missed stuff though.

> The general problem is determining the length of a
> number.  The subset is the problem of overlapped dialing where the 
> endpoint
> is sending digits blindly and the network doesn't know what the length of
> the number is.

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?

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

> 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.

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

> 4. Routing and rating systems diagnosing problems

How does the web service solution improve this?

> 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.

> 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.

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.

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.

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.

Thanks,

Pete.
--
=============================================
Pete Cordell
Codalogic
=============================================