<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: On TD26 - Fast TCS and M/S negotiation in H.323v4</TITLE>
<META content="text/html; charset=windows-1252" http-equiv=Content-Type>
<META content="MSHTML 5.00.3013.2600" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial>Francois,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial>I agree that the behavior is desirable, but I still argue
that it will break backward compatibility. If we can agree with a new
field "earlyH245" as a special field for SETUP to do essentially the same thing,
but only for V4, I would be quite happy-- we get the same end result without V3
and V2 compatibility issues.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial>I do not want to wait until Portland. The Whitepaper
drafts are due before then and I hope that that meeting will be focused on only
critical issues in H.323 and that most of our time will be spent on further
development of Annexes and perhaps forward thinking on V5 :-)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial>Paul</FONT></DIV>
<DIV> </DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A href="mailto:audet@NORTELNETWORKS.COM"
title=audet@NORTELNETWORKS.COM>Francois Audet</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A
href="mailto:ITU-SG16@mailbag.cps.intel.com"
title=ITU-SG16@mailbag.cps.intel.com>ITU-SG16@mailbag.cps.intel.com</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Thursday, June 01, 2000 8:33
AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: On TD26 - Fast TCS and M/S
negotiation in H.323v4</DIV>
<DIV><BR></DIV>
<P><FONT size=2>I fully agree with Orit.</FONT> </P>
<P><FONT size=2>So far, I haven't heard of anybody that actually implemented
clearing the call</FONT> <BR><FONT size=2>if both fastStart and h245Control
are present in SETUP. I would argue, it would</FONT> <BR><FONT size=2>be a
very bad implementation, regardless of what they interpreted the spec
</FONT><BR><FONT size=2>saying.</FONT> </P>
<P><FONT size=2>This being said, it seems that it will not create any
interoperability 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 proceed as fast
</FONT><BR><FONT size=2>tunnelling (as per the spec) and ignore the fast
start.</FONT> </P>
<P><FONT size=2>The benefits of doing the fastStart and the fast tunnelling at
the same time</FONT> <BR><FONT size=2>far outweight the theoretical backward
compatibility problems.</FONT> </P>
<P><FONT size=2>If anybody wants to revoke the Osaka agreement, contributions
in Portland are</FONT> <BR><FONT size=2>welcomed. ;^)</FONT> </P>
<P><FONT size=2>> -----Original Message-----</FONT> <BR><FONT size=2>>
From: Orit Levin [<A
href="mailto:orit@RADVISION.COM">mailto:orit@RADVISION.COM</A>]</FONT>
<BR><FONT size=2>> Sent: Wednesday, May 31, 2000 8:32 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>> Hi Paul and all the others!</FONT> <BR><FONT size=2>> Here it
is (and it is not surprising for those, participated in Osaka</FONT> <BR><FONT
size=2>> meeting).</FONT> <BR><FONT size=2>> I believe, that it is the
last moment to clear the confusion </FONT><BR><FONT size=2>> in the
least</FONT> <BR><FONT size=2>> harmful way (even on the expense of
THEORETICAL H.323v.2 "strict"</FONT> <BR><FONT size=2>>
implementations).</FONT> <BR><FONT size=2>> RADVision definitely votes for
allowing Fast Connect and </FONT><BR><FONT size=2>> H.245 tunneling
in</FONT> <BR><FONT size=2>> Setup, supporting by that TD-26.</FONT>
<BR><FONT size=2>> Best Regards,</FONT> <BR><FONT size=2>> Orit
Levin</FONT> <BR><FONT size=2>> RADVision Inc.</FONT> <BR><FONT size=2>>
575 Corporate Drive Suite 420</FONT> <BR><FONT size=2>> Mahwah, NJ
07430</FONT> <BR><FONT size=2>> Tel: 1 201 529 4300 (230)</FONT>
<BR><FONT size=2>> Fax: 1 201 529 3516</FONT> <BR><FONT size=2>>
www.radvision.com</FONT> <BR><FONT size=2>> orit@radvision.com</FONT>
<BR><FONT size=2>> -----Original Message-----</FONT> <BR><FONT size=2>>
From: Paul E. Jones <paulej@PACKETIZER.COM></FONT> <BR><FONT size=2>>
To: ITU-SG16@MAILBAG.INTEL.COM <ITU-SG16@MAILBAG.INTEL.COM></FONT>
<BR><FONT size=2>> Date: Wednesday, May 31, 2000 1:46 AM</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>> >Pete,</FONT> <BR><FONT size=2>>
></FONT> <BR><FONT size=2>> >If we could follow such logic, I would
agree that this </FONT><BR><FONT size=2>> procedure would be</FONT>
<BR><FONT size=2>> >worth perusing. Unfortunately, the inclusion
of fastStart </FONT><BR><FONT size=2>> and tunneled</FONT> <BR><FONT
size=2>> >H.245 messages in the SETUP message is not defined.
There </FONT><BR><FONT size=2>> is no way to</FONT> <BR><FONT size=2>>
>predict how a V2 device will behave when receiving these </FONT><BR><FONT
size=2>> messages. I like</FONT> <BR><FONT size=2>> >the idea,
but I'm afraid we will compromise backward compatibility by</FONT> <BR><FONT
size=2>> >including it.</FONT> <BR><FONT size=2>> ></FONT>
<BR><FONT size=2>> >Let's assume a V2 device does *not* recognize the
tunneled </FONT><BR><FONT size=2>> H.245 in SETUP</FONT> <BR><FONT
size=2>> >(ignores it), but accepts the Fast Connect proposal.
</FONT><BR><FONT size=2>> Assume, also, that in</FONT> <BR><FONT
size=2>> >the CONNECT message, the endpoint includes the fastStart
</FONT><BR><FONT size=2>> element *and* a</FONT> <BR><FONT size=2>>
>tunneled TCS message. What could the calling endpoint
</FONT><BR><FONT size=2>> *safely* assume?</FONT> <BR><FONT size=2>>
></FONT> <BR><FONT size=2>> >Assume that CONNECT was the first
message received following </FONT><BR><FONT size=2>> the SETUP if</FONT>
<BR><FONT size=2>> >that helps complicate matters further for you.
:-)</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> >I just
need further convincing.</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT
size=2>> >Paul</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT
size=2>> >----- Original Message -----</FONT> <BR><FONT size=2>>
>From: "Pete Cordell" <pete@TECH-KNOW-WARE.COM></FONT> <BR><FONT
size=2>> >To: <ITU-SG16@mailbag.cps.intel.com></FONT> <BR><FONT
size=2>> >Sent: Tuesday, May 30, 2000 2:40 PM</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>> >> RE: On TD26 - Fast TCS and M/S
negotiation in H.323v4Hi </FONT><BR><FONT size=2>> Paul, Francois,</FONT>
<BR><FONT size=2>> >and</FONT> <BR><FONT size=2>> >>
others,</FONT> <BR><FONT size=2>> >></FONT> <BR><FONT size=2>>
>> I think it is important that we make it work, but as you
</FONT><BR><FONT size=2>> say, it has to</FONT> <BR><FONT size=2>>
be</FONT> <BR><FONT size=2>> >> reliable and any burden of insuring
backwards </FONT><BR><FONT size=2>> compatibility has to be</FONT>
<BR><FONT size=2>> >placed</FONT> <BR><FONT size=2>> >> on the
newer EP. In this case it is primarily an issue </FONT><BR><FONT
size=2>> for the calling</FONT> <BR><FONT size=2>> >EP.</FONT>
<BR><FONT size=2>> >></FONT> <BR><FONT size=2>> >> As I see
it, (and I'm sure you'll correct me if I'm not </FONT><BR><FONT size=2>>
seeing it right!)</FONT> <BR><FONT size=2>> >> when there is H.245 in
the SETUP message, then the called </FONT><BR><FONT size=2>> endpoint
can</FONT> <BR><FONT size=2>> >> either ignore the H.245, or accept
it. (It could clear </FONT><BR><FONT size=2>> the call, but</FONT>
<BR><FONT size=2>> I'll</FONT> <BR><FONT size=2>> >> ignore that
one for the time being.) There is also the </FONT><BR><FONT size=2>>
case where it</FONT> <BR><FONT size=2>> >> decides that the H.245
takes precedence over fast start.</FONT> <BR><FONT size=2>> >></FONT>
<BR><FONT size=2>> >> Knowing whether fast start has been accepted is
fairly </FONT><BR><FONT size=2>> straight forward.</FONT> <BR><FONT
size=2>> >></FONT> <BR><FONT size=2>> >> I think the called
endpoint has a very good idea of what </FONT><BR><FONT size=2>> decision
was</FONT> <BR><FONT size=2>> >taken</FONT> <BR><FONT size=2>>
>> with regard to the H.245 based on the reply from the </FONT><BR><FONT
size=2>> called endpoint.</FONT> <BR><FONT size=2>> >></FONT>
<BR><FONT size=2>> >> - If the reply message in which the fast start
information </FONT><BR><FONT size=2>> is contained</FONT> <BR><FONT
size=2>> >> contains H.245, then it can assume that the called EP
</FONT><BR><FONT size=2>> accepted the H.245.</FONT> <BR><FONT size=2>>
>> The H.245 state about which channels are open will be
</FONT><BR><FONT size=2>> updated according</FONT> <BR><FONT size=2>>
to</FONT> <BR><FONT size=2>> >> the fast start parameters.</FONT>
<BR><FONT size=2>> >></FONT> <BR><FONT size=2>> >> - If the
reply message in which the fast start information </FONT><BR><FONT size=2>>
is contained</FONT> <BR><FONT size=2>> >> contains no H.245, then it
has probably ignored the H.245.</FONT> <BR><FONT size=2>> >></FONT>
<BR><FONT size=2>> >> --- If H.245 tunneling is enabled, but the
calling </FONT><BR><FONT size=2>> endpoint believes that</FONT> <BR><FONT
size=2>> >> the called endpoint ignored its H.245 in the SETUP
</FONT><BR><FONT size=2>> message, then it can</FONT> <BR><FONT size=2>>
>> re-transmit its capability set when it becomes OK to do so
</FONT><BR><FONT size=2>> under the</FONT> <BR><FONT size=2>>
>normal</FONT> <BR><FONT size=2>> >> fast start/H.245 rules.
(It should probably modify the </FONT><BR><FONT size=2>> sequence
number</FONT> <BR><FONT size=2>> >> before doing this.)</FONT>
<BR><FONT size=2>> >></FONT> <BR><FONT size=2>> >> --- In
the case where the called EP actually did accept </FONT><BR><FONT size=2>>
the H.245 but did</FONT> <BR><FONT size=2>> >> not reply as expected,
the called EP will receive a second </FONT><BR><FONT size=2>>
capability</FONT> <BR><FONT size=2>> set.</FONT> <BR><FONT size=2>>
>> However, endpoints should be able to handle this as this
</FONT><BR><FONT size=2>> is a standard</FONT> <BR><FONT size=2>>
>H.245</FONT> <BR><FONT size=2>> >> procedure.</FONT> <BR><FONT
size=2>> >></FONT> <BR><FONT size=2>> >> So as long as V4
endpoints use this kind of logic then I </FONT><BR><FONT size=2>> think it
is safe</FONT> <BR><FONT size=2>> >> for them to combine both H.245
and fast start.</FONT> <BR><FONT size=2>> >></FONT> <BR><FONT
size=2>> >> Perhaps we should document the above more formally for
V4, </FONT><BR><FONT size=2>> and maybe say</FONT> <BR><FONT size=2>>
>> that if a V4 EP wants to accept both fast start and H.245
</FONT><BR><FONT size=2>> Cap tunnelling</FONT> <BR><FONT size=2>>
>at</FONT> <BR><FONT size=2>> >> the same time then it SHALL put
the fast start and H.245 </FONT><BR><FONT size=2>> in the same</FONT>
<BR><FONT size=2>> >> message.</FONT> <BR><FONT size=2>>
>></FONT> <BR><FONT size=2>> >> Does this sound in any way
reasonable?</FONT> <BR><FONT size=2>> >></FONT> <BR><FONT size=2>>
>> Pete.</FONT> <BR><FONT size=2>> >></FONT> <BR><FONT
size=2>> >> =============================================</FONT>
<BR><FONT size=2>> >> Pete Cordell</FONT> <BR><FONT size=2>>
>> pete@tech-know-ware.com</FONT> <BR><FONT size=2>> >>
=============================================</FONT> <BR><FONT size=2>>
>></FONT> <BR><FONT size=2>> >> ----- Original Message
-----</FONT> <BR><FONT size=2>> >> From: Paul E. Jones</FONT>
<BR><FONT size=2>> >> To: Francois Audet ; Mailing list for parties
associated </FONT><BR><FONT size=2>> with ITU-T Study</FONT> <BR><FONT
size=2>> >> Group 16 ; pete</FONT> <BR><FONT size=2>> >> Cc:
Alexander (Sasha) Ruditsky ; Dale Skran</FONT> <BR><FONT size=2>> >>
Sent: 30 May 2000 08:20</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>> >> But the possibility exists that a V2 device may accept
</FONT><BR><FONT size=2>> both, reject one</FONT> <BR><FONT size=2>>
or</FONT> <BR><FONT size=2>> >> the other, or reject both since a
SETUP containing </FONT><BR><FONT size=2>> fastStart and tunneled</FONT>
<BR><FONT size=2>> >> H.245 is "illegal". Heck, a "strict"
endpoint may even </FONT><BR><FONT size=2>> drop the call,</FONT> <BR><FONT
size=2>> but</FONT> <BR><FONT size=2>> >I</FONT> <BR><FONT
size=2>> >> suspect that nobody would go that far.</FONT> <BR><FONT
size=2>> >></FONT> <BR><FONT size=2>> >> If fastStart was
accepted and the remote end returns the </FONT><BR><FONT size=2>> tunneling
flag</FONT> <BR><FONT size=2>> >set</FONT> <BR><FONT size=2>>
>> to TRUE, how do you know if it did or did not process the
</FONT><BR><FONT size=2>> H.245 message</FONT> <BR><FONT size=2>>
in</FONT> <BR><FONT size=2>> >> the SETUP? I'm not convinced
that this procedure is going to make</FONT> <BR><FONT size=2>>
>everybody</FONT> <BR><FONT size=2>> >> happy. (Same could
be said if fastStart is not accepted, </FONT><BR><FONT size=2>> I
suppose.)</FONT> <BR><FONT size=2>> >></FONT> <BR><FONT size=2>>
>> My concern is that this issue is potentially damaging to some</FONT>
<BR><FONT size=2>> >> implementations. If all of the vendors
have no problem </FONT><BR><FONT size=2>> with this change,</FONT>
<BR><FONT size=2>> >> then I can live with it. Cisco has no
objection, but I </FONT><BR><FONT size=2>> would like to</FONT> <BR><FONT
size=2>> >> solicit the input of others-- changes like this, even as
</FONT><BR><FONT size=2>> good as they</FONT> <BR><FONT size=2>>
are,</FONT> <BR><FONT size=2>> >> could cause serious
problems.</FONT> <BR><FONT size=2>> >></FONT> <BR><FONT size=2>>
>> It appears that we've already made a similar "mistake" by
</FONT><BR><FONT size=2>> allowing H.245</FONT> <BR><FONT size=2>>
>> procedures to be done in parallel to fastConnect by </FONT><BR><FONT
size=2>> removing the clause</FONT> <BR><FONT size=2>> >that</FONT>
<BR><FONT size=2>> >> says that if we start H.245, fast connect is
terminated. </FONT><BR><FONT size=2>> That text was</FONT> <BR><FONT
size=2>> >> removed, because there was a race condition that could
</FONT><BR><FONT size=2>> occur, which could</FONT> <BR><FONT size=2>>
>> result in interoperability problems. The right solution
</FONT><BR><FONT size=2>> probably should</FONT> <BR><FONT size=2>>
>> have been to document the race condition and tell people
</FONT><BR><FONT size=2>> "don't do that".</FONT> <BR><FONT size=2>>
>> However, we made the change and now some manufacturers have
serious</FONT> <BR><FONT size=2>> >backward</FONT> <BR><FONT size=2>>
>> compatibility problems. I don't want to make the same
</FONT><BR><FONT size=2>> mistake again.</FONT> <BR><FONT size=2>>
>></FONT> <BR><FONT size=2>> >> Comments?</FONT> <BR><FONT
size=2>> >></FONT> <BR><FONT size=2>> >> Paul</FONT>
<BR><FONT size=2>> >></FONT> <BR><FONT size=2>> >> -----
Original Message -----</FONT> <BR><FONT size=2>> >> From: Francois
Audet</FONT> <BR><FONT size=2>> >> To: 'Paul E. Jones' ; Mailing list
for parties associated </FONT><BR><FONT size=2>> with ITU-T</FONT>
<BR><FONT size=2>> Study</FONT> <BR><FONT size=2>> >> Group 16 ;
pete</FONT> <BR><FONT size=2>> >> Cc: Alexander (Sasha) Ruditsky ;
Dale Skran</FONT> <BR><FONT size=2>> >> Sent: Monday, May 29, 2000
11:00 PM</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>> >> Yes, a
few comments:</FONT> <BR><FONT size=2>> >> 1 It seems that all
current implementations that we could think of</FONT> <BR><FONT size=2>>
>> would simply ignore the tunnelling information if the
fastStart</FONT> <BR><FONT size=2>> >> element is
present. This means, that there would be no</FONT> <BR><FONT size=2>>
>> interoperability problems. Fast start would be
</FONT><BR><FONT size=2>> sucessfull, but not</FONT> <BR><FONT size=2>>
>> tunnelling, which would mean that tunnelling would have
to happen</FONT> <BR><FONT size=2>> >> after the SETUP
message, as per H.323v2 and v3.</FONT> <BR><FONT size=2>> >> 2 There
is a small possibility that an implementation </FONT><BR><FONT size=2>>
would acutally</FONT> <BR><FONT size=2>> >> give priority
to the tunnelling information instead of </FONT><BR><FONT size=2>> the
fastStart</FONT> <BR><FONT size=2>> >> element (v2 and v3
don't say what would happen if they </FONT><BR><FONT size=2>> are
present,</FONT> <BR><FONT size=2>> they</FONT> <BR><FONT size=2>>
>> just say not to do it). In that particular case, the
</FONT><BR><FONT size=2>> fastStart would</FONT> <BR><FONT size=2>>
>fail</FONT> <BR><FONT size=2>> >> but the tunnelling
would be successful. So the worst </FONT><BR><FONT size=2>> case scenario
is</FONT> <BR><FONT size=2>> >that</FONT> <BR><FONT size=2>>
>> fastStart fails, but "fast tunnelling" is successful.
</FONT><BR><FONT size=2>> This doesn't seem</FONT> <BR><FONT size=2>>
>to</FONT> <BR><FONT size=2>> >> me to be a real
interoperability problem. In any case, </FONT><BR><FONT size=2>> it seems
that</FONT> <BR><FONT size=2>> >case</FONT> <BR><FONT size=2>>
>> 1 is much more likely.</FONT> <BR><FONT size=2>>
>></FONT> <BR><FONT size=2>> >></FONT> <BR><FONT size=2>>
>> > -----Original Message-----</FONT> <BR><FONT size=2>> >>
> From: Paul E. Jones [<A
href="mailto:paulej@packetizer.com">mailto:paulej@packetizer.com</A>]</FONT>
<BR><FONT size=2>> >> > Sent: Monday, May 29, 2000 7:46 PM</FONT>
<BR><FONT size=2>> >> > To: Mailing list for parties associated
with ITU-T Study</FONT> <BR><FONT size=2>> >> > Group 16;
pete</FONT> <BR><FONT size=2>> >> > Cc: Audet, Francois
[SC9:4K02:EXCH]; Alexander (Sasha) </FONT><BR><FONT size=2>> Ruditsky;
Dale</FONT> <BR><FONT size=2>> >> > Skran</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>> >> > Pete,
Sasha, Francois, Dale, et al,</FONT> <BR><FONT size=2>> >>
></FONT> <BR><FONT size=2>> >> > I have concerns about this
document that differ from Pete's.</FONT> <BR><FONT size=2>> >> >
However, since</FONT> <BR><FONT size=2>> >> > discussion on this
document has started, I thought I might as</FONT> <BR><FONT size=2>>
>> > well express</FONT> <BR><FONT size=2>> >> > my
concerns now while the material is fresh on people's minds.</FONT> <BR><FONT
size=2>> >> ></FONT> <BR><FONT size=2>> >> > The issue
has to do with the very first sentence of the</FONT> <BR><FONT size=2>>
>> > proposal, which says</FONT> <BR><FONT size=2>> >> >
to strike "shall not" and replace it with "may". So, V2</FONT> <BR><FONT
size=2>> >> > devices shall not</FONT> <BR><FONT size=2>>
>> > send a fastStart element and an H.245 message in SETUP,
but</FONT> <BR><FONT size=2>> >> > V4 may. This</FONT>
<BR><FONT size=2>> >> > seems to be a serious backward
compatibility issue. If a V2</FONT> <BR><FONT size=2>> >> >
device were to</FONT> <BR><FONT size=2>> >> > receive a SETUP
containing fastStart and an encapsulated</FONT> <BR><FONT size=2>> >>
> H.245 message, what</FONT> <BR><FONT size=2>> >> > would it
do? I believe the behavior is not defined.</FONT> <BR><FONT size=2>>
>> ></FONT> <BR><FONT size=2>> >> > Would somebody like
to comment?</FONT> <BR><FONT size=2>> >> ></FONT> <BR><FONT
size=2>> >> > Paul</FONT> <BR><FONT size=2>> >>
></FONT> <BR><FONT size=2>> >> ... cut ...</FONT> <BR><FONT
size=2>> >></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>
<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><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></BLOCKQUOTE></BODY></HTML>