[jcifs] Re: SMB URL

[Christopher R. Hertel]

> please could someone expliain the definition of 'unified'?
:
> and also non-overlapping.

We are all coming at this problem from separate directions, so it is no 
surprise that we are having terminology trouble.  I think these terms 
came from Conrad, but I'm not sure any more.

Okay, this pure taxonomy not a statement of intent.  Terminologywise:

  - By "unified" I mean that one URL format (either SMB: or CIFS: or both
    as aliases for one another) would support browsing and filesharing
    over either transport. 

  - By "non-overlapping" I mean the model in which SMB: speaks only 
    SMB/NBT and CIFS: speaks only CIFS/TCP.

  - By "SMB/NBT" I mean "old-style" (pre-W2K) NBT transport.

  - By "CIFS/TCP" I mean SMB over native TCP and all of the newer
    supporting protocols and services that go along with that
    (MS-Kerberos, Active Directory, MS-DNS, etc.)

Hope that helps.

The whole purpose of this discussion is to determine if it is reasonable
to create a "unified" specification as proposed by Thursby and Apple. 

History:  In earlier discussions, I had proposed the "non-overlapping" 
          approach.  The current draft includes that proposal.  My 
          reasoning, for historical reference, was as follows:

          1) I felt that the "non-overlapping" approach had already 
             presented us with a large problem.  The string "smb://name/"
             is already difficult to resolve (is it a DNS name or IP, a
             NetBIOS server name, or a NetBIOS workgroup?).

          2) The different transports seemed sufficient to distinguish 
             the two systems (SMB/NBT vs. CIFS/TCP).  In addition, the 
             two transports come with completely different support
             protocols.  Browsing, authentication, etc. are all different. 

          At the CIFS conference, I presented the SMB URL and opened a 
          number of discussions with different vendors.  At that time, the
          folks from Thursby and Apple proposed the "unified" model.  They
          were able to convince me that the problems of switching between
          SMB/NBT and CIFS/TCP were managable (though, once again, these
          take time to resolve on the wire).

Where we are:
        Where *I* am right now is this:  I need one or more documentable 
        mechanisms for reliably interpreting a string in the form

          smb://<name>/

        I also need to know that the user will not be sitting on his/her
        hands for an annoying amount of time while packets are sent all 
        over the place trying to figure out what kind of name '<name>'
        really is, and which kind of service it represents.

        I think this is critical to providing a specification for a 
        "unified" URL scheme.  Before we can provide such a scheme, we 
        need to *know* that it will work.

All that said, I *know* that the "non-overlapping" scheme will work.  The 
problem with the "non-overlapping" scheme is that it isn't percieved to 
be "user-friendly".  Okay, I can buy that.  So let's come up with a 
workable mechanism that would support a friendlier URL.


I outlined my best effort in another message.  Luke, you replied with:

> >   Note, by the way, that the decision to use port 139 or port 445 is made
> >   based on whether or not we detect NBT.  Now that I think of it,
> >   there is no reason to try both ports *if* we go to the trouble of
> >   discovering NBT by sending queries.
>
> yes there is.
>
> samba may be running on both ports, is resolved via a WINS
> server but not via DNS.  going to 445 will save a round-trip.
>
> a dual-mode NT4/NT5-domain server may not be accessible / 
> correctly configured to be reached via DNS but is accessible
> via Broadcast-mode NetBIOS, but again, it's still running
> both 139 and 445.

If these servers are running both SMB/NBT and CIFS/TCP then it doesn't 
matter which transport we use, or to which port we connect.

The point I was trying to make, however, is that one possible mechanism
for figuring out how to resolve "smb://name/" or "cifs://name/" is to 
determine whether the remote system is running NBT at all.  If it is, 
then use SMB/NBT semantics and defaults.  If not, then use CIFS/TCP 
semantics and defaults.

I'm not arguing that it is or isn't the best mechanism, just that it could
work. 

Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services

    Ideals are like stars; you will not succeed in touching them
    with your hands...you choose them as your guides, and following
    them you will reach your destiny.  --Carl Schultz