smb://

[Steve Langasek]

On Fri, 29 Dec 2000, Michael Sweet wrote:

> Steve Langasek wrote:
> > ...
> > My personal feeling is that a backslash may still be preferable
> > here.  I can't imagine a situation where a modern client would
> > maltreat this character, with the exception of posix shell... and
> > I already have to escape URLs at the commandline because of the use
> > of '&'.  I'd be interested to know the reasons for marking the
> > backslash as an 'unwise' character.  If this character really
> > no longer deserves the label 'unwise', it's always possible to
> > change the RFC. If it /is/ unwise to use \ in urls, I still think,
> > based on my reading of the RFC, that we'll want to avoid the
> > semicolon.

> It isn't just the POSIX shell, it is every programming language in
> existance, too!

> The backslash character is almost universally used as an escape
> character; that plus the fact that the RFC for URIs specifically
> excludes it in URIs makes it an unsuitable choice.

And the @ character must be escaped in perl, and the & must be escaped in
shell scripts, and $ is almost as universally troublesome in scripting
languages as the \ is, yet these other three characters are all considered
acceptable in URIs.  I fail to see why \ should be treated differently on this
basis alone.  Even though it is almost universally used as an escape
character, it is NOT used as an escape character in URL encoding.  So what if
it has special meaning to scripting languages?  Other URL characters have
special meaning to scripting languages, and we still expect them to be
transcribed literally.

Yes, the RFC specifically excludes its use.  But RFCs are intended to be
guides, not laws, and occasionally the RFCs need to be revised.  I think this
may be an RFC that could use a footnote.

Steve Langasek
postmodern programmer