SMB URL

[Christopher R. Hertel]

> Ah, I see.  You read "broken" in a different sense than I intended.  By
> "broken" URLs I meant broken links, which amounts to a "minor annoyance",
> or "frustrated customer hopelessly lost in cyberspace", or something in
> between, depending upon degree of user sophistication.

Well, I can see the distinction and why there was a miscommunication on
this point.  I don't, however, imagine users (they're real people, after
all, not just "customers") being "hopelessly lost".

Forgetting the relative sizes of the gaps between the hidden-from-view
protocol types, I don't see users getting hopelessly lost when they have
to switch from ftp to http and back again.  Both protocols allow file
access and a 'smart' browser could easily apply mailcap MIME rules to FTP
files, if desired.  From the user's perspective, how much difference is
there?  From the user's perspective, not much.

> To break the non-synonomous URL form, just add a new transport in 5 years
> or so.  With the synonomous URL form, the new transport slides on in.

OH NO!  There is *NO* way to know what kind of new transport we are
talking about and *NO* way to know if it will slide right in.  We already
*have* alternate transports.  There is SMB over NetBEUI, SMB over IPX/SPX,
DECNet, Banyan, etc., etc.  The list goes on.

Besides, it isn't the new transport that I'm talking about.  That appears
to be a solvable problem.  It's the rest of the suite.  I personally do
*not* know how to retrieve the W2K equivalent of the browse list.

Part of the goal of the SMB URL is to allow users to navigate the entire 
service hierarchy.  Under NBT, that means:

List of available workgroups (smb://)
 \
  List of workgroup/NTDomain member servers (smb://workgroup/)
   \
    List of server shares (smb://server/)
     \
      List of files/directories under a given share (smb://server/share/)
       \
        etc.

If we can, with some degree of technical face-saving, come up with a way
to do this for both protocol suites then the argument that it is valid to
further overload the URL form to that additional degree will make sense. 

I just need to know how to read the W2K service list to see if this is
possible. 

> Under a non-synonomous model a third prefix should be created.  Yuck.  If
> one URL prefix can encompass the semantic and functional differences in smb
> from windows xp back to early lanmanager, then I hope and expect it can
> encompass this change too.

That will be a bridge to be crossed when it starts burning.

> If we find we _must_ go down the path of N prefixes for this network
> filesystem, then I'd like to see there be a special prefix which retains
> ambiguity - one prefix which can be used when you want to create a link
> which is likely to survive.

If there are multiple prefixes, one per transport and supporting suite, 
then the likely reason will be that we cannot resolve the ambiguities.

> BTW ftp and http are so very different...  

Not at the user level.

> I'd rather consider cifs/tcp vs cifs tunneled over something - nfs lets say. 

...but that's not the issue at hand.  It doesn't make sense to consider 
SMB over NFS.  The URL form won't support that anyway.  (You would use an 
NFS URL string of some kind, I think.)

> The tunneled will have less
> functionality, and perhaps subtle semantic issues, but for this would you
> advocate breaking link-portability by having a different prefix?

Why/how would it break link-portability?

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