On Fri, 2010-11-05 at 21:51 +0000, Bryan Burgin wrote: > Hi Andrew. > > Is the absence of the Windows-specific variable names blocking your > development?
Yes, in a way. The behaviour of these items is not well documented here, but is elsewhere, but without the constant values. Using the correct names allows us to tie in different sources of information. > There may be push back to do so since this is in the normative section > of the document. I agree that it seems like a helpful suggestion. Is > there an argument I can present on your behalf to show a reason that > doing so is required to implement the protocol. > > As for adding the hex values, I'm prepared to make that request. Frankly, I don't understand why the name cannot be included, as it is in so many other places? For example, MS-SAMR 2.2.1.12 USER_ACCOUNT Codes Given that the fundamental purpose of these documents is to help, rather than hinder, the development of interoperable implementations, what is the argument against including the normative and traditional names for the bits? On the same argument you could rewrite the IDL to be a series of 'member1, member2', with verbose descriptions but no rational names. Using common, existing names helps developers achieve interoperability because it enables clear and effective communication between all the parties, including in particular parties that have had to rely on other Microsoft documents released before and alongside the WSPP program, and therefore should form part of the normative description of the protocol. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
