It was brought to my attention, that one of the last revisions to Annex G before decision was omitted in the decided version due to my fault as an editor. This is the syntax of the Annex G message:
Message ::= SEQUENCE { body AnnexGMessageBody, common AnnexGCommonInfo, ... }
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.
Message ::= SEQUENCE { common AnnexGCommonInfo, body AnnexGMessageBody, ... }
This was proposed in the SG16 meeting in Santiago, but during the editing session, it was omitted.
Since this is already decided, and the change breaks possible existing implementations, changing it now is next to impossible.
I would like to explore how "impossible" it is: I have a reason to believe that there are no officially released products that implement Annex G, so if absolute consensus is reached, we may have a chance to change it in the Red Bank meeting.
I know this brings painful memories with the H.235 ClearToken, and I really don't want this to cause frustration and pain. Therefore I ask everyone whom it might concern, to say if he has any objection in making the change. If there is even only one objection, I will drop everything, but if there is none, I will submit this to the Red Bank meeting. Even then, the acceptance is not guaranteed.
Lior
Lior Moscovici Program Manager, Servers Group R&D VocalTec Communications Ltd. Voice: +972 9 9707767 E-mail: liorm@vocaltec.com Fax: +972 9 9561867