No concensus for ASN.1 extension support (was: Re: APC-1265)

Paul Long plong at SMITHMICRO.COM
Wed Sep 3 20:26:44 EDT 1997

Toby Nixon wrote:
> Paul Long wrote:
> >> 1. It shall be mandatory for all H.323 V2 terminals to promote
> >> interoperability.
> >
> >Please, Mr. Nilsson or Mr. Toga, correct me if I'm wrong, but I don't
> >believe it can be made mandatory at this time. A newer version of a
> >Recommendation can augment and clarify but cannot constrain previous
> >versions.
> But a new version of a recommendation CAN add new mandatory requirements
> on terminals claiming compliance to that new version. For example, if
> "X" was optional in Version 1, version 2 could make "X" mandatory for
> terminals claiming compliance to version 2. Or, if "X" was mandatory in
> version 1, and version 2 specifies an improved technique "XX", version 2
> could require that two version 2 terminals communicating with each other
> use "XX" instead of "X" even though both implement "X" for backward
> compatibility with version 1. A new version should always require
> backward compatibility by continuing to mandate fallback to mechanisms
> required in previous versions.

Because the only version information currently exchanged between all
endpoints is the H.245 protocol identifier--in particular, the version
of the H.323 Recommendation is not exchanged--I assume you are referring
to the version of the H.245 Recommendation "in use." And there's the
rub. The protocol identifier is practically useless because extensions
not in the root extension may be implemented at the vendor's discretion,
"shall" or not.

Case in point: Hasn't at least one vendor released product based on the
Determined H.245 version 2 syntax, which is different than the Decided
syntax? That means that even though this vendor's terminal advertises
"version 2," it does not recognize the extension additions that were
added after being Decided. Some may not need to be recognized, such as a
new field in a capability; others _shall_ be recognized and processed,
such as a new command. Therefore, an endpoint cannot assume that another
endpoint will recognize (and therefore process) _any_ extension
additions and must take this possible lack of behavior into
consideration. And this is not just the behavior of an obscure
implementation ;-). Correct me if I'm wrong, Dave, but I believe this is
also Dave Lindbergh's interpretation.

I talked with Bancroft Scott about this, and he said that a system that
uses ASN.1 usually requires implementations to encode all extension
additions in a particular version of the syntax for that system. IOW, an
implementor can't just encode the first 5 of a possible 9 extension
additions in a given version of a syntax tree. However, version
information about the syntax tree is not typically presented to the
receiver; therefore, the receiver cannot _expect_ a particular number of
extension additions to be present. (In addition to sequence fields, this
also applies to choices not in the root extension.) In other words, all
extension additions are in a sense optional (of course, there cannot be
a gap in a sequence of fields), and all implementations must be able to
handle this. Transmitters must not assume that a message (a choice) or
field (a choice or sequence component) not in the root extension will be
recognized by the receiver, and receivers must not treat the absence of
an extension addition as an error.

I don't like this. I would prefer that if an endpoint advertises that it
supports version N syntax, it supports _all_ of version N syntax, and
other endpoints can rely on that support. For example, if an endpoint
receives only 5 of the 9 extension additions defined in the version of
the H.245 syntax tree that the transmitting endpoint advertised that it
supports, it shall treat it as an error--a malformed message. Likewise,
a transmitting endpoint can assume that a receiver that advertises
support for version N syntax will recognize and process, according to
the applicable Recommendations, all extensions defined in that version
of the tree.

I believe that there is a serious ommission in the Recommendations about
what to do about extensions. We must come to some concensus about what
the rules are and document them. Soon. I meant to prepare a contribution
for Sunriver about this; however, I have not had the time due to
circumstances beyond my control.

Back to the original problem, since the only version information
exchanged between terminals is for H.245 and since receiving terminals
are free to implement whatever extensions they wish to, I go back to my
original assertion. A newer version of the H.245 Recommendation can
augment and clarify but cannot constrain previous versions.

Paul Long___________________________
Smith Micro Software, Inc.__________

More information about the sg16-avd mailing list