No concensus for ASN.1 extension support (was: Re: APC-1265)
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/
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*** *************************************************************************
Jim Toga wrote:
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).
Of course. I think this is obvious.
This is not to say that a new version cannot have required additional functionality.
I am referring to H.245. The version of H.323 is not exchanged between endpoints. Therefore, there is no such thing as an H.323 version-2 (or -3 or -4, etc.) endpoint as far as another endpoint can descern, and the version of H.245, Q.931, or RAS that an endpoint advertises does not imply which H.323 version the endpoint has implemented. Therefore, how can something be mandatory in one version of H.323 but not in another if the version is not observable?
But that's really a different, but just as important, issue. What I'm trying to say is that an implementation may signal support for any H.245 version and yet support whatever extensions it wishes or none at all. And remember that all _messages_ added after version 1 are extensions. There is no correlation between an endpoint's behavior and the value of the protocolIdentifier field in its termCapSet--this field is therefore useless. Don't depend on an endpoint that advertises support for H.245 version 3, for example, to exhibit any behavior required by H.245 version 3. This is because--and I wish it weren't true--an endpoint is not required to process all or any of the sequence extension additions or choice extensions defined in the version of H.245 for which it indicates support.
Mr. Skran's proposal in APC-1265 that a certain form of H.245 DTMF signaling be made mandatory for H.323v2, where it is not mandatory for v1, is a case in point of the problems with versioning and ASN.1 extensions in H.245. Let's take a pont-to-point call, for example. If a terminal cannot know upon what version of H.323 the remote terminal is based and if the advertised H.245 version of the remote terminal is meaningless, how can it depend on the remote terminal recognizing and processing a particular form of H.245 DTMF signaling? The remote terminal may ignore the new syntax either because it was not defined for the version of H.245 that it supports or because the implementors simply chose not to recognize the extension additions upon which it is based.
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
Right, but we are informally signaling version information out-of-band at interops. In the field, however, there is no such thing as "version 2." Entities cannot depend on any version-specific behavior because, in H.323's case, the version is not available, and in H.245's case, the version is available but meaningless. Therefore, Recommendations shall be augmented or clarified in subsequent versions, but shall not be constrained. Version N+1 may include additional requirements relative to version N but shall not further constrain any version-N behavior, because N is either not known or is meaningless to another entity.
It is curious that anyone would implement v2 when it isn't finalized.
I agree.
For that matter, much of v1 isn't implemented by most of the vendors currently showing their products.
Again, it sounds like you are talking about the H.323, not H.245, although the same thing can be said about H.245.
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.
Precisely--there are no rules. I'd much prefer rules to the interoperability problems I foresee when we start having implementations out there of different versions trying to talk to each other. We tried it, already, with H.324, using H.245 version 2 in a world of version-1's. We backed off because of the differing interpretations as to what was required of both the transmitting and receiving terminals.
I would be happier if we required that an endpoint signaling support for version N of H.245, truely supported Decided version N of H.245. Specifically, it did not encode any extensions defined in a subsequent version, it encoded all extension additions defined in version N for a particular sequence, and it treated missing extension additions as a semantic error. I believe we would have a lot fewer problems in the months ahead if this would happen.
-- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/
participants (2)
-
Jim Toga -
Paul Long