Re: Limitation of nonStandardData
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.
One example of why this is necessary is so that when someone else uses our stack we can both pass non-standard parameters.
Question to all "industry techie-leaders" (by definition people reading this message ;-)). Is there any chance of gettting agreement on this or is it too late? Of course we can do it privately (and we do), but it would be very useful to have everyone do it together, no?
I would offer an OID in the VoIP forum's space, but I really could not care less about ownership. If there is a way to put this into the standard, that would be fantastic.
Scott
jtoga@ideal.jf.intel.com on 12/01/97 09:42:53 PM
Please respond to ITU-SG16@mailbag.jf.intel.com
To: ITU-SG16@mailbag.jf.intel.com cc: (bcc: Scott Petrack) Subject: Re: Limitation of nonStandardData
Pete, An easy fix for backward compatability is to simply define a particular 'nonStandardParameter' as a "SEQUENCE OF nonStandardParameter".
Regards, jimt.
At 07:02 PM 12/1/97 -0000, you wrote:
Dear All,
I have noticed that there is a limitation in H.225 (and H.245) on how nonStandardData is included in messages. Basically only one non-standard element can be included in each PDU. This is because of the syntax:
nonStandardData NonStandardParameter,What is really required for a truly extensible protocol is:
nonStandardData SEQUENCE OF NonStandardParameter,This is especially important if a gatekeeper wants to insert nonStandardData into a message that already has nonStandardData added in to it by an endpoint.
This may be too late to fix for H.225, but we can fix this for the H.450.x protocols.
Pete
Pete Cordell BT Labs E-Mail: pete.cordell@bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================
************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga@ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************
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/
participants (2)
-
Paul Long -
Scott Petrack