[jcifs] SMB URL

[Michael B. Allen]

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.

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

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

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

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

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

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