CIFS archives -- September 2001, week 2 (#14)

[Christopher R. Hertel]

> Chris,
> 
> The issue that we at Thursby have with the URL types is that our users
> need a single type allowing our implementation to locate computers,

That is the goal you have stated.  I do not believe that it is "needed",
but I can see that it may be desirable.

> shares, files and folders regardless of how the infrastructure is set
> up (ie: NBT or 445, and independent of browsing technology).

You have listed computers (servers), shares, files, and folders.  That
brings up the tough point:  Shares, files, and folders are all basic SMB
and, as was discussed at the conference, there is one exchange within
the protocol that "goes away" under port 445 semantics.  I still have
not had anyone explain to me how a client would go about searching for
the service list in this scenario.  Given the string

  cifs://name/

I need to figure out if 'name' is a NetBIOS name or a DNS name.  If it's
a NetBIOS name I need to figure out if it represents an SMB server or a
workgroup (or, in unusual cases, both).  I know how to do that.

If, however, the name is a DNS name then I need to figure out if it is:
  - an SMB over NBT server
  - an SMB over native TCP server
  - a W2K Domain Controller.

In that last case, I also need some idea how to read the browse list.

> For example, our customers need a way to access a particular folder
> on a particular server when they know the name of the computer and
> folder.  This is in fact how Windows 2000 works when the file:// url
> form is used.

The case of file access is not at issue here.  We concluded that it
could easily be done while at the conference.

> Is
> there any ambiguity when a user types in file://george/share_aaa on a
> Windows machine?  Don't we all know what the user means?

*Our* knowing what it means has little to do with whether the software
can figure out what it means.  Those are two separate issues.

> (I know there may be ambiguities, but these are not forced on the
> customer by the implementers

They exist within the protocol suite, which we all know to be 'messy'.
We are already doing a whole lot of work on the wire just trying to
figure out what kind of name we have and what kind of service we are
trying to reach.  If I were really, truly Anal Retentive I would say we
need four URL prefixes, one for each form of SMB access and one for
each browse list type.

> - rather they are a result of how the customer configures their
> products)

I don't see that at all.

> Second, if you are not prepared to spec 'cifs:' url form, then that is
> fine with us.  We rely on a 'cifs:' form anyway so we would have no
> problem conforming to your spec if it only covers 'smb:'.  In fact,
> DAVE 2.5.2 does not use the smb: url, and the newer (yet to be
> released) version will handle smb: per your draft spec.

The original goal was to have smb: support both browsing and filesharing
via the older NBT transport, and use cifs: for the newer transport.  If
you overload smb: so that it handles both, and if that final spec does
*not* support this, your implementatio will be non-compliant.

The whole point of this process is to produce a specification that is a
"best fit" for everyone.  I really have done my best to listen to and
encourage discussion.  Threats to go your own way defeat the purpose and
cost everyone.

> It would appear that a better basis for the cifs: spec would be to
> document the behavior of Windows 2000 when it encounters a file: url
> followed by two slashes, then expand that behavior to include
> additional features such as user credentials.

If it is technically possible *and* technically reasonable to include
support for both browse mechanisms (as it seems to be for file service
transports) then we, as a community, should be considering that as a
viable option.  If not, then it makes sense to separate the two
transports, as the current draft suggests.  As you point out, the
file:// (as implemented by Microsoft) is not as full-featured as even
the current draft SMB URL.

Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services
-------------- next part --------------
HTML attachment scrubbed and removed