<br><font size=2 face="Courier">Hi,</font>
<br>
<br><font size=2 face="Courier">I recall having a discussion on this topic with Ernst Horvath when this clarification </font>
<br><font size=2 face="Courier">text was proposed. I thoroughly checked the ASN.1 back then and based on that I must</font>
<br><font size=2 face="Courier">add that both Sasha and Ernst are right. </font>
<br>
<br><font size=2 face="Courier">Again, in the Invoke, the invokeId is encoded as a constrained integer. In the </font>
<br><font size=2 face="Courier">ReturnResult and ReturnError, the invokeId is encoded as "a regular" integer. I do not </font>
<br><font size=2 face="Courier">see any concerns for interoperability, unless it is your intention to copy the encoded </font>
<br><font size=2 face="Courier">invokeId from the Invoke straight to the ReturnResult/ReturnError. There is no </font>
<br><font size=2 face="Courier">inconsistency, between the different APDUs, there just happens to be a different </font>
<br><font size=2 face="Courier">specification for the invokeId in the different APDUs. This specification is identical </font>
<br><font size=2 face="Courier">to the one used in X.880, on which  H.450.1 is based.</font>
<br>
<br><font size=2 face="Courier">I don't quite understand what you mean with the "two ASN.1 versions" in the "does not</font>
<br><font size=2 face="Courier">gel in" section of your text. Coul you clarify this?</font>
<br>
<br><font size=2 face="Courier">Regards,</font>
<br>
<br><font size=2 face="Courier">Frank</font>
<br>
<br>
<br>
<br>
<br><font size=2 color=blue face="Courier">Hi </font>
<br><font size=3 face="Courier"> </font>
<br><font size=3 color=blue face="Courier">I just want to rewrite the same to be sure we are in sync.</font>
<br><font size=3 face="Courier"> </font>
<br><font size=3 color=blue face="Courier">6.6.1.3 of the V4 implementors guide does not CHANGE/CONTRADICT ASN.1 of H.450.1</font>
<br><font size=3 color=blue face="Courier">it EXPLAINS how to encode values correctly according to ASN.1 definitions of H.450.1</font>
<br><font size=3 color=blue face="Courier">And this correct encoding is: (as written in 6.6.1.3)</font>
<br><font size=3 color=blue face="Courier">invoke.invokeId shall be encoded as INTEGER(0..65535)</font>
<br><font size=3 color=blue face="Courier">returnResult.invokeId and returnError.invokeId  shall be encoded as INTEGER</font>
<br><font size=3 face="Courier"> </font>
<br><font size=3 face="Courier"> </font>
<br><font size=3 color=blue face="Courier">Sasha</font>
<br>
<br><font size=3 face="Courier"> -----Original Message-----<b><br>
From:</b> Horvath Ernst [mailto:ernst.horvath@SIEMENS.COM]<b><br>
Sent:</b> Monday, May 13, 2002 8:49 AM<b><br>
To:</b> ITU-SG16@echo.jf.INTEL.COM<b><br>
Subject:</b> AW: H.450.1 ASN.1 interoperability issue<br>
</font>
<p><font size=2 face="Courier">Mark,</font><font size=3 face="Courier"> </font>
<p><font size=2 face="Courier">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.</font>
<p><font size=2 face="Courier">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. </font>
<p><font size=2 face="Courier">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".</font>
<p><font size=2 face="Courier">Ernst Horvath</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
Siemens AG</font><font size=3 face="Courier"> </font>
<p><font size=2 face="Courier">> -----Ursprüngliche Nachricht-----</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> Von: Mark Brown [</font><a href=mailto:Mark.Brown@ED.ACULAB.COM><font size=2 color=blue face="Courier"><u>mailto:Mark.Brown@ED.ACULAB.COM</u></font></a><font size=2 face="Courier">]</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> Gesendet am: Freitag, 10. Mai 2002 17:29</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> An: ITU-SG16@echo.jf.INTEL.COM</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> Betreff: H.450.1 ASN.1 interoperability issue</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> <br>
> We've been experiencing some fairly serious interoperability problems</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> with some systems due to confusion over what exactly the ASN.1 for</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> H.450.1 is and were hoping someone could clarify things for us.  The</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> problem stems from section 6.6.1.3 of the V4 implementors guide which</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> adds a note below table 4:</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> <br>
>    In the Invoke APDU, the invokeID is an INTEGER constrained by a</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
>    PER-visible constraint (InvokeIdSet = 0..65535) and is therefore</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
>    encoded as a *constrained* INTEGER (16 bits, no length field).  In</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
>    the ReturnResult and ReturnError APDUs, however, the invokeID is</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
>    encoded as an *unconstrained* integer (with explicit length field)</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
>    because the applicable constraint... is not PER-visible.</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> <br>
> However, in H.450.1 table 3 (on page 8) defines InvokeIdSet to be:</font><font size=3 face="Courier"> </font>
<br><font size=2 face="Courier">> <br>
>    InvokeIdSet     INTEGER ::= {InvokeIds,...}</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
>    InvokeIDs   ::= INTEGER (0..65535)</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> <br>
> which does not gel with the text in the IG and causes interoperability</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> issues since the two versions of the ASN.1 for InvokeIdSet are not</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> encoded identically.  This text appears to be unchanged from the</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> prepublished edition on Packetizer.</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> <br>
> Our understanding of the text added in the IG is that the <br>
> intent was to</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> emphasise that the encoding of the invokeID is not consistent between</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> the various APDUs and that the no change to the ASN.1 was intended.</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> This is particularly the case since the IG doesn't modify table 3 as</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> would be expected if it were correcting the ASN.1 there.  Others read</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> things differently and are using the definition of <br>
> InvokeIdSet given in</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> the IG.</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> <br>
> What is the intention here?  If the intention is to redefine the ASN.1</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> then some clarification as to why this was done would be very much</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> appreciated.</font><font size=3 face="Courier"> </font><font size=2 face="Courier"><br>
> </font>
<br>
<br>