Dear All,

After a tireless and exhaustive survey of vendors it appears that no one is using nonStandardData in a way that would cause problems with defining the piece of data that goes into the NonStandardParameter OCTET STRING as a SEQUENCE OF NonStandardParameter.

Some suitable text to cover this case may be:

"To include multiple elements of nonStandardData in an H.225 message the nonStandardParameter is used in the following way. This special use of the nonStandardParameter is identified by setting the nonStandardIdentifier to be an OBJECT IDENTIFIER of type {itu-t (0) recommendation (0) h (8) 2250}. In this case the information contained in the data part of the nonStandardParameter consists of a fragment of ASN.1 encoded into an OCTET STRING (The ASN.1 encoding rules are the same as those for all H.225 messages). The ASN.1 fragment has the following syntax:

ExtendNonStandard ::= SEQUENCE OF NonStandardParameter

It is recommended that entities use this method for including nonStandardData in messages even if they only insert one piece of information as it allows other entities in the signalling path to either add or delete their own nonStandardData without overwriting information inserted by the originating entity."

Apart from winning longest sentence of the year, how does this sound?

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

---

From: Pete Cordell[SMTP:pete.cordell@BT-SYS.BT.CO.UK] Sent: 05 December 1997 13:53 To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Limitation of nonStandardData

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