Christopher R. Hertel
crh at nts.umn.edu
Thu Dec 28 20:44:59 GMT 2000
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> -> Great. That simplifies things to this:
> -> (known server)
> -> smb://[[domain/]user[:password]@]server/[share/[path/]]
> -> (browse workgrp) smb://workgroup/
> -> (browse default) smb://
> I like this format. It make logical sense.
> -> use ":" and "@", I see no choice but this:
> -> smb://[[domain;]user[:password]@]server/[share/[path/]]
> I don't like this. It's non-intuitive, and just tries to make the URI
> easier to parse, w/o looking at the whole URI.
As I understand it, based on other messages here, it is necessary that the
'/' *not* be used to delimit the domain from the user in order to comply
with the RFC specified syntax.
> If the @ exists in the URI,
> then what if the is a / to the left of it, the slash seperates the domain
> from the username[:password] fields. If there is no @ in the URI, then no
> domain should be specified, unless the domain is what is being browsed. It
> makes sense to me anyways...
Yes, I see your point. If the domain exists then the @ must also exist,
so if the @ is present, then we know that the first field must be the domain.
Except that I do not know if an @ sign is a legitimate character in a
service name, directory path, or filename. I think that it is allowed,
which would break the scheme you suggest.
I think the two formats that we are narrowing towards are:
There is precedent for using the backslash and, since Microsoft uses that
character as part of their UNC, it is unlikely at worst that it will be
part of a username.
(Um, should that be [domain\]user or user[\domain] ??)
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
More information about the samba-technical