Subject: [Iptel] comments on rfc2806bis - separators

From: [email-masked]
Date: Tue, 3 Dec 2002 12:20:47 EST

In a message dated 12/3/2002 11:13:48 AM Eastern Standard Time, 
[email-masked] writes:

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

[MAP] This goes back to the question of what the tel:uri is used for. The 
inclusion of visual separators seems to assume that it is intended as 
something which the human user will enter or see, which may have been the 
original idea. With the addition of other things, I think we have gone beyond 
this and should assume that it is not primarly for (easy) human 
understanding. That would allow us to remove any visual separators from the 
tel:uri.

It would be recognized that a user interface could allow a user to enter 
visual separators including spaces (e.g., on a keyboard) and display them, 
but just not include them in the tel:uri it sends. Likewise, a user could 
type in letters and have them converted to numbers to go in the tel:uri. When 
receiving a tel:uri (without visual separators) the user interface could add 
them in for display if it understands the local dial plan. (Off hand, I can't 
think of a use of the tel:uri in which it would need to display what it 
receives, but I suppose there could be some.)

Elimination of the visual separators would certainly simplify this whole 
thing.

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

---

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

I'm all for simplification. The only real reason is that the receiver 
may not really know how to render, say, a tel: URI contained in a SIP 
request. If a US-English UA gets a European number, it likely has no 
clue what part is the area code and what part is the subscriber number. 
(Indeed, in that case, even a smart UI would have real difficulty 
discerning the two parts, given that area codes are variable-length.) As 
long as people do

From: +49 (2232) 12345 <tel:+49223212345>

this may not be a big deal.

The specification complexity is pretty modest - one additional line of BNF.

The main drawback of visual separators is in URI comparison - a 
byte-by-byte comparison may yield inequality, while a URI-aware 
comparison (and a normal human user) would detect equality after 
stripping the visual separators.