Ok; thanks. We have a decoder that handles this case; it's just that we're considering whether to continue with that decoder or implement a new one. In the process of prototyping a replacement, I found the blocked format and couldn't find anything in 690/8825 that stated this is an allowed format. -- Wayne
-----Original Message----- From: Bancroft Scott [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 04, 2005 11:31 AM To: [email protected] Cc: Wayne Adams Subject: Re: [ASN1] "Blocked" BER data? On Wed, 4 May 2005, Wayne Adams wrote: > Hello, all: > > I'm trying to process some data files that are described as being > BER encoded but are also blocked. Of the two examples I have, the > fill octets for one of the files are "00" and for the other, "FF". Is > this technically "correct" BER encoding? I'm not seeing any way to > unambiguously discriminate between end-of-contents octets (in the case > of the "00" fill octets), and I'm also wondering how many "FF" octets > you would see in a decode operation before you decided you were > looking at padding characters (as opposed to "real" encoded data). This is technically not "correct" BER in that it is not part of the BER standard; it is a mechanism utilized by some applications to create message blocks of fixed size. There are tools available to process BER-encoded messages of the kind you describe (encodings followed by "00" or "FF" fill bytes), such as the OSS CDR Assistant: http://www.oss.com/products/cdr.html. Bancroft _______________________________________________ ASN1 mailing list [email protected] http://lists.asn1.org/mailman/listinfo/asn1
