Limitation of nonStandardData

[Scott Petrack]

I rather thought that Jim's original solution, which is that we agree to
get an OID which means "the OCTET STRING in the data part is actually a
SEQUENCE OF NonStandardParameter" was simple and clean and totally
compatible.  (I don't really care whether it's SEQUENCE or SET).

Is it possible just to write into the H.225/H.245 standards some OID which
is actually within the tree of each standard and then add a single sentence
to the standard which says something like "if the OID is xxxxxx then the
data contains a sequence of NonStandardParameter." That's all. There is no
compatibility problem, no one has to change code, that's all. If you don't
need this OID then you don't use it. It doesn't need to change a line of
anyone's code. Current implementations which don't recognize or send this
OID work exactly as before.

I would like to do this both in H.225 and H.245. In each case where the
nonStandardData is not now a sequence, I may in the future want to pass
some parameters through someone else's stack or through a cloud of
gatekeepers. All this discussion about "I can think of a case where it
won't work" are beside the point. The point is that I can think of
situations where it will work, and right now I have no choice but to come
to private agreements on what the OID will be. *This* is a pain, as well as
making it very difficult to work with more than one other person. An
agreement on a single OID will certainly improve useability and
interoperability.

I thought that it's much too late to muck about with the actual standards.
Quite frankly, I am likely to object to the ASN.1 gymnastics suggested in
other letters, because this is real new code and new state suggested in
December when the thing is going to Decision in January! The simple
suggestion that we add an OID to the tree of H.225 and H.245 surely solves
the problem in a way which is just an "editorial change". And if it's too
late even for this, then let's do nothing now and put it into VoIP or the
implementor's guide.

Sorry if this note sounds rushed -- I am busy preparing for a difficult
IETF.

Scott