Subject: [Iptel] Tel URL and ENUM dips

From: Cullen Jennings <[email-masked]>
Date: Sun, 22 Jun 2003 19:52:01 -0700

There has been some discussion about indicated a ENUM query has already been
done for a given tel URL.

The use case given is usually something along the following lines: A call
control element such as a SIP phone gets a phone number and tries an ENUM
lookup on it. No record is found in the DNS query so the call is sent to a
proxy (or a gatekeeper) that might know how to route the call. This proxy
does not know the ENUM query has been tried so it tries the ENUM query over
again.

This is somewhat wasteful and adds to the latency of the setup but does not
introduce any horrible failures into the system. I have heard three
proposals to deal with this. They are:

A) Don't do anything - it's not that big a problem.

B) Add a flag to the tel URL to allow it to indicate if an ENUM query has
been done - much like the local number portability indicator.

C) Create a new URL, say an enum URL, that specifically indicates a enum
query is required and change the semantics of the tel URL to specifically
not do an ENUM query.

Are there other proposal to this problem that I am missing? The slim number
of opinions I have got so far mostly favor B. If there are strong argument
for or against any of these - sometime between now and Vienna would be a
good time to get them on the list.

Perhaps deciding this is not possible without a stronger statement of what
the semantics of tel URL are. If people feel this is the case - let's get
the issues about tel semantics on the table.

Thanks,
Cullen

_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 22 Jun 2003 23:48:24 -0400

I tend to favor (B) - it qualifies the meaning of tel, but not strongly 
enough that a new scheme is justified (since option (A) works, if 
sub-optimally).

Semantics are currently defined as "The ``tel'' URI describes resources 
identified by telephone numbers." (from the abstract of 2806bis)

As I've noted in earlier discussions, tel URIs are closer in spirit to 
URNs such as ISBNs than they are to, say, a SIP URI or http URI. (One 
could make a case that they should be urn:tel:, but I won't go there for 
now.) If looked at as a URN-like thingie, the question is essentially 
moot, or only as interesting as asking what the semantics of an ISBN 
are. A tel URI doesn't "do" anything unless it is translated into a 
dialstring (internally), SIP URI (via ENUM) or some other 'actionable' 
URL that has protocol semantics - just like an ISBN URN doesn't 'do' 
anything until it is translated into a HTTP URL, say.

May I suggest that any such discussion has to include concise, testable 
definitions.

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Mon, 23 Jun 2003 10:13:01 +0100

Hi Folks,
   You can guess that I'm in favour of (C), as I feel that the current
"dual use" of the "tel:" URI is confusing. As I've argued before, splitting
"tel:" from "enum:" would be pretty clear - "enum:" requires an ENUM lookup
to be resolved; "tel:" does NOT require an ENUM lookup (and existing RFC2806
"tel:" software that by definition doesn't do an ENUM lookup carries on this
way).

There is a tendency to consider the "tel:" URI to be associated with 
a telephony
resource - i.e. it can be *used* to deliver a call to a telephony-addressed end
point. In theory it could imply that the recipient will be able to handle only
a web request, but in practice it is usually taken to mean that this addresses
an end point that can handle Real Time Communication sessions.

Creating an "enum:" identifier means that we have something that is guaranteed
to say nothing about the session that will result - the only way to even find
out the session choices is via an ENUM lookup.

IIRC, Jon has argued that, at most, we should have a URI parameter such as
"enum=yes". I think that the effect is similar, with differences only in some
implementation details; specifically, if there's a browser plug-in for "tel:"
and this cannot or won't do ENUM lookups, then having a different scheme
reduces parsing - minor point.

I do still have one confusion on the use of a enum://tel:;enum=yes URI in
a session control/call setup sequence. Doesn't this have the same security
issues as CPC and the original ideas on "database dip" indicators?

all the best,
   Lawrence

>I tend to favor (B) - it qualifies the meaning of tel, but not 
>strongly enough that a new scheme is justified (since option (A) 
>works, if sub-optimally).
>
>Semantics are currently defined as "The ``tel'' URI describes 
>resources identified by telephone numbers." (from the abstract of 
>2806bis)
>
>As I've noted in earlier discussions, tel URIs are closer in spirit 
>to URNs such as ISBNs than they are to, say, a SIP URI or http URI. 
>(One could make a case that they should be urn:tel:, but I won't go 
>there for now.) If looked at as a URN-like thingie, the question is 
>essentially moot, or only as interesting as asking what the 
>semantics of an ISBN are. A tel URI doesn't "do" anything unless it 
>is translated into a dialstring (internally), SIP URI (via ENUM) or 
>some other 'actionable' URL that has protocol semantics - just like 
>an ISBN URN doesn't 'do' anything until it is translated into a HTTP 
>URL, say.
>
>May I suggest that any such discussion has to include concise, 
>testable definitions.
>
>Cullen Jennings wrote:
>

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

---

From: Richard Shockey <[email-masked]>
Date: Mon, 23 Jun 2003 10:35:08 -0400

>"tel:" software that by definition doesn't do an ENUM lookup carries on this

Well as we know this has come up several times before ..specifically I 
remember this discussion in Yokohama where the concept of the ENUM URL was 
not well received in the ENUM WG..

Obviously I favor B since 1. it matches current practice 2. I've yet to see 
a convincing argument that C. is necessary. The presence of a tel: url 
could have a presumption that a query has _not_ been done and the 
attachment of the dip indicator would then indicate it has.

IMHO the ENUM indicator is a good idea and worth proceeding with documentation.

>There is a tendency to consider the "tel:" URI to be associated with a 
>telephony
>>moot, or only as interesting as asking what the semantics of an ISBN are. 
>>A tel URI doesn't "do" anything unless it is translated into a dialstring 
>>(internally), SIP URI (via ENUM) or some other 'actionable' URL that has 
>>protocol semantics - just like an ISBN URN doesn't 'do' anything until it 
>>is translated into a HTTP URL, say.
>>

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 23 Jun 2003 13:19:58 -0400

I favor "B" as well, but (as Patrick pointed out recently in a private discussion
about this), there is the issue of allowing for use of alternative roots for
"enum-like" applications, in which case a simple boolean will no longer do.

-- Flemming

---

From: Michael Hammer <[email-masked]>
Date: Mon, 23 Jun 2003 14:41:49 -0400

Flemming,

Are you suggesting that the parameter should list out all the roots tried 
thus far, and only do dip if another known root hasn't be checked yet?

Would at some point, the list be long enough that it would be faster to 
simply do option "A" do dips in the ENUM sites you know?

Could the presence of "ENUMi" (versus ENUM="yes") simply mean that the 
golden root had been tried?

Mike

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 23 Jun 2003 14:55:25 -0400

Michael Hammer wrote:

> Flemming,
>
> Are you suggesting that the parameter should list out all the roots
> tried thus far, and only do dip if another known root hasn't be
> checked yet?
>

I didn't suggest any specific solutions; I merely noted the potential
issue.

>
> Would at some point, the list be long enough that it would be faster
> to simply do option "A" do dips in the ENUM sites you know?
>

Hard to speculate on how many roots we might have and/or want to
support.

> golden root had been tried?

Clearly we would want to support the golden root, and specific syntax
aside, you can always define a simple way of expressing that the golden
root has been tried; the question is whether we want to enable more than
that.

-- Flemming

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 23 Jun 2003 21:14:43 +0200

On måndag, jun 23, 2003, at 20:41 Europe/Stockholm, Michael Hammer 

> golden root had been tried?

That is not enough either (see separate email). You also have to say 
what enum service fields you have ignored (I think, I have only spent 
some 10 minutes thinking about the problems with this).

    paf

> strongly
> resources
> testable

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 23 Jun 2003 21:13:15 +0200

On måndag, jun 23, 2003, at 19:19 Europe/Stockholm, Flemming Andreasen 

> "enum-like" applications, in which case a simple boolean will no 

Correct.

In theory, DNS is coherent, and if everyone really use the same root 
(e164.arpa), every lookup should give the same response, but, in 
reality that is not the case. Because of this, the design of this flag 
must be extremely carefully thought out, and it must absolutely be the 
case that the receiver something which has this flag set is not 
guaranteed anything at all, so he can do another lookup if he wants to.

Just two scenarios when B should do another lookup even though A has 
done it:

1. A get a call for destination 1234, and to an enum lookup for 
4.3.2.1.e164.foo.
    B get the call with the flag set, but B uses root e164.arpa.

2. A get a call for destination 1234 but throws away records with a 
certain
    ENUM-service-field.
    B get the call with the flag set, but B can handle those 
ENUM-service-fields.

       paf

>>> a
>>>> to

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Tue, 24 Jun 2003 14:02:17 +0100

At 9:13 pm +0200 23/6/03, Patrik Fältström wrote:
>On måndag, jun 23, 2003, at 19:19 Europe/Stockholm, Flemming Andreasen wrote:
>
>reality that is not the case. Because of this, the design of this 
>flag must be extremely carefully thought out, and it must absolutely 
>be the case that the receiver something which has this flag set is 
>not guaranteed anything at all, so he can do another lookup if he 
>wants to.
>
>Just two scenarios when B should do another lookup even though A has done it:
>
>2. A get a call for destination 1234 but throws away records with a certain
>    ENUM-service-field.

<rest of thread snipped>

[with Apologies to any [email-masked] - expunged from cc list]

Hi Patrik, folks,

  Um...ENUM (a la RFC2916 and 2916bis) cannot be used to search
other than in the golden tree; the Initial Key generates a domain
that ends in .e164.arpa. (note trailing dot).
For other uses, one could produce an ENUM-like DDDS application;
this will happen, if only for Carrier/Infrastructure/Private use.
However, it is not ENUM (as specified in 2916bis). Thus (as I think
Patrik is suggesting), edi is only talking about ENUM as specified.
Given that edi means ENUM Dip Indicator, then this is fine.

BTW, this means that, in the above case (1) A *MUST NOT* set the edi flag,
as it has NOT done an ENUM lookup; it has looked in some voodoo domain.

However, anything more is dodgy. As these ENUM-like applications
may be processed by units that have at least different views, it's
extremely risky to assume any but random behaviour; the recipient
may be looking at a completely different set of data, so a "X dip done"
flag is generally of no use.

There ARE circumstances in which this may work - James Yu did an I-D
on the npdi flag already; I don't see why we need to re-invent something.

Isn't having ->a<- common data source for all to see one of the reasons
why we went away from the chaos of alternative roots in the first place?

all the best,
   Lawrence

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 24 Jun 2003 15:42:06 +0200

On tisdag, jun 24, 2003, at 15:02 Europe/Stockholm, Conroy, Lawrence 

>>    B get the call with the flag set, but B uses root e164.arpa.

You are absolutely correct that the EDI might indicate a dip in 
e164.arpa.

But, what about this second case?

   paf

> Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, 
> Bracknell,
> Berkshire. RG12 8FZ
>
> The information contained in this e-mail and any attachments is 
> confidential to
> Roke Manor Research Ltd and must not be passed to any third party 
> without
> permission. This communication is for information only and shall not 
> create or
> change any contractual relationship.