Subject: Re: [IPTEL] New draft RFC 2806bis

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 03 Jan 2002 20:06:11 -0500

Brett Tate wrote:

> This is from rfc2396 section 2.4.3:
> "The space character is excluded because
> significant spaces may disappear and
> insignificant spaces may be introduced
> when URI are transcribed or typeset or
> subjected to the treatment of
> word-processing programs.  Whitespace is
> also used to delimit URI in many contexts."

And immediately below in 2.4.3 it says:

"Data corresponding to excluded characters must be escaped in order to
   be properly represented within a URI."

This is a common misunderstanding about URLs: Just about any character
can appear in a URL, as long as it is escaped. It just can't be used
as-is. Space, as is, also couldn't be used as a delimiter between parts
of the URL. 

http://www.example.com/A%20filename%20with%20spaces

is a perfectly valid URL.

> 
> The last sentence might be a reason to
> exclude spaces.  Backwards compatibility
> with rfc2806 might be another.
> 

The latter reason is, of course, a concern. If there was a large
installed base of non-changeable devices, I would be inclined to agree
that this would not be worth the hassle. I have no opinion on this.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 3 Jan 2002 19:59:51 -0500

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