Paul,
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 -----
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