Scott Petrack wrote:
This problem has bothered me for a long time. I considered many times introducing into the VoIP Forum an OID which would be used precisely as Jim suggests, so that the entire industry could signal a SEQUENCE of NonStandardParameter.
So do you mean something like this?:
NonStandardParameter ::=SEQUENCE { nonStandardIdentifier NonStandardIdentifier, -- e.g., VoIP OID data OCTET STRING }
where data contains the following:
SET SIZE (1..256) OF NonStandardParameter
BTW, I believe that it should be a SET OF and not a SEQUENCE OF, because SEQUENCE OF implies that the order is important, and I don't think that is the intent here. Or is it?
One way to handle this for _future_ syntax is to define a type that is itself a set of NonStandardParameters, as in:
NonStandardParameters ::=SEQUENCE { nonStandardParameters SET SIZE (1..256) OF NonStandardParameter }
One example of why this is necessary is so that when someone else uses our stack we can both pass non-standard parameters.
Just to play devil's advocate, can you give an example of a specific need for this? A quick review of H.245 didn't turn up very many situations where aggregation isn't handled already at a higher level or where it just doesn't make sense in the first place.
Here is an example of where iteration is expressed at a higher level. The capability table contains multiple capabilities, so there is no need for a single capability containing multiple NonStandardParameters--just add more nonStandard capabilities. Case in point: it makes no sense, IMO, for UserInputCapability to have a nonStandard CHOICE of multiple NonStandardParameters, when multiple nonStandard UserInputCapabilities would have served just as well. I agree with Dykstra--_I don't like more than one way of doing the same thing._
An example of where multiple NonStandardParameters may not make sense in the first place is in the NonStandardMessage type. Is there ever a need to combine several NonStandardParameters in the same RequestMessage, for example? IOW, these uses are atomic.
-- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/