Re: H.450.1 ASN.1 interoperability issue

Hi I just want to rewrite the same to be sure we are in sync. 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 And this correct encoding is: (as written in 6.6.1.3) invoke.invokeId shall be encoded as INTEGER(0..65535) returnResult.invokeId and returnError.invokeId shall be encoded as INTEGER Sasha -----Original Message----- From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.COM] Sent: Monday, May 13, 2002 8:49 AM To: ITU-SG16@echo.jf.INTEL.COM Subject: AW: H.450.1 ASN.1 interoperability issue Mark, there was no intention to change any ASN.1 definition in H.450.1. The note was added just to make implementers aware that the InvokeID is encoded differently in the "invoke" APDU and in the "returnResult/returnError" APDUs: in the first case it is constrained by InvokeIdSet, in the second case it is not constrained. This is not an incosistency, just a consequence of the way Packed Encoding Rules were designed. Please also note that "InvokeIdSet" is used in two different meanings: in table 4 it is the name of a parameter of the parameterized structure ROS (i.e. a placeholder), whereas in table 3 it is an "actual" value-set of integers. The brackets in the new note (InvokeIdSet = 0..65535) are not an ASN.1 definition, just an indication what the effective constraint is, namely 0..65535. Table 3 is still the (unchanged) formal definition of the actual "InvokeIdSet". Ernst Horvath Siemens AG

On Tue, May 14, 2002 at 11:22:14AM -0400, Sasha Ruditsky wrote:
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.
participants (2)
-
Mark Brown
-
Sasha Ruditsky