On Tue, May 21, 2002 at 08:32:59AM +0200, frank.derks@philips.com wrote:
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
My question was sparked by a discussion with another implementor about some actual interoperability issues we're experiencing. The other implementor pointed me at the IG and suggested that the way to apply the IG was to modify the ASN.1 I was using so that InvokeIdSet was defined as an INTEGER(0..65535). I couldn't see how the standard or the IG would support that but they were most insistent and I wasn't terribly sure of my ASN.1 so I came here for clarification.
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.
Well, it's inconsistent in that it's not the same definition for the equivalent thing in the various APDUs. That isn't a problem, it's just that the various invokes aren't cut and pastes of each other.
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?
It's not immediately apparent without looking at the encoding rules for PER that the invokeId will be encoded as an INTEGER(0..65535) as given and the wording in the IG is a little unclear in that it says "InvokeIdSet = INTEGER(0..65535)". That is what the constraint boils down to but it is not what InvokeIdSet is.