[jcifs] SMB URL

Christopher R. Hertel crh at ubiqx.mn.org
Sun Jul 7 17:45:50 EST 2002

Lots of context...  New content below...

On Sun, Jul 07, 2002 at 01:31:41AM -0400, Michael B. Allen wrote:
> On Sat, 6 Jul 2002 19:35:09 -0500
> "Christopher R. Hertel" <crh at ubiqx.mn.org> wrote:
> > On Sat, Jul 06, 2002 at 08:03:16PM -0400, Michael B. Allen wrote:
> > > On Sat, 6 Jul 2002 15:47:15 -0500
> > > "Christopher R. Hertel" <crh at ubiqx.mn.org> wrote:
> > > 
> > > > I need to get a new SMB URL draft into the IETF.  The current is set to 
> > > > expire.
> > > > 
> > > > Some quick thoughts:
> > > > 
> > > > - I went over the list of parameters that can be set using the ?<query> 
> > > >   syntax and removed a few (per Mike's suggestion, IIRC).  The current 
> > > >   list is:
> > > > 
> > > >       nbt_param     = ( ( "NBNS=" | "WINS=" ) host )
> > > >                       | ( "NBDD=" host )
> > > >                       | ( "SCOPE=" hostname )
> > > >                       | ( "CALLED=" netbiosname )
> > > >                       | ( "CALLING=" netbiosname )
> > > >                       | ( ( "WORKGROUP=" | "NTDOMAIN=" ) nbtname )
> > > >                       | ( "RESOLVE=" nbt_resorder )
> > > 
> > > I  would  rather you introduce only the obviously useful parameters so that
> > > we  can  incorporate  that  functionality  into  clients and then gradually
> > > determine what other parameters would be useful. It would be much better to
> > > add  additional  parameters  later  rather  than  have to remove some after
> > > realizing  they  weren't  appropriate. For example it's not clear that NBDD
> > > would  be useful or even applicable
> > 
> > I agree about NBDD.  No one implements it, and NBT browsing works better
> > without it.
> > 
> > > whereas parameters to specify the local
> > > interface  to  bind to or an lmhosts file to use are examples of parameters
> > > that  might  be  necessary  for  the client to function properly.
> > 
> > How so?  That sound's like really dangerous ground.  Also, recall that a 
> > URL is supposed to be something that someone else can give you.  Eg. you 
> > should be able to click on an SMB link on the jCIFS page and get a file, 
> > just as you would with an FTP URL.
> So, all parameters must be locale indenpendent? I'm not sure I see why
> that is so crucial. They should not use them just like passwords should
> not be. But ok.

Yeah... My thinking is this:  An SMB URL -aware application will likely 
have its own configuration.  Things like Scope ID, WINS server, resolve 
order, etc. really belong there.  What KDE does now is that they read the 
smb.conf (because they are using Richard's libsmbclient library, which is 
interwoven with Samba).  My feeling is, if the URL string is going to 
override or supplement local configuration it should do so with purpose.

Andrew Bartlett argues eloquently against these parameters, but I don't 
agree with all of his reasoning.  Some specific ideas...

( ( "NBNS=" | "WINS=" ) host )

  This is useful for choosing the WINS server on the fly.  Something you 
  do on the command-line (as Mike points out).  Nice, but should it be 
  used across the 'net?  In the latter case, what you're doing is saying 
  "here, use my WINS server to resolve this NetBIOS name".  Better to just 
  hand the user a DNS name or IP address.  The only problem there is that 
  you may wind up not having a valid CALLED NAME for the NBT SESSION 

( "NBDD=" host )

  Removed.  No point.

( "SCOPE=" hostname )

  This is interesting.  The SCOPE is never used in the NBT SESSION
  REQUEST, so the only time it is used is during name resolution.  This is
  SMB, after all, so NBT name resolution should be supported.  My 
  thinking, though, is to go back to the way things are currently done
  using UNC format or with Samba or other tools, and allow for names of 
  the form: <netbios_name>["." <Scope_ID>].  I think that makes more sense 
  from a user perspective.

( "CALLED=" netbiosname )

  Here's the problem:  If you are using port forwarding or ssh tunnelling 
  or somesuch, how do you get hold of a correct CALLED NAME?  If the 
  server is a W/9x box then "*SMBSERVER" won't work.  Port forwarding 
  situations typically will block NBT name resolution, so the connection
  address is probably the DNS name or IP address of the forwarder, not the
  actual server.  End result:  No way to derive a CALLED NAME.  That's why
  this parameter would be useful.

( "CALLING=" netbiosname )

  Normally ignored... *but* Samba uses the CALLING name in a variety of 
  ways.  There's actually a macro for it.  Further, you could (in theory, 
  though I'm wondering if some Windows boxes don't do this in practice)
  restrict access based on the CALLING name.  It would be nice to be able
  to set it in the config file (which you can do) or on the URL line.

( ( "WORKGROUP=" | "NTDOMAIN=" ) nbtname )

  Sorry to be unclear about this.  This specifies the workgroup for 
  browsing.  I am leaning more and more toward "smb:<workgroup>" for
  browsing, though, so this may be unnecessary.

( "RESOLVE=" nbt_resorder )

  This really should be client config, though being able to specify it on 
  the command line would be convenient.

> > If we set up a "public" (read "nailed down, unchangeable, static") WINS 
> > server we could even supply the NBNS parameter.  Just about everything in 
> > the list is highly portable.  The exception *might* be the WORKGROUP 
> > option, but even that...  I am working on that one...
> I  agree  that  what works for the Internet provides insight into what will
> work  successfully  on  LANs but let's keep in mind that CIFS will never be
> used on the open internet. 

Let's hope not, but don't count on it.  :(

> > > Also, the
> > > RESOLVE parameter  suggests  that  clients  must  provide  resolve  order
> > > functionality  which  is more sophisticated than I think most clients would
> > > be willing to support. I'd say only NBNS/WINS and SCOPE would be the minmum
> > > introductory  set although CALLED *might* be useful for clients that do not
> > > have  sophisticated  resource resoultion.
> > 
> > jCIFS and smbclient allow specification of resolve order, and so do 
> > several other tools I've seen.  You would need to be able, at minimum, to 
> > specify B, P, M, or H mode.  All clients do that (as far as I know).  
> > The other option is simply a way to include DNS into the ordering.
> Well  it's  not  a  crucial  option.  Obviously all of these parameters are
> optional  so  if the client doesn't support a resolve order it's not a show
> stopper. 

If I remove it from the specification, though, it could still be
implemented as a client-specific feature.  In other words, jCIFS would
know what it means but you would never post a URL that had that string
included.  Hmmm... Or clients that don't support it would just ignore it.

> > As for CALLED and CALLING, I doubt that people will use them much, but 
> > they might.  Adding CALLED is important because, for example, I might be 
> > connecting to a W/95 box across the country.  I have the DNS name but not 
> > the CALLED name, and W/95 doesn't support *SMBSERVER.  What do I do?
> Right.

This is only a problem if you can't get a node status and you can't be 
sure of the DNS name of the target... both possible.

> > > The WORKGROUP/NTDOMAIN parameters
> > > are  redundant (and thus confusing) because you can specify the ntdomain in
> > > the  authentiocation  credentials  and  the  workgroup  in  the  overloaded
> > > authority component. 
> > 
> > Different purpose.  We talked previously about the fact that you can 
> > authenticate in one domain but access services in another.  Not a big 
> > deal, since the server name is independent of the authentication domain.
> >
> > Anyway, the purpose of the ?WORKGROUP= parameter is to designate the 
> > default workgroup (or NTDOMAIN) for browsing.
> Ahh, I thought you were using NTDOMAIN to designate the authentication
> domain and WORKGROUP to designate the browsing group.

Normally I do.  My fault.

> > > > - This is the controversial one...
> > > >   In the current draft, you can type:
> > > > 
> > > >     smb://<name>
> > > > 
> > > >   and if <name> resolves to a workgroup name you will get the browselist 
> > > >   for that workgroup (assuming it's available somewhere).  I am thinking 
> > > >   that we could change that to:
> > > > 
> > > >     smb://?WORKGROUP=<name>
> > > > 
> > > >   to get the browselist for that workgroup.
> > > 
> > > Why?  I  don't  understand. Where did you get this from? Doesn't USENET use
> > > something  like  news:GROUP.  If you're going to change it I would do that.
> > > But  I  think  it's been established that the current scheme works and that
> > > there are no fundamental issues with it so ... 
> > 
> > That was one of the suggestions from the RFC2396 authors.  Could do...  I 
> > figured that, since we already had the ?<keyword>= syntax going why not 
> > put it there?
> Because it's a little confusing unless you're talking about getting rid
> of the smb://workgroup format.


> > Well, following a heated discussion on #samba-technical IRC, I could 
> > be convinced that only the SCOPE is worth-while, and even that is 
> > questionable.
> >
> > What would happen if all of the above parameter options were removed?
> > It seems to me that most of them would need to be configured within
> > the application.  That might be a pain in tools like Mozilla or
> > Netscape.
> >
> > Thoughts?
> What  were  their  arguments  against?  I  think query string parameters
> in general  is  a  good  idea  so I don't see how anyone can fault them.

One argument against the WINS= parameter was that it would be a hard thing
to add to some implementations.  Samba was given as an example, but it's 
really libsmbclient that one would need to consider.  The problem being 
that libsmbclient reads its config data from smb.conf, and doesn't have a 
means for overriding things like the WINS server.

On the one hand, I'm not sure that's a valid point.  That's a limitation 
of the software, not the URL format.  On the other, I think that the only 
good reason for being able to specify the WINS server in the URL is as a 
command-line config shortcut.  Very useful, but it means that it's not 
necessary to support that as part of the general URL.  It's just something 
that a client implementation would do on its own.

I think that the resolve order is in the same category.  I really don't 
want a remote site specifying my WINS server *or* my resolve order.

Called and calling names are interesting.  In the case where you cannot 
guess at the Called name you really do need to be able to specify one.
The calling name is only interesting if the server makes use of it...

It might be nice to let a remote site specify these.  The site may only 
allow specific called and/or calling names to access their services.

In many ways, the Scope ID belongs with the name.  It is only used during 
name resolution anyway.

> But I think you should restrict the introductory set to the minimum.

...then I'd need a mechanism for adding new "official" ones.

I *think* that the proposed list is fairly exhaustive.  There's probably 
something I'm missing...  Let me know if you find it.

> SCOPE is necessary if it's not woven into the URL.

I'm leaning toward weaving it into the URL.

> NBNS/WINS is something I have a tendency to specify on the commmandline
> with jCIFS so I think that would be the runner up. That would be good
> enough just to introduce the idea and let it grow.  For example jCIFS
> could simply expose all non-global java properties using this technique.

Now *that's* an idea.  Putting all of the properties into query strings...

It highlights the basic problem, though.  If you allow those strings then
people will want to post them on the web for others to click on.  What
happens when the query string is ignored because the client doesn't know
what the keyword means?

I think that the minimum required would be the CALLED NAME.  The rest are
varying degress of optional, but I think they are the minimum set in the
sense that they represent the most basic set of configuration details you
would need to run a client.  Every client needs to know it's resolve order
(even if it's hard-coded), scope, calling and called names, WINS server
(if there is one).

It is likely, by the way, that I will switch to using smb:<name> for 
browsing in the draft.  That doesn't set it in stone, though.

Chris -)-----

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 at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org

More information about the jcifs mailing list