smb://

[Kevin Colby]

"Christopher R. Hertel" wrote:
> 
> A server cannot have the same name as a workgroup/ntdomain since both
> need to register using the #00 suffix.

Great.  That simplifies things to this:

(known server)    smb://[[domain/]user[:password]@]server/[share/[path/]]
(browse workgrp)  smb://workgroup/
(browse default)  smb://

> I do have a problem with the '/' in [domain/].  Because of the use of the
> slash, there is no way to know if the first field is a domain or server
> field.  [...]  If the '/' is used as a delimiter, and if the [domain/] is
> optional, then you have no way of knowing which field represents the server.
> You cannot use the ':' and '@' characters as guides.

The URI RFC #2396 may shed some light on this.
(http://www.ietf.org/rfc/rfc2396.txt)

Section 3.2.2 seems to indicate that an "@" would be neccessary to
terminate the userinfo portion of the authority component.  Good.
However, earlier, 3.2 also said this about the authority component:

  The authority component is preceded by a double slash "//" and is
  terminated by the next slash "/", question-mark "?", or by the end
  of the URI.  Within the authority component, the characters ";",
  ":", "@", "?", and "/" are reserved.

Well, great, the "@" & ":" are reserved within there, but this sounds
like a "/" would prematurely end that component.  Personally, I think
this is unfortunate (I like the domain/user syntax), but this seems to
indicate that only ";:@?/" are reserved are thereby eligible to be an
internal delimiter, but thet "/" and "?" will go too far and end the
component.  Since this only leaves ";", ":", and "@", and we are already
use ":" and "@", I see no choice but this:

  smb://[[domain;]user[:password]@]server/[share/[path/]]

Am I misinterpreting this?  Comments?

	- Kevin Colby
	  kevinc at grainsystems.com