[jcifs] Annoying SMB URL question.

[Conrad Minshall]

At 8:01 AM -0500 12/9/02, Glass, Eric wrote:

>>  > Just beating a dead horse

Me too.

>>  > c) Selecting ";" simply because it doesn't have to be
>>  escaped doesn't really
>>  > buy you anything; to be correct, your applications will
>>  still have to be
>>  > able to unescape whatever separator is chosen.  i.e.:
>>
>
>Actually, my previous statement above is incorrect.  Using ';' as the
>reserved (as defined in RFC 2396, section 2.2) delimiter for domain-user
>separation would NOT necessarily require that an application handle the
>instance in which the semicolon is escaped as '%3B'.  For the sake of
>completeness in the spec, it might be worthwhile to specify whether the
>presence of '%3B' is to be treated as an encoded separator (valid) or as an
>encoded literal ';' (which would be an illegal character in this case).
>This would only be significant in determining whether something like:
>
>smb://user%3Binfo:password@server
>
>should be parsed as the (valid) user "info" in domain "user", or the
>(invalid) username "user;info" with no domain qualifier.

2396 defines "unreserved characters" (and excludes semicolon from 
that list).  2396 also says "data must be escaped if it does not have 
a representation using an unreserved character".  2396 also defines 
"reserved characters" (and includes semicolon).

So interpreting a %3B as a delimiter rather than as data invalidates 
escaping, the only mechanism available to represent a semicolon as 
data.  In the password component for instance this would mean no way 
exists to embed a "@" as password data.