(Resolution?) Limitation of nonStandardData

[Joerg Ott]

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