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(a)vocaltec.com
Fax: +972 9 9561867
