My point was that folk who are looking at this mechanism as an optimization
within the existing boxes should also look at the fact that the box
boundaries are wrong and inefficient.

The use experience should be unaffected by this issue. A telephone call has
ten or so numbers and a DNS round trip should complete before the user types
in the next digit on modern networks.


So what we come down to is attempting to save a few round trips and that
does not excite me greatly as the number of phone calls per day is only in
the billions. And ten billion packets is not such a big deal in the modern
Internet.

It is a worthwhile thing to do, but its a minor detail.


On Thu, Oct 21, 2010 at 11:10 AM, Lawrence Conroy
<[email protected]>wrote:

> Hi folks,
> What you're saying is that you are not the target customer for this stuff.
> I would guess that few people on this list are either.
>
> That does not however mean that a few billion users around the world mostly
> use smartphones or PCs; either that or I have missed the heaps of 12 digit
> phones at landfill sites, or bulging re-cycling warehouses.
>
> Everyone MOSTLY calls from a small contact list, and the same holds for the
> group of people who call them. The goal is to support them when they don't.
> I don't know how long a phone number in Marrakech should be. Rather than
> place an International call to find out I've missed a digit, I would like
> a scheme to help me, ideally before I even get into the voice application.
> I guess I could use google, but that is too Web 2.0 for my taste or
> patience.
>
> As for overlap signalling being obsolete -- it depends on your definition.
> I'm pretty sure every equipment provider would be VERY happy if big Telcos
> removed the requirement, and the requirement to continue to support it for
> years. EnBloc dialling has definite benefits, but until landlines ALL go
> away we're stuck with digit-by-digit dialling.
>
> I'm AssUMing that you are not suggesting that the IETF is soooo slow that
> by the time anything is specified, we'll all be using wristwatch mobiles?
>
> all the best,
>   Lawrence
>
> On 21 Oct 2010, at 12:57, Phillip Hallam-Baker wrote:
> > It is quite possible and rather likely that the PSTN will disappear but
> the
> > numbering system will not.
> >
> > Telephone numbers have a major advantage of being able to be dialed from
> a
> > 12 button keypad without kludges. China and other countries that
> > have syllabaries rather than alphabets are likely to prefer numbers as a
> > naming system since they use a limited character set that can be
> expressed
> > directly on a keyboard.
> >
> >
> > What I expect to disappear is digit-by-digit dialing. Telephone numbers
> are
> > only dialed digit by digit by the user in exceptional cases today. The
> need
> > to support efficient dialing in this fashion seems to arise as an
> artifact
> > of a poorly integrated system.
> >
> >
> >
> >
> > On Wed, Oct 20, 2010 at 10:51 PM, David Conrad <[email protected]>
> wrote:
> >
> >> On Oct 20, 2010, at 5:28 PM, Masataka Ohta wrote:
> >>> Richard Shockey wrote:
> >>>> So what is your point ..you don't use phone numbers so the rest of the
> >>>> planet shouldn't?
> >>>
> >>> As PSTN will disappear, E.164 will also disappear, because there
> >>> will be no PSTN operator to maintain E.164 number space.
> >>
> >> "In the long run, we're all dead" -- John Maynard Keynes
> >>
> >> In the intervening decades, it is probably worthwhile dealing with the
> >> reality that PSTN (and hence E.164) exists.
> >>
> >> Regards,
> >> -drc
> >>
> >> _______________________________________________
> >> Ietf mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/ietf
> >>
> >
> >
> >
> > --
> > Website: http://hallambaker.com/
> > _______________________________________________
> > Ietf mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/ietf
>
>


-- 
Website: http://hallambaker.com/
_______________________________________________
Ietf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf

Reply via email to