RE: fastStart element in all Q.931 messages up to and including ConnectPaul,
I have an idea about how to improve H.323 interoperability and inter-version compatibility or at least raise the visibility of these issues early in the standards process. You know how IETF RFCs and IDs are required to discuss security considerations, even if there are none? Here's the description of this in RFC2223:
9. Security Considerations Section All RFCs must contain a section near the end of the document that discusses the security considerations of the protocol or procedures that are the main topic of the RFC.
How about requiring or at least strongly recommending that authors add a section to all APCs and TDs that discusses Interoperability Considerations? For example, the APC that proposed requiring v4 EPs to use H.245 Tunneling when Fast Connect is used would have had a section something like this:
x. Interoperability Considerations This proposal precludes v4 and subsequent EPs from interoperating with pre-v4 EPs that support Fast Connect but do not support H.245 Tunneling. This proposal also prevents pre-v4 EPs from dependably interoperating with v4 and subsequent EPs when switching from H.245 Tunneling to a separate H.245 channel because a v4-or-subsequent EP may or may not support this switching and a pre-v4 EP which attempts to switch has no way of knowing this ahead of time. The author believes that these implementations are either non-existent or extremely rare and therefore impact on interoperability is minimized.
This section would force an author to stop and consider interoperability (not that they aren't already). He or she might then reconsider submitting the contribution altogether, might modify the proposal to improve interoperability, or at least would be more aware of the impact it would have on this critical issue. It would also improve understanding by the contribution's audience because the author would presumably have a better understanding of the issues than the reader.
At minimum, this should be the placeholder in all contributions:
x. Interoperability Considerations Interoperability considerations are not discussed in this contribution.
And this indicates that there are no problems, which would hopefully be the rule:
x. Interoperability Considerations There are no known interoperability considerations.
This section should be added to boilerplates. If found missing during presentation, the editor or another attendee might point this out in order to prompt discussion or a follow-up TD on interoperability.
Paul Long ipDIalog