[jcifs] SMB URL

[Michael B. Allen]

On Sun, 7 Jul 2002 02:45:50 -0500
"Christopher R. Hertel" <crh at ubiqx.mn.org> wrote:

> 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.

I  agree but the query parameters are very useful to override configuration
parameters on a URL by URL basis. Without them you would have to change the
smb.conf.  Maybe  you  don't  have  access to the smb.conf. I use smbclient
//server/share  -W  ntdomain  all the time at work because my workgroup for
browsing is different. 

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

Well then what was his argument?


> ( ( "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?

Do you mean the Internet? If so, of course not but if CIFS were used
over the Internet the query parameters would be even more necessary.

>  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 
>   REQUEST.

It's better to hand it an IP address then a WINS name? What's the point
in having WINS then?

> ( "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.

I  thought  we  settled  this?  I think you should stop listening to Andrew
Bartlett because he obviously doesn't know what's involved in resolving the
authority component of these SMB URLs. 

> ( ( "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

Then I wouldn't overload this. I've used the term ntdomain to refer to the
authentication domain because a workgroup is clearly a browsing principle.

>   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.

I agree, this isn't that important but I don't follow the "should be in the config" argument.

> > 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.

Well this would be one of those parameters that should just be ignored
in that context.

> > > 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.

So you're going to leave out functionality from your IETF draft because
the one group says it's too much of an inconvienence to change their
existing implementation?

> 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.

The point of having the query string parameters is to remove these
implementation specific options!

Have to go to work.

Bye,
Mike

-- 
http://www.eskimo.com/~miallen/c/jus.c