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