Andrew, Your response “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” was helpful. I filed a request with the documentation group to consider your feedback. Attached is a mock-up of [MS-NRPC] 2.2.1.4.15 NETLOGON_LOGON_IDENTITY_INFO’s ParameterControl I provided them to illustrate your request.
I will update you when I get a response from the PG. Since this is documentation feedback, I intend to close this incident if I properly captured your request. Bryan -----Original Message----- From: Andrew Bartlett [mailto:[email protected]] Sent: Friday, November 05, 2010 3:04 PM To: Bryan Burgin Cc: [email protected]; MSSolve Case Email Subject: RE: [REG:110110481276509] Please include bitfield names in MS-NRPC LogonParameters 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.
ParameterControlMockup.docx
Description: ParameterControlMockup.docx
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
