RE: erroneous references to little-endian

[Richard Guthrie-3]

Andrew,

We have completed our investigation and have updated the documentation to remove references that specify a parameter as little endian where the values endianess is negotiated by the underlying RPC protocol as we discussed previously.  Here is the list of fields in which the endianess text was removed:

2.2.1.3.1   NL_AUTH_MESSAGE - MessageType
2.2.1.3.1   NL_AUTH_MESSAGE - Flags
2.2.1.3.6   NETLOGON_WORKSTATION_INFO - WorkstationFlags
2.2.1.3.11   NETLOGON_DOMAIN_INFO - WorkstationFlags
2.2.1.4.15   NETLOGON_LOGON_IDENTITY_INFO -Control
2.2.1.5.3   NETLOGON_DELTA_ACCOUNTS - PrivilegeControl
2.2.1.5.3   NETLOGON_DELTA_ACCOUNTS - PrivilegeAttributes
2.2.1.5.3   NETLOGON_DELTA_ACCOUNTS - SystemAccessFlags
2.2.1.5.13   NETLOGON_DELTA_GROUP - Attributes
2.2.1.5.15   NLPR_USER_PRIVATE_INFO - DataType
2.2.1.5.15   NLPR_USER_PRIVATE_INFO - LmLength
2.2.1.5.15   NLPR_USER_PRIVATE_INFO - NtLength
2.2.1.5.15   NLPR_USER_PRIVATE_INFO - LmHistoryLength
2.2.1.5.15   NLPR_USER_PRIVATE_INFO - NtHistoryLength
2.2.1.6.2   DS_DOMAIN_TRUSTSW - Flags
2.2.1.6.2   DS_DOMAIN_TRUSTSW - TrustType
2.2.1.6.2   DS_DOMAIN_TRUSTSW - TrustAttributes
2.2.1.7.2   NETLOGON_INFO_1 - netlog1_flags
2.2.1.7.3   NETLOGON_INFO_2 - netlog2_flags
3.5.4.2.1   DsrGetDcNameEx2 (Opnum 34) - AllowableAccountControlBits
3.5.4.2.1   DsrGetDcNameEx2 (Opnum 34) - Flags
3.5.4.4.1   NetrLogonSamLogonEx (Opnum 39) - ExtraFlags
3.5.4.4.2   NetrLogonSamLogonWithFlags (Opnum 45) - ExtraFlags
3.5.4.5.4   NetrDatabaseRedo (Opnum 17) - Flags
3.5.4.6.1   DsrEnumerateDomainTrusts (Opnum 40) - Flags
3.5.4.6.5   DsrGetForestTrustInformation (Opnum 43) - Flags
3.5.4.7.5   NetrLogonSetServiceBits (Opnum 22) - ServiceBitsOfInterest
3.5.4.7.5   NetrLogonSetServiceBits (Opnum 22) - ServiceBits

A future documentation release should contain these changes.  Please let us know if you have any further questions/comments.

Richard Guthrie
Support Escalation Engineer
Open Protocols Support Team
http://blogs.msdn.com/OpenSpecification 
Tel: [phone]
E-mail: rguthrie@...



-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Wednesday, April 15, 2009 7:13 AM
To: Interoperability Documentation Help
Cc: pfif@...; cifs-protocol@...
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
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Thu, 2009-05-28 at 06:03 -0700, Richard Guthrie wrote:
> Andrew,
>
> We have completed our investigation and have updated the documentation
> to remove references that specify a parameter as little endian where
> the values endianess is negotiated by the underlying RPC protocol as
> we discussed previously.  Here is the list of fields in which the endianess text was removed:

Thankyou.  

However, have you made investigations to see if this has occurred in any
other protocols?  

For example, MS-ADTS 7.3.1.1 continues the fine tradition of claiming to
present a bit table in little endian, but it is actually big-endian (and
is an integer string on LDAP, and little-endian in the NBT netlogon
dgram 7.3.1.4).

Andrew Bartlett

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


_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Bill Wesse]

Good morning Andrew! I have created case SRX090529600007 against [MS-ADTS]. My colleague Richard Guthrie will be your contact for this, and will contact you shortly.

Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  [phone]
CELL: [phone]
FAX:  [phone]


-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Thursday, May 28, 2009 9:39 PM
To: Richard Guthrie
Cc: Interoperability Documentation Help; pfif@...; cifs-protocol@...
Subject: RE: erroneous references to little-endian

On Thu, 2009-05-28 at 06:03 -0700, Richard Guthrie wrote:
> Andrew,
>
> We have completed our investigation and have updated the documentation
> to remove references that specify a parameter as little endian where
> the values endianess is negotiated by the underlying RPC protocol as
> we discussed previously.  Here is the list of fields in which the endianess text was removed:

Thankyou.  

However, have you made investigations to see if this has occurred in any other protocols?  

For example, MS-ADTS 7.3.1.1 continues the fine tradition of claiming to present a bit table in little endian, but it is actually big-endian (and is an integer string on LDAP, and little-endian in the NBT netlogon dgram 7.3.1.4).

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Richard Guthrie-3]

Andrew,

Thank you for the feedback.  We wanted to complete the NRPC investigation prior to looking at this issue from a broader perspective.  We will be working with the product teams to look for any further inconsistencies moving forward.  In the meantime, if you find any further inconsistencies, please feel free to forward them and we will investigate.  I will let you know the results of my investigation shortly with regard to your issue below.

Also, I will be on vacation next week so my teammate John Dunning will be working with you regarding this issue.

Richard Guthrie
Support Escalation Engineer
Open Protocols Support Team
http://blogs.msdn.com/OpenSpecification 
Tel: [phone]
E-mail: rguthrie@...

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Thursday, May 28, 2009 8:39 PM
To: Richard Guthrie
Cc: Interoperability Documentation Help; pfif@...; cifs-protocol@...
Subject: RE: erroneous references to little-endian

On Thu, 2009-05-28 at 06:03 -0700, Richard Guthrie wrote:
> Andrew,
>
> We have completed our investigation and have updated the documentation
> to remove references that specify a parameter as little endian where
> the values endianess is negotiated by the underlying RPC protocol as
> we discussed previously.  Here is the list of fields in which the endianess text was removed:

Thankyou.  

However, have you made investigations to see if this has occurred in any other protocols?  

For example, MS-ADTS 7.3.1.1 continues the fine tradition of claiming to present a bit table in little endian, but it is actually big-endian (and is an integer string on LDAP, and little-endian in the NBT netlogon dgram 7.3.1.4).

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Richard Guthrie-3]

Andrew,

Thank you for the feedback.  In Section 7.3.1.1, the NETLOGON_NT_VERSION options bit table is indeed presented in little-endian byte ordering with the lowest order byte being represented by bits 0-7, the next higher byte represented by bits 8-15 and so on. Therefore the claim that the bit table is presented in little-endian format is correct. We have verified this for other bit fields in [MS-ADTS] as well. The explicit specification of whether the bytes are ordered in little-endian or big endian format is intended to clarify the relative position of the bytes in a multi-byte bit flag.

The NETLOGON_NT_VERSION options is not represented as an integer string over LDAP. It may appear in the LDAP search filter of an LDAP ping (Section 7.3.3) as a binary encoded value or it appears in an LDAP response to an LDAP ping (Section 7.3.3.2) where it is packed as part of one of the following (in little-endian format): NETLOGON_PRIMARY_RESPONSE (described in Section 7.3.1.5), NETLOGON_SAM_LOGON_RESPONSE_NT40 (Section 7.3.1.7), NETLOGON_SAM_LOGON_RESPONSE (Section 7.3.1.8), or NETLOGON_SAM_LOGON_RESPONSE_EX (Section 7.3.1.9).  Please let us know if you have any further questions/feedback.

Richard Guthrie
Support Escalation Engineer
Open Protocols Support Team
Tel: [phone]
E-mail: rguthrie@...  

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Thursday, May 28, 2009 8:39 PM
To: Richard Guthrie
Cc: Interoperability Documentation Help; pfif@...; cifs-protocol@...
Subject: RE: erroneous references to little-endian

On Thu, 2009-05-28 at 06:03 -0700, Richard Guthrie wrote:
> Andrew,
>
> We have completed our investigation and have updated the documentation
> to remove references that specify a parameter as little endian where
> the values endianess is negotiated by the underlying RPC protocol as
> we discussed previously.  Here is the list of fields in which the endianess text was removed:

Thankyou.  

However, have you made investigations to see if this has occurred in any other protocols?  

For example, MS-ADTS 7.3.1.1 continues the fine tradition of claiming to present a bit table in little endian, but it is actually big-endian (and is an integer string on LDAP, and little-endian in the NBT netlogon dgram 7.3.1.4).

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Richard Guthrie-3]

Andrew,

I wanted to confirm that the information below resolves your issue.  If I don't hear from you by Wednesday of next week I will go ahead and archive this issue.

Richard Guthrie
Support Escalation Engineer
Open Protocols Support Team
http://blogs.msdn.com/OpenSpecification 
Tel: [phone]
E-mail: rguthrie@...



-----Original Message-----
From: Richard Guthrie
Sent: Tuesday, June 16, 2009 3:22 PM
To: Andrew Bartlett
Cc: Interoperability Documentation Help; pfif@...; cifs-protocol@...
Subject: RE: erroneous references to little-endian

Andrew,

Thank you for the feedback.  In Section 7.3.1.1, the NETLOGON_NT_VERSION options bit table is indeed presented in little-endian byte ordering with the lowest order byte being represented by bits 0-7, the next higher byte represented by bits 8-15 and so on. Therefore the claim that the bit table is presented in little-endian format is correct. We have verified this for other bit fields in [MS-ADTS] as well. The explicit specification of whether the bytes are ordered in little-endian or big endian format is intended to clarify the relative position of the bytes in a multi-byte bit flag.

The NETLOGON_NT_VERSION options is not represented as an integer string over LDAP. It may appear in the LDAP search filter of an LDAP ping (Section 7.3.3) as a binary encoded value or it appears in an LDAP response to an LDAP ping (Section 7.3.3.2) where it is packed as part of one of the following (in little-endian format): NETLOGON_PRIMARY_RESPONSE (described in Section 7.3.1.5), NETLOGON_SAM_LOGON_RESPONSE_NT40 (Section 7.3.1.7), NETLOGON_SAM_LOGON_RESPONSE (Section 7.3.1.8), or NETLOGON_SAM_LOGON_RESPONSE_EX (Section 7.3.1.9).  Please let us know if you have any further questions/feedback.

Richard Guthrie
Support Escalation Engineer
Open Protocols Support Team
Tel: [phone]
E-mail: rguthrie@...  

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Thursday, May 28, 2009 8:39 PM
To: Richard Guthrie
Cc: Interoperability Documentation Help; pfif@...; cifs-protocol@...
Subject: RE: erroneous references to little-endian

On Thu, 2009-05-28 at 06:03 -0700, Richard Guthrie wrote:
> Andrew,
>
> We have completed our investigation and have updated the documentation
> to remove references that specify a parameter as little endian where
> the values endianess is negotiated by the underlying RPC protocol as
> we discussed previously.  Here is the list of fields in which the endianess text was removed:

Thankyou.  

However, have you made investigations to see if this has occurred in any other protocols?  

For example, MS-ADTS 7.3.1.1 continues the fine tradition of claiming to present a bit table in little endian, but it is actually big-endian (and is an integer string on LDAP, and little-endian in the NBT netlogon dgram 7.3.1.4).

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Fri, 2009-06-19 at 07:40 -0700, Richard Guthrie wrote:
> Andrew,
>
> I wanted to confirm that the information below resolves your issue.  If I don't hear from you by Wednesday of next week I will go ahead and archive this issue.

No, it doesn't.  In short, this still feels like a complete mess, and is
only made worse by the tables.  

>
> Thank you for the feedback.  In Section 7.3.1.1, the
> NETLOGON_NT_VERSION options bit table is indeed presented in
> little-endian byte ordering with the lowest order byte being
> represented by bits 0-7, the next higher byte represented by bits 8-15
> and so on. Therefore the claim that the bit table is presented in
> little-endian format is correct. We have verified this for other bit
> fields in [MS-ADTS] as well. The explicit specification of whether the
> bytes are ordered in little-endian or big endian format is intended to
> clarify the relative position of the bytes in a multi-byte bit flag.

Ahh, so the table is self-contradictory and even more useless than
normal.  I should have remembered, as this was one of the most annoying
things I found when first going over this area.

It is *never* valid to present bits in a different order to the bytes.

> The NETLOGON_NT_VERSION options is not represented as an integer
> string over LDAP. It may appear in the LDAP search filter of an LDAP
> ping (Section 7.3.3) as a binary encoded value or it appears in an
> LDAP response to an LDAP ping (Section 7.3.3.2) where it is packed as
> part of one of the following (in little-endian format):
> NETLOGON_PRIMARY_RESPONSE (described in Section 7.3.1.5),
> NETLOGON_SAM_LOGON_RESPONSE_NT40 (Section 7.3.1.7),
> NETLOGON_SAM_LOGON_RESPONSE (Section 7.3.1.8), or
> NETLOGON_SAM_LOGON_RESPONSE_EX (Section 7.3.1.9).  Please let us know
> if you have any further questions/feedback.

I think this is an excellent example of why this documentation fails
spectacularly to communicate these issues, and presents the least
implementable formation for the bit-fields it attempts to describe.

Is is ever actually useful to list bits with a value such that the bit
cannot be represented on the network with the calculation of 2^n = bit
value?

Thanks,

Andrew Bartlett

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


_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Richard Guthrie-3]

Andrew,

We will continue to work to resolution on the broader issue of how to handle bit fields in the documentation.  Your feedback is much appreciated there.  For this specific issue, in general, for custom-marshaled fields you should see a bit field that follows the RFC convention where the high bit of the first byte to hit the wire is in column 0, and the low bit of the last byte to hit the wire is in column 31 (so that the bits are shown from left-to-right in the order they naturally appear over the network). We are going back through the documentation to ensure that custom marshaled fields have the appropriate specification for endianness.

Please let us know if you have any further questions/comments.

Richard Guthrie
Support Escalation Engineer
Open Protocols Support Team
http://blogs.msdn.com/OpenSpecification 
Tel: [phone]
E-mail: rguthrie@...

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet@...]
Sent: Sunday, June 28, 2009 11:56 PM
To: Richard Guthrie
Cc: Interoperability Documentation Help; 'pfif@...'; 'cifs-protocol@...'
Subject: RE: erroneous references to little-endian

On Fri, 2009-06-19 at 07:40 -0700, Richard Guthrie wrote:
> Andrew,
>
> I wanted to confirm that the information below resolves your issue.  If I don't hear from you by Wednesday of next week I will go ahead and archive this issue.

No, it doesn't.  In short, this still feels like a complete mess, and is only made worse by the tables.  

>
> Thank you for the feedback.  In Section 7.3.1.1, the
> NETLOGON_NT_VERSION options bit table is indeed presented in
> little-endian byte ordering with the lowest order byte being
> represented by bits 0-7, the next higher byte represented by bits 8-15
> and so on. Therefore the claim that the bit table is presented in
> little-endian format is correct. We have verified this for other bit
> fields in [MS-ADTS] as well. The explicit specification of whether the
> bytes are ordered in little-endian or big endian format is intended to
> clarify the relative position of the bytes in a multi-byte bit flag.

Ahh, so the table is self-contradictory and even more useless than normal.  I should have remembered, as this was one of the most annoying things I found when first going over this area.

It is *never* valid to present bits in a different order to the bytes.

> The NETLOGON_NT_VERSION options is not represented as an integer
> string over LDAP. It may appear in the LDAP search filter of an LDAP
> ping (Section 7.3.3) as a binary encoded value or it appears in an
> LDAP response to an LDAP ping (Section 7.3.3.2) where it is packed as
> part of one of the following (in little-endian format):
> NETLOGON_PRIMARY_RESPONSE (described in Section 7.3.1.5),
> NETLOGON_SAM_LOGON_RESPONSE_NT40 (Section 7.3.1.7),
> NETLOGON_SAM_LOGON_RESPONSE (Section 7.3.1.8), or
> NETLOGON_SAM_LOGON_RESPONSE_EX (Section 7.3.1.9).  Please let us know
> if you have any further questions/feedback.

I think this is an excellent example of why this documentation fails spectacularly to communicate these issues, and presents the least implementable formation for the bit-fields it attempts to describe.

Is is ever actually useful to list bits with a value such that the bit cannot be represented on the network with the calculation of 2^n = bit value?

Thanks,

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Fri, 2009-07-10 at 09:23 -0700, Richard Guthrie wrote:

> Andrew,
>
> We will continue to work to resolution on the broader issue of how to
> handle bit fields in the documentation.  Your feedback is much
> appreciated there.  For this specific issue, in general, for
> custom-marshaled fields you should see a bit field that follows the
> RFC convention where the high bit of the first byte to hit the wire is
> in column 0, and the low bit of the last byte to hit the wire is in
> column 31 (so that the bits are shown from left-to-right in the order
> they naturally appear over the network).

Your two statements are inconsistent, and not consistent with what the
documentation does.  Do you mean to say that I can expect the above in
future, or that you claim the documentation does the above?

If the bits were numbers, for little-endian numbers, such that bit 0,
representing integer 1 appeared a the left (the little end), and that
the numbers in the heading increased 0..31 left-to-right, above the
value such that for it's natural natural number representation (as
indicated by the stated endianness) that value == n^2, then I would be
happy.

> We are going back through the documentation to ensure that custom
> marshaled fields have the appropriate specification for endianness.

Alternately, can you please point me at the RFC that indicates both bit
numbering such that (value != n^2) where n is the described bit number,
and where bits are ordered in a different order to bytes.  

Microsoft's documentation is the only place, ever, that I have seen this
insanity.

Thanks,


Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Sat, 2009-07-11 at 09:42 +1000, Andrew Bartlett wrote:

> On Fri, 2009-07-10 at 09:23 -0700, Richard Guthrie wrote:
> > Andrew,
> >
> > We will continue to work to resolution on the broader issue of how to
> > handle bit fields in the documentation.  Your feedback is much
> > appreciated there.  For this specific issue, in general, for
> > custom-marshaled fields you should see a bit field that follows the
> > RFC convention where the high bit of the first byte to hit the wire is
> > in column 0, and the low bit of the last byte to hit the wire is in
> > column 31 (so that the bits are shown from left-to-right in the order
> > they naturally appear over the network).
>
> Your two statements are inconsistent, and not consistent with what the
> documentation does.  Do you mean to say that I can expect the above in
> future, or that you claim the documentation does the above?
>
> If the bits were numbers, for little-endian numbers, such that bit 0,
> representing integer 1 appeared a the left (the little end), and that
> the numbers in the heading increased 0..31 left-to-right, above the
> value such that for it's natural natural number representation (as
> indicated by the stated endianness) that value == n^2, then I would be
> happy.
>
> > We are going back through the documentation to ensure that custom
> > marshaled fields have the appropriate specification for endianness.
>
> Alternately, can you please point me at the RFC that indicates both bit
> numbering such that (value != n^2) where n is the described bit number,
> and where bits are ordered in a different order to bytes.  
>
> Microsoft's documentation is the only place, ever, that I have seen this
> insanity.

I'm still unsatisfied with the situation here.  Will there ever be any
progress?

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Hongwei Sun]

Andrew,

  Richard has left our team and I have taken the ownership of this request.  In the last a few weeks, We have been actively working on updating documentation for this broad issue to improve our documentation.  We will finish the update soon.   I will let you know as soon as the detail is finalized.

  We have scheduled a meeting between the Samba team and our documentation team to have more discussion on this issue in the Samba IOLab next month.

Thanks for your patience.

Hongwei

-----Original Message-----
From: cifs-protocol-bounces@... [mailto:cifs-protocol-bounces@...] On Behalf Of Andrew Bartlett
Sent: Monday, August 10, 2009 2:41 AM
To: Richard Guthrie
Cc: 'pfif@...'; 'cifs-protocol@...'
Subject: Re: [cifs-protocol] erroneous references to little-endian

On Sat, 2009-07-11 at 09:42 +1000, Andrew Bartlett wrote:

> On Fri, 2009-07-10 at 09:23 -0700, Richard Guthrie wrote:
> > Andrew,
> >
> > We will continue to work to resolution on the broader issue of how
> > to handle bit fields in the documentation.  Your feedback is much
> > appreciated there.  For this specific issue, in general, for
> > custom-marshaled fields you should see a bit field that follows the
> > RFC convention where the high bit of the first byte to hit the wire
> > is in column 0, and the low bit of the last byte to hit the wire is
> > in column 31 (so that the bits are shown from left-to-right in the
> > order they naturally appear over the network).
>
> Your two statements are inconsistent, and not consistent with what the
> documentation does.  Do you mean to say that I can expect the above in
> future, or that you claim the documentation does the above?
>
> If the bits were numbers, for little-endian numbers, such that bit 0,
> representing integer 1 appeared a the left (the little end), and that
> the numbers in the heading increased 0..31 left-to-right, above the
> value such that for it's natural natural number representation (as
> indicated by the stated endianness) that value == n^2, then I would be
> happy.
>
> > We are going back through the documentation to ensure that custom
> > marshaled fields have the appropriate specification for endianness.
>
> Alternately, can you please point me at the RFC that indicates both
> bit numbering such that (value != n^2) where n is the described bit
> number, and where bits are ordered in a different order to bytes.
>
> Microsoft's documentation is the only place, ever, that I have seen
> this insanity.

I'm still unsatisfied with the situation here.  Will there ever be any progress?

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Hongwei Sun]

Andrew,

    We added the explanation about how bit fields are presented in documents to MS-DTYP v2.1.  This information is consistent with the template we have been using to write our currently published protocol documents.  The updated section is attached for your review.

    Hopefully this update can provide readers a clear reference when  using bit field tables in the documents.   At the same time, we are continuing working on the broader issue of the bit fields to improve their usability.

Thanks!

--------------------------------------------------------------------
Hongwei  Sun - Sr. Support Escalation Engineer
DSC Protocol  Team, Microsoft
hongweis@...
Tel:  [phone] x 57027
---------------------------------------------------------------------






-----Original Message-----
From: cifs-protocol-bounces@... [mailto:cifs-protocol-bounces@...] On Behalf Of Andrew Bartlett
Sent: Monday, August 10, 2009 2:41 AM
To: Richard Guthrie
Cc: 'pfif@...'; 'cifs-protocol@...'
Subject: Re: [cifs-protocol] erroneous references to little-endian

On Sat, 2009-07-11 at 09:42 +1000, Andrew Bartlett wrote:

> On Fri, 2009-07-10 at 09:23 -0700, Richard Guthrie wrote:
> > Andrew,
> >
> > We will continue to work to resolution on the broader issue of how
> > to handle bit fields in the documentation.  Your feedback is much
> > appreciated there.  For this specific issue, in general, for
> > custom-marshaled fields you should see a bit field that follows the
> > RFC convention where the high bit of the first byte to hit the wire
> > is in column 0, and the low bit of the last byte to hit the wire is
> > in column 31 (so that the bits are shown from left-to-right in the
> > order they naturally appear over the network).
>
> Your two statements are inconsistent, and not consistent with what the
> documentation does.  Do you mean to say that I can expect the above in
> future, or that you claim the documentation does the above?
>
> If the bits were numbers, for little-endian numbers, such that bit 0,
> representing integer 1 appeared a the left (the little end), and that
> the numbers in the heading increased 0..31 left-to-right, above the
> value such that for it's natural natural number representation (as
> indicated by the stated endianness) that value == n^2, then I would be
> happy.
>
> > We are going back through the documentation to ensure that custom
> > marshaled fields have the appropriate specification for endianness.
>
> Alternately, can you please point me at the RFC that indicates both
> bit numbering such that (value != n^2) where n is the described bit
> number, and where bits are ordered in a different order to bytes.
>
> Microsoft's documentation is the only place, ever, that I have seen
> this insanity.

I'm still unsatisfied with the situation here.  Will there ever be any progress?

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

[Andrew Bartlett]

On Thu, 2009-08-13 at 19:27 +0000, Hongwei Sun wrote:
> Andrew,
>
>     We added the explanation about how bit fields are presented in documents to MS-DTYP v2.1.  This information is consistent with the template we have been using to write our currently published protocol documents.  The updated section is attached for your review.
>
>     Hopefully this update can provide readers a clear reference when  using bit field tables in the documents.   At the same time, we are continuing working on the broader issue of the bit fields to improve their usability.

Well, for me it only confirms the insanity.  

Can we at least agree to remove the use of bitfield tables where the
endian-ness is negotiated (RPC) or otherwise determined (ASN.1)?.  The
'network order' bitfeilds make no sense in this situations, as all
programming must be done in host-order integers with bitmasks anyway.  

This remains the single most frustrating part of the documentation
because it's clear that Microsoft very much understands the problem, yet
is unable to overcome it's insistence on creating this impediment!

Thank you in advance for any progress you are able to make in this area,

Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol