The reason for my gymnastics is to give transparency to implementations that already use nonStandardData and are already out there. A gatekeeper that sees previousNonStandard (I've changed the name to overWritten below in an attempt to increase the clarity) when it goes to remove its nonStandard part knows that an earlier gatekeeper in the chain overwrote nonStandardData that wasn't in this form and so can restore it as it was. This allows endpoints that are out there and only understand the data in the form that it presents it in can make use of it.

From a code impact point of view I see no difference between saying the

OCTET STRING is

SEQUENCE OF NonStandardParameter, or

SEQUENCE { overWritten NonStandardParameter OPTIONAL, extra SEQUENCE OF NonStandardParameter }

If you support the OID you have to write code either way.

However, if nobody is using nonStandardData in the H.225 PDUs yet then we are trying to solve a problem that doesn't exist. So the question is:

IS ANYBODY OUT THERE USING NONSTANDARDDATA AT THE MOMENT???

If not Jim's solution is fine.

Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell@bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

---

From: Scott Petrack[SMTP:Scott_Petrack@VOCALTEC.COM] Sent: 05 December 1997 11:31 To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Limitation of nonStandardData

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