Christopher R. Hertel crh at
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] ??)

Chris -)-----

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

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

More information about the samba-technical mailing list