<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>AW: H.450.1 ASN.1 interoperability issue</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>Mark,</FONT>
</P>
<P><FONT SIZE=2>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>
<P><FONT SIZE=2>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>
<P><FONT SIZE=2>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>
<P><FONT SIZE=2>Ernst Horvath</FONT>
<BR><FONT SIZE=2>Siemens AG</FONT>
</P>
<P><FONT SIZE=2>> -----Ursprüngliche Nachricht-----</FONT>
<BR><FONT SIZE=2>> Von: Mark Brown [<A HREF="mailto:Mark.Brown@ED.ACULAB.COM">mailto:Mark.Brown@ED.ACULAB.COM</A>]</FONT>
<BR><FONT SIZE=2>> Gesendet am: Freitag, 10. Mai 2002 17:29</FONT>
<BR><FONT SIZE=2>> An: ITU-SG16@echo.jf.INTEL.COM</FONT>
<BR><FONT SIZE=2>> Betreff: H.450.1 ASN.1 interoperability issue</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> We've been experiencing some fairly serious interoperability problems</FONT>
<BR><FONT SIZE=2>> with some systems due to confusion over what exactly the ASN.1 for</FONT>
<BR><FONT SIZE=2>> H.450.1 is and were hoping someone could clarify things for us. The</FONT>
<BR><FONT SIZE=2>> problem stems from section 6.6.1.3 of the V4 implementors guide which</FONT>
<BR><FONT SIZE=2>> adds a note below table 4:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> In the Invoke APDU, the invokeID is an INTEGER constrained by a</FONT>
<BR><FONT SIZE=2>> PER-visible constraint (InvokeIdSet = 0..65535) and is therefore</FONT>
<BR><FONT SIZE=2>> encoded as a *constrained* INTEGER (16 bits, no length field). In</FONT>
<BR><FONT SIZE=2>> the ReturnResult and ReturnError APDUs, however, the invokeID is</FONT>
<BR><FONT SIZE=2>> encoded as an *unconstrained* integer (with explicit length field)</FONT>
<BR><FONT SIZE=2>> because the applicable constraint... is not PER-visible.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> However, in H.450.1 table 3 (on page 8) defines InvokeIdSet to be:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> InvokeIdSet INTEGER ::= {InvokeIds,...}</FONT>
<BR><FONT SIZE=2>> InvokeIDs ::= INTEGER (0..65535)</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> which does not gel with the text in the IG and causes interoperability</FONT>
<BR><FONT SIZE=2>> issues since the two versions of the ASN.1 for InvokeIdSet are not</FONT>
<BR><FONT SIZE=2>> encoded identically. This text appears to be unchanged from the</FONT>
<BR><FONT SIZE=2>> prepublished edition on Packetizer.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Our understanding of the text added in the IG is that the </FONT>
<BR><FONT SIZE=2>> intent was to</FONT>
<BR><FONT SIZE=2>> emphasise that the encoding of the invokeID is not consistent between</FONT>
<BR><FONT SIZE=2>> the various APDUs and that the no change to the ASN.1 was intended.</FONT>
<BR><FONT SIZE=2>> This is particularly the case since the IG doesn't modify table 3 as</FONT>
<BR><FONT SIZE=2>> would be expected if it were correcting the ASN.1 there. Others read</FONT>
<BR><FONT SIZE=2>> things differently and are using the definition of </FONT>
<BR><FONT SIZE=2>> InvokeIdSet given in</FONT>
<BR><FONT SIZE=2>> the IG.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> What is the intention here? If the intention is to redefine the ASN.1</FONT>
<BR><FONT SIZE=2>> then some clarification as to why this was done would be very much</FONT>
<BR><FONT SIZE=2>> appreciated.</FONT>
<BR><FONT SIZE=2>> </FONT>
</P>
</BODY>
</HTML>