Just a note of clarification - H.225.0 (both Q.931 derived messages and RAS) includes a protocol identifier for versioning......
You are correct in that a newer version of the protocol shall not require older versions to comply with new functionality (and must provide backward compatiblity). This is not to say that a new version cannot have required additional functionality.
In terms of 'version 2' compliance, I believe that when interopability trials a run to test this, any non-conforming implementation will be high-lighted. It is curious that anyone would implement v2 when it isn't finalized. For that matter, much of v1 isn't implemented by most of the vendors currently showing their products.
If vendors want to utilize some of the constructs from v2 in their v1 implementations (and other entities recognize and respond to them) there is no 'rule' against this.
Regards,
jimt.
At 07:26 PM 9/3/97 -0500, you wrote:
Toby Nixon wrote:
Paul Long wrote:
- 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___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/
************************************************************************* *** +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*** *************************************************************************