Andrew,

Thank you for the feedback.  I wanted to provide you with a status update at 
this time.  We have completed our investigation and will be updating the 
documentation to reflect that NRPC allows RPC to negotiate the endianess on 
fields with the exception of a subset of byte arrays which NRPC handles 
explicitly.  We will keep the identifying text for those fields in which NRPC 
explicitly sets the endianess.  We are working to correct the documentation at 
this time and once the final changes are complete I will send you the updated 
NRPC documentation.  Please let us know if you have any further 
comments/questions.

Richard Guthrie
Support Escalation Engineer
Open Protocols Support Team
Tel: +1 (469) 775-7794
E-mail: [email protected] 

-----Original Message-----
From: Andrew Bartlett [mailto:[email protected]] 
Sent: Wednesday, April 15, 2009 7:13 AM
To: Interoperability Documentation Help
Cc: [email protected]; [email protected]
Subject: erroneous references to little-endian

Before many (but oddly, not all) of the impossible-to-parse bitfield diagrams 
in MS-NRPC is the statement:

> A set of bit flags in little-endian format ... A flag is TRUE (or set) 
> if its value is equal to 1. The value is constructed from zero or more bit 
> flags from the following table.

(search for little-endian)

These refer to bitfields are transferred over DCE/RPC, and as such are in 
negotiated bit order, as chosen by the client and server.  Therefore the 
reference to their bit order should be removed.  (This is doubly confusing 
because the table itself is in bit-endian order. :-)

There are exceptions where the use is actually correct - the IP address and 
credentials calculations, or in conjunction with non-RPC structures, but the 
rest appear to be a copy-and-pasted template reproduced though the entire 
document.

Can you please review this (and other RPC protocols) to ensure that these 
references are corrected?

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com

_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol

Reply via email to