I rather thought that Jim's original solution, which is that we agree to get an OID which means "the OCTET STRING in the data part is actually a SEQUENCE OF NonStandardParameter" was simple and clean and totally compatible. (I don't really care whether it's SEQUENCE or SET).

Is it possible just to write into the H.225/H.245 standards some OID which is actually within the tree of each standard and then add a single sentence to the standard which says something like "if the OID is xxxxxx then the data contains a sequence of NonStandardParameter." That's all. There is no compatibility problem, no one has to change code, that's all. If you don't need this OID then you don't use it. It doesn't need to change a line of anyone's code. Current implementations which don't recognize or send this OID work exactly as before.

I would like to do this both in H.225 and H.245. In each case where the nonStandardData is not now a sequence, I may in the future want to pass some parameters through someone else's stack or through a cloud of gatekeepers. All this discussion about "I can think of a case where it won't work" are beside the point. The point is that I can think of situations where it will work, and right now I have no choice but to come to private agreements on what the OID will be. *This* is a pain, as well as making it very difficult to work with more than one other person. An agreement on a single OID will certainly improve useability and interoperability.

I thought that it's much too late to muck about with the actual standards. Quite frankly, I am likely to object to the ASN.1 gymnastics suggested in other letters, because this is real new code and new state suggested in December when the thing is going to Decision in January! The simple suggestion that we add an OID to the tree of H.225 and H.245 surely solves the problem in a way which is just an "editorial change". And if it's too late even for this, then let's do nothing now and put it into VoIP or the implementor's guide.

Sorry if this note sounds rushed -- I am busy preparing for a difficult IETF.

Scott