Well, this would make the change even "more" impossible - it would require a change in the ASN.1 per each type of PDU, e.g.:
AccessRequest ::= SEQUENCE { common AnnexGCommonInfo, destinationInfo PartyInformation, sourceInfo PartyInformation OPTIONAL, callInfo CallInformation OPTIONAL, usageSpec UsageSpecification OPTIONAL, ... }
Also it doesn't guarantee that the common part gets into every PDU that will be invented in the future.
Well, that's ASN.1 and we have to leave with it.
Regards, Lior
"Krishna Kr Banka" kkbanka@HSS.HNS.COM on 10/08/99 10:26:16 AM
To: Lior Moscovici cc: "ITU-SG16" itu-sg16@mailbag.cps.intel.com, "H323 Implementors" h323implementors@imtc.org, "Krishna Kr Banka" kkbanka@HSS.HNS.COM, "Chirag Vaidya" cvaidya@HSS.HNS.COM Subject: Re: Message Structure in H.225.0 Annex G
Hi Lior..!!
There seems to be yet another issue regarding the following :
Since the "common" part includes the Sequence Number and other
information
needed for lower level treatment of the message, this part should be decoded first, and the natural order should have been reversed. This is important since the size of the "body" is not fixed, and for cases in
which
there is an error in the encoding of the body.
If the *common* part is placed above the *message-specific* portion, then we shall have a problem extracting the message type out of the encoded message PDU. Since the common part contains fields such as : tokens, cryptoTokens, nonStandard, which can be of variable length; the message-type cannot be accessed without decoding the whole message. One of the possibilities, in my opinion, is that the common part should be made the first field of the message-body itself.
Regards Krishna