Questions on H.235

[Aseem Agarwal]

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 at TECH-KNOW-WARE.COM]
Sent: Wednesday, September 08, 1999 2:26 AM
To: ITU-SG16 at 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 at tech-know-ware.com
=============================================