RE: AW: [Iptel] comments on rfc2806bis - 800 numbers

["Crizza, Roberto" <roberto.crizza@eds.com>]

Team

We don't have this kind of prblem in my country Brazil, the toll free number
here
is "0800" but it is unique for the hole country, the carrier never assign
the same number to different company the string is 0800 xxx yyyy.

Roberto Crizza
EDS do Brasil
----- Original Message -----
From: Crizza, Roberto <roberto.crizza@eds.com>
To: Ieee (E-mail) <roberto.crizza@ieee.org>
Sent: Friday, November 22, 2002 3:13 PM
Subject: FW: AW: [Iptel] comments on rfc2806bis - 800 numbers


>
>
> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Thursday, November 21, 2002 19:38
> To: Mpierce1@aol.com
> Cc: iptel@ietf.org
> Subject: Re: AW: [Iptel] comments on rfc2806bis - 800 numbers
>
>
> M. Pierce wrote:
>
>
> > [MAP] I think one needs to look at the intended use of this tel:uri. I
> > think of the best example (certainly one of the valid ones) is that the
> > tel:uri is the real information to dial a call that is "behind" a link
> > on a web page. In this case, anyone anywhere in the world may try to
> > place a call by clicking on this link. Therefore, the contents/format of
> > the tel:uri should not depend on whether or not your local national
> > agreements allows the call to be made. The format needs to be one single
> > global format (E.164-type format works well) and the local user
> > agent/device needs to be able to figure out from the information in the
> > tel:uri as well as knowledge of where it is to decide whether or not the
> > call can be made (or even how to make it).
> >
> > The fact that an 800 number can be represented as an E.164 number is not
> > unfortunate - I think it is a big help here.
> >
> > I suggest that the rule is that any number that can be represented in
> > the E.164 format MUST be done this way. (A slight
> > strengthening/clarification of the current text.) This means that an
> > "800" number would never have a context included, just as no other E.164
> > number needs one. This removes some of the difficulties with the current
> > definition.
>
> I think treating tel URIs consistently as identifiers ("URN") helps
> conceptually. After all, if I specify an ISBN number (another URN), it
> is globally unique, but there is no guarantee that my local book store
> can order the book or that the library carries it.
>
> Similarly, there are any number of reasons that a non-800 E.164 number
> can fail: administrative prohibition, number disconnected, invalid
> number, local outbound call filtering, etc.
>
> Thus, the important consideration is only "is this number unique without
> a context"? Thus, a context would be needed if +1-800-something refers
> to two logically different entities in Canada and the US. (Obviously, an
> 800 number may end up in many different locations depending on the
> source of the call, but that's not the problem.) I don't know if that's
> possible. To put it more concretely: will the same 800# ever be assigned
> to two different entities, as in
>
> 1-800-123-4567 reaches PizzaHut if dialed in New York
> and
> 1-800-123-4567 reaches Domino's if dialed in New Jersey
> and
> 1-800-123-4567 reaches WeightWatchers if dialed in Canada
>
> > On the other hand, a more complex web page/user agent may include logic
> > (Java Script?) to provide a single point to click, and the user
> > agent/device would know where it is (within the numbering plans) or the
> > user would have told it and the UA would figure out which one of many
> > internal numbers to use to place the call. Each of these internal
> > numbers would be in the form of a tel:uri.
>
> We need a DHCP option that conveys the local area code! (Sorry, inside
> joke for the Geopriv crowd.)
>
>
> >
> > Mike Pierce
> > Artel
>
>
> _______________________________________________
> Iptel mailing list
> Iptel@ietf.org
> https://www.ietf.org/mailman/listinfo/iptel
>
_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel