Re: URI Scheme that needs help.

Claus,

You've identified some of the biggest compromises that needed to be made to
get the SMB URI scheme to work.  SMB is an old protocol, and there are a lot
of conventions (and ingrained expectations) that need (to some extent) to be
accommodated.

[Aside: I submitted draft v12 but had to get it in by the deadline and
        didn't have time to include all of the recommendations I've
        received so far.  I'll keep working on them and add the new
        boilerplate that Frank pointed out.]

Claus Färber wrote:
> 
> Frank Ellermann schrieb:
>> The concept of a workgroup context wrt to relative URLs is of course
>> odd, but your description makes it clear.  Or I think it does.
> 
> The hierarchy structure is not compliant with RFC 3986.
> 
> For example, "smb://foo" + "../bar" must resolve to "smb://foo/../bar",
> not "smb://bar" ("//bar" would be allowed).

The relationship between workgroups and servers is not properly
hierarchical.  To include support for both (which is something all of the
implementations do) there has to be some overloading.  The goal of the draft
is to specify a standard way to make that overloading work.

One way around the problem you've identified is to consider workgroups and
servers to be at the same level in the hierarchy.  That's what we've done
syntactically.  The result of:

  smb://<workgroup>/

is a list of servers that are members of the workgroup.

There is, however, a logical hierarchy that exists.  That is:  servers can
be members of workgroups.  As a result, it has been suggested that the URI
scheme should take the form.

  smb://<workgroup>/<server>/

but that format was rejected because:

* The workgroup system is a convention.  Technically, servers do not need
  to be part of a workgroup.  Under so-called "naked" transport (non-NBT)
  the workgroup scheme goes away so including the workgroup in the path
  won't work in that case.

* Users are currently accustomed to the ability to access servers directly,
  without having to specify the workgroup.

In the current revision of the draft, I outline one suggested behavior for
user agents.  That behavior is to make the lateral (where possible) move
from server to workgroup when moving upward in the hierarchy.

It's messy, but here's the idea:

- Syntactically, adding ".." to smb://<server>/ should give smb:// (more on
  smb:// in a moment).

- Semantically, however, an NBT-based server will likely be a member of a
  workgroup.  In that case, a user agent *may* choose to make the lateral
  move and display the list of servers in the workgroup.  That is:

  smb://<server>/ + ".." ==> smb://<workgroup>/

  where <server> happens to be a member of <workgroup>.

Yeah that's ugly, but it is what happens when browsing the Network
Neighborhood.  When you are viewing the shares available from a server and
go "up", you get the workgroup member list (the servers in the workgroup).

Because the most common implementation behaves this way (even though it
doesn't support this URI scheme), it is likely that other implementations
will follow suit.

On the other hand, it's not clear how similar behavior would be implemented
in a non-NBT environment (the subject of another recent e'mail discussion)
so this is a point which needed to be raised and reconsidered.

> "smb://" also does not fit into the generic SMB syntax, "smb:" is not an
> alternative as it is a relative URL to the current document.

Yep, but this has been discussed a few times.  It's the only way to access
the list of workgroups (since there's no "name" at the top of the hierarchy).

...and yes, support for workgroup browsing needs to be included.  It was
included in the very first implementations of this scheme mostly because it
mimics the behavior of the Network Neighborhood.  All current
implementations of the SMB URI (of which I am aware) support this sytnax.

> Collisions between DNS and NETBIOS names should be avoided, too.

Absolutely, and it's an argument I've lost a thousand times.

The default on Windows and Samba systems is to use the hostname as the base
name when forming NetBIOS names.  So my old machine ruby.nts.umn.edu formed
NetBIOS names as "RUBY" + <padding> + <suffix byte>.  Using common NetBIOS
name notation, the Server Service was RUBY<20> and the Browser Election
Listener was RUBY<1E>.

The thing is, there is no real reason (from the protocol perspective) that
the above mapping needs to be enforced.  It's a convenience only.  NetBIOS
names have completely different *meaning*.  A NetBIOS name represents a
service (like a port under TCP or UDP), while a DNS name resolves to the IP
address of an interface.

From that perspective, the whole business of mapping DNS names to NetBIOS
services really doesn't make any sense.   ...but it's common practice.  A
kludge that has become a tradition that won't be broken.  Sigh.

I've spent a lot of time with this protocol suite.  It's quirky at best.

Again, you've identified issues that are important.  Some of them have been
discussed in detail previously but I can go over them again.

Thanks!

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh@ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh@ubiqx.org

Received on Thursday, 11 January 2007 19:02:09 UTC