Christopher R. Hertel crh at
Tue Jul 30 09:02:02 GMT 2002

    Mike: I share your frustration, but I also know how much work went 
          into getting the doc where it is.  Send me comments and I'll 
          collect them.  There will be a workgroup meeting at the CIFS 
          conference and, as far as I know, the #1 agenda item is work
          toward a V2 version of the doc.

Abartlet: Mike is the lead coder for jCIFS.  He and I work together quite 
          a lot.  He has more than his fair share of clue.

    Mike: Abartlet is the Samba Team's authorization guru.  I've been 
          digging at him for answers on NTLMv2 and SPNEGO and such.  He 
          also has more than his fair share of clue.

I'm glad you two have met.  :)  I should mention that my first experience
with the Samba Team was a flame war.  Not that this is anything like a's a good, heated discussion.  I like that.

On Tue, Jul 30, 2002 at 08:24:48PM +1000, Andrew Bartlett wrote:
> "Michael B.Allen" wrote:
> > 
> > On Tue, 30 Jul 2002 18:58:16 +1000
> > Andrew Bartlett <abartlet at> 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? 

Microsoft was on the Workgroup.  I believe that was done by request, but
you're right that Leach and Naik deserve credit.

I'll mention that I e'mailed Naik to get permission to include the expired 
draft in the printed version of my book, but did not hear back.  Dang.

> > > > This document is a big turd. There are major grammatical errors,

Yes.  These need to be fixed.  Abartlet and I, among others, have already 
started sending in corrections.

> > > > technical inaccuracies, and huge holes that aren't even mentioned
> > > > (what's the  number of seconds between 1601 and 1970 again?). How

Yep.  A lot of this needs to be filled in.  (BTW, if someone has that
number please let me know so that I can include it in my book.)

> > > > 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.

Actually, that's changed (long story).  It's not a proposed standard any
more.  For the same reasons you cite, it's now a Technical Reference.  
This has been brought to the attention of the current keeper of the doc.

That blurb above probably dates back to the motivation that drove
Microsoft to publish an Internet Draft in the first place:  competition
with WebNFS.

> > > > 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?

Oooh.. Interesting.  Is there code to test this?  :)

> > > >  There's *nothing* about DCE/RPC in here
> > > > except  for  some incomprehensible banter about PDUs.

Yes.  This is a known and major problem with SMB/CIFS.

> > > 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. the SNIA doc is based on the wrong version of the Leach/Naik draft, 
do I follow correctly?

> 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.

Okay, this has me interested.  You're saying that the dialect string has
little impact on the behavior of the server... is that right?  From what I
can see, the best bet for new client code (and what Mike does in jCIFS) is
to limit the client to NT LM 0.12, and work out the quirks within that.
OS/2, DOS, and WfWG 3.11 servers would not be usable, but that's a 
dwindling set of systems nowdays.

> > > > The  few  corrections  I
> > > > submitted  have  not  been  fixed so why bother to contibute anything?

Get them to me and I'll keep track of the list, and see what I can get 
done.  The source of the doc is MS-Word, which is a problem, but I can 
work with the workgroup on changes.

> > > > 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.

Yes, the Unix extensions are actually worth-while.  I think that the Mac 
extensions should be reviewed too.  Dave is popular product, and Apple 
have their own implementation now (though I'm not sure if it would want 
Unix extensions, Mac extensions, or both).

> > I find it hard to believe NFS is that much worse.
> It's the user/host authenticated bit that gets poeple.

That's an interesting point that has been intriguing me for a while.  NFS
expects that its "shares" will be mounted on the client by root, and that
(the client being a multi-user system) system-wide access rules will
apply.  CIFS assumes that shares will be accessed by the user.  A 
different paradigm.

> > > > 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.

Andrew:  There was talk at the last CIFS conference about putting up a
"wiki" (sp?) for comments on the document.  Do you know what happened to
that?  I think that such a thing is exactly what we need.  I see Mike's 
point, that it can be frustrating to try and get changes made.  I'm 
involved with the workgroup and I can see all of the machinery churning, 
so I suppose I'm not as surprised that changes take time.

> 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

...and there is the chance to comment outside the SNIA.  I really would 
like to have that wiki thing...

> > > give Chris's site a look - his online book is a very worthwhile read:
> > >
> > >
> > 
> > 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'.

You two, along with Tridge, are probably my top resources right

Chris -)-----

Samba Team --     -)-----   Christopher R. Hertel
jCIFS Team --   -)-----   ubiqx development, uninq.
ubiqx Team --     -)-----   crh at
OnLineBook --    -)-----   crh at

More information about the samba-technical mailing list