Luke Kenneth Casson Leighton
lkcl at samba-tng.org
Wed Sep 12 13:52:05 GMT 2001
On Wed, Sep 12, 2001 at 11:29:57AM -0500, Christopher R. Hertel wrote:
> 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.
that is very sensible.
> I was, er, convinced that one URL form could handle both.
no it can't. was the following issue raised:
at some point, netbios is going to be deprecated
[maybe 15 more years?]
at that point, port 139 is going to be unused.
at _that_ point, or possibly even earlier, ms
may decide to 'do away' with the NetBIOS session
request, and simply skip straight to what is
now the exclusive domain of port 445, which
i will refer to as cifs/tcp. [and will also
refer to what is now the exclusive (except
for port redirection requests) domain of
port 139 as smb/nbt.]
at that point, it will become necessary to
distinguish between cifs/tcp and smb/nbt -
_on the same port number_, for legacy
also, what happens if you get a port redirection
response from an smb/nbt server on port 139 which
tells you to connect to port 445?
even if netbios is not deprecated, how do you
detect the difference between cifs/tcp:portnumber
and smb/nbt:portnumber at the moment?
oh, what, if it's port 139 then it's _definitely_
smb/nbt, and if it's port 445, then it's _definitely_
so i think that it is incredibly important to have
the distinction between the cifs/tcp style [netbios
sessionless] and smb/nbt style [full netbios] file
sharing, and for this to be reflected in the
url naming convention.
otherwise, you're going to have to add an extra
parameter that says, "hey, i _know_ this is on
port 139, but i _really_ want a cifs/tcp style
netbios sessionless here. pleeease?"
> 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.
urr... not obvious.
> smb://server/ - would return the shares offered by the server.
well, that's just like a directory listing, so if you treat the
shares as directories, then it's obvious.
my concern is that you'd have to distinguish the server-list in
the workgroup from a directory listing.
how about :
Content-type=text/servers for a server list and
Content-type=[usual directory format] for shares and directories
> 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.
don't think it's going to be enough.
for example, on an NT5 PDC, RestrictAnonymous defaults to 0x2.
this terminates any possibility of performing anonymous
browse list requests.
according to the appendix c, you must not treat a smb_name
as a workgroup if there is any auth info sent.
> The draft it at
> > 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
> 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
> Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> contains important info including how to unsubscribe. Save time, search
> the archives at http://discuss.microsoft.com/archives/index.html
More information about the samba-technical