Paul,
Whoops! There is the same problem with LocationRejectReason and aliasesInconsistent--it also changed position between IGv2 and H.225.0v3.
I never did like H.323 IGs being normative. Too dangerous. If normative, IGs should only be used for clarification and true corrections, not for _any_ modifications no matter how innocuous they may seem. For H.324, IGs were not normative and merely somewhere to write down the things we were going to change in the _next_ version until the next version came out.
FWIW, Smith Micro skipped v2 and went straight from v1 to v3, so we use the Decided v3 syntax for ARJ and not the v2 syntax as modified by IGv2.
BTW, I didn't see this latest email from you on the implementers reflectors. In case we have a disjoint set of participants, you need to keep them in the loop, too.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Wednesday, October 04, 2000 2:19 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Error in H.323v3 ASN.1
Anatoli,
This is a difficult situation here: and we've been here before. I received e-mail from one company this morning that said they need the H.323v2 field, because they did use the Implementers Guide definitions.
Now, it appears that we have the same problem as we had with the TokenOID problem back in May 1999 where one published document contradicted another.
So, how can we resolve this issue? I've already concluded that, based on the number of vendors out there with H.323 products, we can't possibly contact them all and take a vote :-)
Without getting into specific details: at this point, 1 year after the published H.323v3 document, how much effort would it be to try to change the H.323v3 software you have deployed and how much of an impact would that have? Did you also pick up all of the other H.323v3 ASN.1 changes that have been made? See this file for a complete, updated ASN.1 for v3: http://www.packetizer.com/iptel/h323/h2250v3.asn. Of course, it does contain the error we're talking about here, but that is only because I copied the ASN.1 from the published v3 document and then modified it according to the Implementers Guide.
Paul