Limitation of nonStandardData

[Pete Cordell]

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 at bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================


>----------
>From:  Scott Petrack[SMTP:Scott_Petrack at VOCALTEC.COM]
>Sent:  05 December 1997 11:31
>To:    ITU-SG16 at 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
>