Re: [jcifs] Re: SMB URL
On Wed, Mar 26, 2003 at 07:55:58PM -0500, Allen, Michael B (RSCH) wrote: : > > It's flakey, but the terminology is flakey to begin with. > > > This is how I always distinguished workgroups and domains. Okay. Then it's probably just me that's flakey. Chrudz -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
RE: [jcifs] Re: SMB URL
> -Original Message- > From: Christopher R. Hertel [SMTP:[EMAIL PROTECTED] > Sent: Wednesday, March 26, 2003 4:26 PM > To: Michael B. Allen > Cc: Stephan Kulow; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [jcifs] Re: SMB URL > > On Wed, Mar 26, 2003 at 03:42:34AM -0500, Michael B. Allen wrote: > : > > > The other part missing is the query handling. Currently libsmbclient relies > > > on ~/.smb/smb.conf for the workgroup (which is a bit problematic when you > > > want to copy files from one workgroup to another from a linux client ;( > > > Above that it gives a ?WORKGROUP=COOLO - no such file > > > > I'm not sure I understand this. Do you mean domain? Does libsmbclient > > support the forms: > > > > smb://domain;user:[EMAIL PROTECTED]/share/path/to/file > > > > and > > > > smb://workgroup/ > > I'm just throwing in a side-comment on terminology... > > After a lot of discussion I (personally) have settled on the following: > > Workgroup: The scope of the browse environment. > NT Domain: An authentication domain. > > It's flakey, but the terminology is flakey to begin with. > This is how I always distinguished workgroups and domains. Mike
Re: [jcifs] Re: SMB URL
On Wed, Mar 26, 2003 at 03:42:34AM -0500, Michael B. Allen wrote: : > > The other part missing is the query handling. Currently libsmbclient relies > > on ~/.smb/smb.conf for the workgroup (which is a bit problematic when you > > want to copy files from one workgroup to another from a linux client ;( > > Above that it gives a ?WORKGROUP=COOLO - no such file > > I'm not sure I understand this. Do you mean domain? Does libsmbclient > support the forms: > > smb://domain;user:[EMAIL PROTECTED]/share/path/to/file > > and > > smb://workgroup/ I'm just throwing in a side-comment on terminology... After a lot of discussion I (personally) have settled on the following: Workgroup: The scope of the browse environment. NT Domain: An authentication domain. It's flakey, but the terminology is flakey to begin with. Regarding that definition of workgroup... If you have two subnets and all of the nodes belong to the "FOO" workgroup then: - if there is a DMB, and the LMBs on both subnets are exchanging browse lists with the DMB, then you have a single workgroup named "FOO". - if there is no DMB, or if the LMBs are not exchanging browse information (perhaps one is a B node, or perhaps there are different WINS serves) then you have two separate workgroups, both nmaed "FOO". Again, it's flakey, but it's the best I've been able to come up with. Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
Re: SMB URL
Am Wednesday 26 March 2003 09:42 schrieb Michael B. Allen: > On Wed, 26 Mar 2003 08:20:17 +0100 > > Stephan Kulow <[EMAIL PROTECTED]> wrote: > > > We did reach an important conclusion that would be influential to > > > anyone writing an SMB URL parser. That is, even though SMB URLs do not > > > require Unicode characters be escaped (for practical reasons) they > > > should be able to decode escaped Unicode characters. This begs the > > > question; how do you escape Unicode characters? The prevailing answer > > > appears to be specified in the W3C IRI documents which suggest each > > > escape should be treated as a byte in a UTF-8 multibyte sequence. > > > > > > Otherwise, the SMB URL is reasonably well defined. Unicode handling was > > > the only remaining issue I believe. The jCIFS client implements all of > > > this functionality minus the decoding of escaped UTF-8 sequences. > > > > > > Please join the jCIFS mailing list if you have specific questions. We > > > have had many interesting discussions there about the SMB URL, we have > > > implemented it completely, and there are three people who understand it > > > quite well. Chris and Eric have the brains. Me type. > > > > > > I'm not familiar with the state of the libsmbclient SMB URL handling. > > > > Well, as you say yourself, the client needs to be able to decode escaped > > characters (you always say unicode characters, but that's not the only > > problem, you need to descape '?', '=', '@' and similar characters too, > > that > > Sure. > > > So while libsmbclient doesn't need code to escape any characters as it > > never returns URLs, but just names or data, it urgently needs code to > > descape them. > > I wouldn't say "urgently". JCIFS is getting along without it ok at the > moment. It depends where their being used. One such case is when they So it can't browse my host named @home? :) > are embedded in the PATH_INFO of an HTTP URL however it would also be > necessary to provide an escape function to the author so that the URLs > are properly escaped using UTF-8. Well, I browse within konqueror and KDE does have a correct URL handling, so either I descape these in the mapping to libsmbclient or I fix it where it belongs: in libsmbclient. > > > The other part missing is the query handling. Currently libsmbclient > > relies on ~/.smb/smb.conf for the workgroup (which is a bit problematic > > when you want to copy files from one workgroup to another from a linux > > client ;( Above that it gives a ?WORKGROUP=COOLO - no such file > > I'm not sure I understand this. Do you mean domain? Does libsmbclient > support the forms: > > smb://domain;user:[EMAIL PROTECTED]/share/path/to/file Yes. But what if a server appears in two workgroups? Even if you have anonymous access to both of them. The DRAFT specifies WORKGROUP query for that, libsmbclient doesn't even code yet to ignore queries. > > and > > smb://workgroup/ It does. And when I enter a directory within that, I can't simply make sure the URLs are unique in using smb://host/?WORKGROUP=workgroup I think, I would even have gone for smb:///?WORKGROUP=workgroup to make this even less ambiguous. Greetings, Stephan
Re: SMB URL
On Wed, 26 Mar 2003 08:20:17 +0100 Stephan Kulow <[EMAIL PROTECTED]> wrote: > > We did reach an important conclusion that would be influential to anyone > > writing an SMB URL parser. That is, even though SMB URLs do not require > > Unicode characters be escaped (for practical reasons) they should be > > able to decode escaped Unicode characters. This begs the question; how > > do you escape Unicode characters? The prevailing answer appears to be > > specified in the W3C IRI documents which suggest each escape should be > > treated as a byte in a UTF-8 multibyte sequence. > > > > Otherwise, the SMB URL is reasonably well defined. Unicode handling was > > the only remaining issue I believe. The jCIFS client implements all of > > this functionality minus the decoding of escaped UTF-8 sequences. > > > > Please join the jCIFS mailing list if you have specific questions. We > > have had many interesting discussions there about the SMB URL, we have > > implemented it completely, and there are three people who understand it > > quite well. Chris and Eric have the brains. Me type. > > > > I'm not familiar with the state of the libsmbclient SMB URL handling. > Well, as you say yourself, the client needs to be able to decode escaped > characters (you always say unicode characters, but that's not the only > problem, you need to descape '?', '=', '@' and similar characters too, that Sure. > So while libsmbclient doesn't need code to escape any characters as it > never returns URLs, but just names or data, it urgently needs code to > descape them. I wouldn't say "urgently". JCIFS is getting along without it ok at the moment. It depends where their being used. One such case is when they are embedded in the PATH_INFO of an HTTP URL however it would also be necessary to provide an escape function to the author so that the URLs are properly escaped using UTF-8. > The other part missing is the query handling. Currently libsmbclient relies > on ~/.smb/smb.conf for the workgroup (which is a bit problematic when you > want to copy files from one workgroup to another from a linux client ;( > Above that it gives a ?WORKGROUP=COOLO - no such file I'm not sure I understand this. Do you mean domain? Does libsmbclient support the forms: smb://domain;user:[EMAIL PROTECTED]/share/path/to/file and smb://workgroup/ Wouldn't these resolve the issue (which ever it is) you describe. I think SCOPE and WINS (or Chris prefers NBNS) are probably the only parameters that are necessary for a completely autonomous SMB URL. I fear the different SMB URL implementations are probably quite different when it comes to semantic details :-( It would be nice to see them become uniform. Mike -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived.
Re: SMB URL
Am Tuesday 25 March 2003 22:12 schrieb Michael B. Allen: > Please look at the jCIFS mailing list for discussions in February > about the SMB URL. There was an interesting discussion about Unicode > hanlding. The problem of course is that URLs require characters outside > of ASCII to be escaped with %HH hex escapes. This is of course not very > reasonable with SMB URLs so hex escaping is not required. In practice > this should not be a problem because these URLs are not submitted as > parameters to text based RPCs like HTTP GET requests. Correct. As long as libsmbclient (or any cifs client for that matter) doesn't use a URL itself for communication, it doesn't need to encode any URL part. > > We did reach an important conclusion that would be influential to anyone > writing an SMB URL parser. That is, even though SMB URLs do not require > Unicode characters be escaped (for practical reasons) they should be > able to decode escaped Unicode characters. This begs the question; how > do you escape Unicode characters? The prevailing answer appears to be > specified in the W3C IRI documents which suggest each escape should be > treated as a byte in a UTF-8 multibyte sequence. > > Otherwise, the SMB URL is reasonably well defined. Unicode handling was > the only remaining issue I believe. The jCIFS client implements all of > this functionality minus the decoding of escaped UTF-8 sequences. > > Please join the jCIFS mailing list if you have specific questions. We > have had many interesting discussions there about the SMB URL, we have > implemented it completely, and there are three people who understand it > quite well. Chris and Eric have the brains. Me type. > > I'm not familiar with the state of the libsmbclient SMB URL handling. Well, as you say yourself, the client needs to be able to decode escaped characters (you always say unicode characters, but that's not the only problem, you need to descape '?', '=', '@' and similar characters too, that do have a specific meaning in URLs (I named my test machine @home just to annoy parsers :) So while libsmbclient doesn't need code to escape any characters as it never returns URLs, but just names or data, it urgently needs code to descape them. The other part missing is the query handling. Currently libsmbclient relies on ~/.smb/smb.conf for the workgroup (which is a bit problematic when you want to copy files from one workgroup to another from a linux client ;( Above that it gives a ?WORKGROUP=COOLO - no such file Greetings, Stephan
Re: SMB URL
On Tue, 25 Mar 2003 21:39:26 +0100 Stephan Kulow <[EMAIL PROTECTED]> wrote: > Hi! > > I looked into the URL handling libsmbclient is doing and it's > lacking quite some of the stuff that the DRAFT specifies (and > some of the stuff that generally are required for URIs). Is > someone working on that? > > I'm currently preparing some patches, but hate C programming > enough to dump it for some other solution :) > > Greetings, Stephan Please look at the jCIFS mailing list for discussions in February about the SMB URL. There was an interesting discussion about Unicode hanlding. The problem of course is that URLs require characters outside of ASCII to be escaped with %HH hex escapes. This is of course not very reasonable with SMB URLs so hex escaping is not required. In practice this should not be a problem because these URLs are not submitted as parameters to text based RPCs like HTTP GET requests. We did reach an important conclusion that would be influential to anyone writing an SMB URL parser. That is, even though SMB URLs do not require Unicode characters be escaped (for practical reasons) they should be able to decode escaped Unicode characters. This begs the question; how do you escape Unicode characters? The prevailing answer appears to be specified in the W3C IRI documents which suggest each escape should be treated as a byte in a UTF-8 multibyte sequence. Otherwise, the SMB URL is reasonably well defined. Unicode handling was the only remaining issue I believe. The jCIFS client implements all of this functionality minus the decoding of escaped UTF-8 sequences. Please join the jCIFS mailing list if you have specific questions. We have had many interesting discussions there about the SMB URL, we have implemented it completely, and there are three people who understand it quite well. Chris and Eric have the brains. Me type. I'm not familiar with the state of the libsmbclient SMB URL handling. Mike -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived.
SMB URL
Hi! I looked into the URL handling libsmbclient is doing and it's lacking quite some of the stuff that the DRAFT specifies (and some of the stuff that generally are required for URIs). Is someone working on that? I'm currently preparing some patches, but hate C programming enough to dump it for some other solution :) Greetings, Stephan
