Subject: [Iptel] comments on rfc2806bis

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Nov 2002 01:18:13 -0500

I haven't really been involved in the discussions on 2806bis up until 
now, so I apologize if any of these are repeating past comments.

I have one big comment and a bunch of smaller ones.

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.

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?

Besides that major comment, I have the following additional comments:

* The short title that appears across the top of each page is 
"rfc2806bis". This should change to "The tel URI", since it won't be 
correct once we have a new rfc number.

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

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

>  This document defines the URI scheme "tel" that contains telephone
>    numbers.

reword: "This document defines the "tel" URI scheme, which contains 
telephone numbers".

> signaling network. Generally, this means E.164 numbers, or
>              numbers that can be trivially converted into them.

this is the first reference to e.164; please provide the reference here.

> Since URI use the forward slash to describe path hierarchy, the URI
>    scheme described here uses the semicolon, in keeping with SIP URI
>    conventions [4].

Expand SIP.

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

 > The URI is used as a request URI in SIP [4] requests.

can be used.... This makes it sounds like the only application is SIP.

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

>    local-number          =  phone-number *global-par context *global-par

this syntax seemed a bit odd to me. I may have missed the discussion on 
why it was done. Why is global-par repeated twice? Perhaps the idea is 
to say that ordering is irrelevant, but you can have only one context 
parameter?

> reserved              =  ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+"  |
>                                  / "$" / ","      

this production is never used. What is it for?

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

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

>  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"?

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

> Phone numbers MAY contain visual separators. Visual separators
>    (<visual-separator>) 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...

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

> Since called and calling terminal numbers (TNs) are encoded in BCD in
>    ISUP, this allows for six additional values per digit, sometimes
>    represented as the hexadecimal characters A through F. However, in
>    accordance with E.164, they may not be included in global numbers.

If that is the case, shouldn't the BNF for global-number differ from 
local-number to reflect this?

> A global number prefix consists of the initial digits of a valid       |
>    global number. When a global number prefix is used as the context, it  |
>    MUST be chosen to be unique. 

unique across what?

> As noted
>    earlier, numbers that can be represented as valid global numbers MUST
>    NOT be represented as local numbers plus phone-context.

noted earlier where? I foudn this text:

> International numbers have the property of being unambiguous
>    everywhere in the world and are RECOMMENDED. 

which is SHOULD strength, not MUST.

> National freephone numbers SHOULD be represented with a local prefix.

what is a local prefix? The text above defines global prefix and domain 
name.

> The number SHOULD be visible to the end user if it is conceivable
>    that the user might not have a client which is able to use these
>    URIs.

what does visible mean?

>  "Tel" URI parameters (<param>) MUST be registered with IANA.

this is not sufficient to set up an IANA registry. You need to provide 
guidance to iana on what information has to appear in those 
registrations. I would expect this to include the parameter name, 
whether its mandatory or not, a paragraph on its usage, possible values, 
the BNF for it, the specification that defines it.

You also need to provide IANA with the initial entries in the registry, 
which include those parameters defined in the spec (phone-context).

> Mandatory parameters must be
>    described in an informational or standards-track RFC.

Do we really want mandatory parameters defined in informational RFCs?

References section needs to be split into normative and non-normative.

WHy is there still a reference [4] to rfc2543? should be 3261.

TOC needs to go up front.

-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

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

---

From: [email-masked]
Date: Tue, 19 Nov 2002 16:00:29 EST

> to say that ordering is irrelevant, but you can have only one context 

I'm not sure what the problem is here, but I agree that this seems a bit odd. 
There was discussion before about have a single tel:uri contain multiple 
numbers or multiple contexts, but I don't know if this is related. In the 
above, "global-par" is defined in the ABNF to be made up of "parameter" which 
is not defined. I thought the only thing needed with "local-number" was the 
"context" (once) as in -05.

Mike Pierce
Artel