SNIA CIFS TR
Andrew Bartlett
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
--
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
mailing list