Subject: Re: [Iptel] comments on rfc2806bis

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

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

No. The problem was that local phone numbers must have exactly one 
context parameter, which can be either preceded or be followed by zero 
or more global-par's. There might well be a better way to express this. 
Thus,

tel:1234;globalA;context=x;globalB

is allowed, as is
tel:1234;context=x;globalA

etc.

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

Should be 'parameter', not 'param'. Fixed.

> Mike Pierce
> Artel

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

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 3 Dec 2002 14:42:19 +0100

Hi all,
 
from my understanding the tel: URI scheme will be used mainly in at least 3 environments:
-on a web-page, as you mention,
-in SIP messages, ev. with the yu-extensions
-in ENUM NAPTRs, also with the yu extensions and maybe others.
 
all three environments may have different requirements.
in the latter environments, you may need hex-digits, e.g. for routing numbers
regards
Richad

	-----Ursprüngliche Nachricht----- 
	Von: Alexeitsev, D [mailto:[email-masked]] 
	Gesendet: Di 03.12.2002 12:54 
	An: [email-masked] 
	Cc: 
	Betreff: [Iptel] comments on rfc2806bis

	Hello All,
	
	Just a few questions, comments for my clarification:
	
	The main scope of the tel URI is the publication on the web pages, how this URI is used by the SIP UAs (mail agents, ...) i.e. if it is converted to the SIP URI by adding the default outgoing proxy address as hostportion is out of scope for this document.
	
	Coming from the use scope the entities that tel URI will identify will be only those that are available to the regular telephone subscribers i.e. geographical nongeographical and service numbers, but not the network internal numbers that are not allowed for subscribers to dial anyway (hex digits, ...)
	
	If it is true then there is no need to allow the use of hex digits, if the scope is more then just the numbers that are allowed for subscribers input, then the 4 bit space for address digits as defined in Q.763 must be preserved.
	
	Greetings,
	Denis Alexeitsev

---

From: "Alexeitsev, D" <[email-masked]>
Date: Tue, 3 Dec 2002 15:00:51 +0100

Thanks for the answer,

comments inline:

>Given the identifier role, I'm a bit reluctant to rule out the full 
>4-bit space (hex digits). Since this is just an identifier, I see no 
>harm in having
>
>tel:+1-201-ABC-1234
>
>(where A, B, C are the hex digits, not digits on your dialpad). The only 
>drawback I can see in practice is that this will indeed be confused with 
>the 1-800-AAA-4357 style.

[DA] Yes I would definitely support having the possibility to transfer hex digits even if they are not considered to be a part of the E.164 numbering space. The only issue I see here is that this kind of digits are not allowed for the end subscribers to dial, thus the tel:+1-201-ABC-1234 will never result in a successful call when placed on the web page and will success if used inside of the network. But this brings us back to the issue of unique against dialable.

B.t.w I agree that it is not a problem if <a href="tel://+1+800-111-4357">1-800-AAA-4357</a> is used, as the actual tel: URI will be valid.

Greetings,
Denis Alexeitsev

---

From: "Alexeitsev, D" <[email-masked]>
Date: Tue, 3 Dec 2002 15:21:01 +0100

Thanks for answer,

comments inline
 
>all three environments may have different requirements.

[DA] I think is it a very valid consideration that people are putting different requirements on tel: URI from the perspective of future environment. 

>in the latter environments, you may need hex-digits, e.g. for routing numbers

[DA]Yes that is what I was trying to reference by "if the scope is more then just the numbers that are allowed for subscribers input, then the 4 bit space for address digits as defined in Q.763 must be preserved"

If the later environments are considered to be in the scope (I hope so) then I believe that the uniqueness of the hex digits in routing numbers may require additional considerations as the different service providers working inside one national numbering plan may independently reuse the same routing number. But if in the case of routing numbers tel URI with hex digits stays inside service providers domain then the uniqueness requirement is fulfilled.

Greetings,
Denis Alexeitsev

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 4 Dec 2002 12:16:59 -0800

Good.

But just to clarify that an E.164 number can NOT have more than 15 digits:

- The total length of an E.164 number can NOT be more than 15 digits.
- The E.164 number can be either:
  - Geographic number, where the country code is 1 to 3 digits and the
    national number is 15-n (where n is 1 to 3). Individual countries
    can partion the national number into a subscriber number and a
    an area code subject to the 15-n total lenght maximum.
  - A global number with a 3 digit country code for global services, and
    a global subscriber number with up to 12 digits.
  - An international public telecommunication number with a country code
    of 3 digit, and id code of 1-4 digit, and a subscriber number of 12-x
    digits (x=1-4).

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Wednesday, December 04, 2002 7:39 AM
> To: Alexeitsev, D
> Cc: [email-masked]
> Subject: Re: [Iptel] comments on rfc2806bis
> 
> 
> The about-to-be-released (07) draft does not impose a length 
> restriction. Hopefully, that will settle this particular issue.
> 
> Alexeitsev, D wrote:
> > Hello All,
> > 
> > 
> >>Not much of an advantage, but in general it's nice to be able to say
> >>"that 1 MB URI you just sent me must be bogus". One less 
> avenue for a 
> >>denial-of-service attack. (This obviously does not advocate 
> fixed length 
> >>buffers without length checking...)
> > 
> > 
> > [DA] Thanks for the clarification. I think it is already 
> possible to 
> > say that, as one would not find any routing entry for this URI :-)
> >>From my experience with the problems that operators are facing with 
> >>the number length limitations I would not like fixing it exactly to 
> >>the size of currently defined E.164. It generally good 
> design to have 
> >>some future proved reserve in this buffer, but I'm not sure if it 
> >>possible to recommend any specific value.
> > 
> > Greeting,
> > Denis Alexeitsev
>

---

From: "Alexeitsev, D" <[email-masked]>
Date: Thu, 5 Dec 2002 16:28:15 +0100

Hello All

I think I still missing the point, but I agree to close this discussion if I'm the only one who does. If it is only for the called party pleasure problem then, we can recommend to use the display name or any other means that are available to please him. 

My concerns are about the possible impact on the subscribers behaviour if people would start dialling points, spaces and brackets on the terminals that do not support separators omission just because some of them can.

The preferences for visual separators are different around the world anyway, so   
tel:+49223226329 with more probability will be understood correctly on the other hemisphere as tel:+49-2232-2.63.29

Greetings,
Denis Alexeitsev

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Thursday, December 05, 2002 2:32 PM
To: Alexeitsev, D
Cc: [email-masked]
Subject: Re: [Iptel] comments on rfc2806bis

You missed the point of the discussion. The recipient UA (in the SIP 
case) does not have sufficient information to insert the visual 
separators. Thus, you're losing valuable (user presentation) 
information. As noted a few times, URIs *are* meant to be seen and 
transcribed by humans; see RFC 2396.

Nobody can force you to insert visual seps, but that doesn't mean we 
should take the opportunity away from people. I much prefer

Can we close this discussion now - this is not a real problem.
_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel

---

From: Michael Hammer <[email-masked]>
Date: Thu, 05 Dec 2002 11:49:54 -0500

Denis,

While I think that the processing of what goes into the message on 
origination could just as easily strip out the separators, the bottom line 
is that any processes along the signaling path can do that as well if 
separators are found in the URI before processing the number.

But, the key here is not key-presses from phones, but what happens when the 
URI is presented in a Web page and clicked-on to talk.  So it is for the 
sake of visual displays that this is allowed, not for typical phones.  The 
two forms of URI (with and without separators) should be iso-potent.

My only question is whether it would be allowable for a node along the path 
to normalize the number to a non-separator form to help optimize downstream 
processing.  Is that allowed?

Mike

At 04:28 PM 12/5/2002 +0100, Alexeitsev, D wrote:
>Hello All
>
>I think I still missing the point, but I agree to close this discussion if 
>I'm the only one who does. If it is only for the called party pleasure 
>problem then, we can recommend to use the display name or any other means 
>that are available to please him.
>
>My concerns are about the possible impact on the subscribers behaviour if 
>people would start dialling points, spaces and brackets on the terminals 
>that do not support separators omission just because some of them can.
>