http://ietfreport.isoc.org/idref/draft-crhertel-smb-url/ is the current SMB URI
draft.

Therefore a SMB URI to a printer should look like
smb://[workgroup;][user[:password]@]server/printername

There is no password in the SMB URI draft.

Actually, the ABNF definition includes the userinfo_nosem rule which allows for
strings of the form user:pass, just as RFC 3986 does.

The authdomain portion from:

    smb://authdomain;user:pass@server/...

is NOT the same as the workgroup, but corresponds instead to the NT domain used
for authentication (they often have the same name, but that is not a requirement)

It appears that the current SMB URI spec does not include the workgroup in the
name resolution of a server, so I'm not sure how that will fit with SAMBA's
implementation of SMB/NMB...

RFC 3986 is a new URI General Syntax document, which was recently published.  I
have already read through it a couple of times (when it was in draft form) and
will read it again before posting another SMB URI draft update.

That said...

In the earlier RFC 2396, the '\' character was listed as part of the "unwise"
set.  The semicolon (';'), in contrast, was given as a legitimate character in
the <userinfo> field.  In the newer RFC 3986, the semicolon is listed as a
sub-delimiter and also considered a valid <userinfo> character.  So...  It works.

You can't really use the '\' without escaping it, as in:
  smb://ntdom%5Cusrnam@svr/

In the above, however, the URI escape sequence can't be used as a URI delimiter,
so the above would be parsed as:

  username: ntdom\usrnam
    server: svr

The username would then be passed to the SMB implementation layer that is below
the URI parsing layer, and the SMB implementation could easily do its own parsing.

...but that's not how we decided to do it.

Since the '\' character is not a legitimate character in the <userinfo> field,
it woundn't really work to permit things like:

  smb://ntdom\usrnam@svr/
or
  smb://ntdom\\usrnam@svr/

Those don't conform to the general syntax of a URI.  That's why you have to use
"%5C".  The problem was that "%5C" is more annoying to type than ";" or "\;", so
we chose, instead to allow the SMB URI parser to handle separating the
authentication domain from the username.

As for the use of the colon (':') for password entry...  The folks on the W3C's
URI mailing list strongly dislike the use of the colon to permit the entry of
the password as part of the URI string.  On the other hand, everyone does it.
The colon is also a legitimate delimiter.

The strong recommendations would be:
1) Users should not enter a password as part of the URI string.
2) User agents should remove the password and redisplay the URI without it,
   if possible.
3) User agents should provide an alternate means of entering a password (a
   pop-up or prompt).

On the other hand...  There's a lot of good reason to support the :password
syntax.  It's use is wide-spread, after all, and there does need to be some
mechanism for supplying passwords in, for example, /etc/fstab (or
/etc/samba/smbfstab).

To some specifics:

  'Basically, the current SMB schema does not conform to RFC 3986 (the current
   URI specification) since the workgroup/domain is part of the userinfo.
   Since the "/" character is not an allowed character in this part of the
   URI, it must be escaped (%2F), however the smbspool program doesn't do %
   decoding in the URI.'

In the SMB URI, the workgroup/domain part is really the <auth_domain> field, and
it's purpose is to specify the NT (or AD) domain to which the user belongs.  It
doesn't have any impact on Network Neighborhood (workgroup) browsing.

The <auth_domain field is delimited from the username using a semicolon, not a
slash or backslash (for reasons given above).

I have no idea whether smbspool attempts to use correct SMB URI syntax or not.

  'Sooo, the solution is to support % decoding in smbspool; normally, I'd just
   use httpSeparate() (which handles it already), however I remember that you
   didn't want to depend on CUPS just to compile this program.'

URI escapes should be decoded only *after* the URI has been parsed into its
component pieces.  Delimiters can't be delimiters if they're URI escaped.

So, as outlined in the discussion...

  smb://[[authdomain;]username[:password]@]server[:port]/print_share

would be pretty dang close to correct syntax for specifying an SMB-shared print
service.

Chris -)-----

Chris, you said:

    'URI escapes should be decoded only *after* the URI has been parsed into
     its component pieces.  Delimiters can't be delimiters if they're URI
     escaped.

     So, as outlined in the discussion...

       smb://[[authdomain;]username[:password]@]server[:port]/print_share

     would be pretty dang close to correct syntax for specifying an SMB-shared
     print service.'

I have no problem with the proposed (new) syntax, and just want smbspool to
support a single URI format.  FWIW, httpSeparate() does all the "right" things
WRT % escaping and delimiters, and the code is small and simple enough that I
have no problem contributing it to the Samba project so that smbspool works
properly... :)

So, I guess the real question is: will server lookups work without a workgroup
in general?  That used to be a problem when I first did smbspool, so before I go
ahead and code the changes needed, will it work? :)

Michael Sweet wrote:

  'I have no problem with the proposed (new) syntax, and just want smbspool to
   support a single URI format.  FWIW, httpSeparate() does all the "right"
   things WRT % escaping and delimiters, and the code is small and simple
   enough that I have no problem contributing it to the Samba project so that
   smbspool works properly... :)'

I'm not familiar with any "proposed (new) syntax" for the SMB URI.  I've been
working on the drafts for years (several) and we've never proposed using the '\'
as a delimiter in any of the drafts.  It's been the semicolon for a long time
now.  Nothing "new" as far as I know...

  'So, I guess the real question is: will server lookups work without a
  workgroup in general?  That used to be a problem when I first did smbspool,
  so before I go ahead and code the changes needed, will it work? :)'

There is a different set of semantics for looking up servers that are members of
a workgroup.  Just quickly:

  smb://

is supposed to find all of the "locally known" workgroups.

  smb://workgroup/

is supposed to list all of the SMB servers that are members of the given
workgroup.  Note that the workgroup in the above string fits into the <server>
field, so something like this:

  smb://ntdom;user:passwd@workgroup/

is also legitimate.  In fact, it's needed for some servers that require
authentication to access the browse list.

The distinction between smb://workgroup/ and smb://smb_server/ is made
semantically.  You have to contact the server and find out what services it is
offering under those names.

So... back to your question:  will server lookups work without a workgroup in
general?

If you just want to find a server by name then you don't need to specify the
workgroup.  You only need the server name (which can be a NetBIOS name or a DNS
name).

If, however, you want to get a list of servers so that you can "browse" them
(see what services they're offering) you will probably want to start with at the
workgroup level:  smb://workgroup/.

The pseudo-hierarchy is this:

All workgroups (equivalent, more or less, to Windows' "Entire Network")
  |
  +-> A specific workgroup
        |
        +-> A server within the workgroup
              |
              +-> share offered by the server
                    |
                    +-> directory path, etc.

Does that answer the question?

Hope so!

Chris -)-----

It is new in the sense that the smbspool program has, since I contributed it for
2.0.6, used the following formats:

    smb://[username[:password]@]server/printername
    smb://[username[:password]@]workgroup/server/printername

So what I am asking is an implementation question: will the SAMBA client
lookup/connection code work without the workgroup name?  If so, there should be
no problems using the SMB schema URL format instead.

why is this in trunk ?  SHould be 3.0

As a matter of fact, this bug prevents from using password including '#' (sharp) character. The right way of escaping this character in CUPS is URLEncode : '%23'. However, smbspool don't decode %-encoded chars, and fails to authenticate.

Created attachment 2748 [details]
Unescape URI components of the uri passed to smbspool

This patch should address the problem of passing charcters that should be escaped to smbspool as part of the uri.
My preliminary test show the uri components are escaped properly, please comment.
If good I'll commit

A report tells me this is good.
Close it.
Committed r23524