"Michael B.Allen" wrote: > > On Tue, 30 Jul 2002 18:58:16 +1000 > Andrew Bartlett <[EMAIL PROTECTED]> wrote: > > > "Michael B.Allen" wrote: > > > > > > Don't you think it's kind of funny that Leach and Naik aren't even > > > mentioned in the acknowledgements? And they put a Copyright 2001, 2002 SNIA > > > in there? This document is a big turd. There are major grammatical errors, > > > technical inaccuracies, and huge holes that aren't even mentioned (what's > > > the number of seconds between 1601 and 1970 again?). How about this gem on > > > page 1: > > > > > > "Adoption of a common file sharing protocol having modern semantics > > > such as shared files, byte-range locking, coherent caching, change > > > notification, replicated storage, etc. would provide important benifits > > > to the Internet community." > > > > Unfortunetly the politics SNIA require its current status as a 'proposed > > standard', but anyway. > > > > > What a load of crap! Who's going to run a CIFS server on the internet? DCE > > > on top of Transactions on top of SMB in front of empty 4 byte NetBIOS > > > headers? No thanks! Don't you think it would be worth mentioning that > > > SMB_COM_COPY doesn't even work? There's *nothing* about DCE/RPC in here > > > except for some incomprehensible banter about PDUs. > > > > Much as we would like to have DCE/RPC documented, it's a lot of work. > > So why confuse the Transactions section with some awkward bit about PDUs? I > can't believe there isn't someone out there that could write a nice little > intro about DCE/RPC. And the other bit about Transactions is from an old > leach draft. They (leach) got the IETF version number mixed up. This was > discussed on MS CIFS list but I guess no one from the WG was listening.
Well, I think the lack of RPC stuff is more becouse MS doesn't want it documented in anything they are associated with - and those involved are still trying to keep MS in the process. > > > The only stuff that's > > > accurate is the original Leach/Naik content. > > > > My understanding is that even that isn't too flash. > > Sure it has it's little inconsistencies. Unicode is hosed in info level > 0x105's, Unicode is seriously screwed between Win98 and NT (e.g. short > names in TRANS2_FIND_FIRST/NEXT), and so on but these are exactly the > things I hoped would be sorted out. The new content in the SNIA doc is just > not reality. Someone was seriously in denial. The part about "Protocol > version negotiation"? How many servers do you think actually make decisions > based on what dialect is negotiated? Probably Windows and that's it because > the code was there already. But there are enough incompatabilities between > servers that new dialects are warranted. Why isn't there as "NT LM 0.12 > WIN98"? There needs to be some emperical analysis before a "standard" can > be drafted. Sorry, I don't quite see what you mean. Samba certainly uses the agreed dialect to determine many things - in particular the provision of NT1 only SessionSetup etc. Sure, there should be new dialects - but until MS starts matching on the *protocol strings* there isn't any point 'defining' a new dialect. An addition to the document explaining what packets particular clients/server can/will exchange would be a useful improvement. > > > The few corrections I > > > submitted have not been fixed so why bother to contibute anything? This > > > document is an excuse for the different shadowy clicks to get their little > > > two-bit extensions in. And the funny thing is the extensions will never be > > > implemented by Windows servers so they're nearly pointless. > > > > Nearly, but not quite. Such extenstions do exist, and they may as well > > be publicly documented - not everybody runs windows, and sometimes the > > extenstions provide some quite useful features. Samba->Samba > > connections are quite common on small networks trying to avoid the > > perils of NFS for example. > > I find it hard to believe NFS is that much worse. It's the user/host authenticated bit that gets poeple. > > > I wish someone > > > would do a real analysis and write some practical documentation. > > > > A volenteer! Great! I'll see what help I can be, but you might want to > > This is such a crappy argument. I file this one with the "if you don't like > it, submit a patch" argument. If someone writes some code that does X, the > chances of someone else, possibly much more capable, of also writing code > to do X decreases greatly. So now the SNIA comes up with a crappy document > (nice formatting; too bad it's a MS Word doc) and another group that might > have formed a real working group that would turn out to do some good > research, generate dependency graphs, maintain a bug database, etc has now > gone off and done something else instead. So? But this is the document the CIFS community is working with - and it really is the best we have - despite its' defficiencies. As to 'why SNIA'? Well, SNIA puts on the annual CIFS conference, and MS is a member. Given the need for MS participation in an forum that seriously attempts to document the protocol, and the need for a vender neutral body, I can certainly understand SNIA's role > > give Chris's site a look - his online book is a very worthwhile read: > > > > http://www.ubiqx.org/cifs/index.html > > I'm very familar with this work. I'm excited to see Chris has moved past > NetBIOS and I try to help him and encourage him to document the quirks like > his interest in mappings of NT and DOS error/status codes. Just yesterday I > helped clairify UTF-16 vs. UCS-2LE. Guess what the SNIA docs says about > character encoding? Putting a UTF-16 CIFS server on the Internet sounds > like a great idea. Chis was chasing the UTF-16 issue becouse I flagged it with him. Chris does a very good job keeping on top of these 'little details'. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
