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

---

From: Joerg Ott[SMTP:jo@CS.TU-BERLIN.DE] Sent: 11 December 1997 02:53 To: ITU-SG16@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