H.450.1 ASN.1 interoperability issue

[Mark Brown]

On Tue, May 14, 2002 at 11:22:14AM -0400, Sasha Ruditsky wrote:

> 6.6.1.3 of the V4 implementors guide does not CHANGE/CONTRADICT ASN.1 of
> H.450.1
> it EXPLAINS how to encode values correctly according to ASN.1 definitions of
> H.450.1

I think we all agree here - the ASN.1 is unchanged so an implementation
should be able to use the ASN.1 from H.450.1 verbatim without reference
to the IG and not experience interoperability problems due to this.

> And this correct encoding is: (as written in 6.6.1.3)
> invoke.invokeId shall be encoded as INTEGER(0..65535)

Could someone please clarify for me exactly where this constraint comes
from?

I believe the source of the interoperability issues we're experiencing
in relation to this is that implementors have read the note in the IG,
seen that InvokeIdSet is defined in table 3 and therefore assumed that
6.6.1.3 must be correcting the ASN.1 there when in fact all it's doing
is pointing out the existence of a constraint that's already there.

> returnResult.invokeId and returnError.invokeId  shall be encoded as INTEGER

I don't think there has ever been any question about this.