RE: fastStart element in all Q.931 messages up to and including ConnectPaul,
That might be a good idea, but I suspect the practice would be to copy whatever words somebody else used in a different APC :-)
I would definitely like to see the authors of APCs look through the entire H.323 document to look for "interaction" problems. I'll have to confess that I have failed to do that myself, so I can't complain at all about this :-)
While editing, I have tried to double-check contributor's work and fit it into H.323 in such a way that things do not break. However, considering the amount of work that I spend just copying and pasting text, I am amazed that the document looks as good as it does. Rich Bowen (editor of H.225.0) and I literally stayed up the entire night the second Monday night of the last meeting in Geneva adding all of the approved material to H.323 and H.225.0. We tried very hard to make sure that all of the field names matched, nothing was missing, etc. I had not planned on spending the night in front of the computer screen with a Coke on the desk, but there was literally that much work to do.
This was an experience that I have had a few times.
Unfortunately, spending such long periods of time on the computer forces the document quality to go down. Some contributors, such as Francois, have always done an excellent job at giving me complete text that requires hardly any work in order to integrate into the document. For other contributions, I find myself creating text, correcting inconsistencies, looking up references, etc. It's an error-prone process that I would like to see stopped.
At the Osaka meeting, I told the Rapporteur at the beginning of the meeting that I was not going to have the H.323 and Implementers text available for review at the end of the meeting: I meant it. I don't think he believed me, as he looked totally surprised at the end of the meeting when I didn't have the text ready. (I did have much of the IG done, but not all-- and none of the H.323 text.) I took a little more time to get it done and (hopefully) it's in better shape as a result. However, I have received a few (much appreciated) e-mails pointing out errors, so there may still be a few more errors.
I honestly believe the best way to make the text as good as it can be is to invite people to read the H.323 document. I have always been consistent in making sure that the H.323v4 document contains revision marks for every change since H.323v3. If people would just read that text, it would be extremely helpful. Interested parties should make sure that what is written is clear and does not break what's in H.323v1/2/3. (Actually, I'm not so concerned about v1: I've mentioned before that I think it is about time we consider deprecating it: perhaps in a couple of years.)
I can easily correct editorial errors. If there is an error in the procedure, I can contact the contributor of the particular text and work out any issues. If something looks completely flawed, we can take it right out of the H.323v4 document: I'd much rather remove text than to approve something that is flawed (even if I edited it at 4:15am).
Paul
----- Original Message ----- From: Paul Long To: ITU-SG16@mailbag.cps.intel.com Sent: Saturday, November 04, 2000 11:54 AM Subject: Suggestion for future contributions
Paul,
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