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(a)HSS.HNS.COM> on 10/08/99 10:26:16 AM
To: Lior Moscovici
cc: "ITU-SG16" <itu-sg16(a)mailbag.cps.intel.com>, "H323 Implementors"
<h323implementors(a)imtc.org>, "Krishna Kr Banka"
<kkbanka(a)HSS.HNS.COM>, "Chirag Vaidya" <cvaidya(a)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
