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.