> What does Integer(1 ... 32 768, ...) mean in PER aligned encoded ASN.1.
I believe you mean to say INTEGER (1..32768, ...) Note a) INTEGER is all capitals; b) there are only two periods between the 1 and the 32768; and c) there is no space betwen the 32 and the 768. If that is the original intention, then it means that the integer may take a value within the range 1-32768, and it is extensible (denoted by ...). This "extensible" stuff means that a later generation of the ASN.1 syntax for this application could extend the range without having to change the original specification. Thus there could be two versions of the application, one (let's call it the 1st version) which accepts integers within the range 1-32768, and another (let's call it the 2nd version) which accepts integers within the range 1-40000. The ASN.1 specification for V1 would be INTEGER (1..32768, ...) and the specification for V2 would be INTEGER (1..32768, ..., 32769..40000) Let's dwell a little on the purpose of extensibility. Extensibility recognizes the fact that an application is rarely actually finished being developed. At some point, someone will want to change something and so a V1 application is born. But now the problem is that I can't afford, if, for instance, I have 1000 systems exchanging data, to upgrade them all to V2 simultaneously! Extensibility both permits the newer V2 applications to do new things and the older V1 applications to recognize that new things might be done. In this manner both V1 and V2 applications can interoperate. You might, at this point, understand the point of extensibility, but not yet fully comprehend why the ... is important to both V1 and V2. The ... informs V1 that it might receive something outside the 1-32768 range (for instance, from a V2 application) and should not consider it a fatal error. If you're using PER (as you say you are) the encoding for such an out-of-range integer would be different from a normal encoding in that the integers within the extended range are encapsulated so that the V1 application can simply skip over them without trying to decode them. We are therefore saying that the V1 application can receive three types of integers: a) valid integers within the range 1-32768, b) invalid integers which the decoding software would recognize as invalid and reject, and c) extended range integers which the decoding software doesn't know anything about (except that they are extended) and ignores. The V1 application can, because of the encapsulation of the extended range integers, tell the difference between outright invalid integers and extended range integers (unknown integers). The V2 application has to also be aware of the difference between integers in the V1 range and integers in the V2 range for the encoding (as we pointed out above) is different. When V2 encodes an integer within the V1 range, it simple encodes it; when V2 encodes an integer within the V2 range, it also encapsulates it so that V1 can recognize that the data comes from a V2 system. Luckily, if you're using ASN.1 software, the encoding and decoding routines take care of all this for you. Please excuse me if I provided more information than you needed. ===================================================================== Conrad Sigona Toll Free : 1-888-OSS-ASN1 OSS Nokalva Voice Mail : 1-732-302-9669 x400 [EMAIL PROTECTED] Fax : 1-419-831-5035 http://www.oss.com My direct line : 1-315-845-1773
