[jcifs] Re: SMB URL

[Conrad Minshall]

At 1:43 PM -0700 9/13/01, Christopher R. Hertel wrote:

>> For Person 1 the style used might be "the other one",
>> because 1) they have a different client and/or 2) the server has changed
>> and now prefers or requires the other style.
>
>No, that would invalidate the meaning of the URL string.
>
>In order for the URL string to be valid, the string must mean the same
>thing to both Person1 and Person2.  This is highly problematic when
>NetBIOS is considered, since two separate networks may include machines
>with the same name.  Fortunately, there is a parallel that "helps" us out
>of this bind.  That is, a non-fully-qualified DNS name has the same
>problem.  In, for example, and HTTP URL you get around the problem by
>fully qualifying the name.  We do the same in the SMB URL in a variety of
>ways:
>
>  1) You can use the FQDN instead of the NetBIOS name.
>  2) You can use an IP address instead of the NetBIOS name, and specify
>     the called name as part of the query string.
>  3) You can specify an NBNS (WINS) server in the query string.
>
>Note that incorrect or incomplete implementation of URL support on the
>client is *not* a requirement, since that has no impact on the validity
>of the URL string itself.

I must clarify, as I'm not positive what you heard is what I meant to say.
Perhaps we are speaking a different protocol ;)  My comment is not about
URL validity, just about usefulness.  Lets imagine a server X which
supports... everything.  And say client software A supports only the
"smb://" style and client software B only does "cifs://".  Now off on
server Y is a document with an embedded URL linking to a SMB/CIFS file back
on server X.  What form should said URL take?  Either form will shut out
some users, preventing them from accessing a server resource even though
client & server could have communicated fine.

That is what I meant with case 1) "they have a different client".  Feel
free to ignore case 2) "the server has changed" until we have case 1)
behind us.


--
Conrad Minshall ... conrad at apple.com ... 408 974-2749
Alternative email addresses: rad at acm.org and conrad at mac.com.