Rich,
I know I'm fighting a losing battle, so I'll be quiet. Just realize that (one last parting shot :-) ) 1. this change risks undesired behavior (call termination) or at least undefined behavior (EP crashes? EP accepts?), 2. there is really no way to know whether this breaks existing implementations (you can't just ask 12 people around a table or 100 people on an email reflector because many may not actually know the answer and many more didn't even hear the question), and 3. there are alternatives that are completely safe.
Paul Long Smith Micro Software, Inc. "Primum non nocere"
-----Original Message----- From: Rich Bowen [mailto:rkbowen@CISCO.COM] Sent: Thursday, June 08, 2000 2:21 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: AW: H.225.0 v4 inconsistencies/errors found
The backward compatibility issue was debated last year on the mailing lists and in Santiago (5/99). No implementor claimed to have a backward compatibility problem, and it was agreed in Santiago that octet 3a would be allowed, as shown in H.225.0 v3. However, now the text is inconsistent with itself, in that it allows octet 3a but says that the extension bit shall be set to 1, thus indicating that octet 3a is not present. This is an error in v3 that needs to be corrected to indicate that the value may be either 0 or 1 to indicate the presence of octet 3a.
- Rich
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com