Time for me to jump in :-0

This is getting close. One potential problem surrounds intermediaries (for example GKs in a GK-routed call). We need to indicate what exactly is the expected behaviour of 'M' entities when they get 'N' type messages (that look like 'M' messages with extentions.)

I would contend that the reality of the situation is that all we can stipulate, is that the 'M' entities don't crash in the presense of 'N' messages. We can't mandate that 'M's pass new (uninterpreted/not-understood) data on. Obviously if there is an existing opaque field defined, this _shall_ be forwarded.

comments?

jimt. At 08:15 PM 1/20/99 -0800, you wrote:

Dave, Pete, et al.,

We need to be very clear about how products of different versions can be interoperable. Terms such as "compatible," "backward compatible," and "supports" are too ambiguous to be useful in normative text. Here's my attempt at splitting hairs. The first paragraph is taken straight from

Dave's

email.

Products claiming compliance with Version 2 of H.323 shall comply with all of the mandatory requirements of this document, H.323 (1998), which references H.225.0 (1998) and H.245 (1998). The protocol identifiers used in messages defined in H.225.0 (1998) and H.245 (1998) are specified in those recommendations.

Interoperability between products of possibly different versions is

assured by

the following. Note that what is commonly referred to as a "message" is an ASN.1 component of a choice type of typically the first or second level of an ASN.1 syntax tree. Therefore, in the following paragraph, a "message" that is not a component of the extension root is treated the same as any other choice extension addition.

Assume that an H.323vM product and an H.323vN product are in communication with each other, where M and N are version numbers and M <= N. The H.323 version number shall be taken to be the same as the version number indicated in the H.225.0 protocolIdentifier field. Each product shall encode and

decode

the H.245 and H.225.0 ASN.1 syntax trees defined in their respective version of H.323. The H.323vM product shall behave according to H.323vM and shall assume that the H.323vN product also behaves according to H.323vM, with these two exceptions:

•   the H.323vN product encodes values for the protocolIdentifier fields
  

for H.323vN, not H.323vM, and

•   the H.323vN product encodes ASN.1 sequence and choice extension
  

additions defined in H.323vN that may not be defined in H.323vM. Although the H.323vM product shall parse extension additions defined in later versions of H.323 (as prescribed by ASN.1), it shall not recognize or otherwise act upon them. Therefore, the H.323vN product shall not rely on behavior in the H.323vM product that is based on the value or presence of extension additions defined in H.323vN but not H.323vM. This in effect

forces

the H.323vN product to behave like an H.323vM product. In addition, if a product is relaying an ASN.1 value, it shall encode the same value that it decoded, regardless of its own version or the version of the value's sender.

Paul Long Smith Micro Software, Inc.

+1-503-264-8816(voice) Intel - Hillsboro, OR mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41