Pete,
Bancroft is correct in criticizing tools that don't handle indefinite-precision integers; however, in practice, I totally agree with you. Sad to say, but it is very likely that quite a few (most?) implementations will fail when confronted with, for example, a 33-bit integer. On previous occasions, limitations of ASN.1 tools have been taken into consideration when choosing a particular syntax, so it's not unprecedented to do this again.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Wednesday, September 08, 1999 2:26 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Issues with H.235
Dear All,
I'm implementing some of the H.235 stuff and have a few concerns.
RandomVal is defined as INTEGER only. This is not a particularly helpful definition as in theory this could be a million bit + integer if needed. Not many computers support such types! In fact, a well known ASN.1 compiler maps this to an int which is a signed 32-bit value on our platform. Is this sufficient? Without further discussion about the range of this value I feel there is a potential for interoperability problems.
Perhaps we can say that RandomVal will never be more than 32 bits long, and then add a type like RandomSeq as an OCTET STRING for cases when we need a longer random value.
There are also a few other issues, for example:
nonStandardParameter in H.235 is defined differently to that in H.225. Why is that?
Similarly tokenID only takes an OID. Again, why such a limited format?
Regards,
Pete
============================================= Pete Cordell pete@tech-know-ware.com =============================================