[jcifs] Re: SMB URL

[Christopher R. Hertel]

Luke Kenneth Casson Leighton wrote:
> 
> hiya chris,

Hi Luke,

Good comments.

Basically, the current draft covers only SMB over NBT.  The move to
include SMB over native TCP is based on...um...pressure from some
vendors who have already started implementing.  My original thought was
to use smb:// for SMB over NBT and cifs:// for SMB over native TCP.  I
was, er, convinced that one URL form could handle both.

That said, the original smb:// URL form was [is] designed to handle both
SMB shares *and* browse list access.  So:

  smb://           - would return the list of local workgroups.
  smb://workgroup/ - would return the servers in the workgroup.
  smb://server/    - would return the shares offered by the server.

Yes, that's overloaded.  It's also convenient and there are mechanisms
(outlined in the draft appendix) for determining whether smb://name/
represents a workgroup or a server.  The mechanisms are semantic, rather
than syntactic, and do involve some network traffic.

The draft it at
  http://search.ietf.org/internet-drafts/draft-crhertel-smb-url-01.txt

So...

> On Tue, Sep 11, 2001 at 09:50:15AM -0500, Christopher R. Hertel wrote:
> 
> > * The URL will support both SMB over NBT and SMB over native TCP
> >   (port
> >   445 semantics).  I do *not* yet know if/how a browse list can be
> >   obtained from a W2K domain (a non-NBT browse list, probably
> >   stored in Active Directory), so I do not yet know if/how the SMB
> >   URL could be used to access a W2K Domain service list.
> 
> that is not part of file-serving, unless you want to
> go down the route of specifying IPC$ as one of the shares,
> whereupon it becomes a matter of specifying requests etc.

Right.  The URL form, as described and as currently specified in the
draft, is overloaded and supports *two* service types.  The most
important is the SMB filesharing service, but the second (and equally
important when you consider using this URL in browsers, KDE, etc.) is
the browser service.

...and yes there are a lot of reasons that this is ugly but hey, the
whole protocol is ugly.  :)

> i wouldn't recommend that this be done, not least because
> dce/rpc is available over http (proxied by ms from port 80
> to port 593, iirc correctly)

Lost me.  If DCE/RPC is available over http, then I assume that the AD
browse list can be accessed using a browser.  That simply saves me the
trouble of having to describe and outline a mechanism for retrieving
that list and, further, for figuring out if  smb://name/ represents 1)
an NBT share, 2) a W2K share, 3) an NBT workgroup, or 4) a W2K Domain
Active Directory server name (for obtaining the AD browse list).

The overloading is quite out of hand as it is.  Being able to say
"Active Directory browse lists are not supported by the SMB URL, use
HTTP instead" would be nice.

> > * The trailing "query string" syntax, common in URL strings, will
> >   likely be supported for the purpose of adding additional
> >   parameters such as the WINS server IP address, the Called Name to
> >   be used, etc.
> 
> have you considered specifying parts of files?
> (?start=NNNN&length=NNNN)

The idea crossed my mind.  I want to get a list of valid tags because I
really do *not* want people to add new tags without consultation with
other CIFS implementors.  It would be best if an organization, such as
SNIA, were to maintain the list of valid tags.  So far I have:

NBNS     - DNS name or IP address of the NBNS to use for NetBIOS name
           resolution.
NBDD     - DNS name or IP address of the Datagram Distribution Server
           to use for datagram distribution (I know, no one implements
           the NBDD but it is included for completeness).
WINS     - Synonym for NBNS.
SCOPE    - Scope should be included in the server identifier field, but
           I am adding room for it here as well.
START    - As you suggest.
LENGTH   - As you suggest.
OFFSET   - Synonym for START.
CALLNAME - When specifying a server by DNS name or IP address, it is
           sometimes necessary to also specify the called name to be
           used.  This tag allows the NetBIOS called name to be
           specified in the URL string.
SERVER   - When specifying a server by NetBIOS name, if that NetBIOS
           name cannot be resolved locally this field allows the server
           IP address or DNS name to be listed.  (That is, it's the
           reverse of the CALLNAME tag.)

> [also have you looked at DAV?]

Not yet.  I am aware of it.  It may "win" in the long term but, as I
mentioned, some vendors are already implementing the smb:// URL so we
might as well have a spec for it.  :)

> also, does the specification explicitly mention streams, which
> are referenced via two colons followed by the stream name
> (e.g. filename::data is the data stream, synonymous with the
> file itself).

No, it doesn't.  I am aware of them, however, and I feel that it is safe
to leave them out of the URL spec as they are part of the filesystem
syntax rather than the URL syntax.

> a lot of security mistakes have been made in IIS plugin
> components due to parsing of URLs that 'forget' about
> being able to reference the filename as sourcecode.asp::data
> which of course doesn't have an extension of .asp so is
> allowed.

Right.  That happens on the server side, however, and not on the client
side.  You can (I have) use string syntax in http URL strings in, for
example, Netscape.  I'm pretty sure Lynx allows it too.

It is the server's responsibility to parse the path string.  When we
implement such things in Linux, etc., we may run across the same
problems that the Windows and Mac systems have seen.  Hopefully, we will
have learned the lessons by then.


Thanks.  These are all issues that need to be raised so everyone knows
about them.

Chris -)-----

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