Yes, Bancroft understands what I said completely! Applications based on ASN.1 or our ASN.1 extension care nothing about byte ordering, however, the decoder/encoder need that notation to be instructed to do its job using non-ASN.1 encoding rules. After all, bit fields or integer fields in the bit-stream(encodings) may be encoded in little-endian order as far as some legacy protocols or private protocols are concerned.
----- Original Message ----- From: "Bancroft Scott" <[EMAIL PROTECTED]> To: "WangHao" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, August 31, 2004 3:08 PM Subject: Re: [ASN1] What is the bytes order in ASN.1 message? > On Tue, 31 Aug 2004, WangHao wrote: > > > > He asked what the standard interface was. What you are doing is not > > > compatible with the standards and is therefore not relevant. > > > > I think you might misunderstand what I meant. I extended the standard > > ASN.1 notation and designed that notation carefully and considered the > > compatibility, so standard ASN.1 notations still work in its way. The > > default endian is big-endian. > > > > I mean that perhaps endian control should be provided for users to > > control the actual endian just as ECN does. There exists the > > applications that require messages in one endian order be converted into > > messages in another endian order or that require messages in > > little-endian order instead of in standard big-endian order. > > The concept of byte ordering is of no significance in the ASN.1 encoding > rules, other than in the need at a low level to stipulate the order bytes > should be encoded in so that the receiving decoder knows precisely how the > data was encoded. If a decoder is written properly it will always yield > the right byte order in the data that it returns to the calling program, > without the need for the calling program to know the byte order. > > As for ECN supporting different byte orders, the reason that it allows > this is that it is used to support legacy protocols that use non-ASN.1 > encodings. Since some legacy protocols may have chosen to encode data in > little endian byte order while others may have chosen big endian, it is > necessary for ECN to allow the person *who is creating the ECN > specification* to choose the byte ordering. Note well that with ECN there > is no need for the *implementation* to choose the byte order, just as with > BER, PER, XER there is no need for the implementation to choose the byte > order. It is easy to write the decoder so that not even the decoder > itself knows whether the byte order on a given machine is big endian or > little endian; thus, it can with no added effort deliver the decoded data > to the calling program in the format that is native to the machine on > which the implementaiton is running. > > ------------------------------------------------------------------------- > Bancroft Scott Toll Free :1-888-OSS-ASN1 > OSS Nokalva International:1-732-302-0750 > [EMAIL PROTECTED] Tech Support :1-732-302-9669 x-1 > 1-732-302-9669 x-200 Fax :1-732-302-0023 > http://www.oss.com _______________________________________________ ASN1 mailing list [EMAIL PROTECTED] http://lists.asn1.org/mailman/listinfo/asn1
