H.450.1 ASN.1 interoperability issue

[frank.derks at PHILIPS.COM]

Hi,

I recall having a discussion on this topic with Ernst Horvath when this 
clarification 
text was proposed. I thoroughly checked the ASN.1 back then and based on 
that I must
add that both Sasha and Ernst are right. 

Again, in the Invoke, the invokeId is encoded as a constrained integer. In 
the 
ReturnResult and ReturnError, the invokeId is encoded as "a regular" 
integer. I do not 
see any concerns for interoperability, unless it is your intention to copy 
the encoded 
invokeId from the Invoke straight to the ReturnResult/ReturnError. There 
is no 
inconsistency, between the different APDUs, there just happens to be a 
different 
specification for the invokeId in the different APDUs. This specification 
is identical 
to the one used in X.880, on which  H.450.1 is based.

I don't quite understand what you mean with the "two ASN.1 versions" in 
the "does not
gel in" section of your text. Coul you clarify this?

Regards,

Frank




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 at SIEMENS.COM]
Sent: Monday, May 13, 2002 8:49 AM
To: ITU-SG16 at 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 
> -----Ursprüngliche Nachricht----- 
> Von: Mark Brown [mailto:Mark.Brown at ED.ACULAB.COM] 
> Gesendet am: Freitag, 10. Mai 2002 17:29 
> An: ITU-SG16 at echo.jf.INTEL.COM 
> Betreff: H.450.1 ASN.1 interoperability issue 
> 
> We've been experiencing some fairly serious interoperability problems 
> with some systems due to confusion over what exactly the ASN.1 for 
> H.450.1 is and were hoping someone could clarify things for us.  The 
> problem stems from section 6.6.1.3 of the V4 implementors guide which 
> adds a note below table 4: 
> 
>    In the Invoke APDU, the invokeID is an INTEGER constrained by a 
>    PER-visible constraint (InvokeIdSet = 0..65535) and is therefore 
>    encoded as a *constrained* INTEGER (16 bits, no length field).  In 
>    the ReturnResult and ReturnError APDUs, however, the invokeID is 
>    encoded as an *unconstrained* integer (with explicit length field) 
>    because the applicable constraint... is not PER-visible. 
> 
> However, in H.450.1 table 3 (on page 8) defines InvokeIdSet to be: 
> 
>    InvokeIdSet     INTEGER ::= {InvokeIds,...} 
>    InvokeIDs   ::= INTEGER (0..65535) 
> 
> which does not gel with the text in the IG and causes interoperability 
> issues since the two versions of the ASN.1 for InvokeIdSet are not 
> encoded identically.  This text appears to be unchanged from the 
> prepublished edition on Packetizer. 
> 
> Our understanding of the text added in the IG is that the 
> intent was to 
> emphasise that the encoding of the invokeID is not consistent between 
> the various APDUs and that the no change to the ASN.1 was intended. 
> This is particularly the case since the IG doesn't modify table 3 as 
> would be expected if it were correcting the ASN.1 there.  Others read 
> things differently and are using the definition of 
> InvokeIdSet given in 
> the IG. 
> 
> What is the intention here?  If the intention is to redefine the ASN.1 
> then some clarification as to why this was done would be very much 
> appreciated. 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20020521/b9f66db6/attachment-0001.htm>