Consolidated List of All CIFS Spec Feedback

[Andrea Westerinen]

Attached is the latest list of CIFS Spec comments and feedback.  Updated
items are 2a and 52.  53 is closed.  54 is new.

Also, 2a references another text file, CIFS-UndefinedTerms.txt - that is
also attached.  (Thanks to Paul Popelka from Veritas for pulling this list
of terms together.)

Andrea

-------------- next part --------------
Comments on the CIFS Specification
March 8, 2000

Item Format:
Ref# - Requested Change
<Blank Line>
Type of Change - Status, "Assigned To"

1) Need information on Windows 95 through Windows 2000 - perhaps in an Appendix.  
For example,
a) In SMB_COM_SEARCH and SMB_COM_QUERY_ INFORMATION, the Windows 95 client will 
sometimes give a null pathname.  Is this legal, and if so, what are the intended 
semantics?
b) Description of a number of messages missing - These are used by Windows 95 
under certain conditions (i.e. the Write SMB is still used by all Microsoft clients 
to set the file length).

Additional Information - Open, Microsoft

2) Need descriptions and permissible values for all fields 

Clarification - Open, Microsoft

2a) Make sure that the document defines/explains all  opcodes, constructs, etc.  
For example, the smb opcode list (at the end of the Spec) lists: SMB_COM_FIND,
SMB_COM_FIND_UNIQUE, SMB_COM_FIND_ NOTIFY_CLOSE, and SMB_COM_CLOSE_AND_ TREE_DISC.  
Yet the body of the document never refers to them.  A list of all "undefined" 
constructs and concepts is contained in the file, CIFS-UndefinedTerms.txt.

Additional Information - Open, Microsoft
Question to ALL - Is the list of opcodes complete?  Mail additions to td at snia.org.

3) Several sections do not have lists of error codes.  For example, Section 4.3.2, 
"Delete Directory", and all the TRANS2_XXX Sections.  Also missing ERRHRD/39 (is this 
"disk full"?)  All error codes (both NT and DOS) should be fully documented (which 
to use when, and what they mean).

Clarification - Open, Microsoft

4) Need guidance about using NT status codes.  There are some cases where the 
relevant status code is reasonably obvious.  But there are many cases where it 
is not.  Here are some important ones:  
- STATUS_NO_SUCH_FILE vs. STATUS_OBJECT_NAME_INVALID vs. STATUS_OBJECT_NAME_
NOT_FOUND for a directory lookup failure.
- STATUS_OBJECT_NAME_EXISTS vs.  STATUS_OBJECT_NAME_ COLLISION for an attempt to 
create a file whose name already exists.

Clarification and Additional Information - Open, Microsoft

5a) Document the mechanisms for getting/setting network share information 
(old protocol) 

Additional Information - Open, Quantum 
NetrShareEnum format available from the book, "DCE/RPC over SMB ...", the
srvsvc chapter

5b) Document the mechanisms for getting/setting network share information 
(through RPC)

Additional Information - Deferred for first release

5c) Document the mechanisms for getting/setting security information (through RPC).  
Need clarification on this question as to which DCE/RPC pipe.  Does this mean 
SamrGetSecObject, LsarGetSecObject, (and set equivs.) or RegretKeySecurity?  
There is essentially one for every single handle-based pipe.

Additional Information - Deferred for first release

6) Questions on "transaction2"s:
a) For find_first and find_next,  what are "resume keys"?
b)  What is the EA size referred to in info-levels? Windows seems to be 
setting it to zero.  Does EA refer to extended attributes which might have been 
defined for a file by a specific implementation and are non-standard?

Clarification - Open, IBM

6a) Please discuss searchids and resume keys?  For instance, what is the scope of 
a search id?  Can different processes on the same client use the same one?  
What is contained in a resume key?  Does the client understand its contents?

Clarification - Open, IBM

7) Questions on "string encodings":
a) Is Unicode required?  If not, what are the implications of not supporting Unicode?
b) If all files and folders use ASCII, must an implementation support non-ASCII 
encodings?

Clarification - Open, NetApp

8) Increase/improve the documentation for CIFS using TCP transport (Appendix B).  
There are questions wrt how SMB frame length is specified and how multiple sessions 
are handled when the client's NETBIOS name is not passed.

Additional Information - Open, Microsoft
Question to ALL - What are specific TCP issues?

9) Define a new dialect that explicitly removes OBSOLETE SMB messages - 
In Section 3.15 of the I-D, each dialect introduces new messages w/o getting rid 
of old ones, for backward compatibility. Section 4 seems to contradict this.  
However, it's normally the case that NT or 2000 will negotiate the top-level 
dialects and the top-level CAPABILITIES, and never use the old ones.  This leads 
to weird problems (such as NT trying to set a 64 bit date in a 32 bit field) 
by _not_ negotiating certain SMBs or certain CAPABILITIES.

Addition of Negotiation Info and/or New Dialect - Enhancement, Not worked at this time

10) Mapping of individual functions to releases (Windows, SAMBA, etc.).  Perhaps 
this could be done in an Appendix and is similar to #1, above.

Additional Information - Deferred, New Informational ID 

11) Outline the use of SPNEGO / GSS-API in the CAP_EXTENDED_SECURITY blobs  

Additional Information - Open, Microsoft

12) Outline of how NTLMv1 and NTLMv2 work.  This should likely be a separate 
document, containing annotated examples, showing intermediate calculation stages.

Additional Information - In new draft?  Deferred for first release
One approach is to summarize material in the book, "DCE/RPC over SMB, Samba and 
Windows NT Domain Internals"

13) Outline of how NTLMSSP works, and how it uses 40-bit, 128-bit, key-exchange 
and both sign and seal modes (for BOTH NTLMV1 and NTLMV2).  Again, annotated 
examples needed showing the intermediate calculation stages and the signed/sealed 
traffic, before and after.

Additional Information - In new draft? Deferred for first release  
The book, "DCE/RPC over SMB..." does not address enough.  Sign and seal constants 
for NTLMv2-based NTLMSSP are not discussed.

14) Outline of how NETLOGON, the new 0x400001ff and the new Windows 2000 0x7fff01ff
(or whatever) modes work - ie, "the NETLOGON secure channel"

Additional Information - In new draft? Deferred for first release 
The book, "DCE/RPC over SMB..." is not sufficient since it only describes the 
0x400001ff mode.  Also, its text in this area has not been verified.

15) Specification of how DCE/RPC over SMB works

Additional Information - In new draft? Deferred for first release 
The book, "DCE/RPC over SMB..." is not sufficient since it does not cover how to use
SMBwriteX or SMBtrans+SMBtranssecondary to transfer multiple PDU requests.  Also, 
it does not cover SMBwritebraw, which is only used by win95. 

16) Specification of each of the services that run over DCE/RPC.  Could this be 
done as IDL files?

Additional Information - In new draft? Deferred for first release 
One approach is to summarize material in the book, "DCE/RPC over SMB, Samba and 
Windows NT Domain Internals"

17) Abstract states:  "This document omits discussion of obsolescent requests 
not needed by modern clients. They are defined in a companion document." - But there 
is no companion document.  Also it appears that some flags are reserved for 
obsolescent requests as documented in Section 3.2.2 and 3.2.3.

Additional Information - SNIA to remove sentence as there is no companion doc 
at this time.

18) When I connect via "net use" from an NT client to sambe, I see two messages, 
each with Session-setup-andX/Tree-connect-andX.  In the first message, the session 
setup username is the name of my workstation, and the tree connect pathname is 
\\<samba-host>\IPC$. The Spec mentions that "IPC" is one of the possibilities for 
that field in the reply message, but it doesn't say anything about semantics.  
Can you describe what sort of SMB traffic an "IPC" service is likely to see?  

Clarification - Open, Quantum, Microsoft to explain the scenario

19) Question on CREATE_DIRECTORY and TRANS2_CREATE_DIRECTORY:  If the following is 
sent by an NT client, "mkdir \foo\baz" with Command Extensions enabled, and if foo 
does not exist, an NT server returns STATUS_OBJECT_NAME_NOT_ FOUND.  The NT client 
realizes that its original expectation has not been met and sends two separate 
CREATE_DIRECTORY messages, one specifying "foo" and the next specifying "foo\baz".  
Is the possibility of creating multiple path components with one message part of 
the spec, or just eccentric behavior?  If possible, then it should be documented.  
Also, different error codes are returned from different implementations - this 
relates to #3 above.

Clarification - Open, Microsoft

20) Have greater granularity in the TOC - 3 levels to allow lookup of an individual 
message

Formatting - Fix TOC, SNIA

21) Need consistency in naming of flags in Section 3.2.2 and 3.2.3 between the 
Spec and smbtrace

Consistency of Naming - Open, Microsoft

22) Regarding Section 3.15, it says: "CIFS Clients and servers may exchange the 
following SMB messages if the "PC NETWORK PROGRAM 1.0" dialect is negotiated: ..." 
and "If the "LANMAN 1.0" dialect is negotiated ... etc. ... New messages 
introduced ... are: ..."  

Should it also say:  "If the "NT LM 0.12" dialect is supported, with the CAP_NT_FIND 
capability, the following information levels are introduced for the indicated messages:
    TRANS2_FIND_FIRST2    0x101 through 0x104
    TRANS2_QUERY_FS_INFORMATION 0x102 through 0x105"

And:  "If the "NT LM 0.12" dialect is supported, with the CAP_NT_SMBS capability, 
the following information levels are introduced for the indicated messages, in addition 
to those listed above for CAP_NT_FIND:
    TRANS2_QUERY_PATH_INFORMATION   0x101 through 0x10B
    TRANS2_QUERY_FILE_INFORMATION   same
    TRANS2_SET_PATH_INFORMATION etc.
    etc."

Clarification - Open, Microsoft

23) In Section 3.15, SMB_COM_NT_RENAME is listed, but no such request is listed in 
Section 5.1, "SMB Command Codes."  What does this mean and why is it in Section 3.15?

Clarification - Open, Microsoft

24) It appears that information levels in some SMB requests (such as TRANS2_ FIND_
FIRST2, TRANS2_QUERY_PATH_ INFORMATION, etc.) depend on negotiated dialect.  This 
should be documented and a listing of these is necessary.  Should it go into 
Section 3.15 on "negotiated dialect"?

Additional Information - Open, Microsoft

25) In Section 3.4 (WildCards), it says: "If the negotiated dialect is 'NT LM 0.12' 
or later, and the client requires MS-DOS wildcard matching semantics ..."  What 
alternative matching semantics are there?  How are MS-DOS semantics different from 
others? Should "?" be treated differently from ">", or are they equivalent?  
Likewise for "." and """", and for "*" and "<".

Clarification - Open, Microsoft

26) Time/date fields are SMB_TIME - Some were listed as LARGE_INTEGER. Some of the 
code-paths are not debugged for non NT/NT, Win95/NT and NT/Win95 negotiated SMBs.  
This has resulted in other CIFS vendors sending SMBs with generally-unused-
outside-of-microsoft-clients-and-servers-but-used-by-everyone-else-because-that's-
what'sin-the-spec time/dates.  Or, Win/NT returns 64-bit timestamps in 32-bit fields. 
Where there are "bugs" but these are used/exploited/copied in code, they should be 
documented.

Correction - Fix wording, SNIA / Documentation, Microsoft
Question to ALL - What should be documented for time/date discrepancies and bugs?

26a) When a time value is returned or specified, but a timezone is not specified, 
should the timezone default to local time, server local time, GMT or something else?  
Need documentation on assumptions when the value returned is "Undefined" and in 
corner cases (such as the switch from daylight to standard time).  Additionally, 
what is the expected behavior when a server moves and changes time zones?

Additional Information - Open, Quantum

27) Section 3.8, "Access Mask Encoding" needs the flags - perhaps defined using 
the WINNT.H header file. 

Additional Information - Fix flags from header, Microsoft to send current header file

28) Explain the semantics of CAP_NT_FIND

Additional Information - Open, Microsoft

29) It is claimed that RAW_MODE is obsolescent.  What does this mean when NT clients 
still send raw mode messages?

Clarification - Remove "obsolete", insert "Not recommended" and explain what this 
means, SNIA

30) STATUS_MORE_PROCESSING_REQUEIRED is misspelled /  FILE_PRSISTENT_ACLS is 
misspelled and needs an explanation

Correction and Additional Information - Open, Misspells SNIA, Explanation Microsoft

31) Explain SMB_SUPPORT_SEARCH_BITS

Additional Information - Open, Microsoft

32) Can clients ignore capabilities?  If so, should this be documented in Section 
4.1.2.  For example, it appears that the Win 95 client pays attention to the 
Native File System in the response to Tree Connect And X.  In the earlier response 
to Negotiate, CAP_NT_FIND was specified, but the Win 95 client ignored this 
unless (subsequently) something like "NTFS" or "FAT" was specified in the response.  
(Originally, "AFS" was specified.)  This also relates to #1, above.

Additional Information - Open, Document that you "can not ignore capabilities", SNIA /
Microsoft to explain scenario

33) In Section 4.2.1, the description of CreateDisposition is completely at variance 
with the NT client and server implementation.  A usable description is in the 
documentation of NtCreateFile in the Microsoft DDK.  Also, Name is apparently (in the 
NT client) not null-terminated.  Is this part of the spec?

Consistency and Clarification - Open, Microsoft

34) In Section 4.2.10, explain in detail how wildcarding should work.  Give examples 
such as renaming multiple files and renaming a file to a name with a wildcard in it.

Additional Information and Request for Example - Open, NetApp

34a) Provide pseudo code for mask_match

Additional Information - Open, Microsoft

35) In Section 4.2.13.4 (TRANS2_QUERY_ PATH_INFORMATION) SMB_QUERY_FILE_ BASIC_INFO 
- From sniffing the NT client and server, it is observed that instead of a USHORT 
attributes, the data ended with two longs, of which the first was apparently extended 
attributes, and the second was unknown (always zero).  Servers have to conform to 
the above description, rather than to the CIFS spec, to work with the NT client.

Consistency - Open, Microsoft

35a) Document extended attributes.  Is this used outside of OS/2? 

Additional Information - Open, IBM, 
Question to Microsoft as to use (copying MAC files)

36) In Section 4.2.13.7 (TRANS2_QUERY_ PATH_INFORMATION) SMB_QUERY_FILE_ NAME_INFO 
- Is the whole file name to be used, or just the last component?

Clarification - Open, Microsoft

37) In Section 4.2.13.9 (TRANS2_QUERY_ PATH_INFORMATION) SMB_QUERY_FILE_ ALT_NAME_INFO 
- Clarify that this gets the 8.3 name, given the long name.

Clarification - Open, SNIA

38) In Section 4.2.13.10 (TRANS2_QUERY_ PATH_INFORMATION) SMB_QUERY_FILE_ STREAM_INFO - 
What is an appropriate response to this, if the server does not support streams?

Clarification - Open, Microsoft

39) In Section 4.2.16 TRANS2_SET_FILE_ INFORMATION - There is no description for 
SMB_FILE_BASIC_INFO.  

Additional Information - Open, Microsoft

40) In Section 4.3.3 Check Directory -  What if the path turns out to specify a 
file (non-directory)?  Should ERRDOS/ERRbadpath, STATUS_OBJECT_ PATH_INVALID or 
some other error code be returned?

Clarification - Open, Microsoft

41) Questions from Section 4.3.4 TRANS2_FIND_FIRST2:
a) If the search finds no names, should it return an error code?  NT server returns 
STATUS_NO_SUCH_FILE when responding to the Win 95 client.
b) Resume keys are not used for information levels above (and including) 0x101.
c) There are alignment requirements when responding to an NT client. These should be 
documented.  For example, 
    - The parameter block for the response to SMB_COM_TRANSACTION2 is aligned on a 
short boundary.
    - The data block for the response to SMB_COM_TRANSACTION2 is aligned on a 
longword boundary.
    - For the response to TRANS2_FIND_FIRST2, each individual entry is aligned on 
a longword boundary.

Additional Information - Open, Microsoft

42) In Section 4.3.7 NT_TRANSACT_ NOTIFY_CHANGE - A flow diagram is necessary here. 
What happens if the message is ignored?  It seems that an NT_CANCEL would be sent, 
to which a reply would be sent with "something useful to say", or with STATUS_CANCELED. 
Can the message be rejected (e.g. STATUS_NOT_ IMPLEMENTED)?

Additional Information - Open, Microsoft

43) Questions from Section 5.4 SMB Protocol Dialect Constants:
a) What is the difference between LM1.2X002 and DOS LM1.2X002?  A Win95 client offers 
the latter, the NT client offers the former. How are they different?
b) The text says, "... the server will perform error mapping to appropriate DOS 
errors."  What does this mean?  Should the error codes in Chapter 6 be used?  
c) NT clients do not correctly process DOS status codes under all instances.  
Weird and erratic client-side behavour usually goes away if 32-bit status codes are 
returned instead of DOS ones.  How should this be documented?

Additional Information - Open, Microsoft

44) Clarify the use and operation of Filter Oplock

Additional Information - Closed, Only local FS, not Networked

45) Clarify how bulk reads and writes operate and where and how they are implemented

Additional Information - Closed, Not implemented in any publicly released code

46) Explain how DFS is set on the Server (The current Spec explains how to use DFS 
but not how to set it)

Additional Information - Open, Microsoft

47) Define the type BOOLEAN.  It is referred to in the spec but never defined.  
In some scenarios, a 2 byte BOOLEAN is returned.

Clarification - Open, Microsoft

48) Define how file record locking works.  A focus on lock conflicts, lock beyond 
EOF and other exception cases should be documented.  Behavior may be specified as 
SHOULD/MUST.

Clarification - Open, Microsoft
Question to ALL - What are the exception cases or missing documentation?

49) Looking at DFS traffic, DFS servers respond to NT Get DFS Referral requests 
with an extra blob of 22 bytes that is undocumented. This blob follows the referral 
paths in UNICODE (from the Get DFS Referral reply in the SMB spec). This appears to 
be some sort of verification data, but no information on it is available in the 
Spec.  These bytes appear to be critical to a DFS client accepting the referral and
continuing to speak DFS with the server.

Additional Information - Open, Microsoft

50) Focus on all implementations

Clarification - Initial focus will be for Win95 implementations and newer. Other 
implementations will be documented if information is submitted or in future drafts. 

51) Request for Change - To support responses returning a 32bit status code 
irregardless of server support.  The SMB_FLAGS2 could be set in an individual 
response to indicate that 32bit status codes are returned in THAT response only.  
Currently, it is mandated that 32-bit status codes be ignored by clients, if the 
server says it does not support them in the negotiation phase.  

RFC - Open 

52) Microsoft NT 4 servers in processing the SessionSetup request (when the flag 
CAP_EXTENDED_SECURITY is not set by the client) use the domain name in the field, 
PrimaryDomain - ie, "the client's primary domain." But the use of this field is not 
documented.   It seems that for proper behavior, clients would have to clear this 
field rather than use their logon domain (or they should set the PrimaryDomain 
field to the domain of the server, which was returned in the previous frame ie the 
negotiate protocol response).  This seems counterintuitive, and should be documented.

The NT server appears to try to forward a side authentication request (presumably a 
proprietary RPC call which is unspecified in the CIFS doc) to the domain controller 
for the domain specified.   If the user has logged on to a non-NT domain this session 
setup will fail (since the non-NT domain controller does not understand the 
proprietary RPC call that the NT server is issuing).  This also needs to be documented.  
(It appears that the NetrReqChal, NetrAuth2, NetrSamLogon sequence is using the 
"network" logon info level.  The same proprietary asdce/rpc or msrpc call is used 
for checking against the pdc, too.)

Additional Information - Open - Microsoft 
This ties back to #12 - documentation of NTLMv2.  This would explain why the client's 
domain (which can be the hostname if the user is not logged into a domain) is
used.  Failure to specify the client's domain when generating NTLMv2 challenge-
responses will result in an incorrect response and no users will be verified.

53) Win2000 sends a random password of 0xf0 UNICODE characters in length when 
joining a domain (SamrSetUserInfo - opcode 0x3a, info level 0x18).  Is there a 
limit of 128 [UNICODE] chars on NT passwords?  In any case, it should be clear that 
- at least - 256 unicode-char-length passwords should be supported by NT#/LM# 
generation code.

Clarification - Closed, 0xf0 bytes were sent, which is 0x78 unicode chars, 
which is 120 unicode chars, which is below the 128 unicode char limit.

54) Need to explain why a client that makes use of a reliable service (in this 
case, NetBEUI or NetBT Session Service) would want to timeout at the application 
level. The transport layer will handle reporting errors. The only case where this 
might be meaningful is when talking to a ruined SMB implementation, which just 
discards the SMB request and keeps the connection open. But this seems rare.  
Could the timeout value be infinite by default?

Also, the SMB specification says that any SMB should be responded to immediately 
without blocking at the server, which can't be done in all cases.  And, there are 
a few SMBs, which may (in normal usage) block at the server.   The most obvious 
are those relating to byte range locking.  Then, there are slow SMBs - those that 
most clients will wait forever (without timing out) on - e.g. responses to 
LANMAN RPC ("RAP") requests and SMB IOCTLs requests.  This is a contradiction.

Clarification - Open 
-------------- next part --------------
General
- The document refers to Unicode in many places but doesn't
  define it anywhere or even give a reference to a document
  describing it.

Page 1
- Don't include URLs for web pages they become stale too
  quickly.  For example www.microsoft.com/intdev/cifs
  was non-existent the last time I checked.

Page 2
- The document refers to several other documents which probably
  don't exist.  For example at the top of page 2 there is a
  reference to "Obsolescent SMB Requests".  There should be an
  entry in the References section of this document for each
  document refered to.

Page 14
- In section 2.8 there is a reference to "information on
  authentication" being moved to a "different specification".
  This is really helpful.  How about a title for this
  "different specification" and author and put this info in
  the references section.

Page 15
- Section 3 claims that it describes the entire set of SMB
  commands and response.  Unfortunately it seems that section
  4 really contains this information.

- Section 3.2 defines several variable types used throughout
  the document (like UCHAR USHORT...).  There are other types
  used in the document which don't seem to be defined anywhere.
  The ones I found are WCHAR, STRING, BYTE, UNICODESTRING, and BOOLEAN.  I've
  noticed STRING being used as an array and as a scalar.  I
  think they are intended to mean the same thing in the document,
  but the usage is inconsistent.

Page 16
- The definition of the field SecuritySignature has a comment
  containing the letters MIC.  I'm probably ignorant.  What is
  MIC?

- Section 3.2.1 could you join the C in the word command back
  to the rest of the word.

Page 17
- Sections 3.2.2 and 3.2.3 define the meanings of bit fields
  using 2 different notations.  In one case they refer to
  bit numbers and in the other case they use bit masks.  Can
  they be consistent and do it just one way?  Let's just use
  bit masks.  Can you make the entire document consistent?

Page 19
- Section 3.2.4 claims that a tid of 0xffff in the SMB header
  means no tid is specified.  I have observed that a zero is
  sent.  So, which is it?  Or is it both?

Page 20
- In section 3.2.8 there is a sentence that discusses errors
  returned on the next write or close on a fid that had a
  delayed error.  Can the delayed error only be returned on
  a write or close or can it be returned on the next smb
  that refers to that fid?

Page 22
- Section 3.3 talks about long filenames and short filenames.
  It says that short filenames may not contain certain
  characters but says nothing about what characters are allowed
  in long filenames.  Are there any characters that are not
  allowed in long filenames?

Page 23
- At the end of section 3.4 there is mention of unicode wildcards.
  I don't think the document defines unicode wildcards anywhere.
  Can unicode wildcards be defined?

Page 25
- Section 3.7 defines 5 different kinds of sharing modes but
  nowhere in the document is there a definition of what they
  mean.  It also discusses something called an FCB open that
  is also not discussed in the document.

Page 28
- Section 3.12 mentions an attribute called FILE_ATTR_NORMAL.
  I think they really mean ATTR_NORMAL.  Look in the table
  following the paragraphs.

Page 29
- In the description of NO_BUFFERING there is a reference to
  FILE_FLAG_NO_BUFFERING,  I think they mean NO_BUFFERING.

Page 33
- The command listed in the table on this page should be
  SMB_COM_TRANSACTION2_SECONDARY, not SMB_COM_TRANSACTION_SECONDARY.
  In the description of the Fid field they note that this
  field is only present for an SMB_COM_TRANSACTION2 request.
  Since they deleted the definition of SMB_COM_TRANSACTION
  from this section, this note is no longer necessary.

Page 34
- The section title for section 3.14.2 also contains the
  section number 3.13.2.  This should be removed.
- Section 3.14.2 - the definition of the SMB_COM_NT_TRANSACTION
  request has an extra byte in it.  I don't know which
  one is extra.  The WordCount is supposed to be 19 plus
  the setup count.  If you add up the number of words in
  the message you will find there are 14 words (plus setupcount)
  and then an extra byte (probably Buffer).  Could microsoft
  tell us what this should be?

Page 35
- In the area entitled "Secondary Client Request" please add
  "Command          SMB_COM_NT_TRANSACT_SECONDARY".
- This message description also uses the acronym MBZ.  I know
  what this means but others may not.  Stop using it or
  define it.

Page 40
- Section 3.15 defines which smb requests are valid with which
  negotiated dialect.  What should a server do when request
  does not match the dialect selected?  Abort the connection?
  Return and error?  Which error?

Page 42
- There is a reference to "CIFS Security" document.  What is
  this document?  Why isn't it spelled out in the reference
  section of the specification?

Page 43
- There is a field called MaxNumberVcs in the negotiate response.
  Could you add a section someplace that talks about what a vc
  is?  I think a vc is a virtual circuit.  What does cifs think
  it is and why do we need an upper limit on it?  I realize the
  section (top of page 44) on session setup talks about vcs but
  I still don't understand what they are trying to do.

Page 44
- The description for CAP_LARGE_WRITEX says "The server supports
  large SMB_COM_READ_ANDX".  Yeah right.

Page 51
- The capability CAP_NT_FIND is mentioned but there is no
  explaination.  Define it or remove it.

Page 52
- In section 4.1.3 please describe what should happen to resources
  connected with a SMB_COM_TREE_CONNECT_ANDX when a LOGOFF
  is processed.  Do the trees remain connected?

Page 53
- In section 4.1.4 (TREE_CONNECT_ANDX) the description of the
  Flags field in the message says you can disconnect a tid
  if bit 0 is on.  Yet in the text discussing the message
  it says the Tid field in the client request can be ignored.
  So, why would you disconnect a Tid if it is supposed to
  be ignored?

- In the last paragraph of page 53 there is a reference to a
  "paused" server.  What is a paused server?

Page 55
- Please explain what SMB_SUPPORT_SEARCH_BITS and SMB_SHARE_IS_IN_DFS
  mean.

Page 56
- At the end of section 4.1.5 please tell us what value should
  be placed in the Tid field of the response to a tree disconnect
  request.
- The paragraph at the bottom of the page refers to the
  NtQueryVolumeInformationFile kernel function (library function?).
  Please don't refer to kernel functions.

Page 57
- Sections 4.1.6.1 thru 4.1.6.6 describe what information is
  returned for various TRANS2_QUERY_FS_INFORMATION InformationLevels.
  Sometimes they include names for the fields sometimes they
  don't.  Please be consistent.  Either always provide the field
  names or always omit them.

Page 61
- In section 4.1.7 the description of the ECHO request and
  response describe Buffer as "UCHAR Buffer[1]".  Perhaps
  it would be better to describe Buffer as "UCHAR Buffer[ ByteCount ]".

Page 62
- Section 4.1.8 mentions Sid as being in the fields of the
  NT_CANCEL smb request or smb header.  It isn't.  I don't think Sid
  should be in this paragraph.

Page 63
- In the NT_CREATE_ANDX description could you talk about what
  should be done if the fid in RootDirectoryFid is not contained
  in the share described by the Tid in the smb header of the
  request?

Page 64
- The valid values for the CreateDisposition and ImpersonationLevel
  and SecurityFlags
  fields of the NT_CREATE_ANDX request are only given symbolic
  values, the numeric values are missing.  Put in the numeric
  values.

- In the NT_CREATE_ANDX response, the valid values (and meanings)
  for the FileType and DeviceState fields should be defined.

Page 66
- What is an SD?

- There are definitions for something called "Creation Flag Name".
  Which field of the NT_TRANSACT_CREATE request would someone put
  these values in (CreateOptions?)?

Page 67
- Does the CREATE_TEMPORARY request return just the filename
  (ie the abc portion of \qqq\zzz\rrr\abc)?

Page 68
- Section 4.2.4 talks about a field called MaxCountHigh in the
  READ_ANDX request.  The description says this is the upper
  16 bits of the 32 bit length of data to be read.  32 bit
  read lengths lead to many problems that should be explained.
  For instance the client could attempt to request 256000
  bytes of data which is impossible to fit into a netbios
  message.  Are reads this large disallowed if the transport
  is netbios?  Another problem is the AndxOffset field is
  only 16 bits.  So, if a read andx for 256000 bytes is in
  the middle of an andx chain how do you specify the offset
  to the next response in an andx chain?  The andxoffset field
  is too small to hold an offset of 256000+headers.  And,
  finally the ByteCount field is also only 16 bits so it
  couldn't represent the amount of data following it if there
  is more than 64*1024 bytes of data.
  You need to discuss how these oddities are handled.

Page 69
- Discuss what the DataCompactionMode field of
  the READ_ANDX field is and what its values are?

Page 70
- Section 4.2.5 (WRITE_ANDX) has a field called DataLengthHigh.
  This field is an attempt to write amounts of data larger
  than 64*1024 bytes.  This suffers from the same problems
  I mentioned above under read andx.  Can you please explain
  how these problems are avoided?

Page 71
- What error is returned if the client attempts to issue a
  write andx with large file offset when it hasn't negotiated
  the proper dialect to allow this?

Page 72
- Please define the legal values for the OplockLevel field of
  the LOCKING_ANDX request.

Page 73
- All of the following apply to the locking andx request:
- We've done some experiments here with acquiring file record
  locks against an nt server.  The results seem to indicate
  that one client process can acquire an exclusive lock and
  then another process on the same client using the same fid
  can acquire
  a shared lock on top of the exclusive lock.  This would
  seem to contradict the statement "if any of the specified
  bytes are already locked, the lock will fail" in the spec.
  Are we doing something wrong or is the spec wrong?  In
  any case, once these 2 locks are acquired, you eventually
  must release them.  Which lock is released with the first
  unlock request?  The exclusive lock, the shared lock, or
  both?
- If a locking andx request contains both unlocks and locks,
  which are performed first the unlocks or the locks?
- If you have a locking andx request that contains both
  unlocks and locks and you get an error while acquiring
  the locks (assume the unlocks are done first) in addition
  to releasing the locks that were acquired, must we go back
  and reacquire the unlocks that were released?
- If you have a locking andx containing both unlocks and locks,
  and (assuming the unlocks are done first) one of the unlocks
  fail (invalid lock range or something), should the server
  ignore the error and continue releasing locks and then
  acquire new locks?  Or, should it reacquire the unlocked
  locks and return an error?
- Does the LOCKING_ANDX_CANCEL_LOCK option of locking andx
  work on any waiting lock attempt (like LOCK_BYTE_RANGE or
  LOCK_AND_READ) or just on locking andx lock attempts?
- Does the server respond to a LOCKING_ANDX_CANCEL_LOCK
  request in addition to responding to the canceled locking andx?
  What error code should be returned in the LOCKING_ANDX_CANCEL_LOCK
  response (assuming there is one) if the locking andx request to
  be canceled could not be found (because it had completed)?
  What error code should be returned in the response to a
  canceled locking andx?
- When would you use a LOCKING_ANDX_CANCEL_LOCK to cancel a
  lock request and when would you use an NT_CANCEL to cancel a
  lock request?

Page 74
- Section 4.2.6.1 oplocks, In the oplock break request the
  server sends to a client to have and oplock broken, is the
  Flags/SMB_FLAGS_SERVER_RESP bit in the smb header set or clear?

Page 75
- The first paragraph on the page refers to "the optional
  second protocol".  What is this?

Page 84
- Section 4.2.13.3, states that an error is returned if the
  filename syntax is incorrect.  What error?

Page 86
- The definition of the data block for SMB_QUERY_FILE_ALL_INFO
  contains "LARGE_INTEGER Index Number" twice.  Is it really
  there twice?  Can you remove the blank from the symbolname?

Page 87
- All of the flag values have the first letter missing from
  their symbolic names.  "ILE*" should be "FILE*".  "ELETE"
  should be "DELETE".  "EAD*" should be "READ*".  "RITE*"
  should be "WRITE*".  "YNCH*" should be "SYNCH*".

Page 89
- Section 4.2.13.9,  could you explain what a SMB_QEURY_FILE_ALT_NAME_INFO
  does?
- Section 4.2.13.10 and 4.2.13.11, please explain what these do too?

Page 93
- Please describe the format of the data sent for a
  TRANS2_SET_FILE_INFORMATION request with an InformationLevel
  of SMB_SET_FILE_BASIC_INFO.
- There is a reference to NT_SET_PATH_INFORMATION.  Should this
  really be TRANS2_SET_PATH_INFORMATION?

Page 95
- Section 4.3.3, the text refers to the symbol SMB_ERR_BAD_PATH.
  Where is its value defined?

Page 96
- Section 4.3.4, please define the allowable values and thier
  meanings for the SearchAttributes and SearchStorageType fields
  of the TRANS2_FIND_FIRST request parameter block.

Page 99
- Section 4.3.4.4 and 4.3.4.5, please define what FileIndex is.

Page 104
- The structure definition for FILE_NOTIFY_INFORMATION contains
  a field whose type is WCHAR.  Should this be UNICODESTRING or
  STRING or define what a WCHAR is and how it is different from
  STRING or UNICODESTRING.

Page 105
- There is a reference to a type called UNICODESTRINGE, perhaps
  they meant UNICODESTRING.

Page 109
- Section 4.5.2, don't refer to nt kernel functions.
  NtQuerySecurityObject().  Define what data structures it returns.