In other words, if 1-800 numbers are unique they can be tought of
as E.164.
If they are not unique, then they need to be tought of as local
number with an associated context.
I might be wrong, but I believe that the first case is the right one.
> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Thursday, November 21, 2002 1:38 PM
> 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
>