[jcifs] Re: preliminary comments on doc

[Christopher R. Hertel]

Some comments on the SMB URL draft.  These came originally from Alan
Yoder.  A slightly edited copy of my reply is below...


> Section 1.
> 
>    Probably should include the standard verbiage about
> use of SHOULD, MUST, etc.  [RFC 2119]

I have looked through the guidelines on use of that text and it is very 
unclear to me if it should be used.  I have asked IETF folk, but not yet 
gotten an answer.  I plan on pushing the issue with the next revision.

So, for now, point taken.  The resolution is up in the air.

> Section 2.2.2
> 
>    I'd be a bit concerned, from a naming perspective, about the 
> implications of having smb:// be the root of the local workgroup 
> tree.  Won't this confuse users who share documents within the 
> same organization that has multiple LANs and browse masters?
> Using something like smb://workgroupname/ seems preferable, IMO.
> Your call, though.

smb://workgroupname/ is supported.  An application should probably have a
mechanism for setting the default workgroup (a configuration file,
whatever), and when it starts up it can start with the
smb://<def_workgroup>/ URL string.

The reason for the smb:// form is that, in order to support full browsing 
capabilities, we needed to be able to access the top level of the browse 
list.  That is, the list of workgroups/ntdomains.

Think of the Network Neighborhood application on a Windows box.  When you
start up, it shows you the default workgroup.  You can go "down" to
individual servers, or you can go "up" to the "Entire Network".  Since the
smb:// form had no other meaning, it seemed logical to use it as the root
of the workgroup hierarchy. 

It certainly can be a bit awkward, since smb://server/.. will give you 
the "Entire Network" instead of the workgroup itself.  There were debates 
about this, but having to specify something like:

  smb://workgroup/server/share/path

did not make sense, so we scrapped it.  (It also did not comply with the
base standard URL syntax.) The result is that SMB URL is simply
overloaded.  It accesses two services instead of one.  I didn't want to 
create a separate URL form for the Browse Service.

> 
> 
> Section 2.6
> 
>    First sentence.  Why?  First of all, there are Urban's 
> objections. 

Yes.  Urban was right.  We need support for the :<port> field.

> Secondly, it seems quite reasonable to want 
> smb://<server>:445/ to do the same thing as cifs://.  I'm
> completely unclear on the reasons for the introduction of
> an entire new scheme in order to avoid parsing port numbers.

It seems reasonable, but the transport and supporting protocols are
completely different.  Naming is different, authentication is different, 
service announcement is different, etc.  In fact, the only part that is 
the same is the SMB protocol...and even that is different.

Point is, to implement support for a single URL form to access both
network filesharing systems would be massive overload.  The software would
need to do a lot of work to figure out which protocol suite was being
used.  It already needs to do too much work to figure out if the server
name is a workgroup or a file server, and if it is a DNS name, NetBIOS
name, or IP address.

Also, specifying that port 445 is new CIFS and any other port is old CIFS 
doesn't seem safe to me.

Much easier if the URL prefix identifies which protocol to use.  That's 
what it's for, really.

>    Would you be open to the specification of a secure PKI-
> based shorthand mechanism?  Something like, say,
> 
> 	smb://<ntdomain>;<pki-id>:<blob>@<smb-srv-name>  ?
> 
> I.e., encrypt the username and password with smb-srv-name's 
> public key, and send those instead of the cleartext username
> and password.

If the draft excludes this possibility let me know.  I see no reason why
this should not be supported.  The use of the colon worries me because the
colon separtates the <port> field.  Still, anyone parsing the above string
should key on the '@' first.  I'll have to check the syntax rules, but I
think you may be okay with what you've got. 

>    For Win2k compatibility, it seems to me that a way of
> doing Kerberos authentication is pretty much required.

Another reason for a separate URL form for new CIFS.  ;)

By the way, I think it would be *very* important to have someone write up 
a CIFS:// URL specification (and I certainly don't have time).


Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services

    Ideals are like stars; you will not succeed in touching them
    with your hands...you choose them as your guides, and following
    them you will reach your destiny.  --Carl Schultz

----- End forwarded message -----

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