smb://

[Christopher R. Hertel]

> On Wed, 27 Dec 2000, Allen, Michael B (RSCH) wrote:
> >
> >       The "workgroup#" is a special exception to the whole concept of URLs
> > and is meant to deal specifically which Richards original issue.  Steve
> > has suggested several times that it has no business in the URL (and I tend
> > to agree).  It is _only for browsing_ under rare cases where the name of
> > the workgroup of intrest is not the same as the authentication domain.

Hang on.

This is not a problem.  A server cannot have the same name as a
workgroup/ntdomain since both need to register using the #00 suffix.  Take
the following: 

  smb://foobar/

A quick check (yes, I know we'd rather avoid too much network traffic but
name resolution is legit) will let us know if the name resolves to a
server.  If so, list the services.  If not, see if it is a
workgroup/ntdomain and then ennumerate the browse list.  No need for the #
character. 

> Yes, I think Richard hit on this earlier.  If you are trying to browse
> the workgroup, you need a way to specify it, but once you know what
> server you wish to access, the workgroup becomes irrelevant.

I don't think that you need a way to specify that the name is a 
workgroup/ntdomain vs. a server, as described above.

> Likewise,
> you don't need to have a way of specifying domain/user:pass when simply
> browsing the workgroup, so there it no conflict there.
> 
> The only possibilities I can see needing are:
> (known server)    smb://[[domain/]user[:password]@]server/[share/[path/]]
> (browse workgrp)  smb://workgroup#
> (browse default)  smb://

I do have a problem with the '/' in [domain/].

Because of the use of the slash, there is no way to know if the first
field is a domain or server field. 

I prefer to work with the idea that the first field is *always* a server
field, representing a service that we wish to access.  This is consistent
with the idea, above, that the service might be a browse list.  If the '/'
is used as a delimiter, and if the [domain/] is optional, then you have no
way of knowing which field represents the server.  You cannot use the ':'
and '@' characters as guides. The colon may not be present in all cases
and I imagine that the '@' may be a valid character in a share name or a
file or path name. 

If the first '/' delimited field is always the server name then we can
apply special syntax to it.  (Note, though, that we may still need some
form of escape character so that @'s and :'s can be part of a server
name--ick.)

There's one more note:  I think that the smb:// prefix should only be 
used to access filesharing services.  That is print and file shares and 
the browse list.  If we start trying to access other services, such as 
SQL or other stuff, we will be dealing with different protocols.  SMB is 
for filesharing, and the browse list is a reasonable extension.

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