<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2651.65">
<TITLE>RE: On TD26 - Fast TCS and M/S negotiation in H.323v4</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>If they reject the call with cause 100, then it is their implementation that is</FONT>
<BR><FONT SIZE=2>broken.</FONT>
</P>

<P><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Paul Long [<A HREF="mailto:Plong@SMITHMICRO.COM">mailto:Plong@SMITHMICRO.COM</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Thursday, June 01, 2000 8:04 AM</FONT>
<BR><FONT SIZE=2>> To: ITU-SG16@MAILBAG.INTEL.COM</FONT>
<BR><FONT SIZE=2>> Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Francois,</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> We should not be taking a poll as to whether something would </FONT>
<BR><FONT SIZE=2>> break existing</FONT>
<BR><FONT SIZE=2>> implementations. What about vendors that we don't ask, that </FONT>
<BR><FONT SIZE=2>> don't respond,</FONT>
<BR><FONT SIZE=2>> or are out of the loop for some reason? A standard is a </FONT>
<BR><FONT SIZE=2>> contract of sorts.</FONT>
<BR><FONT SIZE=2>> Breaking contracts is a bad thing in part because future </FONT>
<BR><FONT SIZE=2>> contracts cannot be</FONT>
<BR><FONT SIZE=2>> depended on.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Paul Long</FONT>
<BR><FONT SIZE=2>> Smith Micro Software, Inc.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Francois Audet [<A HREF="mailto:audet@NORTELNETWORKS.COM">mailto:audet@NORTELNETWORKS.COM</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Thursday, June 01, 2000 7:34 AM</FONT>
<BR><FONT SIZE=2>> To: ITU-SG16@MAILBAG.INTEL.COM</FONT>
<BR><FONT SIZE=2>> Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> I fully agree with Orit.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> So far, I haven't heard of anybody that actually implemented clearing</FONT>
<BR><FONT SIZE=2>> the call</FONT>
<BR><FONT SIZE=2>> if both fastStart and h245Control are present in SETUP. I would argue,</FONT>
<BR><FONT SIZE=2>> it would</FONT>
<BR><FONT SIZE=2>> be a very bad implementation, regardless of what they interpreted the</FONT>
<BR><FONT SIZE=2>> spec</FONT>
<BR><FONT SIZE=2>> saying.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> This being said, it seems that it will not create any interoperability</FONT>
<BR><FONT SIZE=2>> problems.</FONT>
<BR><FONT SIZE=2>> The *worst* case scenario (here again, I haven't heard of anybody that</FONT>
<BR><FONT SIZE=2>> actually implemented it that way) is that the call would </FONT>
<BR><FONT SIZE=2>> proceed as fast</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> tunnelling (as per the spec) and ignore the fast start.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> The benefits of doing the fastStart and the fast tunnelling </FONT>
<BR><FONT SIZE=2>> at the same</FONT>
<BR><FONT SIZE=2>> time</FONT>
<BR><FONT SIZE=2>> far outweight the theoretical backward compatibility problems.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> If anybody wants to revoke the Osaka agreement, contributions in</FONT>
<BR><FONT SIZE=2>> Portland are</FONT>
<BR><FONT SIZE=2>> welcomed. ;^)</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</FONT>
<BR><FONT SIZE=2>> For help on this mail list, send "HELP ITU-SG16" in a message to</FONT>
<BR><FONT SIZE=2>> listserv@mailbag.intel.com</FONT>
<BR><FONT SIZE=2>> </FONT>
</P>

</BODY>
</HTML>