(Resolution?) Limitation of nonStandardData

Pete Cordell pete.cordell at BT-SYS.BT.CO.UK
Thu Dec 11 06:37:23 EST 1997


Joerg,

Obviously the IETF has not been too busy this time!!!

I agree we have to say what to do if you want to insert nonStandardData
when there is already some there.  Unfortunately our application will
break if the our nonStanadardData is not passed between co-operating
gatekeepers.  So I'm afraid we are 180 degrees out of phase with your
proposed text!!!

I had resolved that the nonStandardData from endpoints passed between my
cooperating entities would use the nesting technique that I originally
mentioned anyway.  Basically if non extended nonStandardData is seen I
would build it into a SEQUENCE like I originally proposed and then add
the whole lot as a single item in the extended nonStandardParameter
form.  Because I am pretty sure of the entities I am talking to I can
ensure that it is un-rolled properly.

So my additional text would be:

"If intermediate entities on the signalling path need to insert
nonStandardData when there is already nonStandardData present that is
not of the extended form described above (i.e. this sentence goes below
what I originally presented, just avoid any confusion!) they are
encouraged to take measures to ensure that the original nonStandardData
can be recovered by entities further down the signalling path once those
entities have removed any nonStandardData specific to them.  This can be
achieved by nesting the original nonStandardData field inside the
nonStandardParameter created by the intermediate entity.

However, endpoints should be aware that if they do not insert
nonStandardData in the extended form it may be overwritten by
intermediate signalling entities."

The latter statement really conforms with Joerg's a) suggestion without
using SHALL!!!

Pete

(P.S.  The prize is a grammar checker, but it is still in the post!)
=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell at bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================


>----------
>From:  Joerg Ott[SMTP:jo at CS.TU-BERLIN.DE]
>Sent:  11 December 1997 02:53
>To:    ITU-SG16 at MAILBAG.INTEL.COM
>Subject:       Re: (Resolution?) Limitation of nonStandardData
>
>Pete and others,
>
>I have followed this discussion with some delay but eventually managed
>to get through all the e-mails sent on this subject.  Your final
>suggestion looks good to me but I would want to include
>
>a)  either a strong recommendation that endpoints SHALL use the new
>    parameter
>
>b)  or -- if this is not possible because of our backward
>    compatibility vow in the ITU-T -- a statement that specifies what
>    an entity is supposed to do if it does receive a parameters that
>    does not follow this convention.
>
>Although we can assume that there are not too many implementations out
>there doing this (probably people are still chewing on the base spec
>:-),
>completeness requires to define this behavior as well.
>
>>
>> Some suitable text to cover this case may be:
>>
>> "To include multiple elements of nonStandardData in an H.225 message the
>> nonStandardParameter SHALL BE 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 SHALL CONSIST 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
>>
>> Entities SHOULD 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."
>
>IF AN ENTITY RECEIVES A SIMPLE NonStandardParameter, IT SHALL NOT
>MODIFY
>OR MOVE ITS CONTENTS IN ANY WAY BUT PASS ON THE PARAMETER UNCHANGED.
>IN THIS CASE, IT CANNOT ADD ITS OWN NonStandardParameter TO THE
>MESSAGE.
>AS A CONSEQUENCE, AN ENTITY SHALL NOT RELY ON NonStandardParameters TO
>FUNCTION PROPERLY.
>
>IF AN ENTITY KNOWS THAT IT COMMUNICATES WITH A VERSION 1 ENTITY, IT
>SHALL
>NOT MAKE USE OF THIS MECHANISM.
>
>This is probably not yet the right (order of) wording but right now I
>just
>want to get across what I think should be added...
>
>>
>> Apart from winning longest sentence of the year, how does this sound?
>Good.  And congratulations!  What did you win? ;-)
>
>Joerg
>



More information about the sg16-avd mailing list