Consolidated List of All CIFS Spec Feedback

Andrea Westerinen andreawest at mindspring.com
Wed Feb 16 08:43:00 GMT 2000


Here is the latest list of CIFS Spec comments and assigments.  New items are
2a, 6a, 26a, 47, 48 and 49. Two items were closed (44 and 45), and some
items' text was updated to be clearer and/or broader.

At this time, I am reformatting the "Dec 1997" Internet-Draft into a Word
document (I know that this doesn't work in vi, but Word is useful to track
revisions, etc).  I will be highlighting where new text goes, getting 3
levels of TOC, etc.  When in a little better shape, I will re-format/re-flow
to txt and mail it out.

Thanks.
Andrea

-------------- next part --------------
Comments on the CIFS Specification

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

Clarification - Open, New
 
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.  Actually 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

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)

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, New

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)

Additional Information - Open, Microsoft

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, Recommend new, separate 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,
One approach is to summarize material in the book, "DCE/RPC over SMB, Samba and 
Windows NT Domain Internals"

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,
One approach is to summarize material in the book, "DCE/RPC over SMB, Samba and 
Windows NT Domain Internals"

15) Specification of how DCE/RPC over SMB works

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"

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 - Remove sentence, No companion doc at this time, SNIA

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

Correction - Fix wording, SNIA

26a) When a time value is returned or specified, but a timezone is not 
specified, should default to local time, server local time, GMT or 
something else? 

Clarification - Open, New

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 what it 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

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 
(Is it used when 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?

Additional Information - Open, Microsoft

44) Clarify the use and operation of Filter Oplock

Closed - Only local FS, not Networked

45) Clarify how bulk reads and writes operate and where and how they are implemented
 
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.  
It was defined in an older copy of the Spec.

Clarification - Open, New

48) Define how file record locking works.

Clarification - Open, New

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, New








More information about the samba-technical mailing list