SNIA CIFS TR
abartlet at samba.org
Tue Jul 30 03:27:01 GMT 2002
"Michael B.Allen" wrote:
> On Tue, 30 Jul 2002 18:58:16 +1000
> Andrew Bartlett <abartlet at samba.org> 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 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team abartlet at samba.org
Student Network Administrator, Hawker College abartlet at hawkerc.net
http://samba.org http://build.samba.org http://hawkerc.net
More information about the samba-technical