Subject: Re: [Iptel] comments on rfc2806bis - semantics

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 02 Dec 2002 15:58:47 -0500

Thanks for the extensive comments. Comments on non-editorial items 
in-line. Split to simplify follow-up.

Jonathan Rosenberg wrote:

> My big comment is that the draft doesnt actually define any semantics
> associated with the tel URI. There is nothing which says that I should
> make a call, or that I should do an enum query, or that I should make a
> sip call, etc. Even if there are multiple possibilities, we need a
> section that describes the options, and what it basically means when you
> encounter a tel URI in various contexts.

I've tried to emphasize up front "URI scheme ``tel'' that describes 
resources identified by telephone numbers." Thus, I tend to think of it 
much more like a URN - it does not specify a protocol to get the 
resource ("dialing"), but rather there are several ways to resolve it to 
something real (a phone call, say). Thus, the semantics are similar to, 
say, an ISBN - identifies a book (or any object with such a number), but 
doesn't say anything more than that. Is this precise enough?

The current text reads:

This document defines the URI scheme ``tel'' that describes resources
identified by telephone numbers.  The telephone number can refer to
terminals in the telephone network or the Internet, mobile and landline
devices, voice, data and fax devices.  The URI can refer to originators
\begin{changebar}
or targets of a telephone call.  The ``tel'' URI is an identifier only;
it does not describe the steps necessary to reach a particular number
and does not imply dialing semantics.
\end{changebar}

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 02 Dec 2002 20:08:42 -0500

Here is some new text:

If the receiver of a ``tel'' URI uses the URI simply for identification,
the receiver does not need to know anything about the context
descriptor.  It simply treats it as one part of a globally unique
identifier, with the other being the local number.  If a recipient of
the URI intends to place a call to the local number, it {\MUST} verify
that it is within the same context as one of the descriptors.
Otherwise, it {\MUSTNOT} initiate the call and treat the URI like an
invalid destination.

Earlier, local numbers are given the SHOULDNOT tag; I added a bit of 
motivation why they are a bad idea.

>
> Related to this, the spec doesn't define any specific processing
> associated with the phone-context. No where is there something like "the
> client SHOULD compare the phone-context with its configured domain names
> and prefixes, and if there is no match, discard the URI and inform the
> user". That is needed. The draft should also talk more about the
> configuration burdens and other problems associated with local numbers.
> They would seem to require clients to know their phone contexts. Also,
> what happens exactly if a client encounters one it doesnt know? What is
> the right error reporting?

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 02 Dec 2002 20:21:16 -0500

>
> > This document specifies the URI (Uniform Resource Identifier) scheme
> >    "tel" for specifying the address of a terminal in the phone network.
>
>
> Are we only specifying terminals? It seems that with some of the recent
> work on things like trunk groups, we are really specifying a wider range
> of "telephony resources". These include terminals, but also appear to
> include individual circuits, for example.

Added 'circuits'. In general, it's probably hard to define exactly what 
a telephone number describes, since it may describe not just one 
terminal or circuit, but a whole logical grouping (see the 800# discussion).

Maybe we should just leave it at the definition in E.164:

Number: A string of decimal digits that uniquely indicates the public 
network termination point. The number contains the
information necessary to route the call to this termination point.

>
>
> >  The tel URI is service-independent and describes voice calls (phone
> >    calls, answering machines and voice messaging systems), facsimile
> >    (telefax) calls and data calls, for landline, ISDN and mobile
> >    subscribers.
>
>
> It doesn't really describe calls at all. A call has things like a start
> and stop time, two endpoints, states, and so on. The tel URI identifies
> resources that can be contact on the telephone network.

Simplified to

This document specifies the URI (Uniform Resource Identifier) scheme
``tel'' that describes resources identified by telephone numbers.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 02 Dec 2002 22:30:00 -0500

>  > The approach pursued here has the disadvantage that certain services,
>  >    such as extensions on a PBX (when direct inward dialing is not used)
>  >    or electronic banking, cannot be specified in a URI.
> 
> I plead stupidity here. I don't see why you can't do PBX extensions with 
> a tel URI. Isnt this just a local number with an appropriate phone-context?

But that local number would not be dialable outside the context (It is 
not sufficient to just prefix the context and create to create an E.164 
number). Extensions do seem like a legitimate need, so there are two 
options:

- treat them as the same thing as ISDN sub-addresses, i.e., as a common 
parameter;

- add another parameter, say ;ext. This seems cleaner given that the 
allowable parameter values are different.

This fits into the identifier model. Think of the extension as roughly 
equivalent to the #anchor notation in http URIs.

>> URI comparisons are case-insensitive. However, all parameter names     |
>>    and values SHOULD use lower-case characters since tel URIs may 
>> be      |
>>    used within contexts where comparisons are case-sensitive.      
> 
> 
> Does that mean that:
> 
> tel:+1-987-654-3210
> and
> tel:+19876543210
> 
> are not equivalent?
> 
> If so, we should explicitly state that.

I elaborated on the comparison rules. I suppose it would be helpful if 
tel URIs were stripped of visual separators when they become user-parts 
in SIP URIs, to avoid spurious differences.

>> Each parameter name ("pname"), the ISDN subaddress and the context
>>    MUST NOT appear more than once.
> 
> 
> Hmm. You seemed to use this BNF trick above to specify one instance of 
> context, but not ISDN sub-address. Is there a reason its not consistent?

Unfortunately, I don't see how I can specify 'at most one isub, but can 
appear anywhere' while specifying a single context. You'd have to 
enumerate all combinations, as in

*par [isdn-subaddress] *par context *par
*par context *par [isdn-subaddress]

Any other ideas?

> 
>> is compared character-by-character, such as SIP URIs [5], the ISDN     |
>>    subaddress SHOULD appear first, if present, followed by the 
>> context,   |
>>    if present, followed by any other parameters in alphabetical order.
> 
> 
> Since paramchar can contain non-alphabetic characters, what is the 
> meaning of alphabetical order?

I18N and canonicalization, here we come... I guess this would mean 
lexicographic ordering according to the character set, presumably UTF-8. 
(However, is there any reason that parameter names could not just be 
unreserved? They are protocol constants, not somebody's personal name.)

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 03 Dec 2002 11:10:07 -0500

> >  All phone numbers MUST use the global form unless they cannot be
> >    represented as such.
>
>
> isnt this the same as saying "SHOULD use the global form"?

Almost; it explicitly states the (only) condition under which local form 
is allowed. SHOULD would seem to imply a more relaxed version.

>
>
> > Implementations MUST NOT assume that telephone numbers have a
> >    maximum, minimum or fixed length, or that they always begin with a
> >    certain number.
>
>
> For global numbers, I certainly can assume a maximum length of 15, as
> that is the constraint in the BNF. I think you should say "local
> numbers" instead of telephone numbers.

I've removed the constraint from the BNF. As was pointed out, it 
couldn't deal with the visual separators. Given visual separators, the 
length becomes unbounded. Something like

tel:+1-----------201.........(((((555)))))))1234

is odd, but legal according to the current BNF. (I've now rewritten the 
BNF so that each digit can be followed by at most one visual separator. 
Is there any reason to have more than that? This would limit the length 
to 30.)

>
>
> > Phone numbers MAY contain visual separators. Visual separators
> >    () merely aid readability and MUST be ignored by
> >    the client.
>
>
> What does "ignored" mean? There needs to be some defined semantic
> operations in which to ignore them. I ask the question above if
> comparison qualifies...

Now, comparison explicitly discards the separators.

>
>
> >  Even though ITU-T E.123 [8] recommends the use of space characters as
> >    visual separators in printed telephone numbers, tel URIs MUST NOT use
> >    spaces.
>
>
> The BNF clearly disallows spaces as part of the phone number itself, so
> having a MUST NOT here seems redundant. Does this mean I can't have
> escaped spaces as part of a parameter value? That is allowed by the BNF.

I suppose we can allow %20 spaces as visual separators. Is there value 
in that?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Dec 2002 17:42:25 -0500

> Is there any reason to have more than that? This would limit the length 

I've been pondering the role of visual separators in the URI, and did a 
bit of thinking and research on the topic. Here are my thoughts.

On one hand, since URI are ultimately for computer consumtpion, the 
separators play no role. They also complicate the comparison process 
since they should probably be removed before comparison. Simplicity 
would argue for their elimination entirely.

However, one can argue that they play a reasonable role in supporting 
the general transcribability requirement of a URI. From RFC 2396:

> A URI often needs to be remembered by people, and it is easier
>          for people to remember a URI when it consists of meaningful
>          components.

This would argue in favor of the separators, since people very 
frequently use them to help correct write the number. As an example, its 
much easier to get the correct number of ones when writing:

tel:+1(111)111-1111

as opposed to tel:+11111111111.

Interestingly, there is precedent for the usage of such separators in a 
URN. The ISBN URN (rfc3187), uses dashes in the same way we use them. 
The specifications for that URN scheme do require that the dashes are 
removed before comparing for equivalence.

So, in the interests of transcribability and in keeping with the trend 
in the ISBN URN, I would argue that we retain the separators and remove 
them for comparison purposes.

So, the issue remains of whether or not to allow multiple separators. I 
think what you have done is reasonable - allowing a single separator. I 
can think of no reason why we would need more.

> I suppose we can allow %20 spaces as visual separators. Is there value 

Probably not. This isn't like an HTTP URI, where we are trying to 
describe files whose names are frequently unconstrained in their natural 
form.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Dec 2002 17:59:21 -0500

Henning Schulzrinne wrote:
> something real (a phone call, say). 

Agreed its closer to a URN. Indeed, one might question why it wasn't 
made a URN in the first place (urn:tel:111), but I suppose that is too 
radical a change for this point in time.

I suppose that the tel URI really munges two things together. One is 
truly a URN - merely a unique name. There are many ways that can be used 
to access the resource identified by the name. You could send a SIP 
request to it, using the SIP protocol, or you could send an H323 request 
to it, using H.323, or you can call it using a circuit switched 
telephone, which can be considered a "protocol" in its own right, akin 
to SIP and H.323.

Part of the confusion is that we are using the tel URI to represent both 
the name and one specific protocol for accessing the resource  - the 
circuit switched telephone network.

Had we separated these two to begin with, this whole enum URI thing 
would be a non-issue. The URN specifies the abstract resource name. 
Using DNS (i.e., ENUM), you look it up, and find the set of URI that can 
be used to reach that resource. This might include a SIP URI, H.323 URI, 
or a "telephony" URI, which indicates that the only way to reach this 
resource is through the PSTN. That URI would clearly not be looked up 
again in DNS.

Indeed, one path forward is to narrow the scope of the tel URI as 
defined now to not be a generic name, but rather, to indicate that this 
specific telephone number should be contacted on the PSTN. We can then 
additionally specify a URN, and it is that URN which would be looked up 
in ENUM.

> devices, voice, data and fax devices. 

One wrinkle. If we plan on adding trunk groups to the tel URI, we can no 
longer claim that we are addressing TERMINALs, since a circuit on a 
trunk group is not a terminal! Based on the above discussion, circuits 
in a trunk group may very well be another URN. That would help us handle 
some of the thorny naming issues surrounding trunk groups; we could use 
some of the URN infrastructure for this.

Hmm....

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 03 Dec 2002 18:47:18 -0500

> resource is through the PSTN. That URI would clearly not be looked up 

I don't think that works very well, simply because this is subject to 
change at any moment. I don't think it's a good idea to want to change 
an identifier just because I've placed a number into ENUM (or removed it 
from there). In the end, this has to be a recursive lookup - attempt if 
the number is in ENUM. If not, it must be reachable (if at all) only 
using traditional circuit switching. If it is in ENUM, recurse if 
necessary (i.e., if there's another URI).

> longer claim that we are addressing TERMINALs, since a circuit on a 

I think I've tried to remove all references to terminals, except by 
example. E.164 doesn't address terminals - it just says "public network 
termination point".

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 3 Dec 2002 20:01:50 -0500

----- Original Message -----
From: "Henning Schulzrinne" <[email-masked]>
<snip>
> > that is the constraint in the BNF.

I believe the maximum length for a global number should be at least 17. I
may be mistaken, but I recall from a previous life that E.164 allows for up
to 9-digit local numbers with up to 5-digit city/area code and 3-digit
country code.

---

From: Mahesh <[email-masked]>
Date: Wed, 04 Dec 2002 20:45:51 +0800

Hello Mr Henning,

Yaa you are right. E164 number does support the specifications you have
said. (9-digit local numbers with up to 5-digit city/area code and 3-digit
country code.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Bob
Penfield
Sent: Wednesday, December 04, 2002 9:02 AM
To: Henning Schulzrinne; Jonathan Rosenberg
Cc: [email-masked]
Subject: Re: [Iptel] comments on rfc2806bis (maximum length)

---

From: Michael Hammer <[email-masked]>
Date: Wed, 04 Dec 2002 09:29:02 -0500

I seem to remember 15 being the magic maximum number from E.164 I think.

Mike

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 6 Dec 2002 14:43:16 -0500

> maximum number from E.164 I think.

Yes.  Excluding the international prefix,
the maximum number is 15 digits.

However I think that rfc2806 currently
allows an infinite number of visual 
separators among those 15 digits. :)

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 06 Dec 2002 14:44:57 -0500

Version -07, in the I-D editor's hands, dispenses with infinity, based 
on the discussion here. In general, it might be useful if folks took a 
moment to read the new draft before commenting. A number of editorial 
changes were made that reflect the discussion. I'd hate to go over the 
same old territory again and again. For those who can't wait:

http://www.cs.columbia.edu/~hgs/sip/drafts/draft-antti-rfc2806bis-07.txt
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-antti-rfc2806bis-07.pdf

Henning