foltsh at NCS.GOV
Sun May 26 21:36:09 EDT 2002
On Tue, May 21, 2002 at 08:32:59AM +0200, frank.derks at philips.com wrote:
> Again, in the Invoke, the invokeId is encoded as a constrained integer. In
> 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
> 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.
More information about the sg16-avd