[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
REQUEST.
( "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.
Agreed.
> > 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