[cifs-protocol] [REG:110110481276509] Please include bitfield names in MS-NRPC LogonParameters

Bryan Burgin bburgin at microsoft.com
Tue Nov 9 16:27:37 MST 2010


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:abartlet at samba.org] 
Sent: Friday, November 05, 2010 3:04 PM
To: Bryan Burgin
Cc: cifs-protocol at samba.org; 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ParameterControlMockup.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 17830 bytes
Desc: ParameterControlMockup.docx
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20101109/da1869c6/attachment-0001.bin>


More information about the cifs-protocol mailing list