Subject: [Iptel] tel: URI resolution

From: "Alexeitsev, D" <[email-masked]>
Date: Mon, 3 Mar 2003 15:52:22 +0100

Hello All

To kick-off the discussion on tel: URI resolution I would like to share some initial ideas on this subject:

There are two major possibilities for tel: URI resolution

1) The general one using DNS/ENUM system as described in RFC 2913 § 7.3 Example 3.
The additional consideration may be given to the fact that probably not all complete e.164 numbers will be put in to the DNS,  but just CC, NDC or parts of SN thus changing the NAPTR in the example to something like:

given the tel:+1-770-555-1212

$ORIGIN 7.1.e164.arpa
IN NAPTR 100 10 "u" "sip+E2U" "change to sip:[email-masked];user=phone"
IN NAPTR 100 10 "u" "mailto+E2U" "change to mailto:[email-masked]"

then one would resolve the sip: URI following the 3263 procedures

2) Not so general one that is probably more interesting for special propose clients (SIP only, HTTP only, SMTP only,...)
This mechanism is based on the RFC 2169 where an update for SIP would be strait-forward, but the general description could be used in the draft-antti-rfc2806bis to keep tel: URI protocol independent, i.e. resolvable using http, sip, smtp,...

An option could be to say that if tel: URI resolves (among others) to the URL of the protocol that is being user for it's resolution, then instead reporting back the resolver may continue with the session setup using resolved URL. And only in the case that the session setup fails report the URLs of other protocols.

Of course this mechanisms do not exclude each other but can be combined in a particular network architecture.  

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

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Mon, 3 Mar 2003 16:49:48 +0000

Hi Folks,
*  Sorry, but I can't find the references:
    (i) RFC2913?
    (ii) section 7.3 example 3?
    Also, note that RFC2169 is Experimental.

*  Whoa! I suspect that this is the wrong list for ENUM basic operation, but...
    ENUM is used to publish data for a fully qualified E.164 number, not a
    number range. Thus it is NOT probable that "CC, NDC or parts of SN"
    would be used in ENUM; It's all defined in rfc2916 (and rfc2916bis-03.txt).

*  See also ETSI TS 102 172. This covers the European systems (see example
    in there for a syntactically correct "range" suggestion as I think you're
    trying to write here).

*  In general, RFC2806 (and I-Ds 2806bis) cover this topic, with RFC2916
    (and RFC3402-3405 , along with I-Ds 2916bis).
    Thus please explain what this proposal is intended to do. It seems to
    be intended as an alternative, so is DT now changing its position on ENUM?

best regards,
   Lawrence

----

At 3:52 pm +0100 3/3/03, Alexeitsev, D wrote:
>Hello All
>
>To kick-off the discussion on tel: URI resolution I would like to 
>share some initial ideas on this subject:
>
>The additional consideration may be given to the fact that probably 
>not all complete e.164 numbers will be put in to the DNS,  but just 
>CC, NDC or parts of SN thus changing the NAPTR in the example to 
>something like:
>
>IN NAPTR 100 10 "u" "sip+E2U" "change to 
>sip:[email-masked];user=phone"
>2) Not so general one that is probably more interesting for special 
>propose clients (SIP only, HTTP only, SMTP only,...)
>This mechanism is based on the RFC 2169 where an update for SIP 
>would be strait-forward, but the general description could be used 
>in the draft-antti-rfc2806bis to keep tel: URI protocol independent, 
>i.e. resolvable using http, sip, smtp,...
>
>An option could be to say that if tel: URI resolves (among others) 
>to the URL of the protocol that is being user for it's resolution, 
>then instead reporting back the resolver may continue with the 
>session setup using resolved URL. And only in the case that the 
>session setup fails report the URLs of other protocols.
>
>Of course this mechanisms do not exclude each other but can be 
>combined in a particular network architecture. 
>
>Greetings,
>Denis Alexeitsev

-- 
-----------------------------------------------------------------------
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.
_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel