Subject: RE: [Uri-review] SMB URL v05.

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 9 Jul 2003 08:22:07 -0700

Hi folks,

Here's a link to Chris Hertel's latest Internet-Draft of
the SMB URL scheme, posted on the IEEE/ISTO Printer Working
Group's anonymous FTP server:

ftp://ftp.pwg.org/pub/pwg/ps/draft-crhertel-smb-url-05.txt

It should also be available from the IETF I-D repositories
after next week's IETF 57 in Vienna.

Thanks,
- Ira McDonald
  High North Inc

PS - The IEEE/ISTO PWG folks would like to allow use of the
SMB URL scheme in their new Web services printing protocol
(PSI) for 'legacy' print system references.

_______________________________________________
Uri-review mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/uri-review

---

From: "Daniel R. Tobias" <[email-masked]>
Date: Wed, 09 Jul 2003 11:43:37 -0400

> ftp://ftp.pwg.org/pub/pwg/ps/draft-crhertel-smb-url-05.txt

My question is why the "//" part is included in the "null URI":

smb://
   -- No server has been specified.  In this form, the URL should be
      interpreted as a request for a list of Workgroups available
      on the local LAN.

This seems to reflect a mindset where "://" is an "atomic" separator 
between the protocol name and the rest of the URI, and in fact it's 
shown this way in the BNF syntax:

smb_absURL    = scheme "://"
                      [ smb_net_path ] [ "?" [ nbt_context ] ]

Actually, the colon (:) is the separator between the scheme and the 
rest of the URI, and the "//" is merely a prefix indicating that what 
follows is an authority or hostname.  Thus, the "null SMB URI" should 
be "smb:", not "smb://".

Note, for instance, that "mailto:" and "news:" URIs normally don't 
have any double (or single) slashes in them.

It seems to be part of the "dumbing down" of the Internet that people 
have misconstrued URI syntax to think that "://" is always part of 
it, even in instances where it doesn't actually make any sense.

-- 
Dan
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/

---

From: "Christopher R. Hertel" <[email-masked]>
Date: Wed, 9 Jul 2003 13:02:34 -0500

> My question is why the "//" part is included in the "null URI":

There are three reasons for this.

First, if you have "smb://smb_server/" and add the relative "..", which do
  you get?  "smb://" or "smb:"?

  When we put this together (a few years ago--and it was a bunch of
  SMB/CIFS developers, not URI designers), our understanding of the syntax
  was that the the correct result would be "smb://".

  The general BNF gives:

    net_path      = "//" authority [ abs_path ]

  We saw "smb://" as a 'network path' with a null authority.  "smb://" is
  the top of a hierarchy and, therefore, we believed it to more
  appropriately fit the net_path syntax (not the opaque_part syntax).

Second, that's what people implemented.  It seemed "natural" to the 
  SMB/CIFS crowd.  I imagine that it may have something to do with the 
  (surface-level) similarity between the URI and UNC formats (though, 
  honestly, the UNC format does not provide a meaning for "\\").  It may 
  also be that most of us think of "/" or "\" as the root of a directory
  tree, and since we were trying to suggest the top of the workgroup
  hierarchy as the root of the SMB tree (a. la. the Windows Network 
  Neighborhood hierarchy) the "//" seemed correct.

Third, I don't remember if it was Larry or Roy who first suggested using
  "smb:" instead of "smb://", but it was suggested.  After thinking about 
  it a while and proposing it to the CIFS community the proposal was 
  quietly dropped.

  Personally, I grew to like the idea because it provided a separate
  syntax for two different semantic aspects of SMB.  The idea was:

    smb:
      -- Return the list of workgroups.
    smb:workgroup
      -- Return the list of SMB file servers within the workgroup.
    smb://smb_server
      -- provide a list of shares offered by the SMB server.
    etc.

  That removes one of many layers of overloading from the SMB URI.  

  Practically speaking, however, there is little gain from the 
  implementor's perspective.  The change makes the URI-handling code more 
  complex and does not really change much with regard to the on-the-wire 
  protocol semantics.  The SMB URI is overloaded, yes, but SMB/CIFS 
  developers have to deal with such overloading anyway.  It comes with the
  territory.

Your question is a good one, of course, and has been debated before.  The 
issue stems from a problem that is inherent in the SMB/CIFS protocol 
suite.  Please allow me to explain:

- The SMB URI is meant to work with two different underlying transports:
  NBT (RFC 1001/1002) and what I call "naked" TCP transport.  We will
  ignore naked TCP transport for now, since it does not really enter into
  the discussion at hand.

- With NBT transport, SMB servers exist within workgroups (or NT
  domains--the two are equivalent for our immediate purposes).

- The list of available workgroups (often an incomplete list) can be 
  obtained by sending a query to a "browser" node, which can be located 
  using the NBT name service.

That provides a natural hierarchy:

- The list of workgroups is at the top.
  - Within a given workgroup there will be a list of fileservers.
    - Each fileserver offers a list of shares.
      - Each share is the root of a directory tree.

The problem is that the hierarchy is not strictly enforced by the protocol
(because workgroups were created and implemented as an afterthought).  It
is possible to connect to a server without knowing its workgroup
membership.  You can, for instance, connect directly using the DNS name or
IP address.

That in mind:

  smb://smb_server

is the best choice for identifying a fileserver because it means that 
things like:

  smb://favog.ubiqx.mn.org
and
  smb://192.168.101.21

both work as expected.  Of course, this dents the hierarchy since the
workgroup is not represented.

There are a lot of ways to work around this, and all have their problems.
We toyed, for instance, with:

  smb://workgroup/smb_server/path

but that did not map very well to existing URI schemes and broke 
completely when we considered naked TCP transport.

> between the protocol name and the rest of the URI,

No, this is just me recalling my highschool mathematics and reducing the 
equation by combining constants.  I am aware that "://" is not atomic.  I 
will correct the grammar in the draft.

> and in fact it's shown this way in the BNF syntax:
> 

Only if the "null SMB URI" is not viewed as the root of a hierarchy.  As
it stands it is viewed as such and, therefore, the slashes are appropriate
as they represent the "root" of a "net_path".

As I explained above, the SMB URI scheme as presented in the draft is
overloaded.  That is because the SMB/CIFS protocol suite itself is complex
and overloaded.  It even has its own special namespace (and all of the 
baggage that comes with that).  

I have a discussion of the workings of the scheme here:

  http://ubiqx.org/cifs/Appendix-D.html

It represents current practice and is, therefore, postscriptive not
prescriptive.  Note that the title of one of the sections is "Of Round
Pegs, Square Holes, and Big Mallets".  The SMB/CIFS protocol suite is not
particularly "clean", and it was difficult to get it to fit into something
that was actually "designed" in the way that the general URI syntax was
designed.

Chris -)-----

...a shame.  SMB was such a nice little protocol when it started out.

-- 
"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/     -)-----   [email-masked]
OnLineBook -- http://ubiqx.org/cifs/    -)-----   [email-masked]

---

From: "Daniel R. Tobias" <[email-masked]>
Date: Wed, 09 Jul 2003 14:54:47 -0400

>   you get?  "smb://" or "smb:"?

I wouldn't think either... If you have "http://someserver.example/" 
and add the relative "..", you don't get "http://" or "http:"; as far 
as I'm aware (correct me if I'm wrong) you just get 
"http://someserver.example/" again.  The semantics of relative URIs 
are defined independently of specific schemes, so the same should be 
true of "smb:" URIs.

---

From: "Christopher R. Hertel" <[email-masked]>
Date: Wed, 9 Jul 2003 14:36:56 -0500

> are defined independently of specific schemes, so the same should be 

There is no defined meaning for "http://" or for "http:".  There are no 
semantics for that.

In the SMB case, we are trying to retrofit a URI scheme to an existing
protocol--one that grew up outside of any standards framework (with the
notable exception of RFC1001/1002, but that only provides a mapping from
the NetBIOS API to IPv4 internetworks).  The point is that there are
several areas of SMB semantics that we have to squeeze into an SMB URI
scheme.  One of these is the need to work within the (somewhat broken)  
hierarchy preented by the protocol suite.

We needed a syntax to represent the semantic element "All available
workgroups".  The use of "smb://" (or "smb:") was a good choice.  No name
(workgroup name, DNS name, server name) is needed by the protocol when 
requesting the workgroup list.

So, we ask the question "what is the hierarchical parent of
'smb://smb_server/'?" because there is a semantic answer provided in the
SMB/CIFS suite.  We are using net_path syntax rather than the opaque
syntax for smb_server paths, so it seems reasonable to me to stick with 
that when moving to the "root" of the hierarchy.

Again, this is a very worth-while discussion since the mapping is
difficult, at best.  I don't completely like any of the solutions.  The
fact is that SMB/CIFS does not really map well to URI syntax, there are
compromises that need to be made, and most of those have already been
implemented (sigh).  The key is finding the best compromises.

Chris -)-----