Subject: [IPTEL] New draft RFC 2806bis

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 22 Dec 2001 23:01:47 -0500

I will submit the draft below after the holidays, when the I-D editor
returns:

http://www.cs.columbia.edu/~hgs/sip/drafts/draft-schulzrinne-rfc2806bis-00.txt

Comments are much appreciated. Much of the text has been rewritten, but
the document is meant to be backwards-compatible except for the omission
of the private context name.

Henning
_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 29 Dec 2001 03:56:32 -0700

I don't think this has been discussed in the past. I agree with your
analysis - there is no technical reason why %20 (space) couldn't be
allowed as a visual separator and since visual separators are
exchangeable, there's no reason you'd have to put
tel:+1%20212%20555%1234 on a bus or business card. (%20 is not uncommon
in mailto and http URLs, as file names commonly allow spaces and mailto
permits headers.)

In terms of backwards-compatibility: Implementations MUST understand
%-escapes anywhere. Thus,

tel:+1%32%31%32-%35%35%35-%31%32%33%34 (for tel:+1212-555-1234)

is a perfectly valid URL, albeit a bit unusual. 

Unfortunately, I have only heard from one tel implementor so far. Since
having space-separators is common in everyday usage of telephone numbers
and E.123 even recommends it, I'm inclined to allow it barring
objections from implementors.

"Richard H. Gumpertz" wrote:
> 
> I apologize if I am reopening something that has already been beat to death...
> 
> Why is space prohibited as a visual-separator in telephone numbers?  Yes, it has to be escaped, which can be ugly, but the end-user may not see that escaping.  End users may be dealing with User Interfaces rather than raw URIs and so enhanced readability of the URI is NOT the issue; enhanced readability at the UI level is.  Why not allow space as a visual-separator so that such information can be preserved?
> 
> A sentence in 6.1.2 discouraging use of space (due to the ugliness of escaping) as a visual separator seems more appropriate than prohibition.
> 
> On the other hand, I understand that allowing escaped spaces as visual separators might break existing implementations, which could be more costly than any benefit to be gained at this point in time by allowing them.
>