Douglas, I couldn't have said it better...

As far as constraints and SETs etc....

Paul, It's funny you mentioned 32MB because that's exactly how big an H.245 structure came out when we compiled it! Perhaps we did something wrong, but now we have gone to linked lists and its all hunky dory. My feeling is that if you use the fixed size constraints you are guaranteed to waste memory in systems that can't afford to waste it. What you need is a size constraint for the entire decoded message. Unfortunately ASN.1 does not give you such a feature.

Woops, I have to take back what I said about the encoding of SET OF. It came from my hazy memory of the following paragraph from X.691: 21 Encoding the set-of type 21.1 For CANONICAL-PER the encoding of the component values of the set-of type shall appear in ascending order, the component encodings being compared as bit strings padded with as many as seven 0 bits to an octet boundary. NOTE - Any pad bits added to achieve octet alignment for the sort do not appear in the actual encoding. 21.2 For BASIC-PER the set-of shall be encoded as if it had been declared a sequence-of type. However, we are using the BASIC for so there shouldn't be a problem.

For what it's worth, I agree that ERROR propagation is not a good thing, but, based on the premise that exceptional cases introduce bugs, SUB-OPTIMALITY propagation is not always a bad thing if it leads to consistency!!!

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

---

From: Douglas Clowes[SMTP:dclowes@OZEMAIL.COM.AU] Sent: 04 December 1997 01:22 To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Limitation of nonStandardData

Paul,

There seems to be a mismatch in the understanding here and I'm not sure that it isn't me. So I'll give my version the understanding and hope to be corrected where I'm wrong. (BTW, I don't understand what the '...' in the ASN.1 does and why it's in the middle of the H.323 V2 stuff.)

At 13:25 3/12/97 -0800, Paul Long wrote:

...

Pete Cordell wrote:

...

We are mainly interested in gatekeepers. We have a need to ship nonStandard information between cooperating gatekeepers, particularly in the SETUP message.

Okay, I see that H.225.0 apparently wasn't engineered for multiple nonStandardParameters, whereas H.245 at least originally was, but at a higher level, not merely a SET OF NonStandardParameters. I agree that this is a problem in H.225.0, but I don't think there is a problem with H.245, unless someone can give me specific examples.

The problem tends to arise in a channel where there are multiple nodes. This could be true of RAS if there is a hierarchy of gatekeepers. It is true of of the Call Signalling Channel and the H.245 Control Channel when going via one or more gatekeepers, proxies or other devices.

An obvious problem arises in the following situation. Two endpoints require a NonStandardParameter in the Q.931 SETUP message so that they can cooperative complete a connection. Two intermediate (to the endpoints) and cooperative gatekeepers require to add a NonStandardParameter for their participation in the SETUP process. Two intermediate (to the gatekeepers) and cooperative proxies require to add a NonStandardParameter for their own use. The problem arises when the intermediaries throw away the NonStandardParameter already in the message and substitute their own because the syntax only allows one NonStandardParameter.

I don't understand how H.245 intrinsically solves this problem for, say, OpenLogicalChannel.

...

...

To do this, I propose that the piece of ASN.1 put in the data part of nonStandardParameter should be:

ExtendedNonStandardData ::= SEQUENCE { previousNonStandard NonStandardParameter OPTIONAL, extraNonStandard SEQUENCE OF NonStandardParameter, ... }

Please constrain this aggregate with something like this: extraNonStandard SET SIZE (0..255) OF NonStandardParameter,

Given that a NonStandardParameter contains a data field that is an unconstrained OCTET STRING, I don't see the point of arbitrarily constraining the number of them.

...

...

A V1 endpoint could put its own piece of nonStandardData into the existing nonStandard field. When a gatekeeper (or something else) received it, it would take the data from the existing nonStandard field and put it in the previousNonStandard field of the above SEQUENCE.

Copying it or moving it? IOW, would the original nonStandardData still be present?

The original nonStandardData is moved, by the first gateway of the above example, into the previousNonStandard field. This allows the first gateway to add its own NonStandardParameter to the extraNonStandard field.

The whole ExtendedNonStandardData is placed in the data field of the V1 NonStandardParameter which is included in the original message in place of the original nonStandardData.

The first proxy does exactly the same thing.

The message is still V1 compliant so if it goes through anything else that cares, it still sees a standard V1 message with the single NonStandardParameter allowed in the standard and, hopefully, passes it on to the second proxy.

The second proxy recognizes the NonStandardparameter as its very own and unwraps it to reveal, in the previousNonStandard field, the NonStandardParameter that the first proxy received from the first gatekeeper. It takes its own stuff out and restores the NonStandardparameter from the previousNonStandard field, places it in the outgoing message as the one and only NonStandardParameter allowed in the message and sends it to the second gatekeeper.

The second gatekeeper does exactly the same thing. The message that it sends to the second endpoint contains the original (from the first endpoint) NonStandardparameter as received by the first gatekeeper.

...

...

It would then add whatever nonStandard stuff it needed to the extraNonStandard bit. It would put the combined nonStandard data in the data part of the nonStandardParameter and give it the tag that we decide on.

I don't understand, why have "previousNonStandard?" Why not just have a single nonStandard SET SIZE (0..255) OF NonStandardParameter, and simply append any GK stuff to the end? Also, as someone said previously in this thread, what if a third-party stack uses the single, original NonStandardParameter, yet the layer above that stack also wishes to include NonStandardParameters. Sounds like NonStandardParameters can be added and removed at any point in the data path, not just by GKs.

In V1, there is only a single nonStandard, not a set of them. To include a NonStandardParameter where there alreay is one requires the original to be discarded which is the root of the problem. To extend the standard to have a SET or SEQUENCE OF is a possible solution to the problem. If the message goes through something that only tollerates a single NonStandardParameter as specified in the standard, there could be a problem.

[cut]

...

...

I've used an unconstrained SEQUENCE OF for the following reasons:

1. No other SEQUENCE OFs are bounded within H.225.

They should have been, and this will cause implementation problems down the line. Each vendor guesses what the max should be. Although all guesses are equally "correct," some will be too low and could cause the system to fail through no fault of the vendor. Remember that not all implementations will have 32MB of RAM and all the virtual memory they need.

I understand your concern but, again, the NonStandardParameter is unbounded (if I correctly interpret 'OCTET STRING') and so, limiting the number of them to 255 doesn't add a lot and imposes an arbitrary constraint.

...

...

2. Size constraints on SEQUENCE OF are not always that useful

(especially in the case of H.245!)

I have no idea what you mean by this. There are always real size constraints--no system has infinite resources. It would just be nice if the constraints were agreed upon and stated up front in the Recommendation.

If you impose limitations that fit the lowest hardware of today, they will be innappropriate for the hardware of this afternoon. If you set the limits to handle the growth, does it help today. Say we imposed a limit of a 4GB today, would it help. If we made that limit 16K today, how would that impact us later?

...

...

3. We have no other SET OFs in H.225

So error propagation is a good thing, right? :-)

This bit I agree with, so it probably means I don't understand the finer points of difference between sequences and sets, right? :-)

...

...

4. As I understand it, for some strange reason, because the order of the

members of a SET OF is intended to be un-important the compiler takes it upon itself to sort the values entered into some form of order!!! This seems a waste of time and is a step best avoided by using SEQUENCE OF.

I've never heard of this before. I'll check with Bancroft. Sounds like a bug in the OSS compiler, which by the way we don't use for reasons like this.

Sounds like a problem with implementation in a particular compiler, not a good basis for setting the direction of a standard. I think that the *best* way to avoid such a problem is to fix or replace the compiler.

Regards,

Douglas Clowes