> There are many pros and cons. The angle I view as outweighing all others
> has gotten little if any consideration in this thread as yet, so here it is:
>
> Usefulness.

I simply had not gotten to that part of the discussion yet. I needed to
put the issue itself on the table first. Besides, I knew that you would
be better able to state your case than I. :)

> If person 1 provides an smb-file-reference URL to person 2, that URL should
> work so long as person 2's client software shares a "style" (nbt or tcp)
> with the server.

...which basically says that full support for the URL must be implemented,
however the URL is defined.

> For Person 1 the style used might be "the other one",
> because 1) they have a different client and/or 2) the server has changed
> and now prefers or requires the other style.

No, that would invalidate the meaning of the URL string.

In order for the URL string to be valid, the string must mean the same
thing to both Person1 and Person2. This is highly problematic when
NetBIOS is considered, since two separate networks may include machines
with the same name. Fortunately, there is a parallel that "helps" us out
of this bind. That is, a non-fully-qualified DNS name has the same
problem. In, for example, and HTTP URL you get around the problem by
fully qualifying the name. We do the same in the SMB URL in a variety of
ways:

  1) You can use the FQDN instead of the NetBIOS name.
  2) You can use an IP address instead of the NetBIOS name, and specify
     the called name as part of the query string.
  3) You can specify an NBNS (WINS) server in the query string.

Note that incorrect or incomplete implementation of URL support on the
client is *not* a requirement, since that has no impact on the validity
of the URL string itself.

> Every client and server might support either or both styles. And as new
> software is installed every system can change in that regard. Probably
> software will trend to supporting both styles, but that isn't certain. In
> any case, our URLs should remain useful... if they are independant of
> style. URLs specific to one style or another will soon be broken.

I agree with all except the last sentance. As I said at the conference,
and as part of this thread, the technical question (which must be
answered) is this: Is there sufficient similarity between the protocol
"styles" (I'd say transports) to warrant support for both in one URL
format?

You say yes, as does George. I need to get consensus from the community
as a whole (and I am trying to present both sides, though it does take
time to do so).

As for the last sentance, allow me this example:

- If someone was offering a file via FTP and then decided to serve the
  file via HTTP, the change would not invalidate the FTP "style" of file
  transfer. The original ftp:// URL string would also still be "valid";
  it's just that it would no longer point to anything. The string
  "ftp://ftp.apple.com/ms-windows/source/W2K/" is a syntactically valid
  URL string, it just doesn't point to anything (I hope).

So, if we were to specify that SMB:// was SMB/NBT-only and that cifs://
was CIFS/TCP only then someone changing a fileserver to run one 'style'
rather than the other would not "break" the URL form. It would simply
invalidate existing URL strings. That would, granted, be annoying to
users.

> As it is possible to determine what style support is available from a given
> server, URLs can and should be transparent to "style".

It possible for SMB file transport over either NBT or TCP. My question
was and is: Can we also access the non-NBT service list this way?
That is:

  - Under NBT, the URL string smb:// would list the workgroups on the
    local LAN. What does it do under CIFS/TCP?

  - Under NBT, the URL string smb://workgroup/ would list the servers
    available in the workgroup. What does the equivalent
    (smb://W2KDomain/) do under CIFS/TCP?

  - What additional work must we do on the wire to figure all of that out?

If I've got my facts straight, it is trivial to support both SMB over NBT
and SMB over TCP using one URL string. As George said, we can specify
that the "smb://" prefix means use port 139 and try NBT semantics first.
The "cifs://" prefix would mean use port 445 and try non-NBT semantics
first. I suppose that we must now also try *both* port options (when the
port not explicit) for each prefix. The prefix is nothing more than a
hint.

That's all ugly, but this is SMB we're talking about. Ugly is to be
expected.

> Were it somehow
> impossible to determine style, even through trial and error, then we'd have
> a protocol problem to address, not just a URL issue.

That's my question. It's not just the file service that we need to
consider, it is also file location (browsing).

Chris -)-----

--
Christopher R. Hertel -)-----                   University of Minnesota
crhnts.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
----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info including how to unsubscribe.  Save time, search
the archives at http://discuss.microsoft.com/archives/index.html

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]