Subject: [Iptel] Comments on draft rfc-2600bis

From: [email-masked]
Date: Wed, 25 Jun 2003 13:53:42 EDT

Several additional comments on new version (although the material commented 
on was in previous versions):

Definition of Address-of-record and Dial String

Section 2 defines two types of telephone numbers: "address-of-record" (or 
identifier) and "dial string". Unfortunately, the definitions leave some 
uncertainty as to where addresses which represent destinations in a private network 
belong. Since such a number as passed within such a private network may not be 
exactly what was dialed, it is not a "dial string". However, 
"Address-of-record" is defined in terms of "a public network termination point". Neither 
definition correctly covers the private network number.

The problem seems to be the definition of "Address-of-record" which directly 
relates it to a "public network". The definition should include the notion of 
"non-public" networks as follows:

---------------------
Address-of-record or identifier: The telephone number is understood here as 
the canonical address-of-record or identifier for a termination point within a 
specific network. For the public network, these numbers generally follow the 
rules in E.164 [4]. Subscribers publish such identifiers or phone numbers as a 
universal means of being reached from within that network, independent of the 
location of the caller. (Naturally, not all numbers are reachable from 
everywhere in a network, for a variety of technical and local policy reasons.) It 
should be noted that a single termination point in one network may be reachable 
from different networks and would then have multiple such identifiers, one 
valid from each network.
----------------------

Section 2

The 4th paragraph has some wording errors. It is not clear what it is 
intended to say. It refers to the user or the terminal converting a telephone number 
into a dial string. In fact, the user needs to know whether or not to dial the 
area code, etc (i.e., converting the desired telephone number into a dial 
string), but the terminal may need to do the opposite. It needs to convert what 
the user dialed (dial string) into a telephone number (e.g., full E.164 number) 
to put into the tel:uri. The terminal would never convert from a real 
telephone number to what is called a "dial string", at least not when originating a 
call.
The following rewrite of this paragraph is suggested:

---------------------
To reach a telephone number from a particular terminal, the user of the 
terminal has to know how to convert that telephone number into a dial string 
appropriate for that terminal. The telephone number itself does not convey what 
needs to be done for a particular terminal. Instructions may include dialing "9" 
before placing a call or prepending a "00" to reach a number in a foreign 
country. The user may also need to strip area and country codes.

The terminal has to know how to convert what the user dials or enters into a 
full telephone number (e.g., E.164) in order to form a tel:uri. This requires 
knowledge of the local dialing plan, county code, area code, etc.
----------------------

10 Security Considerations

The last bullet item, about "a call may use ... different contexts", should 
be deleted.

Mike Pierce
Artel

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Wed, 25 Jun 2003 22:57:57 +0100

At 1:53 pm -0400 25/6/03, [email-masked] wrote:
>Several additional comments on new version (although the material 
>commented on was in previous versions):
><snip>
>Section 2
>
>The 4th paragraph has some wording errors. It is not clear what it 
>is intended to say. It refers to the user or the terminal converting 
>a telephone number into a dial string. In fact, the user needs to 
>know whether or not to dial the area code, etc (i.e., converting the 
>desired telephone number into a dial string), but the terminal may 
>need to do the opposite. It needs to convert what the user dialed 
>(dial string) into a telephone number (e.g., full E.164 number) to 
>put into the tel:uri. The terminal would never convert from a real 
>telephone number to what is called a "dial string", at least not 
>when originating a call.
>To reach a telephone number from a particular terminal, the user of 
>the terminal has to know how to convert that telephone number into a 
>dial string appropriate for that terminal. The telephone number 
>itself does not convey what needs to be done for a particular 
>terminal. Instructions may include dialing "9" before placing a call 
>or prepending a "00" to reach a number in a foreign country. The 
>user may also need to strip area and country codes.
>
>The terminal has to know how to convert what the user dials or 
>enters into a full telephone number (e.g., E.164) in order to form a 
>tel:uri. This requires knowledge of the local dialing plan, county 
>code, area code, etc.
>----------------------
<snip>

to which I reply:

Hi Mike, folks,

I guess it depends on what you consider a terminal. Does this include 
an LCR/CP box, and/or
a program on a PC to control the phone, and ... ?
However, I am now more confused than ever with the proposed 
replacement. Assuming that
we're talking about para 5 in section 2, starting "To Reach a 
telephone number from..."

*   A tel: URI might (or might not -- see annex A) be generated by a 
SIP UAC. My ISDN phone doesn't.
     As SIP is *not* the only use for this URI scheme, the last para 
in the proposed replacement
     is not appropriate, IMHO.

(Notwithstanding the fact that I use an integrated dialer program 
that instructs the ISDN phone,
and so neither this user nor his phone knows about converting 
telephone numbers into dial strings :),
the first paragraph of the proposed replacement seems OK to me.

all the best,
   Lawrence
-- 
-----------------------------------------------------------------------
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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Jun 2003 18:15:24 -0400

Thanks for your comments.

[email-masked] wrote:

[elided]
> for a variety of technical and local policy reasons.) It should be noted 
> that a single termination point in one network may be reachable from 
> different networks and would then have multiple such identifiers, one 
> valid from each network.
> ----------------------

I've adopted your definition, more or less.

> The terminal has to know how to convert what the user dials or enters 
> into a full telephone number (e.g., E.164) in order to form a tel:uri. 
> This requires knowledge of the local dialing plan, county code, area 
> code, etc.
> ----------------------

Adopted, modulo minor tweaking.

> The last bullet item, about "a call may use ... different contexts", 
> should be deleted.

Gone.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Jun 2003 18:26:34 -0400

> I guess it depends on what you consider a terminal. Does this include an 
> LCR/CP box, and/or

Does 2806bis really have to get into these philosophical distinctions? 
Are they material to understanding the text? Maybe I should just use 
"telephone", and treat this as an example, rather than trying to make 
find distinctions between humans, software that acts like humans, and 
random other special boxes.

> However, I am now more confused than ever with the proposed replacement. 
> Assuming that
> we're talking about para 5 in section 2, starting "To Reach a telephone 
> number from..."

I reworded this as an example, using 'phone on a PBX' instead of 
'device'. Since the conversion from dial strings to tel URIs is covered 
in depth later in the document, I'd rather not repeat this up front, as 
a full treatment would simply be a rehash. (You'd have to mention local 
numbers, etc.)

> 
> *   A tel: URI might (or might not -- see annex A) be generated by a SIP 
> UAC. My ISDN phone doesn't.
>     As SIP is *not* the only use for this URI scheme, the last para in 
> the proposed replacement
> (Notwithstanding the fact that I use an integrated dialer program that 
> instructs the ISDN phone,
> and so neither this user nor his phone knows about converting telephone 
> numbers into dial strings :),