(Resolution?) Limitation of nonStandardData

Pete Cordell pete.cordell at BT-SYS.BT.CO.UK
Wed Dec 10 11:47:40 EST 1997


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


>----------
>From:  Pete Cordell[SMTP:pete.cordell at BT-SYS.BT.CO.UK]
>Sent:  05 December 1997 13:53
>To:    ITU-SG16 at 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 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
>>
>



More information about the sg16-avd mailing list