smb://

"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