smb://

[Christopher R. Hertel]

Sorry, I disagree completely.  It does no damage to the syntax or the 
namespace to be able to follow the logical progression:

smb://
  Finds a Master Browser and queries for a list of workgroups.

smb://workgroup/
  Queries the Master Browser for the workgroup for a list of servers.

smb://server/
  Queries the server for a list of shares.

smb://server/share/
  Provides access to the share.

This is simple practicality.  We have only seen one situation in which
there would be a conflic, and this is a situation which RFC 1001, Sec. 10
identifies as a misconfiguration:

  NOTE: It is recommended that the administration of a NetBIOS
        scope avoid using both M and B nodes within the same scope.
        A NetBIOS scope should contain only B nodes or only P and M
        nodes.

Further, we have identified more than one work-around that are perfectly 
useful.

Though the browser service is not carried over SMB, it is part of the
whole smb-based filesharing system.  The name service is also not smb, but
we will still need to use it to find the services.  If you can think of
the LMB as a directory service then you can also consider a server's
listing of shares to be a directory service.  They are very similar in 
their purpose.

> After the latest talks I also think workgroup is nearly useless.
> Just to conform to other URI, with ftp or http you never specify the
> domain name to have the list of the servers of the domain so the same may
> be for smb:// syntax.

But you do specify a DNS name which has to be looked up using a separate 
service.

> if you need a service the only things you need are:
> 1. a way to authenticate yourself ([[domain;]username[:password]@....)
> 2. a server name smb://server/...
> 3. a share/service name smb://server/folder/file...
> 
> nothing more.

It's #2 that needs a bit of help.  You need "a server name".  Where do you
get that?  Traditionally, you either know it off the top of your head or
you get it via the browser service. 

> browsing the network is after all unrelated

Unrelated at the protocol level (though both use the NBT suite underneath), 
but not unrelated at the service access level.

> and should be demanded to
> something different (like an nslookup for smb and zone transfers or domain
> listing requests to a dns (wins in this case?) )

No, I don't see the analogy here at all.

You don't use dns:// to look up a dns name so that you can plug the IP
into an http:// string.  That part is taken care of behind the scenes. 
Likewise with NetBIOS name resolution in an smb:// string.  In this case,
though, if the name resolves to browse list service instead of a file
service then list the servers returned by the browse list.  If it resolves
to a file service, then list the shares offered by the file server.  In 
either case, you are ennumerating a list offered by the service.

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