Subject: Re: [Enum] enum uri considered harmful?

From: Lawrence Conroy <[email-masked]>
Date: Sun, 1 Sep 2002 19:44:22 +0100

At 9:11 am +0200 1/8/02, Patrik Fältström wrote:
>--On 2002-07-30 16.54 +0100 Lawrence Conroy <[email-masked]> wrote:
>
>>  Well...Unless someone can give answers to these points,
>>  I am not happy with this - IMHO enum: is not the same as
>>  tel: ; enum=yes.
>
>And default is enum=yes I presume. Else we will not be able to start use
>ENUM for existing tel: URI's out there.
>
>    paf

Hi again Patrik, Rich, folks,
(sorry about the delayed response).

As mentioned in my earlier post in this thread, that's my concern.

-We- have two existing "tel:" URI processors, neither of which do enum lookups.
I believe that Brett and the mob at Broadsoft have another one that 
also doesn't
do enum lookups either.

Thus, for -at least- two existing implementations, the default acts 
as if ';ENUM=NO'.

This is not the same as James' URI parameters - you can be justified 
in believing
that the clients connected to "infrastructure ENUM" processing these 
"tel:" URIs
are new clients, and can handle the CIC/RN parameters.
We're not so lucky with "basic" "tel:" clients "out there in the wild".

That's one big reason for my worry - we won't even try an enum lookup 
with these existing
clients, and there's no way to guess in advance what someone has 
sitting on their machine
(unless there's yet another security hole in a certain manufacturer's 
OS and Web Browser :).

Thus, I still think that we need an "enum:" URI. What am I missing?

all the best,
   Lawreence
-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 01 Sep 2002 21:13:49 +0200

--On 2002-09-01 19.44 +0100 Lawrence Conroy <[email-masked]> wrote:

> with these existing clients, and there's no way to guess in advance what
> someone has sitting on their machine (unless there's yet another security
> hole in a certain manufacturer's OS and Web Browser :).
> 

That today ENUM lookup can be injected in the processing of an E.164 number
at whatever node in the network which have that intelligence. I know of
several implementations of IN nodes which look at starting doing ENUM
lookups, and several SIP proxies and various gateways between PSTN and
Internet which also do ENUM lookups.

If a specific node which gets a destination in the form of E.164 number
doesn't do ENUM processing, it will forward the call towards the
destination according to whatever the E.164 routing says.

Finally, the number will reach the "destination" and a clever holder of
E.164 numbers (organisation which allocated the number in the first place)
route the call to some IN node which _can_ do ENUM lookup.

I.e. default for E.164 processing is to do ENUM.

Saying in a tel URI that you do _not_ allow ENUM lookup is an exception to
the standard mechanism and a hint to the processing. My view is that you
still can not prohibit anyone from doing ENUM processing (especially when
you start signalling using SS7 or whatever other protocol which can not
forward the "no" message, only the E.164 number.

   paf