Limitation of nonStandardData

[Pete Cordell]

Jim, Scott, Douglas, Paul,.....

To answer Paul's question about the need for the change first:

We are mainly interested in gatekeepers.  We have a need to ship
nonStandard information between cooperating gatekeepers, particularly in
the SETUP message.  However, endpoints may also wish to ship their own
nonStandard information which the gatekeeper doesn't want to stamp on
(because I'm a nice guy!).  Hence we both have a need to use a field
that is only intended to carry one value.

This helps identify a suitable syntax for the data that goes into the
data part of nonStandard data, as I believe we need to cater for both
the nested form (for backwards compatibility) and multiple pieces of
nonStandard data without any particular order.

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,
        ...
}

This would be used as follows:

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.  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.

On the other side a gatekeeper could see that the extraNonStandard
related to it, and remove parts the parts that it needed to.  If all
that was left was the previousNonStandard part, then it would use this
to recover what was the original format of the nonStandard message.
This allows endpoints to send nonStandardData transparently, but also
allows gatekeepers to get in on the act.

As far as how this is captured in the standard, this seems a fairly
important feature for H.225.  I think we should include this as a
separate root in the H.225 ASN.1 and give a fairly official OBJECT
IDENTIFIER (e.g. {itu-t (0) recommendation (0) h(8) 2250} which
shouldn't clash with anything in the context that we are using it).

I've used an unconstrained SEQUENCE OF for the following reasons:
1. No other SEQUENCE OFs are bounded within H.225.
2. Size constraints on SEQUENCE OF are not always that useful
(especially in the case of H.245!)
3. We have no other SET OFs in H.225
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.

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


>----------
>From:  Paul Long[SMTP:plong at SMITHMICRO.COM]
>Sent:  02 December 1997 21:05
>To:    ITU-SG16 at MAILBAG.INTEL.COM
>Subject:       Re: Limitation of nonStandardData
>
>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/
>