From mailnull@www1.ietf.org Tue Jun 3 09:10:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03215 for ; Tue, 3 Jun 2003 09:10:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53DAVs12732 for speechsc-archive@odin.ietf.org; Tue, 3 Jun 2003 09:10:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53DAUB12729 for ; Tue, 3 Jun 2003 09:10:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03193 for ; Tue, 3 Jun 2003 09:10:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NBWp-0005nO-00 for speechsc-web-archive@ietf.org; Tue, 03 Jun 2003 09:08:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NBWp-0005nK-00 for speechsc-web-archive@ietf.org; Tue, 03 Jun 2003 09:08:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53DALB12720; Tue, 3 Jun 2003 09:10:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53D9SB12673 for ; Tue, 3 Jun 2003 09:09:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03175 for ; Tue, 3 Jun 2003 09:09:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NBVp-0005mz-00 for speechsc@ietf.org; Tue, 03 Jun 2003 09:07:37 -0400 Received: from smtp-102-tuesday.nerim.net ([62.4.16.102] helo=kraid.nerim.net) by ietf-mx with esmtp (Exim 4.12) id 19NBVo-0005mw-00 for speechsc@ietf.org; Tue, 03 Jun 2003 09:07:36 -0400 Received: from weasel.hq.eloquant.com (styx.eloquant.com [80.65.227.37]) by kraid.nerim.net (Postfix) with ESMTP id E19B440FF3; Tue, 3 Jun 2003 15:09:22 +0200 (CEST) Received: from polo (polo.hq.eloquant.com [192.168.0.131]) by weasel.hq.eloquant.com (Postfix) with SMTP id D86653B6CA; Tue, 3 Jun 2003 09:13:09 -0400 (EDT) Reply-To: From: "Brian Wyld" To: "Sarvi Shanmugham" , Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC Date: Tue, 3 Jun 2003 15:05:17 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3ECBEFBE.3000507@cisco.com> Content-Transfer-Encoding: 7bit Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Sarvi, My initial feedback (before having read the doc in detail) is that I was somewhat surprised to see the use of SIP messages for the media setup. This did not corrospond to what I had thought was the trend of the discussion here, to bypass resuse of such a media protocol and create directly a new speechsc protocol for this also. (which would probably use SDP however). The major issue I see with your use of SIP INVITE/BYE/REINVITE etc is that adds a lot of _potential_ complexity (it pulls in an entire SIP stack), for very little gain in real functionality. I really don't see the use in having all the potential SIP stuff and then having to define exactly what is and isn't allowed..... I'd go for a simpler model where we just define new speechsc messages to setup/control the media that are specific to speechsc..... Brian [Brian Wyld] [brian.wyld@eloquant.com] [Directeur General R&D] [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com] [advanced solutions for telecoms and IT services] > -----Message d'origine----- > De : speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]De la part > de Sarvi Shanmugham > Envoye : Wednesday, May 21, 2003 23:30 > A : speechsc@ietf.org > Objet : [Speechsc] Protpcol proposal for SPEECHSC > > > > > Hi > Please find attached a proposal for a SPEECHSC protocol. This > leverages the MRCP specification. But removes the tunnelling aspects of > the protocol. I have also submitted this document to the internet drafts > repository and should be available from there soon. > > The current version does not address SI and SV aspects of the > requirements document. But addresses most of the others. This document > is meant to be a starting point for a possible direction that the > SPEECHSC protocol could take. Based on interest and comments received, > we can proceed to add SI and SV capabilities in a following version of > the draft. > > Any thoughts. > > Sarvi > _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Jun 3 10:14:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06367 for ; Tue, 3 Jun 2003 10:14:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53EDe918096 for speechsc-archive@odin.ietf.org; Tue, 3 Jun 2003 10:13:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53EDeB18093 for ; Tue, 3 Jun 2003 10:13:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06291 for ; Tue, 3 Jun 2003 10:13:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NCVv-0006Nz-00 for speechsc-web-archive@ietf.org; Tue, 03 Jun 2003 10:11:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NCVv-0006Nw-00 for speechsc-web-archive@ietf.org; Tue, 03 Jun 2003 10:11:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53EDZB18082; Tue, 3 Jun 2003 10:13:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53ECeB18015 for ; Tue, 3 Jun 2003 10:12:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06172 for ; Tue, 3 Jun 2003 10:12:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NCUy-0006NJ-00 for speechsc@ietf.org; Tue, 03 Jun 2003 10:10:48 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19NCUx-0006Md-00 for speechsc@ietf.org; Tue, 03 Jun 2003 10:10:47 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h53EC43I010041 for ; Tue, 3 Jun 2003 07:12:04 -0700 (PDT) Received: from [10.32.254.189] (stealth-10-32-254-189.cisco.com [10.32.254.189]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AES25258; Tue, 3 Jun 2003 07:12:03 -0700 (PDT) Date: Tue, 03 Jun 2003 10:11:46 -0400 From: "David R. Oran" To: speechsc@ietf.org Message-ID: <170170328.1054635106@[10.32.254.189]> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Speechsc] Meeting in Vienna Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, You may have noted that SPEECHSC is not yet on the schedule for Vienna. Eric and I would first like to know how much business we have -- that is, who would like an agenda slot -- and how many people are planning to attend. We have a protocol proposal on the table from Sarvi, and still have not wrapped up the evaluation document, so these have the highest priority for the group. Neither will benefit from a WG meeting unless we have critical mass to have a useful high-bandwidth discussion of issues. Please send a message to us now if you would like an agenda slot for anything else. We need to hear from those who are planning to attend and those who are planning not to attend. Please post to the list. Thanks. -- Dave. ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc From mailnull@www1.ietf.org Tue Jun 3 16:07:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23011 for ; Tue, 3 Jun 2003 16:07:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53K7GH24251 for speechsc-archive@odin.ietf.org; Tue, 3 Jun 2003 16:07:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53K7GB24248 for ; Tue, 3 Jun 2003 16:07:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23005 for ; Tue, 3 Jun 2003 16:07:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NI2A-0002Ps-00 for speechsc-web-archive@ietf.org; Tue, 03 Jun 2003 16:05:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NI29-0002Pp-00 for speechsc-web-archive@ietf.org; Tue, 03 Jun 2003 16:05:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53K79B24035; Tue, 3 Jun 2003 16:07:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53K6tB23771 for ; Tue, 3 Jun 2003 16:06:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22990 for ; Tue, 3 Jun 2003 16:06:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NI1o-0002PT-00 for speechsc@ietf.org; Tue, 03 Jun 2003 16:05:04 -0400 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 19NI1n-0002PQ-00 for speechsc@ietf.org; Tue, 03 Jun 2003 16:05:03 -0400 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Tue, 3 Jun 2003 21:09:36 +0100 Received: from gbnewp1014m ([192.168.1.100]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Jun 2003 21:07:03 +0100 From: "Neil Deason" To: "'Sarvi Shanmugham'" Cc: Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC Date: Tue, 3 Jun 2003 13:06:50 -0700 Message-ID: <000101c32a0b$ac344760$6401a8c0@eu.ubiquity.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C329D0.FFD56F60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <3ED66B3D.60501@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 03 Jun 2003 20:07:04.0467 (UTC) FILETIME=[B3B7A630:01C32A0B] Sender: speechsc-admin@ietf.org Errors-To: speechsc-admin@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Speech Services Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C329D0.FFD56F60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sarvi. -----Original Message----- From: Sarvi Shanmugham [mailto:sarvi@cisco.com]=20 Sent: 29 May 2003 13:19 To: Neil Deason Cc: speechsc@ietf.org Subject: Re: [Speechsc] Protpcol proposal for SPEECHSC some comments line. Neil Deason wrote: Hi. I have some comments on the usage of SDP for SPEECHSC part of the draft. + I would suggest an alternative format for the 'm=3D' line. Use a value for the protocol that designates the underlying transport protocol, this then allows for TCP, TLS, SCTP to be used with speechsc. For the media format use the mime type 'application/speechsc'. Then use two SDP attributes to describe the resource ID and channel ID. An example written this way would therefore be: m=3Dcontrol 32416 TCP application/speechsc a=3DresourceId:speechrec a=3DchannelId:32AECB234338=20 1. I am fine with using TCP/SCTP/TLS as the transport field of the m-line and specifiying the channel-id/resource-id as an attribute of the m-line. That said, could you explain what we gain between using a transport of SPEECHSC(whisch specifies what transports are supported) and your suggestion of specifying TCP or SCTP in the transport field of the m-line. My current approach seems similar to examples used where the transport is claimed to be "h323".=20 =20 It allows the offerer to seek an explicit transport from the answerer, e.g. TLS if security was important. If I understand it this SPEECHSC proposal just says that TCP MUCT be supported and SCTP MAY be for the actual session. Therefore which is actually used needs to be explicitly described in the SDP. 2. Channel -id / resource format Do you see problem with the channel id covering the resource identity and the channel identity? I had done it this way, so that we have the option of requesting resource-id "00" to mean, on demand allocation. This returns a channel-id of "32AECB23433800" where 00 means on-demand resource usage. There is no specific resourece that is being reserved or allocated.=20 This then allows an ASR or TTS or SI or SV command to be issued. The just need to have a channel-id of "32AECB234338XX" where XX is the resource identifier.=20 It also has the added benefit of figuring out from the chhanel -id what type of resource is being controlled.=20 =20 I dont think there is a problem with this. I just split these out as SDP attributes are essentially free so there is no cost in having 2 over 1. Being less terse than hex for the resource ID also seemed to fit with the rest of the proposal. However, it probably comes down to no more than issue of taste. =20 Cheers, Neil. =20 + Section 3.2 refers to setting the offerer setting the port to 0 in the SDP when it wants to act as the client in the connection setup procedure. However, setting a port to 0 has a defined meaning that a stream is offered but must not be used according to RFC3264. This an area where alignment with draft-ietf-mmusic-sdp-comedia-05.txt could help. That recommends the offerer use a value of port 9 (the discard port) in its offer. This work also then defines a SDP attribute to define the client/server roles to be used in the connection set up procedure, which could be reused here. Agreed. I will make the appropriate changes in the next revision. + Section 3.2 refers to a client removing a 'm=3D' line from the SDP description in a session to de-allocate a resource. RFC3264 describes the mode for removing a media stream as continuing to offer it, but with the port set to 0. Agreed. I will make the appropriate changes in the next revision. + The SDP in Example 1 of the draft would not be legal according to RFC 2327 - the SDP in the INVITE is missing a mandatory 'm=3D' line. This = may not be a big deal as it was not clear to me why you would have this preliminary offer/answer prior to establishing the resource control channel. If there is no clear reason the exchange described in Example 1 would be unnecessary and can be removed. I was just trying to demonstrate that there could be times in the SIP session when there is no m-lines becuase there is no resources used or media between the client and the server. This may most likely happen mid session than at the beginning. the SIP session may add m-line for the different resources as need and m-lines for audio as needed by the resource. The client could allocate and deallocate resources(m-lines) as needed within in the session. This might mean that there are times, when the client has released the all the individual resources but may want to allocate it as part of the session at a later point. At these points I don't want to have to destroy the whole SIP session and recreate it. Anyway, atleast thats what I was trying to do. If this is illegal in SIP, I will remove it or find an alternative for this. + Finally a few nits have crept in: The SIP URL used in the contact header of the examples has an illegal whitespace in it, the SIP messages are missing Via headers. I will incorporate these into the next revision. Thx, Sarvi ------=_NextPart_000_0002_01C329D0.FFD56F60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Sarvi.
-----Original Message-----
From: = Sarvi Shanmugham=20 [mailto:sarvi@cisco.com]
Sent: 29 May 2003 = 13:19
To: Neil=20 Deason
Cc: speechsc@ietf.org
Subject: Re: = [Speechsc]=20 Protpcol proposal for SPEECHSC

some comments=20 line.

Neil Deason wrote:
Hi.

I have some comments on the usage of SDP for SPEECHSC part of the draft.


+ I would suggest an alternative format for the 'm=3D' line. Use a value
for the protocol that designates the underlying transport protocol, this
then allows for TCP, TLS, SCTP to be used with speechsc. For the media
format use the mime type 'application/speechsc'. Then use two SDP
attributes to describe the resource ID and channel ID. An example
written this way would therefore be:

		m=3Dcontrol 32416 TCP application/speechsc
		a=3DresourceId:speechrec
		a=3DchannelId:32AECB234338
1.  I am fine with using TCP/SCTP/TLS as the transport field = of the=20 m-line and specifiying the channel-id/resource-id as an attribute of = the=20 m-line. That said, could you explain what we gain between using a = transport of=20 SPEECHSC(whisch specifies what transports are supported)  and = your=20 suggestion of specifying TCP or SCTP in the transport field of the = m-line. My=20 current approach seems similar to examples used where the transport is = claimed=20 to be "h323". 
 
It allows=20 the offerer to seek an explicit transport from the answerer, e.g. TLS = if=20 security was important. If I understand it this SPEECHSC proposal just = says=20 that TCP MUCT be supported and SCTP MAY be for the actual=20 session. Therefore which is actually used needs to be explicitly=20 described in the SDP.

  
2. Channel -id / resource format
Do you see problem with the =
channel=20
  id covering the resource identity and the channel identity?
I had =
done it=20
  this way, so that we have the option of requesting resource-id "00" to =
mean,=20
  on demand allocation. This returns a channel-id of =
 "32AECB23433800"=20
  where 00 means on-demand resource usage. There is no specific =
resourece that=20
  is being reserved or allocated. 

This then allows an ASR or TTS =
or SI=20
  or SV command to be issued. The just need to have a channel-id of=20
  "32AECB234338XX" where XX is the resource identifier. 

It also =
has the=20
  added benefit of figuring out from the chhanel -id what type of =
resource is=20
  being controlled. 

  
 

  
I dont =
think there is a=20
  problem with this. I just split these out as SDP attributes =
are=20
  essentially free so there is no cost in having 2 over 1. Being =
less terse=20
  than hex for the resource ID also seemed to fit with the rest of =
the=20
  proposal. However, it probably comes down to no more than issue =
of=20
  taste.

  
 

  
Cheers,

  
Neil.  

  
+ Section 3.2 refers to setting the offerer =
setting the port to 0 in the
SDP when it wants to act as the client in the connection setup
procedure. However, setting a port to 0 has a defined meaning that a
stream is offered but must not be used according to RFC3264. This an
area where alignment with draft-ietf-mmusic-sdp-comedia-05.txt could
help. That recommends the offerer use a value of port 9 (the discard
port) in its offer. This work also then defines a SDP attribute to
define the client/server roles to be used in the connection set up
procedure, which could be reused here.
Agreed. I will =
make=20
  the appropriate changes in the next revision.

  
+ Section 3.2 refers to a client removing a 'm=3D' line from the SDP
description in a session to de-allocate a resource. RFC3264 describes
the mode for removing a media stream as continuing to offer it, but with
the port set to 0.
Agreed. I will make the appropriate =

  changes in the next revision.

  
+ The SDP in Example 1 of the draft would not be legal according to RFC
2327 - the SDP in the INVITE is missing a mandatory 'm=3D' line. This =
may
not be a big deal as it was not clear to me why you would have this
preliminary offer/answer prior to establishing the resource control
channel. If there is no clear reason the exchange described in Example 1
would be unnecessary and can be removed.
I was just =
trying=20
  to demonstrate that there could be times in the SIP session when there =
is no=20
  m-lines becuase there is no resources used or media between the client =
and the=20
  server. This may most likely happen mid session than at the beginning. =
the SIP=20
  session may add m-line for the different resources as need and m-lines =
for=20
  audio as needed by the resource. The client could allocate and =
deallocate=20
  resources(m-lines) as needed within in the session. This might mean =
that there=20
  are times,  when the client has released the all the individual =
resources=20
  but may want to allocate it as part of the session at a later point. =
At these=20
  points I don't want to have to destroy the whole SIP session and =
recreate=20
  it.
Anyway, atleast thats what I was trying to do. If this is =
illegal in=20
  SIP, I will remove it or find an alternative for this.

  
+ Finally a few nits have crept in: The SIP URL used in the contact
header of the examples has an illegal whitespace in it, the SIP messages
are missing Via headers.
I will incorporate these into =
the=20
  next revision.

Thx,
Sarvi

------=_NextPart_000_0002_01C329D0.FFD56F60--

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Tue Jun  3 16:31:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23733
	for ; Tue, 3 Jun 2003 16:31:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h53KV8626168
	for speechsc-archive@odin.ietf.org; Tue, 3 Jun 2003 16:31:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53KV8B26165
	for ; Tue, 3 Jun 2003 16:31:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23725
	for ; Tue, 3 Jun 2003 16:31:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NIPF-0002a5-00
	for speechsc-web-archive@ietf.org; Tue, 03 Jun 2003 16:29:17 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19NIPF-0002a2-00
	for speechsc-web-archive@ietf.org; Tue, 03 Jun 2003 16:29:17 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53KV5B26154;
	Tue, 3 Jun 2003 16:31:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53KUHB26084
	for ; Tue, 3 Jun 2003 16:30:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23672
	for ; Tue, 3 Jun 2003 16:30:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NIOQ-0002ZW-00
	for speechsc@ietf.org; Tue, 03 Jun 2003 16:28:26 -0400
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157])
	by ietf-mx with esmtp (Exim 4.12)
	id 19NIOP-0002Yn-00
	for speechsc@ietf.org; Tue, 03 Jun 2003 16:28:25 -0400
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h53KTVk08525;
	Tue, 3 Jun 2003 16:29:31 -0400 (EDT)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id KRLF9WFC; Tue, 3 Jun 2003 16:29:31 -0400
Received: from nortelnetworks.com (acart1cv.ca.nortel.com [47.129.129.71]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JQNA0PYA; Tue, 3 Jun 2003 16:29:32 -0400
Message-ID: <3EDD052A.9000403@nortelnetworks.com>
Date: Tue, 03 Jun 2003 16:29:30 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507
X-Accept-Language: en-ca, en-us, en, fr
MIME-Version: 1.0
To: Neil Deason 
CC: "'Sarvi Shanmugham'" , speechsc@ietf.org
Subject: Re: [Speechsc] Protpcol proposal for SPEECHSC
References: <000101c32a0b$ac344760$6401a8c0@eu.ubiquity.net>
In-Reply-To: <000101c32a0b$ac344760$6401a8c0@eu.ubiquity.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Actually, SDP specifies zero or more media descriptions in a session description, 
meaning that the example shown is legal.

Neil Deason wrote:

> Hi Sarvi.
> 
[snip]
> 
>>+ The SDP in Example 1 of the draft would not be legal according to RFC
>>2327 - the SDP in the INVITE is missing a mandatory 'm=' line. This may
>>not be a big deal as it was not clear to me why you would have this
>>preliminary offer/answer prior to establishing the resource control
>>channel. If there is no clear reason the exchange described in Example 1
>>would be unnecessary and can be removed.
> 
>     I was just trying to demonstrate that there could be times in the
>     SIP session when there is no m-lines becuase there is no resources
>     used or media between the client and the server. This may most
>     likely happen mid session than at the beginning. the SIP session may
>     add m-line for the different resources as need and m-lines for audio
>     as needed by the resource. The client could allocate and deallocate
>     resources(m-lines) as needed within in the session. This might mean
>     that there are times,  when the client has released the all the
>     individual resources but may want to allocate it as part of the
>     session at a later point. At these points I don't want to have to
>     destroy the whole SIP session and recreate it.
>     Anyway, atleast thats what I was trying to do. If this is illegal in
>     SIP, I will remove it or find an alternative for this.
> 
[snip]

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Fri Jun  6 11:20:52 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28240
	for ; Fri, 6 Jun 2003 11:20:52 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56FKO000398
	for speechsc-archive@odin.ietf.org; Fri, 6 Jun 2003 11:20:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FKOB00393
	for ; Fri, 6 Jun 2003 11:20:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28220
	for ; Fri, 6 Jun 2003 11:20:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OIz6-00031N-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 11:18:28 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19OIz5-00031H-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 11:18:27 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FKBB00352;
	Fri, 6 Jun 2003 11:20:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FJtB32764
	for ; Fri, 6 Jun 2003 11:19:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28208
	for ; Fri, 6 Jun 2003 11:19:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OIye-000314-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 11:18:00 -0400
Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com)
	by ietf-mx with smtp (Exim 4.12)
	id 19OIyd-00030k-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 11:17:59 -0400
Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap 
	 id 7824; Fri, 06 Jun 2003 11:21:09 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 6 Jun 2003 11:19:23 -0400
Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6435@zoe.office.snowshore.com>
Thread-Topic: SPEECHSC Protocol: Resource Type Identification
Thread-Index: AcMsKklcJBQAOU8NRwCf5Ive1HkCBg==
From: "Eric Burger" 
To: "IETF SPEECHSC (E-mail)" 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56FJtB32765
Subject: [Speechsc] SPEECHSC Protocol: Resource Type Identification
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

[cf. Section 3.2 of http://www.ietf.org/internet-drafts/draft-shanmugham-speechsc-00.txt]

I don't like the idea of addressing resources by using magic numbers at the end of a string.  Is there any reason not to use mnemonic identifiers?

How about this for a proposal:

 Old Resource ID   Proposal I   Proposal II   Meaning
       00                                    Reserved
       01             ASR           SR       Speech Recognition
       02             TTS           SS       Speech Synthesis
       03             SI            SI       Speaker Identification
       04             SV            SV       Speaker Verification

Proposal II uses the same number of bytes as the document proposes.  However, it is somewhat more readable.  Proposal I uses 1 more byte (adding 0.5% overhead :-) and is yet more readable.

Thoughts?

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Fri Jun  6 11:20:52 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28242
	for ; Fri, 6 Jun 2003 11:20:52 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56FKOu00410
	for speechsc-archive@odin.ietf.org; Fri, 6 Jun 2003 11:20:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FKOB00397
	for ; Fri, 6 Jun 2003 11:20:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28221
	for ; Fri, 6 Jun 2003 11:20:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OIz6-00031Q-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 11:18:28 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19OIz5-00031I-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 11:18:27 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FKEB00369;
	Fri, 6 Jun 2003 11:20:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FJsB32759
	for ; Fri, 6 Jun 2003 11:19:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28205
	for ; Fri, 6 Jun 2003 11:19:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OIyd-000311-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 11:17:59 -0400
Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com)
	by ietf-mx with smtp (Exim 4.12)
	id 19OIyc-00030k-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 11:17:59 -0400
Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap 
	 id 7824; Fri, 06 Jun 2003 11:21:08 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 6 Jun 2003 11:19:22 -0400
Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6432@zoe.office.snowshore.com>
Thread-Topic: [Speechsc] Protpcol proposal for SPEECHSC
Thread-Index: AcMp0jpUwA8kDH68QvaeTbhXAXCW0wCVEvFw
From: "Eric Burger" 
To: 
Cc: 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56FJtB32761
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Do you have a counter-proposal?  If the counter-proposal is 80% of the session initiation mechanism of either SIP or RTSP, I would offer that it would be less work to simply use SIP -- at least you can buy or download SIP stacks.

> -----Original Message-----
> From: Brian Wyld [mailto:brian.wyld@eloquant.com]
> Sent: Tue, June 03, 2003 9:05 AM
> To: Sarvi Shanmugham; speechsc@ietf.org
> Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC
> 
> 
> Hi Sarvi,
> 
> My initial feedback (before having read the doc in detail) is 
> that I was
> somewhat surprised to see the use of SIP messages for the 
> media setup. This
> did not corrospond to what I had thought was the trend of the 
> discussion
> here, to bypass resuse of such a media protocol and create 
> directly a new
> speechsc protocol for this also. (which would probably use 
> SDP however).
> 
> The major issue I see with your use of SIP 
> INVITE/BYE/REINVITE etc is that
> adds a lot of _potential_ complexity (it pulls in an entire 
> SIP stack), for
> very little gain in real functionality. I really don't see 
> the use in having
> all the potential SIP stuff and then having to define exactly 
> what is and
> isn't allowed.....
> 
> I'd go for a simpler model where we just define new speechsc 
> messages to
> setup/control the media that are specific to speechsc.....
> 
> Brian
> 
> [Brian Wyld] [brian.wyld@eloquant.com]
> [Directeur General R&D]
> [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
> [advanced solutions for telecoms and IT services]

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Fri Jun  6 11:58:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29702
	for ; Fri, 6 Jun 2003 11:58:38 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56FwBv03597
	for speechsc-archive@odin.ietf.org; Fri, 6 Jun 2003 11:58:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FwBB03594
	for ; Fri, 6 Jun 2003 11:58:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29685
	for ; Fri, 6 Jun 2003 11:58:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OJZf-0003Q3-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 11:56:15 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19OJZe-0003Q0-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 11:56:14 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56Fw4B03579;
	Fri, 6 Jun 2003 11:58:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FVHB01210
	for ; Fri, 6 Jun 2003 11:31:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28690
	for ; Fri, 6 Jun 2003 11:31:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OJ9d-00039k-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 11:29:21 -0400
Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk)
	by ietf-mx with esmtp (Exim 4.12)
	id 19OJ9c-00039C-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 11:29:20 -0400
Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk
 (Content Technologies SMTPRS 4.2.5) with SMTP id  for ;
 Fri, 6 Jun 2003 16:28:52 +0100
Received: from RNIDMAIL-Message_Server by rnid.org.uk
	with Novell_GroupWise; Fri, 06 Jun 2003 16:28:33 +0100
Message-Id: 
X-Mailer: Novell GroupWise 5.5.2
Date: Fri, 06 Jun 2003 16:28:11 +0100
From: "Guido Gybels" 
To: , , ,
        , ,
        , "James Hamlin" ,
        "Mike Spanner" 
Cc: , , 
Subject: Re: [Speechsc] Re: Request for review and feedback
	ondraft-ietf-speechsc-reqts-02.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56FVIB01211
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

David,

<>

Thanks for the reply and for the very positive way you have approached the issues of people with disabilities. It seems most of the open questions we had have been answered/addressed. There is, however, one remaining issue:

<>

<>

I think we must make it clear to service providers that it is imperative (and more and more a legal requirement) to build services and products in such a way that they are accessible and usable by *all* people, regardless of their abilities and preferences. Also, I have some issues with the way we talk about people with disabilities, so I suggest we change this to the following:

"It is also important that implementers of SPEECHSC clients and servers be cognizant that some interaction modalities of SPEECHSC may be inconvenient, or simply inappropriate for people with disabilities. Hearing-impaired users may find TTS of limited utility. Spech-impaired users may be unable to make use of ASR or SI/SV capabilities. Therefore, systems employing SPEECHSC MUST provide alternative, equivalent interaction modes or avoid the use of speech processing entirely."

Let me all know what you think. I'll be in Vienna, so we can talk in more detail about this there as well if you want to.
Best regards,

Guido



Guido Gybels
Director of New Technologies

RNID, 19-23 Featherstone Street
London EC1Y 8SL, UK
Tel +44(0)20-7294 3713
Fax +44(0)20-7296 8069




************************************************************************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. Any views or opinions expressed
are solely those of the author and do not necessarily represent
RNID policy.

If you are not the intended recipient you are advised that any
use, dissemination, forwarding, printing or copying of this
email is strictly prohibited.

If you have received this email in error please notify the RNID
Helpdesk by telephone on: +44 (0) 207 296 8282.

The Royal National Institute for Deaf People  
Registered Office 19-23 Featherstone Street 
London EC1Y 8SL No. 454169 (England)
Registered Charity No. 207720
************************************************************************

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Fri Jun  6 12:10:13 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28245
	for ; Fri, 6 Jun 2003 11:20:52 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56FKOF00428
	for speechsc-archive@odin.ietf.org; Fri, 6 Jun 2003 11:20:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FKOB00425
	for ; Fri, 6 Jun 2003 11:20:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28225
	for ; Fri, 6 Jun 2003 11:20:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OIz7-00031U-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 11:18:29 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19OIz6-00031R-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 11:18:28 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FKFB00385;
	Fri, 6 Jun 2003 11:20:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FJtB00300
	for ; Fri, 6 Jun 2003 11:19:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28211
	for ; Fri, 6 Jun 2003 11:19:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OIye-000319-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 11:18:00 -0400
Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com)
	by ietf-mx with smtp (Exim 4.12)
	id 19OIyd-00030k-01
	for speechsc@ietf.org; Fri, 06 Jun 2003 11:18:00 -0400
Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap 
	 id 7824; Fri, 06 Jun 2003 11:21:09 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 6 Jun 2003 11:19:23 -0400
Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6436@zoe.office.snowshore.com>
Thread-Topic: Channel Identifiers in Requests and Responses
Thread-Index: AcMsLcB0wMksedaHRqq98aO8y4J7OA==
From: "Eric Burger" 
To: "IETF SPEECHSC (E-mail)" 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56FJtB00301
Subject: [Speechsc] Channel Identifiers in Requests and Responses
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

The SPEECHSC protocol often states (sections 3.4, 5.1, 5.3) that the Channel-Identifier header field SHOULD be used in requests and responses.

I would offer that requests and responses MUST use the Channel-Identifier.  That way, multiple resources, multiple streams, and pipelined requests/responses will ALWAYS work.

More importantly, from an implementer's perspective, parsing responses becomes considerably easier.  I don't need to keep special state sometimes depending on the request, what requests are outstanding, etc.

Disagreements?

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Fri Jun  6 12:30:12 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01298
	for ; Fri, 6 Jun 2003 12:30:11 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56GTjA07267
	for speechsc-archive@odin.ietf.org; Fri, 6 Jun 2003 12:29:45 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GTjB07264
	for ; Fri, 6 Jun 2003 12:29:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01286
	for ; Fri, 6 Jun 2003 12:29:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OK4C-0003qS-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 12:27:48 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19OK4B-0003qP-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 12:27:47 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GTPB07233;
	Fri, 6 Jun 2003 12:29:25 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GSYB07154
	for ; Fri, 6 Jun 2003 12:28:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01244
	for ; Fri, 6 Jun 2003 12:28:30 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OK33-0003pj-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 12:26:37 -0400
Received: from smtp804.mail.sc5.yahoo.com ([66.163.168.183])
	by ietf-mx with smtp (Exim 4.12)
	id 19OK32-0003pa-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 12:26:36 -0400
Received: from n20.vocent.com (HELO safehouse) (karlmutc@pacbell.net@12.40.203.20 with login)
  by smtp-sbc-v1.mail.vip.sc5.yahoo.com with SMTP; 6 Jun 2003 16:28:24 -0000
From: "karlmutc" 
To: "Eric Burger" 
Cc: , 
Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC
Date: Fri, 6 Jun 2003 09:29:48 -0700
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <4A3384433CE2AB46A63468CB207E209D4F6432@zoe.office.snowshore.com>
Content-Transfer-Encoding: 7bit
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

.02 c again

The problem with this being, as I pointed out before, that vocal etc are
notoriously diffcult to maintain and modify.  Given that CISCO are
active with contributing to the standard if they undertook to produce
an open reference implementation on top of VOCAL, to which they
already make contributions, then your argument makes a great deal of
sense otherwise ...

-----Original Message-----
From: speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]On Behalf
Of Eric Burger
Sent: Friday, June 06, 2003 8:19 AM
To: brian.wyld@eloquant.com
Cc: speechsc@ietf.org
Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC


Do you have a counter-proposal?  If the counter-proposal is 80% of the
session initiation mechanism of either SIP or RTSP, I would offer that it
would be less work to simply use SIP -- at least you can buy or download SIP
stacks.

> -----Original Message-----
> From: Brian Wyld [mailto:brian.wyld@eloquant.com]
> Sent: Tue, June 03, 2003 9:05 AM
> To: Sarvi Shanmugham; speechsc@ietf.org
> Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC
>
>
> Hi Sarvi,
>
> My initial feedback (before having read the doc in detail) is
> that I was
> somewhat surprised to see the use of SIP messages for the
> media setup. This
> did not corrospond to what I had thought was the trend of the
> discussion
> here, to bypass resuse of such a media protocol and create
> directly a new
> speechsc protocol for this also. (which would probably use
> SDP however).
>
> The major issue I see with your use of SIP
> INVITE/BYE/REINVITE etc is that
> adds a lot of _potential_ complexity (it pulls in an entire
> SIP stack), for
> very little gain in real functionality. I really don't see
> the use in having
> all the potential SIP stuff and then having to define exactly
> what is and
> isn't allowed.....
>
> I'd go for a simpler model where we just define new speechsc
> messages to
> setup/control the media that are specific to speechsc.....
>
> Brian
>
> [Brian Wyld] [brian.wyld@eloquant.com]
> [Directeur General R&D]
> [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
> [advanced solutions for telecoms and IT services]

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Fri Jun  6 12:32:52 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01608
	for ; Fri, 6 Jun 2003 12:32:52 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56GWQx07541
	for speechsc-archive@odin.ietf.org; Fri, 6 Jun 2003 12:32:26 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GWQB07534
	for ; Fri, 6 Jun 2003 12:32:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01525
	for ; Fri, 6 Jun 2003 12:32:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OK6n-0003vB-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 12:30:29 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19OK6m-0003v8-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 12:30:28 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GW1B07436;
	Fri, 6 Jun 2003 12:32:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GTEB07216
	for ; Fri, 6 Jun 2003 12:29:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01269
	for ; Fri, 6 Jun 2003 12:29:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OK3h-0003qF-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 12:27:17 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OK3g-0003po-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 12:27:16 -0400
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h56GSaCL009728;
	Fri, 6 Jun 2003 09:28:36 -0700 (PDT)
Received: from cisco.com (dhcp-128-107-139-4.cisco.com [128.107.139.4])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AIB86045;
	Fri, 6 Jun 2003 09:28:35 -0700 (PDT)
Message-ID: <3EE0C132.9020203@cisco.com>
Date: Fri, 06 Jun 2003 09:28:34 -0700
From: Sarvi Shanmugham 
Organization: Cisco Systems Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eric Burger 
CC: "IETF SPEECHSC (E-mail)" 
Subject: Re: [Speechsc] Channel Identifiers in Requests and Responses
References: <4A3384433CE2AB46A63468CB207E209D4F6436@zoe.office.snowshore.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Agreed.
My intention here was a MUST. :-) must have mistyped it.

Sarvi

Eric Burger wrote:

>The SPEECHSC protocol often states (sections 3.4, 5.1, 5.3) that the Channel-Identifier header field SHOULD be used in requests and responses.
>
>I would offer that requests and responses MUST use the Channel-Identifier.  That way, multiple resources, multiple streams, and pipelined requests/responses will ALWAYS work.
>
>More importantly, from an implementer's perspective, parsing responses becomes considerably easier.  I don't need to keep special state sometimes depending on the request, what requests are outstanding, etc.
>
>Disagreements?
>
>_______________________________________________
>Speechsc mailing list
>Speechsc@ietf.org
>https://www1.ietf.org/mailman/listinfo/speechsc
>
>  
>


_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Fri Jun  6 12:39:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01783
	for ; Fri, 6 Jun 2003 12:39:46 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56GdLe08730
	for speechsc-archive@odin.ietf.org; Fri, 6 Jun 2003 12:39:21 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GdLB08727
	for ; Fri, 6 Jun 2003 12:39:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01776
	for ; Fri, 6 Jun 2003 12:39:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OKDU-0003yj-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 12:37:24 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19OKDT-0003yg-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 12:37:23 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56Gd1B08707;
	Fri, 6 Jun 2003 12:39:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GcEB08652
	for ; Fri, 6 Jun 2003 12:38:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01754
	for ; Fri, 6 Jun 2003 12:38:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OKCP-0003yI-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 12:36:17 -0400
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OKCN-0003yF-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 12:36:16 -0400
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h56GbZwc025527;
	Fri, 6 Jun 2003 09:37:35 -0700 (PDT)
Received: from cisco.com (dhcp-128-107-139-4.cisco.com [128.107.139.4])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AIB87260;
	Fri, 6 Jun 2003 09:37:34 -0700 (PDT)
Message-ID: <3EE0C34D.10503@cisco.com>
Date: Fri, 06 Jun 2003 09:37:33 -0700
From: Sarvi Shanmugham 
Organization: Cisco Systems Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eric Burger 
CC: "IETF SPEECHSC (E-mail)" 
Subject: Re: [Speechsc] SPEECHSC Protocol: Resource Type Identification
References: <4A3384433CE2AB46A63468CB207E209D4F6435@zoe.office.snowshore.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Makes sense. Both proposal 1 and 2 are fine with me.
If we plan on using Proposal I(or II), since it is a variable length 
text string at the end, it might be useful to structure the identifier 
to allow easy parsing of the 2 pieces(specially since the main part is 
hexadecimal). Something like
           Channel -Identifer: 2354AB123D243@ASR
OR
           Require the main part of the Channel-identifer to be 
specified in decimal, in whcih case the separation is clear.
           Channel -Identifer: 2352343243242324ASR

Sarvi

Eric Burger wrote:

>[cf. Section 3.2 of http://www.ietf.org/internet-drafts/draft-shanmugham-speechsc-00.txt]
>
>I don't like the idea of addressing resources by using magic numbers at the end of a string.  Is there any reason not to use mnemonic identifiers?
>
>How about this for a proposal:
>
> Old Resource ID   Proposal I   Proposal II   Meaning
>       00                                    Reserved
>       01             ASR           SR       Speech Recognition
>       02             TTS           SS       Speech Synthesis
>       03             SI            SI       Speaker Identification
>       04             SV            SV       Speaker Verification
>
>Proposal II uses the same number of bytes as the document proposes.  However, it is somewhat more readable.  Proposal I uses 1 more byte (adding 0.5% overhead :-) and is yet more readable.
>
>Thoughts?
>
>_______________________________________________
>Speechsc mailing list
>Speechsc@ietf.org
>https://www1.ietf.org/mailman/listinfo/speechsc
>
>  
>


_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Fri Jun  6 14:12:20 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05503
	for ; Fri, 6 Jun 2003 14:12:20 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56IBs916771
	for speechsc-archive@odin.ietf.org; Fri, 6 Jun 2003 14:11:54 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56IBsB16768
	for ; Fri, 6 Jun 2003 14:11:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05475
	for ; Fri, 6 Jun 2003 14:11:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OLez-00051t-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 14:09:53 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19OLez-00051q-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 14:09:53 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56IBLB16715;
	Fri, 6 Jun 2003 14:11:21 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56IAkB16693
	for ; Fri, 6 Jun 2003 14:10:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05410
	for ; Fri, 6 Jun 2003 14:10:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OLdu-00050s-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 14:08:46 -0400
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OLds-000503-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 14:08:44 -0400
Received: from [10.32.254.189] (stealth-10-32-254-189.cisco.com [10.32.254.189])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with SMTP id h56I9wwc002253;
	Fri, 6 Jun 2003 11:09:59 -0700 (PDT)
Date: Fri, 06 Jun 2003 14:09:55 -0400
From: David Oran 
To: Guido Gybels , Arnoud.van.Wijk@eln.ericsson.se,
        speechsc@ietf.org, michael.gasson@korusolutions.com,
        nathan@millpark.com, James Hamlin ,
        Mike Spanner 
cc: mankin@isi.edu, eburger@snowshore.com, Jon Peterson 
Subject: Re: [Speechsc] Re: Request for review and
 feedback	ondraft-ietf-speechsc-reqts-02.txt
Message-ID: <248574281.1054908595@[10.32.254.189]>
In-Reply-To: 
References:  
X-Mailer: Mulberry/3.0.3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



--On Friday, June 06, 2003 4:28 PM +0100 Guido Gybels 
 wrote:

> David,
>
> < updated a while ago based on these very good comments. It will be
> re-submitted for IESG review in the next few days.>>
>
> Thanks for the reply and for the very positive way you have approached
> the issues of people with disabilities. It seems most of the open
> questions we had have been answered/addressed. There is, however, one
> remaining issue:
>
> < "   The SPEECHSC framework MUST allow a Media Processing Entity to
>     request the SI/SV Server to perform speaker identification or
>     verification on an RTP stream, returning the results over
>     SPEECHSC."
> Presumably, the results of the identification/validation are returned
> over SPEECHSC?
> In the context of SIP: In the event of a speech impaired user, who
> would prefer using an outbound text stream, how would he, as a
> "speaker", be identified or verified? Is there some sort of
> pass-through to another protocol to identify/verify him?>>
>
The exact mechanism is likely to be implementation-specific, but my 
suspicion is that there would be some kind of fallback to a text-based 
scheme rather than pass-through. Since we have the requirement discussed 
below, this means that whatever is providing the front end client to 
SPEECHSC will have to figure out it is interacting with a handicapped user. 
For example, if it's a SIP based user endpoint owned by the handicapped 
user (e.g. a PC or PDA-like device) the device knows already who the user 
is and what the capabilities are, and would have the state and policy 
information to know that some alternative interaction modality has to be 
used, or possibly it would have the ability to "spoof" user input (e.g. 
play out a pre-recorded anme for speaker announcement - this works for 
conference servers but obvious not for authentication/authorization usage).

In the case of a legacy device or a gateway to a legacy device, there would 
need to be some heuristics. For example, detecting a TTD instead of an 
audio input from a phone would cause the media processing entity in the 
speechsc model to know it should not do certain things with Speechsc. 
Assuming some kind of VXML-driven IVR application, it seems the appropriate 
thing to do is to redirect to an IVR-menu tree specifically crafted for a 
hearing/speech impaired user.

This is a long way of saying that I think we have the bases covered by the 
requirement cited below.

> < of speech  processing may be simply inappropriate. I've added the
> following text to  the on the general requirement to address handicapped
> users:
> "It is also important that implementers of SPEECHSC clients and servers
> be cognizant that some interaction modalities of SPEECHSC may be
> inconvenient,o  r simply inappropriate for handicapped users.
> Hearing-impaired users mayf  ind TTS of limited utility. Spech-impaired
> users may be unable to make useo  f ASR or SI/SV capabilities. Therefore,
> systems employing SPEECHSC need  to, where feasible, provide alternative
> interaction modes or avoid the useo  f speech processing entirely.">>
>
> I think we must make it clear to service providers that it is imperative
> (and more and more a legal requirement) to build services and products in
> such a way that they are accessible and usable by *all* people,
> regardless of their abilities and preferences. Also, I have some issues
> with the way we talk about people with disabilities, so I suggest we
> change this to the following:
>
> "It is also important that implementers of SPEECHSC clients and servers
> be cognizant that some interaction modalities of SPEECHSC may be
> inconvenient, or simply inappropriate for people with disabilities.
> Hearing-impaired users may find TTS of limited utility. Spech-impaired
> users may be unable to make use of ASR or SI/SV capabilities. Therefore,
> systems employing SPEECHSC MUST provide alternative, equivalent
> interaction modes or avoid the use of speech processing entirely."
>
I'm happy with your replacement text, if the Area directors are. One thing 
we have taken care to dance around is to what extent we can/should write 
requirements for the implementation of client applications which do not 
themselves affect the design or implementation of the protocol. I don't 
want to run afoul or overstepping the charter of the WG in this regard.

I have already sent the txt in for final approval by the IESG and 
publication, so if it's ok with the ADs I can recommend this change as 
edits to be done by the rfc editor as part of the publication process.

> Let me all know what you think. I'll be in Vienna, so we can talk in more
> detail about this there as well if you want to. Best regards,
>
I'll look forward to seeing you, but hopefully the requirements will be 
already published as an RFC by then and we can forge ahead with making sure 
the protocol in fact meets the requirements!

Best regards, Dave.

> Guido
>
>
>
> Guido Gybels
> Director of New Technologies
>
> RNID, 19-23 Featherstone Street
> London EC1Y 8SL, UK
> Tel +44(0)20-7294 3713
> Fax +44(0)20-7296 8069
>
>
>
>
> ************************************************************************
> This email and any files transmitted with it are confidential
> and intended solely for the use of the individual or entity to
> whom they are addressed. Any views or opinions expressed
> are solely those of the author and do not necessarily represent
> RNID policy.
>
> If you are not the intended recipient you are advised that any
> use, dissemination, forwarding, printing or copying of this
> email is strictly prohibited.
>
> If you have received this email in error please notify the RNID
> Helpdesk by telephone on: +44 (0) 207 296 8282.
>
> The Royal National Institute for Deaf People
> Registered Office 19-23 Featherstone Street
> London EC1Y 8SL No. 454169 (England)
> Registered Charity No. 207720
> ************************************************************************
>




_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Fri Jun  6 15:07:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08029
	for ; Fri, 6 Jun 2003 15:07:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56J7HU20887
	for speechsc-archive@odin.ietf.org; Fri, 6 Jun 2003 15:07:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56J7HB20876
	for ; Fri, 6 Jun 2003 15:07:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07940
	for ; Fri, 6 Jun 2003 15:07:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OMWZ-0005Wj-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 15:05:15 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19OMWY-0005Wg-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 15:05:14 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56J74B20597;
	Fri, 6 Jun 2003 15:07:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56J3CB20314
	for ; Fri, 6 Jun 2003 15:03:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07522
	for ; Fri, 6 Jun 2003 15:03:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OMSc-0005VY-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 15:01:10 -0400
Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net)
	by ietf-mx with smtp (Exim 4.12)
	id 19OMSb-0005VV-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 15:01:10 -0400
Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net
          via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Fri, 6 Jun 2003 20:05:47 +0100
Received: from gbnewp1014m ([192.168.1.100]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 6 Jun 2003 20:02:56 +0100
From: "Neil Deason" 
To: "'Tom Taylor'" 
Cc: "'Sarvi Shanmugham'" , 
Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC
Date: Fri, 6 Jun 2003 12:02:55 -0700
Message-ID: <006401c32c5e$3dc05a30$6401a8c0@eu.ubiquity.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-reply-To: <3EDD052A.9000403@nortelnetworks.com>
X-OriginalArrivalTime: 06 Jun 2003 19:02:57.0032 (UTC) FILETIME=[3DB4E880:01C32C5E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56J3DB20315
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi Tom.

You are correct. Re-reading RFC2327 shows that the 'm=' line is only
manadatory if there are any media level description lines used. So
provided you only use session level descriptors zero 'm=' lines would be
OK.

Thanks,
Neil.

> -----Original Message-----
> From: Tom Taylor [mailto:taylor@nortelnetworks.com]
> Sent: 03 June 2003 13:30
> To: Neil Deason
> Cc: 'Sarvi Shanmugham'; speechsc@ietf.org
> Subject: Re: [Speechsc] Protpcol proposal for SPEECHSC
> 
> 
> Actually, SDP specifies zero or more media descriptions in a
> session description, 
> meaning that the example shown is legal.
> 
> Neil Deason wrote:
> 
> > Hi Sarvi.
> > 
> [snip]
> > 
> >>+ The SDP in Example 1 of the draft would not be legal according to
> >>+ RFC
> >>2327 - the SDP in the INVITE is missing a mandatory 'm=' line. This
> >>may not be a big deal as it was not clear to me why you would have 
> >>this preliminary offer/answer prior to establishing the resource 
> >>control channel. If there is no clear reason the exchange 
> described in
> >>Example 1 would be unnecessary and can be removed.
> > 
> >     I was just trying to demonstrate that there could be
> times in the
> >     SIP session when there is no m-lines becuase there is
> no resources
> >     used or media between the client and the server. This may most
> >     likely happen mid session than at the beginning. the
> SIP session may
> >     add m-line for the different resources as need and
> m-lines for audio
> >     as needed by the resource. The client could allocate
> and deallocate
> >     resources(m-lines) as needed within in the session.
> This might mean
> >     that there are times,  when the client has released the all the
> >     individual resources but may want to allocate it as part of the
> >     session at a later point. At these points I don't want
> to have to
> >     destroy the whole SIP session and recreate it.
> >     Anyway, atleast thats what I was trying to do. If this
> is illegal in
> >     SIP, I will remove it or find an alternative for this.
> > 
> [snip]
> 

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Fri Jun  6 15:07:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08051
	for ; Fri, 6 Jun 2003 15:07:45 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56J7Le21024
	for speechsc-archive@odin.ietf.org; Fri, 6 Jun 2003 15:07:21 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56J7LB21021
	for ; Fri, 6 Jun 2003 15:07:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07950
	for ; Fri, 6 Jun 2003 15:07:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OMWd-0005Wp-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 15:05:19 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19OMWc-0005Wm-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 15:05:18 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56J6xB20471;
	Fri, 6 Jun 2003 15:06:59 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56J2IB20284
	for ; Fri, 6 Jun 2003 15:02:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07484
	for ; Fri, 6 Jun 2003 15:02:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OMRj-0005V9-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 15:00:15 -0400
Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net)
	by ietf-mx with smtp (Exim 4.12)
	id 19OMRh-0005V0-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 15:00:14 -0400
Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net
          via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Fri, 6 Jun 2003 20:04:51 +0100
Received: from gbnewp1014m ([192.168.1.100]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 6 Jun 2003 20:01:55 +0100
From: "Neil Deason" 
To: , "'Sarvi Shanmugham'" ,
        
Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC
Date: Fri, 6 Jun 2003 12:01:54 -0700
Message-ID: <006301c32c5e$1998d420$6401a8c0@eu.ubiquity.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-reply-To: 
X-OriginalArrivalTime: 06 Jun 2003 19:01:56.0630 (UTC) FILETIME=[19B44B60:01C32C5E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56J2IB20285
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi.

There are benefits to using SIP with speechsc because the architectural
model for speechsc is complementary to the disaggregated application
component model which SIP promotes. Plus it avoids re-inventing the
wheel for initiation, modification and termination of speechsc sessions.
Speechsc and SIP are synergistic and often likely to be deployed within
a common environment. Therefore having this form of defined working
relationship is a good thing. 

I don't see anything new needed in SIP for speechsc sessions. It is pure
reuse. RFC 3261 and RFC 3264 say what is and isn't allowed for SIP and
the offer/answer model for SDP. The only additions required would be for
SDP. The IETF promotes a modular multi-protocol approach, so I am afraid
the question of whether it means another stack is somewhat irrelevant.
The real question that needs to be asked is does SIP perform the job
required and the answer appears to be yes. 

Now, all that said, I don't think you should have to use SIP to use
speechsc anymore than you have to use SIP to use RTP. If you want to
assume a model where a priori knowledge from some other mechanism allows
a client and server to use speechsc between them that should be
supported. The draft could be made more explicit about that and keeping
the layers suitably delineated should be a design goal.

Cheers,
Neil.

> -----Original Message-----
> From: speechsc-admin@ietf.org
> [mailto:speechsc-admin@ietf.org] On Behalf Of Brian Wyld
> Sent: 03 June 2003 06:05
> To: Sarvi Shanmugham; speechsc@ietf.org
> Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC
> 
> 
> Hi Sarvi,
> 
> My initial feedback (before having read the doc in detail) is
> that I was somewhat surprised to see the use of SIP messages 
> for the media setup. This did not corrospond to what I had 
> thought was the trend of the discussion here, to bypass 
> resuse of such a media protocol and create directly a new 
> speechsc protocol for this also. (which would probably use 
> SDP however).
> 
> The major issue I see with your use of SIP
> INVITE/BYE/REINVITE etc is that adds a lot of _potential_ 
> complexity (it pulls in an entire SIP stack), for very little 
> gain in real functionality. I really don't see the use in 
> having all the potential SIP stuff and then having to define 
> exactly what is and isn't allowed.....
> 
> I'd go for a simpler model where we just define new speechsc
> messages to setup/control the media that are specific to speechsc.....
> 
> Brian
> 
> [Brian Wyld] [brian.wyld@eloquant.com]
> [Directeur General R&D]
> [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
> [advanced solutions for telecoms and IT services]
> 
> > -----Message d'origine-----
> > De : speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]De la
> > part de Sarvi Shanmugham Envoye : Wednesday, May 21, 2003 23:30
> > A : speechsc@ietf.org
> > Objet : [Speechsc] Protpcol proposal for SPEECHSC
> >
> >
> >
> >
> > Hi
> >      Please find attached a proposal for a SPEECHSC protocol. This
> > leverages the MRCP specification. But removes the 
> tunnelling aspects
> > of the protocol. I have also submitted this document to the
> internet
> > drafts repository and should be available from there soon.
> >
> > The current version does not address SI and SV aspects of the
> > requirements document. But addresses most of the others. 
> This document
> > is meant to be a starting point for a possible direction that the
> > SPEECHSC protocol could take. Based on interest and 
> comments received,
> > we can proceed to add SI and SV capabilities in a following
> version of
> > the draft.
> >
> > Any thoughts.
> >
> > Sarvi
> >
> 
> _______________________________________________
> Speechsc mailing list
> Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc
> 

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Fri Jun  6 15:08:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08187
	for ; Fri, 6 Jun 2003 15:08:37 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h56J8D021461
	for speechsc-archive@odin.ietf.org; Fri, 6 Jun 2003 15:08:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56J8DB21458
	for ; Fri, 6 Jun 2003 15:08:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08126
	for ; Fri, 6 Jun 2003 15:08:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OMXT-0005XJ-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 15:06:11 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19OMXS-0005XG-00
	for speechsc-web-archive@ietf.org; Fri, 06 Jun 2003 15:06:10 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56J81B21440;
	Fri, 6 Jun 2003 15:08:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56J5hB20398
	for ; Fri, 6 Jun 2003 15:05:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07774
	for ; Fri, 6 Jun 2003 15:05:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19OMV3-0005WB-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 15:03:41 -0400
Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net)
	by ietf-mx with smtp (Exim 4.12)
	id 19OMV1-0005W4-00
	for speechsc@ietf.org; Fri, 06 Jun 2003 15:03:40 -0400
Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net
          via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Fri, 6 Jun 2003 20:08:18 +0100
Received: from gbnewp1014m ([192.168.1.100]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 6 Jun 2003 20:05:27 +0100
From: "Neil Deason" 
To: "'Sarvi Shanmugham'" ,
        "'Eric Burger'" 
Cc: "'IETF SPEECHSC \(E-mail\)'" 
Subject: RE: [Speechsc] SPEECHSC Protocol: Resource Type Identification
Date: Fri, 6 Jun 2003 12:05:26 -0700
Message-ID: <006501c32c5e$97745f40$6401a8c0@eu.ubiquity.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-reply-To: <3EE0C34D.10503@cisco.com>
X-OriginalArrivalTime: 06 Jun 2003 19:05:27.0524 (UTC) FILETIME=[97682A40:01C32C5E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56J5hB20399
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

It is even easier to parse if you use the separate SDP attributes
approach. In terms of bytes required this needs to be seen in the
context of the wider SIP message + SDP being used. The number of bytes
being saved in the alternatives will be about as effective at
'compression' as the compact header name forms in SIP. Therefore I would
go for readability and easier debugging, something like the following
ABNF grammar (incorporating Proposal I):

  resource-attribute = "resource" : resource-id
  resource-id = 1*(alpha-numeric) ; typically ASR, TTS, SI, SV  

  channel-attribute = "channel" : channel-id
  channel-id = 1*(DIGIT) ; must be unique for originating client

An example speechsc SDP media level description:

  m=control 32416 TCP application/speechsc
  a=resource:ASR
  a=channel:583769103560

Cheers,
Neil.

> -----Original Message-----
> From: speechsc-admin@ietf.org 
> [mailto:speechsc-admin@ietf.org] On Behalf Of Sarvi Shanmugham
> Sent: 06 June 2003 09:38
> To: Eric Burger
> Cc: IETF SPEECHSC (E-mail)
> Subject: Re: [Speechsc] SPEECHSC Protocol: Resource Type 
> Identification
> 
> 
> Makes sense. Both proposal 1 and 2 are fine with me.
> If we plan on using Proposal I(or II), since it is a variable length 
> text string at the end, it might be useful to structure the 
> identifier 
> to allow easy parsing of the 2 pieces(specially since the 
> main part is 
> hexadecimal). Something like
>            Channel -Identifer: 2354AB123D243@ASR
> OR
>            Require the main part of the Channel-identifer to be 
> specified in decimal, in whcih case the separation is clear.
>            Channel -Identifer: 2352343243242324ASR
> 
> Sarvi
> 
> Eric Burger wrote:
> 
> >[cf. Section 3.2 of 
> >http://www.ietf.org/internet-drafts/draft-shanmugham-speechsc-00.txt]
> >
> >I don't like the idea of addressing resources by using magic 
> numbers at 
> >the end of a string.  Is there any reason not to use mnemonic 
> >identifiers?
> >
> >How about this for a proposal:
> >
> > Old Resource ID   Proposal I   Proposal II   Meaning
> >       00                                    Reserved
> >       01             ASR           SR       Speech Recognition
> >       02             TTS           SS       Speech Synthesis
> >       03             SI            SI       Speaker Identification
> >       04             SV            SV       Speaker Verification
> >
> >Proposal II uses the same number of bytes as the document proposes.  
> >However, it is somewhat more readable.  Proposal I uses 1 more byte 
> >(adding 0.5% overhead :-) and is yet more readable.
> >
> >Thoughts?
> >
> >_______________________________________________
> >Speechsc mailing list
> >Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc
> >
> >  
> >
> 
> 
> _______________________________________________
> Speechsc mailing list
> Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc
> 

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Mon Jun  9 03:19:48 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23145
	for ; Mon, 9 Jun 2003 03:19:47 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h597JJM07686
	for speechsc-archive@odin.ietf.org; Mon, 9 Jun 2003 03:19:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h597JJB07682
	for ; Mon, 9 Jun 2003 03:19:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23142
	for ; Mon, 9 Jun 2003 03:19:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PGu5-0000Q7-00
	for speechsc-web-archive@ietf.org; Mon, 09 Jun 2003 03:17:17 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PGu5-0000Q3-00
	for speechsc-web-archive@ietf.org; Mon, 09 Jun 2003 03:17:17 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h597JCB07670;
	Mon, 9 Jun 2003 03:19:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h597IQB07645
	for ; Mon, 9 Jun 2003 03:18:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23135
	for ; Mon, 9 Jun 2003 03:18:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PGtF-0000Q0-00
	for speechsc@ietf.org; Mon, 09 Jun 2003 03:16:25 -0400
Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PGtE-0000Pl-00
	for speechsc@ietf.org; Mon, 09 Jun 2003 03:16:24 -0400
Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk
 (Content Technologies SMTPRS 4.2.5) with SMTP id  for ;
 Mon, 9 Jun 2003 08:16:05 +0100
Received: from RNIDMAIL-Message_Server by rnid.org.uk
	with Novell_GroupWise; Mon, 09 Jun 2003 08:15:41 +0100
Message-Id: 
X-Mailer: Novell GroupWise 5.5.2
Date: Mon, 09 Jun 2003 08:15:01 +0100
From: "Guido Gybels" 
To: , , ,
        , ,
        "James Hamlin" ,
        "Mike Spanner" 
Cc: , , 
Subject: Re: [Speechsc] Re: Request for review andfeedback on
	draft-ietf-speechsc-reqts-02.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h597IRB07647
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

David,

Thanks for the swift reply.

<>

I see what you mean, but I think we are within the provisions of the charter here. I believe it is important that the protocol is at least capable, it not aware, of supporting our requirement. I don't think it complicates matters, so I'm hopeful that the AD will agree.

<>

That would be very good.

<>

Excellent. See you in Vienna.

Guido



Guido Gybels
Director of New Technologies

RNID, 19-23 Featherstone Street
London EC1Y 8SL, UK
Tel +44(0)20-7294 3713
Fax +44(0)20-7296 8069




************************************************************************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. Any views or opinions expressed
are solely those of the author and do not necessarily represent
RNID policy.

If you are not the intended recipient you are advised that any
use, dissemination, forwarding, printing or copying of this
email is strictly prohibited.

If you have received this email in error please notify the RNID
Helpdesk by telephone on: +44 (0) 207 296 8282.

The Royal National Institute for Deaf People  
Registered Office 19-23 Featherstone Street 
London EC1Y 8SL No. 454169 (England)
Registered Charity No. 207720
************************************************************************

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Mon Jun  9 07:54:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29098
	for ; Mon, 9 Jun 2003 07:54:41 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h59BsDN26688
	for speechsc-archive@odin.ietf.org; Mon, 9 Jun 2003 07:54:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59BsDB26685
	for ; Mon, 9 Jun 2003 07:54:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29074
	for ; Mon, 9 Jun 2003 07:54:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PLC7-00020Z-00
	for speechsc-web-archive@ietf.org; Mon, 09 Jun 2003 07:52:11 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PLC6-00020W-00
	for speechsc-web-archive@ietf.org; Mon, 09 Jun 2003 07:52:10 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Bs8B26673;
	Mon, 9 Jun 2003 07:54:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Bk2B26303
	for ; Mon, 9 Jun 2003 07:46:02 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28741;
	Mon, 9 Jun 2003 07:46:00 -0400 (EDT)
Message-Id: <200306091146.HAA28741@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: speechsc@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Mon, 09 Jun 2003 07:46:00 -0400
Subject: [Speechsc] I-D ACTION:draft-ietf-speechsc-reqts-04.txt
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Speech Services Control Working Group of the IETF.

	Title		: Requirements for Distributed Control of ASR, SI/SV and
                          TTS Resources
	Author(s)	: D. Oran
	Filename	: draft-ietf-speechsc-reqts-04.txt
	Pages		: 18
	Date		: 2003-6-6
	
This document outlines the needs and requirements for a protocol to
control distributed speech processing of audio streams.  By speech
processing, this document specifically means automatic speech
recognition (ASR), speaker recognition - which includes both speaker
identification (SI) and speaker verification (SV) - and
text-to-speech (TTS).  Other IETF protocols, such as SIP and RTSP,
address rendezvous and control for generalized media streams.
However, speech processing presents additional requirements that none
of the extant IETF protocols address.
Discussion of this and related documents is on the speechsc mailing
list.  To subscribe, send the message 'subscribe speechsc' to
speechsc-request@ietf.org.  The public archive is at http://
www.ietf.org/mail-archive/workinggroups/speechsc/current/
maillist.html

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speechsc-reqts-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-speechsc-reqts-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-speechsc-reqts-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-6-6133307.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-speechsc-reqts-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-speechsc-reqts-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-6-6133307.I-D@ietf.org>

--OtherAccess--

--NextPart--


_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Tue Jun 10 03:49:04 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16243
	for ; Tue, 10 Jun 2003 03:49:03 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5A7mZh25875
	for speechsc-archive@odin.ietf.org; Tue, 10 Jun 2003 03:48:35 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A7mZB25872
	for ; Tue, 10 Jun 2003 03:48:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16240
	for ; Tue, 10 Jun 2003 03:48:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pdpv-0002hZ-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 03:46:31 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pdpu-0002hV-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 03:46:30 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A7mRB25855;
	Tue, 10 Jun 2003 03:48:27 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A7l2B25800
	for ; Tue, 10 Jun 2003 03:47:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16196
	for ; Tue, 10 Jun 2003 03:47:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PdoQ-0002h9-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 03:44:58 -0400
Received: from smtp-102-tuesday.noc.nerim.net ([62.4.17.102] helo=mallaury.noc.nerim.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PdoP-0002h5-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 03:44:57 -0400
Received: from weasel.hq.eloquant.com (styx.eloquant.com [80.65.227.37])
	by mallaury.noc.nerim.net (Postfix) with ESMTP
	id 2424962E3D; Tue, 10 Jun 2003 09:46:58 +0200 (CEST)
Received: from polo (polo.hq.eloquant.com [192.168.0.131])
	by weasel.hq.eloquant.com (Postfix) with SMTP
	id 569CC3B6CA; Tue, 10 Jun 2003 03:52:35 -0400 (EDT)
Reply-To: 
From: "Brian Wyld" 
To: "Neil Deason" ,
        "'Sarvi Shanmugham'" , 
Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC
Date: Tue, 10 Jun 2003 09:42:47 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <006301c32c5e$1998d420$6401a8c0@eu.ubiquity.net>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Content-Transfer-Encoding: 7bit
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi,

I quite like the idea of separating the media setup and speechsc operation
completely as Sarvi has proposed. However, I think this together with SIP is
going to give us big headaches when it comes to real implementations and
interoperability...

1/ SIP-in-speechsc : SIP is a protocol that has lot of stuff that speechsc
does not need - does a speechsc client or server have to supply a full SIP
complient stack, or just the bits that seem to be needed by speechsc? Do we
define a "speechsc profile" to avoid such a problem?

2/ SIP-commercial : SIP stacks might be generally available, but is it
really a requirement that a producer of a speechsc client/server must both
create a speechsc stack and acquire a full SIP stack as well? Although as
Neil says the environment around speechsc is likely to include SIP, a) this
cannot be enforced and b) the SIP stack elements may be present in the
environment, but not neccessarily in the speechsc elements. In particular,
the speechsc server is unlikely to have a SIP stack in most cases (IMHO bien
sur - none of my MRCP servers have a SIP stack....)

3/ not-SIP : as Neil says, one could substitute ANOProtocol for SIP and it
should work - however, as there is no mechanism to inform the client or
server of such a substitution this will ensure non-interoperability between
vendors..... (a Bad Thing)

This said, if we can avoid SIP causing either 'bloat' or an interoperability
nightmare, maybe by creating a 'speechsc profile' then I'm not against it
generally....

Brian

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

> -----Message d'origine-----
> De : Neil Deason [mailto:ndeason@ubiquity.net]
> Envoye : Friday, June 06, 2003 21:02
> A : brian.wyld@eloquant.com; 'Sarvi Shanmugham'; speechsc@ietf.org
> Objet : RE: [Speechsc] Protpcol proposal for SPEECHSC
>
>
> Hi.
>
> There are benefits to using SIP with speechsc because the architectural
> model for speechsc is complementary to the disaggregated application
> component model which SIP promotes. Plus it avoids re-inventing the
> wheel for initiation, modification and termination of speechsc sessions.
> Speechsc and SIP are synergistic and often likely to be deployed within
> a common environment. Therefore having this form of defined working
> relationship is a good thing.
>
> I don't see anything new needed in SIP for speechsc sessions. It is pure
> reuse. RFC 3261 and RFC 3264 say what is and isn't allowed for SIP and
> the offer/answer model for SDP. The only additions required would be for
> SDP. The IETF promotes a modular multi-protocol approach, so I am afraid
> the question of whether it means another stack is somewhat irrelevant.
> The real question that needs to be asked is does SIP perform the job
> required and the answer appears to be yes.
>
> Now, all that said, I don't think you should have to use SIP to use
> speechsc anymore than you have to use SIP to use RTP. If you want to
> assume a model where a priori knowledge from some other mechanism allows
> a client and server to use speechsc between them that should be
> supported. The draft could be made more explicit about that and keeping
> the layers suitably delineated should be a design goal.
>
> Cheers,
> Neil.
>
> > -----Original Message-----
> > From: speechsc-admin@ietf.org
> > [mailto:speechsc-admin@ietf.org] On Behalf Of Brian Wyld
> > Sent: 03 June 2003 06:05
> > To: Sarvi Shanmugham; speechsc@ietf.org
> > Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC
> >
> >
> > Hi Sarvi,
> >
> > My initial feedback (before having read the doc in detail) is
> > that I was somewhat surprised to see the use of SIP messages
> > for the media setup. This did not corrospond to what I had
> > thought was the trend of the discussion here, to bypass
> > resuse of such a media protocol and create directly a new
> > speechsc protocol for this also. (which would probably use
> > SDP however).
> >
> > The major issue I see with your use of SIP
> > INVITE/BYE/REINVITE etc is that adds a lot of _potential_
> > complexity (it pulls in an entire SIP stack), for very little
> > gain in real functionality. I really don't see the use in
> > having all the potential SIP stuff and then having to define
> > exactly what is and isn't allowed.....
> >
> > I'd go for a simpler model where we just define new speechsc
> > messages to setup/control the media that are specific to speechsc.....
> >
> > Brian
> >
> > [Brian Wyld] [brian.wyld@eloquant.com]
> > [Directeur General R&D]
> > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
> > [advanced solutions for telecoms and IT services]
> >
> > > -----Message d'origine-----
> > > De : speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]De la
> > > part de Sarvi Shanmugham Envoye : Wednesday, May 21, 2003 23:30
> > > A : speechsc@ietf.org
> > > Objet : [Speechsc] Protpcol proposal for SPEECHSC
> > >
> > >
> > >
> > >
> > > Hi
> > >      Please find attached a proposal for a SPEECHSC protocol. This
> > > leverages the MRCP specification. But removes the
> > tunnelling aspects
> > > of the protocol. I have also submitted this document to the
> > internet
> > > drafts repository and should be available from there soon.
> > >
> > > The current version does not address SI and SV aspects of the
> > > requirements document. But addresses most of the others.
> > This document
> > > is meant to be a starting point for a possible direction that the
> > > SPEECHSC protocol could take. Based on interest and
> > comments received,
> > > we can proceed to add SI and SV capabilities in a following
> > version of
> > > the draft.
> > >
> > > Any thoughts.
> > >
> > > Sarvi
> > >
> >
> > _______________________________________________
> > Speechsc mailing list
> > Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc
> >
>
>

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Tue Jun 10 07:46:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21109
	for ; Tue, 10 Jun 2003 07:46:38 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5ABk9p12593
	for speechsc-archive@odin.ietf.org; Tue, 10 Jun 2003 07:46:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ABk9B12590
	for ; Tue, 10 Jun 2003 07:46:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21098
	for ; Tue, 10 Jun 2003 07:46:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PhXp-0003zz-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 07:44:05 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PhXo-0003zw-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 07:44:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ABk5B12561;
	Tue, 10 Jun 2003 07:46:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ABj1B12500
	for ; Tue, 10 Jun 2003 07:45:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21067
	for ; Tue, 10 Jun 2003 07:44:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PhWj-0003zY-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 07:42:57 -0400
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PhWi-0003zJ-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 07:42:56 -0400
Received: from [10.32.254.189] (stealth-10-32-254-189.cisco.com [10.32.254.189])
	by sj-core-3.cisco.com (8.12.6/8.12.6) with SMTP id h5ABiHI2029001;
	Tue, 10 Jun 2003 04:44:18 -0700 (PDT)
Date: Tue, 10 Jun 2003 07:44:13 -0400
From: "David R. Oran" 
To: brian.wyld@eloquant.com, Neil Deason ,
        "'Sarvi Shanmugham'" , speechsc@ietf.org
Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC
Message-ID: <571029125.1055231053@[10.32.254.189]>
In-Reply-To: 
References:  
X-Mailer: Mulberry/3.0.3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

--On Tuesday, June 10, 2003 9:42 AM +0200 Brian Wyld 
 wrote:

> Hi,
>
> I quite like the idea of separating the media setup and speechsc operation
> completely as Sarvi has proposed. However, I think this together with SIP
> is going to give us big headaches when it comes to real implementations
> and interoperability...
>
> 1/ SIP-in-speechsc : SIP is a protocol that has lot of stuff that speechsc
> does not need - does a speechsc client or server have to supply a full SIP
> complient stack, or just the bits that seem to be needed by speechsc? Do
> we define a "speechsc profile" to avoid such a problem?
>
I suspect that once we deviate from 3261 compliance, we are buying tons of 
potential problems with interoperability and complex specification. While I 
have seen the profile approach taken in a number of fora, in the IETF tis 
is generally considered to be inimical to the goal of interoperability 
which is very high on the IETF's list of criteria for protocol 
specification.

> 2/ SIP-commercial : SIP stacks might be generally available, but is it
> really a requirement that a producer of a speechsc client/server must both
> create a speechsc stack and acquire a full SIP stack as well?
If we decide to go this path, then yes. However, 3261-compliant SIP stacks 
are quite easy to obtain and there are multiple open source versions 
(vovida.org, iptel.org). As one of the "SIP bigots", my defense here is 
that us crazy's really expect SIP to be ubiquitous - of the same universal 
deployment as DTTP, FTP, Telnet, SMTPm so depending on a SIP stack is a 
perfectly natural and reasonable thing to do, especially if it simplifies 
the rest of the problem space, which in this case it seems to do quite 
nicely.

> Although as
> Neil says the environment around speechsc is likely to include SIP, a)
> this cannot be enforced
well...we can enforce it if we so choose. It is unlikely that a service 
enviroment which employs SPEECHSC would lack FTP, or HTTP, or DNS. This 
proposal adds SIP to the list of things needed.

Also, it seems that the argument that SIP is an extra burden probably 
applies to the server side, but not really to the client side. Nearly all 
the envinroments we cite for SPEECHSC are ones in which speech services are 
being provided within the context of preparing for a session establishment 
of some sort, or during such sessions. I would have to construct some 
artificial examples to justify a SPEECHSC client which did not also employ 
SIP.

For servers, your argument carries more weight, since a SPEECHSC server may 
be just a dedicated back-end box which does not itself initiate or 
terminate other sessions. In analyzing the tradeoff, I still come down on 
the SIP side of the equation because SPEECHSC servers are likely to be 
general-purpose computers, running general-purpose OSs, with a rich 
programming environment in which embedding SIP should be somewhere between 
easy and trivial.


> and b) the SIP stack elements may be present in
> the environment, but not neccessarily in the speechsc elements. In
> particular, the speechsc server is unlikely to have a SIP stack in most
> cases (IMHO bien sur - none of my MRCP servers have a SIP stack....)
>
True, but they wound up with nearly all of an RTSP stack, no?

> 3/ not-SIP : as Neil says, one could substitute ANOProtocol for SIP and it
> should work - however, as there is no mechanism to inform the client or
> server of such a substitution this will ensure non-interoperability
> between vendors..... (a Bad Thing)
>
> This said, if we can avoid SIP causing either 'bloat' or an
> interoperability nightmare, maybe by creating a 'speechsc profile' then
> I'm not against it generally....
>
I suspect something which mandates less than 3261 compliance will not have 
an easy time getting through the IESG. On the other hand, I would have no 
objection to the spec including guidance of the sort "note that a speechsc 
server has no need to ever initiate a SIP session and hence will be 
responding to INVITES but not generating them".

> Brian
>
> [Brian Wyld] [brian.wyld@eloquant.com]
> [Directeur General R&D]
> [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
> [advanced solutions for telecoms and IT services]
>
>> -----Message d'origine-----
>> De : Neil Deason [mailto:ndeason@ubiquity.net]
>> Envoye : Friday, June 06, 2003 21:02
>> A : brian.wyld@eloquant.com; 'Sarvi Shanmugham'; speechsc@ietf.org
>> Objet : RE: [Speechsc] Protpcol proposal for SPEECHSC
>>
>>
>> Hi.
>>
>> There are benefits to using SIP with speechsc because the architectural
>> model for speechsc is complementary to the disaggregated application
>> component model which SIP promotes. Plus it avoids re-inventing the
>> wheel for initiation, modification and termination of speechsc sessions.
>> Speechsc and SIP are synergistic and often likely to be deployed within
>> a common environment. Therefore having this form of defined working
>> relationship is a good thing.
>>
>> I don't see anything new needed in SIP for speechsc sessions. It is pure
>> reuse. RFC 3261 and RFC 3264 say what is and isn't allowed for SIP and
>> the offer/answer model for SDP. The only additions required would be for
>> SDP. The IETF promotes a modular multi-protocol approach, so I am afraid
>> the question of whether it means another stack is somewhat irrelevant.
>> The real question that needs to be asked is does SIP perform the job
>> required and the answer appears to be yes.
>>
>> Now, all that said, I don't think you should have to use SIP to use
>> speechsc anymore than you have to use SIP to use RTP. If you want to
>> assume a model where a priori knowledge from some other mechanism allows
>> a client and server to use speechsc between them that should be
>> supported. The draft could be made more explicit about that and keeping
>> the layers suitably delineated should be a design goal.
>>
>> Cheers,
>> Neil.
>>
>> > -----Original Message-----
>> > From: speechsc-admin@ietf.org
>> > [mailto:speechsc-admin@ietf.org] On Behalf Of Brian Wyld
>> > Sent: 03 June 2003 06:05
>> > To: Sarvi Shanmugham; speechsc@ietf.org
>> > Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC
>> >
>> >
>> > Hi Sarvi,
>> >
>> > My initial feedback (before having read the doc in detail) is
>> > that I was somewhat surprised to see the use of SIP messages
>> > for the media setup. This did not corrospond to what I had
>> > thought was the trend of the discussion here, to bypass
>> > resuse of such a media protocol and create directly a new
>> > speechsc protocol for this also. (which would probably use
>> > SDP however).
>> >
>> > The major issue I see with your use of SIP
>> > INVITE/BYE/REINVITE etc is that adds a lot of _potential_
>> > complexity (it pulls in an entire SIP stack), for very little
>> > gain in real functionality. I really don't see the use in
>> > having all the potential SIP stuff and then having to define
>> > exactly what is and isn't allowed.....
>> >
>> > I'd go for a simpler model where we just define new speechsc
>> > messages to setup/control the media that are specific to speechsc.....
>> >
>> > Brian
>> >
>> > [Brian Wyld] [brian.wyld@eloquant.com]
>> > [Directeur General R&D]
>> > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
>> > [advanced solutions for telecoms and IT services]
>> >
>> > > -----Message d'origine-----
>> > > De : speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]De la
>> > > part de Sarvi Shanmugham Envoye : Wednesday, May 21, 2003 23:30
>> > > A : speechsc@ietf.org
>> > > Objet : [Speechsc] Protpcol proposal for SPEECHSC
>> > >
>> > >
>> > >
>> > >
>> > > Hi
>> > >      Please find attached a proposal for a SPEECHSC protocol. This
>> > > leverages the MRCP specification. But removes the
>> > tunnelling aspects
>> > > of the protocol. I have also submitted this document to the
>> > internet
>> > > drafts repository and should be available from there soon.
>> > >
>> > > The current version does not address SI and SV aspects of the
>> > > requirements document. But addresses most of the others.
>> > This document
>> > > is meant to be a starting point for a possible direction that the
>> > > SPEECHSC protocol could take. Based on interest and
>> > comments received,
>> > > we can proceed to add SI and SV capabilities in a following
>> > version of
>> > > the draft.
>> > >
>> > > Any thoughts.
>> > >
>> > > Sarvi
>> > >
>> >
>> > _______________________________________________
>> > Speechsc mailing list
>> > Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc
>> >
>>
>>
>
> _______________________________________________
> Speechsc mailing list
> Speechsc@ietf.org
> https://www1.ietf.org/mailman/listinfo/speechsc



------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: oran@cisco.com
_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Tue Jun 10 12:25:53 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07694
	for ; Tue, 10 Jun 2003 12:25:53 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AGPR205329
	for speechsc-archive@odin.ietf.org; Tue, 10 Jun 2003 12:25:27 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGPRB05326
	for ; Tue, 10 Jun 2003 12:25:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07673
	for ; Tue, 10 Jun 2003 12:25:23 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Plu5-00009s-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 12:23:21 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Plu5-00009p-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 12:23:21 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGP8B05255;
	Tue, 10 Jun 2003 12:25:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGKeB04968
	for ; Tue, 10 Jun 2003 12:20:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07489
	for ; Tue, 10 Jun 2003 12:20:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PlpS-00006d-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 12:18:34 -0400
Received: from smtp-102-tuesday.nerim.net ([62.4.16.102] helo=kraid.nerim.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PlpS-00006a-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 12:18:34 -0400
Received: from weasel.hq.eloquant.com (styx.eloquant.com [80.65.227.37])
	by kraid.nerim.net (Postfix) with ESMTP
	id A9D2740FE9; Tue, 10 Jun 2003 18:20:34 +0200 (CEST)
Received: from polo (polo.hq.eloquant.com [192.168.0.131])
	by weasel.hq.eloquant.com (Postfix) with SMTP
	id 8FDC03B6CA; Tue, 10 Jun 2003 12:26:18 -0400 (EDT)
Reply-To: 
From: "Brian Wyld" 
To: "David R. Oran" , "Neil Deason" ,
        "'Sarvi Shanmugham'" , 
Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC
Date: Tue, 10 Jun 2003 18:16:24 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <571029125.1055231053@[10.32.254.189]>
Content-Transfer-Encoding: 7bit
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi David,

I'll brutally resume your arguements as:
"SIP should be supplied natively by all OS's on which you might run
speechsc, and hence is not a burden for a speechsc implementation"

Whilest some might dispute this, I don't think this is a true statement
today; and tomorrow is another country as one might (mis)quote..... Making
this assumption and basing the operation and acceptance of speechsc on it
seems unneccessary to me.  Integrating a SIP stack is not a simple activity
(and generally more expensive if its free!).

Sorry, but I still think that it's easier to specify the media setup
specifically (maybe by cut-n-paste from RTSP) rather than suck in the entire
SIP protocol.

Maybe we should instead specify the use of RTSP as the media setup agent, as
most folks with MRCP experience will have such an implementation already and
it is known to serve the needs of mrcp......

A+

Brian

PS> I note that to achieve an operation MRCP server today, it is neccessary
to implement very little of RTSP and none of the media state machinary (no
play, record etc). In fact, only SETUP and TEARDOWN are really required, and
the 'tunnel message' ANNOUNCE......

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

> -----Message d'origine-----
> De : David R. Oran [mailto:oran@cisco.com]
> Envoye : Tuesday, June 10, 2003 13:44
> A : brian.wyld@eloquant.com; Neil Deason; 'Sarvi Shanmugham';
> speechsc@ietf.org
> Objet : RE: [Speechsc] Protpcol proposal for SPEECHSC
>
>
> --On Tuesday, June 10, 2003 9:42 AM +0200 Brian Wyld
>  wrote:
>
> > Hi,
> >
> > I quite like the idea of separating the media setup and
> speechsc operation
> > completely as Sarvi has proposed. However, I think this
> together with SIP
> > is going to give us big headaches when it comes to real implementations
> > and interoperability...
> >
> > 1/ SIP-in-speechsc : SIP is a protocol that has lot of stuff
> that speechsc
> > does not need - does a speechsc client or server have to supply
> a full SIP
> > complient stack, or just the bits that seem to be needed by speechsc? Do
> > we define a "speechsc profile" to avoid such a problem?
> >
> I suspect that once we deviate from 3261 compliance, we are
> buying tons of
> potential problems with interoperability and complex
> specification. While I
> have seen the profile approach taken in a number of fora, in the IETF tis
> is generally considered to be inimical to the goal of interoperability
> which is very high on the IETF's list of criteria for protocol
> specification.
>
> > 2/ SIP-commercial : SIP stacks might be generally available, but is it
> > really a requirement that a producer of a speechsc
> client/server must both
> > create a speechsc stack and acquire a full SIP stack as well?
> If we decide to go this path, then yes. However, 3261-compliant
> SIP stacks
> are quite easy to obtain and there are multiple open source versions
> (vovida.org, iptel.org). As one of the "SIP bigots", my defense here is
> that us crazy's really expect SIP to be ubiquitous - of the same
> universal
> deployment as DTTP, FTP, Telnet, SMTPm so depending on a SIP stack is a
> perfectly natural and reasonable thing to do, especially if it simplifies
> the rest of the problem space, which in this case it seems to do quite
> nicely.
>
> > Although as
> > Neil says the environment around speechsc is likely to include SIP, a)
> > this cannot be enforced
> well...we can enforce it if we so choose. It is unlikely that a service
> enviroment which employs SPEECHSC would lack FTP, or HTTP, or DNS. This
> proposal adds SIP to the list of things needed.
>
> Also, it seems that the argument that SIP is an extra burden probably
> applies to the server side, but not really to the client side. Nearly all
> the envinroments we cite for SPEECHSC are ones in which speech
> services are
> being provided within the context of preparing for a session
> establishment
> of some sort, or during such sessions. I would have to construct some
> artificial examples to justify a SPEECHSC client which did not
> also employ
> SIP.
>
> For servers, your argument carries more weight, since a SPEECHSC
> server may
> be just a dedicated back-end box which does not itself initiate or
> terminate other sessions. In analyzing the tradeoff, I still come down on
> the SIP side of the equation because SPEECHSC servers are likely to be
> general-purpose computers, running general-purpose OSs, with a rich
> programming environment in which embedding SIP should be
> somewhere between
> easy and trivial.
>
>
> > and b) the SIP stack elements may be present in
> > the environment, but not neccessarily in the speechsc elements. In
> > particular, the speechsc server is unlikely to have a SIP stack in most
> > cases (IMHO bien sur - none of my MRCP servers have a SIP stack....)
> >
> True, but they wound up with nearly all of an RTSP stack, no?
>
> > 3/ not-SIP : as Neil says, one could substitute ANOProtocol for
> SIP and it
> > should work - however, as there is no mechanism to inform the client or
> > server of such a substitution this will ensure non-interoperability
> > between vendors..... (a Bad Thing)
> >
> > This said, if we can avoid SIP causing either 'bloat' or an
> > interoperability nightmare, maybe by creating a 'speechsc profile' then
> > I'm not against it generally....
> >
> I suspect something which mandates less than 3261 compliance will
> not have
> an easy time getting through the IESG. On the other hand, I would have no
> objection to the spec including guidance of the sort "note that a
> speechsc
> server has no need to ever initiate a SIP session and hence will be
> responding to INVITES but not generating them".
>
> > Brian
> >
> > [Brian Wyld] [brian.wyld@eloquant.com]
> > [Directeur General R&D]
> > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
> > [advanced solutions for telecoms and IT services]
> >
> >> -----Message d'origine-----
> >> De : Neil Deason [mailto:ndeason@ubiquity.net]
> >> Envoye : Friday, June 06, 2003 21:02
> >> A : brian.wyld@eloquant.com; 'Sarvi Shanmugham'; speechsc@ietf.org
> >> Objet : RE: [Speechsc] Protpcol proposal for SPEECHSC
> >>
> >>
> >> Hi.
> >>
> >> There are benefits to using SIP with speechsc because the architectural
> >> model for speechsc is complementary to the disaggregated application
> >> component model which SIP promotes. Plus it avoids re-inventing the
> >> wheel for initiation, modification and termination of speechsc
> sessions.
> >> Speechsc and SIP are synergistic and often likely to be deployed within
> >> a common environment. Therefore having this form of defined working
> >> relationship is a good thing.
> >>
> >> I don't see anything new needed in SIP for speechsc sessions.
> It is pure
> >> reuse. RFC 3261 and RFC 3264 say what is and isn't allowed for SIP and
> >> the offer/answer model for SDP. The only additions required
> would be for
> >> SDP. The IETF promotes a modular multi-protocol approach, so I
> am afraid
> >> the question of whether it means another stack is somewhat irrelevant.
> >> The real question that needs to be asked is does SIP perform the job
> >> required and the answer appears to be yes.
> >>
> >> Now, all that said, I don't think you should have to use SIP to use
> >> speechsc anymore than you have to use SIP to use RTP. If you want to
> >> assume a model where a priori knowledge from some other
> mechanism allows
> >> a client and server to use speechsc between them that should be
> >> supported. The draft could be made more explicit about that and keeping
> >> the layers suitably delineated should be a design goal.
> >>
> >> Cheers,
> >> Neil.
> >>
> >> > -----Original Message-----
> >> > From: speechsc-admin@ietf.org
> >> > [mailto:speechsc-admin@ietf.org] On Behalf Of Brian Wyld
> >> > Sent: 03 June 2003 06:05
> >> > To: Sarvi Shanmugham; speechsc@ietf.org
> >> > Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC
> >> >
> >> >
> >> > Hi Sarvi,
> >> >
> >> > My initial feedback (before having read the doc in detail) is
> >> > that I was somewhat surprised to see the use of SIP messages
> >> > for the media setup. This did not corrospond to what I had
> >> > thought was the trend of the discussion here, to bypass
> >> > resuse of such a media protocol and create directly a new
> >> > speechsc protocol for this also. (which would probably use
> >> > SDP however).
> >> >
> >> > The major issue I see with your use of SIP
> >> > INVITE/BYE/REINVITE etc is that adds a lot of _potential_
> >> > complexity (it pulls in an entire SIP stack), for very little
> >> > gain in real functionality. I really don't see the use in
> >> > having all the potential SIP stuff and then having to define
> >> > exactly what is and isn't allowed.....
> >> >
> >> > I'd go for a simpler model where we just define new speechsc
> >> > messages to setup/control the media that are specific to
> speechsc.....
> >> >
> >> > Brian
> >> >
> >> > [Brian Wyld] [brian.wyld@eloquant.com]
> >> > [Directeur General R&D]
> >> > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
> >> > [advanced solutions for telecoms and IT services]
> >> >
> >> > > -----Message d'origine-----
> >> > > De : speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]De la
> >> > > part de Sarvi Shanmugham Envoye : Wednesday, May 21, 2003 23:30
> >> > > A : speechsc@ietf.org
> >> > > Objet : [Speechsc] Protpcol proposal for SPEECHSC
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > Hi
> >> > >      Please find attached a proposal for a SPEECHSC protocol. This
> >> > > leverages the MRCP specification. But removes the
> >> > tunnelling aspects
> >> > > of the protocol. I have also submitted this document to the
> >> > internet
> >> > > drafts repository and should be available from there soon.
> >> > >
> >> > > The current version does not address SI and SV aspects of the
> >> > > requirements document. But addresses most of the others.
> >> > This document
> >> > > is meant to be a starting point for a possible direction that the
> >> > > SPEECHSC protocol could take. Based on interest and
> >> > comments received,
> >> > > we can proceed to add SI and SV capabilities in a following
> >> > version of
> >> > > the draft.
> >> > >
> >> > > Any thoughts.
> >> > >
> >> > > Sarvi
> >> > >
> >> >
> >> > _______________________________________________
> >> > Speechsc mailing list
> >> > Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc
> >> >
> >>
> >>
> >
> > _______________________________________________
> > Speechsc mailing list
> > Speechsc@ietf.org
> > https://www1.ietf.org/mailman/listinfo/speechsc
>
>
>
> ------------------------
> David R. Oran
> Cisco Systems
> 7 Ladyslipper Lane
> Acton, MA 01720
> Office: +1 978 264 2048
> VoIP: +1 408 571 4576
> Email: oran@cisco.com
>

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Tue Jun 10 12:40:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08465
	for ; Tue, 10 Jun 2003 12:40:44 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AGeJK07167
	for speechsc-archive@odin.ietf.org; Tue, 10 Jun 2003 12:40:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGeIB07164
	for ; Tue, 10 Jun 2003 12:40:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08441
	for ; Tue, 10 Jun 2003 12:40:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pm8T-0000MR-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 12:38:13 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pm8S-0000MO-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 12:38:12 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGeEB07115;
	Tue, 10 Jun 2003 12:40:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGbUB06815
	for ; Tue, 10 Jun 2003 12:37:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08353
	for ; Tue, 10 Jun 2003 12:37:25 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pm5k-0000Kk-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 12:35:24 -0400
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pm5j-0000K7-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 12:35:23 -0400
Received: from [10.32.254.189] (stealth-10-32-254-189.cisco.com [10.32.254.189])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with SMTP id h5AGakwc026958;
	Tue, 10 Jun 2003 09:36:47 -0700 (PDT)
Date: Tue, 10 Jun 2003 12:36:42 -0400
From: David Oran 
To: brian.wyld@eloquant.com, Neil Deason ,
        "'Sarvi Shanmugham'" , speechsc@ietf.org
Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC
Message-ID: <588578406.1055248602@[10.32.254.189]>
In-Reply-To: 
References:  
X-Mailer: Mulberry/3.0.3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

--On Tuesday, June 10, 2003 6:16 PM +0200 Brian Wyld 
 wrote:

> Hi David,
>
> I'll brutally resume your arguements as:
> "SIP should be supplied natively by all OS's on which you might run
> speechsc, and hence is not a burden for a speechsc implementation"
>
Well, I think that is in fact a fair summary on the server side, but my 
argument was a bit different on the client side (you'd need SIP anyway for 
other things the client was doing and integration would be arguably easier 
than for another protocol).

> Whilst some might dispute this, I don't think this is a true statement
> today; and tomorrow is another country as one might (mis)quote..... Making
> this assumption and basing the operation and acceptance of speechsc on it
> seems unneccessary to me.  Integrating a SIP stack is not a simple
> activity (and generally more expensive if its free!).
>
I won't dispute this either. We are just coming down on different sides of 
a discussion about engineering tradeoffs and what best tracks the direction 
of the technology and industry adoption.

> Sorry, but I still think that it's easier to specify the media setup
> specifically (maybe by cut-n-paste from RTSP) rather than suck in the
> entire SIP protocol.
>
Minor terminology quibble. I think it's hard to dispute that from a 
*specification* point of view it's easier to say "use SIP; describe 
SPEECHSC servers in SDP thusly", than it is to respecify the entire 
rendezvous and session management state machine of even such a simple 
protocol as RTSP. Implementation is another matter of course, and that's 
where the rubber meets the sky...

> Maybe we should instead specify the use of RTSP as the media setup agent,
> as most folks with MRCP experience will have such an implementation
> already and it is known to serve the needs of mrcp......
>
I personally think this is an acceptable alternative, and would be 
perfectly happy to adopt this if we can get WG consensus on such a 
proposal. However... we do have a concrete proposal on the table which uses 
SIP. As someone already noted, it's up to you to offer a concrete (i.e. 
written Internet draft) counter proposal.

> A+
>
Cheers, Dave.

> Brian
>
> PS> I note that to achieve an operation MRCP server today, it is
> neccessary to implement very little of RTSP and none of the media state
> machinary (no play, record etc). In fact, only SETUP and TEARDOWN are
> really required, and the 'tunnel message' ANNOUNCE......
>
> [Brian Wyld] [brian.wyld@eloquant.com]
> [Directeur General R&D]
> [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
> [advanced solutions for telecoms and IT services]
>
>> -----Message d'origine-----
>> De : David R. Oran [mailto:oran@cisco.com]
>> Envoye : Tuesday, June 10, 2003 13:44
>> A : brian.wyld@eloquant.com; Neil Deason; 'Sarvi Shanmugham';
>> speechsc@ietf.org
>> Objet : RE: [Speechsc] Protpcol proposal for SPEECHSC
>>
>>
>> --On Tuesday, June 10, 2003 9:42 AM +0200 Brian Wyld
>>  wrote:
>>
>> > Hi,
>> >
>> > I quite like the idea of separating the media setup and
>> speechsc operation
>> > completely as Sarvi has proposed. However, I think this
>> together with SIP
>> > is going to give us big headaches when it comes to real implementations
>> > and interoperability...
>> >
>> > 1/ SIP-in-speechsc : SIP is a protocol that has lot of stuff
>> that speechsc
>> > does not need - does a speechsc client or server have to supply
>> a full SIP
>> > complient stack, or just the bits that seem to be needed by speechsc?
>> > Do we define a "speechsc profile" to avoid such a problem?
>> >
>> I suspect that once we deviate from 3261 compliance, we are
>> buying tons of
>> potential problems with interoperability and complex
>> specification. While I
>> have seen the profile approach taken in a number of fora, in the IETF tis
>> is generally considered to be inimical to the goal of interoperability
>> which is very high on the IETF's list of criteria for protocol
>> specification.
>>
>> > 2/ SIP-commercial : SIP stacks might be generally available, but is it
>> > really a requirement that a producer of a speechsc
>> client/server must both
>> > create a speechsc stack and acquire a full SIP stack as well?
>> If we decide to go this path, then yes. However, 3261-compliant
>> SIP stacks
>> are quite easy to obtain and there are multiple open source versions
>> (vovida.org, iptel.org). As one of the "SIP bigots", my defense here is
>> that us crazy's really expect SIP to be ubiquitous - of the same
>> universal
>> deployment as DTTP, FTP, Telnet, SMTPm so depending on a SIP stack is a
>> perfectly natural and reasonable thing to do, especially if it simplifies
>> the rest of the problem space, which in this case it seems to do quite
>> nicely.
>>
>> > Although as
>> > Neil says the environment around speechsc is likely to include SIP, a)
>> > this cannot be enforced
>> well...we can enforce it if we so choose. It is unlikely that a service
>> enviroment which employs SPEECHSC would lack FTP, or HTTP, or DNS. This
>> proposal adds SIP to the list of things needed.
>>
>> Also, it seems that the argument that SIP is an extra burden probably
>> applies to the server side, but not really to the client side. Nearly all
>> the envinroments we cite for SPEECHSC are ones in which speech
>> services are
>> being provided within the context of preparing for a session
>> establishment
>> of some sort, or during such sessions. I would have to construct some
>> artificial examples to justify a SPEECHSC client which did not
>> also employ
>> SIP.
>>
>> For servers, your argument carries more weight, since a SPEECHSC
>> server may
>> be just a dedicated back-end box which does not itself initiate or
>> terminate other sessions. In analyzing the tradeoff, I still come down on
>> the SIP side of the equation because SPEECHSC servers are likely to be
>> general-purpose computers, running general-purpose OSs, with a rich
>> programming environment in which embedding SIP should be
>> somewhere between
>> easy and trivial.
>>
>>
>> > and b) the SIP stack elements may be present in
>> > the environment, but not neccessarily in the speechsc elements. In
>> > particular, the speechsc server is unlikely to have a SIP stack in most
>> > cases (IMHO bien sur - none of my MRCP servers have a SIP stack....)
>> >
>> True, but they wound up with nearly all of an RTSP stack, no?
>>
>> > 3/ not-SIP : as Neil says, one could substitute ANOProtocol for
>> SIP and it
>> > should work - however, as there is no mechanism to inform the client or
>> > server of such a substitution this will ensure non-interoperability
>> > between vendors..... (a Bad Thing)
>> >
>> > This said, if we can avoid SIP causing either 'bloat' or an
>> > interoperability nightmare, maybe by creating a 'speechsc profile' then
>> > I'm not against it generally....
>> >
>> I suspect something which mandates less than 3261 compliance will
>> not have
>> an easy time getting through the IESG. On the other hand, I would have no
>> objection to the spec including guidance of the sort "note that a
>> speechsc
>> server has no need to ever initiate a SIP session and hence will be
>> responding to INVITES but not generating them".
>>
>> > Brian
>> >
>> > [Brian Wyld] [brian.wyld@eloquant.com]
>> > [Directeur General R&D]
>> > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
>> > [advanced solutions for telecoms and IT services]
>> >
>> >> -----Message d'origine-----
>> >> De : Neil Deason [mailto:ndeason@ubiquity.net]
>> >> Envoye : Friday, June 06, 2003 21:02
>> >> A : brian.wyld@eloquant.com; 'Sarvi Shanmugham'; speechsc@ietf.org
>> >> Objet : RE: [Speechsc] Protpcol proposal for SPEECHSC
>> >>
>> >>
>> >> Hi.
>> >>
>> >> There are benefits to using SIP with speechsc because the
>> >> architectural model for speechsc is complementary to the
>> >> disaggregated application component model which SIP promotes. Plus it
>> >> avoids re-inventing the wheel for initiation, modification and
>> >> termination of speechsc
>> sessions.
>> >> Speechsc and SIP are synergistic and often likely to be deployed
>> >> within a common environment. Therefore having this form of defined
>> >> working relationship is a good thing.
>> >>
>> >> I don't see anything new needed in SIP for speechsc sessions.
>> It is pure
>> >> reuse. RFC 3261 and RFC 3264 say what is and isn't allowed for SIP and
>> >> the offer/answer model for SDP. The only additions required
>> would be for
>> >> SDP. The IETF promotes a modular multi-protocol approach, so I
>> am afraid
>> >> the question of whether it means another stack is somewhat irrelevant.
>> >> The real question that needs to be asked is does SIP perform the job
>> >> required and the answer appears to be yes.
>> >>
>> >> Now, all that said, I don't think you should have to use SIP to use
>> >> speechsc anymore than you have to use SIP to use RTP. If you want to
>> >> assume a model where a priori knowledge from some other
>> mechanism allows
>> >> a client and server to use speechsc between them that should be
>> >> supported. The draft could be made more explicit about that and
>> >> keeping the layers suitably delineated should be a design goal.
>> >>
>> >> Cheers,
>> >> Neil.
>> >>
>> >> > -----Original Message-----
>> >> > From: speechsc-admin@ietf.org
>> >> > [mailto:speechsc-admin@ietf.org] On Behalf Of Brian Wyld
>> >> > Sent: 03 June 2003 06:05
>> >> > To: Sarvi Shanmugham; speechsc@ietf.org
>> >> > Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC
>> >> >
>> >> >
>> >> > Hi Sarvi,
>> >> >
>> >> > My initial feedback (before having read the doc in detail) is
>> >> > that I was somewhat surprised to see the use of SIP messages
>> >> > for the media setup. This did not corrospond to what I had
>> >> > thought was the trend of the discussion here, to bypass
>> >> > resuse of such a media protocol and create directly a new
>> >> > speechsc protocol for this also. (which would probably use
>> >> > SDP however).
>> >> >
>> >> > The major issue I see with your use of SIP
>> >> > INVITE/BYE/REINVITE etc is that adds a lot of _potential_
>> >> > complexity (it pulls in an entire SIP stack), for very little
>> >> > gain in real functionality. I really don't see the use in
>> >> > having all the potential SIP stuff and then having to define
>> >> > exactly what is and isn't allowed.....
>> >> >
>> >> > I'd go for a simpler model where we just define new speechsc
>> >> > messages to setup/control the media that are specific to
>> speechsc.....
>> >> >
>> >> > Brian
>> >> >
>> >> > [Brian Wyld] [brian.wyld@eloquant.com]
>> >> > [Directeur General R&D]
>> >> > [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
>> >> > [advanced solutions for telecoms and IT services]
>> >> >
>> >> > > -----Message d'origine-----
>> >> > > De : speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]De la
>> >> > > part de Sarvi Shanmugham Envoye : Wednesday, May 21, 2003 23:30
>> >> > > A : speechsc@ietf.org
>> >> > > Objet : [Speechsc] Protpcol proposal for SPEECHSC
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > > Hi
>> >> > >      Please find attached a proposal for a SPEECHSC protocol. This
>> >> > > leverages the MRCP specification. But removes the
>> >> > tunnelling aspects
>> >> > > of the protocol. I have also submitted this document to the
>> >> > internet
>> >> > > drafts repository and should be available from there soon.
>> >> > >
>> >> > > The current version does not address SI and SV aspects of the
>> >> > > requirements document. But addresses most of the others.
>> >> > This document
>> >> > > is meant to be a starting point for a possible direction that the
>> >> > > SPEECHSC protocol could take. Based on interest and
>> >> > comments received,
>> >> > > we can proceed to add SI and SV capabilities in a following
>> >> > version of
>> >> > > the draft.
>> >> > >
>> >> > > Any thoughts.
>> >> > >
>> >> > > Sarvi
>> >> > >
>> >> >
>> >> > _______________________________________________
>> >> > Speechsc mailing list
>> >> > Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc
>> >> >
>> >>
>> >>
>> >
>> > _______________________________________________
>> > Speechsc mailing list
>> > Speechsc@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/speechsc
>>
>>
>>
>> ------------------------
>> David R. Oran
>> Cisco Systems
>> 7 Ladyslipper Lane
>> Acton, MA 01720
>> Office: +1 978 264 2048
>> VoIP: +1 408 571 4576
>> Email: oran@cisco.com
>>
>




_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Tue Jun 10 12:40:48 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08482
	for ; Tue, 10 Jun 2003 12:40:48 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AGeMB07183
	for speechsc-archive@odin.ietf.org; Tue, 10 Jun 2003 12:40:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGeMB07180
	for ; Tue, 10 Jun 2003 12:40:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08445
	for ; Tue, 10 Jun 2003 12:40:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pm8W-0000MX-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 12:38:16 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pm8V-0000MU-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 12:38:15 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGeGB07156;
	Tue, 10 Jun 2003 12:40:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGd0B07000
	for ; Tue, 10 Jun 2003 12:39:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08396
	for ; Tue, 10 Jun 2003 12:38:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pm7C-0000LZ-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 12:36:54 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pm7B-0000LQ-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 12:36:53 -0400
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5AGcLCL011065;
	Tue, 10 Jun 2003 09:38:22 -0700 (PDT)
Received: from cisco.com (dhcp-128-107-139-4.cisco.com [128.107.139.4])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AIF04634;
	Tue, 10 Jun 2003 09:38:21 -0700 (PDT)
Message-ID: <3EE6097D.20100@cisco.com>
Date: Tue, 10 Jun 2003 09:38:21 -0700
From: Sarvi Shanmugham 
Organization: Cisco Systems Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: brian.wyld@eloquant.com
CC: "David R. Oran" , Neil Deason ,
        speechsc@ietf.org
Subject: Re: [Speechsc] Protpcol proposal for SPEECHSC
References: 
Content-Type: multipart/alternative;
 boundary="------------080008060907070606030902"
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	


--------------080008060907070606030902
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Here is my take on using SIP.
    1. It fits very well with what we are doing. Even better than RTSP 
as in MRCP which many people have called a kludgy/ugly etc. and I can 
see where they are coming from.
    2. A protocol such as SPEECHSC, needs a session level protocol that 
does the following.
          1. Locate a server or farm.
          2. Discover capabilities.
          3. Reach the server.
          4. Establish a session.
          5. Add/Remove media and speechsc control pipes.
          6. Support Redirection/Transfer/Load balancing
          7. Support scalability(RTSP does seem to allow the sharing of 
a TCP/SCTP connection between the client and server between multiple 
RTSP/MRCP sessions).
          8. Potentially..... allow the setup of a control pipe between 
the ASR and TTS server for efficient barge-in support. This is a MAY BE. 
I don't want to turn this into a discussion of if this the right or 
wrong approach.
          Now all of the above requirements, would basically mean that 
session message additions directly to SPEECHSC would get us a session 
protocol very close to SIP. So why reinvent the wheel.
          More over the conference control which controls yet another 
media resource for conferencing seems to be going along these lines.

         Though I very much considered RTSP as well, I felt SIP would be 
a much better fit and would be a much more welcome choice with the rest 
of IETF.

Sarvi

Brian Wyld wrote:

>Hi David,
>
>I'll brutally resume your arguements as:
>"SIP should be supplied natively by all OS's on which you might run
>speechsc, and hence is not a burden for a speechsc implementation"
>
>Whilest some might dispute this, I don't think this is a true statement
>today; and tomorrow is another country as one might (mis)quote..... Making
>this assumption and basing the operation and acceptance of speechsc on it
>seems unneccessary to me.  Integrating a SIP stack is not a simple activity
>(and generally more expensive if its free!).
>
>Sorry, but I still think that it's easier to specify the media setup
>specifically (maybe by cut-n-paste from RTSP) rather than suck in the entire
>SIP protocol.
>
>Maybe we should instead specify the use of RTSP as the media setup agent, as
>most folks with MRCP experience will have such an implementation already and
>it is known to serve the needs of mrcp......
>
>A+
>
>Brian
>
>PS> I note that to achieve an operation MRCP server today, it is neccessary
>to implement very little of RTSP and none of the media state machinary (no
>play, record etc). In fact, only SETUP and TEARDOWN are really required, and
>the 'tunnel message' ANNOUNCE......
>
>[Brian Wyld] [brian.wyld@eloquant.com]
>[Directeur General R&D]
>[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
>[advanced solutions for telecoms and IT services]
>
>  
>
>>-----Message d'origine-----
>>De : David R. Oran [mailto:oran@cisco.com]
>>Envoye : Tuesday, June 10, 2003 13:44
>>A : brian.wyld@eloquant.com; Neil Deason; 'Sarvi Shanmugham';
>>speechsc@ietf.org
>>Objet : RE: [Speechsc] Protpcol proposal for SPEECHSC
>>
>>
>>--On Tuesday, June 10, 2003 9:42 AM +0200 Brian Wyld
>> wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>I quite like the idea of separating the media setup and
>>>      
>>>
>>speechsc operation
>>    
>>
>>>completely as Sarvi has proposed. However, I think this
>>>      
>>>
>>together with SIP
>>    
>>
>>>is going to give us big headaches when it comes to real implementations
>>>and interoperability...
>>>
>>>1/ SIP-in-speechsc : SIP is a protocol that has lot of stuff
>>>      
>>>
>>that speechsc
>>    
>>
>>>does not need - does a speechsc client or server have to supply
>>>      
>>>
>>a full SIP
>>    
>>
>>>complient stack, or just the bits that seem to be needed by speechsc? Do
>>>we define a "speechsc profile" to avoid such a problem?
>>>
>>>      
>>>
>>I suspect that once we deviate from 3261 compliance, we are
>>buying tons of
>>potential problems with interoperability and complex
>>specification. While I
>>have seen the profile approach taken in a number of fora, in the IETF tis
>>is generally considered to be inimical to the goal of interoperability
>>which is very high on the IETF's list of criteria for protocol
>>specification.
>>
>>    
>>
>>>2/ SIP-commercial : SIP stacks might be generally available, but is it
>>>really a requirement that a producer of a speechsc
>>>      
>>>
>>client/server must both
>>    
>>
>>>create a speechsc stack and acquire a full SIP stack as well?
>>>      
>>>
>>If we decide to go this path, then yes. However, 3261-compliant
>>SIP stacks
>>are quite easy to obtain and there are multiple open source versions
>>(vovida.org, iptel.org). As one of the "SIP bigots", my defense here is
>>that us crazy's really expect SIP to be ubiquitous - of the same
>>universal
>>deployment as DTTP, FTP, Telnet, SMTPm so depending on a SIP stack is a
>>perfectly natural and reasonable thing to do, especially if it simplifies
>>the rest of the problem space, which in this case it seems to do quite
>>nicely.
>>
>>    
>>
>>>Although as
>>>Neil says the environment around speechsc is likely to include SIP, a)
>>>this cannot be enforced
>>>      
>>>
>>well...we can enforce it if we so choose. It is unlikely that a service
>>enviroment which employs SPEECHSC would lack FTP, or HTTP, or DNS. This
>>proposal adds SIP to the list of things needed.
>>
>>Also, it seems that the argument that SIP is an extra burden probably
>>applies to the server side, but not really to the client side. Nearly all
>>the envinroments we cite for SPEECHSC are ones in which speech
>>services are
>>being provided within the context of preparing for a session
>>establishment
>>of some sort, or during such sessions. I would have to construct some
>>artificial examples to justify a SPEECHSC client which did not
>>also employ
>>SIP.
>>
>>For servers, your argument carries more weight, since a SPEECHSC
>>server may
>>be just a dedicated back-end box which does not itself initiate or
>>terminate other sessions. In analyzing the tradeoff, I still come down on
>>the SIP side of the equation because SPEECHSC servers are likely to be
>>general-purpose computers, running general-purpose OSs, with a rich
>>programming environment in which embedding SIP should be
>>somewhere between
>>easy and trivial.
>>
>>
>>    
>>
>>>and b) the SIP stack elements may be present in
>>>the environment, but not neccessarily in the speechsc elements. In
>>>particular, the speechsc server is unlikely to have a SIP stack in most
>>>cases (IMHO bien sur - none of my MRCP servers have a SIP stack....)
>>>
>>>      
>>>
>>True, but they wound up with nearly all of an RTSP stack, no?
>>
>>    
>>
>>>3/ not-SIP : as Neil says, one could substitute ANOProtocol for
>>>      
>>>
>>SIP and it
>>    
>>
>>>should work - however, as there is no mechanism to inform the client or
>>>server of such a substitution this will ensure non-interoperability
>>>between vendors..... (a Bad Thing)
>>>
>>>This said, if we can avoid SIP causing either 'bloat' or an
>>>interoperability nightmare, maybe by creating a 'speechsc profile' then
>>>I'm not against it generally....
>>>
>>>      
>>>
>>I suspect something which mandates less than 3261 compliance will
>>not have
>>an easy time getting through the IESG. On the other hand, I would have no
>>objection to the spec including guidance of the sort "note that a
>>speechsc
>>server has no need to ever initiate a SIP session and hence will be
>>responding to INVITES but not generating them".
>>
>>    
>>
>>>Brian
>>>
>>>[Brian Wyld] [brian.wyld@eloquant.com]
>>>[Directeur General R&D]
>>>[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
>>>[advanced solutions for telecoms and IT services]
>>>
>>>      
>>>
>>>>-----Message d'origine-----
>>>>De : Neil Deason [mailto:ndeason@ubiquity.net]
>>>>Envoye : Friday, June 06, 2003 21:02
>>>>A : brian.wyld@eloquant.com; 'Sarvi Shanmugham'; speechsc@ietf.org
>>>>Objet : RE: [Speechsc] Protpcol proposal for SPEECHSC
>>>>
>>>>
>>>>Hi.
>>>>
>>>>There are benefits to using SIP with speechsc because the architectural
>>>>model for speechsc is complementary to the disaggregated application
>>>>component model which SIP promotes. Plus it avoids re-inventing the
>>>>wheel for initiation, modification and termination of speechsc
>>>>        
>>>>
>>sessions.
>>    
>>
>>>>Speechsc and SIP are synergistic and often likely to be deployed within
>>>>a common environment. Therefore having this form of defined working
>>>>relationship is a good thing.
>>>>
>>>>I don't see anything new needed in SIP for speechsc sessions.
>>>>        
>>>>
>>It is pure
>>    
>>
>>>>reuse. RFC 3261 and RFC 3264 say what is and isn't allowed for SIP and
>>>>the offer/answer model for SDP. The only additions required
>>>>        
>>>>
>>would be for
>>    
>>
>>>>SDP. The IETF promotes a modular multi-protocol approach, so I
>>>>        
>>>>
>>am afraid
>>    
>>
>>>>the question of whether it means another stack is somewhat irrelevant.
>>>>The real question that needs to be asked is does SIP perform the job
>>>>required and the answer appears to be yes.
>>>>
>>>>Now, all that said, I don't think you should have to use SIP to use
>>>>speechsc anymore than you have to use SIP to use RTP. If you want to
>>>>assume a model where a priori knowledge from some other
>>>>        
>>>>
>>mechanism allows
>>    
>>
>>>>a client and server to use speechsc between them that should be
>>>>supported. The draft could be made more explicit about that and keeping
>>>>the layers suitably delineated should be a design goal.
>>>>
>>>>Cheers,
>>>>Neil.
>>>>
>>>>        
>>>>
>>>>>-----Original Message-----
>>>>>From: speechsc-admin@ietf.org
>>>>>[mailto:speechsc-admin@ietf.org] On Behalf Of Brian Wyld
>>>>>Sent: 03 June 2003 06:05
>>>>>To: Sarvi Shanmugham; speechsc@ietf.org
>>>>>Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC
>>>>>
>>>>>
>>>>>Hi Sarvi,
>>>>>
>>>>>My initial feedback (before having read the doc in detail) is
>>>>>that I was somewhat surprised to see the use of SIP messages
>>>>>for the media setup. This did not corrospond to what I had
>>>>>thought was the trend of the discussion here, to bypass
>>>>>resuse of such a media protocol and create directly a new
>>>>>speechsc protocol for this also. (which would probably use
>>>>>SDP however).
>>>>>
>>>>>The major issue I see with your use of SIP
>>>>>INVITE/BYE/REINVITE etc is that adds a lot of _potential_
>>>>>complexity (it pulls in an entire SIP stack), for very little
>>>>>gain in real functionality. I really don't see the use in
>>>>>having all the potential SIP stuff and then having to define
>>>>>exactly what is and isn't allowed.....
>>>>>
>>>>>I'd go for a simpler model where we just define new speechsc
>>>>>messages to setup/control the media that are specific to
>>>>>          
>>>>>
>>speechsc.....
>>    
>>
>>>>>Brian
>>>>>
>>>>>[Brian Wyld] [brian.wyld@eloquant.com]
>>>>>[Directeur General R&D]
>>>>>[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
>>>>>[advanced solutions for telecoms and IT services]
>>>>>
>>>>>          
>>>>>
>>>>>>-----Message d'origine-----
>>>>>>De : speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]De la
>>>>>>part de Sarvi Shanmugham Envoye : Wednesday, May 21, 2003 23:30
>>>>>>A : speechsc@ietf.org
>>>>>>Objet : [Speechsc] Protpcol proposal for SPEECHSC
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>Hi
>>>>>>     Please find attached a proposal for a SPEECHSC protocol. This
>>>>>>leverages the MRCP specification. But removes the
>>>>>>            
>>>>>>
>>>>>tunnelling aspects
>>>>>          
>>>>>
>>>>>>of the protocol. I have also submitted this document to the
>>>>>>            
>>>>>>
>>>>>internet
>>>>>          
>>>>>
>>>>>>drafts repository and should be available from there soon.
>>>>>>
>>>>>>The current version does not address SI and SV aspects of the
>>>>>>requirements document. But addresses most of the others.
>>>>>>            
>>>>>>
>>>>>This document
>>>>>          
>>>>>
>>>>>>is meant to be a starting point for a possible direction that the
>>>>>>SPEECHSC protocol could take. Based on interest and
>>>>>>            
>>>>>>
>>>>>comments received,
>>>>>          
>>>>>
>>>>>>we can proceed to add SI and SV capabilities in a following
>>>>>>            
>>>>>>
>>>>>version of
>>>>>          
>>>>>
>>>>>>the draft.
>>>>>>
>>>>>>Any thoughts.
>>>>>>
>>>>>>Sarvi
>>>>>>
>>>>>>            
>>>>>>
>>>>>_______________________________________________
>>>>>Speechsc mailing list
>>>>>Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc
>>>>>
>>>>>          
>>>>>
>>>>        
>>>>
>>>_______________________________________________
>>>Speechsc mailing list
>>>Speechsc@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/speechsc
>>>      
>>>
>>
>>------------------------
>>David R. Oran
>>Cisco Systems
>>7 Ladyslipper Lane
>>Acton, MA 01720
>>Office: +1 978 264 2048
>>VoIP: +1 408 571 4576
>>Email: oran@cisco.com
>>
>>    
>>
>
>
>  
>


--------------080008060907070606030902
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  


Here is my take on using SIP.

    1. It fits very well with what we are doing. Even better than RTSP as
in MRCP which many people have called a kludgy/ugly etc. and I can see where
they are coming from.

    2. A protocol such as SPEECHSC, needs a session level protocol that does
the following.

          1. Locate a server or farm.

          2. Discover capabilities.

          3. Reach the server.

          4. Establish a session.

          5. Add/Remove media and speechsc control pipes. 

          6. Support Redirection/Transfer/Load balancing

          7. Support scalability(RTSP does seem to allow the sharing of a
TCP/SCTP connection between the client and server between multiple RTSP/MRCP
sessions).

          8. Potentially..... allow the setup of a control pipe between the
ASR and TTS server for efficient barge-in support. This is a MAY BE. I don't
want to turn this into a discussion of if this the right or wrong approach.

          Now all of the above requirements, would basically mean that session
message additions directly to SPEECHSC would get us a session protocol very
close to SIP. So why reinvent the wheel. 

          More over the conference control which controls yet another media
resource for conferencing seems to be going along these lines. 



         Though I very much considered RTSP as well, I felt SIP would be
a much better fit and would be a much more welcome choice with the rest of
IETF.



Sarvi



Brian Wyld wrote:



  
Hi David,

I'll brutally resume your arguements as:
"SIP should be supplied natively by all OS's on which you might run
speechsc, and hence is not a burden for a speechsc implementation"

Whilest some might dispute this, I don't think this is a true statement
today; and tomorrow is another country as one might (mis)quote..... Making
this assumption and basing the operation and acceptance of speechsc on it
seems unneccessary to me.  Integrating a SIP stack is not a simple activity
(and generally more expensive if its free!).

Sorry, but I still think that it's easier to specify the media setup
specifically (maybe by cut-n-paste from RTSP) rather than suck in the entire
SIP protocol.

Maybe we should instead specify the use of RTSP as the media setup agent, as
most folks with MRCP experience will have such an implementation already and
it is known to serve the needs of mrcp......

A+

Brian

PS> I note that to achieve an operation MRCP server today, it is neccessary
to implement very little of RTSP and none of the media state machinary (no
play, record etc). In fact, only SETUP and TEARDOWN are really required, and
the 'tunnel message' ANNOUNCE......

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

  

  

    
-----Message d'origine-----
De : David R. Oran [mailto:oran@cisco.com]
Envoye : Tuesday, June 10, 2003 13:44
A : brian.wyld@eloquant.com; Neil Deason; 'Sarvi Shanmugham';
speechsc@ietf.org
Objet : RE: [Speechsc] Protpcol proposal for SPEECHSC


--On Tuesday, June 10, 2003 9:42 AM +0200 Brian Wyld
<brian.wyld@eloquant.com> wrote:

    

    

      
Hi,

I quite like the idea of separating the media setup and
      

    

    
speechsc operation
    

    

      
completely as Sarvi has proposed. However, I think this
      

    

    
together with SIP
    

    

      
is going to give us big headaches when it comes to real implementations
and interoperability...

1/ SIP-in-speechsc : SIP is a protocol that has lot of stuff
      

    

    
that speechsc
    

    

      
does not need - does a speechsc client or server have to supply
      

    

    
a full SIP
    

    

      
complient stack, or just the bits that seem to be needed by speechsc? Do
we define a "speechsc profile" to avoid such a problem?

      

    

    
I suspect that once we deviate from 3261 compliance, we are
buying tons of
potential problems with interoperability and complex
specification. While I
have seen the profile approach taken in a number of fora, in the IETF tis
is generally considered to be inimical to the goal of interoperability
which is very high on the IETF's list of criteria for protocol
specification.

    

    

      
2/ SIP-commercial : SIP stacks might be generally available, but is it
really a requirement that a producer of a speechsc
      

    

    
client/server must both
    

    

      
create a speechsc stack and acquire a full SIP stack as well?
      

    

    
If we decide to go this path, then yes. However, 3261-compliant
SIP stacks
are quite easy to obtain and there are multiple open source versions
(vovida.org, iptel.org). As one of the "SIP bigots", my defense here is
that us crazy's really expect SIP to be ubiquitous - of the same
universal
deployment as DTTP, FTP, Telnet, SMTPm so depending on a SIP stack is a
perfectly natural and reasonable thing to do, especially if it simplifies
the rest of the problem space, which in this case it seems to do quite
nicely.

    

    

      
Although as
Neil says the environment around speechsc is likely to include SIP, a)
this cannot be enforced
      

    

    
well...we can enforce it if we so choose. It is unlikely that a service
enviroment which employs SPEECHSC would lack FTP, or HTTP, or DNS. This
proposal adds SIP to the list of things needed.

Also, it seems that the argument that SIP is an extra burden probably
applies to the server side, but not really to the client side. Nearly all
the envinroments we cite for SPEECHSC are ones in which speech
services are
being provided within the context of preparing for a session
establishment
of some sort, or during such sessions. I would have to construct some
artificial examples to justify a SPEECHSC client which did not
also employ
SIP.

For servers, your argument carries more weight, since a SPEECHSC
server may
be just a dedicated back-end box which does not itself initiate or
terminate other sessions. In analyzing the tradeoff, I still come down on
the SIP side of the equation because SPEECHSC servers are likely to be
general-purpose computers, running general-purpose OSs, with a rich
programming environment in which embedding SIP should be
somewhere between
easy and trivial.


    

    

      
and b) the SIP stack elements may be present in
the environment, but not neccessarily in the speechsc elements. In
particular, the speechsc server is unlikely to have a SIP stack in most
cases (IMHO bien sur - none of my MRCP servers have a SIP stack....)

      

    

    
True, but they wound up with nearly all of an RTSP stack, no?

    

    

      
3/ not-SIP : as Neil says, one could substitute ANOProtocol for
      

    

    
SIP and it
    

    

      
should work - however, as there is no mechanism to inform the client or
server of such a substitution this will ensure non-interoperability
between vendors..... (a Bad Thing)

This said, if we can avoid SIP causing either 'bloat' or an
interoperability nightmare, maybe by creating a 'speechsc profile' then
I'm not against it generally....

      

    

    
I suspect something which mandates less than 3261 compliance will
not have
an easy time getting through the IESG. On the other hand, I would have no
objection to the spec including guidance of the sort "note that a
speechsc
server has no need to ever initiate a SIP session and hence will be
responding to INVITES but not generating them".

    

    

      
Brian

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

      

      

        
-----Message d'origine-----
De : Neil Deason [mailto:ndeason@ubiquity.net]
Envoye : Friday, June 06, 2003 21:02
A : brian.wyld@eloquant.com; 'Sarvi Shanmugham'; speechsc@ietf.org
Objet : RE: [Speechsc] Protpcol proposal for SPEECHSC


Hi.

There are benefits to using SIP with speechsc because the architectural
model for speechsc is complementary to the disaggregated application
component model which SIP promotes. Plus it avoids re-inventing the
wheel for initiation, modification and termination of speechsc
        

      

    

    
sessions.
    

    

      

        
Speechsc and SIP are synergistic and often likely to be deployed within
a common environment. Therefore having this form of defined working
relationship is a good thing.

I don't see anything new needed in SIP for speechsc sessions.
        

      

    

    
It is pure
    

    

      

        
reuse. RFC 3261 and RFC 3264 say what is and isn't allowed for SIP and
the offer/answer model for SDP. The only additions required
        

      

    

    
would be for
    

    

      

        
SDP. The IETF promotes a modular multi-protocol approach, so I
        

      

    

    
am afraid
    

    

      

        
the question of whether it means another stack is somewhat irrelevant.
The real question that needs to be asked is does SIP perform the job
required and the answer appears to be yes.

Now, all that said, I don't think you should have to use SIP to use
speechsc anymore than you have to use SIP to use RTP. If you want to
assume a model where a priori knowledge from some other
        

      

    

    
mechanism allows
    

    

      

        
a client and server to use speechsc between them that should be
supported. The draft could be made more explicit about that and keeping
the layers suitably delineated should be a design goal.

Cheers,
Neil.

        

        

          
-----Original Message-----
From: speechsc-admin@ietf.org
[mailto:speechsc-admin@ietf.org] On Behalf Of Brian Wyld
Sent: 03 June 2003 06:05
To: Sarvi Shanmugham; speechsc@ietf.org
Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC


Hi Sarvi,

My initial feedback (before having read the doc in detail) is
that I was somewhat surprised to see the use of SIP messages
for the media setup. This did not corrospond to what I had
thought was the trend of the discussion here, to bypass
resuse of such a media protocol and create directly a new
speechsc protocol for this also. (which would probably use
SDP however).

The major issue I see with your use of SIP
INVITE/BYE/REINVITE etc is that adds a lot of _potential_
complexity (it pulls in an entire SIP stack), for very little
gain in real functionality. I really don't see the use in
having all the potential SIP stuff and then having to define
exactly what is and isn't allowed.....

I'd go for a simpler model where we just define new speechsc
messages to setup/control the media that are specific to
          

        

      

    

    
speechsc.....
    

    

      

        

          
Brian

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

          

          

            
-----Message d'origine-----
De : speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]De la
part de Sarvi Shanmugham Envoye : Wednesday, May 21, 2003 23:30
A : speechsc@ietf.org
Objet : [Speechsc] Protpcol proposal for SPEECHSC




Hi
     Please find attached a proposal for a SPEECHSC protocol. This
leverages the MRCP specification. But removes the
            

          

          
tunnelling aspects
          

          

            
of the protocol. I have also submitted this document to the
            

          

          
internet
          

          

            
drafts repository and should be available from there soon.

The current version does not address SI and SV aspects of the
requirements document. But addresses most of the others.
            

          

          
This document
          

          

            
is meant to be a starting point for a possible direction that the
SPEECHSC protocol could take. Based on interest and
            

          

          
comments received,
          

          

            
we can proceed to add SI and SV capabilities in a following
            

          

          
version of
          

          

            
the draft.

Any thoughts.

Sarvi

            

          

          
_______________________________________________
Speechsc mailing list
Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc

          

        

        
        

      

      
_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc
      

    

    

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: oran@cisco.com

    

  

  


  








--------------080008060907070606030902--

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Tue Jun 10 15:31:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14691
	for ; Tue, 10 Jun 2003 15:31:45 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AJVHP19491
	for speechsc-archive@odin.ietf.org; Tue, 10 Jun 2003 15:31:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJVHB19488
	for ; Tue, 10 Jun 2003 15:31:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14679
	for ; Tue, 10 Jun 2003 15:31:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ponw-0001Yc-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 15:29:12 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ponw-0001YZ-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 15:29:12 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJVDB19480;
	Tue, 10 Jun 2003 15:31:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJUrB19415
	for ; Tue, 10 Jun 2003 15:30:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14641
	for ; Tue, 10 Jun 2003 15:30:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PonY-0001Xk-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 15:28:48 -0400
Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com)
	by ietf-mx with smtp (Exim 4.12)
	id 19PonY-0001XL-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 15:28:48 -0400
Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap 
	 id 7855; Tue, 10 Jun 2003 15:31:52 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Speechsc] Protocol proposal for SPEECHSC
Date: Tue, 10 Jun 2003 15:30:21 -0400
Message-ID: <4A3384433CE2AB46A63468CB207E209D097C9E@zoe.office.snowshore.com>
Thread-Topic: [Speechsc] Protpcol proposal for SPEECHSC
Thread-Index: AcMvblcLM+xPmBY+SWKlouzL9QdxJgAFwdTQ
From: "Eric Burger" 
To: , 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5AJUrB19416
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

> -----Original Message----- From: Brian Wyld [mailto:brian.wyld@eloquant.com]
> Sent: Tue, June 10, 2003 12:16 PM

[snip]

> Sorry, but I still think that it's easier to specify the media setup
> specifically (maybe by cut-n-paste from RTSP) rather than 
> suck in the entire
> SIP protocol.

I would be very hesitant to create yet another "looks like SIP/RTSP, smells like SIP/RTSP, operates like SIP/RTSP, but has a different life and future than SIP/RTSP."

I'd much rather leverage the 974 engineer years of work over the last 6 years put in to SIP than spend 3 engineer years explaining what is the same and different in a new protocol.  Moreover, I would not want to find myself wishing I had 500 engineer years of resources to catch up when something useful gets introduced into SIP/RTSP that I might want.

SIP is actually pretty good when dealing with small, embedded implementations.  Most everything is an extension ("Accept/Allow").  You don't even need the list of extensions to say, "I don't know what you are talking about."  Thus an SPEECHSC-only implementation can be pretty light.  It is what we do in the media server world, for example.

> 
> Maybe we should instead specify the use of RTSP as the media 
> setup agent, as
> most folks with MRCP experience will have such an 
> implementation already and
> it is known to serve the needs of mrcp......

I can go either way.  At this point one could submit a RTSP-based SPEECHSC protocol proposal, similar to Sarvi's.  Alternately, one could submit a "these are the reasons RTSP works/interoperates/easier-to-implement than SIP" draft.

Do be aware that you have until 0900 USA-ET to submit a -00 draft.

> 
> A+
> 
> Brian
> 
> PS> I note that to achieve an operation MRCP server today, it 
> is neccessary
> to implement very little of RTSP and none of the media state 
> machinary (no
> play, record etc). In fact, only SETUP and TEARDOWN are 
> really required, and
> the 'tunnel message' ANNOUNCE......

My point above, exactly...

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Tue Jun 10 15:34:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14751
	for ; Tue, 10 Jun 2003 15:34:33 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AJY5c19617
	for speechsc-archive@odin.ietf.org; Tue, 10 Jun 2003 15:34:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJY5B19613
	for ; Tue, 10 Jun 2003 15:34:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14744
	for ; Tue, 10 Jun 2003 15:34:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Poqe-0001ZO-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 15:32:01 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Poqe-0001ZL-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 15:32:00 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJY1B19600;
	Tue, 10 Jun 2003 15:34:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AJXiB19582
	for ; Tue, 10 Jun 2003 15:33:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14737
	for ; Tue, 10 Jun 2003 15:33:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PoqK-0001ZB-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 15:31:40 -0400
Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com)
	by ietf-mx with smtp (Exim 4.12)
	id 19PoqJ-0001Z2-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 15:31:39 -0400
Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap 
	 id 4320; Tue, 10 Jun 2003 15:34:43 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 10 Jun 2003 15:33:12 -0400
Message-ID: <4A3384433CE2AB46A63468CB207E209D59E357@zoe.office.snowshore.com>
Thread-Topic: Internet Draft cutoff dates and Meeting Materials
Thread-Index: AcMvhyGdwTfvaRAHQSq1z/cEsB1ZNg==
From: "Eric Burger" 
To: "IETF SPEECHSC (E-mail)" 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5AJXiB19583
Subject: [Speechsc] Internet Draft cutoff dates and Meeting Materials
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Please be aware of looming Internet Draft dates:

June 23, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00 ET
June 30, Monday - Internet Draft final submission cut-off at 09:00 ET

* All times are in US Eastern Time 


You MUST have drafts in by that date for consideration in our working session.

I have requested a 2-hour working session in Vienna.  In the *unlikely* event you wish to make a presentation (it is, after all, a working session), please send it to me NO LATER than Tuesday, July 8.

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Tue Jun 10 16:27:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16414
	for ; Tue, 10 Jun 2003 16:27:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AKR8Q23717
	for speechsc-archive@odin.ietf.org; Tue, 10 Jun 2003 16:27:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AKR8B23714
	for ; Tue, 10 Jun 2003 16:27:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16365
	for ; Tue, 10 Jun 2003 16:27:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ppfy-0001si-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 16:25:02 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Ppfy-0001sf-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 16:25:02 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AKR5B23706;
	Tue, 10 Jun 2003 16:27:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AKQKB23667
	for ; Tue, 10 Jun 2003 16:26:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16282
	for ; Tue, 10 Jun 2003 16:26:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PpfC-0001sM-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 16:24:14 -0400
Received: from navgw.sandcherry.com ([63.117.80.26])
	by ietf-mx with smtp (Exim 4.12)
	id 19PpfB-0001s6-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 16:24:13 -0400
Received: from con-63-117-80-25.rocky.net ([10.20.1.32])
 by navgw.sandcherry.com (SAVSMTP 3.0.0.44) with SMTP id M2003061014251417456
 ; Tue, 10 Jun 2003 14:25:14 -0600
Received: by exchange01.sccorp.com with Internet Mail Service (5.5.2656.59)
	id ; Tue, 10 Jun 2003 14:25:14 -0600
Message-ID: 
From: Brian Marquette 
To: "'Eric Burger '" ,
        "'brian.wyld@eloquant.com '"
	 ,
        "'speechsc@ietf.org '" 
Subject: RE: [Speechsc] Protocol proposal for SPEECHSC
Date: Tue, 10 Jun 2003 14:25:13 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	

The setup and teardown of SPEECHSC sessions using SIP DOES work very well
and I believe is the right way to go. SIP is becoming more and more
pervasive (3G, etc) and will be the prominent interface to media servers.

Although RTSP can work as well, I believe that SIP will continue to be
adopted much more predominantly.

brian



-----Original Message-----
From: Eric Burger
To: brian.wyld@eloquant.com; speechsc@ietf.org
Sent: 10/06/2003 13:30
Subject: RE: [Speechsc] Protocol proposal for SPEECHSC

> -----Original Message----- From: Brian Wyld
[mailto:brian.wyld@eloquant.com]
> Sent: Tue, June 10, 2003 12:16 PM

[snip]

> Sorry, but I still think that it's easier to specify the media setup
> specifically (maybe by cut-n-paste from RTSP) rather than 
> suck in the entire
> SIP protocol.

I would be very hesitant to create yet another "looks like SIP/RTSP,
smells like SIP/RTSP, operates like SIP/RTSP, but has a different life
and future than SIP/RTSP."

I'd much rather leverage the 974 engineer years of work over the last 6
years put in to SIP than spend 3 engineer years explaining what is the
same and different in a new protocol.  Moreover, I would not want to
find myself wishing I had 500 engineer years of resources to catch up
when something useful gets introduced into SIP/RTSP that I might want.

SIP is actually pretty good when dealing with small, embedded
implementations.  Most everything is an extension ("Accept/Allow").  You
don't even need the list of extensions to say, "I don't know what you
are talking about."  Thus an SPEECHSC-only implementation can be pretty
light.  It is what we do in the media server world, for example.

> 
> Maybe we should instead specify the use of RTSP as the media 
> setup agent, as
> most folks with MRCP experience will have such an 
> implementation already and
> it is known to serve the needs of mrcp......

I can go either way.  At this point one could submit a RTSP-based
SPEECHSC protocol proposal, similar to Sarvi's.  Alternately, one could
submit a "these are the reasons RTSP
works/interoperates/easier-to-implement than SIP" draft.

Do be aware that you have until 0900 USA-ET to submit a -00 draft.

> 
> A+
> 
> Brian
> 
> PS> I note that to achieve an operation MRCP server today, it 
> is neccessary
> to implement very little of RTSP and none of the media state 
> machinary (no
> play, record etc). In fact, only SETUP and TEARDOWN are 
> really required, and
> the 'tunnel message' ANNOUNCE......

My point above, exactly...

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc
_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Tue Jun 10 17:31:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18937
	for ; Tue, 10 Jun 2003 17:31:40 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5ALVEo28860
	for speechsc-archive@odin.ietf.org; Tue, 10 Jun 2003 17:31:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ALVEB28857
	for ; Tue, 10 Jun 2003 17:31:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18913
	for ; Tue, 10 Jun 2003 17:31:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pqfz-0002N1-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 17:29:07 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pqfz-0002My-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 17:29:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ALV9B28847;
	Tue, 10 Jun 2003 17:31:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ALU4B28787
	for ; Tue, 10 Jun 2003 17:30:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18858
	for ; Tue, 10 Jun 2003 17:29:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pqer-0002MM-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 17:27:57 -0400
Received: from smtp-102-tuesday.nerim.net ([62.4.16.102] helo=kraid.nerim.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Pqeq-0002MJ-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 17:27:56 -0400
Received: from weasel.hq.eloquant.com (styx.eloquant.com [80.65.227.37])
	by kraid.nerim.net (Postfix) with ESMTP
	id D120F40F7E; Tue, 10 Jun 2003 23:29:57 +0200 (CEST)
Received: from polo (atalante.hq.eloquant.com [192.168.0.11])
	by weasel.hq.eloquant.com (Postfix) with SMTP
	id 998D83B6CA; Tue, 10 Jun 2003 17:35:44 -0400 (EDT)
Reply-To: 
From: "Brian Wyld" 
To: "Eric Burger" , 
Subject: RE: [Speechsc] Protocol proposal for SPEECHSC
Date: Tue, 10 Jun 2003 23:25:46 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <4A3384433CE2AB46A63468CB207E209D097C9E@zoe.office.snowshore.com>
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5ALV9B28847
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5ALVEB28857
Content-Transfer-Encoding: 8bit

Ok, if I have time I will munge something thru a web services toolset and
produce an alternative proposal based on WS.....

Then again, maybe not.

To be frank, if you all want SIP, and I don't see many other viewpoints
here, then I'll go with your experience. As long as we can model all the
different session viewpoints (as already discussed here) that are needed for
usage of the resources then that's fine with me. (pointers to a good open
source java SIP stack gratefully received....)

So, is anyone going to update their sections for the protocol comparison
document before the 30th June or not?

Brian (another hapless victem crushed by the SIP juggernaught)

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

> -----Message d'origine-----
> De : Eric Burger [mailto:eburger@snowshore.com]
> Envoyé : Tuesday, June 10, 2003 21:30
> À : brian.wyld@eloquant.com; speechsc@ietf.org
> Objet : RE: [Speechsc] Protocol proposal for SPEECHSC
>
>
> > -----Original Message----- From: Brian Wyld
> [mailto:brian.wyld@eloquant.com]
> > Sent: Tue, June 10, 2003 12:16 PM
>
> [snip]
>
> > Sorry, but I still think that it's easier to specify the media setup
> > specifically (maybe by cut-n-paste from RTSP) rather than
> > suck in the entire
> > SIP protocol.
>
> I would be very hesitant to create yet another "looks like
> SIP/RTSP, smells like SIP/RTSP, operates like SIP/RTSP, but has a
> different life and future than SIP/RTSP."
>
> I'd much rather leverage the 974 engineer years of work over the
> last 6 years put in to SIP than spend 3 engineer years explaining
> what is the same and different in a new protocol.  Moreover, I
> would not want to find myself wishing I had 500 engineer years of
> resources to catch up when something useful gets introduced into
> SIP/RTSP that I might want.
>
> SIP is actually pretty good when dealing with small, embedded
> implementations.  Most everything is an extension
> ("Accept/Allow").  You don't even need the list of extensions to
> say, "I don't know what you are talking about."  Thus an
> SPEECHSC-only implementation can be pretty light.  It is what we
> do in the media server world, for example.
>
> >
> > Maybe we should instead specify the use of RTSP as the media
> > setup agent, as
> > most folks with MRCP experience will have such an
> > implementation already and
> > it is known to serve the needs of mrcp......
>
> I can go either way.  At this point one could submit a RTSP-based
> SPEECHSC protocol proposal, similar to Sarvi's.  Alternately, one
> could submit a "these are the reasons RTSP
> works/interoperates/easier-to-implement than SIP" draft.
>
> Do be aware that you have until 0900 USA-ET to submit a -00 draft.
>
> >
> > A+
> >
> > Brian
> >
> > PS> I note that to achieve an operation MRCP server today, it
> > is neccessary
> > to implement very little of RTSP and none of the media state
> > machinary (no
> > play, record etc). In fact, only SETUP and TEARDOWN are
> > really required, and
> > the 'tunnel message' ANNOUNCE......
>
> My point above, exactly...
>
>

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Tue Jun 10 18:13:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20781
	for ; Tue, 10 Jun 2003 18:13:33 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5AMD9Z32068
	for speechsc-archive@odin.ietf.org; Tue, 10 Jun 2003 18:13:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AMD9B32065
	for ; Tue, 10 Jun 2003 18:13:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20719
	for ; Tue, 10 Jun 2003 18:13:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PrKX-0002c2-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 18:11:01 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PrKW-0002bz-00
	for speechsc-web-archive@ietf.org; Tue, 10 Jun 2003 18:11:00 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AMD4B32057;
	Tue, 10 Jun 2003 18:13:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AMCvB32043
	for ; Tue, 10 Jun 2003 18:12:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20688
	for ; Tue, 10 Jun 2003 18:12:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PrKL-0002bs-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 18:10:49 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PrKK-0002bS-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 18:10:48 -0400
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5AMCIms006477;
	Tue, 10 Jun 2003 15:12:18 -0700 (PDT)
Received: from cisco.com (dhcp-128-107-139-4.cisco.com [128.107.139.4])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AIF55657;
	Tue, 10 Jun 2003 15:12:17 -0700 (PDT)
Message-ID: <3EE657C0.4010107@cisco.com>
Date: Tue, 10 Jun 2003 15:12:16 -0700
From: Sarvi Shanmugham 
Organization: Cisco Systems Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: brian.wyld@eloquant.com
CC: Eric Burger , speechsc@ietf.org
Subject: Re: [Speechsc] Protocol proposal for SPEECHSC
References: 
Content-Type: multipart/alternative;
 boundary="------------050208020604090503050204"
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	


--------------050208020604090503050204
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-MIME-Autoconverted: from 8bit to quoted-printable by sj-core-1.cisco.com id h5AMCIms006477
Content-Transfer-Encoding: quoted-printable

Hi Brian,
            Does my section need updation(MRCP evalutation), if so let=20
me know and I will get back o you with the edits by the end of next week.

Sarvi

Brian Wyld wrote:

>Ok, if I have time I will munge something thru a web services toolset an=
d
>produce an alternative proposal based on WS.....
>
>Then again, maybe not.
>
>To be frank, if you all want SIP, and I don't see many other viewpoints
>here, then I'll go with your experience. As long as we can model all the
>different session viewpoints (as already discussed here) that are needed=
 for
>usage of the resources then that's fine with me. (pointers to a good ope=
n
>source java SIP stack gratefully received....)
>
>So, is anyone going to update their sections for the protocol comparison
>document before the 30th June or not?
>
>Brian (another hapless victem crushed by the SIP juggernaught)
>
>[Brian Wyld] [brian.wyld@eloquant.com]
>[Directeur General R&D]
>[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
>[advanced solutions for telecoms and IT services]
>
> =20
>
>>-----Message d'origine-----
>>De : Eric Burger [mailto:eburger@snowshore.com]
>>Envoy=E9 : Tuesday, June 10, 2003 21:30
>>=C0 : brian.wyld@eloquant.com; speechsc@ietf.org
>>Objet : RE: [Speechsc] Protocol proposal for SPEECHSC
>>
>>
>>   =20
>>
>>>-----Original Message----- From: Brian Wyld
>>>     =20
>>>
>>[mailto:brian.wyld@eloquant.com]
>>   =20
>>
>>>Sent: Tue, June 10, 2003 12:16 PM
>>>     =20
>>>
>>[snip]
>>
>>   =20
>>
>>>Sorry, but I still think that it's easier to specify the media setup
>>>specifically (maybe by cut-n-paste from RTSP) rather than
>>>suck in the entire
>>>SIP protocol.
>>>     =20
>>>
>>I would be very hesitant to create yet another "looks like
>>SIP/RTSP, smells like SIP/RTSP, operates like SIP/RTSP, but has a
>>different life and future than SIP/RTSP."
>>
>>I'd much rather leverage the 974 engineer years of work over the
>>last 6 years put in to SIP than spend 3 engineer years explaining
>>what is the same and different in a new protocol.  Moreover, I
>>would not want to find myself wishing I had 500 engineer years of
>>resources to catch up when something useful gets introduced into
>>SIP/RTSP that I might want.
>>
>>SIP is actually pretty good when dealing with small, embedded
>>implementations.  Most everything is an extension
>>("Accept/Allow").  You don't even need the list of extensions to
>>say, "I don't know what you are talking about."  Thus an
>>SPEECHSC-only implementation can be pretty light.  It is what we
>>do in the media server world, for example.
>>
>>   =20
>>
>>>Maybe we should instead specify the use of RTSP as the media
>>>setup agent, as
>>>most folks with MRCP experience will have such an
>>>implementation already and
>>>it is known to serve the needs of mrcp......
>>>     =20
>>>
>>I can go either way.  At this point one could submit a RTSP-based
>>SPEECHSC protocol proposal, similar to Sarvi's.  Alternately, one
>>could submit a "these are the reasons RTSP
>>works/interoperates/easier-to-implement than SIP" draft.
>>
>>Do be aware that you have until 0900 USA-ET to submit a -00 draft.
>>
>>   =20
>>
>>>A+
>>>
>>>Brian
>>>
>>>PS> I note that to achieve an operation MRCP server today, it
>>>is neccessary
>>>to implement very little of RTSP and none of the media state
>>>machinary (no
>>>play, record etc). In fact, only SETUP and TEARDOWN are
>>>really required, and
>>>the 'tunnel message' ANNOUNCE......
>>>     =20
>>>
>>My point above, exactly...
>>
>>
>>   =20
>>
>
>_______________________________________________
>Speechsc mailing list
>Speechsc@ietf.org
>https://www1.ietf.org/mailman/listinfo/speechsc
>
> =20
>


--------------050208020604090503050204
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


Hi Brian,

            Does my section need updation(MRCP evalutation), if so let me
know and I will get back o you with the edits by the end of next week.



Sarvi



Brian Wyld wrote:



  
Ok, if I have time I will munge something thru a web services toolset and
produce an alternative proposal based on WS.....

Then again, maybe not.

To be frank, if you all want SIP, and I don't see many other viewpoints
here, then I'll go with your experience. As long as we can model all the
different session viewpoints (as already discussed here) that are needed for
usage of the resources then that's fine with me. (pointers to a good open
source java SIP stack gratefully received....)

So, is anyone going to update their sections for the protocol comparison
document before the 30th June or not?

Brian (another hapless victem crushed by the SIP juggernaught)

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

  

  

    
-----Message d'origine-----
De : Eric Burger [mailto:eburger@snowshore.com]
Envoyé : Tuesday, June 10, 2003 21:30
À : brian.wyld@eloquant.com; speechsc@ietf.org
Objet : RE: [Speechsc] Protocol proposal for SPEECHSC


    

    

      
-----Original Message----- From: Brian Wyld
      

    

    
[mailto:brian.wyld@eloquant.com]
    

    

      
Sent: Tue, June 10, 2003 12:16 PM
      

    

    
[snip]

    

    

      
Sorry, but I still think that it's easier to specify the media setup
specifically (maybe by cut-n-paste from RTSP) rather than
suck in the entire
SIP protocol.
      

    

    
I would be very hesitant to create yet another "looks like
SIP/RTSP, smells like SIP/RTSP, operates like SIP/RTSP, but has a
different life and future than SIP/RTSP."

I'd much rather leverage the 974 engineer years of work over the
last 6 years put in to SIP than spend 3 engineer years explaining
what is the same and different in a new protocol.  Moreover, I
would not want to find myself wishing I had 500 engineer years of
resources to catch up when something useful gets introduced into
SIP/RTSP that I might want.

SIP is actually pretty good when dealing with small, embedded
implementations.  Most everything is an extension
("Accept/Allow").  You don't even need the list of extensions to
say, "I don't know what you are talking about."  Thus an
SPEECHSC-only implementation can be pretty light.  It is what we
do in the media server world, for example.

    

    

      
Maybe we should instead specify the use of RTSP as the media
setup agent, as
most folks with MRCP experience will have such an
implementation already and
it is known to serve the needs of mrcp......
      

    

    
I can go either way.  At this point one could submit a RTSP-based
SPEECHSC protocol proposal, similar to Sarvi's.  Alternately, one
could submit a "these are the reasons RTSP
works/interoperates/easier-to-implement than SIP" draft.

Do be aware that you have until 0900 USA-ET to submit a -00 draft.

    

    

      
A+

Brian

PS> I note that to achieve an operation MRCP server today, it
is neccessary
to implement very little of RTSP and none of the media state
machinary (no
play, record etc). In fact, only SETUP and TEARDOWN are
really required, and
the 'tunnel message' ANNOUNCE......
      

    

    
My point above, exactly...


    

  

  

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc

  








--------------050208020604090503050204--

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Wed Jun 11 02:58:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27653
	for ; Wed, 11 Jun 2003 02:58:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5B6wBR11791
	for speechsc-archive@odin.ietf.org; Wed, 11 Jun 2003 02:58:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B6wAB11788
	for ; Wed, 11 Jun 2003 02:58:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27649
	for ; Wed, 11 Jun 2003 02:58:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PzWb-0005S7-00
	for speechsc-web-archive@ietf.org; Wed, 11 Jun 2003 02:56:01 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PzWa-0005S4-00
	for speechsc-web-archive@ietf.org; Wed, 11 Jun 2003 02:56:00 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B6w5B11779;
	Wed, 11 Jun 2003 02:58:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B6vgB11762
	for ; Wed, 11 Jun 2003 02:57:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27640
	for ; Wed, 11 Jun 2003 02:57:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PzW9-0005Rl-00
	for speechsc@ietf.org; Wed, 11 Jun 2003 02:55:33 -0400
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PzW8-0005Rh-00
	for speechsc@ietf.org; Wed, 11 Jun 2003 02:55:32 -0400
Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121])
	by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5B6vHT3029002;
	Wed, 11 Jun 2003 08:57:17 +0200 (MEST)
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id LVY395MZ; Wed, 11 Jun 2003 08:58:26 +0200
Message-ID: <3EE6D223.50303@ericsson.com>
Date: Wed, 11 Jun 2003 08:54:27 +0200
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: brian.wyld@eloquant.com
CC: speechsc@ietf.org
Subject: Re: [Speechsc] Protpcol proposal for SPEECHSC
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Brian,

I would like to give some comments on why RTSP may not be the best 
choice even if you are only using the SETUP part.

- RTSP uses a lot of RTTs. RTSP requires at least two RTT, if more than 
one media stream needs to be established.

- There exist no specification for secured transport of RTSP yet.

- The NAT traversal in RTSP is not as mature and with less work going on 
than for SIP.

- Currently no stable and good specification exist. RFC 2326 is not that 
much to have.


Best Regards

Magnus Westerlund

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Wed Jun 11 08:05:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04370
	for ; Wed, 11 Jun 2003 08:05:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BC5Eh00350
	for speechsc-archive@odin.ietf.org; Wed, 11 Jun 2003 08:05:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BC5EB00347
	for ; Wed, 11 Jun 2003 08:05:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04329
	for ; Wed, 11 Jun 2003 08:05:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q4Jo-0006vW-00
	for speechsc-web-archive@ietf.org; Wed, 11 Jun 2003 08:03:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q4Jn-0006vS-00
	for speechsc-web-archive@ietf.org; Wed, 11 Jun 2003 08:03:07 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BC59B00307;
	Wed, 11 Jun 2003 08:05:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ALmAB30291
	for ; Tue, 10 Jun 2003 17:48:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19423
	for ; Tue, 10 Jun 2003 17:48:04 -0400 (EDT)
From: jhaynie@vocalocity.net
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PqwM-0002Ul-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 17:46:03 -0400
Received: from [216.248.178.195] (helo=luke.vocalocity.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PqwM-0002Ui-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 17:46:02 -0400
Received: (from www@localhost)
	by luke.vocalocity.net (8.11.6/8.11.6) id h5ALm5j07644
	for speechsc@ietf.org; Tue, 10 Jun 2003 17:48:05 -0400
X-Authentication-Warning: luke.vocalocity.net: www set sender to jhaynie@vocalocity.net using -f
Received: from 131.107.167.7 ( [131.107.167.7])
	as user jhaynie@192.168.248.1 by luke.vocalocity.net with HTTP;
	Tue, 10 Jun 2003 17:48:04 -0400
Message-ID: <1055281684.3ee65214e6401@luke.vocalocity.net>
Date: Tue, 10 Jun 2003 17:48:04 -0400
To: speechsc@ietf.org
Subject: RE: [Speechsc] Protocol proposal for SPEECHSC
References: 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
User-Agent: Internet Messaging Program (IMP) 3.1
X-Originating-IP: 131.107.167.7
X-MIME-Autoconverted: from 8bit to quoted-printable by luke.vocalocity.net id h5ALm5j07644
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5ALmAB30292
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5BC59B00307
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5BC5EB00347
Content-Transfer-Encoding: 8bit

NIST has a JAIN compatible SIP stack.

http://snad.ncsl.nist.gov/proj/iptel/


Better than open source, its considered public domain I believe.

Jeff
CTO
Vocalocity, Inc.


Quoting Brian Wyld :

> Ok, if I have time I will munge something thru a web services toolset and
> produce an alternative proposal based on WS.....
> 
> Then again, maybe not.
> 
> To be frank, if you all want SIP, and I don't see many other viewpoints
> here, then I'll go with your experience. As long as we can model all the
> different session viewpoints (as already discussed here) that are needed for
> usage of the resources then that's fine with me. (pointers to a good open
> source java SIP stack gratefully received....)
> 
> So, is anyone going to update their sections for the protocol comparison
> document before the 30th June or not?
> 
> Brian (another hapless victem crushed by the SIP juggernaught)
> 
> [Brian Wyld] [brian.wyld@eloquant.com]
> [Directeur General R&D]
> [Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
> [advanced solutions for telecoms and IT services]
> 
> > -----Message d'origine-----
> > De : Eric Burger [mailto:eburger@snowshore.com]
> > Envoyé : Tuesday, June 10, 2003 21:30
> > À : brian.wyld@eloquant.com; speechsc@ietf.org
> > Objet : RE: [Speechsc] Protocol proposal for SPEECHSC
> >
> >
> > > -----Original Message----- From: Brian Wyld
> > [mailto:brian.wyld@eloquant.com]
> > > Sent: Tue, June 10, 2003 12:16 PM
> >
> > [snip]
> >
> > > Sorry, but I still think that it's easier to specify the media setup
> > > specifically (maybe by cut-n-paste from RTSP) rather than
> > > suck in the entire
> > > SIP protocol.
> >
> > I would be very hesitant to create yet another "looks like
> > SIP/RTSP, smells like SIP/RTSP, operates like SIP/RTSP, but has a
> > different life and future than SIP/RTSP."
> >
> > I'd much rather leverage the 974 engineer years of work over the
> > last 6 years put in to SIP than spend 3 engineer years explaining
> > what is the same and different in a new protocol.  Moreover, I
> > would not want to find myself wishing I had 500 engineer years of
> > resources to catch up when something useful gets introduced into
> > SIP/RTSP that I might want.
> >
> > SIP is actually pretty good when dealing with small, embedded
> > implementations.  Most everything is an extension
> > ("Accept/Allow").  You don't even need the list of extensions to
> > say, "I don't know what you are talking about."  Thus an
> > SPEECHSC-only implementation can be pretty light.  It is what we
> > do in the media server world, for example.
> >
> > >
> > > Maybe we should instead specify the use of RTSP as the media
> > > setup agent, as
> > > most folks with MRCP experience will have such an
> > > implementation already and
> > > it is known to serve the needs of mrcp......
> >
> > I can go either way.  At this point one could submit a RTSP-based
> > SPEECHSC protocol proposal, similar to Sarvi's.  Alternately, one
> > could submit a "these are the reasons RTSP
> > works/interoperates/easier-to-implement than SIP" draft.
> >
> > Do be aware that you have until 0900 USA-ET to submit a -00 draft.
> >
> > >
> > > A+
> > >
> > > Brian
> > >
> > > PS> I note that to achieve an operation MRCP server today, it
> > > is neccessary
> > > to implement very little of RTSP and none of the media state
> > > machinary (no
> > > play, record etc). In fact, only SETUP and TEARDOWN are
> > > really required, and
> > > the 'tunnel message' ANNOUNCE......
> >
> > My point above, exactly...
> >
> >
> 
> _______________________________________________
> Speechsc mailing list
> Speechsc@ietf.org
> https://www1.ietf.org/mailman/listinfo/speechsc
> 



_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Wed Jun 11 08:05:46 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04385
	for ; Wed, 11 Jun 2003 08:05:46 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BC5Ia00366
	for speechsc-archive@odin.ietf.org; Wed, 11 Jun 2003 08:05:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BC5IB00363
	for ; Wed, 11 Jun 2003 08:05:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04334
	for ; Wed, 11 Jun 2003 08:05:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q4Jr-0006vd-00
	for speechsc-web-archive@ietf.org; Wed, 11 Jun 2003 08:03:11 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q4Jq-0006vZ-00
	for speechsc-web-archive@ietf.org; Wed, 11 Jun 2003 08:03:10 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BC5DB00339;
	Wed, 11 Jun 2003 08:05:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B1SsB11896
	for ; Tue, 10 Jun 2003 21:28:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25658
	for ; Tue, 10 Jun 2003 21:28:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PuNz-0003na-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 21:26:47 -0400
Received: from krishna.genesyslab.com ([198.49.180.171])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PuNy-0003nQ-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 21:26:46 -0400
Received: from aster.us.int.genesyslab.com ([10.10.10.25.26929])
	by krishna.genesyslab.com with esmtp (Exim 3.36 #1)
	id 19PuPL-0006Dh-00; Tue, 10 Jun 2003 18:28:11 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Speechsc] Protocol proposal for SPEECHSC
Date: Tue, 10 Jun 2003 18:28:05 -0700
Message-ID: <52F49B5A0E5B0F4781C9C8F7159409E48394B4@aster.us.int.genesyslab.com>
Thread-Topic: [Speechsc] Protocol proposal for SPEECHSC
Thread-Index: AcMvl6JoW6P04f42QlCofqaZ+wMQjwAIO/uA
From: "Rajiv Dharmadhikari" 
To: , "Eric Burger" ,
        
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5B1SsB11897
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5BC5DB00339
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5BC5IB00363
Content-Transfer-Encoding: 8bit

Brian,

I will have my changes done by early next week.

-Rajiv

-----Original Message-----
From: Brian Wyld [mailto:brian.wyld@eloquant.com]
Sent: Tuesday, June 10, 2003 2:26 PM
To: Eric Burger; speechsc@ietf.org
Subject: RE: [Speechsc] Protocol proposal for SPEECHSC


Ok, if I have time I will munge something thru a web services toolset and
produce an alternative proposal based on WS.....

Then again, maybe not.

To be frank, if you all want SIP, and I don't see many other viewpoints
here, then I'll go with your experience. As long as we can model all the
different session viewpoints (as already discussed here) that are needed for
usage of the resources then that's fine with me. (pointers to a good open
source java SIP stack gratefully received....)

So, is anyone going to update their sections for the protocol comparison
document before the 30th June or not?

Brian (another hapless victem crushed by the SIP juggernaught)

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

> -----Message d'origine-----
> De : Eric Burger [mailto:eburger@snowshore.com]
> Envoyé : Tuesday, June 10, 2003 21:30
> À : brian.wyld@eloquant.com; speechsc@ietf.org
> Objet : RE: [Speechsc] Protocol proposal for SPEECHSC
>
>
> > -----Original Message----- From: Brian Wyld
> [mailto:brian.wyld@eloquant.com]
> > Sent: Tue, June 10, 2003 12:16 PM
>
> [snip]
>
> > Sorry, but I still think that it's easier to specify the media setup
> > specifically (maybe by cut-n-paste from RTSP) rather than
> > suck in the entire
> > SIP protocol.
>
> I would be very hesitant to create yet another "looks like
> SIP/RTSP, smells like SIP/RTSP, operates like SIP/RTSP, but has a
> different life and future than SIP/RTSP."
>
> I'd much rather leverage the 974 engineer years of work over the
> last 6 years put in to SIP than spend 3 engineer years explaining
> what is the same and different in a new protocol.  Moreover, I
> would not want to find myself wishing I had 500 engineer years of
> resources to catch up when something useful gets introduced into
> SIP/RTSP that I might want.
>
> SIP is actually pretty good when dealing with small, embedded
> implementations.  Most everything is an extension
> ("Accept/Allow").  You don't even need the list of extensions to
> say, "I don't know what you are talking about."  Thus an
> SPEECHSC-only implementation can be pretty light.  It is what we
> do in the media server world, for example.
>
> >
> > Maybe we should instead specify the use of RTSP as the media
> > setup agent, as
> > most folks with MRCP experience will have such an
> > implementation already and
> > it is known to serve the needs of mrcp......
>
> I can go either way.  At this point one could submit a RTSP-based
> SPEECHSC protocol proposal, similar to Sarvi's.  Alternately, one
> could submit a "these are the reasons RTSP
> works/interoperates/easier-to-implement than SIP" draft.
>
> Do be aware that you have until 0900 USA-ET to submit a -00 draft.
>
> >
> > A+
> >
> > Brian
> >
> > PS> I note that to achieve an operation MRCP server today, it
> > is neccessary
> > to implement very little of RTSP and none of the media state
> > machinary (no
> > play, record etc). In fact, only SETUP and TEARDOWN are
> > really required, and
> > the 'tunnel message' ANNOUNCE......
>
> My point above, exactly...
>
>

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc
_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Wed Jun 11 08:05:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04387
	for ; Wed, 11 Jun 2003 08:05:46 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BC5JT00382
	for speechsc-archive@odin.ietf.org; Wed, 11 Jun 2003 08:05:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BC5IB00379
	for ; Wed, 11 Jun 2003 08:05:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04337
	for ; Wed, 11 Jun 2003 08:05:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q4Jr-0006vg-00
	for speechsc-web-archive@ietf.org; Wed, 11 Jun 2003 08:03:11 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q4Jq-0006va-00
	for speechsc-web-archive@ietf.org; Wed, 11 Jun 2003 08:03:10 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BC5CB00323;
	Wed, 11 Jun 2003 08:05:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B1RMB11794
	for ; Tue, 10 Jun 2003 21:27:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25620
	for ; Tue, 10 Jun 2003 21:27:18 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19PuMV-0003mu-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 21:25:15 -0400
Received: from ns1.wc.wcnat.genesyslab.com ([199.165.223.221] helo=mail3.genesyslab.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19PuMT-0003ml-00
	for speechsc@ietf.org; Tue, 10 Jun 2003 21:25:13 -0400
Received: from aster.us.int.genesyslab.com ([10.10.10.25.19249])
	by mail3.genesyslab.com with esmtp (Exim 3.36 #1)
	id 19PuNn-000OTU-00; Tue, 10 Jun 2003 18:26:35 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C32FB8.7E398478"
Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC
Date: Tue, 10 Jun 2003 18:26:33 -0700
Message-ID: <52F49B5A0E5B0F4781C9C8F7159409E48394B3@aster.us.int.genesyslab.com>
Thread-Topic: [Speechsc] Protpcol proposal for SPEECHSC
Thread-Index: AcMvbwCydw5IXwrwQwiIrt+lDnc9oAASDjPg
From: "Rajiv Dharmadhikari" 
To: "Sarvi Shanmugham" , 
Cc: "David R. Oran" , "Neil Deason" ,
        
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	

This is a multi-part message in MIME format.

------_=_NextPart_001_01C32FB8.7E398478
Content-Type: text/plain;
	charset="KOI8-R"
Content-Transfer-Encoding: quoted-printable

Sorry to jump in late here as I wrote the SIP chapter in protocol =
evaluation draft for Speechsc.=20
=20
I agree with the approach of using SIP for Speechsc session =
establishment and having a separate channel for Speechsc messages. For =
all the benefits described below (server location, scalability etc.), =
SIP is perfect for establishing sessions for Speechsc. Most of the =
VoiceXML or SALT browsers will have SIP stack to manage media streams =
from/to media server and ASR/TTS servers. Therefore, I do not think SIP =
will make the Speechsc client implementaion anymore bulky.=20
=20
-Rajiv

-----Original Message-----
From: Sarvi Shanmugham [mailto:sarvi@cisco.com]
Sent: Tuesday, June 10, 2003 9:38 AM
To: brian.wyld@eloquant.com
Cc: David R. Oran; Neil Deason; speechsc@ietf.org
Subject: Re: [Speechsc] Protpcol proposal for SPEECHSC


Here is my take on using SIP.
    1. It fits very well with what we are doing. Even better than RTSP =
as in MRCP which many people have called a kludgy/ugly etc. and I can =
see where they are coming from.
    2. A protocol such as SPEECHSC, needs a session level protocol that =
does the following.
          1. Locate a server or farm.
          2. Discover capabilities.
          3. Reach the server.
          4. Establish a session.
          5. Add/Remove media and speechsc control pipes.=20
          6. Support Redirection/Transfer/Load balancing
          7. Support scalability(RTSP does seem to allow the sharing of =
a TCP/SCTP connection between the client and server between multiple =
RTSP/MRCP sessions).
          8. Potentially..... allow the setup of a control pipe between =
the ASR and TTS server for efficient barge-in support. This is a MAY BE. =
I don't want to turn this into a discussion of if this the right or =
wrong approach.
          Now all of the above requirements, would basically mean that =
session message additions directly to SPEECHSC would get us a session =
protocol very close to SIP. So why reinvent the wheel.=20
          More over the conference control which controls yet another =
media resource for conferencing seems to be going along these lines.=20

         Though I very much considered RTSP as well, I felt SIP would be =
a much better fit and would be a much more welcome choice with the rest =
of IETF.

Sarvi

Brian Wyld wrote:


Hi David,



I'll brutally resume your arguements as:

"SIP should be supplied natively by all OS's on which you might run

speechsc, and hence is not a burden for a speechsc implementation"



Whilest some might dispute this, I don't think this is a true statement

today; and tomorrow is another country as one might (mis)quote..... =
Making

this assumption and basing the operation and acceptance of speechsc on =
it

seems unneccessary to me.  Integrating a SIP stack is not a simple =
activity

(and generally more expensive if its free!).



Sorry, but I still think that it's easier to specify the media setup

specifically (maybe by cut-n-paste from RTSP) rather than suck in the =
entire

SIP protocol.



Maybe we should instead specify the use of RTSP as the media setup =
agent, as

most folks with MRCP experience will have such an implementation already =
and

it is known to serve the needs of mrcp......



A+



Brian



PS> I note that to achieve an operation MRCP server today, it is =
neccessary

to implement very little of RTSP and none of the media state machinary =
(no

play, record etc). In fact, only SETUP and TEARDOWN are really required, =
and

the 'tunnel message' ANNOUNCE......



[Brian Wyld] [ brian.wyld@eloquant.com]

[Directeur General R&D]

[Eloquant SA] [+33 476 77 46 92] [ www.eloquant.com]

[advanced solutions for telecoms and IT services]



 =20

-----Message d'origine-----

De : David R. Oran [ mailto:oran@cisco.com]

Envoye : Tuesday, June 10, 2003 13:44

A :  brian.wyld@eloquant.com; Neil Deason; 'Sarvi Shanmugham';

speechsc@ietf.org

Objet : RE: [Speechsc] Protpcol proposal for SPEECHSC





--On Tuesday, June 10, 2003 9:42 AM +0200 Brian Wyld

   wrote:



   =20

Hi,



I quite like the idea of separating the media setup and

     =20

speechsc operation

   =20

completely as Sarvi has proposed. However, I think this

     =20

together with SIP

   =20

is going to give us big headaches when it comes to real implementations

and interoperability...



1/ SIP-in-speechsc : SIP is a protocol that has lot of stuff

     =20

that speechsc

   =20

does not need - does a speechsc client or server have to supply

     =20

a full SIP

   =20

complient stack, or just the bits that seem to be needed by speechsc? Do

we define a "speechsc profile" to avoid such a problem?



     =20

I suspect that once we deviate from 3261 compliance, we are

buying tons of

potential problems with interoperability and complex

specification. While I

have seen the profile approach taken in a number of fora, in the IETF =
tis

is generally considered to be inimical to the goal of interoperability

which is very high on the IETF's list of criteria for protocol

specification.



   =20

2/ SIP-commercial : SIP stacks might be generally available, but is it

really a requirement that a producer of a speechsc

     =20

client/server must both

   =20

create a speechsc stack and acquire a full SIP stack as well?

     =20

If we decide to go this path, then yes. However, 3261-compliant

SIP stacks

are quite easy to obtain and there are multiple open source versions

(vovida.org, iptel.org). As one of the "SIP bigots", my defense here is

that us crazy's really expect SIP to be ubiquitous - of the same

universal

deployment as DTTP, FTP, Telnet, SMTPm so depending on a SIP stack is a

perfectly natural and reasonable thing to do, especially if it =
simplifies

the rest of the problem space, which in this case it seems to do quite

nicely.



   =20

Although as

Neil says the environment around speechsc is likely to include SIP, a)

this cannot be enforced

     =20

well...we can enforce it if we so choose. It is unlikely that a service

enviroment which employs SPEECHSC would lack FTP, or HTTP, or DNS. This

proposal adds SIP to the list of things needed.



Also, it seems that the argument that SIP is an extra burden probably

applies to the server side, but not really to the client side. Nearly =
all

the envinroments we cite for SPEECHSC are ones in which speech

services are

being provided within the context of preparing for a session

establishment

of some sort, or during such sessions. I would have to construct some

artificial examples to justify a SPEECHSC client which did not

also employ

SIP.



For servers, your argument carries more weight, since a SPEECHSC

server may

be just a dedicated back-end box which does not itself initiate or

terminate other sessions. In analyzing the tradeoff, I still come down =
on

the SIP side of the equation because SPEECHSC servers are likely to be

general-purpose computers, running general-purpose OSs, with a rich

programming environment in which embedding SIP should be

somewhere between

easy and trivial.





   =20

and b) the SIP stack elements may be present in

the environment, but not neccessarily in the speechsc elements. In

particular, the speechsc server is unlikely to have a SIP stack in most

cases (IMHO bien sur - none of my MRCP servers have a SIP stack....)



     =20

True, but they wound up with nearly all of an RTSP stack, no?



   =20

3/ not-SIP : as Neil says, one could substitute ANOProtocol for

     =20

SIP and it

   =20

should work - however, as there is no mechanism to inform the client or

server of such a substitution this will ensure non-interoperability

between vendors..... (a Bad Thing)



This said, if we can avoid SIP causing either 'bloat' or an

interoperability nightmare, maybe by creating a 'speechsc profile' then

I'm not against it generally....



     =20

I suspect something which mandates less than 3261 compliance will

not have

an easy time getting through the IESG. On the other hand, I would have =
no

objection to the spec including guidance of the sort "note that a

speechsc

server has no need to ever initiate a SIP session and hence will be

responding to INVITES but not generating them".



   =20

Brian



[Brian Wyld] [ brian.wyld@eloquant.com]

[Directeur General R&D]

[Eloquant SA] [+33 476 77 46 92] [ www.eloquant.com]

[advanced solutions for telecoms and IT services]



     =20

-----Message d'origine-----

De : Neil Deason [ mailto:ndeason@ubiquity.net]

Envoye : Friday, June 06, 2003 21:02

A :  brian.wyld@eloquant.com; 'Sarvi Shanmugham';  speechsc@ietf.org

Objet : RE: [Speechsc] Protpcol proposal for SPEECHSC





Hi.



There are benefits to using SIP with speechsc because the architectural

model for speechsc is complementary to the disaggregated application

component model which SIP promotes. Plus it avoids re-inventing the

wheel for initiation, modification and termination of speechsc

       =20

sessions.

   =20

Speechsc and SIP are synergistic and often likely to be deployed within

a common environment. Therefore having this form of defined working

relationship is a good thing.



I don't see anything new needed in SIP for speechsc sessions.

       =20

It is pure

   =20

reuse. RFC 3261 and RFC 3264 say what is and isn't allowed for SIP and

the offer/answer model for SDP. The only additions required

       =20

would be for

   =20

SDP. The IETF promotes a modular multi-protocol approach, so I

       =20

am afraid

   =20

the question of whether it means another stack is somewhat irrelevant.

The real question that needs to be asked is does SIP perform the job

required and the answer appears to be yes.



Now, all that said, I don't think you should have to use SIP to use

speechsc anymore than you have to use SIP to use RTP. If you want to

assume a model where a priori knowledge from some other

       =20

mechanism allows

   =20

a client and server to use speechsc between them that should be

supported. The draft could be made more explicit about that and keeping

the layers suitably delineated should be a design goal.



Cheers,

Neil.



       =20

-----Original Message-----

From:  speechsc-admin@ietf.org

[ mailto:speechsc-admin@ietf.org] On Behalf Of Brian Wyld

Sent: 03 June 2003 06:05

To: Sarvi Shanmugham;  speechsc@ietf.org

Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC





Hi Sarvi,



My initial feedback (before having read the doc in detail) is

that I was somewhat surprised to see the use of SIP messages

for the media setup. This did not corrospond to what I had

thought was the trend of the discussion here, to bypass

resuse of such a media protocol and create directly a new

speechsc protocol for this also. (which would probably use

SDP however).



The major issue I see with your use of SIP

INVITE/BYE/REINVITE etc is that adds a lot of _potential_

complexity (it pulls in an entire SIP stack), for very little

gain in real functionality. I really don't see the use in

having all the potential SIP stuff and then having to define

exactly what is and isn't allowed.....



I'd go for a simpler model where we just define new speechsc

messages to setup/control the media that are specific to

         =20

speechsc.....

   =20

Brian



[Brian Wyld] [ brian.wyld@eloquant.com]

[Directeur General R&D]

[Eloquant SA] [+33 476 77 46 92] [ www.eloquant.com]

[advanced solutions for telecoms and IT services]



         =20

-----Message d'origine-----

De :  speechsc-admin@ietf.org [ mailto:speechsc-admin@ietf.org]De la

part de Sarvi Shanmugham Envoye : Wednesday, May 21, 2003 23:30

A :  speechsc@ietf.org

Objet : [Speechsc] Protpcol proposal for SPEECHSC









Hi

     Please find attached a proposal for a SPEECHSC protocol. This

leverages the MRCP specification. But removes the

           =20

tunnelling aspects

         =20

of the protocol. I have also submitted this document to the

           =20

internet

         =20

drafts repository and should be available from there soon.



The current version does not address SI and SV aspects of the

requirements document. But addresses most of the others.

           =20

This document

         =20

is meant to be a starting point for a possible direction that the

SPEECHSC protocol could take. Based on interest and

           =20

comments received,

         =20

we can proceed to add SI and SV capabilities in a following

           =20

version of

         =20

the draft.



Any thoughts.



Sarvi



           =20

_______________________________________________

Speechsc mailing list

Speechsc@ietf.org  https://www1.ietf.org/mailman/listinfo/speechsc



         =20

       =20

_______________________________________________

Speechsc mailing list

Speechsc@ietf.org

https://www1.ietf.org/mailman/listinfo/speechsc

     =20



------------------------

David R. Oran

Cisco Systems

7 Ladyslipper Lane

Acton, MA 01720

Office: +1 978 264 2048

VoIP: +1 408 571 4576

Email:  oran@cisco.com



   =20





 =20



------_=_NextPart_001_01C32FB8.7E398478
Content-Type: text/html;
	charset="KOI8-R"
Content-Transfer-Encoding: quoted-printable









Sorry=20
to jump in late here as I wrote the SIP chapter in protocol =
evaluation draft=20
for Speechsc. 


 


I=20
agree with the approach of using SIP for Speechsc session establishment =
and=20
having a separate channel for Speechsc messages. For all the benefits =
described=20
below (server location, scalability etc.), SIP is perfect for =
establishing=20
sessions for Speechsc. Most of the VoiceXML or SALT browsers will have =
SIP stack=20
to manage media streams from/to media server and ASR/TTS servers. =
Therefore, I=20
do not think SIP will make the Speechsc client implementaion anymore =
bulky.=20



 


-Rajiv



  
-----Original Message-----
From: Sarvi Shanmugham=20
  [mailto:sarvi@cisco.com]
Sent: Tuesday, June 10, 2003 9:38=20
  AM
To: brian.wyld@eloquant.com
Cc: David R. Oran; =
Neil=20
  Deason; speechsc@ietf.org
Subject: Re: [Speechsc] Protpcol =
proposal=20
  for SPEECHSC

Here is my take on using =
SIP.
 =20
    1. It fits very well with what we are doing. Even better than =
RTSP as=20
  in MRCP which many people have called a kludgy/ugly etc. and I can see =
where=20
  they are coming from.
    2. A protocol such as SPEECHSC, =
needs a=20
  session level protocol that does the following.
    =
   =20
    1. Locate a server or farm.
        =
  2.=20
  Discover capabilities.
          3. Reach =
the=20
  server.
          4. Establish a=20
  session.
          5. Add/Remove media and =

  speechsc control pipes. 
          6. =
Support=20
  Redirection/Transfer/Load balancing
        =
  7.=20
  Support scalability(RTSP does seem to allow the sharing of a TCP/SCTP=20
  connection between the client and server between multiple RTSP/MRCP=20
  sessions).
          8. Potentially..... =
allow the=20
  setup of a control pipe between the ASR and TTS server for efficient =
barge-in=20
  support. This is a MAY BE. I don't want to turn this into a discussion =
of if=20
  this the right or wrong approach.
        =
  Now=20
  all of the above requirements, would basically mean that session =
message=20
  additions directly to SPEECHSC would get us a session protocol very =
close to=20
  SIP. So why reinvent the wheel. 
          =
More=20
  over the conference control which controls yet another media resource =
for=20
  conferencing seems to be going along these lines. 

  =
   =20
     Though I very much considered RTSP as well, I felt SIP =
would be a=20
  much better fit and would be a much more welcome choice with the rest =
of=20
  IETF.

Sarvi

Brian Wyld wrote:

  
Hi David,

I'll brutally resume your arguements as:
"SIP should be supplied natively by all OS's on which you might run
speechsc, and hence is not a burden for a speechsc implementation"

Whilest some might dispute this, I don't think this is a true statement
today; and tomorrow is another country as one might (mis)quote..... =
Making
this assumption and basing the operation and acceptance of speechsc on =
it
seems unneccessary to me.  Integrating a SIP stack is not a simple =
activity
(and generally more expensive if its free!).

Sorry, but I still think that it's easier to specify the media setup
specifically (maybe by cut-n-paste from RTSP) rather than suck in the =
entire
SIP protocol.

Maybe we should instead specify the use of RTSP as the media setup =
agent, as
most folks with MRCP experience will have such an implementation already =
and
it is known to serve the needs of mrcp......

A+

Brian

PS> I note that to achieve an operation MRCP server today, it is =
neccessary
to implement very little of RTSP and none of the media state machinary =
(no
play, record etc). In fact, only SETUP and TEARDOWN are really required, =
and
the 'tunnel message' ANNOUNCE......

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

  

    
-----Message d'origine-----
De : David R. Oran [mailto:oran@cisco.com]
Envoye : Tuesday, June 10, 2003 13:44
A : brian.wyld@eloquant.com; =
Neil Deason; 'Sarvi Shanmugham';
speechsc@ietf.org
Objet : RE: [Speechsc] Protpcol proposal for SPEECHSC


--On Tuesday, June 10, 2003 9:42 AM +0200 Brian Wyld
<brian.wyld@eloquant.com> wrote:

    

      
Hi,

I quite like the idea of separating the media setup and
      
speechsc operation
    

      
completely as Sarvi has =
proposed. However, I think this
      
together with SIP
    

      
is going to give us big =
headaches when it comes to real implementations
and interoperability...

1/ SIP-in-speechsc : SIP is a protocol that has lot of stuff
      
that speechsc
    

      
does not need - does a =
speechsc client or server have to supply
      
a full SIP
    

      
complient stack, or just =
the bits that seem to be needed by speechsc? Do
we define a "speechsc profile" to avoid such a problem?

      
I suspect that once we deviate =
from 3261 compliance, we are
buying tons of
potential problems with interoperability and complex
specification. While I
have seen the profile approach taken in a number of fora, in the IETF =
tis
is generally considered to be inimical to the goal of interoperability
which is very high on the IETF's list of criteria for protocol
specification.

    

      
2/ SIP-commercial : SIP =
stacks might be generally available, but is it
really a requirement that a producer of a speechsc
      
client/server must both
    

      
create a speechsc stack =
and acquire a full SIP stack as well?
      
If we decide to go this path, =
then yes. However, 3261-compliant
SIP stacks
are quite easy to obtain and there are multiple open source versions
(vovida.org, iptel.org). As one of the "SIP bigots", my defense here is
that us crazy's really expect SIP to be ubiquitous - of the same
universal
deployment as DTTP, FTP, Telnet, SMTPm so depending on a SIP stack is a
perfectly natural and reasonable thing to do, especially if it =
simplifies
the rest of the problem space, which in this case it seems to do quite
nicely.

    

      
Although as
Neil says the environment around speechsc is likely to include SIP, a)
this cannot be enforced
      
well...we can enforce it if we =
so choose. It is unlikely that a service
enviroment which employs SPEECHSC would lack FTP, or HTTP, or DNS. This
proposal adds SIP to the list of things needed.

Also, it seems that the argument that SIP is an extra burden probably
applies to the server side, but not really to the client side. Nearly =
all
the envinroments we cite for SPEECHSC are ones in which speech
services are
being provided within the context of preparing for a session
establishment
of some sort, or during such sessions. I would have to construct some
artificial examples to justify a SPEECHSC client which did not
also employ
SIP.

For servers, your argument carries more weight, since a SPEECHSC
server may
be just a dedicated back-end box which does not itself initiate or
terminate other sessions. In analyzing the tradeoff, I still come down =
on
the SIP side of the equation because SPEECHSC servers are likely to be
general-purpose computers, running general-purpose OSs, with a rich
programming environment in which embedding SIP should be
somewhere between
easy and trivial.


    

      
and b) the SIP stack =
elements may be present in
the environment, but not neccessarily in the speechsc elements. In
particular, the speechsc server is unlikely to have a SIP stack in most
cases (IMHO bien sur - none of my MRCP servers have a SIP stack....)

      
True, but they wound up with =
nearly all of an RTSP stack, no?

    

      
3/ not-SIP : as Neil =
says, one could substitute ANOProtocol for
      
SIP and it
    

      
should work - however, as =
there is no mechanism to inform the client or
server of such a substitution this will ensure non-interoperability
between vendors..... (a Bad Thing)

This said, if we can avoid SIP causing either 'bloat' or an
interoperability nightmare, maybe by creating a 'speechsc profile' then
I'm not against it generally....

      
I suspect something which =
mandates less than 3261 compliance will
not have
an easy time getting through the IESG. On the other hand, I would have =
no
objection to the spec including guidance of the sort "note that a
speechsc
server has no need to ever initiate a SIP session and hence will be
responding to INVITES but not generating them".

    

      
Brian

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

      

        
-----Message =
d'origine-----
De : Neil Deason [mailto:ndeason@ubiquity.net]
Envoye : Friday, June 06, 2003 21:02
A : brian.wyld@eloquant.com; =
'Sarvi Shanmugham'; speechsc@ietf.org
Objet : RE: [Speechsc] Protpcol proposal for SPEECHSC


Hi.

There are benefits to using SIP with speechsc because the architectural
model for speechsc is complementary to the disaggregated application
component model which SIP promotes. Plus it avoids re-inventing the
wheel for initiation, modification and termination of speechsc
        
sessions.
    

      

        
Speechsc and SIP are =
synergistic and often likely to be deployed within
a common environment. Therefore having this form of defined working
relationship is a good thing.

I don't see anything new needed in SIP for speechsc sessions.
        
It is pure
    

      

        
reuse. RFC 3261 and RFC =
3264 say what is and isn't allowed for SIP and
the offer/answer model for SDP. The only additions required
        
would be for
    

      

        
SDP. The IETF promotes =
a modular multi-protocol approach, so I
        
am afraid
    

      

        
the question of whether =
it means another stack is somewhat irrelevant.
The real question that needs to be asked is does SIP perform the job
required and the answer appears to be yes.

Now, all that said, I don't think you should have to use SIP to use
speechsc anymore than you have to use SIP to use RTP. If you want to
assume a model where a priori knowledge from some other
        
mechanism allows
    

      

        
a client and server to =
use speechsc between them that should be
supported. The draft could be made more explicit about that and keeping
the layers suitably delineated should be a design goal.

Cheers,
Neil.

        

          
-----Original =
Message-----
From: speechsc-admin@ietf.org
[mailto:speechsc-admin@ietf.org] On Behalf Of Brian Wyld
Sent: 03 June 2003 06:05
To: Sarvi Shanmugham; speechsc@ietf.org
Subject: RE: [Speechsc] Protpcol proposal for SPEECHSC


Hi Sarvi,

My initial feedback (before having read the doc in detail) is
that I was somewhat surprised to see the use of SIP messages
for the media setup. This did not corrospond to what I had
thought was the trend of the discussion here, to bypass
resuse of such a media protocol and create directly a new
speechsc protocol for this also. (which would probably use
SDP however).

The major issue I see with your use of SIP
INVITE/BYE/REINVITE etc is that adds a lot of _potential_
complexity (it pulls in an entire SIP stack), for very little
gain in real functionality. I really don't see the use in
having all the potential SIP stuff and then having to define
exactly what is and isn't allowed.....

I'd go for a simpler model where we just define new speechsc
messages to setup/control the media that are specific to
          
speechsc.....
    

      

        

          
Brian

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

          

            
-----Message =
d'origine-----
De : speechsc-admin@ietf.org [mailto:speechsc-admin@ietf.org]De la
part de Sarvi Shanmugham Envoye : Wednesday, May 21, 2003 23:30
A : speechsc@ietf.org
Objet : [Speechsc] Protpcol proposal for SPEECHSC




Hi
     Please find attached a proposal for a SPEECHSC protocol. This
leverages the MRCP specification. But removes the
            
tunnelling aspects
          

            
of the protocol. I =
have also submitted this document to the
            
internet
          

            
drafts repository =
and should be available from there soon.

The current version does not address SI and SV aspects of the
requirements document. But addresses most of the others.
            
This document
          

            
is meant to be a =
starting point for a possible direction that the
SPEECHSC protocol could take. Based on interest and
            
comments received,
          

            
we can proceed to =
add SI and SV capabilities in a following
            
version of
          

            
the draft.

Any thoughts.

Sarvi

            
_______________________________________________
Speechsc mailing list
Speechsc@ietf.org https://www1.iet=
f.org/mailman/listinfo/speechsc

          
        =

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc
      
------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: oran@cisco.com

    


  



------_=_NextPart_001_01C32FB8.7E398478--
_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Wed Jun 11 09:54:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09041
	for ; Wed, 11 Jun 2003 09:54:34 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5BDs9209370
	for speechsc-archive@odin.ietf.org; Wed, 11 Jun 2003 09:54:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BDs9B09367
	for ; Wed, 11 Jun 2003 09:54:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09027
	for ; Wed, 11 Jun 2003 09:54:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q61A-0000Uw-00
	for speechsc-web-archive@ietf.org; Wed, 11 Jun 2003 09:52:00 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q619-0000Us-00
	for speechsc-web-archive@ietf.org; Wed, 11 Jun 2003 09:51:59 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BDs4B09350;
	Wed, 11 Jun 2003 09:54:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BDrNB09315
	for ; Wed, 11 Jun 2003 09:53:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09009;
	Wed, 11 Jun 2003 09:53:18 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Q60Q-0000Uc-00; Wed, 11 Jun 2003 09:51:14 -0400
Received: from [63.163.229.65] (helo=gateus.nmss.com)
	by ietf-mx with smtp (Exim 4.12)
	id 19Q60P-0000UX-00; Wed, 11 Jun 2003 09:51:14 -0400
Received: from NAMASMTP02 by gateus.nmss.com
          via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 11 Jun 2003 08:48:23 UT
Subject: Re: [Speechsc] Protpcol proposal for SPEECHSC
To: Sarvi Shanmugham 
Cc: speechsc@ietf.org, speechsc-admin@ietf.org
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: 
From: "John Potemri" 
Date: Wed, 11 Jun 2003 09:51:28 -0400
X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.11  |July
 24, 2002) at 06/11/2003 09:49:07 AM
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5BDrNB09317
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h5BDs4B09350
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5BDs9B09367
Content-Transfer-Encoding: 8bit


I have a few comments for your draft that will help someone not involved in
the day-to-day discussions to be able to read it and understand it better.

1. Defining Client and Server
I would suggest defining it up front and sticking with the same terms
throughout the document.

- Introduction, first paragraph introduces "client device" and "media
processing resources on the network". The latter is initially defined as
ASR, TTS, SV, and SI engines.
- Introduction, third paragraph references "to the media server".  I would
have expected "between the client and the media resources".
- Later, 3.1, you say connecting "to the media server", and that section
talks about the client finding a SPEECHSC server, and then finishes with
"and the media server" again.

I'll leave you to give some thought to it, but you might consider defining:
      CLIENT: any device or server that may leverage the media processing
resources provided by a SPEECH server.
      SPEECHSC server: a server providing one or more media processing
resources, including, but not limited to ASR, TTS, SI, and SV.
...and then only using these terms throughout.


2. Clarifying SIP Session Relationship

In the Architecture section, fourth paragraph says "MUST BE" and makes any
reader wonder why. There's no explanation. Perhaps it's the "SIP session"
that is governing this thought. Maybe it's a use case, but I assume that an
application session will have one or more "SIP sessions" with "media
processing resources". Are you implying that multiple resources controlled
under the same SIP session (obviously to the same physical resource) MUST
share a media pipe?  Later, multiple pipes and media streams are described
(3.1 and 3.3 paragraph 2)


3. Speaker Identification
2.1, third paragraph, rename to "Speaker Identification" to match SI
denotion and later reference.


4. Clarify "it"
3.1 says "It is also used to establish...". Is this meant to be the
SPEECHSC protocol, SIP or the SDP offer/exchange model?  I read it as the
latter.
Also it says "pipes" and I thought earlier it was said that that resources
must share a media pipe; should this not be plural?


Regards,
John


John Potemri
Director of Technology, Advanced Platform Group
NMS Communications
100 Crossing Blvd
Framingham, MA  01702
+1-508-271-1369
john_potemri@nmss.com



_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Fri Jun 13 12:58:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12461
	for ; Fri, 13 Jun 2003 12:58:39 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5DGwCn02402
	for speechsc-archive@odin.ietf.org; Fri, 13 Jun 2003 12:58:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DGwCm02399
	for ; Fri, 13 Jun 2003 12:58:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12255
	for ; Fri, 13 Jun 2003 12:58:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QrqL-0006kv-00
	for speechsc-web-archive@ietf.org; Fri, 13 Jun 2003 12:56:01 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QrqL-0006kr-00
	for speechsc-web-archive@ietf.org; Fri, 13 Jun 2003 12:56:01 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DCd1a06135;
	Fri, 13 Jun 2003 08:39:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DCc9m06101
	for ; Fri, 13 Jun 2003 08:38:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00434
	for ; Fri, 13 Jun 2003 08:38:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qnmh-00046v-00
	for speechsc@ietf.org; Fri, 13 Jun 2003 08:35:59 -0400
Received: from [217.158.120.227] (helo=rnidmail.rnid.org.uk)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qnmg-00046l-00
	for speechsc@ietf.org; Fri, 13 Jun 2003 08:35:58 -0400
Received: from rnid.org.uk (unverified) by rnidmail.rnid.org.uk
 (Content Technologies SMTPRS 4.2.5) with SMTP id  for ;
 Fri, 13 Jun 2003 13:35:53 +0100
Received: from RNIDMAIL-Message_Server by rnid.org.uk
	with Novell_GroupWise; Fri, 13 Jun 2003 13:35:22 +0100
Message-Id: 
X-Mailer: Novell GroupWise 5.5.2
Date: Fri, 13 Jun 2003 13:34:38 +0100
From: "Guido Gybels" 
To: 
Cc: "James Hamlin" ,
        "Mike Spanner" , 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5DCc9m06102
Subject: [Speechsc] Re: I-D ACTION:draft-ietf-speechsc-reqts-04.txt
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

All,

<>

<>

Based on the previous discussions, can I suggest we replace 3.9 with the following:

"3.9 Users with disabilities

The SPEECHSC framework must have sufficient capabilities to address the critical needs of people with disabilities. In particular, the set of requirements set forth in RFC3351 [4] MUST be taken into account by the framework. It is also important that implementers of SPEECHSC clients and servers be cognizant that some interaction modalities of SPEECHSC may be inconvenient, or simply inappropriate for disabled users. Hearing-impaired individuals may find TTS of limited utility. Speech-impaired users may be unable to make use of ASR or SI/SV capabilities. Therefore, systems employing SPEECHSC MUST provide alternative interaction modes or avoid the use of speech processing entirely."

And some spelling issues:

Page 3, justbefore 2.1: replace "decompostion" with "decomposition"
Page 14, 9.3, replace "vulnerabilties" with "vulnerabilities" 

Best regards,

Guido



Guido Gybels
Director of New Technologies

RNID, 19-23 Featherstone Street
London EC1Y 8SL, UK
Tel +44(0)20-7294 3713
Fax +44(0)20-7296 8069




************************************************************************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. Any views or opinions expressed
are solely those of the author and do not necessarily represent
RNID policy.

If you are not the intended recipient you are advised that any
use, dissemination, forwarding, printing or copying of this
email is strictly prohibited.

If you have received this email in error please notify the RNID
Helpdesk by telephone on: +44 (0) 207 296 8282.

The Royal National Institute for Deaf People  
Registered Office 19-23 Featherstone Street 
London EC1Y 8SL No. 454169 (England)
Registered Charity No. 207720
************************************************************************

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Fri Jun 13 14:37:16 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17407
	for ; Fri, 13 Jun 2003 14:37:16 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5DIamD02253
	for speechsc-archive@odin.ietf.org; Fri, 13 Jun 2003 14:36:48 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIalm01780
	for ; Fri, 13 Jun 2003 14:36:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17306
	for ; Fri, 13 Jun 2003 14:36:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19QtNk-0000Fg-00
	for speechsc-web-archive@ietf.org; Fri, 13 Jun 2003 14:34:36 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19QtNj-0000Fd-00
	for speechsc-web-archive@ietf.org; Fri, 13 Jun 2003 14:34:35 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHq1a03330;
	Fri, 13 Jun 2003 13:52:01 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHpGm02906
	for ; Fri, 13 Jun 2003 13:51:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15560
	for ; Fri, 13 Jun 2003 13:51:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qsfh-0007eC-00
	for speechsc@ietf.org; Fri, 13 Jun 2003 13:49:05 -0400
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qsfg-0007di-00
	for speechsc@ietf.org; Fri, 13 Jun 2003 13:49:04 -0400
Received: from [10.32.254.189] (stealth-10-32-254-189.cisco.com [10.32.254.189])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with SMTP id h5DHocwc027819;
	Fri, 13 Jun 2003 10:50:39 -0700 (PDT)
Date: Fri, 13 Jun 2003 13:50:31 -0400
From: "David R. Oran" 
To: Guido Gybels , speechsc@ietf.org
cc: James Hamlin ,
        Mike Spanner , A.vWijk@viataal.nl
Subject: Re: [Speechsc] Re: I-D ACTION:draft-ietf-speechsc-reqts-04.txt
Message-ID: <184772765.1055512231@[10.32.254.189]>
In-Reply-To: 
References:  
X-Mailer: Mulberry/3.0.3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I've asked the AD's if they'd rather this be handled as part of RFC editor 
processing, or if they want a new draft posted with these changes.

Stay tuned...

--On Friday, June 13, 2003 1:34 PM +0100 Guido Gybels 
 wrote:

> All,
>
> < directories. This draft is a work item of the Speech Services Control
> Working Group of the IETF.>>
>
> <>
>
> Based on the previous discussions, can I suggest we replace 3.9 with the
> following:
>
> "3.9 Users with disabilities
>
> The SPEECHSC framework must have sufficient capabilities to address the
> critical needs of people with disabilities. In particular, the set of
> requirements set forth in RFC3351 [4] MUST be taken into account by the
> framework. It is also important that implementers of SPEECHSC clients and
> servers be cognizant that some interaction modalities of SPEECHSC may be
> inconvenient, or simply inappropriate for disabled users.
> Hearing-impaired individuals may find TTS of limited utility.
> Speech-impaired users may be unable to make use of ASR or SI/SV
> capabilities. Therefore, systems employing SPEECHSC MUST provide
> alternative interaction modes or avoid the use of speech processing
> entirely."
>
> And some spelling issues:
>
> Page 3, justbefore 2.1: replace "decompostion" with "decomposition"
> Page 14, 9.3, replace "vulnerabilties" with "vulnerabilities"
>
> Best regards,
>
> Guido
>
>
>
> Guido Gybels
> Director of New Technologies
>
> RNID, 19-23 Featherstone Street
> London EC1Y 8SL, UK
> Tel +44(0)20-7294 3713
> Fax +44(0)20-7296 8069
>
>
>
>
> ************************************************************************
> This email and any files transmitted with it are confidential
> and intended solely for the use of the individual or entity to
> whom they are addressed. Any views or opinions expressed
> are solely those of the author and do not necessarily represent
> RNID policy.
>
> If you are not the intended recipient you are advised that any
> use, dissemination, forwarding, printing or copying of this
> email is strictly prohibited.
>
> If you have received this email in error please notify the RNID
> Helpdesk by telephone on: +44 (0) 207 296 8282.
>
> The Royal National Institute for Deaf People
> Registered Office 19-23 Featherstone Street
> London EC1Y 8SL No. 454169 (England)
> Registered Charity No. 207720
> ************************************************************************
>
> _______________________________________________
> Speechsc mailing list
> Speechsc@ietf.org
> https://www1.ietf.org/mailman/listinfo/speechsc



------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: oran@cisco.com
_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From mailnull@www1.ietf.org  Fri Jun 13 23:45:36 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04579
	for ; Fri, 13 Jun 2003 23:45:36 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5E3j2218030
	for speechsc-archive@odin.ietf.org; Fri, 13 Jun 2003 23:45:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E3imm18018
	for ; Fri, 13 Jun 2003 23:44:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04523
	for ; Fri, 13 Jun 2003 23:44:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19R1w1-0003qH-00
	for speechsc-web-archive@ietf.org; Fri, 13 Jun 2003 23:42:33 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19R1w0-0003q9-00
	for speechsc-web-archive@ietf.org; Fri, 13 Jun 2003 23:42:32 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DJE0a31696;
	Fri, 13 Jun 2003 15:14:00 -0400
Received: from ietf.org (lists.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DJDmm31644
	for ; Fri, 13 Jun 2003 15:13:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20024
	for ; Fri, 13 Jun 2003 15:13:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Qtxa-0000bq-00
	for speechsc@ietf.org; Fri, 13 Jun 2003 15:11:38 -0400
Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com)
	by ietf-mx with smtp (Exim 4.12)
	id 19QtxZ-0000bj-00
	for speechsc@ietf.org; Fri, 13 Jun 2003 15:11:37 -0400
Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap 
	 id 22326; Fri, 13 Jun 2003 15:14:36 -0400 (EDT)
content-class: urn:content-classes:message
Subject: RE: [Speechsc] SPEECHSC Protocol: Resource Type Identification
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 13 Jun 2003 15:13:04 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <4A3384433CE2AB46A63468CB207E209D59E39D@zoe.office.snowshore.com>
Thread-Topic: [Speechsc] SPEECHSC Protocol: Resource Type Identification
Thread-Index: AcMsXp67BlA+EDmgQR6m6tL7akrocQFgSCaQ
From: "Eric Burger" 
To: "Neil Deason" , "Sarvi Shanmugham" 
Cc: "IETF SPEECHSC (E-mail)" 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5DJDmm31645
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

You mean, "say what you mean"? :-)

Any reason *not* to go with Neil's proposal?

> -----Original Message-----
> From: Neil Deason [mailto:ndeason@ubiquity.net]
> Sent: Fri, June 06, 2003 3:05 PM
> To: 'Sarvi Shanmugham'; Eric Burger
> Cc: 'IETF SPEECHSC (E-mail)'
> Subject: RE: [Speechsc] SPEECHSC Protocol: Resource Type 
> Identification
> 
> 
> It is even easier to parse if you use the separate SDP attributes
> approach. In terms of bytes required this needs to be seen in the
> context of the wider SIP message + SDP being used. The number of bytes
> being saved in the alternatives will be about as effective at
> 'compression' as the compact header name forms in SIP. 
> Therefore I would
> go for readability and easier debugging, something like the following
> ABNF grammar (incorporating Proposal I):
> 
>   resource-attribute = "resource" : resource-id
>   resource-id = 1*(alpha-numeric) ; typically ASR, TTS, SI, SV  
> 
>   channel-attribute = "channel" : channel-id
>   channel-id = 1*(DIGIT) ; must be unique for originating client
> 
> An example speechsc SDP media level description:
> 
>   m=control 32416 TCP application/speechsc
>   a=resource:ASR
>   a=channel:583769103560
> 
> Cheers,
> Neil.
> 
> > -----Original Message-----
> > From: speechsc-admin@ietf.org 
> > [mailto:speechsc-admin@ietf.org] On Behalf Of Sarvi Shanmugham
> > Sent: 06 June 2003 09:38
> > To: Eric Burger
> > Cc: IETF SPEECHSC (E-mail)
> > Subject: Re: [Speechsc] SPEECHSC Protocol: Resource Type 
> > Identification
> > 
> > 
> > Makes sense. Both proposal 1 and 2 are fine with me.
> > If we plan on using Proposal I(or II), since it is a 
> variable length 
> > text string at the end, it might be useful to structure the 
> > identifier 
> > to allow easy parsing of the 2 pieces(specially since the 
> > main part is 
> > hexadecimal). Something like
> >            Channel -Identifer: 2354AB123D243@ASR
> > OR
> >            Require the main part of the Channel-identifer to be 
> > specified in decimal, in whcih case the separation is clear.
> >            Channel -Identifer: 2352343243242324ASR
> > 
> > Sarvi
> > 
> > Eric Burger wrote:
> > 
> > >[cf. Section 3.2 of 
> > 
>http://www.ietf.org/internet-drafts/draft-shanmugham-speechsc-00.txt]
> >
> >I don't like the idea of addressing resources by using magic 
> numbers at 
> >the end of a string.  Is there any reason not to use mnemonic 
> >identifiers?
> >
> >How about this for a proposal:
> >
> > Old Resource ID   Proposal I   Proposal II   Meaning
> >       00                                    Reserved
> >       01             ASR           SR       Speech Recognition
> >       02             TTS           SS       Speech Synthesis
> >       03             SI            SI       Speaker Identification
> >       04             SV            SV       Speaker Verification
> >
> >Proposal II uses the same number of bytes as the document proposes.  
> >However, it is somewhat more readable.  Proposal I uses 1 more byte 
> >(adding 0.5% overhead :-) and is yet more readable.
> >
> >Thoughts?
> >
> >_______________________________________________
> >Speechsc mailing list
> >Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc
> >
> >  
> >
> 
> 
> _______________________________________________
> Speechsc mailing list
> Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc
> 



_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From exim@www1.ietf.org  Thu Jun 19 05:46:19 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06339
	for ; Thu, 19 Jun 2003 05:46:19 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5J9jr522260
	for speechsc-archive@odin.ietf.org; Thu, 19 Jun 2003 05:45:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SvsR-0005PN-GW
	for speechsc-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 05:38:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06154
	for ; Thu, 19 Jun 2003 05:38:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Svq9-00019Y-00
	for speechsc-web-archive@ietf.org; Thu, 19 Jun 2003 05:36:21 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Svq8-00019U-00
	for speechsc-web-archive@ietf.org; Thu, 19 Jun 2003 05:36:20 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SvdF-0004dF-DF; Thu, 19 Jun 2003 05:23:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19SvJ7-0003XD-1Y
	for speechsc@optimus.ietf.org; Thu, 19 Jun 2003 05:02:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05690
	for ; Thu, 19 Jun 2003 05:02:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19SvGp-00011a-00
	for speechsc@ietf.org; Thu, 19 Jun 2003 04:59:51 -0400
Received: from smtp-104-thursday.noc.nerim.net ([62.4.17.104] helo=mallaury.noc.nerim.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 19SvGn-00011W-00
	for speechsc@ietf.org; Thu, 19 Jun 2003 04:59:50 -0400
Received: from weasel.hq.eloquant.com (styx.eloquant.com [80.65.227.37])
	by mallaury.noc.nerim.net (Postfix) with ESMTP
	id 5DADC62DE4; Thu, 19 Jun 2003 11:02:08 +0200 (CEST)
Received: from polo (polo.hq.eloquant.com [192.168.0.131])
	by weasel.hq.eloquant.com (Postfix) with SMTP
	id E8D2C3B6CA; Thu, 19 Jun 2003 05:10:12 -0400 (EDT)
Reply-To: 
From: "Brian Wyld" 
To: "Sarvi Shanmugham" 
Cc: "Eric Burger" , 
Subject: RE: [Speechsc] Protocol proposal for SPEECHSC
Date: Thu, 19 Jun 2003 10:57:48 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0150_01C33651.9F447320"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <3EE657C0.4010107@cisco.com>
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	

This is a multi-part message in MIME format.

------=_NextPart_000_0150_01C33651.9F447320
Content-Type: text/plain;
	charset="iso-8859-1"
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA05691
Content-Transfer-Encoding: quoted-printable

Hi Sarvi,

No, I think the MRCP section is ok.

Eric, I have no other updates yet for the protocol comparison document....

Please note I am on holiday (real holiday, no computers) 28th June until
15th July so won't be able to do any updates after 28th June.

And finally, I'm afraid I won't be at IETF Vienna (budget, time
constraints). I hope you manage to get enough folk to make progress on
Sarvi's proposal....

Brian



  -----Message d'origine-----
  De : Sarvi Shanmugham [mailto:sarvi@cisco.com]
  Envoy=E9 : Wednesday, June 11, 2003 00:12
  =C0 : brian.wyld@eloquant.com
  Cc : Eric Burger; speechsc@ietf.org
  Objet : Re: [Speechsc] Protocol proposal for SPEECHSC


  Hi Brian,
              Does my section need updation(MRCP evalutation), if so let =
me
know and I will get back o you with the edits by the end of next week.

  Sarvi

  Brian Wyld wrote:

Ok, if I have time I will munge something thru a web services toolset and
produce an alternative proposal based on WS.....

Then again, maybe not.

To be frank, if you all want SIP, and I don't see many other viewpoints
here, then I'll go with your experience. As long as we can model all the
different session viewpoints (as already discussed here) that are needed =
for
usage of the resources then that's fine with me. (pointers to a good open
source java SIP stack gratefully received....)

So, is anyone going to update their sections for the protocol comparison
document before the 30th June or not?

Brian (another hapless victem crushed by the SIP juggernaught)

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

  -----Message d'origine-----
De : Eric Burger [mailto:eburger@snowshore.com]
Envoy=E9 : Tuesday, June 10, 2003 21:30
=C0 : brian.wyld@eloquant.com; speechsc@ietf.org
Objet : RE: [Speechsc] Protocol proposal for SPEECHSC


    -----Original Message----- From: Brian Wyld
      [mailto:brian.wyld@eloquant.com]
    Sent: Tue, June 10, 2003 12:16 PM
      [snip]

    Sorry, but I still think that it's easier to specify the media setup
specifically (maybe by cut-n-paste from RTSP) rather than
suck in the entire
SIP protocol.
      I would be very hesitant to create yet another "looks like
SIP/RTSP, smells like SIP/RTSP, operates like SIP/RTSP, but has a
different life and future than SIP/RTSP."

I'd much rather leverage the 974 engineer years of work over the
last 6 years put in to SIP than spend 3 engineer years explaining
what is the same and different in a new protocol.  Moreover, I
would not want to find myself wishing I had 500 engineer years of
resources to catch up when something useful gets introduced into
SIP/RTSP that I might want.

SIP is actually pretty good when dealing with small, embedded
implementations.  Most everything is an extension
("Accept/Allow").  You don't even need the list of extensions to
say, "I don't know what you are talking about."  Thus an
SPEECHSC-only implementation can be pretty light.  It is what we
do in the media server world, for example.

    Maybe we should instead specify the use of RTSP as the media
setup agent, as
most folks with MRCP experience will have such an
implementation already and
it is known to serve the needs of mrcp......
      I can go either way.  At this point one could submit a RTSP-based
SPEECHSC protocol proposal, similar to Sarvi's.  Alternately, one
could submit a "these are the reasons RTSP
works/interoperates/easier-to-implement than SIP" draft.

Do be aware that you have until 0900 USA-ET to submit a -00 draft.

    A+

Brian

PS> I note that to achieve an operation MRCP server today, it
is neccessary
to implement very little of RTSP and none of the media state
machinary (no
play, record etc). In fact, only SETUP and TEARDOWN are
really required, and
the 'tunnel message' ANNOUNCE......
      My point above, exactly...



_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



------=_NextPart_000_0150_01C33651.9F447320
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Hi=20
Sarvi,


 


No, I=20
think the MRCP section is ok.


 


Eric,=20
I have no other updates yet for the protocol comparison=20
document....


 


Please=20
note I am on holiday (real holiday, no computers) 28th June until =
15th July=20
so won't be able to do any updates after 28th=20
June.


 


And=20
finally, I'm afraid I won't be at IETF Vienna (budget, time =
constraints). I hope=20
you manage to get enough folk to make progress on Sarvi's=20
proposal....


 


Brian


 


 


  
-----Message d'origine-----
De : Sarvi =
Shanmugham=20
  [mailto:sarvi@cisco.com]
Envoy=E9 : Wednesday, June 11, =
2003=20
  00:12
=C0 : brian.wyld@eloquant.com
Cc : =
Eric=20
  Burger; speechsc@ietf.org
Objet : Re: [Speechsc] =
Protocol=20
  proposal for SPEECHSC

Hi Brian,
    =
 =20
        Does my section need updation(MRCP evalutation), =
if so=20
  let me know and I will get back o you with the edits by the end of =
next=20
  week.

Sarvi

Brian Wyld wrote:

  
Ok, if I have time I will munge something =
thru a web services toolset and
produce an alternative proposal based on WS.....

Then again, maybe not.

To be frank, if you all want SIP, and I don't see many other viewpoints
here, then I'll go with your experience. As long as we can model all the
different session viewpoints (as already discussed here) that are needed =
for
usage of the resources then that's fine with me. (pointers to a good =
open
source java SIP stack gratefully received....)

So, is anyone going to update their sections for the protocol comparison
document before the 30th June or not?

Brian (another hapless victem crushed by the SIP juggernaught)

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

  

    
-----Message d'origine-----
De : Eric Burger [mailto:eburger@snowshore.com]
Envoy=E9 : Tuesday, June 10, 2003 21:30
=C0 : brian.wyld@eloquant.com; speechsc@ietf.org
Objet : RE: [Speechsc] Protocol proposal for SPEECHSC


    

      
-----Original =
Message----- From: Brian Wyld
      
[mailto:brian.wyld@eloquant.com]
    

      
Sent: Tue, June 10, 2003 =
12:16 PM
      
[snip]

    

      
Sorry, but I still think =
that it's easier to specify the media setup
specifically (maybe by cut-n-paste from RTSP) rather than
suck in the entire
SIP protocol.
      
I would be very hesitant to =
create yet another "looks like
SIP/RTSP, smells like SIP/RTSP, operates like SIP/RTSP, but has a
different life and future than SIP/RTSP."

I'd much rather leverage the 974 engineer years of work over the
last 6 years put in to SIP than spend 3 engineer years explaining
what is the same and different in a new protocol.  Moreover, I
would not want to find myself wishing I had 500 engineer years of
resources to catch up when something useful gets introduced into
SIP/RTSP that I might want.

SIP is actually pretty good when dealing with small, embedded
implementations.  Most everything is an extension
("Accept/Allow").  You don't even need the list of extensions to
say, "I don't know what you are talking about."  Thus an
SPEECHSC-only implementation can be pretty light.  It is what we
do in the media server world, for example.

    

      
Maybe we should instead =
specify the use of RTSP as the media
setup agent, as
most folks with MRCP experience will have such an
implementation already and
it is known to serve the needs of mrcp......
      
I can go either way.  At this =
point one could submit a RTSP-based
SPEECHSC protocol proposal, similar to Sarvi's.  Alternately, one
could submit a "these are the reasons RTSP
works/interoperates/easier-to-implement than SIP" draft.

Do be aware that you have until 0900 USA-ET to submit a -00 draft.

    

      
A+

Brian

PS> I note that to achieve an operation MRCP server today, it
is neccessary
to implement very little of RTSP and none of the media state
machinary (no
play, record etc). In fact, only SETUP and TEARDOWN are
really required, and
the 'tunnel message' ANNOUNCE......
      
My point above, exactly...


    

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc

  



------=_NextPart_000_0150_01C33651.9F447320--


_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From exim@www1.ietf.org  Thu Jun 19 16:19:30 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16412
	for ; Thu, 19 Jun 2003 16:19:30 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5JKJ2L20837
	for speechsc-archive@odin.ietf.org; Thu, 19 Jun 2003 16:19:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19T5s6-0005Q0-NJ
	for speechsc-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 16:19:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16402
	for ; Thu, 19 Jun 2003 16:19:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19T5po-0002rI-00
	for speechsc-web-archive@ietf.org; Thu, 19 Jun 2003 16:16:40 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19T5pn-0002rF-00
	for speechsc-web-archive@ietf.org; Thu, 19 Jun 2003 16:16:39 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19T5s4-0005PT-T4; Thu, 19 Jun 2003 16:19:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19T5rK-0005Oe-Ua
	for speechsc@optimus.ietf.org; Thu, 19 Jun 2003 16:18:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16379;
	Thu, 19 Jun 2003 16:18:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19T5p2-0002qk-00; Thu, 19 Jun 2003 16:15:52 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19T5p1-0002qG-00; Thu, 19 Jun 2003 16:15:51 -0400
Received: from cisco.com (171.68.223.138)
  by sj-iport-2.cisco.com with ESMTP; 19 Jun 2003 13:15:43 -0800
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h5JKHe9b020864;
	Thu, 19 Jun 2003 13:17:40 -0700 (PDT)
Received: from cisco.com (dhcp-128-107-139-4.cisco.com [128.107.139.4])
	by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AIP09352;
	Thu, 19 Jun 2003 13:17:39 -0700 (PDT)
Message-ID: <3EF21A63.1040208@cisco.com>
Date: Thu, 19 Jun 2003 13:17:39 -0700
From: Sarvi Shanmugham 
Organization: Cisco Systems Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John Potemri 
CC: speechsc@ietf.org, speechsc-admin@ietf.org
Subject: Re: [Speechsc] Protpcol proposal for SPEECHSC
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

responses inline.

John Potemri wrote:

>I have a few comments for your draft that will help someone not involved in
>the day-to-day discussions to be able to read it and understand it better.
>
>1. Defining Client and Server
>I would suggest defining it up front and sticking with the same terms
>throughout the document.
>
>- Introduction, first paragraph introduces "client device" and "media
>processing resources on the network". The latter is initially defined as
>ASR, TTS, SV, and SI engines.
>- Introduction, third paragraph references "to the media server".  I would
>have expected "between the client and the media resources".
>- Later, 3.1, you say connecting "to the media server", and that section
>talks about the client finding a SPEECHSC server, and then finishes with
>"and the media server" again.
>
>I'll leave you to give some thought to it, but you might consider defining:
>      CLIENT: any device or server that may leverage the media processing
>resources provided by a SPEECH server.
>      SPEECHSC server: a server providing one or more media processing
>resources, including, but not limited to ASR, TTS, SI, and SV.
>...and then only using these terms throughout.
>
>  
>
Agreed.

>2. Clarifying SIP Session Relationship
>
>In the Architecture section, fourth paragraph says "MUST BE" and makes any
>reader wonder why. There's no explanation. Perhaps it's the "SIP session"
>that is governing this thought. Maybe it's a use case, but I assume that an
>application session will have one or more "SIP sessions" with "media
>processing resources". Are you implying that multiple resources controlled
>under the same SIP session (obviously to the same physical resource) MUST
>share a media pipe?  
>
Correct. A SIP session between the client and its m-lines under that SIP 
session are associated with a single application session at any one 
point.  So there is no reason to establish a separate media pipe for 
ASR, SI and SV which can all feed from the same media pipe.

>Later, multiple pipes and media streams are described
>(3.1 and 3.3 paragraph 2)
>
>
>3. Speaker Identification
>2.1, third paragraph, rename to "Speaker Identification" to match SI
>denotion and later reference.
>
>  
>
agreed.

>4. Clarify "it"
>3.1 says "It is also used to establish...". Is this meant to be the
>SPEECHSC protocol, SIP or the SDP offer/exchange model?  I read it as the
>latter.
>
It is the leter. Will update.

>Also it says "pipes" and I thought earlier it was said that that resources
>must share a media pipe; should this not be plural?
>
Correct. I am just refering to each direction as a pipe.

Sarvi

>
>
>Regards,
>John
>
>
>John Potemri
>Director of Technology, Advanced Platform Group
>NMS Communications
>100 Crossing Blvd
>Framingham, MA  01702
>+1-508-271-1369
>john_potemri@nmss.com
>
>
>
>_______________________________________________
>Speechsc mailing list
>Speechsc@ietf.org
>https://www1.ietf.org/mailman/listinfo/speechsc
>
>  
>


_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From exim@www1.ietf.org  Fri Jun 20 08:21:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02744
	for ; Fri, 20 Jun 2003 08:21:44 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5KCLGP02434
	for speechsc-archive@odin.ietf.org; Fri, 20 Jun 2003 08:21:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TKtH-0000dB-TV
	for speechsc-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 08:21:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02683
	for ; Fri, 20 Jun 2003 08:21:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TKqs-0003G7-00
	for speechsc-web-archive@ietf.org; Fri, 20 Jun 2003 08:18:46 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19TKqr-0003G3-00
	for speechsc-web-archive@ietf.org; Fri, 20 Jun 2003 08:18:45 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TKt3-0000cb-D2; Fri, 20 Jun 2003 08:21:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19TAd2-0000Cu-AG
	for speechsc@optimus.ietf.org; Thu, 19 Jun 2003 21:23:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28027
	for ; Thu, 19 Jun 2003 21:23:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TAai-0005Jm-00
	for speechsc@ietf.org; Thu, 19 Jun 2003 21:21:24 -0400
Received: from mamaya.genesyslab.com ([198.49.180.172])
	by ietf-mx with esmtp (Exim 4.12)
	id 19TAaf-0005JU-00
	for speechsc@ietf.org; Thu, 19 Jun 2003 21:21:21 -0400
Received: from aster.us.int.genesyslab.com ([10.10.10.25.36066])
	by mamaya.genesyslab.com with esmtp (Exim 3.36 #1)
	id 19TAc0-000B5a-00; Thu, 19 Jun 2003 18:22:44 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C336CA.725411EF"
Subject: RE: [Speechsc] Protocol proposal for SPEECHSC
Date: Thu, 19 Jun 2003 18:22:42 -0700
Message-ID: <52F49B5A0E5B0F4781C9C8F7159409E4839536@aster.us.int.genesyslab.com>
X-MS-Has-Attach: yes
Thread-Topic: [Speechsc] Protocol proposal for SPEECHSC
Thread-Index: AcM2RiFrbZd3C1tSRGWJA/PKMxZNfAAg0J1w
From: "Rajiv Dharmadhikari" 
To: , "Sarvi Shanmugham" 
Cc: "Eric Burger" , 
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	

This is a multi-part message in MIME format.

------_=_NextPart_001_01C336CA.725411EF
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C336CA.725411EF"


------_=_NextPart_002_01C336CA.725411EF
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Brian,
=20
Here is the updated protocol comparison document with my updates to the =
SIP section. Session control and resource control sections have been =
updated as per last conference call.
=20
Let me know if any changes are needed.
=20
-Rajiv

-----Original Message-----
From: Brian Wyld [mailto:brian.wyld@eloquant.com]
Sent: Thursday, June 19, 2003 1:58 AM
To: Sarvi Shanmugham
Cc: Eric Burger; speechsc@ietf.org
Subject: RE: [Speechsc] Protocol proposal for SPEECHSC


Hi Sarvi,
=20
No, I think the MRCP section is ok.
=20
Eric, I have no other updates yet for the protocol comparison =
document....
=20
Please note I am on holiday (real holiday, no computers) 28th June until =
15th July so won't be able to do any updates after 28th June.
=20
And finally, I'm afraid I won't be at IETF Vienna (budget, time =
constraints). I hope you manage to get enough folk to make progress on =
Sarvi's proposal....
=20
Brian
=20



-----Message d'origine-----
De : Sarvi Shanmugham [mailto:sarvi@cisco.com]
Envoy=E9 : Wednesday, June 11, 2003 00:12
=C0 : brian.wyld@eloquant.com
Cc : Eric Burger; speechsc@ietf.org
Objet : Re: [Speechsc] Protocol proposal for SPEECHSC


Hi Brian,
            Does my section need updation(MRCP evalutation), if so let =
me know and I will get back o you with the edits by the end of next =
week.

Sarvi

Brian Wyld wrote:


Ok, if I have time I will munge something thru a web services toolset =
and

produce an alternative proposal based on WS.....



Then again, maybe not.



To be frank, if you all want SIP, and I don't see many other viewpoints

here, then I'll go with your experience. As long as we can model all the

different session viewpoints (as already discussed here) that are needed =
for

usage of the resources then that's fine with me. (pointers to a good =
open

source java SIP stack gratefully received....)



So, is anyone going to update their sections for the protocol comparison

document before the 30th June or not?



Brian (another hapless victem crushed by the SIP juggernaught)



[Brian Wyld] [ brian.wyld@eloquant.com]

[Directeur General R&D]

[Eloquant SA] [+33 476 77 46 92] [ www.eloquant.com]

[advanced solutions for telecoms and IT services]



 =20

-----Message d'origine-----

De : Eric Burger [ mailto:eburger@snowshore.com]

Envoy=E9 : Tuesday, June 10, 2003 21:30

=C0 :  brian.wyld@eloquant.com;  speechsc@ietf.org

Objet : RE: [Speechsc] Protocol proposal for SPEECHSC





   =20

-----Original Message----- From: Brian Wyld

     =20

[ mailto:brian.wyld@eloquant.com]

   =20

Sent: Tue, June 10, 2003 12:16 PM

     =20

[snip]



   =20

Sorry, but I still think that it's easier to specify the media setup

specifically (maybe by cut-n-paste from RTSP) rather than

suck in the entire

SIP protocol.

     =20

I would be very hesitant to create yet another "looks like

SIP/RTSP, smells like SIP/RTSP, operates like SIP/RTSP, but has a

different life and future than SIP/RTSP."



I'd much rather leverage the 974 engineer years of work over the

last 6 years put in to SIP than spend 3 engineer years explaining

what is the same and different in a new protocol.  Moreover, I

would not want to find myself wishing I had 500 engineer years of

resources to catch up when something useful gets introduced into

SIP/RTSP that I might want.



SIP is actually pretty good when dealing with small, embedded

implementations.  Most everything is an extension

("Accept/Allow").  You don't even need the list of extensions to

say, "I don't know what you are talking about."  Thus an

SPEECHSC-only implementation can be pretty light.  It is what we

do in the media server world, for example.



   =20

Maybe we should instead specify the use of RTSP as the media

setup agent, as

most folks with MRCP experience will have such an

implementation already and

it is known to serve the needs of mrcp......

     =20

I can go either way.  At this point one could submit a RTSP-based

SPEECHSC protocol proposal, similar to Sarvi's.  Alternately, one

could submit a "these are the reasons RTSP

works/interoperates/easier-to-implement than SIP" draft.



Do be aware that you have until 0900 USA-ET to submit a -00 draft.



   =20

A+



Brian



PS> I note that to achieve an operation MRCP server today, it

is neccessary

to implement very little of RTSP and none of the media state

machinary (no

play, record etc). In fact, only SETUP and TEARDOWN are

really required, and

the 'tunnel message' ANNOUNCE......

     =20

My point above, exactly...





   =20



_______________________________________________

Speechsc mailing list

Speechsc@ietf.org

https://www1.ietf.org/mailman/listinfo/speechsc



 =20



------_=_NextPart_002_01C336CA.725411EF
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Brian,


 


Here=20
is the updated protocol comparison document with my updates to the SIP =
section.=20
Session control and resource control sections have been updated as per =
last=20
conference call.


 


Let me=20
know if any changes are needed.


 


-Rajiv



  
-----Original Message-----
From: Brian Wyld=20
  [mailto:brian.wyld@eloquant.com]
Sent: Thursday, June 19, =
2003 1:58=20
  AM
To: Sarvi Shanmugham
Cc: Eric Burger;=20
  speechsc@ietf.org
Subject: RE: [Speechsc] Protocol proposal =
for=20
  SPEECHSC


  
Hi=20
  Sarvi,

  
 

  
No,=20
  I think the MRCP section is ok.

  
 

  
Eric, I have no other updates yet for the protocol comparison =

  document....

  
 

  
Please note I am on holiday (real holiday, no computers) =
28th June=20
  until 15th July so won't be able to do any =
updates after=20
  28th June.

  
 

  
And=20
  finally, I'm afraid I won't be at IETF Vienna (budget, time =
constraints). I=20
  hope you manage to get enough folk to make progress on Sarvi's=20
  proposal....

  
 

  
Brian

  
 

  

  
    
-----Message d'origine-----
De : Sarvi =
Shanmugham=20
    [mailto:sarvi@cisco.com]
Envoy=E9 : Wednesday, June =
11, 2003=20
    00:12
=C0 : =
brian.wyld@eloquant.com
Cc : Eric=20
    Burger; speechsc@ietf.org
Objet : Re: [Speechsc] =
Protocol=20
    proposal for SPEECHSC

Hi Brian,
    =
 =20
          Does my section need updation(MRCP =
evalutation), if so=20
    let me know and I will get back o you with the edits by the end of =
next=20
    week.

Sarvi

Brian Wyld wrote:

    
Ok, if I have time I will munge something thru a web services =
toolset and
produce an alternative proposal based on WS.....

Then again, maybe not.

To be frank, if you all want SIP, and I don't see many other viewpoints
here, then I'll go with your experience. As long as we can model all the
different session viewpoints (as already discussed here) that are needed =
for
usage of the resources then that's fine with me. (pointers to a good =
open
source java SIP stack gratefully received....)

So, is anyone going to update their sections for the protocol comparison
document before the 30th June or not?

Brian (another hapless victem crushed by the SIP juggernaught)

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

  

      
-----Message =
d'origine-----
De : Eric Burger [mailto:eburger@snowshore.com]
Envoy=E9 : Tuesday, June 10, 2003 21:30
=C0 : brian.wyld@eloquant.com; speechsc@ietf.org
Objet : RE: [Speechsc] Protocol proposal for SPEECHSC


    

        
-----Original =
Message----- From: Brian Wyld
      
[mailto:brian.wyld@eloquant.com]
    

        
Sent: Tue, June 10, =
2003 12:16 PM
      
[snip]

    

        
Sorry, but I still =
think that it's easier to specify the media setup
specifically (maybe by cut-n-paste from RTSP) rather than
suck in the entire
SIP protocol.
      
I would be very hesitant to =
create yet another "looks like
SIP/RTSP, smells like SIP/RTSP, operates like SIP/RTSP, but has a
different life and future than SIP/RTSP."

I'd much rather leverage the 974 engineer years of work over the
last 6 years put in to SIP than spend 3 engineer years explaining
what is the same and different in a new protocol.  Moreover, I
would not want to find myself wishing I had 500 engineer years of
resources to catch up when something useful gets introduced into
SIP/RTSP that I might want.

SIP is actually pretty good when dealing with small, embedded
implementations.  Most everything is an extension
("Accept/Allow").  You don't even need the list of extensions to
say, "I don't know what you are talking about."  Thus an
SPEECHSC-only implementation can be pretty light.  It is what we
do in the media server world, for example.

    

        
Maybe we should instead =
specify the use of RTSP as the media
setup agent, as
most folks with MRCP experience will have such an
implementation already and
it is known to serve the needs of mrcp......
      
I can go either way.  At this =
point one could submit a RTSP-based
SPEECHSC protocol proposal, similar to Sarvi's.  Alternately, one
could submit a "these are the reasons RTSP
works/interoperates/easier-to-implement than SIP" draft.

Do be aware that you have until 0900 USA-ET to submit a -00 draft.

    

        
A+

Brian

PS> I note that to achieve an operation MRCP server today, it
is neccessary
to implement very little of RTSP and none of the media state
machinary (no
play, record etc). In fact, only SETUP and TEARDOWN are
really required, and
the 'tunnel message' ANNOUNCE......
      
My point above, exactly...


    

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc

  



------_=_NextPart_002_01C336CA.725411EF--

------_=_NextPart_001_01C336CA.725411EF
Content-Type: application/msword;
	name="draft-ietf-speechsc-protocol-evaluation-02-working-w2K-Rajiv.doc"
Content-Transfer-Encoding: base64
Content-Description: draft-ietf-speechsc-protocol-evaluation-02-working-w2K-Rajiv.doc
Content-Disposition: attachment;
	filename="draft-ietf-speechsc-protocol-evaluation-02-working-w2K-Rajiv.doc"
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAASQEAAAAAAAAA
EAAASwEAAAEAAAD+////AAAAAEYBAABHAQAASAEAAP//////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEATSAJBAAA+BK/AAAAAAAAEAAAAAAABAAA6fkAAA4AYmpiauI94j0AAAAAAAAAAAAAAAAAAAAA
AAAJBBYAMnkBAIBXAACAVwAAL/UAAAAAAAC5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAADQKAAAAAAAANAoAADQK
AAAAAAAANAoAAAAAAAA0CgAAAAAAADQKAAAAAAAANAoAABQAAAAAAAAAAAAAAEgKAAAAAAAArFgA
AAAAAACsWAAAAAAAAKxYAAA4AAAA5FgAAOQAAADIWQAADAEAAEgKAAAAAAAAcawAAKIBAADgWgAA
pAgAAIRjAAAoAAAArGMAAAAAAACsYwAAAAAAAKxjAAAAAAAArGMAAJYHAABCawAAVAIAAJZtAAAs
AQAAz6kAAAIAAADRqQAAAAAAANGpAAAAAAAA0akAADEAAAACqgAA+AAAAPqqAAD4AAAA8qsAACQA
AAATrgAAIAIAADOwAABsAAAAFqwAABUAAAAAAAAAAAAAAAAAAAAAAAAANAoAAAAAAADCbgAAAAAA
AAAAAAAAAAAAAAAAAAAAAACsYwAAAAAAAKxjAAAAAAAAwm4AAAAAAADCbgAAAAAAABasAAAAAAAA
enoAAAAAAAA0CgAAAAAAADQKAAAAAAAArGMAAAAAAAAAAAAAAAAAAKxjAAAAAAAAK6wAABYAAAB6
egAAAAAAAHp6AAAAAAAAenoAAAAAAADCbgAAZgQAADQKAAAAAAAArGMAAAAAAAA0CgAAAAAAAKxj
AAAAAAAAz6kAAAAAAAAAAAAAAAAAAHp6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAwm4AAAAAAADPqQAAAAAAAHp6AAAcCQAAenoAAAAAAACWgwAA
pgEAAHOmAAAwAQAANAoAAAAAAAA0CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAU6kAAAAAAACsYwAAAAAAANRaAAAMAAAAMNcrP8k2
wwFICgAAZE4AAKxYAAAAAAAAKHMAAC4GAACjpwAAJAAAAAAAAAAAAAAAU6kAAHwAAABBrAAAMAAA
AHGsAAAAAAAAx6cAAIwBAACfsAAAAAAAAFZ5AAAkAQAAn7AAAAAAAABTqQAAAAAAAHp6AAAAAAAA
SAoAAAAAAABICgAAAAAAADQKAAAAAAAANAoAAAAAAAA0CgAAAAAAADQKAAAAAAAAAgDZAAAASW50
ZXJuZXQgRHJhZnQHQi4gV3lsZAcHRG9jdW1lbnQ6IGRyYWZ0LXNwZWVjaHNjLXByb3RvY29sLWV2
YWwudHh0B0VkaXRvcgcHRXhwaXJlczogQXByaWwgMjAwMxMgQVNLICBcKiBNRVJHRUZPUk1BVCAV
B0Vsb3F1YW50BwdWZXJzaW9uIDAyBxMgU0FWRURBVEUgXEAgIk1NTU0geXl5eSIgXCogTUVSR0VG
T1JNQVQgFE1hcmNoIDIwMDMVBwcNU1BFRUNIU0MgUHJvdG9jb2wgRXZhbHVhdGlvbg0NISEhIFdP
UktJTkcgQ09QWSBGT1IgQVVUSE9SUyAhISENISEhIFBsZWFzZSBsaW1pdCBjaGFuZ2VzIHRvIHlv
dXIgc2VjdGlvbnMgdG8gbWFrZSB0aGUgbWVyZ2UgZWFzaWVyISEhDUFzIGRpc2N1c3NlZCBvbiB0
aGUgY29uZiBjYWxsIG9mIDUvMy8yMDAzLCB0aGUgcHJvdG9jb2wgZXZhbHVhdGlvbiBzZWN0aW9u
cyBhcmUgbm93IG9yZ2FuaXplZCBhcyBmb2xsb3dzOg1jb21wYXJpc29uIG9mIJFhcHByb2FjaJIg
YmV0d2VlbiB3ZWIgc2VydmljZXMgYW5kIGNsYXNzaWMgc2Vzc2lvbiBjb250cm9sDXByb3RvY29s
IGV2YWwgc2VjdGlvbnMgYW5hbHl6aW5nIG9ubHkgdGhlIJNzZXNzaW9uIGNvbnRyb2yUIGFzcGVj
dHMgb2YgdGhlIHNwZWVjaHNjIHJlcXVpcmVtZW50cywgZm9yIGVhY2ggcHJvdG9jb2wgdGhhdCBj
b3VsZCBiZSBzYWlkIHRvIHByb3ZpZGUgc3VjaCBmZWF0dXJlcyAoQkVFUCwgU0lQLCBSVFNQLCBX
ZWJTZXJ2aWNlcykuIFRoZXNlIHNlY3Rpb25zIG5vdyBhbHNvIGluY2x1ZGUgYSBuZXcgZWxlbWVu
dCB0byBjb25zaWRlciA6IHRoZSCTaW50ZXJhY3Rpb24gbW9kZWyUIG9mIHRoZSBwcm90b2NvbCBp
biB0aGUgZGF0YSBwaGFzZSAoZWcgZG9lcyBpdCBzdXBwb3J0IHRoZSByZXNvdXJjZSBzZW5kaW5n
IGV2ZW50cyBvciByZXF1ZXN0cyBiYWNrIHRvIHRoZSByZXNvdXJjZSB1c2VyPykgKGxvb2sgZm9y
IJNUQkOUIGF0IHRoZSBlbmQgb2YgdGhlIGV2YWwgc2VjdGlvbnMpDXByb3RvY29sIGV2YWwgc2Vj
dGlvbnMgYW5hbHl6aW5nIHRoZSCTcmVzb3VyY2UgY29udHJvbJQgYXNwZWN0cyBvZiB0aGUgc3Bl
ZWNoc2MgcmVxdWlyZW1lbnRzLCBmb3IgcHJvdG9jb2xzIHRoYXQgaGF2ZSBzdWNoIGVsZW1lbnRz
IEFMUkVBRFkgKE1SQ1AsIFJUU1ApLiBJdCBpcyBvYnZpb3VzIHRoYXQgdGhlIHNlc3Npb24gY29u
dHJvbCBwcm90b2NvbCBjYW4gYWxsIGJlIGV4dGVuZGVkIHRvIGFkZCB0aGVzZSBhc3BlY3RzIJYg
dGhlIHF1ZXN0aW9uIGlzIGhvdyBlYXNpbHkgYW5kIG5hdHVyYWxseT8NDVlvdSB3aWxsIGZpbmQg
dGhlIG1hdGVyaWFsIEkgc25pcHBlZCB0byBhZGp1c3QgdGhlIGV2YWwgc2VjdGlvbnMgdG8gdGhp
cyBtb2RlbCBhdCB0aGUgZW5kIG9mIHRoZSBkb2N1bWVudCBpbiBjYXNlIHlvdSB3YW50IHRvIGJy
aW5nIGFueSBvZiBpdCBiYWNrIGJlY2F1c2UgaXQgcmVsYXRlcyB0byBhbm90aGVyIHJlcXVpcmVt
ZW50hS4NDUVuam95LA0NQnJpYW4NDSANU3RhdHVzIG9mIHRoaXMgTWVtbyANDVRoaXMgZG9jdW1l
bnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCBh
bGwgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDEwIG9mIFJGQzIwMjYuIA0gICAgDUludGVybmV0LURy
YWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIFRh
c2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3Rl
IHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMg
YXMgSW50ZXJuZXQtRHJhZnRzLiANICAgIA1JbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3Vt
ZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVk
LCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkgdGltZS4g
SXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZSBt
YXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4i
IA0gICAgDVRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3Nl
ZCBhdCANICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQgDVRo
ZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNz
ZWQgYXQgDSAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuIA0gICAgDUFic3RyYWN0
IA0NVGhpcyBkb2N1bWVudCBpcyB0aGUgUHJvdG9jb2wgRXZhbHVhdGlvbiBEb2N1bWVudCBmb3Ig
dGhlIFNQRUVDSFNDIFdvcmtpbmcgR3JvdXAuICBTZWN0aW9uIDMgcHJvdmlkZXMgdGhlIHN1bW1h
cnkgb2YgdGhlICBpbmRpdmlkdWFsIHByb3RvY29sIGNvbXBhcmlzb25zIChpbiB0aGUgc2VjdGlv
bnMgNC1OIGZvbGxvd2luZykgYWdhaW5zdCB0aGUgU1BFRUNIU0MgcmVxdWlyZW1lbnRzIFsxXS4N
IA1UYWJsZSBvZiBDb250ZW50cw0NEyBUT0MgXG8gIjEtMiIgXGggXHogFBMgSFlQRVJMSU5LIFxs
ICJfVG9jMzQ2NjY2NTEiIAEUMS4JT3ZlcnZpZXcJEyBQQUdFUkVGIF9Ub2MzNDY2NjY1MSBcaCAB
FDMVFQ0TIEhZUEVSTElOSyBcbCAiX1RvYzM0NjY2NjUyIiABFDIuCVByb3RvY29sIFByb3Bvc2Fs
cwkTIFBBR0VSRUYgX1RvYzM0NjY2NjUyIFxoIAEUMxUVDRMgSFlQRVJMSU5LIFxsICJfVG9jMzQ2
NjY2NTMiIAEUMy4JUHJvdG9jb2wgRXZhbHVhdGlvbiBTdW1tYXJpZXMJEyBQQUdFUkVGIF9Ub2Mz
NDY2NjY1MyBcaCABFDQVFQ0TIEhZUEVSTElOSyBcbCAiX1RvYzM0NjY2NjU0IiABFDMuMS4JUHJv
dG9jb2wgWAkTIFBBR0VSRUYgX1RvYzM0NjY2NjU0IFxoIAEUNBUVDRMgSFlQRVJMSU5LIFxsICJf
VG9jMzQ2NjY2NTUiIAEUNC4JQmFzaWMgUHJvdG9jb2wgOiBXZWIgU2VydmljZXMgdnMgU2Vzc2lv
biBDb250cm9sIHByb3RvY29scwkTIFBBR0VSRUYgX1RvYzM0NjY2NjU1IFxoIAEUNRUVDRMgSFlQ
RVJMSU5LIFxsICJfVG9jMzQ2NjY2NTYiIAEUVEJDIDogSmVycnkgQ2FydGVyCRMgUEFHRVJFRiBf
VG9jMzQ2NjY2NTYgXGggARQ1FRUNEyBIWVBFUkxJTksgXGwgIl9Ub2MzNDY2NjY1NyIgARQ1LglT
ZXNzaW9uIENvbnRyb2wgOiCTQmVlcJQgQ29tcGxpYW5jZSBFdmFsdWF0aW9uIChKZXJyeSBDYXJ0
ZXIpCRMgUEFHRVJFRiBfVG9jMzQ2NjY2NTcgXGggARQ1FRUNEyBIWVBFUkxJTksgXGwgIl9Ub2Mz
NDY2NjY1OCIgARQ1LjEuCUdlbmVyYWwgbm90ZXM6CRMgUEFHRVJFRiBfVG9jMzQ2NjY2NTggXGgg
ARQ1FRUNEyBIWVBFUkxJTksgXGwgIl9Ub2MzNDY2NjY1OSIgARQ1LjIuCUFuYWx5c2lzIG9mIEdl
bmVyYWwgUmVxdWlyZW1lbnRzCRMgUEFHRVJFRiBfVG9jMzQ2NjY2NTkgXGggARQ1FRUNEyBIWVBF
UkxJTksgXGwgIl9Ub2MzNDY2NjY2MCIgARQ1LjMuCUFuYWx5c2lzIG9mIER1cGxleGluZyBhbmQg
UGFyYWxsZWwgT3BlcmF0aW9uIFJlcXVpcmVtZW50cwkTIFBBR0VSRUYgX1RvYzM0NjY2NjYwIFxo
IAEUNhUVDRMgSFlQRVJMSU5LIFxsICJfVG9jMzQ2NjY2NjEiIAEUNS40LglBbmFseXNpcyBvZiBh
ZGRpdGlvbmFsIGNvbnNpZGVyYXRpb25zIChub24tbm9ybWF0aXZlKQkTIFBBR0VSRUYgX1RvYzM0
NjY2NjYxIFxoIAEUNhUVDRMgSFlQRVJMSU5LIFxsICJfVG9jMzQ2NjY2NjIiIAEUNS41LglBbmFs
eXNpcyBvZiBTZWN1cml0eSBjb25zaWRlcmF0aW9ucwkTIFBBR0VSRUYgX1RvYzM0NjY2NjYyIFxo
IAEUNhUVDRMgSFlQRVJMSU5LIFxsICJfVG9jMzQ2NjY2NjMiIAEUNS42LglJbnRlcmFjdGlvbiBN
b2RlbAkTIFBBR0VSRUYgX1RvYzM0NjY2NjYzIFxoIAEUNhUVDRMgSFlQRVJMSU5LIFxsICJfVG9j
MzQ2NjY2NjQiIAEUNi4JU2Vzc2lvbiBDb250cm9sIDogk1NJUJQgQ29tcGxpZW5jZSBFdmFsdWF0
aW9uIChSYWppdiBEaGFybWFkaGlrYXJpKQkTIFBBR0VSRUYgX1RvYzM0NjY2NjY0IFxoIAEUNxUV
DRMgSFlQRVJMSU5LIFxsICJfVG9jMzQ2NjY2NjUiIAEUNi4xLglJbnRyb2R1Y3Rpb24JEyBQQUdF
UkVGIF9Ub2MzNDY2NjY2NSBcaCABFDcVFQ0TIEhZUEVSTElOSyBcbCAiX1RvYzM0NjY2NjY2IiAB
FDYuMi4JQW5hbHlzaXMgb2YgR2VuZXJhbCBSZXF1aXJlbWVudHMJEyBQQUdFUkVGIF9Ub2MzNDY2
NjY2NiBcaCABFDcVFQ0TIEhZUEVSTElOSyBcbCAiX1RvYzM0NjY2NjY3IiABFDYuMy4JQW5hbHlz
aXMgb2YgRHVwbGV4aW5nIGFuZCBQYXJhbGxlbCBPcGVyYXRpb24gUmVxdWlyZW1lbnRzCRMgUEFH
RVJFRiBfVG9jMzQ2NjY2NjcgXGggARQ4FRUNEyBIWVBFUkxJTksgXGwgIl9Ub2MzNDY2NjY2OCIg
ARQ2LjQuCUFuYWx5c2lzIG9mIGFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgKG5vbi1ub3JtYXRp
dmUpCRMgUEFHRVJFRiBfVG9jMzQ2NjY2NjggXGggARQ4FRUNEyBIWVBFUkxJTksgXGwgIl9Ub2Mz
NDY2NjY2OSIgARQ2LjUuCUFuYWx5c2lzIG9mIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zCRMgUEFH
RVJFRiBfVG9jMzQ2NjY2NjkgXGggARQ4FRUNEyBIWVBFUkxJTksgXGwgIl9Ub2MzNDY2NjY3MCIg
ARQ2LjYuCU90aGVyIENyaXRlcmlhCRMgUEFHRVJFRiBfVG9jMzQ2NjY2NzAgXGggARQ4FRUNEyBI
WVBFUkxJTksgXGwgIl9Ub2MzNDY2NjY3MSIgARQ2LjcuCUludGVyYWN0aW9uIE1vZGVsCRMgUEFH
RVJFRiBfVG9jMzQ2NjY2NzEgXGggARQ5FRUNEyBIWVBFUkxJTksgXGwgIl9Ub2MzNDY2NjY3MiIg
ARQ3LglTZXNzaW9uIENvbnRyb2wgOiCTUlRTUJQgQ29tcGxpZW5jZSBFdmFsdWF0aW9uIChCcmlh
biBXeWxkKQkTIFBBR0VSRUYgX1RvYzM0NjY2NjcyIFxoIAEUMTAVFQ0TIEhZUEVSTElOSyBcbCAi
X1RvYzM0NjY2NjczIiABFDcuMS4JR2VuZXJhbCBJbnRyb2R1Y3Rpb24JEyBQQUdFUkVGIF9Ub2Mz
NDY2NjY3MyBcaCABFDEwFRUNEyBIWVBFUkxJTksgXGwgIl9Ub2MzNDY2NjY3NCIgARQ3LjIuCUFu
YWx5c2lzIG9mIEdlbmVyYWwgUmVxdWlyZW1lbnRzCRMgUEFHRVJFRiBfVG9jMzQ2NjY2NzQgXGgg
ARQxMBUVDRMgSFlQRVJMSU5LIFxsICJfVG9jMzQ2NjY2NzUiIAEUNy4zLglBbmFseXNpcyBvZiBE
dXBsZXhpbmcgYW5kIFBhcmFsbGVsIE9wZXJhdGlvbiBSZXF1aXJlbWVudHMJEyBQQUdFUkVGIF9U
b2MzNDY2NjY3NSBcaCABFDEwFRUNEyBIWVBFUkxJTksgXGwgIl9Ub2MzNDY2NjY3NiIgARQ3LjQu
CUFuYWx5c2lzIG9mIGFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgKG5vbi1ub3JtYXRpdmUpCRMg
UEFHRVJFRiBfVG9jMzQ2NjY2NzYgXGggARQxMRUVDRMgSFlQRVJMSU5LIFxsICJfVG9jMzQ2NjY2
NzciIAEUNy41LglBbmFseXNpcyBvZiBTZWN1cml0eSBjb25zaWRlcmF0aW9ucwkTIFBBR0VSRUYg
X1RvYzM0NjY2Njc3IFxoIAEUMTEVFQ0TIEhZUEVSTElOSyBcbCAiX1RvYzM0NjY2Njc4IiABFDcu
Ni4JSW50ZXJhY3Rpb24gTW9kZWwJEyBQQUdFUkVGIF9Ub2MzNDY2NjY3OCBcaCABFDExFRUNEyBI
WVBFUkxJTksgXGwgIl9Ub2MzNDY2NjY3OSIgARQ4LglQcm90b2NvbCCTV2ViIFNlcnZpY2VzlCBD
b21wbGllbmNlIEV2YWx1YXRpb24gKFN0ZXBoYW5lIEguIE1hZXMpCRMgUEFHRVJFRiBfVG9jMzQ2
NjY2NzkgXGggARQxMRUVDRMgSFlQRVJMSU5LIFxsICJfVG9jMzQ2NjY2ODAiIAEUOC4xLglHZW5l
cmFsIE5vdGVzOgkTIFBBR0VSRUYgX1RvYzM0NjY2NjgwIFxoIAEUMTEVFQ0TIEhZUEVSTElOSyBc
bCAiX1RvYzM0NjY2NjgxIiABFDguMi4JQW5hbHlzaXMgb2YgR2VuZXJhbCBSZXF1aXJlbWVudHMJ
EyBQQUdFUkVGIF9Ub2MzNDY2NjY4MSBcaCABFDEyFRUNEyBIWVBFUkxJTksgXGwgIl9Ub2MzNDY2
NjY4MiIgARQ4LjMuCUFuYWx5c2lzIG9mIER1cGxleGluZyBhbmQgUGFyYWxsZWwgT3BlcmF0aW9u
IFJlcXVpcmVtZW50cwkTIFBBR0VSRUYgX1RvYzM0NjY2NjgyIFxoIAEUMTQVFQ0TIEhZUEVSTElO
SyBcbCAiX1RvYzM0NjY2NjgzIiABFDguNC4JQW5hbHlzaXMgb2YgYWRkaXRpb25hbCBjb25zaWRl
cmF0aW9ucyAobm9uLW5vcm1hdGl2ZSkJEyBQQUdFUkVGIF9Ub2MzNDY2NjY4MyBcaCABFDE0FRUN
EyBIWVBFUkxJTksgXGwgIl9Ub2MzNDY2NjY4NCIgARQ4LjUuCUFuYWx5c2lzIG9mIFNlY3VyaXR5
IGNvbnNpZGVyYXRpb25zCRMgUEFHRVJFRiBfVG9jMzQ2NjY2ODQgXGggARQxNRUVDRMgSFlQRVJM
SU5LIFxsICJfVG9jMzQ2NjY2ODUiIAEUOC42LglJbnRlcmFjdGlvbiBNb2RlbAkTIFBBR0VSRUYg
X1RvYzM0NjY2Njg1IFxoIAEUMTUVFQ0TIEhZUEVSTElOSyBcbCAiX1RvYzM0NjY2Njg2IiABFDku
CVJlc291cmNlIENvbnRyb2wgOiCTTVJDUJQgQ29tcGxpZW5jZSBFdmFsdWF0aW9uIChTYXJ2aSBT
aGFubXVnaGFtKQkTIFBBR0VSRUYgX1RvYzM0NjY2Njg2IFxoIAEUMTUVFQ0TIEhZUEVSTElOSyBc
bCAiX1RvYzM0NjY2Njg3IiABFDkuMS4JR2VuZXJhbAkTIFBBR0VSRUYgX1RvYzM0NjY2Njg3IFxo
IAEUMTUVFQ0TIEhZUEVSTElOSyBcbCAiX1RvYzM0NjY2Njg4IiABFDkuMi4JQW5hbHlzaXMgb2Yg
VFRTIHJlcXVpcmVtZW50cwkTIFBBR0VSRUYgX1RvYzM0NjY2Njg4IFxoIAEUMTYVFQ0TIEhZUEVS
TElOSyBcbCAiX1RvYzM0NjY2Njg5IiABFDkuMy4JQW5hbHlzaXMgb2YgQVNSIHJlcXVpcmVtZW50
cwkTIFBBR0VSRUYgX1RvYzM0NjY2Njg5IFxoIAEUMTcVFQ0TIEhZUEVSTElOSyBcbCAiX1RvYzM0
NjY2NjkwIiABFDkuNC4JQW5hbHlzaXMgb2YgU3BlYWtlciBJZGVudGlmaWNhdGlvbiBhbmQgVmVy
aWZpY2F0aW9uIFJlcXVpcmVtZW50cwkTIFBBR0VSRUYgX1RvYzM0NjY2NjkwIFxoIAEUMTgVFQ0T
IEhZUEVSTElOSyBcbCAiX1RvYzM0NjY2NjkxIiABFDEwLglSZXNvdXJjZSBDb250cm9sIDogk1JU
U1CUIENvbXBsaWVuY2UgRXZhbHVhdGlvbiAoQnJpYW4gV3lsZCkJEyBQQUdFUkVGIF9Ub2MzNDY2
NjY5MSBcaCABFDE5FRUNEyBIWVBFUkxJTksgXGwgIl9Ub2MzNDY2NjY5MiIgARQxMC4xLglHZW5l
cmFsIEludHJvZHVjdGlvbgkTIFBBR0VSRUYgX1RvYzM0NjY2NjkyIFxoIAEUMTkVFQ0TIEhZUEVS
TElOSyBcbCAiX1RvYzM0NjY2NjkzIiABFDEwLjIuCUFuYWx5c2lzIG9mIFRUUyByZXF1aXJlbWVu
dHMJEyBQQUdFUkVGIF9Ub2MzNDY2NjY5MyBcaCABFDE5FRUNEyBIWVBFUkxJTksgXGwgIl9Ub2Mz
NDY2NjY5NCIgARQxMC4zLglBbmFseXNpcyBvZiBBU1IgcmVxdWlyZW1lbnRzCRMgUEFHRVJFRiBf
VG9jMzQ2NjY2OTQgXGggARQyMBUVDRMgSFlQRVJMSU5LIFxsICJfVG9jMzQ2NjY2OTUiIAEUMTAu
NC4JQW5hbHlzaXMgb2YgU3BlYWtlciBJZGVudGlmaWNhdGlvbiBhbmQgVmVyaWZpY2F0aW9uIFJl
cXVpcmVtZW50cwkTIFBBR0VSRUYgX1RvYzM0NjY2Njk1IFxoIAEUMjAVFQ0TIEhZUEVSTElOSyBc
bCAiX1RvYzM0NjY2Njk2IiABFDExLglTZWN1cml0eSBDb25zaWRlcmF0aW9ucwkTIFBBR0VSRUYg
X1RvYzM0NjY2Njk2IFxoIAEUMjAVFQ0TIEhZUEVSTElOSyBcbCAiX1RvYzM0NjY2Njk3IiABFDEy
LglSZWZlcmVuY2VzCRMgUEFHRVJFRiBfVG9jMzQ2NjY2OTcgXGggARQyMBUVDRMgSFlQRVJMSU5L
IFxsICJfVG9jMzQ2NjY2OTgiIAEUMTIuMS4JQW5hbHlzaXMgb2YgVFRTIHJlcXVpcmVtZW50cwkT
IFBBR0VSRUYgX1RvYzM0NjY2Njk4IFxoIAEUMjMVFQ0TIEhZUEVSTElOSyBcbCAiX1RvYzM0NjY2
Njk5IiABFDEyLjIuCUFuYWx5c2lzIG9mIEFTUiByZXF1aXJlbWVudHMJEyBQQUdFUkVGIF9Ub2Mz
NDY2NjY5OSBcaCABFDI0FRUNEyBIWVBFUkxJTksgXGwgIl9Ub2MzNDY2NjcwMCIgARQxMi4zLglB
bmFseXNpcyBvZiBTcGVha2VyIElkZW50aWZpY2F0aW9uIGFuZCBWZXJpZmljYXRpb24gUmVxdWly
ZW1lbnRzCRMgUEFHRVJFRiBfVG9jMzQ2NjY3MDAgXGggARQyNBUVDRMgSFlQRVJMSU5LIFxsICJf
VG9jMzQ2NjY3MDEiIAEUMTIuNC4JQW5hbHlzaXMgb2YgVFRTIHJlcXVpcmVtZW50cwkTIFBBR0VS
RUYgX1RvYzM0NjY2NzAxIFxoIAEUMjYVFQ0TIEhZUEVSTElOSyBcbCAiX1RvYzM0NjY2NzAyIiAB
FDEyLjUuCUFuYWx5c2lzIG9mIEFTUiByZXF1aXJlbWVudHMJEyBQQUdFUkVGIF9Ub2MzNDY2Njcw
MiBcaCABFDI2FRUNEyBIWVBFUkxJTksgXGwgIl9Ub2MzNDY2NjcwMyIgARQxMi42LglBbmFseXNp
cyBvZiBTcGVha2VyIElkZW50aWZpY2F0aW9uIGFuZCBWZXJpZmljYXRpb24gUmVxdWlyZW1lbnRz
CRMgUEFHRVJFRiBfVG9jMzQ2NjY3MDMgXGggARQyNxUVDRMgSFlQRVJMSU5LIFxsICJfVG9jMzQ2
NjY3MDQiIAEUMTIuNy4JQW5hbHlzaXMgb2YgVFRTIHJlcXVpcmVtZW50cwkTIFBBR0VSRUYgX1Rv
YzM0NjY2NzA0IFxoIAEUMjgVFQ0TIEhZUEVSTElOSyBcbCAiX1RvYzM0NjY2NzA1IiABFDEyLjgu
CUFuYWx5c2lzIG9mIEFTUiByZXF1aXJlbWVudHMJEyBQQUdFUkVGIF9Ub2MzNDY2NjcwNSBcaCAB
FDI5FRUNEyBIWVBFUkxJTksgXGwgIl9Ub2MzNDY2NjcwNiIgARQxMi45LglBbmFseXNpcyBvZiBT
cGVha2VyIElkZW50aWZpY2F0aW9uIGFuZCBWZXJpZmljYXRpb24gUmVxdWlyZW1lbnRzCRMgUEFH
RVJFRiBfVG9jMzQ2NjY3MDYgXGggARQzMBUVDRMgSFlQRVJMSU5LIFxsICJfVG9jMzQ2NjY3MDci
IAEUMTIuMTAuCUFuYWx5c2lzIG9mIEdlbmVyYWwgUmVxdWlyZW1lbnRzCRMgUEFHRVJFRiBfVG9j
MzQ2NjY3MDcgXGggARQzMRUVDRMgSFlQRVJMSU5LIFxsICJfVG9jMzQ2NjY3MDgiIAEUMTIuMTEu
CUFuYWx5c2lzIG9mIER1cGxleGluZyBhbmQgUGFyYWxsZWwgT3BlcmF0aW9uIFJlcXVpcmVtZW50
cwkTIFBBR0VSRUYgX1RvYzM0NjY2NzA4IFxoIAEUMzIVFQ0TIEhZUEVSTElOSyBcbCAiX1RvYzM0
NjY2NzA5IiABFDEyLjEyLglBbmFseXNpcyBvZiBhZGRpdGlvbmFsIGNvbnNpZGVyYXRpb25zIChu
b24tbm9ybWF0aXZlKQkTIFBBR0VSRUYgX1RvYzM0NjY2NzA5IFxoIAEUMzIVFQ0TIEhZUEVSTElO
SyBcbCAiX1RvYzM0NjY2NzEwIiABFDEyLjEzLglBbmFseXNpcyBvZiBTZWN1cml0eSBjb25zaWRl
cmF0aW9ucwkTIFBBR0VSRUYgX1RvYzM0NjY2NzEwIFxoIAEUMzIVFQ0VDU92ZXJ2aWV3IA0gICAg
DVRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgdGhlIHRlbXBsYXRlIGZvciB0aGUgY29udGVudCBmb3Ig
dGhlIFNQRUVDSFNDIFByb3RvY29sIEV2YWx1YXRpb24gZG9jdW1lbnQuICAgDSAgICANVGhpcyBz
ZWN0aW9uIHdpbGwgY29udGFpbiBhbiBvdmVydmlldyBvZiB0aGUgcHJvY2Vzcy4NDVNlY3Rpb24g
MiBjb250YWlucyBhIGxpc3Qgb2YgdGhlIHByb3Bvc2VkIHByb3RvY29scyBzdWJtaXR0ZWQgdG8g
V0cuIFRoZXNlIHByb3RvY29scyBhcmUgaW4gZmFjdCBvZiAzIGRpZmZlcmVudCBuYXR1cmVzOg1h
IGdlbmVyaWMgc2VydmljZS9yZXNvdXJjZSBhY2Nlc3Mgc3lzdGVtIChXZWIgU2VydmljZXMpDZFj
bGFzc2ljkiBzZXNzaW9uIGNvbnRyb2wgcHJvdG9jb2xzIGZvciBtZWRpYSBjaGFubmVscyAoQkVF
UCwgU0lQLCBSVFNQKSwgb2Ygd2hpY2ggUlRTUCBhbHNvIHByb3ZpZGVzIHJlc291cmNlIGNvbnRy
b2wuDWEgc3BlY2lmaWMgQVNSL1RUUyByZXNvdXJjZSBjb250cm9sIG1lc3NhZ2Ugc2V0IGRlc2ln
bmVkIHRvIGJlIHR1bm5lbGVkIGluIGEgc2Vzc2lvbiBjb250cm9sIHByb3RvY29sIChNUkNQKQ0N
U2VjdGlvbiAzIHByb3ZpZGVzIGEgc3VtbWFyeSBvZiB0aGUgcHJvcG9zZWQgcHJvdG9jb2xzIGFn
YWluc3QgdGhlIFJlcXVpcmVtZW50cyBhbmQgZnJhbWV3b3JrLiANDVNlY3Rpb24gNCBjb250YWlu
cyBhIGNvbXBhcmlzb24gb2YgdGhlIGFwcHJvYWNoZXMgb2YgdGhlIGNsYXNzaWMgc2Vzc2lvbiBj
b250cm9sIHR5cGUgcHJvdG9jb2xzIHZzIGEgd2ViIHNlcnZpY2VzIHN0eWxlIHdpdGggcmVzcGVj
dCB0byB0aGVpciBzdWl0YWJpbGl0eSBmb3IgdGhlIGJhc2ljIGNvbnRyb2wgcHJvdG9jb2wuDQ1T
ZWN0aW9ucyA1LTggcHJvdmlkZSB0aGUgaW5kaXZpZHVhbCBwcm90b2NvbCBldmFsdWF0aW9ucyBm
b3IgdGhlIHByb3RvY29scyBwcm92aWRpbmcgc2Vzc2lvbiBjb250cm9sIGFnYWluc3QgdGhlIFNQ
RUVDSFNDIHJlcXVpcmVtZW50cyBbMV0gdGhhdCByZWxhdGUgdG8gdGhlc2UgbmVlZHMuDQ1TZWN0
aW9ucyA5IGFuZCAxMCBwcm92aWRlIGluZGl2aWR1YWwgcHJvdG9jb2wgZXZhbHVhdGlvbnMgZm9y
IHByb3RvY29scyBwcm92aWRpbmcgcmVzb3VyY2UgY29udHJvbCBhZ2FpbnN0IHRoZSBTUEVFQ0hT
QyByZXNvdXJjZSBjb250cm9sIHJlcXVpcmVtZW50cy4NICAgIA1Qcm90b2NvbCBQcm9wb3NhbHMN
DVRoaXMgc2VjdGlvbiBjb250YWlucyBhIGxpc3Qgb2YgdGhlIGV4aXN0aW5nIHByb3RvY29scyBz
dWJtaXR0ZWQgdG8gdGhlIFNQRUVDSFNDIFdHIGZvciBjb25zaWRlcmF0aW9uIGJ5IHRoZSBkZWFk
bGluZS4gDUJFRVANU0lQDVJUU1ANTVJDUCAoaW5pdGlhbCBzdWJtaXNzaW9uKQ1XZWIgU2Vydmlj
ZXMNDQ1FYWNoIHByb3RvY29sIHNlY3Rpb24gY29udGFpbnMgYSByZXZpZXcgb2YgdGhlIHByb3Rv
Y29sknMgbGV2ZWwgb2YgY29tcGxpYW5jZSB0byBlYWNoIG9mIHRoZSBTUEVFQ0hTQyBSZXF1aXJl
bWVudHMgWzFdIGFzIGRlcml2ZWQgZnJvbSB0aGUgcHJvcG9zZWQgcHJvdG9jb2wgZG9jdW1lbnRz
LiBUaGUgZm9sbG93aW5nIGtleSB3aWxsIGJlIHVzZWQgdG8gaWRlbnRpZnkgdGhlIGxldmVsIG9m
IGNvbXBsaWFuY3kgb2YgZWFjaCBvZiB0aGUgaW5kaXZpZHVhbCBwcm90b2NvbHM6DQ1UID0gVG90
YWwgQ29tcGxpZW5jZS4gIE1lZXRzIHRoZSByZXF1aXJlbWVudCBmdWxseS4NUCA9IFBhcnRpYWwg
Q29tcGxpYW5jZS4gIE1lZXRzIHNvbWUgYXNwZWN0IG9mIHRoZSByZXF1aXJlbWVudC4NUCsgPSBD
b21wbGllbmNlIHBvc3NpYmxlLiBDb3VsZCBtZWV0IHRoZSByZXF1aXJlbWVudCB3aXRoIJNuYXR1
cmFslCBldm9sdXRpb24gb2YgdGhlIHByb3RvY29sLiANRiA9IEZhaWxlZCBDb21wbGlhbmNlLiAg
RG9lcyBub3QgbWVldCB0aGUgcmVxdWlyZW1lbnQuIA0NUHJvdG9jb2wgRXZhbHVhdGlvbiBTdW1t
YXJpZXMgDSAgICANVG8gcHJvdmlkZSBzdGFuZGFsb25lIGNvbXBsZXRlbmVzcyBmb3IgdGhpcyBk
b2N1bWVudCwgdGhpcyBzZWN0aW9uIGNvbnRhaW5zIGEgc3VtbWFyeSBvZiBlYWNoIG9mIHRoZSBw
cm90b2NvbCBjb21wYXJpc29ucy4gVGhlIGNvbXBhcmlzb25zIHNob3VsZCBleHBsaWNpdGx5IHJl
ZmVyZW5jZSB0aGUgcmVxdWlyZW1lbnRzIGFzIGRlZmluZWQgaW4gWzFdLiANDVRCRCA6IFRoaXMg
c2VjdGlvbiB3aWxsIGJlIGNvbXBsZXRlZCBvbmNlIGFncmVlbWVudCBpcyByZWFjaGVkIG9uIHRo
ZSBzcGVjaWZpYyBwcm90b2NvbCBhbmFseXNpcyBzZWN0aW9ucy4NUHJvdG9jb2wgWA1Qcm90b2Nv
bCB4IEFyY2hpdGVjdHVyYWwgTW9kZWwgYXMgY29tcGFyZWQgdG8gdGhlIFNQRUVDSFNDIEFyY2hp
dGVjdHVyYWwgRnJhbWV3b3JrDQ1UaGlzIHNlY3Rpb24gd291bGQgY29udGFpbiBhIGRlc2NyaXB0
aW9uIG9mIHRoZSBrZXkgYXNwZWN0cyBvZiB0aGUgYXJjaGl0ZWN0dXJhbCBtb2RlbCBvZiBwcm90
b2NvbCBYIGFuZCBhIGNvbXBhcmlzb24gb2YgdGhpcyBtb2RlbCBhZ2FpbnN0IHRoZSBTUEVFQ0hT
QyBmcmFtZXdvcmssIGhpZ2hsaWdodGluZyB0aGUgcHJvcy9jb25zIG9mIHRoZSBhcHBsaWNhYmls
aXR5IG9mIHByb3RvY29sIHggdG8gU1BFRUNIU0MuDVNQRUVDSFNDIHJlcXVpcmVtZW50cyBtZXQg
YnkgcHJvdG9jb2wgWC4NDVRoaXMgc2VjdGlvbiBjb250YWlucyBhIGRlc2NyaXB0aW9uIG9mIHRo
ZSBTUEVFQ0hTQyByZXF1aXJlbWVudHMgbWV0IGJ5IHByb3RvY29sIFguDVNQRUVDSFNDIHJlcXVp
cmVtZW50cyBwYXJ0aWFsbHkgbWV0IGJ5IHByb3RvY29sIFguDQ1UaGlzIHNlY3Rpb24gY29udGFp
bnMgYSBkZXNjcmlwdGlvbiBvZiB0aGUgU1BFRUNIU0MgcmVxdWlyZW1lbnRzIHBhcnRpYWxseSBt
ZXQgYnkgcHJvdG9jb2wgWC4gW05vdGU6IGlkZWFsbHksIHRoZXJlIHdvdWxkIGJlIGZldyBvciBO
T05FIG9mIHRoZXNlIHByb3ZpZGVkIHRoZSBTUEVFQ0hTQyByZXF1aXJlbWVudHMgaGF2ZSBiZWVu
IGRlZmluZWQgYXQgdGhlIGFwcHJvcHJpYXRlIGxldmVsXS4gDQlTUEVFQ0hTQyByZXF1aXJlbWVu
dHMgY2FuIGJlIG1ldCBieSBwcm90b2NvbCBYIHdpdGggk25hdHVyYWyUIGV2b2x1dGlvbnMuDQ1U
aGlzIHNlY3Rpb24gY29udGFpbnMgYSBkZXNjcmlwdGlvbiBvZiB0aGUgU1BFRUNIU0MgcmVxdWly
ZW1lbnRzIG5vdCBjdXJyZW50bHkgbWV0IGJ5IHByb3RvY29sIFggYnV0IHRoYXQgY291bGQgYmUg
bWV0IGFzc3VtaW5nIHNvbWUgZXZvbHV0aW9ucy4gW05vdGU6IHRoZSBkZWZpbml0aW9uIG9mIJNu
YXR1cmFslCBldm9sdXRpb24gd2lsbCBubyBkb3VidCBiZSBmb3IgZGlzY3Vzc2lvbl0uIA1TUEVF
Q0hTQyByZXF1aXJlbWVudHMgTk9UIG1ldCBieSBwcm90b2NvbCBYLiANDVRoaXMgc2VjdGlvbiBj
b250YWlucyBhIGRlc2NyaXB0aW9uIG9mIHRoZSBTUEVFQ0hTQyByZXF1aXJlbWVudHMgdGhhdCBh
cmUgTk9UIG1ldCBieSBwcm90b2NvbCBYLiBbTm90ZTogYW4gaW1wb3J0YW50IGFzcGVjdCB0byBo
aWdobGlnaHQgaW4gdGhlIGluZGl2aWR1YWwgcHJvdG9jb2wgY29tcGFyaXNvbnMgd291bGQgYmUg
dGhlIHdvcmsgcmVxdWlyZWQgdG8gZXh0ZW5kIHByb3RvY29sIFggdG8gYmUgYWJsZSB0byBzdXBw
b3J0IHRoaXMgcmVxdWlyZW1lbnQuXQ0NQ29yZSBQcm90b2NvbCBTZWN0aW9uIDogV2ViIFNlcnZp
Y2VzIHZzIFNlc3Npb24gQ29udHJvbCBwcm90b2NvbHMgKEplcnJ5IENhcnRlcikNDVRCQyA6IEpl
cnJ5LCBnb29kIGx1Y2shDQ1TZXNzaW9uIENvbnRyb2wgOiCTQmVlcJQgQ29tcGxpYW5jZSBFdmFs
dWF0aW9uIChKZXJyeSBDYXJ0ZXIpDUdlbmVyYWwgbm90ZXM6DQ1UaGUgQkVFUCBwcm90b2NvbCBw
cm92aWRlcyBhIGdlbmVyYWwgZnJhbWV3b3JrIGZvciBlc3RhYmxpc2hpbmcgDWNvbm5lY3Rpb25z
LCBkZWZpbmluZyBuZXcgY2hhbm5lbHMsIG5lZ290aWF0aW5nIHNlY3VyaXR5LCBhbmQgcGVyZm9y
bWluZyB1c2VyIGF1dGhlbnRpY2F0aW9uLiBQcm90b2NvbHMgYnVpbGQgb24gYmVlcCBtdXN0IGRl
ZmluZSBhIHByb2ZpbGUgZGV0YWlsaW5nIGhvdyBjb25uZWN0aW9ucyBhcmUgZXN0YWJsaXNoZWQg
YW5kIG11c3QgZGVmaW5lIGEgc2V0IG9mIG1lc3NhZ2VzIHdoaWNoIHdpbGwgYmUgZGVsaXZlcmVk
IHVzaW5nIEJFRVAuIFRoZSBwcm90b2NvbCBpcyBwZWVyLXRvLXBlZXIgYWx0aG91Z2ggY2xpZW50
LXNlcnZlciBzdHlsZSByZXF1ZXN0cyBjb3VsZCBiZSBlYXNpbHkgaGFuZGxlZC4NDVRoZSBmb2xs
b3dpbmcgc3ViLXNlY3Rpb25zIGNvbXBhcmUgZWFjaCBpbmRpdmlkdWFsIHJlcXVpcmVtZW50IGFn
YWluc3QgdGhlIHByb3RvY29sLg1BbmFseXNpcyBvZiBHZW5lcmFsIFJlcXVpcmVtZW50cw1SZXVz
ZSBleGlzdGluZyBwcm90b2NvbHMgWzUuMV0NDVQ6IEJlZXAgaXMgYSBwdWJsaXNoZWQgcHJvdG9j
b2wsIGxpc3RlZCBhcyBSRkMgMzA4MCAoaHR0cDovL3d3dy5pZXRmLm9yZy9yZmMvcmZjMzA4MC50
eHQpLg1NYWludGFpbiBFeGlzdGluZyBQcm90b2NvbCBJbnRlZ3JpdHkgWzUuMl0NDVA6IEJFRVAg
YXNzdW1lcyB0aGF0IHByb3RvY29scywgc3VjaCBhcyBTcGVlY2hTQywgd2lsbCBhZGQgbWVzc2Fn
ZXMuDQ1TdXBwb3J0aW5nIG11bHRpcGxlIGNsaWVudHMgdXNpbmcgVENQIG1heSByZXF1aXJlIHNv
bWUgZWZmb3J0Lg1Bdm9pZCBEdXBsaWNhdGluZyBFeGlzdGluZyBQcm90b2NvbHMgWzUuM10NDVQ6
IEJ1aWxkaW5nIFNwZWVjaFNDIG92ZXIgQkVFUCB3b3VsZCBhbGxvdyB0aGUgc3BlY2lmaWNhdGlv
biB0byBmb2N1cyBvbiBtYW5hZ2luZyB0aGUgQVNSLCBtZWRpYSBzZXJ2ZXIsIGFuZCBTSS9TViBy
ZXNvdXJjZXMgYW5kIHRoZSBwb3NzaWJsZSBpbnRlcmFjdGlvbnMgYmV0d2VlbiB0aGVtLiBUaGUg
b3BlcmF0aW9ucyBmb3IgZXN0YWJsaXNoaW5nIGNvbm5lY3Rpb25zIGFuZCBkZWZpbmluZyBuZXcg
Y2hhbm5lbHMgd291bGQgYmUgaGFuZGxlZCBieSBCRUVQLg1Qcm90b2NvbCBlZmZpY2llbmN5IFs1
LjRdDQ1QKzogQkVFUCBpbXBvc2VzIGEgc21hbGwgb3ZlcmhlYWQgKHJvdWdobHkgNDAgYnl0ZXMg
cGVyIG1lc3NhZ2UpLiBJdCBwcm92aWRlcyBhIG1lY2hhbmlzbSBmb3Igc3VwcG9ydGluZyBtdWx0
aXBsZSBjb21tdW5pY2F0aW9uIGNoYW5uZWxzIG92ZXIgYSBzaW5nbGUgcG9ydC4gSWYgZ3JvdXBp
bmcgb2YgcmVxdWVzdHMgaXMgZGVzaXJlZCwgdGhpcyB3b3VsZCBuZWVkIHRvIGJlIGhhbmRsZWQg
YnkgZ3JvdXBpbmcgdGhlIFNwZWVjaFNDIG1lc3NhZ2VzLg1FeHBsaWNpdCBpbnZvY2F0aW9uIG9m
IHNlcnZpY2VzIFs1LjVdDQ1UOiBUaG91Z2ggaXQgaXMgcHJpbWFyaWx5IGEgcGVlci10by1wZWVy
IHByb3RvY29sLCBCRUVQIG1heSBhY3QgYXMgYSB0cmFkaXRpb25hbCBjbGllbnQgc2VydmVyIHBy
b3RvY29sLg1TZXJ2ZXIgTG9jYXRpb24gYW5kIExvYWQgQmFsYW5jaW5nIFs1LjZdDQ1QKzogVGhp
cyBmdW5jdGlvbmFsaXR5IGlzIG5vdCBwcm92aWRlZCBieSBCRUVQLiBUaGlzIHdvdWxkIG5lZWQg
dG8gYmUgYWRkZWQgYXMgYW4gZXh0ZW5zaW9uLg1TaW11bHRhbmVvdXMgc2VydmljZXMgWzUuN10N
DVQ6IE11bHRpcGxlIGNoYW5uZWxzIHByb3ZpZGluZyBkaWZmZXJlbnQgc2VydmljZXMgaXMgcG9z
c2libGUuIEVhY2ggc2VydmljZSBpcyBzaW1wbHkgYSBtZXNzYWdlIHR5cGUgd2hpY2ggaXMgcGFz
c2VkIHRvIHRoZSBzZXJ2ZXIgdXNpbmcgQkVFUC4NTXVsdGlwbGUgbWVkaWEgc2Vzc2lvbnMgWzUu
OF0NDUY6IEJFRVAgYXNzdW1lcyBhIDE6MSB1c2luZyBUQ1AvSVAuDUFuYWx5c2lzIG9mIER1cGxl
eGluZyBhbmQgUGFyYWxsZWwgT3BlcmF0aW9uIFJlcXVpcmVtZW50cw1EdXBsZXhpbmcgYW5kIFBh
cmFsbGVsIE9wZXJhdGlvbiBSZXF1aXJlbWVudHMgWzldDQ1QKzogUGFyYWxsZWwgb3BlcmF0aW9u
cyBtYXkgYmUgb2J0YWluZWQgdXNpbmcgbXVsdGlwbGUgY2hhbm5lbHMuIEEgbWVzc2FnZSBvbiBv
bmUgY2hhbm5lbCBjb3VsZCBwb3RlbnRpYWxseSBpbnRlcnJ1cHQgYWN0aXZpdHkgaGFwcGVuaW5n
IG9uIHRoZSBzZWNvbmQuIEJFRVAgaXMgdmVyeSBmbGV4aWJsZSBhbGxvd2luZyB0aGUgc2VydmVy
IHRvIGltcGxlbWVudCB3aGF0ZXZlciBiZWhhdmlvciBpcyBkZXNpcmVkLg1GdWxsIER1cGxleCBv
cGVyYXRpb24gWzkuMS4xXQ0NVDogQkVFUCBpcyBhIHBlZXItdG8tcGVlciBwcm90b2NvbCBhbGxv
d2luZyBmdWxsIGR1cGxleCBjb21tdW5pY2F0aW9uIG9uIGEgc2luZ2xlIGNoYW5uZWwgb3IgcGFy
YWxsZWwgY29tbXVuaWNhdGlvbiBvbiBtdWx0aXBsZSBjaGFubmVscy4NTXVsdGlwbGUgc2Vydmlj
ZXMgaW4gcGFyYWxsZWwgWzkuMS4yXQ0NUCs6IE11bHRpcGxlIHNlcnZpY2VzIG1heSBiZSBydW4g
b24gc2VwYXJhdGUgY2hhbm5lbHMuIE1lcmdpbmcgb3IgVC1pbmcgb2YgUlRQIG11c3QgYmUgaW1w
bGVtZW50ZWQgYnkgdGhlIHNlcnZlci4NQ29tYmluYXRpb24gb2Ygc2VydmljZXMNVEJEDUFuYWx5
c2lzIG9mIGFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgKG5vbi1ub3JtYXRpdmUpDVRCRA1BbmFs
eXNpcyBvZiBTZWN1cml0eSBjb25zaWRlcmF0aW9ucw1TZWN1cml0eSBDb25zaWRlcmF0aW9ucyBb
MTFdDQ1QKzogQkVFUCBvZmZlcnMgYSBtZWNoYW5pc20gZm9yIG1hbmFnaW5nIHNlY3VyaXR5IGFu
ZCB1c2VyIGF1dGhlbnRpY2F0aW9uLiANU3BlZWNoU0MgcmVxdWlyZXMgbWFuYWdpbmcgbXVsdGlw
bGUgZGF0YSBzdHJlYW1zIGFuZCBzb21lIGZvcm0gb2YgdW5pZmllZCBhdXRoZW50aWNhdGlvbiAv
IHNlY3VyaXR5IG1pZ2h0IGJlIGEgZ29hbC4gSWYgc28sIEJFRVAgc2VjdXJpdHkgc2hvdWxkIGJl
IHJldmlzaXRlZCB3aXRoIHRoaXMgaW4gbWluZC4NDUludGVyYWN0aW9uIE1vZGVsDVRCQyA6IFRP
IEJFIENPTVBMRVRFRCA6IEFuYWx5c2lzIG9mIHRoZSBpbnRlcmFjdGlvbiBtb2RlbCBvZiB0aGUg
cHJvdG9jb2wgZHVyaW5nIHRoZSCRZGF0YZIgcGhhc2UgKGllIGFmdGVyIHNlc3Npb24gZXN0YWJs
aXNobWVudCkgYW5kIGl0cyBzdWl0YWJpbGl0eSBmb3Igc3BlZWNoc2MuDQ0NU2Vzc2lvbiBDb250
cm9sIDogk1NJUJQgQ29tcGxpZW5jZSBFdmFsdWF0aW9uIChSYWppdiBEaGFybWFkaGlrYXJpKQ1J
bnRyb2R1Y3Rpb24NU0lQIGlzIGEgcHJvdG9jb2wgZm9yIGluaXRpYXRpbmcsIG1vZGlmeWluZywg
YW5kIHRlcm1pbmF0aW5nIG11bHRpbWVkaWEgc2Vzc2lvbnMuIFRoZSBwcm90b2NvbCBpcyBjb25z
aWRlcmVkIGFuIElFVEYgc3RhbmRhcmQgYW5kIGl0cyBzcGVjaWZpY2F0aW9ucyBjYW4gYmUgZm91
bmQgaW4gWzJdLiBUaGUgZm9sbG93aW5nIHNlY3Rpb25zIHByb3ZpZGUgYSBnZW5lcmFsIHN0YXRl
bWVudCB3aXRoIHJlZ2FyZHMgdG8gdGhlIGFwcGxpY2FiaWxpdHkgb2YgU0lQIGFzIHRoZSBjb250
cm9sIHByb3RvY29sIGZvciBTUEVFQ0hTQy4gDQ1TSVAgR2VuZXJhbCBBcHBsaWNhYmlsaXR5DVNJ
UCBpcyBhIHByZXR0eSBtYXR1cmUsIHdlbGwgdW5kZXJzdG9vZCwgYW5kIGZyZXF1ZW50bHkgdXNl
ZCAgc2Vzc2lvbiBlc3RhYmxpc2htZW50IHByb3RvY29sLiBJdCBoYXMgZ29uZSB0aHJvdWdoIG11
bHRpcGxlIHJldmlzaW9ucyBpbiB0aGUgSUVURiBzdGFuZGFyZCBwcm9jZXNzLiBUaGVyZSBhcmUg
bnVtYmVyIG9mIGNvbW1lcmNpYWwgYW5kIHB1YmxpYyBkb21haW4gaW1wbGVtZW50YXRpb25zIG9m
IFNJUCB0aGF0IGFyZSBhdmFpbGFibGUuIEJlY2F1c2Ugb2YgaXRzIGNsb3NlIHJlc2VtYmxhbmNl
IHRvIEhUVFAgYW5kIGJlaW5nIGEgdGV4dCBiYXNlZCBwcm90b2NvbCwgdGhlcmUgYXJlIGxhcmdl
IG51bWJlciBvZiBTSVAgYXBwbGljYXRpb24gZGV2ZWxvcGVycyBhdmFpbGFibGUuIA0NU0lQIFVz
ZSBpbiBWT0lQIGVudmlyb25tZW50DVNJUCBpcyBhbHJlYWR5IGJlaW5nIHVzZWQgdG8gZXN0YWJs
aXNoIGFuZCByZWRpcmVjdCBSVFAgc3RyZWFtcyBmcm9tIHZhcmlvdXMgZW5kIHBvaW50cy4gVGhl
IFNQRUVDSFNDIHJlcXVpcmVzIGEgcHJvdG9jb2wgZm9yIGNvbnRyb2xsaW5nIEFTUiwgVFRTIGFu
ZCBTViByZXNvdXJjZXMuIFdoZW4gdGhlc2UgcmVzb3VyY2VzIGFyZSBkZXBsb3llZCBpbiBhIFZP
SVAgbmV0d29yayB0aGF0IHJlcXVpcmVzIHRoZW0gdG8gcHJvY2VzcyBtZWRpYSBjYXJyaWVkIGlu
IFJUUCwgdGhlIFNJUCBwcm90b2NvbCBpcyB1c2VkIGluIGxvdCBvZiBkZXBsb3ltZW50cy4gUmF0
aGVyIHRoYW4gaW52ZW50aW5nIGEgbmV3IGNvbnRyb2wgcHJvdG9jb2wgYW5kIGludHJvZHVjaW5n
IG9wZXJhdGlvbmFsIGFzcGVjdHMgb2YgdGhlIG5ldyBwcm90b2NvbCwgU0lQIGNhbiBiZSByZXVz
ZWQgZm9yIGNvbnRyb2xsaW5nIFNQRUVDSFNDIHJlc291cmNlcy4gDQ1BbmFseXNpcyBvZiBHZW5l
cmFsIFJlcXVpcmVtZW50cw1SZXVzZSBleGlzdGluZyBwcm90b2NvbHMgWzUuMV0NVDogU0lQIGlz
IGFuIGV4aXN0aW5nLCB3aWRlbHkgdXNlZCwgYW5kIG1hdHVyZSBwcm90b2NvbCBkZWZpbmVkIGlu
IFsyXS4NTWFpbnRhaW4gRXhpc3RpbmcgUHJvdG9jb2wgSW50ZWdyaXR5IFs1LjJdDVQ6IEV4aXN0
aW5nIFNJUCBtZXRob2RzIGFuZCBoZWFkZXIgZmllbGRzIHdpbGwgbm90IGJlIGNoYW5nZWQgd2hl
biBTSVAgaXMgdXNlZCB0byBjb250cm9sIFNQRUVDSFNDIHJlc291cmNlcy4gSW4gY2FzZSwgaWYg
ZXh0ZW5zaW9ucyBhcmUgcmVxdWlyZWQsIFNJUCBhbGxvd3MgY2FycmlhZ2Ugb2YgY3VzdG9tIHBh
eWxvYWQgaW4gdGhlIGJvZHkuIFRoaXMgcGF5bG9hZCBpcyB1bmRlcnN0b29kIG9ubHkgYnkgVUFz
IGFuZCBpdCBkb2VzIG5vdCBpbXBhY3QgcHJvdG9jb2wgaW50ZWdyaXR5Lg0NQXZvaWQgRHVwbGlj
YXRpbmcgRXhpc3RpbmcgUHJvdG9jb2xzIFs1LjNdDVQ6IExvdCBvZiB0aGUgcmVxdWlyZW1lbnRz
IGZvciBTUEVFQ0hTQyBvcGVyYXRpb24gY2FuIGVhc2lseSBiZSBzYXRpc2ZpZWQgYnkgU0lQLCBl
LmcuIGVzdGFibGlzaGluZyBSVFAgc3RyZWFtcyBvciByZWRpcmVjdGluZyB0aGVtLiBXaXRob3V0
IFNJUCwgbmV3IFNQRUVDSFNDIHByb3RvY29sIHdpbGwgaGF2ZSB0byBkdXBsaWNhdGUgbG90IG9m
IHNlc3Npb24gbWFuYWdlbWVudCBmdW5jdGlvbmFsaXR5Lg0NUHJvdG9jb2wgZWZmaWNpZW5jeSBb
NS40XQ1UOiBTSVAgaXMgYSB2ZXJ5IGxpZ2h0d2VpZ2h0IHByb3RvY29sIHdoZW4gcnVuIG92ZXIg
VENQIG9yIFVEUC4gSXQgbGV2ZXJhZ2VzIGVmZmljaWVuY3kgYXZhaWxhYmxlIGluIFRDUCBhbmQg
VURQIHByb3RvY29scyB0aGF0IGhhdmUgYmVlbiBhcm91bmQgZm9yIG92ZXIgMjAgeWVhcnMuDUV4
cGxpY2l0IGludm9jYXRpb24gb2Ygc2VydmljZXMgWzUuNV0NVDogU0lQIFVSSSBtZWNoYW5pc20g
YWxsb3dzIGludm9jYXRpb24gb2YgZGlmZmVyZW50IHNlcnZpY2VzLg1TZXJ2ZXIgTG9jYXRpb24g
YW5kIExvYWQgQmFsYW5jaW5nIFs1LjZdDVArOiBTSVAgZW1wbG95cyBzdGFuZGFyZCBETlMgbmFt
ZSByZXNvbHV0aW9uIGZvciBsb2NhdGluZyByZXNvdXJjZXMuIFNJUCBpdHNlbGYgZG9lcyBub3Qg
cHJvdmlkZSBsb2FkIGJhbGFuY2luZyBmZWF0dXJlcy4gQXBwbGljYXRpb24gbGV2ZWwgbG9hZCBi
YWxhbmNlcnMgY2FuIGJlIHVzZWQgdG8gbG9hZCBiYWxhbmNlIFNJUCByZXF1ZXN0cy4NDVNpbXVs
dGFuZW91cyBzZXJ2aWNlcyBbNS43XQ1UOiBTSVAgYWxsb3dzIHNpbXVsdGFuZW91cyBpbnZvY2F0
aW9uIG9mIGRpZmZlcmVudCBzZXJ2aWNlcy4gU0lQIGFsbG93cyBmb3JraW5nIG9yIHNwbGl0dGlu
ZyB0aGUgc2FtZSBtZWRpYSBzdHJlYW0gdG8gZGlmZmVyZW50IGVuZCBwb2ludHMgYXMgZGVmaW5l
ZCBpbiBbMl0uDQ1NdWx0aXBsZSBtZWRpYSBzZXNzaW9ucyBbNS44XQ1UOiBTSVAgdXNlcyBTRFAg
dG8gZGVzY3JpYmUgUlRQIHN0cmVhbSBjaGFyYWN0ZXJpc3RpY3MuIFRoaXMgYWxsb3dzIHRoZSBj
b250cm9sIG9mIGRpcmVjdGlvbiBvZiBSVFAgc3RyZWFtIHN1Y2ggYXMgYmktZGlyZWN0aW9uYWwg
b3IgdW5pLWRpcmVjdGlvbmFsLiBTSVAgYWxsb3dzIGEgVUEgdG8gZXN0YWJsaXNoIHNlc3Npb25z
IHdpdGggbXVsdGlwbGUgVUFzIGZvciB0aGUgc2FtZSBzZXNzaW9uLg0NQW5hbHlzaXMgb2YgRHVw
bGV4aW5nIGFuZCBQYXJhbGxlbCBPcGVyYXRpb24gUmVxdWlyZW1lbnRzDUR1cGxleGluZyBhbmQg
UGFyYWxsZWwgT3BlcmF0aW9uIFJlcXVpcmVtZW50cyBbOV0NVDogU1BFRUNIU0MgcmVzb3VyY2Ug
aXMgYSBTSVAgVUEgdGhhdCBjYW4gaGFuZGxlIHNlc3Npb24gcmVxdWVzdHMgZnJvbSBkaWZmZXJl
bnQgVUFzLg1GdWxsIER1cGxleCBvcGVyYXRpb24gWzkuMS4xXQ1UOiBFYWNoIFNJUCBVQSBjb25z
aXN0cyBvZiBhIFVBQyBhbmQgYSBVQVMuIFRoaXMgYWxsb3dzIGZvciBmdWxsIGR1cGxleCBvcGVy
YXRpb24uDU11bHRpcGxlIHNlcnZpY2VzIGluIHBhcmFsbGVsIFs5LjEuMl0NVDogU0lQIGFsbG93
cyBzaW11bHRhbmVvdXMgaW52b2NhdGlvbiBvZiBkaWZmZXJlbnQgc2VydmljZXMuIFNJUCBhbGxv
d3MgZm9ya2luZyBvciBzcGxpdHRpbmcgdGhlIHNhbWUgbWVkaWEgc3RyZWFtIHRvIGRpZmZlcmVu
dCBlbmQgcG9pbnRzIGFzIGRlZmluZWQgaW4gWzJdLg0NQ29tYmluYXRpb24gb2Ygc2VydmljZXMN
VDogU2VlIDUuNi4zLiBTSVAgVUEgY2FuIGludm9rZSBkaWZmZXJlbnQgc2VydmljZXMgYW5kIGNv
bWJpbmUgdGhlIHJlc3VsdHMuDUFuYWx5c2lzIG9mIGFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMg
KG5vbi1ub3JtYXRpdmUpDVRCRA1BbmFseXNpcyBvZiBTZWN1cml0eSBjb25zaWRlcmF0aW9ucw1T
ZWN1cml0eSBDb25zaWRlcmF0aW9ucyBbMTFdDVQ6IFNJUCBwcm90b2NvbCBlbXBsb3lzIGRpZmZl
cmVudCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIHRoYXQgYXJlIHdpZGVseSB1c2VkIGluIElQIGJh
c2VkIHByb3RvY29scy4NT3RoZXIgQ3JpdGVyaWENVGhlIGZvbGxvd2luZyBjcml0ZXJpYSB3ZXJl
IGFsc28gZGVmaW5lZCBieSB0aGUgZXZhbHVhdG9yIG9mIFNJUC4NQWJpbGl0eSB0byBlc3RhYmxp
c2ggc2Vzc2lvbiBiZXR3ZWVuIFNQRUVDSFNDIGNsaWVudCBhbmQgU1BFRUNIU0MgcmVzb3VyY2UN
VDogU0lQIFVzZXIgQWdlbnQgY2FuIGVzdGFibGlzaCBhIHNlc3Npb24gd2l0aCBhbm90aGVyIFNJ
UCBVc2VyIEFnZW50Lg1BYmlsaXR5IHRvIHRlcm1pbmF0ZSBzZXNzaW9uIGJ5IGVpdGhlciBTUEVF
Q0hTQyBjbGllbnQgb3IgU1BFRUNIU0MgcmVzb3VyY2UNVDogU0lQIFVzZXIgQWdlbnQgY2FuIHRl
cm1pbmF0ZSBhIHNlc3Npb24gd2l0aCBhbm90aGVyIFNJUCBVc2VyIEFnZW50Lg1TdXBwb3J0IHJl
bGlhYmxlIHNlcXVlbmNpbmcgYW5kIGRlbGl2ZXJ5IGJldHdlZW4gU1BFRUNIU0MgY2xpZW50IGFu
ZCBTUEVFQ0hTQyByZXNvdXJjZQ1QOiBTSVAgY2FuIGJlIHJ1biBvdmVyIFRDUCBvciBVRFAuIFdo
ZW4gcnVuIG92ZXIgVENQLCB0aGlzIHJlcXVpcmVtZW50IGlzIGVhc2lseSBzYXRpc2ZpZWQuIFdo
ZW4gcnVuIG92ZXIgVURQLCBTSVAgVXNlciBBZ2VudCBpcyByZXF1aXJlZCB0byBpbXBsZW1lbnQg
bG9naWMgdG8gZW5zdXJlIHJlbGlhYmxlIHNlcXVlbmNpbmcgYW5kIGRlbGl2ZXJ5LiANQWJpbGl0
eSBmb3IgU1BFRUNIU0MgY2xpZW50IHRvIGNvb3JkaW5hdGUgU1BFRUNIU0MgcmVzb3VyY2VzIG9u
IGRpZmZlcmVudCBtYWNoaW5lcyBmb3IgYSBzaW5nbGUgc2Vzc2lvbg1UOiBTUEVFQ0hTQyBjbGll
bnQgY2FuIHVzZSBTSVAgdG8gZXN0YWJsaXNoIFNJUCBzZXNzaW9ucyB3aXRoIGRpZmZlcmVudCBt
YWNoaW5lcy4NQWJpbGl0eSBmb3IgU1BFRUNIU0MgcmVzb3VyY2UgdG8gaGFuZGxlIG11bHRpcGxl
IFNQRUVDSFNDIGNsaWVudHMNVDogU1BFRUNIU0MgcmVzb3VyY2UgaXMgYSBTSVAgVUEgdGhhdCBj
YW4gaGFuZGxlIHNlc3Npb24gcmVxdWVzdHMgZnJvbSBkaWZmZXJlbnQgVUFzLg1UaGUgU1BFRUNI
U0MgcmVzb3VyY2Ugc2hvdWxkIGJlIGFibGUgdG8gZ2VuZXJhdGUgYXN5bmNocm9ub3VzIGV2ZW50
cyBvciB1bnNvbGljaXRlZCBtZXNzYWdlcw1UOiBTSVAgYWxsb3dzIGFzeW5jaHJvbm91cyBldmVu
dHMgb3IgdW5zb2xpY2l0ZWQgbWVzc2FnZXMgdG8gYmUgZ2VuZXJhdGVkIHVzaW5nIFNVQlNDUklC
RS9OT1RJRlkgbWVjaGFuaXNtLg1UaGUgU1BFRUNIU0MgY2xpZW50IGFuZCByZXNvdXJjZSBzaG91
bGQgaGF2ZSBhYmlsaXR5IGZvciBhdXRoZW50aWNhdGluZyBlYWNoIG90aGVyDVQ6IFNJUCBwcm90
b2NvbCBlbXBsb3lzIGRpZmZlcmVudCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIHRoYXQgYXJlIHdp
ZGVseSB1c2VkIGluIElQIGJhc2VkIHByb3RvY29scy4NQWJpbGl0eSB0byBkZXRlcm1pbmUgc3Vj
Y2VzcyBvciBmYWlsdXJlIGZyb20gYm90aCBTUEVFQ0hTQyBjbGllbnQgYW5kIFNQRUVDSFNDIHJl
c291cmNlIHNpZGUNVDogVGhlIHByb3RvY29sIGhhcyBmb2xsb3dpbmcgcmVzcG9uc2UgY29kZXM6
IDIwMCBmb3Igc3VjY2VzcywgM3h4LCA0eHgsIGFuZCA1eHggZm9yIGZhaWx1cmUuDVN1cHBvcnQg
Zm9yIHZlcnNpb25pbmcgYmV0d2VlbiBTUEVFQ0hTQyBjbGllbnQgYW5kIFNQRUVDSFNDIHJlc291
cmNlDVArOiBUaGlzIHdpbGwgcmVxdWlyZSBhbiBhZGRpdGlvbmFsIGhlYWRlciBvciBlbGVtZW50
IGluIHRoZSAgICBib2R5IG9mIFNJUCBtZXNzYWdlIGZvciB2ZXJzaW9uaW5nLiBUaGUgY3VycmVu
dCB2ZXJzaW9uIGZpZWxkIGlzIGludGVuZGVkIGZvciBTSVAgcHJvdG9jb2wgdmVyc2lvbi4gDQ1J
bnRlcmFjdGlvbiBNb2RlbA0NU3BlZWNoc2MgaGFzIGNlcnRhaW4gbmVlZHMgcmVsYXRlZCB0byB0
aGUgaW50ZXJhY3Rpb24gbW9kZWwgb2YgdGhlIHByb3RvY29sIGR1cmluZyB0aGUgkWRhdGGSIHBo
YXNlIChpZSBhZnRlciBzZXNzaW9uIGVzdGFibGlzaG1lbnQpLiBTcGVjaWZpY2FsbHksIHNwZWVj
aHNjIHdpbGwgcmVxdWlyZSB0aGF0IHRoZSByZXNvdXJjZSBzZXJ2ZXIgY2FuIHNlbmQgdW5zb2xp
Y2l0ZWQgbWVzc2FnZXMvdHJhbnNhY3Rpb25zIHRvIHRoZSByZXNvdXJjZSBjbGllbnQgdG8gcmV0
dXJuIHJlc3VsdHMgYW5kIGluZGljYXRlIGV2ZW50cy4LDVNJUCBtZXNzYWdlcyBpbiB0aGUgZGF0
YSBwaGFzZSBjYW4gZmxvdyBpbiBib3RoIGRpcmVjdGlvbnMgKGNsaWVudCB0byBzZXJ2ZXIgYXMg
d2VsbCBhcyBzZXJ2ZXIgdG8gY2xpZW50KS4gU0lQIElORk8gbWVzc2FnZSBjYW4gYmUgdXNlZCBm
b3IgdGhpcyBwdXJwb3NlLiBUaGUgU0lQIElORk8gaXMgaW50ZW5kZWQgZm9yIG1pZC1jYWxsIG1l
c3NhZ2Ugc2VtYW50aWNzLiBXaXRoIHRoaXMgbWVzc2FnZSwgdHJhbnNhY3Rpb25zIGNhbiBiZSBp
bml0aWF0ZWQvZGVmaW5lZCBieSBib3RoIGVuZHMuIA0NU0lQIHRoZXJlZm9yZSBoYXMgYW4gaW50
ZXJhY3Rpb24gbW9kZWwgc3VpdGVkIHRvIHRoZSBzcGVlY2hzYyBtb2RlbCwgd2hpY2ggc3VwcG9y
dHMgcGVlci1wZWVyIG1lc3NhZ2luZyB3aXRoIGEgYmFzaWMgdHJhbnNhY3Rpb25hbCBzeW1tZXRy
aWNhbCByZXF1ZXN0L3Jlc3BvbnNlIG1vZGVsLg0NU2Vzc2lvbiBDb250cm9sIDogk1JUU1CUIENv
bXBsaWVuY2UgRXZhbHVhdGlvbiAoQnJpYW4gV3lsZCkNR2VuZXJhbCBJbnRyb2R1Y3Rpb24NUlRT
UCBpcyBhbiBleGlzdGluZyBwcm90b2NvbCwgb3JpZW50YXRlZCB0b3dhcmRzIGF1ZGlvIHBsYXli
YWNrIGFuZCByZWNvcmRpbmcuIEFzIHN1Y2gsIGl0IGhhcyBzdXBwb3J0IGZvciBSVFAgc2Vzc2lv
biBjb250cm9sLCB3aXRoIFNEUCB1c2VkIGZvciBzZXNzaW9uIGRlc2NyaXB0aW9uLCBhbmQgYSBt
ZXNzYWdlIHNldCBhbGxvd2luZyBvcGVyYXRpb24gYXMgYSBwbGF5ZXIvcmVjb3JkZXIgd2l0aCBh
dWRpbyCTVkNSlCBjb250cm9scy4NDU9ubHkgdGhlIHNlc3Npb24gY29udHJvbCBpcyBldmFsdWF0
ZWQgaGVyZSAoc2VlIGxhdGVyIHNlY3Rpb24gZm9yIGV2YWx1YXRpb24gb2YgdGhlIHJlc291cmNl
IGNvbnRyb2wgZWxlbWVudHMpDQ1UaGUgZm9sbG93aW5nIHN1Yi1zZWN0aW9ucyBjb21wYXJlIGVh
Y2ggaW5kaXZpZHVhbCByZXF1aXJlbWVudCBhZ2FpbnN0IHRoZSBwcm90b2NvbC4NQW5hbHlzaXMg
b2YgR2VuZXJhbCBSZXF1aXJlbWVudHMNUmV1c2UgZXhpc3RpbmcgcHJvdG9jb2xzIFs1LjFdDVQ6
IFJUU1AvUlRQL1NEUCB3b3VsZCBiZSByZXVzZWQuDU1haW50YWluIEV4aXN0aW5nIFByb3RvY29s
IEludGVncml0eSBbNS4yXQ1UOiBUaGUgZXh0ZW5zaW9ucyB0byBSVFNQIHRvIGFsbG93IHNwZWVj
aHNjIHVzZSB3b3VsZCBiZSBpbiB0aGUgc3Bpcml0IG9mIHRoZSBwcm90b2NvbCwgYW5kIHdvdWxk
IG5vdCBicmVhayBleGlzdGluZyBzZXJ2ZXJzIG9yIGNsaWVudHMuDUF2b2lkIER1cGxpY2F0aW5n
IEV4aXN0aW5nIFByb3RvY29scyBbNS4zXQ1UOiBVc2luZyBSVFNQIHdvdWxkIG5vdCByZWNyZWF0
ZSBpdC4NUHJvdG9jb2wgZWZmaWNpZW5jeSBbNS40XQ1UOiBSVFNQIGlzIGEgdGV4dCBiYXNlZCBw
cm90b2NvbCwgYnV0IGlzIHJlbGF0aXZlbHkgc3VjY2luY3QgYXMgbWVzc2FnZXMgYXJlIHNwZWNp
ZmljIHRvIHRoZWlyIG9wZXJhdGlvbi4NRXhwbGljaXQgaW52b2NhdGlvbiBvZiBzZXJ2aWNlcyBb
NS41XQ1UOiBSVFNQIHNlcnZpY2UgaW52b2NhdGlvbiBpcyBzdWZmaWNpZW50Lg1TZXJ2ZXIgTG9j
YXRpb24gYW5kIExvYWQgQmFsYW5jaW5nIFs1LjZdDUY6IFJUU1AgZG9lcyBub3QgYWRkcmVzcyB0
aGlzIHRvcGljOyBob3dldmVyIGl0IGNhbiBiZSB1c2VkIHdpdGggb3RoZXIgSUVURiBwcm90b2Nv
bHMgc3VjaCBhcyBTTFAgb3IgVURESSB0byBkbyBzby4NU2ltdWx0YW5lb3VzIHNlcnZpY2VzIFs1
LjddDVQ6IFJUU1AgYWxsb3dzIHNpbXVsdGFuZW91cyBpbnZvY2F0aW9uIG9mIHNlcnZpY2VzIG9u
IHRoZSBzYW1lIG9yIGRpZmZlcmVudCBjb250cm9sIGNoYW5uZWwuDU11bHRpcGxlIG1lZGlhIHNl
c3Npb25zIFs1LjhdDVQ6IFJUU1AgYWxsb3dzIG11bHRpcGxlIG1lZGlhIHNlc3Npb25zLg1BbmFs
eXNpcyBvZiBEdXBsZXhpbmcgYW5kIFBhcmFsbGVsIE9wZXJhdGlvbiBSZXF1aXJlbWVudHMNRHVw
bGV4aW5nIGFuZCBQYXJhbGxlbCBPcGVyYXRpb24gUmVxdWlyZW1lbnRzIFs5XQ1UOiBSVFNQIGFs
bG93cyBzZXNzaW9uIHNldHVwIHRoYXQgc2hvdWxkIGZ1bGZpbGwgdGhlc2UgcmVxdWlyZW1lbnRz
Lg1GdWxsIER1cGxleCBvcGVyYXRpb24gWzkuMS4xXQ1UOiBSVFNQIGNhbiBjcmVhdGUgYSBmdWxs
IGR1cGxleCBzZXNzaW9uLg1NdWx0aXBsZSBzZXJ2aWNlcyBpbiBwYXJhbGxlbCBbOS4xLjJdDVQ6
IFJUU1AgY2FuIHJlcXVlc3QgbXVsdGlwbGUgb3BlcmF0aW9ucyBvZiB0aGUgc2FtZSB0eXBlIG9u
IHRoZSBzYW1lIHNlc3Npb24uDUNvbWJpbmF0aW9uIG9mIHNlcnZpY2VzDVQ6IFJUU1AgY2FuIHJl
cXVlc3QgbXVsdGlwbGUgb3BlcmF0aW9ucyBvZiBkaWZmZXJlbnQgdHlwZXMgb24gdGhlIHNhbWUg
c2Vzc2lvbi4NQW5hbHlzaXMgb2YgYWRkaXRpb25hbCBjb25zaWRlcmF0aW9ucyAobm9uLW5vcm1h
dGl2ZSkNVEJEDUFuYWx5c2lzIG9mIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zDVNlY3VyaXR5IENv
bnNpZGVyYXRpb25zIFsxMV0NRjogUlRTUCBwcm92aWRlcyBubyBzcGVjaWZpYyBzZWN1cml0eSBm
dW5jdGlvbmFsaXR5IGF0IGFsbCwgYnV0IGRlcGVuZHMgb24gb3RoZXIgSUVURiBzZWN1cml0eSBw
cm90b2NvbHMgKGFzIGl0IHVzZXMgVENQKSB0byBwcmUtdmFsaWRhdGUgYW5kIHByb3RlY3QgdGhl
IHNlc3Npb25zLg1JbnRlcmFjdGlvbiBNb2RlbA1TcGVlY2hzYyBoYXMgY2VydGFpbiBuZWVkcyBy
ZWxhdGVkIHRvIHRoZSBpbnRlcmFjdGlvbiBtb2RlbCBvZiB0aGUgcHJvdG9jb2wgZHVyaW5nIHRo
ZSCRZGF0YZIgcGhhc2UgKGllIGFmdGVyIHNlc3Npb24gZXN0YWJsaXNobWVudCkuIFNwZWNpZmlj
YWxseSwgc3BlZWNoc2Mgd2lsbCByZXF1aXJlIHRoYXQgdGhlIHJlc291cmNlIHNlcnZlciBjYW4g
c2VuZCB1bnNvbGljaXRlZCBtZXNzYWdlcy90cmFuc2FjdGlvbnMgdG8gdGhlIHJlc291cmNlIGNs
aWVudCB0byByZXR1cm4gcmVzdWx0cyBhbmQgaW5kaWNhdGUgZXZlbnRzLgsNUlRTUCBtZXNzYWdl
cyBpbiB0aGUgZGF0YSBwaGFzZSBjYW4gZmxvdyBpbiBib3RoIGRpcmVjdGlvbnMgKGNsaWVudCB0
byBzZXJ2ZXIgYXMgd2VsbCBhcyBzZXJ2ZXIgdG8gY2xpZW50KS4gVHJhbnNhY3Rpb25zIGNhbiBi
ZSBpbml0aWF0ZWQvZGVmaW5lZCBieSBib3RoIGVuZHMuIEN1cnJlbnRseSBtb3N0IG9mIHRoZSBk
ZWZpbmVkIHRyYW5zYWN0aW9ucyBhcmUgQy1TOyBob3dldmVyIHRoZXJlIGFscmVhZHkgZXhpc3Rz
IGFuIEFOTk9VTkNFIG1lc3NhZ2UgdHJhbnNhY3Rpb24gdGhhdCBpcyB1c2VkIHRvIHRyYW5zaXQg
Z2VuZXJhbCBjb250ZW50IGluIGJvdGggZGlyZWN0aW9ucyAoYW5kIGlzIGluIGZhY3QgdXNlZCBi
eSBNUkNQIHRvIHRyYW5zcG9ydCBpdHMgcmVzb3VyY2UgY29udHJvbCBtZXNzYWdlcykuDQ1SVFNQ
IGhhcyB0aGVyZWZvcmUgYW4gaW50ZXJhY3Rpb24gbW9kZWwgc3VpdGVkIHRvIHRoZSBzcGVlY2hz
YyBtb2RlbCwgd2hpY2ggc3VwcG9ydHMgcGVlci1wZWVyIG1lc3NhZ2luZyB3aXRoIGEgYmFzaWMg
dHJhbnNhY3Rpb25hbCBzeW1tZXRyaWNhbCByZXF1ZXN0L3Jlc3BvbnNlIG1vZGVsLg0NU2Vzc2lv
biBDb250cm9sIDogk1dlYiBTZXJ2aWNlc5QgQ29tcGxpZW5jZSBFdmFsdWF0aW9uIChTdGVwaGFu
ZSBILiBNYWVzKQ1HZW5lcmFsIE5vdGVzOg1TcGVlY2ggZW5naW5lcyAoc3BlZWNoIHJlY29nbml0
aW9uLCBzcGVha2VyLCByZWNvZ25pdGlvbiwgc3BlZWNoIA1zeW50aGVzaXMsIHJlY29yZGVycyBh
bmQgcGxheWJhY2ssIE5MIHBhcnNlcnMsIGFuZCBhbnkgb3RoZXIgc3BlZWNoDXByb2Nlc3Npbmcg
ZW5naW5lcyAoZS5nLiBzcGVlY2ggZGV0ZWN0aW9uLCBiYXJnZS1pbiBkZXRlY3Rpb24gZXRjKSAN
ZXRjLi4uKSBhcyB3ZWxsIGFzIGF1ZGlvIHN1Yi1zeXN0ZW1zIChhdWRpbyBpbnB1dCBhbmQgb3V0
cHV0IA1zdWItc3lzdGVtcykgY2FuIGJlIGNvbnNpZGVyZWQgYXMgd2ViIHNlcnZpY2VzIHRoYXQg
Y2FuIGJlIA1kZXNjcmliZWQgYW5kIGFzeW5jaHJvbm91c2x5IHByb2dyYW1tZWQgdmlhIFdTREwg
KG9uIHRvcCBvZiBTT0FQKSwgDWNvbWJpbmVkIGluIGEgZmxvdyBkZXNjcmliZWQgdmlhIFdTRkws
IGRpc2NvdmVyZWQgdmlhIFVEREkgYW5kIA1hc3luY2hyb25vdXNseSBjb250cm9sbGVkIHZpYSBT
T0FQIHRoYXQgYWxzbyBlbmFibGVzIA1hc3luY2hyb25vdXMgZXhjaGFuZ2VzIGJldHdlZW4gdGhl
IGVuZ2luZXMuDaANVGhpcyBzb2x1dGlvbiBwcmVzZW50cyB0aGUgYWR2YW50YWdlIHRvIHByb3Zp
ZGUgZmxleGliaWxpdHksIA1zY2FsYWJpbGl0eSBhbmQgZXh0ZW5zaWJpbGl0eSB3aGlsZSByZXVz
aW5nIGFuIGV4aXN0aW5nIGZyYW1ld29yayANdGhhdCBmaXRzIHRoZSBldm9sdXRpb24gb2YgdGhl
IHdlYjogd2ViIHNlcnZpY2VzIGFuZCBYTUwgcHJvdG9jb2xzIFtXUzFdDQ1BY2NvcmRpbmcgdG8g
dGhlIHdlYiBzZXJ2aWNlcyBmcmFtZXdvcmssIHNwZWVjaCBlbmdpbmVzIChhdWRpbyANc3ViLXN5
c3RlbXMsIGVuZ2luZXMsIHNwZWVjaCBwcm9jZXNzb3JzKSBjYW4gYmUgZGVmaW5lZCBhcyB3ZWIg
c2VydmljZXMNdGhhdCBhcmUgY2hhcmFjdGVyaXplZCBieSBhbiBpbnRlcmZhY2UgdGhhdCBjb25z
aXN0cyBvZiBzb21lIG9mIHRoZSANZm9sbG93aW5nIHBvcnRzOg0gICAgLSAiY29udHJvbCBpbiIg
cG9ydChzKTogSXQgc2V0cyB0aGUgZW5naW5lIGNvbnRleHQsIGkuZS4gYWxsIHRoZQ0gICAgc2V0
dGluZ3MgcmVxdWlyZWQgZm9yIGEgc3BlZWNoIGVuZ2luZSB0byBydW4uIEl0IG1heSBpbmNsdWRl
IA0gICAgYWRkcmVzc2VzIHdoZXJlIHRvIGdldCBvciBzZW5kIHRoZSBzdHJlYW1lZCBhdWRpbyBv
ciByZXN1bHRzLg0gICAgLSAiY29udHJvbCBvdXQiIHBvcnQocyk6IEl0IHByb2R1Y2VzIHRoZSBu
b24tYXVkaW8gZW5naW5lIG91dHB1dA0gICAgKGkuZS4gcmVzdWx0cyBhbmQgZXZlbnRzKS4gSXQg
bWF5IGFsc28gaW52b2x2ZSBzb21lIHNlc3Npb24gDSAgICBjb250cm9sIGV4Y2hhbmdlcy4NICAg
IC0gImF1ZGlvIGluIiBwb3J0KHMpOiBJdCByZWNlaXZlcyBzdHJlYW1lZCBpbnB1dCBkYXRhLiAN
ICAgIC0gImF1ZGlvIG91dCIgcG9ydChzKTogSXQgcHJvZHVjZXMgc3RyZWFtZWQgb3V0cHV0IGRh
dGEuIA0NQXVkaW8gc3ViLXN5c3RlbXMgY2FuIGFsc28gYmUgdHJlYXRlZCBhcyB3ZWIgc2Vydmlj
ZXMgdGhhdCBjYW4gDXByb2R1Y2Ugc3RyZWFtZWQgZGF0YSBvciBwbGF5IGluY29taW5nIHN0cmVh
bWVkIGRhdGEgYXMgc3BlY2lmaWVkIGJ5DXRoZSBjb250cm9sIHBhcmFtZXRlcnMuDQ1UaGUgImNv
bnRyb2wgaW4iIG9yICJjb250cm9sIG91dCIgbWVzc2FnZXMgY2FuIGJlIG91dC1vZi1iYW5kIG9y
IA1zZW50IG9yIHJlY2VpdmVkIGludGVybGVhdmVkIHdpdGggImF1ZGlvIGluIG9yIG91dCIgZGF0
YS4gVGhpcyBjYW4gDWJlIGRldGVybWluZWQgaW4gdGhlIGNvbnRleHQgKHNldHVwKSBvZiB0aGUg
d2ViIHNlcnZpY2VzLiANDVNwZWVjaCBlbmdpbmVzIGFuZCBhdWRpbyBzdWItc3lzdGVtcyBhcmUg
cHJlLXByb2dyYW1tZWQgYXMgd2ViIA1zZXJ2aWNlcyBhbmQgY29tcG9zZWQgaW50byBtb3JlIGFk
dmFuY2VkIHNlcnZpY2VzLiBPbmNlIHByb2dyYW1tZWQgDWJ5IHRoZSBhcHBsaWNhdGlvbiAvIGNv
bnRyb2xsZXIsIGF1ZGlvLXN1Yi1zeXN0ZW1zIGFuZCBlbmdpbmVzIGF3YWl0DWFuIGluY29taW5n
IGV2ZW50IChlc3RhYmxpc2hlZCBhdWRpbyBzZXNzaW9uLCBldGMuLi4pIHRvIGV4ZWN1dGUgdGhl
DXNwZWVjaCBwcm9jZXNzaW5nIHRoYXQgdGhleSBoYXZlIGJlZW4gcHJvZ3JhbW1lZCB0byBkbyBh
bmQgc2VuZCB0aGUgDXJlc3VsdHMgYXMgcHJvZ3JhbW1lZC4gDQ1TcGVlY2ggZW5naW5lcyBhcyB3
ZWIgc2VydmljZXMgYXJlIHR5cGljYWxseSBwcm9ncmFtbWVkIHRvIGhhbmRsZSANY29tcGxldGVs
eSBhIHBhcnRpY3VsYXIgc3BlZWNoIHByb2Nlc3NpbmcgdGFzaywgaW5jbHVkaW5nIGhhbmRsaW5n
IA1vZiBwb3NzaWJsZSBlcnJvcnMuIEZvciBleGFtcGxlLCBhcyBzcGVlY2ggZW5naW5lIGlzIHBy
b2dyYW1tZWQgdG8gDXBlcmZvcm0gcmVjb2duaXRpb24gb2YgdGhlIG5leHQgaW5jb21pbmcgdXR0
ZXJhbmNlIHdpdGggYSBwYXJ0aWN1bGFyDWdyYW1tYXIsIHRvIHNlbmQgcmVzdWx0IHRvIGEgTkwg
cGFyc2VyIGFuZCB0byBjb250YWN0IGEgcGFydGljdWxhciANZXJyb3IgcmVjb3ZlcnkgcHJvY2Vz
cyBpZiBwYXJ0aWN1bGFyIGVycm9ycyBvY2N1ci4NDVRoZSBmb2xsb3dpbmcgc3ViLXNlY3Rpb25z
IGNvbXBhcmUgZWFjaCBpbmRpdmlkdWFsIHJlcXVpcmVtZW50IGFnYWluc3QgdGhlIHByb3RvY29s
Lg1BbmFseXNpcyBvZiBHZW5lcmFsIFJlcXVpcmVtZW50cw1SZXVzZSBleGlzdGluZyBwcm90b2Nv
bHMgWzUuMV0NVDogV2ViIHNlcnZpY2VzIGFyZSBpcyBhIGNsYXNzIG9mIHByb3RvY29scyAoZnJh
bWV3b3JrKSB3aWRlbHkgc3R1ZGllZCBhbmQgZGV2ZWxvcGVkIGFjcm9zcyBudW1lcm91cyBzdGFu
ZGFyZCBib2RpZXMgbGlrZSBXM0MsIE9BU0lTLCBXUy1JLCBMaWJlcnR5LCBQYXJsYXkgYW5kIGFk
YXB0ZWQgdG8gbnVtZXJvdXMgZGVwbG95bWVudCBlbnZpcm9ubWVudHMgIGlzc3VlcyBhdCBJRVRG
LCBPTUEsIDNHUFAsIDNHUFAyLCBKQ1AsIGV0Y4UgQXMgYW4gZW50cnkgcG9pbnQsIHdlIHJlY29t
bWVuZCBjb25zdWx0aW5nIHRoZSB3b3JrIGF0IFczQyBbV1MxXS4NDU1haW50YWluIEV4aXN0aW5n
IFByb3RvY29sIEludGVncml0eSBbNS4yXQ1UOiBXZWIgc2VydmljZXMgaXMgYW4gWE1MLWJhc2Vk
IGZyYW1ld29yayB0aGF0IGlzIGJ5IGRlZmluaXRpb24gZXh0ZW5zaWJsZSB0byBzdXBwb3J0IGFw
cHJvcHJpYXRlIHN5bnRheCBhbmQgc2VtYW50aWNzLiANDVdlYiBzZXJ2aWNlcyBhcmUgYm91bmQg
b24gdW5kZXJseWluZyB0cmFuc3BvcnQgcHJvdG9jb2xzLiBOdW1lcm91cyBzdWNoIGJpbmRpbmcg
aGF2ZSBiZWVuIHNwZWNpZmllZC4gT3RoZXJzIGFyZSBpbiBkZXZlbG9wbWVudC4gQnkgaGFuZGxp
bmcgYXQgU1BFRUNIU0MgYXQgdGhlIGxldmVsIG9mIHRoZSANV2ViIHNlcnZpY2VzIGZyYW1ld29y
aywgdGhlIGludGVncml0eSBpcyBtYWludGFpbmVkIGZvcjoNLSB1bmRlcmx5aW5nIHRyYW5zcG9y
dCBwcm90b2NvbHMgKHRvIHdoaWNoIHRoZSB3ZWIgc2VydmljZSBhcmUgYm91bmQgKGUuZy4gU09B
UCkNLSB3ZWIgc2VydmljZSBmcmFtZXdvcmsNDVRoaXMgZG9lcyBub3QgcHJldmVudCBpbnRyb2R1
Y2luZyBiaW5kaW5ncyB0byBuZXcgcHJvdG9jb2xzIGlmIG5lZWRlZC4gRm9yIGV4YW1wbGUsIGJp
bmRpbmcgdG8gU0lQIG9yIEJFRVAgY291bGQgYmUgYWR2YW50YWdlb3VzIGZvciBtb2JpbGUgZGVw
bG95bWVudHMuDQ1Bdm9pZCBEdXBsaWNhdGluZyBFeGlzdGluZyBQcm90b2NvbHMgWzUuM10NVDog
QnkgZGVmaW5pdGlvbiwgdGhlIHdlYiBzZXJ2aWNlIGZyYW1ld29yayBjYW4gYmUgc3BlY2lmaWVk
IHRvIHJlbW90ZSBjb250cm9sIGFueSB3ZWIgc2VydmljZS4gU3BlY2lmaWVkIHN5bnRheCBjYW4g
YmUgbGltaXRlZCB0byBhdm9pZCBkdXBsaWNhdGluZyByZW1vdGUgY29udHJvbCBmdW5jdGlvbmFs
aXRpZXMgb2ZmZXJlZCBieSBvdGhlciBwcm90b2NvbHMuIA0NQXQgdGhlIHNhbWUgdGltZSwgdGhl
IGV4dGVuc2liaWxpdHkgaW5oZXJlbnQgdG8gdGhlIGZyYW1ld29yayBndWFyYW50ZWVzIHRoYXQg
aXQgaXMgcG9zc2libGUgdG8gc3BlY2lmeSAoc3RhbmRhcmQpIG9yIGRlZmluZSAoYXBwbGljYXRp
b24gc3BlY2lmaWMpIHJlbW90ZSBjb250cm9sIGZvciBvdGhlciBlbnRpdGllcyBiZXlvbmQgdGhl
IGN1cnJlbnQgc2NvcGUgb2YgU1BFRUNIU0MuIA0NSW4gdGhhdCBjb250ZXh0IGFuZCBpbiB2aWV3
IG9mIHVuaWZ5aW5nIHRoZSByZW1vdGUgY29udHJvbCBmcmFtZXdvcmsgZXhwb3NlZCB0byBhbiBh
cHBsaWNhdGlvbiBkZXZlbG9wZXIgb3IgYSBzeXN0ZW0gaW50ZWdyYXRvciwgaXQgbWF5IGJlIG9m
IGludGVyZXN0IHRvIHByb3ZpZGUgcmVtb3RlIGNvbnRyb2wgc3ludGF4IGZvciBzcGVjaWFsIGVu
dGl0aWVzIGxpa2UgcHJvbXB0IHBsYXllciBldGOFDQ1Qcm90b2NvbCBlZmZpY2llbmN5IFs1LjRd
DVArIHRvIFA6IFdlYiBzZXJ2aWNlcyBhcmUgYnkgZGVmaW5pdGlvbiBtb3JlIHZlcmJvc2UgcHJv
dG9jb2xzLiBIZW5jZSwgYXQgdGhpcyBzdGFnZSB0aGlzIGRvZXMgbm90IHF1YWxpZnkgd29yayBh
IFQgbWFyay4gDQ1Ib3dldmVyIHdvcmsgaXMgaW4gcHJvZ3Jlc3MgKGUuZy4gT01BLCBKQ1ApIHRv
IG9wdGltaXplIHRoZSBleGNoYW5nZXMgdG8gaGFuZGxlOg0tIENsaWVudCB3aXRoIGxpbWl0ZWQg
cmVzb3VyY2VzDS0gQ29uc3RyYWluZWQgYmFuZHdpZHRoDVRoZXNlIHJlbHkgb24gcHJvdG9jb2wg
Y29tcHJlc3Npb24gYW5kIG9wdGltaXphdGlvbiwgY2FjaGluZyBhbmQgZ2F0ZXdheXMuIA0NQXMg
c3VjaCB0aGUgcHJvdG9jb2xzIHF1YWxpZnkgYXMgUCsuDQ1JbiBhZGRpdGlvbiwgYmFzZWQgb24g
dGhlIHF1YWxpZmljYXRpb24gb2YgZWZmaWNpZW5jeSBwcm92aWRlZCBpbiBbV1M4XSwgdGhlIHdl
YiBzZXJ2aWNlIGZyYW1ld29yayBwcm9wb3NlZCBmb3IgU1BFRUNIU0MgYW5kIGRlc2NyaWJlZCBp
biBbV1MxXSByZWxpZXMgaW5kZWVkIG9uIGtub3duIGVmZmljaWVudCB0ZWNobmlxdWVzOg0tIEFz
eW5jaHJvbm91cyBwcmUtcHJvZ3JhbW1pbmcgb2YgdGhlIGVuZ2luZXMgYXMgd2ViIHNlcnZpY2Vz
IHRvIHJlZHVjZSBleGNoYW5nZXMgYW5kIGF2b2lkIHJhY2luZyBjb25kaXRpb25zDS0gUG9zc2li
aWxpdHkgdG8gcGlnZ3kgYmFjayBvbiByZXNwb25zZSBtZXNzYWdlIGlmIHRyYW5zcG9ydGVkIG9u
IG9wdGltaXplZCBwcm90b2NvbHMgbGlrZSBTSVAgb3IgQkVFUC4gDS0gc3RhdGUgY2FjaGluZyBp
biB0aGUgZW5naW5lcyB0aGF0IGFyZSBjb25zaWRlcmVkIGFzIHN0YW5kLWFsb25lLCBwcmUtcGFj
a2FnZWQgYW5kIHByZS1wcm9ncmFtbWVkIGVuZ2luZXMuDS0gZXRjhQ0NRXhwbGljaXQgaW52b2Nh
dGlvbiBvZiBzZXJ2aWNlcyBbNS41XQ1UOiBXZWIgc2VydmljZSBpcyB0eXBpY2FsbHkgdXNlZCBp
biBhIGNsaWVudC1zZXJ2ZXIgZW52aXJvbm1lbnQuIFNvbHV0aW9ucyBleGlzdCBmb3IgcGVlciB0
byBwZWVyIChzZXJ2aWNlIHRvIHNlcnZpY2UpIGV0Y4UgDQ1XZWIgc2VydmljZXMgaGF2ZSBiZWVu
IGRlaWduZWQgdG8gc3VwcG9ydCBjbGllbnRzIGFuZCBzZXJ2ZXJzIGF0IGxlYXN0IG9uZSBvZiB3
aGljaCBpcyBvcGVyYXRpbmcgZGlyZWN0bHkgb24gYmVoYWxmIG9mIHRoZSB1c2VyIHJlcXVlc3Rp
bmcgdGhlIHNlcnZpY2UuDQ1JbiBhZGRpdGlvbiwgd29yayBvbi1nb2luZyBhdCBPTUEgYW5kIEpD
UCBhZGRyZXNzZXMgc29tZSBvZiB0aGVzZSBpc3N1ZXMgaW4gbW9iaWxlIGVudmlyb25tZW50IHdp
dGggdGhlIGludHJvZHVjdGlvbiBvZiBwb3NzaWJsZSB3ZWIgc2VydmljZSBnYXRld2F5cy4gDQ1T
ZXJ2ZXIgTG9jYXRpb24gYW5kIExvYWQgQmFsYW5jaW5nIFs1LjZdDVQ6IFdlYiBzZXJ2aWNlcyBh
cmUgd2lkZWx5IGRldmVsb3BlZCBmb3IgZS1idXNpbmVzcyBhcHBsaWNhdGlvbnMuIE51bWVyb3Vz
IHRvb2xzIGFuZCBtZWNoYW5pc21zIGhhdmUgYmVlbiBwcm92aWRlZCBmb3Igc2VydmljZSBkaXNj
b3ZlcnkgYWQgYWR2ZXJ0aXNlbWVudC4gSW4gYWRkaXRpb24sIG51bWVyb3VzIG9mZmVyaW5ncyBw
cm92aWRlIHJvdXRpbmcgYW5kIGxvYWQgYmFsYW5jaW5nIGNhcGFiaWxpdGllcyBhcyBwYXJ0IG9m
IHRoZSB3ZWIgYXBwbGljYXRpb24gc2VydmVyIHVzZWQgdG8gZGVwbG95IHRoZSB3ZWIgc2Vydmlj
ZS4gDQ1Ob3RlIHRoYXQgd2ViIHNlcnZpY2VzIGRvIG5vdCBzcGVjaWZ5IHNlcnZlciBsb2NhdGlv
biBvciBsb2FkIGJhbGFuY2luZzsgYnV0IHRoZXkgYXJlIGRlcGxveWVkIG9uIHN5c3RlbXMgdGhh
dCBwcm92aWRlIHN1Y2ggZnVuY3Rpb25hbGl0aWVzLiBBcyB3ZWIgc2VydmljZXMgYXJlIGV4cGVj
dGVkIHRvIGJlIHdpZGVseSB1c2VkIGluIHRoZSBmdXR1cmUgYW5kIGNlbnRyYWwgdG8gbW9zdCBl
LWJ1c2luZXNzIG9mZmVyaW5ncywgaXQgaXMgdG8gZXhwZWN0IHRoYXQgc3VjaCB0b29scyB3aWxs
IGJlY29tZSBldmVuIG1vcmUgcGVydmFzaXZlIGFuZCBlZmZpY2llbnQuDQ1TaW11bHRhbmVvdXMg
c2VydmljZXMgWzUuN10NV2ViIHNlcnZpY2VzIGFsbG93IGNvbnRyb2wgKGludGVyZmFjZSkgYW5k
IGNvbXBvc2l0aW9uIG9mIHdlYiBzZXJ2aWNlcyBhdCB3aWxsIChlLmcuIFdTRkwpLg1NdWx0aXBs
ZSBtZWRpYSBzZXNzaW9ucyBbNS44XQ1UOiBUaGUgZnJhbWV3b3JrIHByb3Bvc2VkIGRvZXMgbm90
IHByZS1zdXBwb3NlcyBob3cgbWFueSBwb3J0cyBvciBzdHJlYW1zIGFyZSBhc3NvY2lhdGVkIHRv
IHRoZSBlbmdpbmUuIERpZmZlcmVudCBpbmJvdW5kIGFuZCBvdXRib3VuZCBjYW4gYmUgdXNlZCBh
dCB3aWxsDQ1BbmFseXNpcyBvZiBEdXBsZXhpbmcgYW5kIFBhcmFsbGVsIE9wZXJhdGlvbiBSZXF1
aXJlbWVudHMNRHVwbGV4aW5nIGFuZCBQYXJhbGxlbCBPcGVyYXRpb24gUmVxdWlyZW1lbnRzIFs5
XQ1UOiBBcyBleHBsYWluZWQsIHdlYiBzZXJ2aWNlcyBhbGxvdyBjb250cm9sIChpbnRlcmZhY2Up
IGFuZCBjb21wb3NpdGlvbiBvZiB3ZWIgc2VydmljZXMgYXQgd2lsbCAoZS5nLiBXU0ZMKS4gIEFs
c28sIGl0IGRvZXMgbm90IHByZS1zdXBwb3NlcyBob3cgbWFueSBwb3J0cyBvciBzdHJlYW1zIGFy
ZSBhc3NvY2lhdGVkIHRvIHRoZSBlbmdpbmUuIERpZmZlcmVudCBpbmJvdW5kIGFuZCBvdXRib3Vu
ZCBjYW4gYmUgdXNlZCBhdCB3aWxsOyBpbiBmdWxsIGR1cGxleCBvciBldmVuIGJldHdlZW4gZW5n
aW5lcyBhcyBzdXBwb3J0ZWQgYnkgV1NGTCBbV1M0XSBhbmQgV1NYbCBbV1M3XS4NRnVsbCBEdXBs
ZXggb3BlcmF0aW9uIFs5LjEuMV0NVDoNTXVsdGlwbGUgc2VydmljZXMgaW4gcGFyYWxsZWwgWzku
MS4yXQ1UOg1Db21iaW5hdGlvbiBvZiBzZXJ2aWNlcw1UOiBBcyBleHBsYWluZWQsIHdlYiBzZXJ2
aWNlcyBhbGxvdyBjb250cm9sIChpbnRlcmZhY2UpIGFuZCBjb21wb3NpdGlvbiBvZiB3ZWIgc2Vy
dmljZXMgYXQgd2lsbCAoZS5nLiBXU0ZMKSBpbnRvIGNvbXBsZXggcGFyYWxsZWwsIHNlcmlhbCBv
ciBjb29yZGluYXRlZCBjb21iaW5hdGlvbnMgYXMgc3VwcG9ydGVkIGJ5IFdTRkwgW1dTNF0gYW5k
IFdTWGwgW1dTN10uDUFuYWx5c2lzIG9mIGFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgKG5vbi1u
b3JtYXRpdmUpDVRoZSBmcmFtZXdvcmsgcHJvcG9zZWQgc3VwcG9ydHM6DS0gVXNlIG9mIFNEUCB0
byBkZXNjcmliZSBzZXNzaW9ucyBhbmQgc3RyZWFtcyBmb3IgdGhlIHN0cmVhbWVkIGNoYW5uZWxz
IA0tIFRpbWUgc3RhbXBzIGNvdWxkIGJlIHRyYW5zbWl0dGVkIGFzIHBhcnQgb2YgdGhlIGNvbnRy
b2wgbWVzc2FnZXMgYXQgdGhlIHdlYiBzZXJ2aWNlIGxldmVsIG9yIGluIGJhbmQgKGUuZy4gd2l0
aCBkeW5hbWljIHBheWxvYWQgc3dpdGNoIG9yIHdpdGhpbiB0aGUgcGF5bG9hZCkuDS0gVGhlIGZy
YW1ld29yayBpcyBjb21wYXRpYmxlIHdpdGggYW55IGVuY29kaW5nIHNjaGVtZS4gVGhpcyBpcyBp
bGx1c3RyYXRlZCBieSB0aGUgd29yayBvbiBTUkYgKFNwZWVjaCBSZWNvZ25pdGlvbiBGcmFtZXdv
cmspIGRyaXZlbiBhdCAzR1BQIHRoYXQgc3VwcG9ydHMgY29udmVudGlvbmFsIGFuZCBEU1Igb3B0
aW1pemVkIGNvZGVjcyBhbmQgcG9zc2libGUgZXhjaGFuZ2Ugb2Ygc3BlZWNoIG1ldGEtaW5mb3Jt
YXRpb24gKGUuZy4gZGF0YSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBmYWNpbGl0YXRlIGFuZCBl
bmhhbmNlIHRoZSBzZXJ2ZXItc2lkZSBwcm9jZXNzaW5nIG9mIHRoZSBpbnB1dCBzcGVlY2ggYW5k
IGZhY2lsaXRhdGUgdGhlIGRpYWxvZyBtYW5hZ2VtZW50IGluIGFuIGF1dG9tYXRlZCB2b2ljZSBz
ZXJ2aWNlLiBUaGVzZSBtYXkgaW5jbHVkZSBrZXlwYWQgZXZlbnRzIG92ZXItcmlkaW5nIHNwb2tl
biBpbnB1dCwgbm90aWZpY2F0aW9uIHRoYXQgdGhlIFVFIGlzIGluIGhhbmRzLWZyZWUgbW9kZSwg
Y2xpZW50LXNpZGUgY29sbGVjdGVkIGluZm9ybWF0aW9uIChzcGVlY2gvbm8tc3BlZWNoLCBiYXJn
ZS1pbiksIGV0Y4UuKS4NLSBTT0FQIG92ZXIgU0lQIG9yIEJFRVAgdG8gc3VwcG9ydCB0aGUgZnJh
bWV3b3JrIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDEgY2FuIGFsc28gc3VwcG9ydCBWQ1IgY29udHJv
bHMuDS0gcmVhbC10aW1lIG1lc3NhZ2luZyBiZXR3ZWVuIGVuZ2luZSBhbmQgY29udHJvbCBpcyBz
dXBwb3J0ZWQgd2l0aGluIHRoZSBmcmFtZXdvcmsgKGUuZy4gdmlhIFNPQVAgb3IgWE1MIGV2ZW50
cykuIFRoZSBmcmFtZXdvcmsgYWxzbyBzdXBwb3J0IGV4Y2hhbmdlIGJldHdlZW4gZW5naW5lcyAo
c2FtZSBwcm9jZXNzOyBzZWUgYWxzbyBXU1hMIFtXUzddKS4NDUFsdGhvdWdoIG5vbi1ub3JtYXRp
dmUsIHRoZSB3ZWIgc2VydmljZSBmcmFtZXdvcmsgZGVzY3JpYmVkIHByb2JhYmx5IGRlc2VydmVz
IG1hcmtzIG9mIFArIHRvIFQuDQ1BbmFseXNpcyBvZiBTZWN1cml0eSBjb25zaWRlcmF0aW9ucw1T
ZWN1cml0eSBDb25zaWRlcmF0aW9ucyBbMTFdDVdlYiBzZXJ2aWNlcyBhcmUgZXZvbHZpbmcgdG8g
cHJvdmlkZSBzZWN1cml0eSwgYXV0aGVudGljYXRpb24sIGVuY3J5cHRpb24sIHRydXN0IG1hbmFn
ZW1lbnQgYW5kIHByaXZhY3kgLiBEZXRhaWxzIGNhbiBiZSBmb3VuZCBmb3IgZXhhbXBsZSBpbiBb
V1M5XSBhbmQgZXhwbGFpbmVkIGluIFtXUzEwXS4gVGhpcyBpcyBub3cgYW4gT0FTSVMgYWN0aXZp
dHkgW1dTMTFdLg0NVGhpcyBmcmFtZXdvcmsgd291bGQgZW5hYmxlIFNQRUVDSFNDIHRvIGVtcGxv
eSB0aGUgc2VjdXJpdHkgbWVjaGFuaXNtIHByb3ZpZGVkIGJ1IFdTLVNlY3VyaXR5IGZvciB0aGUg
cmVtb3RlIGNvbnRyb2wgYXNwZWN0cy4gRXhjaGFuZ2VkIG1lZGlhIGNhbiByZWx5IG9uIHNlY3Vy
aXR5IG1lY2hhbmlzbSBhdCB0aGUgdHJhbnNwb3J0IC8gc3RyZWFtaW5nIGxldmVsLg0NVGhlIHdl
YiBzZXJ2aWNlIGZyYW1ld29yayBkZXNjcmliZWQgcHJvYmFibHkgZGVzZXJ2ZXMgbWFya3Mgb2Yg
UCsgdG8gVC4NSW50ZXJhY3Rpb24gTW9kZWwNVEJDIDogVE8gQkUgQ09NUExFVEVEIDogQW5hbHlz
aXMgb2YgdGhlIGludGVyYWN0aW9uIG1vZGVsIG9mIHRoZSBwcm90b2NvbCBkdXJpbmcgdGhlIJFk
YXRhkiBwaGFzZSAoaWUgYWZ0ZXIgc2Vzc2lvbiBlc3RhYmxpc2htZW50KSBhbmQgaXRzIHN1aXRh
YmlsaXR5IGZvciBzcGVlY2hzYy4NDQ1SZXNvdXJjZSBDb250cm9sIDogk01SQ1CUIENvbXBsaWVu
Y2UgRXZhbHVhdGlvbiAoU2FydmkgU2hhbm11Z2hhbSkNR2VuZXJhbCANTVJDUCBGcmFtZXdvcmsg
YW5kIEdlbmVyYWwgQXBwbGljYWJpbGl0eQ0NVGhlIG92ZXJhbGwgTVJDUCBmcmFtZXdvcmssIHRo
ZSBjb21wb25lbnRzIGludm9sdmVkIGFuZCB0aGVpciBkaXN0cmlidXRpb24gYW5kIHJlbGF0aW9u
c2hpcCB0byBlYWNoIG90aGVyIG1lZXQgdGhlIGZyYW1ld29yayBzcGVjaWZpZWQgYnkgU1BFRUNI
U0MuIFRoZSBwcmltYXJ5IGFkdmFudGFnZSBvZiBNUkNQIGlzIHRoYXQgaXQgaXMgYSB0ZXh0IGJh
c2VkIHByb3RvY29sIGRlc2lnbmVkIHRvIG1lZXQgbW9zdCBvZiB0aGUgcmVxdWlyZW1lbnRzIG9m
IFNQRUVDSFNDIHBlcnRhaW5pbmcgdG8gc3BlZWNoIHJlY29nbml0aW9uIGFuZCBUZXh0IHRvIHNw
ZWVjaC4gVGhvdWdoIFNwZWFrZXIgUmVjb2duaXRpb24gKFNSKSBhbmQgU3BlYWtlciBWZXJpZmlj
YXRpb24gKFNWKSBhcmUgbm90IHN1cHBvcnRlZCBpbiBpdHMgY3VycmVudCBmb3JtLCBNUkNQIHdh
cyBleHBsaWNpdGx5IGRlc2lnbmVkIHRvIGJlIGV4dGVuZGFibGUgZm9yIHN1Y2ggbmVlZHMuIFRo
ZSBjb3JlIE1SQ1AgZGVmaW5pdGlvbiBvbmx5IGRlYWxzIHdpdGggdGhlIGNvbnRyb2wgb2YgdGhl
IEFTUiBvciBUVFMgcmVzb3VyY2UgYW5kIHRoZSBjb21tYW5kcyBhbmQgcmVzcG9uc2VzIG5lZWRl
ZCB0byBhY2hpZXZlIGl0Lg0NVGhlcmUgYXJlIG11bHRpcGxlIGludGVyb3BlcmFibGUgaW1wbGVt
ZW50YXRpb25zIG9mIE1SQ1AgYW5kIGhlbmNlIGlzIGEgcHJvdmVuIHRlY2hub2xvZ3kuIEl0IGxl
dmVyYWdlcyBleGlzdGluZyBXM0MgWE1MIHN0YW5kYXJkcyBmb3IgZXhjaGFuZ2Ugb2YgZGF0YSBi
ZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBzZXJ2ZXIgcmVzb3VyY2UuIEZvciBFeGFtcGxlLCBp
dHMgdXNlcyB0aGUgVzNDIFhNTCBncmFtbWFyIGZvcm1hdCAoR1JYTUwpIGFsb25nIHdpdGggVzND
IHNlbWFudGljIGF0dGFjaG1lbnRzIGFuZCBOYXR1cmFsIExhbmd1YWdlIFNlbWFudGljIE1hcmt1
cCBMYW5ndWFnZSB0byBleGNoYW5nZSBkYXRhIHdpdGggc3BlZWNoIHJlY29nbml0aW9uIHJlc291
cmNlLiBUaGUgVzNDIFNwZWVjaCBNYXJrdXAgTGFuZ3VhZ2UgaXMgdXNlZCB3aGVuIGRlYWxpbmcg
d2l0aCBUZXh0IHRvIHNwZWVjaCBlbmdpbmVzLg0gDUl0IHdhcyBkZXNpZ25lZCB0byB3b3JrIGFz
IGEgdHVubmVsZWQgcHJvdG9jb2wsIG92ZXIgUlRTUCBvciBTSVAuIEhlbmNlIGl0IGRlcGVuZHMg
b24gdGhlIGNhcnJpZXIgcHJvdG9jb2wgdG8gZXN0YWJsaXNoIGEgY29udHJvbCBhbmQgYSBtZWRp
YSBwYXRoIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIEFTUiBvciBUVFMgc2VydmVyIHJlc291
cmNlLiBIZW5jZSBpdCBnZXRzIG1vc3Qgb2YgdGhlIHNlY3VyaXR5IGFuZCBtZWRpYSBwaXBlIG1h
bmFnZW1lbnQgb3BlcmF0aW9ucyBmb3IgZnJlZS4gT25jZSB0aGVzZSBhcmUgZXN0YWJsaXNoZWQs
IE1SQ1AgY29tbWFuZHMgYW5kIHJlc3BvbnNlcyBhcmUgdHVubmVsZWQgb3ZlciwgY29udHJvbGxp
bmcgdGhlIEFTUiBvciBUVFMgcmVzb3VyY2Ugb24gdGhlIHNlcnZlci4gDU1SQ1AgY2FuIGJlIGV2
b2x2ZWQNDVRob3VnaCBNUkNQIGRpcmVjdGx5IG1lZXRzIG1hbnkgb2YgdGhlIG5lZWRzIG9mIFNQ
RUVDSFNDLiBUaGUgbm90aW9uIHRoYXQgaXQgaXMgYSB0dW5uZWxlZCBwcm90b2NvbCBkaXNhbGxv
d3MgaXRzIGluZGVwZW5kZW50IG9wZXJhdGlvbi4gRnVydGhlciBtb3JlIHRoZSB0dW5uZWxlZCBh
c3BlY3QgaXMgYWxzbyBhIGxlc3MgZWZmaWNpZW50IHByb3RvY29sIGRlc2lnbi4gDQ1CdXQgdGhl
c2UgY2FuIGJlIGFkZHJlc3NlZCBhbmQgdGhlIGNvcmUgTVJDUCBtZXNzYWdlcyBjYW4gYmUgZXZv
bHZlZCB0byBlaXRoZXIgYmVjb21lIHN0YW5kYWxvbmUgcHJvdG9jb2wgYnkgaXRzZWxmIG9yIGV4
dGVuc2lvbnMgdG8gYW4gZXhpc3RpbmcgcHJvdG9jb2wgc3VjaCBhcyBTSVAgb3IgUlRTUC4gIFRv
IG1ha2UgdGhpcyBhIHN0YW5kYWxvbmUgcHJvdG9jb2wgYW5kIGFsbG93IE1SQ1AgdG8gb3BlcmF0
ZSBieSBpdHNlbGYsIG5ldyBzZXNzaW9uIGFuZCBtZWRpYSBtYW5hZ2VtZW50IG1lc3NhZ2VzIG5l
ZWQgdG8gYmUgZGVmaW5lZCB0byBhbGxvdyBpdCB0byBvcGVyYXRlIGluZGVwZW5kZW50bHkuIFRv
IGV2b2x2ZSBNUkNQIGFzIGV4dGVuc2lvbnMgdG8gU0lQIG9yIFJUU1Agd291bGQgYWxzbyBiZSBy
ZWxhdGl2ZWx5IHNpbXBsZSBzaW5jZSBpdCBpcyBhbHNvIGEgdGV4dCBiYXNlZCBwcm90b2NvbCB3
aXRoIG1lc3NhZ2UgZm9ybWF0IGFuZCBoZWFkZXJzIHZlcnkgc2ltaWxhciB0byB0aGVtLiAgSW4g
dGhpcyBwcm90b2NvbCBldmFsdWF0aW9uLCB0aGUgY29tcGxpYW5jZSBldmFsdWF0ZXMgTVJDUCBm
cm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBldm9sdXRpb24gaW4gb25lIG9mIHRoZXNlIGZvcm1zLg0N
VGhlIGZvbGxvd2luZyBzdWItc2VjdGlvbnMgY29tcGFyZSBlYWNoIGluZGl2aWR1YWwgcmVxdWly
ZW1lbnQgcmVsYXRpbmcgdG8gcmVzb3VyY2UgbWFuYWdlbWVudCBhZ2FpbnN0IHRoZSBwcm90b2Nv
bC4NQW5hbHlzaXMgb2YgVFRTIHJlcXVpcmVtZW50cw1SZXF1ZXN0aW5nIFRleHQgUGxheWJhY2sg
WzYuMV0NVDogTVJDUCBoYXMgdGhlIFNQRUFLIG1ldGhvZCBmb3IgdGhlIGNsaWVudCB0byByZXF1
ZXN0IHRoZSBUVFMgcmVzb3VyY2UgdG8gcGxheWJhY2sgdGV4dCBhcyBhbiBhdWRpbyBzdHJlYW0u
DVRleHQgRm9ybWF0cyBbNi4yXQ1UOiBXaGVuIHRoZSBjbGllbnQgcmVxdWVzdHMgdGhlIFRUUyBy
ZXNvdXJjZSB0byBwbGF5YmFjayBhIHRleHQgc3RyZWFtIGl0IGNhbiBwcm92aWRlIHRoZSBjb250
ZW50IGluIHRoZSBmb2xsb3dpbmcgZm9ybWF0cyBhbmQgdGhyb3VnaCB0aGUgZm9sbG93aW5nIG1l
Y2hhbmlzbS4NDVBsYWluIHRleHQNVzNDIFhNTCBiYXNlZCBTcGVlY2ggTWFya3VwIExhbmd1YWdl
IChTU01MKQ1UaGlzIGNvbnRlbnQgdG8gYmUgc3Bva2VuIGNhbiBiZSBwcm92aWRlZCBieSB2YWx1
ZSBkaXJlY3RseSB0aHJvdWdoIHRoZSBjb250cm9sIHBhdGguIA1JdCBhbHNvIHN1cHBvcnRzIHBh
c3NpbmcgdGhlIGNvbnRlbnQgYnkgcmVmZXJlbmNlLiBUaGlzIGlzIGFjaGlldmVkIGhhdmluZyBh
biBhdWRpbyB0YWcgaW5zaWRlIHRoZSBTU01MIG1hcmt1cCB0ZXh0LiBUaGlzIFVSTCBpcyB0aGVu
IGZldGNoZWQgYW5kIHBsYXllZCBvbiB0aGUgUlRQIHN0cmVhbSBpbiBzZXF1ZW5jZSB3aXRoIHRo
ZSByZXN0IG9mIHRoZSB0ZXh0IGFjY29yZGluZyB0byB0aGUgU1NNTCBzcGVjaWZpY2F0aW9uLg1X
aGVuIHRoZSBjbGllbnQgc2VuZHMgcGxhaW4gdGV4dCwgU1NNTCBvciBhbm90aGVyIGZvcm1hdCBv
ZiBzcGVlY2ggdGV4dCB0aGUgY29udGVudCBpcyBjb2RlZCBhcyBhIG1pbWUtdHlwZS4gSGVuY2Ug
dGhlIHNlcnZlciBrbm93cyB3aGF0IGZvcm1hdCB0aGUgc3BlZWNoIGNvbnRlbnQgaXMgY29kZWQg
aW4sIGFuZCBkb2VzIG5vdCBoYXZlIHRvIGZpZ3VyZSBpdCBvdXQgZnJvbSB0aGUgY29udGVudC4N
UGxhaW4gdGV4dCBbNi4yLjFdDVQ6IHNlZSBhYm92ZQ1TU01MIFs2LjIuMl0NVDogc2VlIGFib3Zl
DVRleHQgaW4gQ29udHJvbCBDaGFubmVsIFs2LjIuM10NVKA6IHNlZSBhYm92ZQ1Eb2N1bWVudCBU
eXBlIEluZGljYXRpb24gWzYuMi40XQ1UOiBzZWUgYWJvdmUNQ29udHJvbCBDaGFubmVsIFs2LjNd
DVQ6IEluIE1SQ1AsIHRoaXMgUmVzZXQtQXVkaW8tQ2hhbm5lbCBoZWFkZXIgZGVmaW5lZCBmb3Ig
dGhlIEFTUiByZXNvdXJjZSBhbGxvd3MgdGhlIHJlY29nbml6ZXIgdG8gcmUtaW5pdGlhbGl6ZSB0
aGUgYXVkaW8gY2hhcmFjdGVyaXN0aWNzIHRoYXQgaXQgaGFzIGxlYXJudCB0aWxsIHRoZW4uIFRo
aXMgYWxsb3dzIGEgcmVjb2duaXplciByZXNvdXJjZSB0byBiZSB1c2VkIGZvciBtdWx0aXBsZSBy
ZWNvZ25pdGlvbiBzZXNzaW9ucy4gSXQgY2FuIGJlIHVzZWQgZm9yIHNob3J0IHNpbmdsZSB1dHRl
cmFuY2UgcmVjb2duaXRpb25zIGFzIHdlbGwuIFRoaXMgaXMgYnkgYXBwbHlpbmcgdGhlIFJlc2V0
LUF1ZGlvLUNoYW5uZWwgaGVhZGVyIHRvIGV2ZXJ5IHJlY29nbml0aW9uLiBJIHN1c3BlY3QgdGhl
IHBlcmZvcm1hbmNlIG1heSBub3QgYmUgYXMgZ29vZCwgZHVlIHRvIHRoZSBsYWNrIG9mIGxpbmUg
Y2hhcmFjdGVyaXN0aWNzLCBidXQgdGhpcyBpcyBhIHJlY29nbml6ZXIgaXNzdWUuDVBsYXliYWNr
IENvbnRyb2xzIFs2LjRdDVQ6IE1SQ1Agc3VwcG9ydHMgdGhlIENPTlRST0wgbWV0aG9kIHdpdGgg
dGhlIEp1bXAtVGFyZ2V0IGhlYWRlciBjYW4gdXNlZCB0byBhY2hpZXZlLCBqdW1waW5nIGluIHRp
bWUgb3IgdG8gYW4gZXhhY3Qgb3IgcmVsYXRpdmUgbG9jYXRpb24uIEl0IHN1cHBvcnRzIGp1bXBp
bmcgaW4gcGFyYWdyYXBocywgc2VudGVuY2VzLCB3b3JkcyBhbmQgdG8gc3BlY2lmaWMgbWFya2Vy
cyB0aGF0IG1heSBiZSBlbWJlZGRlZCBpbiB0aGUgc3BlZWNoIGNvbnRlbnQuIFRoZSBDT05UUk9M
IG1ldGhvZCBjYW4gYmUgdXNlZCB3aXRoIHRoZSBWb2ljZSBhbmQgUHJvc29keSBwYXJhbWV0ZXJz
LCBkZXJpdmVkIGZyb20gU1NNTCwgYW5kIGNhbiBhZGRyZXNzIHRoZSBzcGVlZCBvZiBzcGVlY2gg
b3IgaW5jcmVhc2luZy9kZWNyZWFzaW5nIHRoZSB2b2x1bWUuIEl0IGFsc28gc3VwcG9ydHMgdGhl
IFBBVVNFL1JFU1VNRSBtZXRob2RzIHRvIHBhdXNlIG9yIHJlc3VtZSBhIGN1cnJlbnQgU1BFQUsg
cmVxdWVzdC4NU2Vzc2lvbiBQYXJhbWV0ZXJzIFs2LjVdDVQ6IEFzIG1lbnRpb25lZCB0aGUgcHJl
dmlvdXMgc2VjdGlvbiwgTVJDUCBzdXBwb3J0cyB2b2ljZSBhbmQgcHJvc29keSBwYXJhbWV0ZXJz
IHdoaWNoIGFyZSBkaXJlY3RseSBkZXJpdmVkIGZyb20gdGhlIFczQyBTU01MIHNwZWNpZmljYXRp
b24uIFRoZXNlIGhlYWRlcnMgY2FuIGJlIHNlbnQgdXNpbmcgdGhlIFNFVC1QQVJBTVMgbWV0aG9k
IGFuZCBhcHBsaWVkIGFzIGEgZGVmYXVsdCBmb3IgdGhlIGVudGlyZSBzZXNzaW9uLiBUaGV5IGNh
biBhbHNvIGJlIGFwcGxpZWQgaW4gU1BFQUsgcmVxdWVzdHMgdG8gYXBwbHkgcGVyIHVzYWdlIG9y
IGluIHRoZSBDT05UUk9MIG1lc3NhZ2UgdG8gY2hhbmdlIHRoZSBwYXJhbWV0ZXJzIG9mIGFuIGFj
dGl2ZSBTUEVBSyByZXF1ZXN0Lg1TcGVlY2ggTWFya2VycyBbNi42XQ1UOiBTcGVjaWZ5aW5nIHNw
ZWVjaCBtYXJrZXJzIGluIHRoZSBjb250ZW50IGlzIHN1cHBvcnRlZCB0aHJvdWdoIFNTTUwuIFRo
ZSBDT05UUk9MIG1lc3NhZ2UgY2FuIHRoZW4gYmUgdXNlZCB0byBqdW1wIHRvIHNwZWNpZmljIG1h
cmtlciBwb2ludHMgaW4gdGhlIHRleHQuIEFsc28sIHdoZW4gdGhlIFRUUyByZXNvdXJjZSByZWFj
aGVzIHNwZWNpZmljIG1hcmtlcnMgaW4gdGhlIHRleHQsIHRoZSBzZXJ2ZXIgd291bGQgZ2VuZXJh
dGUgdGhlIFNQRUVDSC1NQVJLRVIgbWV0aG9kIHRvIHRoZSBjbGllbnQuDUFuYWx5c2lzIG9mIEFT
UiByZXF1aXJlbWVudHMNUmVxdWVzdGluZyBBdXRvbWF0aWMgU3BlZWNoIFJlY29nbml0aW9uIFs3
LjFdDVQ6IFRoZSBjbGllbnQgdXNlcyB0aGUgUkVDT0dOSVpFIG1ldGhvZCBpbiBNUkNQIHRvIHJl
cXVlc3QgdGhlIHJlY29nbml0aW9uIHJlc291cmNlIHRvIHByb2Nlc3MgdGhlIGF1ZGlvIHN0cmVh
bSBpbiB0aGUgcGlwZS4gVGhlIFJFQ09HTklaRSBtZXRob2QgYWxzbyBzcGVjaWZpZXMgcGFyYW1l
dGVycyBhbmQgZ3JhbW1hcnMgdGhlIHJlY29nbml6ZXIgc2hvdWxkIG1hdGNoIGFnYWluc3QuDVhN
TCBbNy4yXQ1UOiBTaW1pbGFyIHRvIHRoZSBUVFMgcmVzb3VyY2UgaW4gTVJDUCwgQVNSIGFsc28g
dXNlcyBYTUwgZGF0YSB0byBleGNoYW5nZSBpbmZvcm1hdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQg
YW5kIHRoZSByZWNvZ25pdGlvbiByZXNvdXJjZS4gSXQgc3VwcG9ydHMgdGhlIFczQyBHUlhNTCB0
byBwYXNzIGdyYW1tYXJzIGZyb20gdGhlIGNsaWVudCB0byB0aGUgc2VydmVyLiBXaGVuIHRoZSBz
ZXJ2ZXIgaXMgZG9uZSByZWNvZ25pemluZywgaXQgdXNlcyB0aGUgVzNDIE5hdHVyYWwgTGFuZ3Vh
Z2UgU2VtYW50aWMgTWFya3VwIExhbmd1YWdlIChOTFNNTCkgdG8gcGFzcyB0aGUgcmVzdWx0cyBi
YWNrIHRvIHRoZSBjbGllbnQuIEl0IHN1cHBvcnRzIG90aGVyIGdyYW1tYXIgZm9ybWF0cyBhcyB3
ZWxsLCBhcyBsb25nIGFzIHRoZSBzZXJ2ZXIgYWxsb3dzIGl0LiBUaGlzIGlzIHBvc3NpYmxlIHNp
bmNlLCBpdCB1c2VzIG1pbWUtdHlwZXMgdG8gcGFja2FnZSB0aGlzIGRhdGEgYW5kIGhlbmNlIHRo
ZSBmb3JtYXQgdHlwZSBpcyBzcGVjaWZpZWQuDUdyYW1tYXIgU3BlY2lmaWNhdGlvbiBbNy4zLjFd
DVArOiBNUkNQIHN1cHBvcnRzIHNwZWNpZnlpbmcgdGhlIGdyYW1tYXIgYm90aCBieSB2YWx1ZSBh
bmQgYnkgcmVmZXJlbmNlLiBUaGUgUkVDT0dOSVpFIG1ldGhvZCBjYW4gY2Fycnkgd2l0aCBpdCBn
cmFtbWFyIGNvbnRlbnQgYW5kL29yIGEgVVJJIHJlZmVycmluZyB0byB0aGUgZ3JhbW1hciBjb250
ZW50LiBTaW5jZSBNUkNQIHN1cHBvcnRzIHJlZmVycmluZyBhIGdyYW1tYXIsIHRoZSByZWZlcnJl
ZCBncmFtbWFyIGNvdWxkIGJlIGxvY2F0ZWQgb24gdGhlIHNlcnZlciBpdHNlbGYuIFdpdGggcmVz
cGVjdCB0byBzaGFyaW5nIG9mIGdyYW1tYXJzLCB0aGUgZ3JhbW1hcnMgZGVmaW5lZC9jb21waWxl
ZCB0aHJvdWdoIHRoZSBERUZJTkUtR1JBTU1BUiBwcmltaXRpdmUgYXJlIG5vdCBzaGFyYWJsZSBh
Y3Jvc3Mgc2Vzc2lvbnMgb24gdGhlIHNhbWUgc2VydmVyLiBUaGlzIG5lZWRzIHRvIGJlIGFkZHJl
c3NlZCB0byBtZWV0IHRoaXMgc2V0IG9mIHJlcXVpcmVtZW50cyBpbiBmdWxsLg1FeHBsaWNpdCBJ
bmRpY2F0aW9uIG9mIEdyYW1tYXIgRm9ybWF0IFs3LjMuMl0NUCs6IHNlZSBhYm92ZQ1HcmFtbWFy
IFNoYXJpbmcgWzcuMy4zXQ1UQkQNU2Vzc2lvbiBQYXJhbWV0ZXJzIFs3LjRdDVQ6IFRoaXMgcmVx
dWlyZW1lbnQgYXMgZGVmaW5lZCBpcyBhbHJlYWR5IGZ1bGx5IG1ldCBzaW5jZSBNUkNQIGlzIHRo
ZSByZWZlcnJlZCBzdGFuZGFyZCBmb3IgY29tcGxpYW5jZS4NSW5wdXQgQ2FwdHVyZSBbNy41XQ1U
OiBUaGlzIGlzIGFjaGlldmVkIGJ5IHNldHRpbmcgdGhlIFdhdmVmb3JtLXVybCBoZWFkZXIgaW4g
dGhlIFJFQ09HTklaRSBtZXRob2QuIFRoaXMgdGVsbHMgdGhlIHNlcnZlciB0byByZWNvcmQgdGhl
IGF1ZGlvIG9mIHRoZSByZWNvZ25pdGlvbiBhbmQgd2lsbCByZXR1cm4gYSBVUkkgdG8gdGhlIGNs
aWVudCBpbiB0aGUgY29tcGxldGlvbiBldmVudCwgd2hpY2ggY2FuIGJlIHVzZWQgdG8gcmV0cmll
dmUgb3IgcGxheSBiYWNrIHRoZSBhdWRpby4NQW5hbHlzaXMgb2YgU3BlYWtlciBJZGVudGlmaWNh
dGlvbiBhbmQgVmVyaWZpY2F0aW9uIFJlcXVpcmVtZW50cw1SZXF1ZXN0aW5nIFNJL1NWIFs4LjFd
DUY6IG5vdCBzdXBwb3J0ZWQNSWRlbnRpZmllcnMgZm9yIFNJL1NWIFs4LjJdDUY6IG5vdCBzdXBw
b3J0ZWQNU3RhdGUgZm9yIG11bHRpcGxlIHV0dGVyYW5jZXMgWzguM10NRjogbm90IHN1cHBvcnRl
ZA1JbnB1dCBDYXB0dXJlIFs4LjRdDUY6IG5vdCBzdXBwb3J0ZWQNU0kvU1YgZnVuY3Rpb25hbCBl
eHRlbnNpYmlsaXR5IFs4LjVdDUY6IG5vdCBzdXBwb3J0ZWQNDVJlc291cmNlIENvbnRyb2wgOiCT
UlRTUJQgQ29tcGxpZW5jZSBFdmFsdWF0aW9uIChCcmlhbiBXeWxkKQ1HZW5lcmFsIEludHJvZHVj
dGlvbg1SVFNQIGlzIGFuIGV4aXN0aW5nIHByb3RvY29sLCBvcmllbnRhdGVkIHRvd2FyZHMgYXVk
aW8gcGxheWJhY2sgYW5kIHJlY29yZGluZy4gQXMgc3VjaCwgaXQgaGFzIHN1cHBvcnQgZm9yIFJU
UCBzZXNzaW9uIGNvbnRyb2wsIHdpdGggU0RQIHVzZWQgZm9yIHNlc3Npb24gZGVzY3JpcHRpb24s
IGFuZCBhIG1lc3NhZ2Ugc2V0IGFsbG93aW5nIG9wZXJhdGlvbiBhcyBhIHBsYXllci9yZWNvcmRl
ciB3aXRoIGF1ZGlvIJNWQ1KUIGNvbnRyb2xzLiBUaGlzIGNvbXBhcmlzb24gb25seSBhZGRyZXNz
ZXMgdGhlIGV4aXN0aW5nIHJlc291cmNlIGNvbnRyb2wgZWxlbWVudHMgaGVyZSBhbmQgdGhlaXIg
YXBwbGljYWJpbGl0eSB0byB0aGUgc3BlZWNoc2MgcmVxdWlyZW1lbnRzLg0NVGhlIGN1cnJlbnQg
UExBWSBzdGF0ZSBtYWNoaW5lIGlzIGV4YWN0bHkgYXMgcmVxdWlyZWQgZm9yIFRUUyBvcGVyYXRp
b24uIEFsdGhvdWdoIGJ5IGFuYWxvZ3kgUkVDT1JEIGNvdWxkIGluaXRpYXRlIGFuIEFTUiBzZXNz
aW9uLCB3aXRoIGhlYWRlcnMgZ2l2aW5nIHRoZSBncmFtbWVyIHNvdXJjZSBvciByZWZlcmVuY2Vz
LCBpdJJzIHN0YXRlIG1hY2hpbmUgaXMgbm90IG5lYXJseSBhcyBjb21wYXRpYmxlLCBhbmQgbm90
IGF0IGFsbCBmb3IgU1YvU0kuIA1BbmFseXNpcyBvZiBUVFMgcmVxdWlyZW1lbnRzDVJlcXVlc3Rp
bmcgVGV4dCBQbGF5YmFjayBbNi4xXQ1QKzogdGhlIFJUU1AgUExBWSBtZXNzYWdlIHNlbWFudGlj
cyB3b3VsZCByZXF1aXJlIG1pbm9yIGV4dGVuc2lvbnMNVGV4dCBGb3JtYXRzIFs2LjJdDVArOiBU
ZXh0IGNhbiBiZSBkZWZpbmVkIGFzIGFsbCB0ZXh0IHR5cGVzLiANUGxhaW4gdGV4dCBbNi4yLjFd
DVQ6IFBsYWluIHRleHQgbWF5IGJlIGNhcnJpZWQgZGlyZWN0bHkgaW4gdGhlIG1lc3NhZ2UgcGF5
bG9hZC4NU1NNTCBbNi4yLjJdDVQ6IFRleHQgbWF5IGJlIGluIGFueSBmb3JtYXQuDVRleHQgaW4g
Q29udHJvbCBDaGFubmVsIFs2LjIuM10NVDogVGV4dCBtYXkgYmUgYXR0YWNoZWQgdG8gdGhlIGNv
bnRyb2wgbWVzc2FnZXMuDURvY3VtZW50IFR5cGUgSW5kaWNhdGlvbiBbNi4yLjRdDVSgOiBWaWEg
dGhlIENvbnRlbnQtVHlwZSBoZWFkZXINQ29udHJvbCBDaGFubmVsIFs2LjNdDVQ6IFJUU1Agc2Vz
c2lvbnMgbWF5IHVzZSBhIHByaXZhdGUgb3Igc2hhcmVkIFRDUCBjb25uZWN0aW9uLg1QbGF5YmFj
ayBDb250cm9scyBbNi40XQ1UOiBSVFNQIGRlZmluZXMgcGxheWJhY2sgY29udHJvbCBtZXNzYWdl
cyBhbmQgYSBzdGF0ZSBtYWNoaW5lLg1TZXNzaW9uIFBhcmFtZXRlcnMgWzYuNV0NVDogUlRTUCBk
ZWZpbmVzIG9wZXJhdGlvbnMgZm9yIHNlc3Npb24gcGFyYW1ldGVyIGNvbnRyb2wuDVNwZWVjaCBN
YXJrZXJzIFs2LjZdDVArOiBNYXJrZXJzIG1heSBiZSBpbnNlcnRlZCBpbiB0aGUgdGV4dCwgYnV0
IHRvIHByb3ZpZGUgdGhlIHJlcXVpcmVkIGFzeW5jaHJvbm91cyBldmVudHMgd2hlbiBhIG1hcmtl
ciBpcyBzeW50aGVzaXplZCB3aWxsIHJlcXVpcmUgdXNlIHNwZWNpZmljIEFOTk9VTkNFIHR5cGUg
bWVzc2FnZXMgZm9yIHNlcnZlci0+Y2xpZW50IG5vdGlmaWNhdGlvbi4NQW5hbHlzaXMgb2YgQVNS
IHJlcXVpcmVtZW50cw1SZXF1ZXN0aW5nIEF1dG9tYXRpYyBTcGVlY2ggUmVjb2duaXRpb24gWzcu
MV0NUDogVGhlIFJFQ09SRCBtZXNzYWdlIGFuZCBzZW1hbnRpY3MgY291bGQgYmUgdXNlZCBidXQg
d291bGQgcmVxdWlyZSBleHRlbnNpb25zIChzdHJldGNoaW5nIHRoZSBjdXJyZW50IHNlbWFudGlj
IHF1aXRlIGEgbG90KQ1YTUwgWzcuMl0NUCs6IFRleHQgY2FuIGJlIGRlZmluZWQgYXMgYWxsIHRl
eHQgdHlwZXMuDUdyYW1tYXIgU3BlY2lmaWNhdGlvbiBbNy4zLjFdDVArOiBUZXh0IGNhbiBiZSBk
ZWZpbmVkIGFzIGFsbCB0ZXh0IHR5cGVzLg1FeHBsaWNpdCBJbmRpY2F0aW9uIG9mIEdyYW1tYXIg
Rm9ybWF0IFs3LjMuMl0NVKA6IFZpYSB0aGUgQ29udGVudC1UeXBlIGhlYWRlcnMNR3JhbW1hciBT
aGFyaW5nIFs3LjMuM10NRjogVEJEDVNlc3Npb24gUGFyYW1ldGVycyBbNy40XQ1UOiBSVFNQIGRl
ZmluZXMgb3BlcmF0aW9ucyBmb3Igc2Vzc2lvbiBwYXJhbWV0ZXIgY29udHJvbC4NSW5wdXQgQ2Fw
dHVyZSBbNy41XQ1QKzogd291bGQgcmVxdWlyZSBhZGRpdGlvbiBvZiBhIGhlYWRlciB0byB0aGUg
aW5pdGlhdGlvbiBtZXNzYWdlLg1BbmFseXNpcyBvZiBTcGVha2VyIElkZW50aWZpY2F0aW9uIGFu
ZCBWZXJpZmljYXRpb24gUmVxdWlyZW1lbnRzDVJlcXVlc3RpbmcgU0kvU1YgWzguMV0NRjogbm90
IHN1cHBvcnRlZA1JZGVudGlmaWVycyBmb3IgU0kvU1YgWzguMl0NRjogbm90IHN1cHBvcnRlZA1T
dGF0ZSBmb3IgbXVsdGlwbGUgdXR0ZXJhbmNlcyBbOC4zXQ1GOiBub3Qgc3VwcG9ydGVkDUlucHV0
IENhcHR1cmUgWzguNF0NRjogbm90IHN1cHBvcnRlZA1TSS9TViBmdW5jdGlvbmFsIGV4dGVuc2li
aWxpdHkgWzguNV0NRjogbm90IHN1cHBvcnRlZA0NICAgIA1TZWN1cml0eSBDb25zaWRlcmF0aW9u
cyANIA1TZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgdGhlIFNQRUVDSFNDIHByb3RvY29sIGFy
ZSBjb3ZlcmVkIGJ5IHRoZSBjb21wYXJpc29uIGFnYWluc3QgdGhlIHNwZWNpZmljIFNlY3VyaXR5
IHJlcXVpcmVtZW50cyBpbiB0aGUgU1BFRUNIU0MgcmVxdWlyZW1lbnRzIGRvY3VtZW50IFsxXS4g
DSAgICANUmVmZXJlbmNlcyANWzFdIEUuIEJ1cmdlciwgk1JlcXVpcmVtZW50cyBmb3IgRGlzdHJp
YnV0ZWQgQ29udHJvbCBvZiBBU1IsIFNSIGFuZCBUVFMgUmVzb3VyY2VzIiBkcmFmdC1pZXRmLXNw
ZWVjaHNjLXJlcXRzLTAwLnR4dCwgSnVseSAzMSwgMjAwMi4NDVsyXSBKLiBSb3NlbmJlcmcsIEgu
IFNjaHVsenJpbm5lLCBHLiBDYW1hcmlsbG8sIEEuIEpvaG5zdG9uLCBKLiBQZXRlcnNvbiwgUi4g
U3BhcmtzLCBNLiBIYW5kbGV5LCBFLlNjaG9vbGVyLCBTSVA6IFNlc3Npb24gSW5pdGlhdGlvbiBQ
cm90b2NvbCwgUkZDMzI2NSwgSnVuZSAyMDAyLiAoT2Jzb2xldGVzIFJGQzI1NDMpDQ1bV1MxXSBX
M0MgV2ViIFNlcnZpY2VzLCBodHRwOi8vd3d3LnczYy5vcmcvMjAwMi93cy8NW1dTMl0gU2ltcGxl
IE9iamVjdCBBY2Nlc3MgUHJvdG9jb2wgKFNPQVApIGh0dHA6Ly93d3cudzNjLm9yZy8yMDAyL3dz
Lw1bV1MzXSBXZWIgU2VydmljZXMgRGVzY3JpcHRpb24gTGFuZ3VhZ2UgKFdTREwgMS4xKSwgVzND
IE5vdGUgMTUgTWFyY2ggDSAgICAyMDAxLCBodHRwOi8vd3d3LnczLm9yZy9UUi93c2RsLg1bV1M0
XSBMZXltYW5uLCBGLiwgV2ViIFNlcnZpY2UgRmxvdyBMYW5ndWFnZSwgV1NGTCAxLjAsIE1heSAy
MDAxLCANICAgICBodHRwOi8vd3d3LTQuaWJtLmNvbS9zb2Z0d2FyZS9zb2x1dGlvbnMvd2Vic2Vy
dmljZXMvcGRmL1dTRkwucGRmDVtXUzVdIFVEREksIGh0dHA6Ly93d3cudWRkaS5vcmcvc3BlY2lm
aWNhdGlvbi5odG1sIA1bV1M2XSBXM0MgVm9pY2UgQWN0aXZpdHksIGh0dHA6Ly93d3cudzNjLm9y
Zy9Wb2ljZS8gDVtXUzddIFdTWEwgLSBXZWIgU2VydmljZSBlWHBlcmllbmNlIExhbmd1YWdlIHN1
Ym1pdHRlZCB0byBPQVNJUyBXU0lBIA0gICAgIAlhbmQgV1NSUCAtIFdTWEwgLSBXZWIgU2Vydmlj
ZSBlWHBlcmllbmNlIExhbmd1YWdlIHN1Ym1pdHRlZCB0byANICAgIAkgT0FTSVMgV1NJQSBhbmQg
V1NSUA1bV1M4XSBSZXF1aXJlbWVudHMgZm9yIERpc3RyaWJ1dGVkIENvbnRyb2wgb2YgQVNSLCBT
SS9TViBhbmQgVFRTIFJlc291cmNlcywgDWRyYWZ0LWlldGYtc3BlZWNoc2MtcmVxdHMtMDEudHh0
DVtXUzldIFNlY3VyaXR5IGluIGEgV2ViIFNlcnZpY2VzIFdvcmxkOiBBIFByb3Bvc2VkIEFyY2hp
dGVjdHVyZSBhbmQgUm9hZG1hcCwgDUFwcmlsIDcsIDIwMDIsIFZlcnNpb24gMS4wLCBodHRwOi8v
d3d3LnZlcmlzaWduLmNvbS93c3Mvd3NzLnBkZg1bV1MxMF0gS2FwaWwgQXBzaGFua2FyLCBXUy1T
ZWN1cml0eSwgU2VjdXJpdHkgZm9yIFdlYiBTZXJ2aWNlcywNaHR0cDovL3d3dy53ZWJzZXJ2aWNl
c2FyY2hpdGVjdC5jb20vY29udGVudC9hcnRpY2xlcy9hcHNoYW5rYXIwNC5hc3ANW1dTMTFdIE9B
U0lTIFdlYiBTZXJ2aWNlcyBTZWN1cml0eSBUQywgaHR0cDovL3d3dy5vYXNpcy1vcGVuLm9yZy9j
b21taXR0ZWVzL3dzcy8NDUF1dGhvcpJzIEFkZHJlc3MNICAgIA1CcmlhbiBXeWxkIA1FbG9xdWFu
dCBTQQ1aQSBNYWx2YWlzaW4JCQkJCQkgUGhvbmU6ICArMzMgNDc2IDc3IDQ2IDkyIA1MZSBWZXJz
b3VkLCBGcmFuY2UgICAgICAgICAgICAgRW1haWw6ICBicmlhbi53eWxkQGVsb3F1YW50LmNvbSAN
ICAgIA0gDUZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudA0gICANQ29weXJpZ2h0IChDKSBUaGUgSW50
ZXJuZXQgU29jaWV0eSAoMjAwMikuICBBbGwgUmlnaHRzIFJlc2VydmVkLg0gICANVGhpcyBkb2N1
bWVudCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQgYW5kIGZ1cm5pc2hlZCB0
bw1vdGhlcnMsIGFuZCBkZXJpdmF0aXZlIHdvcmtzIHRoYXQgY29tbWVudCBvbiBvciBvdGhlcndp
c2UgZXhwbGFpbiBpdA1vciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9uIG1heSBiZSBwcmVw
YXJlZCwgY29waWVkLCBwdWJsaXNoZWQNYW5kIGRpc3RyaWJ1dGVkLCBpbiB3aG9sZSBvciBpbiBw
YXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9uIG9mIGFueQ1raW5kLCBwcm92aWRlZCB0aGF0IHRoZSBh
Ym92ZSBjb3B5cmlnaHQgbm90aWNlIGFuZCB0aGlzIHBhcmFncmFwaA1hcmUgaW5jbHVkZWQgb24g
YWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiAgSG93ZXZlciwgdGhpcw1kb2N1
bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJl
bW92aW5nDXRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8gdGhlIEludGVybmV0
IFNvY2lldHkgb3Igb3RoZXINSW50ZXJuZXQgb3JnYW5pemF0aW9ucywgZXhjZXB0IGFzIG5lZWRl
ZCBmb3IgdGhlIHB1cnBvc2Ugb2YNZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hp
Y2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3INY29weXJpZ2h0cyBkZWZpbmVkIGluIHRoZSBJbnRl
cm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlDWZvbGxvd2VkLCBvciBhcyByZXF1aXJlZCB0
byB0cmFuc2xhdGUgaXQgaW50byBsYW5ndWFnZXMgb3RoZXIgdGhhbg1FbmdsaXNoLiAgVGhlIGxp
bWl0ZWQgcGVybWlzc2lvbnMgZ3JhbnRlZCBhYm92ZSBhcmUgcGVycGV0dWFsIGFuZA13aWxsIG5v
dCBiZSByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9y
DWFzc2lnbnMuICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkDWhl
cmVpbiBpcyBwcm92aWRlZCBvbiBhbiAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09D
SUVUWSBBTkQNVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU1TIEFM
TCBXQVJSQU5USUVTLA1FWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlU
RUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQNVEhFIFVTRSBPRiBUSEUgSU5GT1JNQVRJT04gSEVSRUlO
IFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1INQU5ZIElNUExJRUQgV0FSUkFOVElFUyBP
RiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQQ1QQVJUSUNVTEFSIFBVUlBPU0UuIg0N
DQ0NDQ0MQkVFUCBTTklQUw1BbmFseXNpcyBvZiBUVFMgcmVxdWlyZW1lbnRzDVJlcXVlc3Rpbmcg
VGV4dCBQbGF5YmFjayBbNi4xXQ1QKzogQSBtZWRpYWwgcGxheWJhY2sgcmVzb3VyY2Ugd291bGQg
YmUgZGVmaW5lZCBhcyBhIG5ldyBCRUVQIHByb2ZpbGUuDVRvIGluaXRpYXRlIGFuIG1lZGlhIHBs
YXliYWNrIHNlc3Npb24sIHRoZSBjbGllbnQgd291bGQgbmVlZCB0byBhc2sgZm9yIHRoaXMgcHJv
ZmlsZSBhcyBwYXJ0IG9mIHRoZSA8c3RhcnQ+IG1lc3NhZ2Ugd2hpY2ggb3BlbnMgYSBuZXcgY2hh
bm5lbC4NVGV4dCBGb3JtYXRzIFs2LjJdDQ1UOiBCRUVQIGFsbG93cyBhcmJpdHJhcnkgZGF0YSBi
bG9ja3Mgb2Ygb2N0ZXRzIHRvIGJlIHBhc3NlZC4gTWVzc2FnZXMgbXVzdCBzcGVjaWZ5IGEgbGVu
Z3RoIGFuZCBtdXN0IGVuZCB3aXRoIGEgc3BlY2lmaWMgc2VxdWVuY2Ugb2YgY2hhcmFjdGVycy4g
UGxhaW4gdGV4dCwgU1NNTCwgVVJJcywgb3Igb3RoZXIgY29udGVudCBjb3VsZCBiZSBwYXNzZWQg
d2l0aGluIEJFRVAgbWVzc2FnZXMuDVBsYWluIHRleHQgWzYuMi4xXQ0NVDogU2VlIDxUZXh0IEZv
cm1hdHM+DVNTTUwgWzYuMi4yXQ0NVDogU2VlIDxUZXh0IEZvcm1hdHM+DVRleHQgaW4gQ29udHJv
bCBDaGFubmVsIFs2LjIuM10NDVQ6IFNlZSA8VGV4dCBGb3JtYXRzPg1Eb2N1bWVudCBUeXBlIElu
ZGljYXRpb24gWzYuMi40XQ0NVDogQkVFUCBwcm92aWRlcyBmb3IgJ0NvbnRlbnQtVHlwZScgc3Bl
Y2lmaWNhdGlvbiBpbiB0aGUgbWVzc2FnZSBoZWFkZXIuIFRoaXMgbWF5IGJlIHVzZWQgdG8gZGV0
ZXJtaW5lIHRoZSBtZWRpYSB0eXBlIG9mIHRoZSBtZXNzYWdlLg1Db250cm9sIENoYW5uZWwgWzYu
M10NDVQ6IEEgc2Vjb25kIGNoYW5uZWwgbWlnaHQgYmUgY3JlYXRlZCB0byBwYXNzIGNvbnRyb2wg
aW5mb3JtYXRpb24uIFRoZSBCRUVQIHByb3RvY29sIGRpY3RhdGVzIHRoYXQgdGhlIHJlcXVlc3Rz
IGZvciBlYWNoIGNoYW5uZWwgbXVzdCBiZSBoYW5kbGVkIGluIHRoZSBvcmRlciBpbiB3aGljaCB0
aGV5IGFyZSByZWNlaXZlZC4gU2VwYXJhdGUgY2hhbm5lbHMgb3BlcmF0ZSBpbmRlcGVuZGVudGx5
IGFuZCBtYXkgc2VydmljZSByZXF1ZXN0IHdpdGggZGlmZmVyZW50IHByaW9yaXRpZXMgKHRob3Vn
aCB0aGUgQkVFUCBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IHByb3ZpZGUgYSBtZWNoYW5pc20gZm9y
IGFzc2lnbmluZyBwcmlvcml0aWVzKS4NUGxheWJhY2sgQ29udHJvbHMgWzYuNF0NDVQ6IFNlZSA2
LjMuIFRoZXNlIG1lc3NhZ2VzIHdvdWxkIHByZXN1bWFibHkgYmUgdHJhbnNtaXR0ZWQgb3ZlciB0
aGUgY29udHJvbCBjaGFubmVsLg1TZXNzaW9uIFBhcmFtZXRlcnMgWzYuNV0NDVQ6IFNlZSA2LjIu
IFNlc3Npb24gcGFyYW1ldGVycyBhcmUgcHJlc3VtYWJseSBjb250ZW50IGRlbGl2ZXJlZCB3aXRo
aW4gYSBtZXNzYWdlLg1TcGVlY2ggTWFya2VycyBbNi42XQ0NVDogU3BlZWNoIG1hcmtlcnMgbWln
aHQgYmUgZGVsaXZlcmVkIG9uIGEgc2VwYXJhdGUgY2hhbm5lbCAoYXMgaW4gNi4zKS4gDUFsdGVy
bmF0aXZlbHksIEJFRVAgaXMgYSBwZWVyLXRvLXBlZXIgcHJvdG9jb2wgc28gZXZlbnRzIG1pZ2h0
IGJlIHNlbnQgb24gdGhlIGNoYW5uZWwgdXNlZCB0byByZWNlaXZlIHJlcXVlc3RzLg1BbmFseXNp
cyBvZiBBU1IgcmVxdWlyZW1lbnRzDVJlcXVlc3RpbmcgQXV0b21hdGljIFNwZWVjaCBSZWNvZ25p
dGlvbiBbNy4xXQ0NUCs6IEFuIEFTUiByZXNvdXJjZSB3b3VsZCBiZSBkZWZpbmVkIGFzIGEgbmV3
IEJFRVAgcHJvZmlsZS4gVG8gaW5pdGlhdGUgYW4gQVNSIHNlc3Npb24sIHRoZSBjbGllbnQgd291
bGQgbmVlZCB0byBhc2sgZm9yIHRoaXMgcHJvZmlsZSBhcyBwYXJ0IG9mIHRoZSA8c3RhcnQ+IG1l
c3NhZ2Ugd2hpY2ggb3BlbnMgYSBuZXcgY2hhbm5lbC4NWE1MIFs3LjJdDQ1UOiBTZWUgcmVzcG9u
c2UgZm9yIDYuMi4NR3JhbW1hciBTcGVjaWZpY2F0aW9uIFs3LjMuMV0NDVQ6IFNlZSByZXNwb25z
ZSBmb3IgNi4yLg1FeHBsaWNpdCBJbmRpY2F0aW9uIG9mIEdyYW1tYXIgRm9ybWF0IFs3LjMuMl0N
DVQ6IFNlZSByZXNwb25zZSBmb3IgNi4yLjQuDUdyYW1tYXIgU2hhcmluZyBbNy4zLjNdDQ1QKzog
Q2hhbm5lbHMgaW4gQkVFUCBhcmUgaW5kZXBlbmRlbnQuIElmIGNvbnRlbnQgaXMgdG8gYmUgc2hh
cmVkLCB0aGlzIHdvdWxkIG5lZWQgdG8gYmUgYWRkZWQsIHByZWZlcmFibHkgdXNpbmcgbWVzc2Fn
ZXMgdG8gZGVmaW5lIHdoYXQgY29udGVudCBpcyB0byBiZSBzaGFyZWQgYW5kIGEgY29ycmVzcG9u
ZGluZyBpZGVudGl0eS4gVGhlIHJldHJpZXZhbCBhbmQgYWN0dWFsIHNoYXJpbmcgd291bGQgbmVl
ZCB0byBiZSBpbXBsZW1lbnRlZCBieSB0aGUgc2VydmVyLg1TZXNzaW9uIFBhcmFtZXRlcnMgWzcu
NF0NDVQ6IFNlZSByZXNwb25zZSBmb3IgNi4yLiBTZXNzaW9uIHBhcmFtZXRlcnMgYXJlIHByZXN1
bWFibHkgY29udGVudCBkZWxpdmVyZWQgd2l0aGluIGEgbWVzc2FnZS4NSW5wdXQgQ2FwdHVyZSBb
Ny41XQ0NUCs6IEJFRVAgZG9lcyBub3QgcHJvdmlkZSBhIG1lY2hhbmlzbSBmb3Igc3RvcmluZyBy
ZXF1ZXN0cy4gU3RvcmluZyBvZiBpbnB1dCBjb3VsZCBiZSBhZGRlZCBieSB0aGUgc2VydmVyLg1B
bmFseXNpcyBvZiBTcGVha2VyIElkZW50aWZpY2F0aW9uIGFuZCBWZXJpZmljYXRpb24gUmVxdWly
ZW1lbnRzDVJlcXVlc3RpbmcgU0kvU1YgWzguMV0NDVArOiBBbiBTSS9TViByZXNvdXJjZSB3b3Vs
ZCBiZSBkZWZpbmVkIGFzIGEgbmV3IEJFRVAgcHJvZmlsZS4gVG8gaW5pdGlhdGUgYW4gU0kvU1Yg
c2Vzc2lvbiwgdGhlIGNsaWVudCB3b3VsZCBuZWVkIHRvIGFzayBmb3IgdGhpcyBwcm9maWxlIGFz
IHBhcnQgb2YgdGhlIDxzdGFydD4gbWVzc2FnZSB3aGljaCBvcGVucyBhIG5ldyBjaGFubmVsLg1J
ZGVudGlmaWVycyBmb3IgU0kvU1YgWzguMl0NDVQ6IFRoaXMgY291bGQgYmUgaGFuZGxlZCBpbiB0
aGUgJ0NvbnRlbnQtVHlwZScgb3IgYnkgb3RoZXIgbWVhbnMuDVN1cHBvcnRlZCBmb3JtYXRzIG1p
Z2h0IGJlIG5lZ290aWF0ZWQgaW4gYSBmYXNoaW9uIHNpbWlsYXIgdG8gc2VjdXJpdHkgbmVnb3Rp
YXRpb24uDVN0YXRlIGZvciBtdWx0aXBsZSB1dHRlcmFuY2VzIFs4LjNdDQ1QKzogQkVFUCBoYXMg
YSBjb25jZXB0IG9mIHNlcXVlbmNlLiBTdGF0ZSB3b3VsZCBuZWVkIHRvIGJlIGFkZGVkIGJ5IHRo
ZSBjbGllbnQuIFRoaXMgc2hvdWxkIGJlIGVhc3kgaWYgYSBjaGFubmVsIGlzIHVzZWQgZm9yIG11
bHRpcGxlIHV0dGVyYW5jZXMuDUlucHV0IENhcHR1cmUgWzguNF0NDVArOiBCRUVQIGRvZXMgbm90
IHByb3ZpZGUgYSBtZWNoYW5pc20gZm9yIHN0b3JpbmcgcmVxdWVzdHMuIFN0b3Jpbmcgb2YgaW5w
dXQgY291bGQgYmUgYWRkZWQgYnkgdGhlIHNlcnZlci4NU0kvU1YgZnVuY3Rpb25hbCBleHRlbnNp
YmlsaXR5IFs4LjVdDQ1UOiBFeHRlbnNpb25zIGNvdWxkIGJlIGFkZGVkIGFzIGFkZGl0aW9uYWwg
bWVzc2FnZXMuDQ0NDFNJUCBTTklQUw1BbmFseXNpcyBvZiBUVFMgcmVxdWlyZW1lbnRzDVJlcXVl
c3RpbmcgVGV4dCBQbGF5YmFjayBbNi4xXQ1QKzogU0lQIGRvZXMgbm90IHByb3ZpZGUgcHJpbWl0
aXZlcyBmb3IgdGV4dCBwbGF5YmFjay4gTmV3IFNJUCBVUkkgY2FuIGJlIGRlZmluZWQgdG8gaW52
b2tlIFRUUyBmZWF0dXJlcy4gWE1MIHNjaGVtYSBuZWVkcyB0byBiZSBkZWZpbmVkIGZvciBUVFMg
cGxheSBhbmQgcGxheWJhY2sgY29udHJvbCBwcmltaXRpdmVzLg1UZXh0IEZvcm1hdHMgWzYuMl0N
VDogU0lQIG1lc3NhZ2UgYm9keSBjYW4gY2FycnkgVFRTIHRleHQgb3IgcmVmZXJlbmNlIHRvIHRo
ZSBUVFMgdGV4dC4gVGhlIHRleHQgZm9ybWF0IGNhbiBiZSBzcGVjaWZpZWQgYnkgbWltZSB0eXBl
Lg1QbGFpbiB0ZXh0IFs2LjIuMV0NVDogUmVmZXIgdG8gMTIuNC4yLg1TU01MIFs2LjIuMl0NVDog
UmVmZXIgdG8gMTIuNC4yLg1UZXh0IGluIENvbnRyb2wgQ2hhbm5lbCBbNi4yLjNdDVSgOlJlZmVy
IHRvIDEyLjQuMi4NRG9jdW1lbnQgVHlwZSBJbmRpY2F0aW9uIFs2LjIuNF0NVDogUmVmZXIgdG8g
MTIuNC4yLg1Db250cm9sIENoYW5uZWwgWzYuM10NUCs6IFhNTCBzY2hlbWEgZGVmaW5pdGlvbiBu
ZWVkcyB0byBpbmNsdWRlIGZpZWxkcyB0byBpZGVudGlmeSBjb250cm9sIG1lc3NhZ2VzLiBJbiBh
ZGRpdGlvbiwgYSBzZXBhcmF0ZSBTSVAgVVJJIGNhbiBhbHNvIGJlIGRlZmluZWQgZm9yIGNvbnRy
b2wgY2hhbm5lbC4gDVBsYXliYWNrIENvbnRyb2xzIFs2LjRdDVArOiBSZWZlciB0byAxMi40LjEu
DVNlc3Npb24gUGFyYW1ldGVycyBbNi41XQ1QKzogU2Vzc2lvbiBwYXJhbWV0ZXJzIG5lZWQgdG8g
YmUgZGVmaW5lZCBhcyBwYXJ0IG9mIFhNTCBzY2hlbWEuIFRoZXkgY2FuIGJlIHBhc3NlZCBpbiBi
b2R5IHBhcnQgb2YgU0lQIGFuZC9vciBjYW4gYmUgbW9kaWZpZWQgYnkgIG1pZCBjYWxsIFNJUCBJ
TkZPIG1ldGhvZC4NU3BlZWNoIE1hcmtlcnMgWzYuNl0NDVQ6IFNwZWVjaCBtYXJrZXJzIGNhbiBi
ZSBkZWxpdmVyZWQgdXNpbmcgYSBzZXBhcmF0ZSBjb250cm9sIGNoYW5uZWwuIFJlZmVyIHRvIDEy
LjQuNy4NQW5hbHlzaXMgb2YgQVNSIHJlcXVpcmVtZW50cw1SZXF1ZXN0aW5nIEF1dG9tYXRpYyBT
cGVlY2ggUmVjb2duaXRpb24gWzcuMV0NUCs6IFNJUCBkb2VzIG5vdCBwcm92aWRlIHByaW1pdGl2
ZXMgZm9yIEFTUiBzZXJ2aWNlcy4gTmV3IFNJUCBVUkkgY2FuIGJlIGRlZmluZWQgdG8gYWRkcmVz
cyBBU1Igc2VydmljZXMgYW5kIHJlcXVlc3RpbmcgQVNSIHJlc291cmNlcy4gWE1MIHNjaGVtYSBu
ZWVkcyB0byBiZSBkZWZpbmVkIGZvciBBU1IgcHJpbWl0aXZlcy4NWE1MIFs3LjJdDVQ6IFNJUCBt
ZXNzYWdlIGJvZHkgY2FuIGNhcnJ5IFhNTC4NR3JhbW1hciBTcGVjaWZpY2F0aW9uIFs3LjMuMV0N
UCs6IEJ5IGRlZmluaW5nIG5ldyBtaW1lIHR5cGVzLCBTSVAgbWVzc2FnZSBib2R5IGNhbiBjYXJy
eSBkaWZmZXJlbnQgWE1MIGdyYW1tYXJzLiBUaGUgbWVzc2FnZSBib2R5IGNhbiBhbHNvIGhhdmUg
YSBVUkkgcmVmZXJlbmNlIHRvIHRoZSBYTUwgZ3JhbW1hci4NDUV4cGxpY2l0IEluZGljYXRpb24g
b2YgR3JhbW1hciBGb3JtYXQgWzcuMy4yXQ1QKzogUmVmZXIgdG8gMTIuNS4zLg1HcmFtbWFyIFNo
YXJpbmcgWzcuMy4zXQ1UQkQNU2Vzc2lvbiBQYXJhbWV0ZXJzIFs3LjRdDVArOiBTZXNzaW9uIHBh
cmFtZXRlcnMgbmVlZCB0byBiZSBkZWZpbmVkIGFzIHBhcnQgb2YgWE1MIHNjaGVtYS4gVGhleSBj
YW4gYmUgcGFzc2VkIGluIGJvZHkgcGFydCBvZiBTSVAgYW5kL29yIGNhbiBiZSBtb2RpZmllZCBi
eSAgbWlkLWNhbGwgU0lQIElORk8gbWV0aG9kLg1JbnB1dCBDYXB0dXJlIFs3LjVdDVQ6IFNJUCBT
VUJTQ1JJQkUvTk9USUZZIG1lY2hhbmlzbSBjYW4gYmUgdXNlZCBpbml0aWF0ZSBpbnB1dCBjYXB0
dXJlIGFuZCByZWNlaXZlIHRoZSByZXN1bHQuIA0NQW5hbHlzaXMgb2YgU3BlYWtlciBJZGVudGlm
aWNhdGlvbiBhbmQgVmVyaWZpY2F0aW9uIFJlcXVpcmVtZW50cw1SZXF1ZXN0aW5nIFNJL1NWIFs4
LjFdDVArOiBTSVAgZG9lcyBub3QgcHJvdmlkZSBwcmltaXRpdmVzIGZvciBTSS9TViBzZXJ2aWNl
cy4gTmV3IFNJUCBVUkkgY2FuIGJlIGRlZmluZWQgdG8gYWRkcmVzcyBTSS9TViBzZXJ2aWNlcyBh
bmQgcmVxdWVzdGluZyBTSS9TViByZXNvdXJjZXMuIFhNTCBzY2hlbWEgbmVlZHMgdG8gYmUgZGVm
aW5lZCBmb3IgU0kvU1YgcHJpbWl0aXZlcy4NSWRlbnRpZmllcnMgZm9yIFNJL1NWIFs4LjJdDVAr
OiBSZWZlciB0byAxMi42LjEuDVN0YXRlIGZvciBtdWx0aXBsZSB1dHRlcmFuY2VzIFs4LjNdDVRC
RA1JbnB1dCBDYXB0dXJlIFs4LjRdDVQ6IFNJUCBTVUJTQ1JJQkUvTk9USUZZIG1lY2hhbmlzbSBj
YW4gYmUgdXNlZCBpbml0aWF0ZSBpbnB1dCBjYXB0dXJlIGFuZCByZWNlaXZlIHRoZSByZXN1bHQu
DVNJL1NWIGZ1bmN0aW9uYWwgZXh0ZW5zaWJpbGl0eSBbOC41XQ1QKzogWE1MIHNjaGVtYSBjYW4g
ZWFzaWx5IGJlIGV4dGVuZGVkIGJ5IGFkZGluZyBuZXcgdGFncyBhbmQgcHJpbWl0aXZlcyB3aXRo
b3V0IGltcGFjdGluZyB0aGUgb3BlcmF0aW9uIG9mIGV4aXN0aW5nIHRhZ3MuIA0NIAxXRUJTRVJW
SUNFIFNOSVBTDQ1BbmFseXNpcyBvZiBUVFMgcmVxdWlyZW1lbnRzDVJlcXVlc3RpbmcgVGV4dCBQ
bGF5YmFjayBbNi4xXQ1UOiAoc3VwcG9ydGVkIJYgc3ludGF4IHRvIGJlIGRlZmluZWQ7IHdoaWNo
IGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgd2ViIHNlcnZpY2UgZnJhbWV3b3JrKQ0NQXMgZGVzY3Jp
YmVkLCBUVFMgZW5naW5lcyBjYW4gYmUgcHJlLXByb2dyYW1tZWQgYXMgd2ViIHNlcnZpY2VzIHRv
IHBlcmZvcm0gVFRTIG9uIGluY29taW5nIHRleHQuIFRoaXMgaXMgc2ltcGx5IGEgbWF0dGVyIG9m
IGFncmVlaW5nIG9uIHRoZSBjb250cm9sIHN5bnRheCB0byBkbyBzby4gVGhlIHRleHQgdG8gcGxh
eSBiYWNrIGNhbiBiZSBwYXJ0IG9mIHRoZSBjb250cm9sIGluc3RydWN0aW9ucyB0cmFuc21pdHRl
ZCBpbiBTT0FQIHRvIHRoZSBUVFMgZW5naW5lLg1UZXh0IEZvcm1hdHMgWzYuMl0NVDogRXhjaGFu
Z2VkIGZvcm1hdCBmb3IgdGV4dCBjYW4gYmUgYW55IE1JTUUgdHlwZTsgaW5jbHVkaW5nIHBsYWlu
IHRleHQuDVBsYWluIHRleHQgWzYuMi4xXQ1UOiBFeGNoYW5nZWQgZm9ybWF0IGZvciB0ZXh0IGNh
biBiZSBhbnkgTUlNRSB0eXBlOyBpbmNsdWRpbmcgcGxhaW4gdGV4dC4NU1NNTCBbNi4yLjJdDVQ6
IEV4Y2hhbmdlZCBmb3JtYXQgZm9yIHRleHQgY2FuIGJlIGFueSBNSU1FIHR5cGU7IGluY2x1ZGlu
ZyBYTUwgYW5kIGhlbmNlIFNTTUwNVGV4dCBpbiBDb250cm9sIENoYW5uZWwgWzYuMi4zXQ1UQkQN
RG9jdW1lbnQgVHlwZSBJbmRpY2F0aW9uIFs2LjIuNF0NVDogU09BUCBhbmQgdGhlIHdlYiBzZXJ2
aWNlIGZyYW1ld29yayBidWlsdCBvbiBTT0FQIHJlbHkgb24gWE1MIGFuZCBNSU1FIHR5cGUgdG8g
aWRlbnRpZnkgbWVkaWEgdHlwZXMuIFRoaXMgaXMgYXQgdGhlIGNvcmUgb2YgZGF0YSBleGNoYW5n
ZSBpbiBTT0FQLg0NQ29udHJvbCBDaGFubmVsIFs2LjNdDVQ6IEFzIHByb3Bvc2VkIGFib3ZlLCBT
T0FQIFtXUzJdIGFuZCBXU0RMIFtXUzNdIHN1cHBvcnQgdGhlIHJlbW90ZSBjb250cm9sIG9mIHRo
ZSB3ZWIgc2VydmljZXMgKGVuZ2luZXMgb3IgbWVkaWEgcHJvY2Vzc2luZyBlbnRpdHkpLg1QbGF5
YmFjayBDb250cm9scyBbNi40XQ1UOiAoc3VwcG9ydGVkIJYgc3ludGF4IHRvIGJlIGRlZmluZWQ7
IHdoaWNoIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgd2ViIHNlcnZpY2UgZnJhbWV3b3JrKQ0NVGhp
cyBpcyBzaW1wbHkgYSBtYXR0ZXIgb2YgYWdyZWVpbmcgb24gdGhlIGNvbnRyb2wgc3ludGF4IHRv
IGRvIHNvIGFzIHBhcnQgb2YgdGhlIGNvbnRyb2wgaW5zdHJ1Y3Rpb25zIHRyYW5zbWl0dGVkIGlu
IFNPQVAgdG8gdGhlIFRUUyBlbmdpbmUuDVNlc3Npb24gUGFyYW1ldGVycyBbNi41XQ1UOiBTZXNz
aW9uIHBhcmFtZXRlcnMgYXJlIHByZXN1bWFibHkgY29udGVudCBkZWxpdmVyZWQgYXMgcGFydCBv
ZiB0aGUgY29udHJvbCBpbnN0cnVjdGlvbnMgdHJhbnNtaXR0ZWQgaW4gU09BUCB0byB0aGUgVFRT
IGVuZ2luZS4NDVNwZWVjaCBNYXJrZXJzIFs2LjZdDVQ6IFNwZWVjaCBtYXJrZXJzIGFyZSBwcmVz
dW1hYmx5IGNvbnRlbnQgZGVsaXZlcmVkIGFzIHBhcnQgb2YgdGhlIGNvbnRyb2wgaW5zdHJ1Y3Rp
b25zIHRyYW5zbWl0dGVkIGluIFNPQVAgdG8gdGhlIFRUUyBlbmdpbmUuDVtORExSIDogaG93IGFy
ZSB0aGUgbWFya2VyIGV2ZW50cyByZXR1cm5lZCB0byB0aGUgY2xpZW50IGVuZD9dDUFuYWx5c2lz
IG9mIEFTUiByZXF1aXJlbWVudHMNUmVxdWVzdGluZyBBdXRvbWF0aWMgU3BlZWNoIFJlY29nbml0
aW9uIFs3LjFdDVQ6IChzdXBwb3J0ZWQgliBzeW50YXggdG8gYmUgZGVmaW5lZDsgd2hpY2ggaXMg
Y29uc2lzdGVudCB3aXRoIHRoZSB3ZWIgc2VydmljZSBmcmFtZXdvcmspDQ1BcyBkZXNjcmliZWQs
IEFTUiBlbmdpbmVzIGNhbiBiZSBwcmUtcHJvZ3JhbW1lZCBhcyB3ZWIgc2VydmljZXMgdG8gcGVy
Zm9ybSBzcGVlY2ggcmVjb2duaXRpb24gb24gaW5jb21pbmcgYXVkaW8uIFRoaXMgaXMgc2ltcGx5
IGEgbWF0dGVyIG9mIGFncmVlaW5nIG9uIHRoZSBjb250cm9sIHN5bnRheCB0byBkbyBzby4gVGhl
IGluc3RydWN0aW9ucyBhbmQgcGFyYW1ldGVycyAoaW5jbHVkaW5nIGRhdGEgZmlsZXMgbGlrZSBn
cmFtbWFycyBldGOFKSBjYW4gYmUgcGFydCBvZiB0aGUgY29udHJvbCBpbnN0cnVjdGlvbnMgdHJh
bnNtaXR0ZWQgaW4gU09BUCB0byB0aGUgQVNSIGVuZ2luZS4gDQ1SZXN1bHRzIGNhbiBiZSBwYXJ0
IG9mIHRoZSB3ZWIgc2VydmljZSBtZXNzYWdpbmcgYXMgc3VwcG9ydGVkIGJ5IHRoZSB3ZWIgc2Vy
dmljZSBmcmFtZXdvcmsuDVhNTCBbNy4yXQ1UOiBFeGNoYW5nZWQgZm9ybWF0IGZvciBtZXNzYWdl
IGNhbiBiZSBhbnkgTUlNRSB0eXBlOyBpbmNsdWRpbmcgWE1MIGFuZCBoZW5jZSBYTUwgZm9yIGNv
bnRyb2xsaW5nIHRoZSBBU1IuDUdyYW1tYXIgU3BlY2lmaWNhdGlvbiBbNy4zLjFdDVQ6IEdyYW1t
YXIgc3BlY2lmaWNhdGlvbiBjYW4gYmUgcGFydCBvZiB0aGUgbWVzc2FnZXMgdG8gY29udHJvbCB0
aGUgQVNSLiBUaGlzIGluY2x1ZGVzIGFueSBNSU1FIHR5cGU7IGluY2x1ZGluZyBYTUwgZm9yIHBh
c3NpbmcgZ3JhbW1hcnMgYnkgdmFsdWVzLCBvdGhlciBNSU1FIGZvcm1hdCBpbmNsdWRpbmcgYmlu
YXJ5IGFuZCBVUkkgZm9yIHBhc3NpbmcgZ3JhbW1hcnMgYnkgcmVmZXJlbmNlLg1FeHBsaWNpdCBJ
bmRpY2F0aW9uIG9mIEdyYW1tYXIgRm9ybWF0IFs3LjMuMl0NVDogU09BUCBhbmQgdGhlIHdlYiBz
ZXJ2aWNlIGZyYW1ld29yayBidWlsdCBvbiBTT0FQIHJlbHkgb24gWE1MIGFuZCBNSU1FIHR5cGUg
dG8gaWRlbnRpZnkgbWVkaWEgdHlwZXMuIFRoaXMgaXMgYXQgdGhlIGNvcmUgb2YgZGF0YSBleGNo
YW5nZSBpbiBTT0FQLg1HcmFtbWFyIFNoYXJpbmcgWzcuMy4zXQ1UOiBUaGUgZnJhbWV3b3JrIGRl
c2NyaWJlZCBzdXBwb3J0cyBwcmUtcHJvZ3JhbW1pbmcgb2YgdGhlIGVuZ2luZXMgcGVyIHV0dGVy
YW5jZSwgcGVyIHNlc3Npb24gb3IgaW4gYW4gdW5saW1pdGVkIG1hbm5lci4gVGhpcyB3YXkgZ3Jh
bW1hciBzaGFyaW5nIGNhbiBlYXNpbHkgYmUgYWNoaWV2ZWQgYW5kIGNvbnRyb2xsZWQgYnkgYW4g
ZXh0ZXJuYWwgY29udHJvbGxlciwgYXBwbGljYXRpb24gZXRjhQ1TZXNzaW9uIFBhcmFtZXRlcnMg
WzcuNF0NVDogU2Vzc2lvbiBwYXJhbWV0ZXJzIGFyZSBwcmVzdW1hYmx5IGNvbnRlbnQgZGVsaXZl
cmVkIGFzIHBhcnQgb2YgdGhlIGNvbnRyb2wgaW5zdHJ1Y3Rpb25zIHRyYW5zbWl0dGVkIGluIFNP
QVAgdG8gdGhlIEFTUiBlbmdpbmUuDUlucHV0IENhcHR1cmUgWzcuNV0NVDogKHN1cHBvcnRlZCCW
IHN5bnRheCB0byBiZSBkZWZpbmVkOyB3aGljaCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIHdlYiBz
ZXJ2aWNlIGZyYW1ld29yaykNDUFzIGRlc2NyaWJlZCwgQVNSIGVuZ2luZXMgY2FuIGJlIHByZS1w
cm9ncmFtbWVkIGFzIHdlYiBzZXJ2aWNlcyB0byBwZXJmb3JtIHNwZWVjaCByZWNvZ25pdGlvbiBv
biBpbmNvbWluZyBhdWRpby4gVGhpcyBpcyBzaW1wbHkgYSBtYXR0ZXIgb2YgYWdyZWVpbmcgb24g
dGhlIGNvbnRyb2wgc3ludGF4IHRvIGRvIHNvLiBUaGUgaW5zdHJ1Y3Rpb25zIGFuZCBwYXJhbWV0
ZXJzIChpbmNsdWRpbmcgZGF0YSBmaWxlcyBsaWtlIGdyYW1tYXJzIGV0Y4UpIGNhbiBiZSBwYXJ0
IG9mIHRoZSBjb250cm9sIGluc3RydWN0aW9ucyB0cmFuc21pdHRlZCBpbiBTT0FQIHRvIHRoZSBB
U1IgZW5naW5lLiBUaGlzIGNhYiBpbmNsdWRlIHRoZSBzeW50YXggYW5kIGluc3RydWN0aW9ucyB0
byBjYXB0dXJlIHRoZSBhdWRpby4NQW5hbHlzaXMgb2YgU3BlYWtlciBJZGVudGlmaWNhdGlvbiBh
bmQgVmVyaWZpY2F0aW9uIFJlcXVpcmVtZW50cw1SZXF1ZXN0aW5nIFNJL1NWIFs4LjFdDVQ6IChz
dXBwb3J0ZWQgliBzeW50YXggdG8gYmUgZGVmaW5lZDsgd2hpY2ggaXMgY29uc2lzdGVudCB3aXRo
IHRoZSB3ZWIgc2VydmljZSBmcmFtZXdvcmspDQ1BcyBkZXNjcmliZWQsIFNJIG9yIFNWIGVuZ2lu
ZXMgY2FuIGJlIHByZS1wcm9ncmFtbWVkIGFzIHdlYiBzZXJ2aWNlcyB0byBwZXJmb3JtIHNwZWFr
ZXIgcmVjb2duaXRpb24gb24gaW5jb21pbmcgYXVkaW8uIFRoaXMgaXMgc2ltcGx5IGEgbWF0dGVy
IG9mIGFncmVlaW5nIG9uIHRoZSBjb250cm9sIHN5bnRheCB0byBkbyBzby4gVGhlIGluc3RydWN0
aW9ucyBhbmQgcGFyYW1ldGVycyAoaW5jbHVkaW5nIGRhdGEgZmlsZXMgbGlrZSB2b2ljZSBwcmlu
dHMsIGV0Y4UpIGNhbiBiZSBwYXJ0IG9mIHRoZSBjb250cm9sIGluc3RydWN0aW9ucyB0cmFuc21p
dHRlZCBpbiBTT0FQIHRvIHRoZSBTSSBvciBTViBlbmdpbmUuIA0NUmVzdWx0cyBjYW4gYmUgcGFy
dCBvZiB0aGUgd2ViIHNlcnZpY2UgbWVzc2FnaW5nIGFzIHN1cHBvcnRlZCBieSB0aGUgd2ViIHNl
cnZpY2UgZnJhbWV3b3JrLg1JZGVudGlmaWVycyBmb3IgU0kvU1YgWzguMl0NVDogVGhpcyBjYW4g
YmUgcGFydCBvZiB0aGUgY29udHJvbCBtZXNzYWdlLg1TdGF0ZSBmb3IgbXVsdGlwbGUgdXR0ZXJh
bmNlcyBbOC4zXQ1UOiBUaGlzIGNhbiBiZSBhY2hpZXZlZCBieSBhcHByb3ByaWF0ZWx5IHByb2dy
YW1taW5nIHRoZSBTSSBvciBTViBlbmdpbmUgYWNyb3NzIG11bHRpcGxlIHV0dGVyYW5jZXMuIFRo
aXMgaXMgc2ltcGx5IGEgbWF0dGVyIG9mIGFncmVlaW5nIG9uIHRoZSBjb250cm9sIHN5bnRheCB0
byBkbyBzby4gVGhlIGZyYW1ld29yayBkZXNjcmliZWQgaW4gc2VjdGlvbiAxIHN1cHBvcnQgc3Bh
bm5pbmcgbXVsdGlwbGUgdXR0ZXJhbmNlcy4NSW5wdXQgQ2FwdHVyZSBbOC40XQ1UOiAoc3VwcG9y
dGVkIJYgc3ludGF4IHRvIGJlIGRlZmluZWQ7IHdoaWNoIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUg
d2ViIHNlcnZpY2UgZnJhbWV3b3JrKQ0NQXMgZGVzY3JpYmVkLCBTSSBvciBTViBlbmdpbmVzIGNh
biBiZSBwcmUtcHJvZ3JhbW1lZCBhcyB3ZWIgc2VydmljZXMgdG8gcGVyZm9ybSBzcGVha2VyIHJl
Y29nbml0aW9uIG9uIGluY29taW5nIGF1ZGlvLiBUaGlzIGlzIHNpbXBseSBhIG1hdHRlciBvZiBh
Z3JlZWluZyBvbiB0aGUgY29udHJvbCBzeW50YXggdG8gZG8gc28uIFRoZSBpbnN0cnVjdGlvbnMg
YW5kIHBhcmFtZXRlcnMgKGluY2x1ZGluZyBkYXRhIGZpbGVzIGxpa2UgZ3JhbW1hcnMgZXRjhSkg
Y2FuIGJlIHBhcnQgb2YgdGhlIGNvbnRyb2wgaW5zdHJ1Y3Rpb25zIHRyYW5zbWl0dGVkIGluIFNP
QVAgdG8gdGhlIEFTUiBlbmdpbmUuIFRoaXMgY2FuIGluY2x1ZGUgdGhlIHN5bnRheCBhbmQgaW5z
dHJ1Y3Rpb25zIHRvIGNhcHR1cmUgdGhlIGF1ZGlvLg1TSS9TViBmdW5jdGlvbmFsIGV4dGVuc2li
aWxpdHkgWzguNV0NVDogQnkgZGVmaW5pdGlvbiBhIHdlYiBzZXJ2aWNlIGZyYW1ld29yayBhbmQg
WE1MIGFyZSBleHRlbnNpYmxlIHRvIG5ldyBmdW5jdGlvbmFsaXR5IGFuZCBkZXNjcmliZSBob3cg
ZXh0ZW5zaWJpbGl0eSBpcyBhY2hpZXZlZC4MTVJDUCBTTklQUw0NQW5hbHlzaXMgb2YgR2VuZXJh
bCBSZXF1aXJlbWVudHMNUmV1c2UgZXhpc3RpbmcgcHJvdG9jb2xzIFs1LjFdDVQ6IElmIFJUU1Ag
b3IgU0lQIGlzIGV4dGVuZGVkIHdpdGggTVJDUCwgaXQgd2lsbCBiZSByZXVzaW5nIGFuIGV4aXN0
aW5nIHByb3RvY29sLiBJZiBNUkNQIHdhcyBleHRlbmRlZCB0byBiZWNvbWUgYSBzdGFuZGFsb25l
IHByb3RvY29sLCBpdCB3b3VsZG6SdC4NTWFpbnRhaW4gRXhpc3RpbmcgUHJvdG9jb2wgSW50ZWdy
aXR5IFs1LjJdDVQ6IElmIFJUU1Agb3IgU0lQIGlzIGV4dGVuZGVkIHdpdGggTVJDUCwgaXQgY2Fu
IGJlIGRvbmUgaW4gYSB3YXkgdGhhdCBtYWludGFpbnMgdGhlIGludGVncml0eSBvZiB0aGUgcHJv
dG9jb2wuDUF2b2lkIER1cGxpY2F0aW5nIEV4aXN0aW5nIFByb3RvY29scyBbNS4zXQ1UOiBJZiBS
VFNQIG9yIFNJUCBpcyBleHRlbmRlZCB3aXRoIE1SQ1AsIGl0IHdvdWxkIGJlIG1lZXQgdGhpcyBy
ZXF1aXJlbWVudC4gSWYgTVJDUCB3YXMgZXh0ZW5kZWQgdG8gYmVjb21lIGEgc3RhbmRhbG9uZSBw
cm90b2NvbCwgaXQgd291bGRuknQuDVByb3RvY29sIGVmZmljaWVuY3kgWzUuNF0NUDogTVJDUCBh
cyBpdCBleGlzdHMgaXMgc3ViLW9wdGltYWwgZHVlIHRvIGl0cyB0dW5uZWxpbmcuIE9uIHRoZSBv
dGhlciBoYW5kLCBpZiBpdCB3ZXJlIGV4dGVuZGVkIGFzIHN0YW5kYWxvbmUgcHJvdG9jb2wgb3Ig
d2l0aCBSVFNQIG9yIFNJUCwgaXQgd291bGQgbWVldCB0aGlzIHJlcXVpcmVtZW50Lg1FeHBsaWNp
dCBpbnZvY2F0aW9uIG9mIHNlcnZpY2VzIFs1LjVdDVQ6DVNlcnZlciBMb2NhdGlvbiBhbmQgTG9h
ZCBCYWxhbmNpbmcgWzUuNl0NVDpJZiBNUkNQIHdlcmUgZXh0ZW5kZWQgYXMgYSBzdGFuZGFsb25l
IHByb3RvY29sIGl0IGNvdWxkIGRlc2lnbmVkIHRvIG1lZXQgdGhpcyByZXF1aXJlbWVudC4gSWYg
TVJDUCB3YXMgdXNlZCB0byBleHRlbmQgU0lQIG9yIFJUU1AsIGl0IHdvdWxkIGF1dG9tYXRpY2Fs
bHkgaW5oZXJpdCB0aGVpciBjYXBhYmlsaXR5IHRoaXMgYXJlYSBhbmQgaGVuY2Ugd291bGQgbWVl
dCB0aGlzIHJlcXVpcmVtZW50Lg1TaW11bHRhbmVvdXMgc2VydmljZXMgWzUuN10NVDogTVJDUCBh
cyBpdCBleGlzdHMgZG9lcyBtZWV0IHRoaXMgcmVxdWlyZW1lbnQgYWxyZWFkeS4gSXQgY291bGQg
Y29udGludWUgdG8gZG8gc28gZXZlbiBpZiBpdCBpcyBleHRlbmRlZCBpbiB3aXRoZXIgb2YgdGhl
IHdheXMgc3VnZ2VzdGVkIGhlcmUuDU11bHRpcGxlIG1lZGlhIHNlc3Npb25zIFs1LjhdDVArOiBN
UkNQIHNoYXJlcyBhIHNpbmdsZSAyIHdheSBtZWRpYSBwaXBlIGJldHdlZW4gQVNSIGFuZCBUVFMg
dG9kYXkuIENvbnNpZGVyaW5nIGl0IHN1cHBvcnRzIG9ubHkgMiByZXNvdXJjZXMgYW5kIHRoZXkg
dHJlYXQgbWVkaWEgaW4gZGlmZmVyZW50IGRpcmVjdGlvbnMgaXQgY3VycmVudGx5IGRvZXNuknQg
bWVldCB0aGlzIHJlcXVpcmVtZW50IGNvbXBsZXRlbHkuIEFnYWluLCBTSSBvciBTViB3YXMgYWRk
ZWQgdG8gTVJDUCBhcyBpdCBleGlzdHMsIGEgc3RhbmRhbG9uZSBwcm90b2NvbCBvciBhcyBhbiBl
eHRlbnNpb24gdG8gUlRTUC9TSVAsIGl0IGNvdWxkIGJlIGRlc2lnbmVkIHRvIG1lZXQgdGhpcyBy
ZXF1aXJlbWVudC4NDQ1BbmFseXNpcyBvZiBEdXBsZXhpbmcgYW5kIFBhcmFsbGVsIE9wZXJhdGlv
biBSZXF1aXJlbWVudHMNRHVwbGV4aW5nIGFuZCBQYXJhbGxlbCBPcGVyYXRpb24gUmVxdWlyZW1l
bnRzIFs5XQ1GdWxsIER1cGxleCBvcGVyYXRpb24gWzkuMS4xXQ1UOiBNUkNQIHN1cHBvcnRzIGhh
dmluZyB0aGUgQVNSIGFuZCBUVFMgZW5naW5lcyBvbiB0aGUgc2FtZSBzZXJ2ZXIuIFdoZW4gaW4g
dGhpcyBtb2RlIHRoZXkgdXNlIGEgc2luZ2xlIGZ1bGwtZHVwbGV4IGF1ZGlvIHN0cmVhbSB0byBi
b3RoIHJlY29nbml6ZSBhdWRpbyBhbmQgZ2VuZXJhdGUgYSBUVFMgdm9pY2Ugc3RyZWFtLg0NTXVs
dGlwbGUgc2VydmljZXMgaW4gcGFyYWxsZWwgWzkuMS4yXQ1GOiBNUkNQIGRvZXNuknQgc3VwcG9y
dCBTSSBvciBTVi4NQ29tYmluYXRpb24gb2Ygc2VydmljZXMNRjogTVJDUCBhc3N1bWVzIHRoYXQg
dGhlIHJlY29nbml6ZXIgdG8gYmUgYSBjb21iaW5lZCB1bml0IGFuZCBkb2VzIG5vdCBzdXBwb3J0
IHNlcGFyYXRpbmcgb2Ygc3ViLWNvbXBvbmVudHMgbGlrZSBzZW1hbnRpYyBhbmFseXplcnMuDUFu
YWx5c2lzIG9mIGFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgKG5vbi1ub3JtYXRpdmUpDVQ6IFNp
bmNlIE1SQ1Agd29ya3Mgd2l0aCBTSVAgb3IgUlRTUCwgaXQgdXNlcyBTRFAgZm9yIHNlc3Npb24g
ZGVzY3JpcHRpb24gYW5kIGNhbiB3b3JrIHdpdGggb3RoZXIgdHJhbnNwb3J0IHNjaGVtZXMgbGlr
ZSBBVE0gZXRjLiBJdCB1c2VzIHN0YW5kYXJkIGNvZGVjcyBhbmQgY2FuIHdvcmsgd2l0aCBzcGVj
aWFsaXplZCBjb2RlY3MgbGlrZSBEU1IuDUFuYWx5c2lzIG9mIFNlY3VyaXR5IGNvbnNpZGVyYXRp
b25zDVNlY3VyaXR5IENvbnNpZGVyYXRpb25zIFsxMV0NVDogU2luY2UgTVJDUCB3b3JrcyB3aXRo
IFJUU1AsIGl0IGluaGVyaXRzIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBvZiBTSVAgb3Ig
UlRTUC4NDQlTUEVFQ0hTQyBQcm90b2NvbCBFdmFsdWF0aW9uIFRlbXBsYXRlIAkTIFNBVkVEQVRF
IFxAICJNTU1NIHl5eXkiIFwqIE1FUkdFRk9STUFUIBRNYXJjaCAyMDAzFQ0NDQ0NDVd5bGQJRXhw
aXJlcyCWIEFwcmlsIDIwMDMJW1BhZ2UgEyBQQUdFIBQxMBVdDQ0NDVd5bGQgCUV4cGlyZXMgliBB
cHJpbCAyMDAzCVtQYWdlIDFdDQ0NDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAADgQAAA8EAAAX
BAAAGAQAAEIEAABDBAAAXgQAAF8EAAB0BAAAdQQAAHYEAAB/BAAAgAQAAIsEAACMBAAAtAQAALUE
AAC/BAAAwAQAAMEEAADCBAAAwwQAAKsJAACsCQAAwAkAAMIJAAB2DAAAdwwAAOwMAADuDAAAzg0A
AM8NAADiDQAA5A0AAOUNAAD5DQAA+g0AAPsNAAD8DQAAFw4AABgOAAAZDgAAGg4AABwOAAAdDgAA
JQ4AACYOAAAnDgAAQA4AAEEOAABCDgAAQw4AAEQOAABFDgAARg4AAEcOAAD57vnpAOQA3wDf5NjT
2N8A3wDfyNO/AOQA5ADkAOQA5ADk3wDfuLUAtae4taC1npeej5eel7iguAAADwIIgQNqewAAAAYI
AVUIAQwDagAAAAARCIFVCAEAAxEIgQxPSgAAUUoAAGFKGAAAGwIIgQNqAAAAAAYIAT4qAUIqAlUI
AXBoAAD/AAQwSh4AAA0DagAAAAAwSh4AVQgBEE9KAABRSgAAbUgMBHNIDAQAFE9KAABRSgAAbUgA
BG5IAARzSAwEAAhtSAwEc0gMBAAMbUgABG5IAARzSAwEAAkDagAAAABVCAEIT0oAAFFKAAAACG1I
BwRzSAcEABRPSgAAUUoAAG1IAARuSAAEc0gHBAAMbUgABG5IAARzSAcEOAAEAAAPBAAAFwQAABgE
AABDBAAASgQAAEsEAAB2BAAAfwQAAIAEAACLBAAAwQQAAMIEAADDBAAA4AQAAOEEAAACBQAASAUA
ALIFAAD5AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAKvMAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA
8AAAAAAAAAAAAAAAAKvUAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAKsIAQAA
AAAAAAAAAAD5AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAKsAAAAAAAAAAAAAAAClAAAAAAAAAAAA
AAAAoAAAAAAAAAAAAAAAAJ4AAAAAAAAAAAAAAACeAAAAAAAAAAAAAAAAnAAAAAAAAAAAAAAAAJwA
AAAAAAAAAAAAAAAAAAABEQAAASAAAAQRAAMkAWEkAQAFEQAPhAAAXoQAAABEAAAWJAEXJAFJZgEA
AAAClmwAB5QQ/wjWMAAClP88HuknAAaoHgAAAAAAAAAAAAAAAAAAAAAABq0JAAAAAAAAAAAAAAAA
AAAAABT2AQAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYA
AQoDbABh9gMAAAkgAAMkAhYkAUlmAQAAAGEkAgYgABYkAUlmAQAAAAASAAQAAC/5AADo+QAA/v4A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQKyBQAA/AUAALsHAADaCAAA
2wgAAJoJAACbCQAAogkAAKMJAACpCQAAqgkAAKwJAADBCQAAwgkAAC8KAAA0CgAA/woAAAQLAAAJ
DAAADgwAAEYMAAB3DAAAuQwAAN4MAADjDAAA7QwAAO4MAADPDQAA+gAAAAAAAAAAAAAAAPoAAAAA
AAAAAAAAAAD6AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAA
AAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPIA
AAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAA
AAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAA
APIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADyAAAA
AAAAAAAAAAAA8AAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAAAAAAAAAABREA
EYQgAWCEIAEAASAAAAERAAAFEQAPhAAAXoQAAAURAAomAAtGDwAAG88NAADRDQAA4w0AAOQNAABG
DgAAnA4AAP0OAABNDwAAyw8AAB4QAACfEAAA8xAAAFkRAADYEQAAUxIAALwSAAATEwAAmhMAAOwT
AABSFAAA0RQAAEwVAAC1FQAACRYAAGAWAADgFgAAOxcAAKIXAAD9AAAAAAAAAAAAAAAA+wAAAAAA
AAAAAAAAAPkAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAA
AADtAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA7QAA
AAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAA
AAAAAADtAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA
7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAA
AAAAAAAAAADzAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAAAAAAAAAAAAAAEU
AAAFFQANxgUAAYAHAAAFFAANxgUAAbAEAAABEQAAASAAAAEXAAAbRw4AAEgOAABjDgAAZA4AAGUO
AABmDgAAaA4AAGkOAAB7DgAAfA4AAH0OAACWDgAAlw4AAJgOAACZDgAAmg4AAJsOAACcDgAAnQ4A
AJ4OAAC5DgAAug4AALsOAAC8DgAAvg4AAL8OAADcDgAA3Q4AAN4OAAD3DgAA+A4AAPkOAAD6DgAA
+w4AAPwOAAD9DgAA/g4AAP8OAAAaDwAAGw8AABwPAAAdDwAAIQ8AACIPAAAsDwAALQ8AAP0A/e/o
/eH939jf0Njf2Ojh6P0A/cLo/eH939jfutjf2OjhraWfpYutpX+ldwAAAAAAAAAAAA4RCIFtSAAE
bkgABHUIAQAXT0oAAFFKAABhShgAbUgABG5IAAR1CAEmAgiBA2riAgAABggBPioBQioCVQgBbUgA
BG5IAARwaAAA/wB1CAEAC21IAARuSAAEdQgBDzBKHgBtSAAEbkgABHUIARgDagAAAAAwSh4AVQgB
bUgABG5IAAR1CAEADwIIgQNqZwIAAAYIAVUIARsCCIEDauwBAAAGCAE+KgFCKgJVCAFwaAAA/wAP
AgiBA2pxAQAABggBVQgBDANqAAAAABEIgVUIAQADEQiBDE9KAABRSgAAYUoYAAANA2oAAAAAMEoe
AFUIARsCCIEDavYAAAAGCAE+KgFCKgJVCAFwaAAA/wAEMEoeAC0tDwAALg8AAEcPAABIDwAASQ8A
AEoPAABLDwAATA8AAE0PAABODwAATw8AAGoPAABrDwAAbA8AAG0PAABvDwAAcA8AAKoPAACrDwAA
rA8AAMUPAADGDwAAxw8AAMgPAADJDwAAyg8AAMsPAADMDwAAzQ8AAOgPAADpDwAA6g8AAOsPAAD9
DwAA/g8AAP8PAAAYEAAAGRAAABoQAAAbEAAAHBAAAB0QAAAeEAAAHxAAACAQAAA7EAAAPBAAAPPr
3fPr89DEvboAuqy9uqW6o5yjlJyjnL2lvboAuoa9uqOco36co5y9pb26ALoAAAAAAAAAAAAAAAAA
AAAAAAAPAgiBA2pJBQAABggBVQgBGwIIgQNqzgQAAAYIAT4qAUIqAlUIAXBoAAD/AA8CCIEDalME
AAAGCAFVCAEMA2oAAAAAEQiBVQgBAAMRCIEMT0oAAFFKAABhShgAABsCCIEDatgDAAAGCAE+KgFC
KgJVCAFwaAAA/wAEMEoeAAANA2oAAAAAMEoeAFUIARdPSgAAUUoAAGFKGABtSAAEbkgABHUIARgD
agAAAAAwSh4AVQgBbUgABG5IAAR1CAEAGgIIgQNqXQMAAAYIAVUIAW1IAARuSAAEdQgBAA4RCIFt
SAAEbkgABHUIAQAXA2oAAAAAEQiBVQgBbUgABG5IAAR1CAEALjwQAAA9EAAAPhAAAEAQAABBEAAA
fhAAAH8QAACAEAAAmRAAAJoQAACbEAAAnBAAAJ0QAACeEAAAnxAAAKAQAAChEAAAvBAAAL0QAAC+
EAAAvxAAAMMQAADEEAAA0hAAANMQAADUEAAA7RAAAO4QAADvEAAA8BAAAPEQAADyEAAA8xAAAPQQ
AAD1EAAAEBEAABERAADx6ufg597X3s/X3tfq4MK6tLqgwrqUuoyAjHKAjIDClMK6tLoAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoCCIEDajUHAAAGCAFVCAFtSAAE
bkgABHUIAQAXA2oAAAAAEQiBVQgBbUgABG5IAAR1CAEOEQiBbUgABG5IAAR1CAEAF09KAABRSgAA
YUoYAG1IAARuSAAEdQgBJgIIgQNqugYAAAYIAT4qAUIqAlUIAW1IAARuSAAEcGgAAP8AdQgBAAtt
SAAEbkgABHUIAQ8wSh4AbUgABG5IAAR1CAEYA2oAAAAAMEoeAFUIAW1IAARuSAAEdQgBAA8CCIED
aj8GAAAGCAFVCAEMA2oAAAAAEQiBVQgBAAMRCIEMT0oAAFFKAABhShgAAAQwSh4AAA0DagAAAAAw
Sh4AVQgBGwIIgQNqxAUAAAYIAT4qAUIqAlUIAXBoAAD/AAAkEREAABIRAAATEQAAFxEAABgRAAA4
EQAAOREAADoRAABTEQAAVBEAAFURAABWEQAAVxEAAFgRAABZEQAAWhEAAFsRAAB2EQAAdxEAAHgR
AAB5EQAAfREAAH4RAAC3EQAAuBEAALkRAADSEQAA0xEAANQRAADVEQAA1hEAANcRAADYEQAA2REA
ANoRAAD1EQAA9hEAAPcRAAD4EQAA/BEAAP0RAAAyEgAAMxIAAOzf18vXw7fDqbfDt9/L39ej14/f
18vXw7fDgbfDt9/L39ej123f18vXwwAAAAAmAgiBA2qcCQAABggBPioBQioCVQgBbUgABG5IAARw
aAAA/wB1CAEAGgIIgQNqIQkAAAYIAVUIAW1IAARuSAAEdQgBACYCCIEDaqYIAAAGCAE+KgFCKgJV
CAFtSAAEbkgABHBoAAD/AHUIAQALbUgABG5IAAR1CAEaAgiBA2orCAAABggBVQgBbUgABG5IAAR1
CAEAFwNqAAAAABEIgVUIAW1IAARuSAAEdQgBDhEIgW1IAARuSAAEdQgBABdPSgAAUUoAAGFKGABt
SAAEbkgABHUIAQ8wSh4AbUgABG5IAAR1CAEYA2oAAAAAMEoeAFUIAW1IAARuSAAEdQgBACYCCIED
arAHAAAGCAE+KgFCKgJVCAFtSAAEbkgABHBoAAD/AHUIASozEgAANBIAAE0SAABOEgAATxIAAFAS
AABREgAAUhIAAFMSAABUEgAAVRIAAHASAABxEgAAchIAAHMSAAB3EgAAeBIAAJsSAACcEgAAnRIA
ALYSAAC3EgAAuBIAALkSAAC6EgAAuxIAALwSAAC9EgAAvhIAANkSAADaEgAA2xIAANwSAADgEgAA
4RIAAPISAADzEgAA9BIAAA0TAAAOEwAADxMAABATAAAREwAAEhMAABMTAADz693z6/PQxNC8tryi
0LzEvOvz65Tz6/PQxNC8tryA0LzEvOvz63Lz6/PQxAAAAAAaAgiBA2oDDAAABggBVQgBbUgABG5I
AAR1CAEAJgIIgQNqiAsAAAYIAT4qAUIqAlUIAW1IAARuSAAEcGgAAP8AdQgBABoCCIEDag0LAAAG
CAFVCAFtSAAEbkgABHUIAQAmAgiBA2qSCgAABggBPioBQioCVQgBbUgABG5IAARwaAAA/wB1CAEA
C21IAARuSAAEdQgBDzBKHgBtSAAEbkgABHUIARdPSgAAUUoAAGFKGABtSAAEbkgABHUIARgDagAA
AAAwSh4AVQgBbUgABG5IAAR1CAEAGgIIgQNqFwoAAAYIAVUIAW1IAARuSAAEdQgBAA4RCIFtSAAE
bkgABHUIAQAXA2oAAAAAEQiBVQgBbUgABG5IAAR1CAEALBMTAAAUEwAAFRMAADATAAAxEwAAMhMA
ADMTAAA1EwAANhMAAHkTAAB6EwAAexMAAJQTAACVEwAAlhMAAJcTAACYEwAAmRMAAJoTAACbEwAA
nBMAALcTAAC4EwAAuRMAALoTAAC+EwAAvxMAAMsTAADMEwAAzRMAAOYTAADnEwAA6BMAAOkTAADq
EwAA6xMAAOwTAADtEwAA7hMAAAkUAAAKFAAA+PUA9ef49eD13tfez9fe1/jgwrq0uqDCupS6jICM
coCMgMKUwrq0ugAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoCCIEDau8NAAAGCAFVCAFtSAAEbkgA
BHUIAQAXA2oAAAAAEQiBVQgBbUgABG5IAAR1CAEOEQiBbUgABG5IAAR1CAEAF09KAABRSgAAYUoY
AG1IAARuSAAEdQgBJgIIgQNqdA0AAAYIAT4qAUIqAlUIAW1IAARuSAAEcGgAAP8AdQgBAAttSAAE
bkgABHUIAQ8wSh4AbUgABG5IAAR1CAEYA2oAAAAAMEoeAFUIAW1IAARuSAAEdQgBAA8CCIEDavkM
AAAGCAFVCAEMA2oAAAAAEQiBVQgBAAMRCIEMT0oAAFFKAABhShgAABsCCIEDan4MAAAGCAE+KgFC
KgJVCAFwaAAA/wAEMEoeAAANA2oAAAAAMEoeAFUIAQAoChQAAAsUAAAMFAAAEBQAABEUAAAxFAAA
MhQAADMUAABMFAAATRQAAE4UAABPFAAAUBQAAFEUAABSFAAAUxQAAFQUAABvFAAAcBQAAHEUAABy
FAAAdhQAAHcUAACwFAAAsRQAALIUAADLFAAAzBQAAM0UAADOFAAAzxQAANAUAADRFAAA0hQAANMU
AADuFAAA7xQAAPAUAADxFAAA9RQAAPYUAAArFQAALBUAAOzf18vXw7fDqbfDt9/L39ej14/f18vX
w7fDgbfDt9/L39ej123f18vXwwAAAAAmAgiBA2pWEAAABggBPioBQioCVQgBbUgABG5IAARwaAAA
/wB1CAEAGgIIgQNq2w8AAAYIAVUIAW1IAARuSAAEdQgBACYCCIEDamAPAAAGCAE+KgFCKgJVCAFt
SAAEbkgABHBoAAD/AHUIAQALbUgABG5IAAR1CAEaAgiBA2rlDgAABggBVQgBbUgABG5IAAR1CAEA
FwNqAAAAABEIgVUIAW1IAARuSAAEdQgBDhEIgW1IAARuSAAEdQgBABdPSgAAUUoAAGFKGABtSAAE
bkgABHUIAQ8wSh4AbUgABG5IAAR1CAEYA2oAAAAAMEoeAFUIAW1IAARuSAAEdQgBACYCCIEDamoO
AAAGCAE+KgFCKgJVCAFtSAAEbkgABHBoAAD/AHUIASosFQAALRUAAEYVAABHFQAASBUAAEkVAABK
FQAASxUAAEwVAABNFQAAThUAAGkVAABqFQAAaxUAAGwVAABwFQAAcRUAAJQVAACVFQAAlhUAAK8V
AACwFQAAsRUAALIVAACzFQAAtBUAALUVAAC2FQAAtxUAANIVAADTFQAA1BUAANUVAADZFQAA2hUA
AOgVAADpFQAA6hUAAAMWAAAEFgAABRYAAAYWAAAHFgAACBYAAAkWAADz693z6/PQxNC8tryi0LzE
vOvz65Tz6/PQxNC8tryA0LzEvOvz63Lz6/PQxAAAAAAaAgiBA2q9EgAABggBVQgBbUgABG5IAAR1
CAEAJgIIgQNqQhIAAAYIAT4qAUIqAlUIAW1IAARuSAAEcGgAAP8AdQgBABoCCIEDascRAAAGCAFV
CAFtSAAEbkgABHUIAQAmAgiBA2pMEQAABggBPioBQioCVQgBbUgABG5IAARwaAAA/wB1CAEAC21I
AARuSAAEdQgBDzBKHgBtSAAEbkgABHUIARdPSgAAUUoAAGFKGABtSAAEbkgABHUIARgDagAAAAAw
Sh4AVQgBbUgABG5IAAR1CAEAGgIIgQNq0RAAAAYIAVUIAW1IAARuSAAEdQgBAA4RCIFtSAAEbkgA
BHUIAQAXA2oAAAAAEQiBVQgBbUgABG5IAAR1CAEALAkWAAAKFgAACxYAACYWAAAnFgAAKBYAACkW
AAAtFgAALhYAAD8WAABAFgAAQRYAAFoWAABbFgAAXBYAAF0WAABeFgAAXxYAAGAWAABhFgAAYhYA
AH0WAAB+FgAAfxYAAIAWAACCFgAAgxYAAL4WAAC/FgAAwBYAANkWAADaFgAA2xYAAN0WAADeFgAA
3xYAAOAWAADhFgAA4hYAAP0WAAD+FgAA8+vl69Hz68XrvbG9o7G9sfPFnJkAmYucmYSZgnuCc3uC
e5yE8+vl6wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwIIgQNqqRQAAAYIAVUIAQwDagAAAAAR
CIFVCAEAAxEIgQxPSgAAUUoAAGFKGAAAGwIIgQNqLhQAAAYIAT4qAUIqAlUIAXBoAAD/AAQwSh4A
AA0DagAAAAAwSh4AVQgBGgIIgQNqsxMAAAYIAVUIAW1IAARuSAAEdQgBABcDagAAAAARCIFVCAFt
SAAEbkgABHUIAQ4RCIFtSAAEbkgABHUIAQAXT0oAAFFKAABhShgAbUgABG5IAAR1CAEmAgiBA2o4
EwAABggBPioBQioCVQgBbUgABG5IAARwaAAA/wB1CAEAC21IAARuSAAEdQgBDzBKHgBtSAAEbkgA
BHUIARgDagAAAAAwSh4AVQgBbUgABG5IAAR1CAEo/hYAAP8WAAAAFwAABBcAAAUXAAAZFwAAGhcA
ABsXAAA0FwAANRcAADYXAAA4FwAAORcAADoXAAA7FwAAPBcAAD0XAABYFwAAWRcAAFoXAABbFwAA
XxcAAGAXAACAFwAAgRcAAIIXAACbFwAAnBcAAJ0XAACfFwAAoBcAAKEXAACiFwAAoxcAAKQXAAC/
FwAAwBcAAMEXAADCFwAAxhcAAMcXAAAAGAAAARgAAOzf18vXw7fDqbfDt9/L39ej14/f18vXw7fD
gbfDt9/L39ej123f18vXwwAAAAAmAgiBA2oQFwAABggBPioBQioCVQgBbUgABG5IAARwaAAA/wB1
CAEAGgIIgQNqlRYAAAYIAVUIAW1IAARuSAAEdQgBACYCCIEDahoWAAAGCAE+KgFCKgJVCAFtSAAE
bkgABHBoAAD/AHUIAQALbUgABG5IAAR1CAEaAgiBA2qfFQAABggBVQgBbUgABG5IAAR1CAEAFwNq
AAAAABEIgVUIAW1IAARuSAAEdQgBDhEIgW1IAARuSAAEdQgBABdPSgAAUUoAAGFKGABtSAAEbkgA
BHUIAQ8wSh4AbUgABG5IAAR1CAEYA2oAAAAAMEoeAFUIAW1IAARuSAAEdQgBACYCCIEDaiQVAAAG
CAE+KgFCKgJVCAFtSAAEbkgABHBoAAD/AHUIASoBGAAAAhgAABsYAAAcGAAAHRgAAB8YAAAgGAAA
IRgAACIYAAAjGAAAJBgAAD8YAABAGAAAQRgAAEIYAABGGAAARxgAAHwYAAB9GAAAfhgAAJcYAACY
GAAAmRgAAJsYAACcGAAAnRgAAJ4YAACfGAAAoBgAALsYAAC8GAAAvRgAAL4YAADCGAAAwxgAAOYY
AADnGAAA6BgAAAEZAAACGQAAAxkAAAUZAAAGGQAABxkAAAgZAADz693z6/PQxNC8tryi0LzEvOvz
65Tz6/PQxNC8tryA0LzEvOvz63Lz6/PQxAAAAAAaAgiBA2p3GQAABggBVQgBbUgABG5IAAR1CAEA
JgIIgQNq/BgAAAYIAT4qAUIqAlUIAW1IAARuSAAEcGgAAP8AdQgBABoCCIEDaoEYAAAGCAFVCAFt
SAAEbkgABHUIAQAmAgiBA2oGGAAABggBPioBQioCVQgBbUgABG5IAARwaAAA/wB1CAEAC21IAARu
SAAEdQgBDzBKHgBtSAAEbkgABHUIARdPSgAAUUoAAGFKGABtSAAEbkgABHUIARgDagAAAAAwSh4A
VQgBbUgABG5IAAR1CAEAGgIIgQNqixcAAAYIAVUIAW1IAARuSAAEdQgBAA4RCIFtSAAEbkgABHUI
AQAXA2oAAAAAEQiBVQgBbUgABG5IAAR1CAEALKIXAAAiGAAAnhgAAAgZAABgGQAA5RkAADoaAACh
GgAAIRsAAJ0bAAAHHAAAXxwAAOYcAAA0HQAAlx0AAPodAACBHgAAAx8AAF8fAADDHwAAJyAAAK8g
AAAMIQAAXCEAAMAhAAAkIgAArCIAABAjAAB0IwAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5
AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA
AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA
AADzAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA
AAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA
AAAAAAD5AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA
+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAA
AAAFFAANxgUAAbAEAAAFFQANxgUAAYAHAAAcCBkAAAkZAAAKGQAAJRkAACYZAAAnGQAAKBkAACwZ
AAAtGQAAPhkAAD8ZAABAGQAAWRkAAFoZAABbGQAAXRkAAF4ZAABfGQAAYBkAAGEZAABiGQAAfRkA
AH4ZAAB/GQAAgBkAAIIZAACDGQAAwxkAAMQZAADFGQAA3hkAAN8ZAADgGQAA4hkAAOMZAADkGQAA
5RkAAOYZAADnGQAAAhoAAAMaAADz6+Xr0fPrxeu9sb2jsb2x88WcmQCZi5yZhJmCe4Jze4J7nITz
6+XrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAgiBA2pjGwAABggBVQgBDANqAAAAABEIgVUI
AQADEQiBDE9KAABRSgAAYUoYAAAbAgiBA2roGgAABggBPioBQioCVQgBcGgAAP8ABDBKHgAADQNq
AAAAADBKHgBVCAEaAgiBA2ptGgAABggBVQgBbUgABG5IAAR1CAEAFwNqAAAAABEIgVUIAW1IAARu
SAAEdQgBDhEIgW1IAARuSAAEdQgBABdPSgAAUUoAAGFKGABtSAAEbkgABHUIASYCCIEDavIZAAAG
CAE+KgFCKgJVCAFtSAAEbkgABHBoAAD/AHUIAQALbUgABG5IAAR1CAEPMEoeAG1IAARuSAAEdQgB
GANqAAAAADBKHgBVCAFtSAAEbkgABHUIASgDGgAABBoAAAUaAAAJGgAAChoAABgaAAAZGgAAGhoA
ADMaAAA0GgAANRoAADcaAAA4GgAAORoAADoaAAA7GgAAPBoAAFcaAABYGgAAWRoAAFoaAABeGgAA
XxoAAH8aAACAGgAAgRoAAJoaAACbGgAAnBoAAJ4aAACfGgAAoBoAAKEaAACiGgAAoxoAAL4aAAC/
GgAAwBoAAMEaAADFGgAAxhoAAP8aAAAAGwAA7N/Xy9fDt8Opt8O338vf16PXj9/Xy9fDt8OBt8O3
38vf16PXbd/Xy9fDAAAAACYCCIEDasodAAAGCAE+KgFCKgJVCAFtSAAEbkgABHBoAAD/AHUIAQAa
AgiBA2pPHQAABggBVQgBbUgABG5IAAR1CAEAJgIIgQNq1BwAAAYIAT4qAUIqAlUIAW1IAARuSAAE
cGgAAP8AdQgBAAttSAAEbkgABHUIARoCCIEDalkcAAAGCAFVCAFtSAAEbkgABHUIAQAXA2oAAAAA
EQiBVQgBbUgABG5IAAR1CAEOEQiBbUgABG5IAAR1CAEAF09KAABRSgAAYUoYAG1IAARuSAAEdQgB
DzBKHgBtSAAEbkgABHUIARgDagAAAAAwSh4AVQgBbUgABG5IAAR1CAEAJgIIgQNq3hsAAAYIAT4q
AUIqAlUIAW1IAARuSAAEcGgAAP8AdQgBKgAbAAABGwAAGhsAABsbAAAcGwAAHhsAAB8bAAAgGwAA
IRsAACIbAAAjGwAAPhsAAD8bAABAGwAAQRsAAEUbAABGGwAAexsAAHwbAAB9GwAAlhsAAJcbAACY
GwAAmhsAAJsbAACcGwAAnRsAAJ4bAACfGwAAuhsAALsbAAC8GwAAvRsAAMEbAADCGwAA5RsAAOYb
AADnGwAAABwAAAEcAAACHAAABBwAAAUcAAAGHAAABxwAAPPr3fPr89DE0Ly2vKLQvMS86/PrlPPr
89DE0Ly2vIDQvMS86/PrcvPr89DEAAAAABoCCIEDajEgAAAGCAFVCAFtSAAEbkgABHUIAQAmAgiB
A2q2HwAABggBPioBQioCVQgBbUgABG5IAARwaAAA/wB1CAEAGgIIgQNqOx8AAAYIAVUIAW1IAARu
SAAEdQgBACYCCIEDasAeAAAGCAE+KgFCKgJVCAFtSAAEbkgABHBoAAD/AHUIAQALbUgABG5IAAR1
CAEPMEoeAG1IAARuSAAEdQgBF09KAABRSgAAYUoYAG1IAARuSAAEdQgBGANqAAAAADBKHgBVCAFt
SAAEbkgABHUIAQAaAgiBA2pFHgAABggBVQgBbUgABG5IAAR1CAEADhEIgW1IAARuSAAEdQgBABcD
agAAAAARCIFVCAFtSAAEbkgABHUIAQAsBxwAAAgcAAAJHAAAJBwAACUcAAAmHAAAJxwAACscAAAs
HAAAPRwAAD4cAAA/HAAAWBwAAFkcAABaHAAAXBwAAF0cAABeHAAAXxwAAGAcAABhHAAAfBwAAH0c
AAB+HAAAfxwAAIEcAACCHAAAxBwAAMUcAADGHAAA3xwAAOAcAADhHAAA4xwAAOQcAADlHAAA5hwA
AOccAADoHAAAAx0AAAQdAADz6+Xr0fPrxeu9sb2jsb2x88WcmQCZi5yZhJmCe4Jze4J7nITz6+Xr
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAgiBA2odIgAABggBVQgBDANqAAAAABEIgVUIAQAD
EQiBDE9KAABRSgAAYUoYAAAbAgiBA2qiIQAABggBPioBQioCVQgBcGgAAP8ABDBKHgAADQNqAAAA
ADBKHgBVCAEaAgiBA2onIQAABggBVQgBbUgABG5IAAR1CAEAFwNqAAAAABEIgVUIAW1IAARuSAAE
dQgBDhEIgW1IAARuSAAEdQgBABdPSgAAUUoAAGFKGABtSAAEbkgABHUIASYCCIEDaqwgAAAGCAE+
KgFCKgJVCAFtSAAEbkgABHBoAAD/AHUIAQALbUgABG5IAAR1CAEPMEoeAG1IAARuSAAEdQgBGANq
AAAAADBKHgBVCAFtSAAEbkgABHUIASgEHQAABR0AAAYdAAAKHQAACx0AABIdAAATHQAAFB0AAC0d
AAAuHQAALx0AADEdAAAyHQAAMx0AADQdAAA1HQAANh0AAFEdAABSHQAAUx0AAFQdAABYHQAAWR0A
AHUdAAB2HQAAdx0AAJAdAACRHQAAkh0AAJQdAACVHQAAlh0AAJcdAACYHQAAmR0AALQdAAC1HQAA
th0AALcdAAC7HQAAvB0AANgdAADZHQAA7N/Xy9fDt8Opt8O338vf16PXj9/Xy9fDt8OBt8O338vf
16PXbd/Xy9fDAAAAACYCCIEDaoQkAAAGCAE+KgFCKgJVCAFtSAAEbkgABHBoAAD/AHUIAQAaAgiB
A2oJJAAABggBVQgBbUgABG5IAAR1CAEAJgIIgQNqjiMAAAYIAT4qAUIqAlUIAW1IAARuSAAEcGgA
AP8AdQgBAAttSAAEbkgABHUIARoCCIEDahMjAAAGCAFVCAFtSAAEbkgABHUIAQAXA2oAAAAAEQiB
VQgBbUgABG5IAAR1CAEOEQiBbUgABG5IAAR1CAEAF09KAABRSgAAYUoYAG1IAARuSAAEdQgBDzBK
HgBtSAAEbkgABHUIARgDagAAAAAwSh4AVQgBbUgABG5IAAR1CAEAJgIIgQNqmCIAAAYIAT4qAUIq
AlUIAW1IAARuSAAEcGgAAP8AdQgBKtkdAADaHQAA8x0AAPQdAAD1HQAA9x0AAPgdAAD5HQAA+h0A
APsdAAD8HQAAFx4AABgeAAAZHgAAGh4AAB4eAAAfHgAAXx4AAGAeAABhHgAAeh4AAHseAAB8HgAA
fh4AAH8eAACAHgAAgR4AAIIeAACDHgAAnh4AAJ8eAACgHgAAoR4AAKQeAAClHgAA4R4AAOIeAADj
HgAA/B4AAP0eAADz693z6/PQxNC8tryi0LzEvOvz65Tz6/PQxI2KAIp8jYp1inNsc2QADwIIgQNq
6yYAAAYIAVUIAQwDagAAAAARCIFVCAEAAxEIgQxPSgAAUUoAAGFKGAAAGwIIgQNqcCYAAAYIAT4q
AUIqAlUIAXBoAAD/AAQwSh4AAA0DagAAAAAwSh4AVQgBGgIIgQNq9SUAAAYIAVUIAW1IAARuSAAE
dQgBACYCCIEDanolAAAGCAE+KgFCKgJVCAFtSAAEbkgABHBoAAD/AHUIAQALbUgABG5IAAR1CAEP
MEoeAG1IAARuSAAEdQgBF09KAABRSgAAYUoYAG1IAARuSAAEdQgBGANqAAAAADBKHgBVCAFtSAAE
bkgABHUIAQAaAgiBA2r/JAAABggBVQgBbUgABG5IAAR1CAEADhEIgW1IAARuSAAEdQgBABcDagAA
AAARCIFVCAFtSAAEbkgABHUIAQAn/R4AAP4eAAAAHwAAAR8AAAIfAAADHwAABB8AAAUfAAAgHwAA
IR8AACIfAAAjHwAAKB8AACkfAAA9HwAAPh8AAD8fAABYHwAAWR8AAFofAABcHwAAXR8AAF4fAABf
HwAAYB8AAGEfAAB8HwAAfR8AAH4fAAB/HwAAhB8AAIUfAAChHwAAoh8AAKMfAAC8HwAAvR8AAL4f
AADAHwAAwR8AAMIfAADDHwAA+ff58Onc1M7UutzUrtSmmqaMmqaa3K7c1M7UeNzUrtSmmqZqmqaa
3K4AAAAaAgiBA2rXKAAABggBVQgBbUgABG5IAAR1CAEAJgIIgQNqXCgAAAYIAT4qAUIqAlUIAW1I
AARuSAAEcGgAAP8AdQgBABoCCIEDauEnAAAGCAFVCAFtSAAEbkgABHUIAQAXA2oAAAAAEQiBVQgB
bUgABG5IAAR1CAEOEQiBbUgABG5IAAR1CAEAF09KAABRSgAAYUoYAG1IAARuSAAEdQgBJgIIgQNq
ZicAAAYIAT4qAUIqAlUIAW1IAARuSAAEcGgAAP8AdQgBAAttSAAEbkgABHUIAQ8wSh4AbUgABG5I
AAR1CAEYA2oAAAAAMEoeAFUIAW1IAARuSAAEdQgBAAxPSgAAUUoAAGFKGAAADQNqAAAAADBKHgBV
CAEDEQiBDANqAAAAABEIgVUIASnDHwAAxB8AAMUfAADgHwAA4R8AAOIfAADjHwAA6B8AAOkfAAAF
IAAABiAAAAcgAAAgIAAAISAAACIgAAAkIAAAJSAAACYgAAAnIAAAKCAAACkgAABEIAAARSAAAEYg
AABHIAAATCAAAE0gAACNIAAAjiAAAI8gAACoIAAAqSAAAKogAACsIAAArSAAAK4gAACvIAAAsCAA
ALEgAADMIAAAzSAAAM4gAADz6+Xr0fPrxeu9sb2jsb2x88Xz6+Xrj/Prxeu9sb2Bsb2x88V6dwB3
aQAbAgiBA2o+KwAABggBPioBQioCVQgBcGgAAP8ABDBKHgAADQNqAAAAADBKHgBVCAEaAgiBA2rD
KgAABggBVQgBbUgABG5IAAR1CAEAJgIIgQNqSCoAAAYIAT4qAUIqAlUIAW1IAARuSAAEcGgAAP8A
dQgBABoCCIEDas0pAAAGCAFVCAFtSAAEbkgABHUIAQAXA2oAAAAAEQiBVQgBbUgABG5IAAR1CAEO
EQiBbUgABG5IAAR1CAEAF09KAABRSgAAYUoYAG1IAARuSAAEdQgBJgIIgQNqUikAAAYIAT4qAUIq
AlUIAW1IAARuSAAEcGgAAP8AdQgBAAttSAAEbkgABHUIAQ8wSh4AbUgABG5IAAR1CAEYA2oAAAAA
MEoeAFUIAW1IAARuSAAEdQgBKc4gAADPIAAA0iAAANMgAADqIAAA6yAAAOwgAAAFIQAABiEAAAch
AAAJIQAACiEAAAshAAAMIQAADSEAAA4hAAApIQAAKiEAACshAAAsIQAALyEAADAhAAA6IQAAOyEA
ADwhAABVIQAAViEAAFchAABZIQAAWiEAAFshAABcIQAAXSEAAF4hAAB5IQAAeiEAAHshAAB8IQAA
gSEAAIIhAACeIQAAnyEAAKAhAAC5IQAA+PXu9ezl7N3l7OX47vj1APXP+PXu9ezl7Mfl7OX47rqy
rLKYurKMsoR4hAAAAAAAAAAAAAAAAAAAAAAAAAAAABcDagAAAAARCIFVCAFtSAAEbkgABHUIAQ4R
CIFtSAAEbkgABHUIAQAXT0oAAFFKAABhShgAbUgABG5IAAR1CAEmAgiBA2oqLQAABggBPioBQioC
VQgBbUgABG5IAARwaAAA/wB1CAEAC21IAARuSAAEdQgBDzBKHgBtSAAEbkgABHUIARgDagAAAAAw
Sh4AVQgBbUgABG5IAAR1CAEADwIIgQNqrywAAAYIAVUIARsCCIEDajQsAAAGCAE+KgFCKgJVCAFw
aAAA/wAPAgiBA2q5KwAABggBVQgBDANqAAAAABEIgVUIAQADEQiBDE9KAABRSgAAYUoYAAAEMEoe
AAANA2oAAAAAMEoeAFUIAQAruSEAALohAAC7IQAAvSEAAL4hAAC/IQAAwCEAAMEhAADCIQAA3SEA
AN4hAADfIQAA4CEAAOUhAADmIQAAAiIAAAMiAAAEIgAAHSIAAB4iAAAfIgAAISIAACIiAAAjIgAA
JCIAACUiAAAmIgAAQSIAAEIiAABDIgAARCIAAEkiAABKIgAAiiIAAIsiAACMIgAApSIAAKYiAACn
IgAAqSIAAKoiAACrIgAArCIAAK0iAACuIgAAySIAAPLm3ubRxdG9t72j0b3Fvd7m3pXm3ubRxdG9
t72B0b3Fvd7m3nPm3ubRxdG9twAaAgiBA2qRLwAABggBVQgBbUgABG5IAAR1CAEAJgIIgQNqFi8A
AAYIAT4qAUIqAlUIAW1IAARuSAAEcGgAAP8AdQgBABoCCIEDapsuAAAGCAFVCAFtSAAEbkgABHUI
AQAmAgiBA2ogLgAABggBPioBQioCVQgBbUgABG5IAARwaAAA/wB1CAEAC21IAARuSAAEdQgBDzBK
HgBtSAAEbkgABHUIARdPSgAAUUoAAGFKGABtSAAEbkgABHUIARgDagAAAAAwSh4AVQgBbUgABG5I
AAR1CAEADhEIgW1IAARuSAAEdQgBABcDagAAAAARCIFVCAFtSAAEbkgABHUIARoCCIEDaqUtAAAG
CAFVCAFtSAAEbkgABHUIAS3JIgAAyiIAAMsiAADMIgAA0SIAANIiAADuIgAA7yIAAPAiAAAJIwAA
CiMAAAsjAAANIwAADiMAAA8jAAAQIwAAESMAABIjAAAtIwAALiMAAC8jAAAwIwAANSMAADYjAABS
IwAAUyMAAFQjAABtIwAAbiMAAG8jAABxIwAAciMAAHMjAAB0IwAAdSMAAHYjAACRIwAAkiMAAJMj
AACUIwAAmSMAAJojAADaIwAA9+PW98r3wrbCqLbCttbK1vei947W98r3wrbCgLbCttbK1vei92zW
98r3AAAmAgiBA2r4MQAABggBPioBQioCVQgBbUgABG5IAARwaAAA/wB1CAEAGgIIgQNqfTEAAAYI
AVUIAW1IAARuSAAEdQgBACYCCIEDagIxAAAGCAE+KgFCKgJVCAFtSAAEbkgABHBoAAD/AHUIAQAL
bUgABG5IAAR1CAEaAgiBA2qHMAAABggBVQgBbUgABG5IAAR1CAEAFwNqAAAAABEIgVUIAW1IAARu
SAAEdQgBDhEIgW1IAARuSAAEdQgBABdPSgAAUUoAAGFKGABtSAAEbkgABHUIARgDagAAAAAwSh4A
VQgBbUgABG5IAAR1CAEAJgIIgQNqDDAAAAYIAT4qAUIqAlUIAW1IAARuSAAEcGgAAP8AdQgBAA8w
Sh4AbUgABG5IAAR1CAEAKtojAADbIwAA3CMAAPUjAAD2IwAA9yMAAPkjAAD6IwAA+yMAAPwjAAD9
IwAA/iMAABkkAAAaJAAAGyQAABwkAAAhJAAAIiQAAD4kAAA/JAAAQCQAAFkkAABaJAAAWyQAAF0k
AABeJAAAXyQAAGAkAABhJAAAYiQAAH0kAAB+JAAAfyQAAIAkAACFJAAAhiQAAKIkAACjJAAApCQA
AL0kAAC+JAAAvyQAAMEkAADCJAAAwyQAAMQkAAD47Pje7Pjs0cXRvbe9o9G9xb347PiV7Pjs0cXR
vbe9gdG9xb347Phz7Pjs0cUAGgIIgQNqXzQAAAYIAVUIAW1IAARuSAAEdQgBACYCCIEDauQzAAAG
CAE+KgFCKgJVCAFtSAAEbkgABHBoAAD/AHUIAQAaAgiBA2ppMwAABggBVQgBbUgABG5IAAR1CAEA
JgIIgQNq7jIAAAYIAT4qAUIqAlUIAW1IAARuSAAEcGgAAP8AdQgBAAttSAAEbkgABHUIAQ8wSh4A
bUgABG5IAAR1CAEXT0oAAFFKAABhShgAbUgABG5IAAR1CAEYA2oAAAAAMEoeAFUIAW1IAARuSAAE
dQgBABoCCIEDanMyAAAGCAFVCAFtSAAEbkgABHUIAQAXA2oAAAAAEQiBVQgBbUgABG5IAAR1CAEO
EQiBbUgABG5IAAR1CAEtdCMAAPwjAABgJAAAxCQAAEwlAAC1JQAANyYAALUmAAAhJwAAIycAAC0n
AAAyJwAAmCcAAJ0nAADTJwAA1CcAAE0oAACFKAAA/SgAAGopAABrKQAAyykAAMwpAACGKgAAhyoA
AC4rAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA
8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPEAAAAA
AAAAAAAAAADvAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADmAAAAAAAAAAAA
AAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAAOEA
AAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADmAAAAAAAA
AAAAAAAA5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF
EQAKJgwLRgAABREACiYAC0YOAAkRAAomDAtGAAAPhLABXoSwAQABEAAAARUAAAUVAA3GBQABsAcA
AAUVAA3GBQABgAcAABnEJAAAxSQAAMYkAADhJAAA4iQAAOMkAADkJAAA6SQAAOokAAAqJQAAKyUA
ACwlAABFJQAARiUAAEclAABJJQAASiUAAEslAABMJQAATSUAAE4lAABpJQAAaiUAAGslAABsJQAA
ciUAAHMlAACTJQAAlCUAAJUlAACuJQAAryUAALAlAACyJQAAsyUAALQlAAC1JQAAtiUAALclAADS
JQAA0yUAANQlAADVJQAA8+vl69Hz68XrvbG9o7G9sfPF8+vl64/z68XrvbG9gbG9sfPF8+vl623z
AAAAACYCCIEDasY2AAAGCAE+KgFCKgJVCAFtSAAEbkgABHBoAAD/AHUIAQAaAgiBA2pLNgAABggB
VQgBbUgABG5IAAR1CAEAJgIIgQNq0DUAAAYIAT4qAUIqAlUIAW1IAARuSAAEcGgAAP8AdQgBABoC
CIEDalU1AAAGCAFVCAFtSAAEbkgABHUIAQAXA2oAAAAAEQiBVQgBbUgABG5IAAR1CAEOEQiBbUgA
BG5IAAR1CAEAF09KAABRSgAAYUoYAG1IAARuSAAEdQgBJgIIgQNq2jQAAAYIAT4qAUIqAlUIAW1I
AARuSAAEcGgAAP8AdQgBAAttSAAEbkgABHUIAQ8wSh4AbUgABG5IAAR1CAEYA2oAAAAAMEoeAFUI
AW1IAARuSAAEdQgBKtUlAADbJQAA3CUAABUmAAAWJgAAFyYAADAmAAAxJgAAMiYAADQmAAA1JgAA
NiYAADcmAAA4JgAAOSYAAFQmAABVJgAAViYAAFcmAABdJgAAXiYAAJMmAACUJgAAlSYAAK4mAACv
JgAAsCYAALImAACzJgAAtCYAALUmAAC2JgAAtyYAANImAADTJgAA1CYAANUmAADbJgAA3CYAAP8m
AAAAJwAAAScAABonAAAbJwAAHCcAAPfr9+PX48nX49e867z3tveivPfr9+PX45TX49e867z3tveA
vPfr9+PX43LXAAAAABoCCIEDai05AAAGCAFVCAFtSAAEbkgABHUIAQAmAgiBA2qyOAAABggBPioB
QioCVQgBbUgABG5IAARwaAAA/wB1CAEAGgIIgQNqNzgAAAYIAVUIAW1IAARuSAAEdQgBACYCCIED
arw3AAAGCAE+KgFCKgJVCAFtSAAEbkgABHBoAAD/AHUIAQALbUgABG5IAAR1CAEYA2oAAAAAMEoe
AFUIAW1IAARuSAAEdQgBABoCCIEDakE3AAAGCAFVCAFtSAAEbkgABHUIAQAXA2oAAAAAEQiBVQgB
bUgABG5IAAR1CAEOEQiBbUgABG5IAAR1CAEAF09KAABRSgAAYUoYAG1IAARuSAAEdQgBDzBKHgBt
SAAEbkgABHUIAQAsHCcAAB4nAAAfJwAAICcAACEnAAAiJwAAIycAAJwnAACdJwAA3isAAN8rAACN
LAAAjiwAAJ8tAAC2LQAAEi4AACwuAADOLgAAzy4AAJwvAAAHMAAAZTAAAGYwAAB+MQAAfzEAAAYy
AAAHMgAANTMAADYzAABFNAAARjQAAJxYAACdWAAAV2gAAFhoAACbaAAAnGgAAN9oAADgaAAAHWkA
AB5pAABZaQAAWmkAAJ1pAACeaQAA3WkAAN5pAAATagAAFGoAAD9qAABAagAAQWoAAEJqAAB/agAA
gGoAAMJqAADDagAAC2sAAAxrAAAfcgAAIHIAAFiEAACBhAAA35MAAOCTAADFmwAA9JsAAPjs39PI
wwDDAMMAwwC+AL4AwwC3AMMAwwDDAMMAwwDDALAAqQCpAKkAqQCpAKkAqQCpAKkAqQCpAKkAqQC+
AKcAvgMMKgcMT0oAAFFKAABhShgAAAxhShgAbkgMBHRIDAQADDUIgTYIgVwIgV0IgQAIbUgMBHNI
DAQACE9KAABRSgAAABQDagAAAABVCAFtSAAEbkgABHUIAQAXT0oAAFFKAABhShgAbUgABG5IAAR1
CAEYA2oAAAAAMEoeAFUIAW1IAARuSAAEdQgBABcDagAAAAARCIFVCAFtSAAEbkgABHUIAQ4RCIFt
SAAEbkgABHUIAUIuKwAALysAAMYrAADLKwAA3isAAN8rAABXLAAAXCwAAGAsAABlLAAAfywAAIws
AACNLAAAjiwAAJ4tAACfLQAA0y0AABIuAAByLgAAqi4AAKsuAADKLgAAzy4AAJsvAACcLwAABzAA
ABIwAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA
7wAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOoAAAAA
AAAAAAAAAADqAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAAD2AAAAAAAAAAAA
AAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYA
AAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD2AAAAAAAA
AAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAEmAAABEQAFEQAKJgALRgYABRAACiYMC0YAAAABEAAJEQAKJgwLRgAA
D4SwAV6EsAEAGhIwAABlMAAAZjAAAFUxAAB+MQAAfzEAANMxAAAGMgAABzIAAOoyAAA1MwAANjMA
ABc0AABFNAAARjQAAE81AABQNQAAoTUAAKI1AAC6NQAAuzUAAPk1AAAINgAACTYAAEo2AACiNwAA
ozcAAP0AAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD0
AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA5QAA
AAAAAAAAAAAAAOUAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAOMAAAAAAAAA
AAAAAADhAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA
AAAAAAABEQAAASYADRAACiYAC0YAAA+EOAQRhJj+XoQ4BGCEmP4AARAACREACiYMC0YAAA+EsAFe
hLABAAEnAAAaozcAAPg3AAAZOAAAODgAADk4AACUOAAAvzgAAMA4AAAFOQAABjkAAEU5AABwOQAA
cTkAAHo6AACUOgAAlToAAJc7AAC9OwAAvjsAACc8AABQPAAAUTwAAK48AADKPAAAyzwAAFo9AAB4
PQAAeT0AAJ09AADXPQAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkA
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAAAAAEnAAAB
JgAAAREAAB3XPQAACT4AAAo+AAD3PgAAFT8AABY/AACgPwAAxj8AAMc/AAA5QAAAUUAAAFVAAACL
QAAAj0AAALNAAADQQAAA0UAAAB1BAADOQQAAz0EAAOFBAACGQgAAh0IAAIhCAADMQgAA2UIAAAZE
AAAHRAAAIUQAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA
+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPsAAAAA
AAAAAAAAAAD5AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAA
AAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsA
AAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD7AAAAAAAA
AAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAAAASYAAAER
AAABJwAAHCFEAACrRQAArEUAAMhFAACiRwAAo0cAAMRHAADjRwAAK0gAAFZIAABuSQAAb0kAAJpJ
AACCSgAAg0oAAJ1KAABBSwAAZ0sAAKVLAADOSwAAk0wAAJRMAACwTAAATk0AAE9NAABtTQAAUU4A
AFJOAACMTgAAvk4AAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
APsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAAAAABJgAAAScA
AAERAAAdvk4AABRPAAAyTwAAhU8AAKtPAABJUAAASlAAAGJQAACuUAAA5FAAAOhQAAAMUQAAKVEA
AI5RAACdUQAA31EAACpSAABxUgAAvVIAAARTAABbUwAAJVQAAI1UAADfVAAAIVUAAHdVAADUVQAA
QFYAAJNWAAD4VgAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD5AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAEmAAABJwAA
AREAAB34VgAAVVcAALNXAAD4VwAAnVgAAJ5YAACwWAAAsVgAAN5ZAAD5WgAA+loAAKFbAACiWwAA
3lsAAPNbAADvXAAA8FwAAF9dAABgXQAAtV0AANZdAAD1XQAAFl4AAEFeAADKXgAA9V4AABpfAAA0
XwAAnl8AAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAA
AAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAA
AAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPcAAAAAAAAA
AAAAAAD5AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA
+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAAAASYAAAERAAAB
JwAAHJ5fAADEXwAA7l8AABdgAACLYAAAp2AAAARhAAAiYQAASmEAAIRhAAC2YQAA+2EAABliAABD
YgAAaWIAALdiAADPYgAAH2MAAFVjAABZYwAAfWMAAJpjAAA+ZAAAUGQAAH1lAAATZwAAFGcAALxn
AAC9ZwAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5
AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAA
AAAAAAAAAPkAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAA
AAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJgAAAREAAAEn
AAAcvWcAAAdoAAAWaAAAWGgAAJxoAADgaAAAHmkAAFppAACeaQAA3mkAABRqAABAagAAQmoAAIBq
AADDagAADGsAAA1rAABNawAAlWsAANprAADrawAAMGwAAHJsAAC0bAAA+WwAADptAABRbQAAjW0A
AMttAADMbQAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA
AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5
AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA
AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA
AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA
AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA
AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAERAAABJgAAARAA
AB3MbQAADG4AAFFuAABpbgAAam4AAKxuAADwbgAAK28AACxvAABsbwAAsG8AAPVvAAA6cAAAf3AA
AJdwAACYcAAA23AAAB9xAABjcQAAqHEAAOxxAAAfcgAAIHIAAHVyAACWcgAAtXIAAPBzAADxcwAA
HHQAAJV0AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAScAAAEmAAABEQAA
HZV0AACWdAAAQ3UAAHx1AADNdQAA5XUAAOZ1AAB/dgAAgHYAAKt2AAB8dwAAfXcAAFp4AABbeAAA
QHkAAEF5AABbeQAA1nkAANd5AAAoegAASHoAAGB6AACsegAArXoAANJ6AADTegAAkHsAAP57AABn
fAAA03wAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAScAAAERAAAd
03wAANp8AADbfAAAAX0AAH59AAB/fQAAF34AABh+AACwfgAAsX4AANp+AAAMgAAADYAAAFCBAABR
gQAAbYEAAMmBAADngQAAgoIAAIOCAAC9ggAA74IAADqEAABYhAAAW4QAAIGEAACEhAAAnIQAAG2F
AACjhQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAEmAAABJwAAAREAAB2j
hQAAxIUAAA2GAACuhgAA/4gAAGaJAAAxigAAMooAAJKKAACTigAAt4oAANSKAACniwAAqIsAAHmM
AAB6jAAAwowAANSMAAB5jQAAeo0AAHuNAAC+jQAAx40AAPCNAADxjQAAWpAAAFuQAAAukgAAMJIA
AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAA
AAAAAPUAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA
AADzAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAABEAAAAScAAAEmAAAFEQAPhAAAXoQAAAABEQAAHDCS
AADLkwAA35MAAOCTAAC1lAAAtpQAAC+XAAAwlwAApZcAAMKXAADhlwAATpgAAGGYAAABmQAAApkA
AA2ZAAA5mQAAkJkAAIaaAABrmwAAfpsAAIubAACYmwAApZsAAMWbAADTmwAA9JsAAAGcAAAXnAAA
/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD5AAAAAAAAAAAA
AAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA+wAAAAAAAAAAAAAAAAAAAAAAAAAABREACiYAC0YNAAABJgAAAScAAAERAAAcF5wA
AA+eAAAnngAAIaAAADqgAAC7oQAA0KEAAO+iAAAMowAAOqMAABikAAAipAAAN6YAAFWmAABLqAAA
eagAAIeoAACfqAAAo6gAALyoAAAkqQAAOKkAADiqAAB5qgAAkKoAAKGqAAC9qgAAzqoAAPKqAAAD
qwAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD7AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAPkAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAEmAAABJwAAAREAAB30mwAA
oaoAAL2qAAC+rwAA368AAFu1AABctQAAfLUAAH21AAA0tgAANbYAAK26AADtugAA2bsAANq7AADm
uwAAZbwAAGa8AAB/vAAAg7wAAO/BAADwwQAAAcIAAHbEAACuxAAASs0AAGfNAACPzwAAnM8AABbR
AAA90QAAftEAAN3RAAA01wAANdcAAE/YAABr2AAAutkAAM7ZAACk3AAAydwAAPnqAAAV6wAABO8A
ABHvAABr9QAAbfUAAC75AAAw+QAAV/kAAFj5AACA+QAAgfkAAIv5AACM+QAAj/kAAJD5AACS+QAA
q/kAAKz5AACy+QAAs/kAALn5AAC6+QAAvPkAAL35AADA+QAAwvkAANz5AADd+QAA6PkAAOn5AAAA
+wD7APYA9gD2APEA9gD76ADlAN72APsA+wD2APsA+wD2APsA9gD7APsA9gD2APYA2QDZ09n2APYA
9gDMyczBzAD2APYA9gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8wSg8AbUgABG5IAAR1CAEE
MEoPAAANA2oAAAAAMEoPAFUIAQttSAAEbkgABHUIAQkDagAAAABVCAEMQ0oYAE9KAABRSgAAAARD
ShgAABBPSgAAUUoAAG1IDARzSAwEAAhtSAcEc0gHBAAIT0oAAFFKAAAACG1IDARzSAwERwOrAAAX
qwAAKKsAAE2rAABeqwAAX6sAAJyrAACxqwAALq0AAC+tAAAzrgAAUK4AAG+uAACyrgAAxa4AAPGu
AAAErwAAQq8AAE+vAABtrwAAja8AAL6vAADfrwAA/68AABWwAABSsAAAarAAAKmwAADCsAAA/QAA
AAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAA
AAAAAAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA
+wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsA
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAAAAAAURAA+ERgJehEYCAAEmAAABEAAAAREAAAEnAAAcwrAAAPyw
AAARsQAA2bEAAPaxAAAksgAAobIAAKuyAADWsgAA9LIAAB+zAABNswAAbrMAAIazAACNswAAprMA
AOCzAAD0swAANrQAAHe0AACOtAAAn7QAALu0AADMtAAA8LQAAAG1AAAVtQAAJrUAAEu1AABctQAA
/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPsAAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA+QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAEmAAABJwAAAREAAB1ctQAAXbUA
AGK1AAB7tQAAfbUAACS2AAAptgAANbYAALm2AAC6tgAAcbcAAHK3AACmtwAA7bcAADS4AABZuAAA
nLgAAOK4AAAWuQAAS7kAAJG5AADXuQAA8bkAAD66AABfugAArboAAO26AAAtuwAAcrsAAP0AAAAA
AAAAAAAAAAD0AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAA
AAAA9AAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAAAAAAAAAEQAAkRAAomDAtGAAAPhLABXoSwAQABEQAAHHK7AADDuwAA
xLsAANW7AADauwAA5rsAAPK7AAAfvAAAX7wAAGS8AABmvAAAf7wAAIO8AADEvAAAyLwAAAy9AABR
vQAAlL0AANW9AAAXvgAAXL4AAKC+AADkvgAAIL8AAF+/AACcvwAA378AACHAAABiwAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAPIAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAAABFwAFJQAKJgALRgAAAAURAA+EAABehAAAAAERAAAcYsAAAJjAAADc
wAAAGsEAAF3BAACfwQAA2sEAAO/BAADwwQAA8cEAAPLBAADzwQAA9MEAAPXBAAABwgAAHsIAAD3C
AACEwgAAE8MAACbDAAAnwwAAB8QAABrEAAAbxAAAMcQAAD7EAAA/xAAAVcQAAHXEAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAScAAAEmAAABFwAAAREAABx1xAAAdsQAAIzE
AACtxAAArsQAADTFAABKxQAAS8UAALXGAADNxgAAzsYAACPHAAA8xwAAPccAAI/HAACkxwAApccA
AO7HAABeyAAAe8gAAKnIAACqyAAAaskAAHTJAAB1yQAAjskAAKzJAACtyQAAxskAAPTJAAD9AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD5AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAAAAASYAAAEnAAABEQAAHfTJAAD1yQAAEMoA
ACjKAAApygAANMsAAE3LAABOywAArcsAAMHLAADCywAALcwAAG7MAACFzAAAhswAAErNAABmzQAA
Z80AAKnNAAD9zQAAIc4AACLOAAC0zgAAyM4AAMnOAAA0zwAAWc8AAFrPAACPzwAAkM8AAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAABJgAAAScAAAERAAAdkM8AAJHPAACczwAA
uc8AANjPAACP0AAAotAAABbRAAAp0QAAPdEAAErRAABe0QAAftEAAJLRAACz0QAAx9EAAN3RAAB3
0gAAj9IAAKTSAAC90gAAWtMAAG/TAABw0wAAxtMAAOPTAAAR1AAAy9QAANXUAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkA
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD5AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA+QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAPAAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD5
AAAAAAAAAAAAAAAACREACiYMC0YAAA+EsAFehLABAAEnAAABJgAAAREAABzV1AAA+NQAABbVAACs
1QAArdUAANvVAADw1QAACNYAAAzWAAAl1gAAwtYAANbWAAA01wAANdcAAHbXAACN1wAAT9gAAGvY
AACA2AAApNgAAKjYAAC82AAAGdkAAD7ZAAC52QAAutkAAM3ZAADO2QAA/QAAAAAAAAAAAAAAAPsA
AAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
APsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAAD7AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAA
ASYAAAURAA+EAABehAAACREACiYMC0YAAA+EsAFehLABAAEnAAABEQAAG87ZAADr2QAACtoAAGTa
AABl2gAAb9sAAILbAADL2wAA3tsAACfcAAA03AAAhNwAAKTcAACo3AAAydwAAF7dAABf3QAAdd0A
APrdAAAS3gAAbN4AAG3eAAD73gAAFN8AAJbfAACX3wAArN8AACrgAABp4AAAhuAAAP0AAAAAAAAA
AAAAAAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA
+wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPsAAAAA
AAAAAAAAAAD5AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD7AAAAAAAAAAAA
AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPsA
AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD7AAAAAAAA
AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA
APkAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAABEQAAAScAAAEmAAAdhuAAALTgAAAO4QAAD+EA
AF7iAABf4gAAu+IAAMXiAAAw4wAATuMAADDkAABe5AAA8+QAAAvlAADv5QAACOYAAIrmAACe5gAA
+OYAAPnmAACK6AAAy+gAAOLoAAA86QAAPekAAJzqAACd6gAA+eoAABXrAABB6wAA/QAAAAAAAAAA
AAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAA
AAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAA
AAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAAAAAEmAAABEQAAAScAAB1B6wAAZesAAFnsAABt7AAA
x+wAAMjsAABf7gAAhO4AABDvAAAR7wAAMu8AAFHvAADm7wAAEfAAAIDwAACr8AAAOvEAAFTxAAAB
8gAAJ/IAACryAABT8gAAOfMAAFXzAADm8wAABPQAAGv1AABs9QAAbfUAAKf1AAD9AAAAAAAAAAAA
AAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsA
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7
AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAASYAAAERAAABJwAAHaf1AADZ9QAA9/UAALH2AACy
9gAA2PYAAPr2AAAS9wAAl/cAAM33AACW+AAAuvgAANf4AAAu+QAAL/kAAI35AACO+QAAj/kAAJD5
AACR+QAAkvkAAL/5AADA+QAAwfkAAML5AADm+QAA5/kAAOj5AADp+QAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAA
APkAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD3AAAA
AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8wAAAAAAAAAA
AAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADz
AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+wAAAAAA
AAAAAAAAAAAAAAAAAAABEwAAAQAAAAESAAABJgAAAREAAAEnAAAcMAEC0tQAAAEAAAD//wAAAQAA
AAAAAAAABAAA//8AAAEAAAAAAAABAAQAAP//AAABAAAAAAAAAQAEAAD//wAAAQAAAAAAAAEABAAA
//8AAAEAAAAAAAABAAQAAP//AAABAAAAAAAAAQAEAAD//wAAAQAAAAAAAAEABAAA//8AAAEAAAAA
AAABAAwAAP//AAABADAGeAAAAAAALgAuAC4ALgAuAC4ALgAuAAAAAACCAAAAAAAAACgvBAeCAAAA
AAAAAAAAAAAAAAAAKC8EBwABAAAAAAAAICsEBwowARQwKiZQAQAcUAEAH7DQLyCw4D0hsAMBIrBQ
ByOQ2wEkkAMBJbAAABewAAAYsAAAONIkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A
AAD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB7AAAARAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brO
EYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA1ADEAAAB7AAAARAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA1ADEAAAB7
AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYA
NgA1ADIAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAz
ADQANgA2ADYANgA1ADIAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAA
XwBUAG8AYwAzADQANgA2ADYANgA1ADMAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAA
AAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA1ADMAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyC
AKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA1ADQAAAB7AAAARAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQ
yep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA1ADQAAAB7AAAA
RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA1
ADUAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQA
NgA2ADYANgA1ADUAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBU
AG8AYwAzADQANgA2ADYANgA1ADYAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgA
AAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA1ADYAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoA
S6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA1ADcAAAB7AAAARAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5
+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA1ADcAAAB7AAAARAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA1ADgA
AAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2
ADYANgA1ADgAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8A
YwAzADQANgA2ADYANgA1ADkAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAN
AAAAXwBUAG8AYwAzADQANgA2ADYANgA1ADkAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kL
AgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA2ADAAAAB7AAAARAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brO
EYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA2ADAAAAB7AAAARAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA2ADEAAAB7
AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYA
NgA2ADEAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAz
ADQANgA2ADYANgA2ADIAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAA
XwBUAG8AYwAzADQANgA2ADYANgA2ADIAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAA
AAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA2ADMAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyC
AKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA2ADMAAAB7AAAARAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQ
yep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA2ADQAAAB7AAAA
RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA2
ADQAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQA
NgA2ADYANgA2ADUAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBU
AG8AYwAzADQANgA2ADYANgA2ADUAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgA
AAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA2ADYAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoA
S6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA2ADYAAAB7AAAARAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5
+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA2ADcAAAB7AAAARAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA2ADcA
AAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2
ADYANgA2ADgAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8A
YwAzADQANgA2ADYANgA2ADgAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAN
AAAAXwBUAG8AYwAzADQANgA2ADYANgA2ADkAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kL
AgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA2ADkAAAB7AAAARAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brO
EYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA3ADAAAAB7AAAARAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA3ADAAAAB7
AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYA
NgA3ADEAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAz
ADQANgA2ADYANgA3ADEAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAA
XwBUAG8AYwAzADQANgA2ADYANgA3ADIAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAA
AAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA3ADIAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyC
AKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA3ADMAAAB7AAAARAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQ
yep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA3ADMAAAB7AAAA
RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA3
ADQAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQA
NgA2ADYANgA3ADQAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBU
AG8AYwAzADQANgA2ADYANgA3ADUAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgA
AAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA3ADUAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoA
S6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA3ADYAAAB7AAAARAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5
+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA3ADYAAAB7AAAARAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA3ADcA
AAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2
ADYANgA3ADcAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8A
YwAzADQANgA2ADYANgA3ADgAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAN
AAAAXwBUAG8AYwAzADQANgA2ADYANgA3ADgAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kL
AgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA3ADkAAAB7AAAARAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brO
EYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA3ADkAAAB7AAAARAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA4ADAAAAB7
AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYA
NgA4ADAAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAz
ADQANgA2ADYANgA4ADEAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAA
XwBUAG8AYwAzADQANgA2ADYANgA4ADEAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAA
AAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA4ADIAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyC
AKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA4ADIAAAB7AAAARAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQ
yep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA4ADMAAAB7AAAA
RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA4
ADMAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQA
NgA2ADYANgA4ADQAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBU
AG8AYwAzADQANgA2ADYANgA4ADQAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgA
AAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA4ADUAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoA
S6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA4ADUAAAB7AAAARAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5
+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA4ADYAAAB7AAAARAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA4ADYA
AAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2
ADYANgA4ADcAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8A
YwAzADQANgA2ADYANgA4ADcAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAN
AAAAXwBUAG8AYwAzADQANgA2ADYANgA4ADgAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kL
AgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA4ADgAAAB7AAAARAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brO
EYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA4ADkAAAB7AAAARAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA4ADkAAAB7
AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYA
NgA5ADAAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAz
ADQANgA2ADYANgA5ADAAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAA
XwBUAG8AYwAzADQANgA2ADYANgA5ADEAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAA
AAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA5ADEAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyC
AKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA5ADIAAAB7AAAARAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQ
yep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA5ADIAAAB7AAAA
RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA5
ADMAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQA
NgA2ADYANgA5ADMAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBU
AG8AYwAzADQANgA2ADYANgA5ADQAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgA
AAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA5ADQAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoA
S6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA5ADUAAAB7AAAARAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5
+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA5ADUAAAB7AAAARAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA5ADYA
AAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2
ADYANgA5ADYAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8A
YwAzADQANgA2ADYANgA5ADcAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAN
AAAAXwBUAG8AYwAzADQANgA2ADYANgA5ADcAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kL
AgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA5ADgAAAB7AAAARAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brO
EYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA5ADgAAAB7AAAARAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA5ADkAAAB7
AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYA
NgA5ADkAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAz
ADQANgA2ADYANwAwADAAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAA
XwBUAG8AYwAzADQANgA2ADYANwAwADAAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAA
AAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANwAwADEAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyC
AKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANwAwADEAAAB7AAAARAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQ
yep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANwAwADIAAAB7AAAA
RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANwAw
ADIAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQA
NgA2ADYANwAwADMAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBU
AG8AYwAzADQANgA2ADYANwAwADMAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgA
AAANAAAAXwBUAG8AYwAzADQANgA2ADYANwAwADQAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoA
S6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANwAwADQAAAB7AAAARAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5
+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANwAwADUAAAB7AAAARAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANwAwADUA
AAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2
ADYANwAwADYAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8A
YwAzADQANgA2ADYANwAwADYAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAN
AAAAXwBUAG8AYwAzADQANgA2ADYANwAwADcAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kL
AgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANwAwADcAAAB7AAAARAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brO
EYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANwAwADgAAAB7AAAARAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANwAwADgAAAB7
AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYA
NwAwADkAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAAXwBUAG8AYwAz
ADQANgA2ADYANwAwADkAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAANAAAA
XwBUAG8AYwAzADQANgA2ADYANwAxADAAAAB7AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAA
AAgAAAANAAAAXwBUAG8AYwAzADQANgA2ADYANwAxADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAFAApAAoAAQBpAA8AAwAAAAAAAAAAAEQAAEDx/wIARAAMAAYATgBvAHIAbQBhAGwA
AAASAAAANSQANyQAOCQAOUQCAEgkABQAQ0oYAF9IAQRtSAkEc0gJBHRICQRIAAFAAQACAEgADAAJ
AEgAZQBhAGQAaQBuAGcAIAAxAAAAEAABAAYkAROk8AAUpDwAQCYAEwA1CIFDSiAAS0ggAE9KAgBR
SgIAAEYAAkABAAIARgAMAAkASABlAGEAZABpAG4AZwAgADIAAAAQAAIABiQBE6TwABSkPABAJgES
ADUIgTYIgUNKHABPSgIAUUoCAFQAA0ABAAIAVAAMAAkASABlAGEAZABpAG4AZwAgADMAAAAfAAMA
BiQBCiYCC0YBAA3GBQAB0AIAE6TwABSkPABAJgIADwA1CIFDShoAT0oCAFFKAgAATAAEAAEAAgBM
AAwACQBIAGUAYQBkAGkAbgBnACAANAAAAB8ABAAGJAEKJgMLRgEADcYFAAFgAwATpPAAFKQ8AEAm
AwAHADUIgUNKHAAASgAFAAEAAgBKAAwACQBIAGUAYQBkAGkAbgBnACAANQAAABwABQAKJgQLRgEA
DcYFAAHwAwATpPAAFKQ8AEAmBAoANQiBNgiBQ0oaAEgABgABAAIASAAMAAkASABlAGEAZABpAG4A
ZwAgADYAAAAcAAYACiYFC0YBAA3GBQABgAQAE6TwABSkPABAJgUHADUIgUNKFgAAQAAHAAEAAgBA
AAwACQBIAGUAYQBkAGkAbgBnACAANwAAABwABwAKJgYLRgEADcYFAAEQBQATpPAAFKQ8AEAmBgAA
RAAIAAEAAgBEAAwACQBIAGUAYQBkAGkAbgBnACAAOAAAABwACAAKJgcLRgEADcYFAAGgBQATpPAA
FKQ8AEAmBwMANgiBAEwACQABAAIATAAMAAkASABlAGEAZABpAG4AZwAgADkAAAAcAAkACiYIC0YB
AA3GBQABMAYAE6TwABSkPABAJggMAENKFgBPSgIAUUoCADwAQUDy/6EAPAAMABYARABlAGYAYQB1
AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAAAAAAAAAAAAmAClAogDxACYA
DAALAFAAYQBnAGUAIABOAHUAbQBiAGUAcgAAAAAAUgD+TxEAAgFSAA0ADABSAEYAQwAgAEgAZQBh
AGQAaQBuAGcAMQAAABcAEAAKJgALRgkAEmQQ/wAAE6QAABSkAAAADwA1CIFDShgAT0oDAFFKAwAA
hAD+TwEAEgGEAAwACABSAEYAQwAgAFQAZQB4AHQAAABaABEADcZHABewAWADEAXABnAIIArQC4AN
MA/gEJASQBTwFaAXUBkAG7AcYB4QIMAhcCMgJdAmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPhLAB
EmQQ/wAAXoSwAQgAT0oDAFFKAwA6AB9AAQAiAToADAAGAEgAZQBhAGQAZQByAAAAEwASAA3GCAAC
sBNgJwECEmQQ/wAAAAgAT0oDAFFKAwA6ACBAAQAyAToADAAGAEYAbwBvAHQAZQByAAAAEwATAA3G
CAACsBNgJwECEmQQ/wAAAAgAT0oDAFFKAwBgABNAEQECAGAABAAFAFQATwBDACAAMQAAADgAFAAN
xjMXsAFgAxAFwAZwCCAK0AuADTAP4BCQEkAU8BWgF1AZABuwHGAeECDAIXAjICXQJgFgJwoLAG1I
AARuSAAEdQgBAFwAFEARAQIAXAAMAAUAVABPAEMAIAAyAAAAQAAVAA3GMxewAWADEAXABnAIIArQ
C4ANMA/gEJASQBTwFaAXUBkAG7AcYB4QIMAhcCMgJdAmAWAnCg+EYANehGADAAAmABUAEQECACYA
DAAFAFQATwBDACAAMwAAAAoAFgAPhAAAXoQAAAAANABaQAEAcgE0AAwACgBQAGwAYQBpAG4AIABU
AGUAeAB0AAAAAgAXAAwAQ0oUAE9KAwBRSgMAJgAWAAEAAgAmAAwABQBUAE8AQwAgADQAAAAKABgA
D4TQAl6E0AIAACYAFwABAAIAJgAMAAUAVABPAEMAIAA1AAAACgAZAA+EwANehMADAAAmABgAAQAC
ACYADAAFAFQATwBDACAANgAAAAoAGgAPhLAEXoSwBAAAJgAZAAEAAgAmAAwABQBUAE8AQwAgADcA
AAAKABsAD4SgBV6EoAUAACYAGgABAAIAJgAMAAUAVABPAEMAIAA4AAAACgAcAA+EkAZehJAGAAAm
ABsAAQACACYADAAFAFQATwBDACAAOQAAAAoAHQAPhIAHXoSABwAAKABVQKIA4QEoAAwACQBIAHkA
cABlAHIAbABpAG4AawAAAAYAPioBQioCOABWQKIA8QE4AAwAEQBGAG8AbABsAG8AdwBlAGQASAB5
AHAAZQByAGwAaQBuAGsAAAAGAD4qAUIqDHAA/k8RAAICcAAEABQAUgBGAEMAIABIAGUAYQBkAGkA
bgBnACAALQAgAE4AbwAgAFQATwBDAAAAGwAgAA3GBQABcycKEmQQ/wAAE6QAABSkAABAJgkAGgA1
CIFDShgAT0oDAFFKAwBtSAAEbkgABHUIATIAHQABABICMgAMAA0ARgBvAG8AdABuAG8AdABlACAA
VABlAHgAdAAAAAIAIQAEAENKFAA2ACpAogAhAjYADAARAEUAbgBkAG4AbwB0AGUAIABSAGUAZgBl
AHIAZQBuAGMAZQAAAAMASCoAADwAKwARATICPAAMAAwARQBuAGQAbgBvAHQAZQAgAFQAZQB4AHQA
AAASACMAD4RgAxGEUP5ehGADYIRQ/gAAOAAmQKIAQQI4AAwAEgBGAG8AbwB0AG4AbwB0AGUAIABS
AGUAZgBlAHIAZQBuAGMAZQAAAAMASCoBAMoA/k8RAFICygAMAAsAUgBGAEMAIABIAGUAYQBkAGkA
bgBnAAAAkgAlAAomCwtG/wcNxggAAmgBsAEAAA+EsAERhFD+EmQQ/wAAE6QAABSkAAA+xlQAAAAA
AAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAJglUZgAAAP9ehLABYIRQ/g8ANQiBQ0oYAE9KAwBRSgMA
AEYA/k8hABIBRgANAAwAUgBGAEMAIABIAGUAYQBkAGkAbgBnADIAAAAJACYACiYBC0YJAAASADUI
gTYIgUNKGABPSgMAUUoDAEQA/k8xABIBRAAMAAwAUgBGAEMAIABIAGUAYQBkAGkAbgBnADMAAAAJ
ACcACiYCC0YJAAAPADUIgUNKGABPSgMAUUoDAABSAP4PYQISAVIADAAGAFMAdAB5AGwAZQAxAAAA
JwAoAAomAQtGAwASZBD/AAATpAAAFKQAADUkATckATgkATlEBABIJAEADABLSCAAUEoFAGFKGAAA
AAAA6fUAAAoAAHgBAAgA/////wAAAAAPAAAAFwAAABgAAABDAAAASgAAAEsAAAB2AAAAfwAAAIAA
AACLAAAAwQAAAMIAAADDAAAA4AAAAOEAAAACAQAASAEAALIBAAD8AQAAuwMAANoEAADbBAAAmgUA
AJsFAACiBQAAowUAAKkFAACqBQAArAUAAMEFAADCBQAALwYAADQGAAD/BgAABAcAAAkIAAAOCAAA
RggAAHcIAAC5CAAA3ggAAOMIAADtCAAA7ggAAM8JAADRCQAA4wkAAOQJAABGCgAAnAoAAP0KAABN
CwAAywsAAB4MAACfDAAA8wwAAFkNAADYDQAAUw4AALwOAAATDwAAmg8AAOwPAABSEAAA0RAAAEwR
AAC1EQAACRIAAGASAADgEgAAOxMAAKITAAAiFAAAnhQAAAgVAABgFQAA5RUAADoWAAChFgAAIRcA
AJ0XAAAHGAAAXxgAAOYYAAA0GQAAlxkAAPoZAACBGgAAAxsAAF8bAADDGwAAJxwAAK8cAAAMHQAA
XB0AAMAdAAAkHgAArB4AABAfAAB0HwAA/B8AAGAgAADEIAAATCEAALUhAAA3IgAAtSIAACEjAAAj
IwAALSMAADIjAACYIwAAnSMAANMjAADUIwAATSQAAIUkAAD9JAAAaiUAAGslAADLJQAAzCUAAIYm
AACHJgAALicAAC8nAADGJwAAyycAAN4nAADfJwAAVygAAFwoAABgKAAAZSgAAH8oAACMKAAAjSgA
AI4oAACeKQAAnykAANMpAAASKgAAcioAAKoqAACrKgAAyioAAM8qAACbKwAAnCsAAAcsAAASLAAA
ZSwAAGYsAABVLQAAfi0AAH8tAADTLQAABi4AAAcuAADqLgAANS8AADYvAAAXMAAARTAAAEYwAABP
MQAAUDEAAKExAACiMQAAujEAALsxAAD5MQAACDIAAAkyAABKMgAAojMAAKMzAAD4MwAAGTQAADg0
AAA5NAAAlDQAAL80AADANAAABTUAAAY1AABFNQAAcDUAAHE1AAB6NgAAlDYAAJU2AACXNwAAvTcA
AL43AAAnOAAAUDgAAFE4AACuOAAAyjgAAMs4AABaOQAAeDkAAHk5AACdOQAA1zkAAAk6AAAKOgAA
9zoAABU7AAAWOwAAoDsAAMY7AADHOwAAOTwAAFE8AABVPAAAizwAAI88AACzPAAA0DwAANE8AAAd
PQAAzj0AAM89AADhPQAAhj4AAIc+AACIPgAAzD4AANk+AAAGQAAAB0AAACFAAACrQQAArEEAAMhB
AACiQwAAo0MAAMRDAADjQwAAK0QAAFZEAABuRQAAb0UAAJpFAACCRgAAg0YAAJ1GAABBRwAAZ0cA
AKVHAADORwAAk0gAAJRIAACwSAAATkkAAE9JAABtSQAAUUoAAFJKAACMSgAAvkoAABRLAAAySwAA
hUsAAKtLAABJTAAASkwAAGJMAACuTAAA5EwAAOhMAAAMTQAAKU0AAI5NAACdTQAA300AACpOAABx
TgAAvU4AAARPAABbTwAAJVAAAI1QAADfUAAAIVEAAHdRAADUUQAAQFIAAJNSAAD4UgAAVVMAALNT
AAD4UwAAnVQAAJ5UAACwVAAAsVQAAN5VAAD5VgAA+lYAAKFXAACiVwAA3lcAAPNXAADvWAAA8FgA
AF9ZAABgWQAAtVkAANZZAAD1WQAAFloAAEFaAADKWgAA9VoAABpbAAA0WwAAnlsAAMRbAADuWwAA
F1wAAItcAACnXAAABF0AACJdAABKXQAAhF0AALZdAAD7XQAAGV4AAENeAABpXgAAt14AAM9eAAAf
XwAAVV8AAFlfAAB9XwAAml8AAD5gAABQYAAAfWEAABNjAAAUYwAAvGMAAL1jAAAHZAAAFmQAAFhk
AACcZAAA4GQAAB5lAABaZQAAnmUAAN5lAAAUZgAAQGYAAEJmAACAZgAAw2YAAAxnAAANZwAATWcA
AJVnAADaZwAA62cAADBoAAByaAAAtGgAAPloAAA6aQAAUWkAAI1pAADLaQAAzGkAAAxqAABRagAA
aWoAAGpqAACsagAA8GoAACtrAAAsawAAbGsAALBrAAD1awAAOmwAAH9sAACXbAAAmGwAANtsAAAf
bQAAY20AAKhtAADsbQAAH24AACBuAAB1bgAAlm4AALVuAADwbwAA8W8AABxwAACVcAAAlnAAAENx
AAB8cQAAzXEAAOVxAADmcQAAf3IAAIByAACrcgAAfHMAAH1zAABadAAAW3QAAEB1AABBdQAAW3UA
ANZ1AADXdQAAKHYAAEh2AABgdgAArHYAAK12AADSdgAA03YAAJB3AAD+dwAAZ3gAANN4AADaeAAA
23gAAAF5AAB+eQAAf3kAABd6AAAYegAAsHoAALF6AADaegAADHwAAA18AABQfQAAUX0AAG19AADJ
fQAA530AAIJ+AACDfgAAvX4AAO9+AAA6gAAAWIAAAFuAAACBgAAAhIAAAJyAAABtgQAAo4EAAMSB
AAANggAAroIAAP+EAABmhQAAMYYAADKGAACShgAAk4YAALeGAADUhgAAp4cAAKiHAAB5iAAAeogA
AMKIAADUiAAAeYkAAHqJAAB7iQAAvokAAMeJAADwiQAA8YkAAFqMAABbjAAALo4AADCOAADLjwAA
348AAOCPAAC1kAAAtpAAAC+TAAAwkwAApZMAAMKTAADhkwAATpQAAGGUAAABlQAAApUAAA2VAAA5
lQAAkJUAAIaWAABrlwAAfpcAAIuXAACYlwAApZcAAMWXAADTlwAA9JcAAAGYAAAXmAAAD5oAACea
AAAhnAAAOpwAALudAADQnQAA754AAAyfAAA6nwAAGKAAACKgAAA3ogAAVaIAAEukAAB5pAAAh6QA
AJ+kAACjpAAAvKQAACSlAAA4pQAAOKYAAHmmAACQpgAAoaYAAL2mAADOpgAA8qYAAAOnAAAXpwAA
KKcAAE2nAABepwAAX6cAAJynAACxpwAALqkAAC+pAAAzqgAAUKoAAG+qAACyqgAAxaoAAPGqAAAE
qwAAQqsAAE+rAABtqwAAjasAAL6rAADfqwAA/6sAABWsAABSrAAAaqwAAKmsAADCrAAA/KwAABGt
AADZrQAA9q0AACSuAAChrgAAq64AANauAAD0rgAAH68AAE2vAABurwAAhq8AAI2vAACmrwAA4K8A
APSvAAA2sAAAd7AAAI6wAACfsAAAu7AAAMywAADwsAAAAbEAABWxAAAmsQAAS7EAAFyxAABdsQAA
YrEAAHuxAAB9sQAAJLIAACmyAAA1sgAAubIAALqyAABxswAAcrMAAKazAADtswAANLQAAFm0AACc
tAAA4rQAABa1AABLtQAAkbUAANe1AADxtQAAPrYAAF+2AACttgAA7bYAAC23AABytwAAw7cAAMS3
AADVtwAA2rcAAOa3AADytwAAH7gAAF+4AABkuAAAZrgAAH+4AACDuAAAxLgAAMi4AAAMuQAAUbkA
AJS5AADVuQAAF7oAAFy6AACgugAA5LoAACC7AABfuwAAnLsAAN+7AAAhvAAAYrwAAJi8AADcvAAA
Gr0AAF29AACfvQAA2r0AAO+9AADwvQAA8b0AAPK9AADzvQAA9L0AAPW9AAABvgAAHr4AAD2+AACE
vgAAE78AACa/AAAnvwAAB8AAABrAAAAbwAAAMcAAAD7AAAA/wAAAVcAAAHXAAAB2wAAAjMAAAK3A
AACuwAAANMEAAErBAABLwQAAtcIAAM3CAADOwgAAI8MAADzDAAA9wwAAj8MAAKTDAAClwwAA7sMA
AF7EAAB7xAAAqcQAAKrEAABqxQAAdMUAAHXFAACOxQAArMUAAK3FAADGxQAA9MUAAPXFAAAQxgAA
KMYAACnGAAA0xwAATccAAE7HAACtxwAAwccAAMLHAAAtyAAAbsgAAIXIAACGyAAASskAAGbJAABn
yQAAqckAAP3JAAAhygAAIsoAALTKAADIygAAycoAADTLAABZywAAWssAAI/LAACQywAAkcsAAJzL
AAC5ywAA2MsAAI/MAACizAAAFs0AACnNAAA9zQAASs0AAF7NAAB+zQAAks0AALPNAADHzQAA3c0A
AHfOAACPzgAApM4AAL3OAABazwAAb88AAHDPAADGzwAA488AABHQAADL0AAA1dAAAPjQAAAW0QAA
rNEAAK3RAADb0QAA8NEAAAjSAAAM0gAAJdIAAMLSAADW0gAANNMAADXTAAB20wAAjdMAAE/UAABr
1AAAgNQAAKTUAACo1AAAvNQAABnVAAA+1QAAudUAALrVAADN1QAAztUAAOvVAAAK1gAAZNYAAGXW
AABv1wAAgtcAAMvXAADe1wAAJ9gAADTYAACE2AAApNgAAKjYAADJ2AAAXtkAAF/ZAAB12QAA+tkA
ABLaAABs2gAAbdoAAPvaAAAU2wAAltsAAJfbAACs2wAAKtwAAGncAACG3AAAtNwAAA7dAAAP3QAA
Xt4AAF/eAAC73gAAxd4AADDfAABO3wAAMOAAAF7gAADz4AAAC+EAAO/hAAAI4gAAiuIAAJ7iAAD4
4gAA+eIAAIrkAADL5AAA4uQAADzlAAA95QAAnOYAAJ3mAAD55gAAFecAAEHnAABl5wAAWegAAG3o
AADH6AAAyOgAAF/qAACE6gAAEOsAABHrAAAy6wAAUesAAObrAAAR7AAAgOwAAKvsAAA67QAAVO0A
AAHuAAAn7gAAKu4AAFPuAAA57wAAVe8AAObvAAAE8AAAa/EAAGzxAABt8QAAp/EAANnxAAD38QAA
sfIAALLyAADY8gAA+vIAABLzAACX8wAAzfMAAJb0AAC69AAA1/QAAC71AAAv9QAAjfUAAI71AACP
9QAAkPUAAJH1AACS9QAAv/UAAOr1AACpAAAAIDAAAAAAAAAAgAAAAICpAAAAIDAAAAAAAAAAgAAA
AICZAAAAADAAAAAAAAAAgAAAAICpAAAAIDAAAAAAAAAAgAAAAICpAAAAIDAAAAAAAAAAgAAAAICZ
AAAAADAAAAAAAAAAgAAAAICpAAAAIDAAAAAAAAAAgAAAAICpAAAAIDAAAAAAAAAAgAAAAICZAAAA
ADAAAAAAAAAAgAAAAICpAAAAIDAAAAAAAAAAgAAAAICpAAAAIDAAAAAAAAAAgAAAAICZAAAAADAA
AAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAIDAAAAAA
AAAAgAAAAICYAAAAIDAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAA
gAAAAICYAA8gETAAAAAAAAAAgAAAAICYAA8gETABAAAAAAAAgAAAAICYAA8gETACAAAAAAAAgAAA
AICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICY
AAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAA
ETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAIDAAAAAAAAAAgAAAAICYAAAAETAA
AAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAA
AAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAA
gAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAA
AICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAIDAAAAAAAAAAgAAAAICY
AAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAFzAAAAAAAAAAgAAAAICYAAAA
IDAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAFDAAAAAAAAAAgAAAAICYAAAAFDAA
AAAAAAAAgAAAAICYAAAAFDAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFDAAAAAA
AAAAgAAAAICYAAAAFDAAAAAAAAAAgAAAAICYAAAAFDAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFDAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFDAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAA
gAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFDAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFDAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFDAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAA
AAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFDAAAAAAAAAA
gAAAAICYAAAAFDAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAA
AICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICY
AAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAA
FTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAA
AAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAICYAAAAFTAAAAAAAAAAgAAAAIAIAAkgEDAAAAAA
AAAAgAAAAICQDAAAETAAAAAAAAAAgCMjAACQDAAAETAAAAAAAAAAgCMjAACQDAAAETAAAAAAAAAA
gCMjAACQDAAAETAAAAAAAAAAgCMjAACQDAAAETAAAAAAAAAAgCMjAACQDAAAETAAAAAAAAAAgCMj
AACQAA4gETAAAAAAAAAAgCMjAACQAA4gETABAAAAAAAAgCMjAACQAA4gETACAAAAAAAAgCMjAACQ
DAAAETAAAAAAAAAAgCMjAACQDAAAETAAAAAAAAAAgCMjAACQDAAAETAAAAAAAAAAgCMjAACQDAAA
ETAAAAAAAAAAgCMjAACQDAAAETAAAAAAAAAAgCMjAACQDAAAETAAAAAAAAAAgCMjAACQDAAAETAA
AAAAAAAAgCMjAACQDAAAETAAAAAAAAAAgCMjAACQDAAAETAAAAAAAAAAgCMjAAAIAAkgEDABAAAA
AAAAgAAAAIAIDAAAEDAAAAAAAAAAgAAAAICQDAAAETAAAAAAAAAAgN4nAACQAAYgETAAAAAAAAAA
gN4nAACQAAYgETABAAAAAAAAgN4nAACQAAYgETACAAAAAAAAgN4nAACQAAYgETADAAAAAAAAgN4n
AACQAAYgETAEAAAAAAAAgN4nAACQAAAAETAAAAAAAAAAgN4nAACQDAAAETAAAAAAAAAAgN4nAACQ
DAAAETAAAAAAAAAAgN4nAACQDAAAETAAAAAAAAAAgN4nAACQDAAAETAAAAAAAAAAgN4nAACQDAAA
ETAAAAAAAAAAgN4nAACQDAAAETAAAAAAAAAAgN4nAACYDAAAETAAAAAAAAAAgN4nAACYDAAAETAA
AAAAAAAAgN4nAAAIAAkgEDACAAAAAAAAgAAAAICQDAAAETAAAAAAAAAAgKsqAACQDAAAETAAAAAA
AAAAgKsqAACQDAAAETAAAAAAAAAAgKsqAACQDAAAETAAAAAAAAAAgKsqAAAQAQkgJjAAAAAAqyoA
AKsqAAAoAgkgJzAAAAAABywAAAcsAACQDAAAETAAAAAAAAAAgBIsAACQDAAAETAAAAAAAAAAgBIs
AAAoAgkgJzABAAAABywAAAcsAACQDAAAETAAAAAAAAAAgFUtAACQDAAAETAAAAAAAAAAgFUtAAAo
AgkgJzACAAAABywAAAcsAACQDAAAETAAAAAAAAAAgNMtAACQDAAAETAAAAAAAAAAgNMtAAAoAgkg
JzADAAAABywAAAcsAACQDAAAETAAAAAAAAAAgOouAACQDAAAETAAAAAAAAAAgOouAAAoAgkgJzAE
AAAABywAAAcsAACQDAAAETAAAAAAAAAAgBcwAACQDAAAETAAAAAAAAAAgBcwAACQDAAAETAAAAAA
AAAAgBcwAAAIAAkgEDADAAAAAAAAgAAAAIAIAAAAEDAAAAAAAAAAgAAAAIAIAAAAEDAAAAAAAAAA
gAAAAICQDAAAETAAAAAAAAAAgKIxAAAIAAkgEDAEAAAAAAAAgAAAAIAYAQkgJjAAAAAAuzEAALsx
AACQAAAAETAAAAAAAAAAgPkxAACQAAAAETAAAAAAAAAAgPkxAACQAAAAETAAAAAAAAAAgPkxAACQ
AAAAETAAAAAAAAAAgPkxAACQAAAAETAAAAAAAAAAgPkxAAAYAQkgJjABAAAAuzEAALsxAAAoAgkg
JzAAAAAA+DMAAPgzAACQAAAAETAAAAAAAAAAgBk0AACQAAAAETAAAAAAAAAAgBk0AAAoAgkgJzAB
AAAA+DMAAPgzAACQAAAAETAAAAAAAAAAgJQ0AACQAAAAETAAAAAAAAAAgJQ0AACQAAAAETAAAAAA
AAAAgJQ0AACQAAAAETAAAAAAAAAAgJQ0AAAoAgkgJzACAAAA+DMAAPgzAACQAAAAETAAAAAAAAAA
gEU1AACQAAAAETAAAAAAAAAAgEU1AAAoAgkgJzADAAAA+DMAAPgzAACQAAAAETAAAAAAAAAAgHo2
AACQAAAAETAAAAAAAAAAgHo2AAAoAgkgJzAEAAAA+DMAAPgzAACQAAAAETAAAAAAAAAAgJc3AACQ
AAAAETAAAAAAAAAAgJc3AAAoAgkgJzAFAAAA+DMAAPgzAACQAAAAETAAAAAAAAAAgCc4AACQAAAA
ETAAAAAAAAAAgCc4AAAoAgkgJzAGAAAA+DMAAPgzAACQAAAAETAAAAAAAAAAgK44AACQAAAAETAA
AAAAAAAAgK44AAAoAgkgJzAHAAAA+DMAAPgzAACQAAAAETAAAAAAAAAAgFo5AACQAAAAETAAAAAA
AAAAgFo5AAAYAQkgJjACAAAAuzEAALsxAAAoAgkgJzAAAAAAnTkAAJ05AACQAAAAETAAAAAAAAAA
gNc5AACQAAAAETAAAAAAAAAAgNc5AAAoAgkgJzABAAAAnTkAAJ05AACQAAAAETAAAAAAAAAAgPc6
AACQAAAAETAAAAAAAAAAgPc6AAAoAgkgJzACAAAAnTkAAJ05AACQAAAAETAAAAAAAAAAgKA7AACQ
AAAAETAAAAAAAAAAgKA7AAAoAgkgJzADAAAAnTkAAJ05AACQAAAAETAAAAAAAAAAgDk8AAAYAQkg
JjADAAAAuzEAALsxAACQAAAAETAAAAAAAAAAgFU8AAAYAQkgJjAEAAAAuzEAALsxAAAoAgkgJzAA
AAAAjzwAAI88AACQAAAAETAAAAAAAAAAgLM8AACQAAAAETAAAAAAAAAAgLM8AACQAAAAETAAAAAA
AAAAgLM8AACQAAAAETAAAAAAAAAAgLM8AAAQAQkgJjAFAAAAuzEAALsxAACQAAAAETAAAAAAAAAA
gM89AACQAAAAETAAAAAAAAAAgM89AACQAAAAETAAAAAAAAAAgM89AAAIAAkgEDAFAAAAAAAAgAAA
AIAYAQkgJjAAAAAAiD4AAIg+AACQAAAAETAAAAAAAAAAgMw+AACQAAAAETAAAAAAAAAAgMw+AAAo
AgkgJzAAAAAAzD4AAMw+AACQAAAAETAAAAAAAAAAgAdAAACQAAAAETAAAAAAAAAAgAdAAAAoAgkg
JzABAAAAzD4AAMw+AACQAAAAETAAAAAAAAAAgKxBAACQAAAAETAAAAAAAAAAgKxBAAAYAQkgJjAB
AAAAiD4AAIg+AAAoAgkgJzAAAAAAo0MAAKNDAACQAAAAETAAAAAAAAAAgMRDAAAoAgkgJzABAAAA
o0MAAKNDAACQAAAAETAAAAAAAAAAgCtEAACQAAAAETAAAAAAAAAAgCtEAAAoAgkgJzACAAAAo0MA
AKNDAACQAAAAETAAAAAAAAAAgG9FAACQAAAAETAAAAAAAAAAgG9FAAAoAgkgJzADAAAAo0MAAKND
AACQAAAAETAAAAAAAAAAgINGAAAoAgkgJzAEAAAAo0MAAKNDAACQAAAAETAAAAAAAAAAgEFHAAAo
AgkgJzAFAAAAo0MAAKNDAACQAAAAETAAAAAAAAAAgKVHAACQAAAAETAAAAAAAAAAgKVHAAAoAgkg
JzAGAAAAo0MAAKNDAACQAAAAETAAAAAAAAAAgJRIAACQAAAAETAAAAAAAAAAgJRIAAAoAgkgJzAH
AAAAo0MAAKNDAACQAAAAETAAAAAAAAAAgE9JAACQAAAAETAAAAAAAAAAgE9JAAAYAQkgJjACAAAA
iD4AAIg+AAAoAgkgJzAAAAAAUkoAAFJKAACQAAAAETAAAAAAAAAAgIxKAAAoAgkgJzABAAAAUkoA
AFJKAACQAAAAETAAAAAAAAAAgBRLAAAoAgkgJzACAAAAUkoAAFJKAACQAAAAETAAAAAAAAAAgIVL
AACQAAAAETAAAAAAAAAAgIVLAAAoAgkgJzADAAAAUkoAAFJKAACQAAAAETAAAAAAAAAAgEpMAAAY
AQkgJjADAAAAiD4AAIg+AACQAAAAETAAAAAAAAAAgK5MAAAYAQkgJjAEAAAAiD4AAIg+AAAoAgkg
JzAAAAAA6EwAAOhMAACQAAAAETAAAAAAAAAAgAxNAAAYAQkgJjAFAAAAiD4AAIg+AACQAAAAETAA
AAAAAAAAgI5NAAAoAgkgJzAAAAAAjk0AAI5NAACQAAAAETAAAAAAAAAAgN9NAAAoAgkgJzABAAAA
jk0AAI5NAACQAAAAETAAAAAAAAAAgHFOAAAoAgkgJzACAAAAjk0AAI5NAACQAAAAETAAAAAAAAAA
gARPAAAoAgkgJzADAAAAjk0AAI5NAACQAAAAETAAAAAAAAAAgCVQAAAoAgkgJzAEAAAAjk0AAI5N
AACQAAAAETAAAAAAAAAAgN9QAAAoAgkgJzAFAAAAjk0AAI5NAACQAAAAETAAAAAAAAAAgHdRAAAo
AgkgJzAGAAAAjk0AAI5NAACQAAAAETAAAAAAAAAAgEBSAAAoAgkgJzAHAAAAjk0AAI5NAACQAAAA
ETAAAAAAAAAAgPhSAAAoAgkgJzAIAAAAjk0AAI5NAACQAAAAETAAAAAAAAAAgLNTAACQAAAAETAA
AAAAAAAAgLNTAAAQAQkgJjAGAAAAiD4AAIg+AACQAAAAETAAAAAAAAAAgJ5UAACQAAAAETAAAAAA
AAAAgJ5UAACQAAAAETAAAAAAAAAAgJ5UAACQQAAAETAAAAAAAAAAgJ5UAACQAAAAETAAAAAAAAAA
gJ5UAACQAAAAETAAAAAAAAAAgJ5UAAAIAAkgEDAGAAAAAAAAgAAAAIAYAQkgJjAAAAAAolcAAKJX
AACYAAAAETAAAAAAAAAAgN5XAACYAAAAETAAAAAAAAAAgN5XAACYAAAAETAAAAAAAAAAgN5XAACY
AAAAETAAAAAAAAAAgN5XAACQAAAAETAAAAAAAAAAgN5XAAAYAQkgJjABAAAAolcAAKJXAAAoAgkg
JzAAAAAAtVkAALVZAACQAAAAETAAAAAAAAAAgNZZAAAoAgkgJzABAAAAtVkAALVZAACQAAAAETAA
AAAAAAAAgBZaAAAoAgkgJzACAAAAtVkAALVZAACQAAAAETAAAAAAAAAAgMpaAAAoAgkgJzADAAAA
tVkAALVZAACQAAAAETAAAAAAAAAAgBpbAAAoAgkgJzAEAAAAtVkAALVZAACQAAAAETAAAAAAAAAA
gJ5bAAAoAgkgJzAFAAAAtVkAALVZAACQAAAAETAAAAAAAAAAgO5bAAAoAgkgJzAGAAAAtVkAALVZ
AACQAAAAETAAAAAAAAAAgItcAAAoAgkgJzAHAAAAtVkAALVZAACQAAAAETAAAAAAAAAAgARdAAAY
AQkgJjACAAAAolcAAKJXAAAoAgkgJzAAAAAASl0AAEpdAACQAAAAETAAAAAAAAAAgIRdAAAoAgkg
JzABAAAASl0AAEpdAACQAAAAETAAAAAAAAAAgPtdAAAoAgkgJzACAAAASl0AAEpdAACQAAAAETAA
AAAAAAAAgENeAAAoAgkgJzADAAAASl0AAEpdAACQAAAAETAAAAAAAAAAgLdeAAAYAQkgJjADAAAA
olcAAKJXAACQAAAAETAAAAAAAAAAgB9fAAAYAQkgJjAEAAAAolcAAKJXAAAoAgkgJzAAAAAAWV8A
AFlfAACQAAAAETAAAAAAAAAAgH1fAAAQAQkgJjAFAAAAolcAAKJXAACQAAAAETAAAAAAAAAAgD5g
AACQAAAAETAAAAAAAAAAgD5gAACQAAAAETAAAAAAAAAAgD5gAACQAAAAETAAAAAAAAAAgD5gAACQ
AAAAETAAAAAAAAAAgD5gAAAIAAkgEDAHAAAAAAAAgAAAAIAYAQkgJjAAAAAAvWMAAL1jAACQAAAA
ETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAA
AAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAA
AAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAA
gAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdk
AACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQ
AAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAA
ETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAA
AAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAA
AAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAA
gAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdk
AACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQ
AAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAA
ETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAA
AAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAA
AAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAA
gAdkAACQAAAAETAAAAAAAAAAgAdkAACQAAAAETAAAAAAAAAAgAdkAAAYAQkgJjABAAAAvWMAAL1j
AAAoAgkgJzAAAAAAdW4AAHVuAACQAAAAETAAAAAAAAAAgJZuAACQAAAAETAAAAAAAAAAgJZuAAAo
AgkgJzABAAAAdW4AAHVuAACQAAAAETAAAAAAAAAAgPFvAACQAAAAETAAAAAAAAAAgPFvAACQAAAA
ETAAAAAAAAAAgPFvAACQAAAAETAAAAAAAAAAgPFvAACQAAAAETAAAAAAAAAAgPFvAACQAAAAETAA
AAAAAAAAgPFvAACQAAAAETAAAAAAAAAAgPFvAACQAAAAETAAAAAAAAAAgPFvAACQAAAAETAAAAAA
AAAAgPFvAAAoAgkgJzACAAAAdW4AAHVuAACQAAAAETAAAAAAAAAAgIByAACQAAAAETAAAAAAAAAA
gIByAACQAAAAETAAAAAAAAAAgIByAACQAAAAETAAAAAAAAAAgIByAACQAAAAETAAAAAAAAAAgIBy
AACQAAAAETAAAAAAAAAAgIByAAAoAgkgJzADAAAAdW4AAHVuAACQAAAAETAAAAAAAAAAgEF1AACQ
AAAAETAAAAAAAAAAgEF1AACQAAAAETAAAAAAAAAAgEF1AACQAAAAETAAAAAAAAAAgEF1AACQAAAA
ETAAAAAAAAAAgEF1AACQAAAAETAAAAAAAAAAgEF1AACQAAAAETAAAAAAAAAAgEF1AACQAAAAETAA
AAAAAAAAgEF1AACQAAAAETAAAAAAAAAAgEF1AACQAAAAETAAAAAAAAAAgEF1AACQAAAAETAAAAAA
AAAAgEF1AACQAAAAETAAAAAAAAAAgEF1AACQAAAAETAAAAAAAAAAgEF1AACQAAAAETAAAAAAAAAA
gEF1AACQAAAAETAAAAAAAAAAgEF1AAAoAgkgJzAEAAAAdW4AAHVuAACQAAAAETAAAAAAAAAAgNt4
AACQAAAAETAAAAAAAAAAgNt4AACQAAAAETAAAAAAAAAAgNt4AACQAAAAETAAAAAAAAAAgNt4AACQ
AAAAETAAAAAAAAAAgNt4AACQAAAAETAAAAAAAAAAgNt4AAAoAgkgJzAFAAAAdW4AAHVuAACQAAAA
ETAAAAAAAAAAgLF6AACQAAAAETAAAAAAAAAAgLF6AACQAAAAETAAAAAAAAAAgLF6AACQAAAAETAA
AAAAAAAAgLF6AAAoAgkgJzAGAAAAdW4AAHVuAACQAAAAETAAAAAAAAAAgFF9AAAoAgkgJzAHAAAA
dW4AAHVuAACQAAAAETAAAAAAAAAAgMl9AACQAAAAETAAAAAAAAAAgMl9AAAYAQkgJjACAAAAvWMA
AL1jAAAoAgkgJzAAAAAAg34AAIN+AACQAAAAETAAAAAAAAAAgL1+AAAoAgkgJzABAAAAg34AAIN+
AACQAAAAETAAAAAAAAAAgDqAAAAoAgkgJzACAAAAg34AAIN+AACQAAAAETAAAAAAAAAAgFuAAAAo
AgkgJzADAAAAg34AAIN+AACQAAAAETAAAAAAAAAAgISAAAAYAQkgJjADAAAAvWMAAL1jAACQAAAA
ETAAAAAAAAAAgG2BAACQAAAAETAAAAAAAAAAgG2BAACQAAAAETAAAAAAAAAAgG2BAACQAAAAETAA
AAAAAAAAgG2BAACQAAAAETAAAAAAAAAAgG2BAACQAAAAETAAAAAAAAAAgG2BAACQAAAAETAAAAAA
AAAAgG2BAACQAAAAETAAAAAAAAAAgG2BAACQAAAAETAAAAAAAAAAgG2BAAAYAQkgJjAEAAAAvWMA
AL1jAAAoAgkgJzAAAAAAk4YAAJOGAACQAAAAETAAAAAAAAAAgLeGAACQAAAAETAAAAAAAAAAgLeG
AACQAAAAETAAAAAAAAAAgLeGAACQAAAAETAAAAAAAAAAgLeGAACQAAAAETAAAAAAAAAAgLeGAAAQ
AQkgJjAFAAAAvWMAAL1jAACQAAAAETAAAAAAAAAAgMKIAACQAAAAETAAAAAAAAAAgMKIAACQAAAA
ETAAAAAAAAAAgMKIAAAIAAkgEDAIAAAAAAAAgAAAAIAYAQkgJjAAAAAAe4kAAHuJAAAoAgkgJzAA
AAAAvokAAL6JAACYAAAAETAAAAAAAAAAgMeJAACYAAAAETAAAAAAAAAAgMeJAACYAAAAETAAAAAA
AAAAgMeJAACYAAAAETAAAAAAAAAAgMeJAACYAAAAETAAAAAAAAAAgMeJAACYAAAAETAAAAAAAAAA
gMeJAAAoAgkgJzABAAAAvokAAL6JAACYAAAAETAAAAAAAAAAgMuPAACYAAAAETAAAAAAAAAAgMuP
AACYAAAAETAAAAAAAAAAgMuPAACYAAAAETAAAAAAAAAAgMuPAACYAAAAETAAAAAAAAAAgMuPAACQ
AAAAETAAAAAAAAAAgMuPAAAYAQkgJjABAAAAe4kAAHuJAAAoAgkgJzAAAAAApZMAAKWTAACQAAAA
ETAAAAAAAAAAgMKTAAAoAgkgJzABAAAApZMAAKWTAACYAAAAETAAAAAAAAAAgE6UAACYAAAAETAA
AAAAAAAAgE6UAACYAA0gETAAAAAAAAAAgE6UAACYAA0gETABAAAAAAAAgE6UAACYAA0gETACAAAA
AAAAgE6UAACYAA0gETADAAAAAAAAgE6UAACQAAAAETAAAAAAAAAAgE6UAAAoAgkgJzACAAAApZMA
AKWTAACQAAAAETAAAAAAAAAAgGuXAAAoAgkgJzADAAAApZMAAKWTAACQAAAAETAAAAAAAAAAgIuX
AAAoAgkgJzAEAAAApZMAAKWTAACQAAAAETAAAAAAAAAAgKWXAAAoAgkgJzAFAAAApZMAAKWTAACQ
AAAAETAAAAAAAAAAgNOXAAAoAgkgJzAGAAAApZMAAKWTAACQAAAAETAAAAAAAAAAgAGYAAAoAgkg
JzAHAAAApZMAAKWTAACQAAAAETAAAAAAAAAAgA+aAAAoAgkgJzAIAAAApZMAAKWTAACQAAAAETAA
AAAAAAAAgCGcAAAoAgkgJzAJAAAApZMAAKWTAACQAAAAETAAAAAAAAAAgLudAAAYAQkgJjACAAAA
e4kAAHuJAAAoAgkgJzAAAAAA754AAO+eAACQAAAAETAAAAAAAAAAgAyfAAAoAgkgJzABAAAA754A
AO+eAACQAAAAETAAAAAAAAAAgBigAAAoAgkgJzACAAAA754AAO+eAACQAAAAETAAAAAAAAAAgDei
AAAoAgkgJzADAAAA754AAO+eAACQAAAAETAAAAAAAAAAgEukAAAoAgkgJzAEAAAA754AAO+eAACQ
AAAAETAAAAAAAAAAgIekAAAoAgkgJzAFAAAA754AAO+eAACQAAAAETAAAAAAAAAAgKOkAAAoAgkg
JzAGAAAA754AAO+eAACQAAAAETAAAAAAAAAAgCSlAAAYAQkgJjADAAAAe4kAAHuJAAAoAgkgJzAA
AAAAOKYAADimAACQAAAAETAAAAAAAAAAgHmmAAAoAgkgJzABAAAAOKYAADimAACQAAAAETAAAAAA
AAAAgKGmAAAoAgkgJzACAAAAOKYAADimAACQAAAAETAAAAAAAAAAgM6mAAAoAgkgJzADAAAAOKYA
ADimAACQAAAAETAAAAAAAAAAgAOnAAAoAgkgJzAEAAAAOKYAADimAACQAAAAETAAAAAAAAAAgCin
AACQAAAAETAAAAAAAAAAgCinAAAIAAkgEDAJAAAAAAAAgAAAAIAYAQkgJjAAAAAAX6cAAF+nAACY
AAAAETAAAAAAAAAAgJynAACYAAAAETAAAAAAAAAAgJynAACQAAAAETAAAAAAAAAAgJynAAAYAQkg
JjABAAAAX6cAAF+nAAAoAgkgJzAAAAAAM6oAADOqAACQAAAAETAAAAAAAAAAgFCqAAAoAgkgJzAB
AAAAM6oAADOqAACQAAAAETAAAAAAAAAAgLKqAAAoAgkgJzACAAAAM6oAADOqAACQAAAAETAAAAAA
AAAAgPGqAAAgAgkgJzADAAAAM6oAADOqAACQAAAAETAAAAAAAAAAgEKrAAAoAgkgJzAEAAAAM6oA
ADOqAACQAAAAETAAAAAAAAAAgG2rAAAoAgkgJzAFAAAAM6oAADOqAACQAAAAETAAAAAAAAAAgL6r
AAAoAgkgJzAGAAAAM6oAADOqAACQAAAAETAAAAAAAAAAgP+rAAAoAgkgJzAHAAAAM6oAADOqAACQ
AAAAETAAAAAAAAAAgFKsAAAoAgkgJzAIAAAAM6oAADOqAACQAAAAETAAAAAAAAAAgKmsAAAoAgkg
JzAJAAAAM6oAADOqAACQAAAAETAAAAAAAAAAgPysAAAYAQkgJjACAAAAX6cAAF+nAAAoAgkgJzAA
AAAA2a0AANmtAACQAAAAETAAAAAAAAAAgPatAAAoAgkgJzABAAAA2a0AANmtAACQAAAAETAAAAAA
AAAAgKGuAAAoAgkgJzACAAAA2a0AANmtAACQAAAAETAAAAAAAAAAgNauAAAoAgkgJzADAAAA2a0A
ANmtAACQAAAAETAAAAAAAAAAgB+vAAAoAgkgJzAEAAAA2a0AANmtAACQAAAAETAAAAAAAAAAgG6v
AAAoAgkgJzAFAAAA2a0AANmtAACQAAAAETAAAAAAAAAAgI2vAAAoAgkgJzAGAAAA2a0AANmtAACQ
AAAAETAAAAAAAAAAgOCvAAAYAQkgJjADAAAAX6cAAF+nAAAoAgkgJzAAAAAANrAAADawAACQAAAA
ETAAAAAAAAAAgHewAAAoAgkgJzABAAAANrAAADawAACQAAAAETAAAAAAAAAAgJ+wAAAoAgkgJzAC
AAAANrAAADawAACQAAAAETAAAAAAAAAAgMywAAAoAgkgJzADAAAANrAAADawAACQAAAAETAAAAAA
AAAAgAGxAAAoAgkgJzAEAAAANrAAADawAACYAAAAETAAAAAAAAAAgCaxAACQAAAAETAAAAAAAAAA
gCaxAACQDAAAETAAAAAAAAAAgCaxAAAIAAkgEDAKAAAAAAAAgAAAAICQDAAAETAAAAAAAAAAgGKx
AACQDAAAETAAAAAAAAAAgGKxAACQDAAAETAAAAAAAAAAgGKxAAAIAAkgEDALAAAAAAAAgAAAAICQ
AAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAA
ETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAA
AAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAA
AAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAA
gCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmy
AACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQ
AAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAA
ETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAA
AAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAA
AAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAJTAAAAAAAAAA
gCmyAACQAAAAFzAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmy
AACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQ
AAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAA
ETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAA
AAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAA
AAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAA
gCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmy
AACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAFzAAAAAAAAAAgCmyAACQ
AAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAAETAAAAAAAAAAgCmyAACQAAAA
ETAAAAAAAAAAgCmyAACYAAAAETAAAAAAAAAAgCmyAACYAAAAETAAAAAAAAAAgCmyAAAYAQkgJjAA
AAAAKbIAACmyAAAoAgkgJzAAAAAAAb4AAAG+AACQAAAAETAAAAAAAAAAgB6+AACQAAAAETAAAAAA
AAAAgB6+AAAoAgkgJzABAAAAAb4AAAG+AACQAAAAETAAAAAAAAAAgBO/AACQAAAAETAAAAAAAAAA
gBO/AAAoAgkgJzACAAAAAb4AAAG+AACQAAAAETAAAAAAAAAAgAfAAACQAAAAETAAAAAAAAAAgAfA
AAAoAgkgJzADAAAAAb4AAAG+AACQAAAAETAAAAAAAAAAgDHAAACQAAAAETAAAAAAAAAAgDHAAAAo
AgkgJzAEAAAAAb4AAAG+AACQAAAAETAAAAAAAAAAgFXAAACQAAAAETAAAAAAAAAAgFXAAAAoAgkg
JzAFAAAAAb4AAAG+AACQAAAAETAAAAAAAAAAgIzAAACQAAAAETAAAAAAAAAAgIzAAAAoAgkgJzAG
AAAAAb4AAAG+AACQAAAAETAAAAAAAAAAgDTBAACQAAAAETAAAAAAAAAAgDTBAAAoAgkgJzAHAAAA
Ab4AAAG+AACQAAAAETAAAAAAAAAAgLXCAACQAAAAETAAAAAAAAAAgLXCAAAoAgkgJzAIAAAAAb4A
AAG+AACQAAAAETAAAAAAAAAAgCPDAACQAAAAETAAAAAAAAAAgCPDAAAoAgkgJzAJAAAAAb4AAAG+
AACQAAAAETAAAAAAAAAAgI/DAACQAAAAETAAAAAAAAAAgI/DAACQAAAAETAAAAAAAAAAgI/DAAAY
AQkgJjABAAAAKbIAACmyAAAoAgkgJzAAAAAAXsQAAF7EAACQAAAAETAAAAAAAAAAgHvEAACQAAAA
ETAAAAAAAAAAgHvEAAAoAgkgJzABAAAAXsQAAF7EAACQAAAAETAAAAAAAAAAgGrFAACQAAAAETAA
AAAAAAAAgGrFAAAoAgkgJzACAAAAXsQAAF7EAACQAAAAETAAAAAAAAAAgI7FAACQAAAAETAAAAAA
AAAAgI7FAAAoAgkgJzADAAAAXsQAAF7EAACQAAAAETAAAAAAAAAAgMbFAACQAAAAETAAAAAAAAAA
gMbFAAAoAgkgJzAEAAAAXsQAAF7EAACQAAAAETAAAAAAAAAAgBDGAACQAAAAETAAAAAAAAAAgBDG
AAAoAgkgJzAFAAAAXsQAAF7EAACQAAAAETAAAAAAAAAAgDTHAACQAAAAETAAAAAAAAAAgDTHAAAo
AgkgJzAGAAAAXsQAAF7EAACQAAAAETAAAAAAAAAAgK3HAACQAAAAETAAAAAAAAAAgK3HAAAYAQkg
JjACAAAAKbIAACmyAAAoAgkgJzAAAAAALcgAAC3IAACQAAAAETAAAAAAAAAAgG7IAACQAAAAETAA
AAAAAAAAgG7IAAAoAgkgJzABAAAALcgAAC3IAACQAAAAETAAAAAAAAAAgErJAACQAAAAETAAAAAA
AAAAgErJAACQAAAAETAAAAAAAAAAgErJAAAoAgkgJzACAAAALcgAAC3IAACQAAAAETAAAAAAAAAA
gP3JAACQAAAAETAAAAAAAAAAgP3JAAAoAgkgJzADAAAALcgAAC3IAACQAAAAETAAAAAAAAAAgLTK
AACQAAAAETAAAAAAAAAAgLTKAAAoAgkgJzAEAAAALcgAAC3IAACQAAAAETAAAAAAAAAAgDTLAACQ
AAAAETAAAAAAAAAAgDTLAACYAAAAETAAAAAAAAAAgDTLAACYAAAAETAAAAAAAAAAgDTLAACYAAAA
ETAAAAAAAAAAgDTLAAAYAQkgJjADAAAAKbIAACmyAAAoAgkgJzAAAAAAnMsAAJzLAACQAAAAETAA
AAAAAAAAgLnLAAAoAgkgJzABAAAAnMsAAJzLAACQAAAAETAAAAAAAAAAgI/MAAAoAgkgJzACAAAA
nMsAAJzLAACQAAAAETAAAAAAAAAAgBbNAAAoAgkgJzADAAAAnMsAAJzLAACQAAAAETAAAAAAAAAA
gD3NAAAoAgkgJzAEAAAAnMsAAJzLAACQAAAAETAAAAAAAAAAgF7NAAAoAgkgJzAFAAAAnMsAAJzL
AACQAAAAETAAAAAAAAAAgJLNAAAoAgkgJzAGAAAAnMsAAJzLAACQAAAAETAAAAAAAAAAgMfNAAAo
AgkgJzAHAAAAnMsAAJzLAACQAAAAETAAAAAAAAAAgHfOAAAoAgkgJzAIAAAAnMsAAJzLAACQAAAA
ETAAAAAAAAAAgKTOAAAoAgkgJzAJAAAAnMsAAJzLAACQAAAAETAAAAAAAAAAgFrPAACQDAAAETAA
AAAAAAAAgFrPAAAYAQkgJjAEAAAAKbIAACmyAAAoAgkgJzAAAAAAxs8AAMbPAACQAAAAETAAAAAA
AAAAgOPPAAAoAgkgJzABAAAAxs8AAMbPAACQAAAAETAAAAAAAAAAgMvQAAAoAgkgJzACAAAAxs8A
AMbPAACQDAAAETAAAAAAAAAAgPjQAACQAAAAETAAAAAAAAAAgPjQAAAoAgkgJzADAAAAxs8AAMbP
AACQAAAAETAAAAAAAAAAgK3RAAAoAgkgJzAEAAAAxs8AAMbPAACQAAAAETAAAAAAAAAAgPDRAAAo
AgkgJzAFAAAAxs8AAMbPAACQAAAAETAAAAAAAAAAgAzSAAAoAgkgJzAGAAAAxs8AAMbPAACQAAAA
ETAAAAAAAAAAgMLSAACQDAAAETAAAAAAAAAAgMLSAAAYAQkgJjAFAAAAKbIAACmyAAAoAgkgJzAA
AAAANdMAADXTAACQAAAAETAAAAAAAAAAgHbTAAAoAgkgJzABAAAANdMAADXTAACQAAAAETAAAAAA
AAAAgE/UAAAoAgkgJzACAAAANdMAADXTAACQAAAAETAAAAAAAAAAgIDUAAAoAgkgJzADAAAANdMA
ADXTAACQAAAAETAAAAAAAAAAgKjUAAAoAgkgJzAEAAAANdMAADXTAACYAAAAETAAAAAAAAAAgBnV
AACYAAAAETAAAAAAAAAAgBnVAACYAAAAETAAAAAAAAAAgBnVAACYAAAAETAAAAAAAAAAgBnVAAAY
AQkgJjAGAAAAKbIAACmyAAAoAgkgJzAAAAAAztUAAM7VAACQAAAAETAAAAAAAAAAgOvVAACQAAAA
ETAAAAAAAAAAgOvVAACQAAAAETAAAAAAAAAAgOvVAAAoAgkgJzABAAAAztUAAM7VAACQAAAAETAA
AAAAAAAAgG/XAAAoAgkgJzACAAAAztUAAM7VAACQAAAAETAAAAAAAAAAgMvXAAAoAgkgJzADAAAA
ztUAAM7VAACQAAAAETAAAAAAAAAAgCfYAAAoAgkgJzAEAAAAztUAAM7VAACQAAAAETAAAAAAAAAA
gGrZAAAoAgkgJzAFAAAAtNYAALTWAACQAAAAETAAAAAAAAAAgI7ZAACQAAAAETAAAAAAAAAAgI7Z
AAAoAgkgJzAGAAAAtNYAALTWAACQAAAAETAAAAAAAAAAgEXaAAAoAgkgJzAHAAAAtNYAALTWAACQ
AAAAETAAAAAAAAAAgODaAACQAAAAETAAAAAAAAAAgODaAACQAAAAETAAAAAAAAAAgODaAAAoAgkg
JzAIAAAAtNYAALTWAACQAAAAETAAAAAAAAAAgOHbAACQAAAAETAAAAAAAAAAgOHbAAAoAgkgJzAJ
AAAAtNYAALTWAACQAAAAETAAAAAAAAAAgLrZAACQAAAAETAAAAAAAAAAgLrZAAAYAQkgJjAHAAAA
KbIAACmyAAAoAgkgJzAAAAAAjNoAAIzaAACQAAAAETAAAAAAAAAAgKnaAACQAAAAETAAAAAAAAAA
gKnaAACQAAAAETAAAAAAAAAAgKnaAACQAAAAETAAAAAAAAAAgKnaAACQAAAAETAAAAAAAAAAgKna
AAAoAgkgJzABAAAAjNoAAIzaAACQAAAAETAAAAAAAAAAgN7cAAAoAgkgJzACAAAAjNoAAIzaAACQ
AAAAETAAAAAAAAAAgFPdAAAoAgkgJzADAAAAjNoAAIzaAACQAAAAETAAAAAAAAAAgFPeAAAoAgkg
JzAEAAAAjNoAAIzaAACQAAAAETAAAAAAAAAAgBbfAAAoAgkgJzAFAAAAjNoAAIzaAACQAAAAETAA
AAAAAAAAgBLgAAAoAgkgJzAGAAAAjNoAAIzaAACQAAAAETAAAAAAAAAAgK3gAACQAAAAETAAAAAA
AAAAgK3gAACQAAAAETAAAAAAAAAAgK3gAAAYAQkgJjAIAAAAKbIAACmyAAAoAgkgJzAAAAAAreIA
AK3iAACQAAAAETAAAAAAAAAAgO7iAACQAAAAETAAAAAAAAAAgO7iAACQAAAAETAAAAAAAAAAgO7i
AACQAAAAETAAAAAAAAAAgO7iAACQAAAAETAAAAAAAAAAgO7iAAAoAgkgJzABAAAAreIAAK3iAACQ
AAAAETAAAAAAAAAAgBzlAAAoAgkgJzACAAAAreIAAK3iAACQAAAAETAAAAAAAAAAgGTlAAAoAgkg
JzADAAAAreIAAK3iAACQAAAAETAAAAAAAAAAgHzmAACQAAAAETAAAAAAAAAAgHzmAACQAAAAETAA
AAAAAAAAgHzmAAAoAgkgJzAEAAAAreIAAK3iAACYAAAAETAAAAAAAAAAgILoAACYAAAAETAAAAAA
AAAAgILoAAAYAQkgJjAJAAAAKbIAACmyAAAoAgkgJzAAAAAANOkAADTpAACQAAAAETAAAAAAAAAA
gFXpAAAoAgkgJzABAAAANOkAADTpAACQAAAAETAAAAAAAAAAgAnqAAAoAgkgJzACAAAANOkAADTp
AACQAAAAETAAAAAAAAAAgKPqAAAoAgkgJzADAAAANOkAADTpAACQAAAAETAAAAAAAAAAgF3rAAAo
AgkgJzAEAAAANOkAADTpAACQAAAAETAAAAAAAAAAgCTsAAAoAgkgJzAFAAAANOkAADTpAACQAAAA
ETAAAAAAAAAAgE3sAAAoAgkgJzAGAAAANOkAADTpAACQAAAAETAAAAAAAAAAgFztAAAoAgkgJzAH
AAAANOkAADTpAACQAAAAETAAAAAAAAAAgAnuAACYAAAAETAAAAAAAAAAgAnuAACYAAAAETAAAAAA
AAAAgAnuAAAYAQkgJjAKAAAAKbIAACmyAAAoAgkgJzAAAAAAkO8AAJDvAAAoAgkgJzABAAAAkO8A
AJDvAACQAAAAETAAAAAAAAAAgPzvAACQAAAAETAAAAAAAAAAgPzvAAAoAgkgJzACAAAAkO8AAJDv
AACQAAAAETAAAAAAAAAAgNXwAAAoAgkgJzADAAAAkO8AAJDvAACQAAAAETAAAAAAAAAAgB3xAAAY
AQkgJjALAAAAKbIAACmyAACQAAAAETAAAAAAAAAAgLrxAAAYAQkgJjAMAAAAKbIAACmyAAAoAgkg
JzAAAAAAufIAALnyAACQAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICaQAAAEjAA
AAAAAAAAgAAAAICYQAAAEjAAAAAAAAAAgAAAAICYQAAAEjAAAAAAAAAAgAAAAICaQAAAADAAAAAA
AAAAgAAAAICYQAAAEzAAAAAAAAAAgAAAAICYQAAAEzAAAAAAAAAAgAAAAICaQAAAEzAAAAAAAAAA
gAAAAIAKAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGEA
AABhAAAAkQAAAJEAAAC4AAAAuwAAAAAEAABHDgAALQ8AADwQAAAREQAAMxIAABMTAAAKFAAALBUA
AAkWAAD+FgAAARgAAAgZAAADGgAAABsAAAccAAAEHQAA2R0AAP0eAADDHwAAziAAALkhAADJIgAA
2iMAAMQkAADVJQAAHCcAAPSbAADp+QAAfgAAAIMAAACEAAAAhQAAAIYAAACHAAAAiAAAAIkAAACK
AAAAiwAAAIwAAACNAAAAjwAAAJAAAACRAAAAkgAAAJMAAACUAAAAlQAAAJYAAACXAAAAmAAAAJkA
AACaAAAAnAAAAJ0AAACeAAAArgAAAAAEAACyBQAAzw0AAKIXAAB0IwAALisAABIwAACjNwAA1z0A
ACFEAAC+TgAA+FYAAJ5fAAC9ZwAAzG0AAJV0AADTfAAAo4UAADCSAAAXnAAAA6sAAMKwAABctQAA
crsAAGLAAAB1xAAA9MkAAJDPAADV1AAAztkAAIbgAABB6wAAp/UAAOn5AAB/AAAAgQAAAIIAAACO
AAAAmwAAAJ8AAACgAAAAoQAAAKIAAACjAAAApAAAAKUAAACmAAAApwAAAKgAAACpAAAAqgAAAKsA
AACsAAAArQAAAK8AAACwAAAAsQAAALIAAACzAAAAtAAAALUAAAC2AAAAtwAAALgAAAC5AAAAugAA
ALsAAAAABAAA6PkAAIAAAABeAAAAdAAAAIsAAAC0AAAAvwAAAOQJAAD5CQAA+gkAABkKAAAmCgAA
QQoAAEMKAABECgAARgoAAGUKAAB8CgAAlwoAAJkKAACaCgAAnAoAALsKAADdCgAA+AoAAPoKAAD7
CgAA/QoAABwLAAAtCwAASAsAAEoLAABLCwAATQsAAGwLAACrCwAAxgsAAMgLAADJCwAAywsAAOoL
AAD+CwAAGQwAABsMAAAcDAAAHgwAAD0MAAB/DAAAmgwAAJwMAACdDAAAnwwAAL4MAADTDAAA7gwA
APAMAADxDAAA8wwAABINAAA5DQAAVA0AAFYNAABXDQAAWQ0AAHgNAAC4DQAA0w0AANUNAADWDQAA
2A0AAPcNAAAzDgAATg4AAFAOAABRDgAAUw4AAHIOAACcDgAAtw4AALkOAAC6DgAAvA4AANsOAADz
DgAADg8AABAPAAARDwAAEw8AADIPAAB6DwAAlQ8AAJcPAACYDwAAmg8AALkPAADMDwAA5w8AAOkP
AADqDwAA7A8AAAsQAAAyEAAATRAAAE8QAABQEAAAUhAAAHEQAACxEAAAzBAAAM4QAADPEAAA0RAA
APAQAAAsEQAARxEAAEkRAABKEQAATBEAAGsRAACVEQAAsBEAALIRAACzEQAAtREAANQRAADpEQAA
BBIAAAYSAAAHEgAACRIAACgSAABAEgAAWxIAAF0SAABeEgAAYBIAAH8SAAC/EgAA2hIAAN0SAADe
EgAA4BIAAP8SAAAaEwAANRMAADgTAAA5EwAAOxMAAFoTAACBEwAAnBMAAJ8TAACgEwAAohMAAMET
AAABFAAAHBQAAB8UAAAgFAAAIhQAAEEUAAB9FAAAmBQAAJsUAACcFAAAnhQAAL0UAADnFAAAAhUA
AAUVAAAGFQAACBUAACcVAAA/FQAAWhUAAF0VAABeFQAAYBUAAH8VAADEFQAA3xUAAOIVAADjFQAA
5RUAAAQWAAAZFgAANBYAADcWAAA4FgAAOhYAAFkWAACAFgAAmxYAAJ4WAACfFgAAoRYAAMAWAAAA
FwAAGxcAAB4XAAAfFwAAIRcAAEAXAAB8FwAAlxcAAJoXAACbFwAAnRcAALwXAADmFwAAARgAAAQY
AAAFGAAABxgAACYYAAA+GAAAWRgAAFwYAABdGAAAXxgAAH4YAADFGAAA4BgAAOMYAADkGAAA5hgA
AAUZAAATGQAALhkAADEZAAAyGQAANBkAAFMZAAB2GQAAkRkAAJQZAACVGQAAlxkAALYZAADZGQAA
9BkAAPcZAAD4GQAA+hkAABkaAABgGgAAexoAAH4aAAB/GgAAgRoAAKAaAADiGgAA/RoAAAAbAAAB
GwAAAxsAACIbAAA+GwAAWRsAAFwbAABdGwAAXxsAAH4bAACiGwAAvRsAAMAbAADBGwAAwxsAAOIb
AAAGHAAAIRwAACQcAAAlHAAAJxwAAEYcAACOHAAAqRwAAKwcAACtHAAArxwAAM4cAADrHAAABh0A
AAkdAAAKHQAADB0AACsdAAA7HQAAVh0AAFkdAABaHQAAXB0AAHsdAACfHQAAuh0AAL0dAAC+HQAA
wB0AAN8dAAADHgAAHh4AACEeAAAiHgAAJB4AAEMeAACLHgAAph4AAKkeAACqHgAArB4AAMseAADv
HgAACh8AAA0fAAAOHwAAEB8AAC8fAABTHwAAbh8AAHEfAAByHwAAdB8AAJMfAADbHwAA9h8AAPkf
AAD6HwAA/B8AABsgAAA/IAAAWiAAAF0gAABeIAAAYCAAAH8gAACjIAAAviAAAMEgAADCIAAAxCAA
AOMgAAArIQAARiEAAEkhAABKIQAATCEAAGshAACUIQAAryEAALIhAACzIQAAtSEAANQhAAAWIgAA
MSIAADQiAAA1IgAANyIAAFYiAACUIgAAryIAALIiAACzIgAAtSIAANQiAAAAIwAAGyMAAB4jAAAf
IwAAISMAAOn1AAATJpUAExaU/5WAEw10/xNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/
lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8T
JXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNY
lP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCV
zBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/
lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8T
JXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNY
lP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCV
zBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/
lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8T
JXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNY
lP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCV
zBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/lcCVzBNYlP8TJXT/
lcCVzJWMKAAAAFEAAABcAAAAgwAAAIoAAACNAAAAuwAAABMWlP+VgBMhlP+VgP//SgAAAA0AXwBU
AG8AYwA1ADMANQA3ADQAMgA4ADUANAANAF8AVABvAGMANQAzADUANwA0ADIAOAA1ADUADQBfAFQA
bwBjADUAMwA1ADcANAAyADgANQA2AA0AXwBUAG8AYwA1ADMANQA3ADQAMgA4ADUANwAMAF8ASABs
AHQAMwA0ADYANgA3ADQANgA5AAwAXwBIAGwAdAAzADQANgA2ADYANwAxADEADABfAEgAbAB0ADMA
NAA2ADYANgA4ADUAMAAMAF8AVABvAGMAMwA0ADYANgA2ADYANQAxAAwAXwBIAGwAdAAyADMANQAy
ADAAOAA5ADQADABfAFQAbwBjADMANAA2ADYANgA2ADUAMgAMAF8AVABvAGMAMwA0ADYANgA2ADYA
NQAzAAwAXwBUAG8AYwAzADQANgA2ADYANgA1ADQADABfAFQAbwBjADMANAA2ADYANgA2ADUANQAM
AF8AVABvAGMAMwA0ADYANgA2ADYANQA2AAwAXwBUAG8AYwAzADQANgA2ADYANgA1ADcADABfAFQA
bwBjADMANAA2ADYANgA2ADUAOAAMAF8AVABvAGMAMwA0ADYANgA2ADYANQA5AAwAXwBUAG8AYwAz
ADQANgA2ADYANgA2ADAADABfAFQAbwBjADMANAA2ADYANgA2ADYAMQAMAF8AVABvAGMAMwA0ADYA
NgA2ADYANgAyAAwAXwBUAG8AYwAzADQANgA2ADYANgA2ADMADABfAFQAbwBjADMANAA2ADYANgA2
ADYANAAMAF8AVABvAGMAMwA0ADYANgA2ADYANgA1AAwAXwBUAG8AYwAzADQANgA2ADYANgA2ADYA
DABfAFQAbwBjADMANAA2ADYANgA2ADYANwAMAF8AVABvAGMAMwA0ADYANgA2ADYANgA4AAwAXwBU
AG8AYwAzADQANgA2ADYANgA2ADkADABfAFQAbwBjADMANAA2ADYANgA2ADcAMAAMAF8AVABvAGMA
MwA0ADYANgA2ADYANwAxAAwAXwBUAG8AYwAzADQANgA2ADYANgA3ADIADABfAFQAbwBjADMANAA2
ADYANgA2ADcAMwAMAF8AVABvAGMAMwA0ADYANgA2ADYANwA0AAwAXwBUAG8AYwAzADQANgA2ADYA
NgA3ADUADABfAFQAbwBjADMANAA2ADYANgA2ADcANgAMAF8AVABvAGMAMwA0ADYANgA2ADYANwA3
AAwAXwBUAG8AYwAzADQANgA2ADYANgA3ADgADABfAFQAbwBjADMANAA2ADYANgA2ADcAOQAMAF8A
VABvAGMAMwA0ADYANgA2ADYAOAAwAAwAXwBUAG8AYwAzADQANgA2ADYANgA4ADEADABfAFQAbwBj
ADMANAA2ADYANgA2ADgAMgAMAF8AVABvAGMAMwA0ADYANgA2ADYAOAAzAAwAXwBUAG8AYwAzADQA
NgA2ADYANgA4ADQADABfAFQAbwBjADMANAA2ADYANgA2ADgANQAMAF8AVABvAGMAMwA0ADYANgA2
ADYAOAA2AAwAXwBUAG8AYwAzADQANgA2ADYANgA4ADcADABfAFQAbwBjADIAMwA0ADgAOAA5ADUA
OAAMAF8AVABvAGMAMgAzADQAOAA4ADkANQA5AAwAXwBUAG8AYwAzADQANgA2ADYANgA4ADgADABf
AFQAbwBjADMANAA2ADYANgA2ADgAOQAMAF8AVABvAGMAMwA0ADYANgA2ADYAOQAwAAwAXwBUAG8A
YwAzADQANgA2ADYANgA5ADEADABfAFQAbwBjADMANAA2ADYANgA2ADkAMgAMAF8AVABvAGMAMwA0
ADYANgA2ADYAOQAzAAwAXwBUAG8AYwAzADQANgA2ADYANgA5ADQADABfAFQAbwBjADMANAA2ADYA
NgA2ADkANQANAF8AVABvAGMANQAzADUANwA0ADIAOAA2ADYADABfAFQAbwBjADMANAA2ADYANgA2
ADkANgANAF8AVABvAGMANQAzADUANwA0ADIAOAA2ADcADABfAFQAbwBjADMANAA2ADYANgA2ADkA
NwANAF8AVABvAGMANQAzADAAMgAwADYAMwA3ADkACwBfAFQAbwBjADEAOQA3ADcAMQA5ADIADABf
AFQAbwBjADMANAA2ADYANgA2ADkAOAAMAF8AVABvAGMAMwA0ADYANgA2ADYAOQA5AAwAXwBUAG8A
YwAzADQANgA2ADYANwAwADAADABfAFQAbwBjADMANAA2ADYANgA3ADAAMQAMAF8AVABvAGMAMwA0
ADYANgA2ADcAMAAyAAwAXwBUAG8AYwAzADQANgA2ADYANwAwADMADABfAFQAbwBjADMANAA2ADYA
NgA3ADAANAAMAF8AVABvAGMAMwA0ADYANgA2ADcAMAA1AAwAXwBUAG8AYwAzADQANgA2ADYANwAw
ADYADABfAFQAbwBjADMANAA2ADYANgA3ADAANwAMAF8AVABvAGMAMwA0ADYANgA2ADcAMAA4AAwA
XwBUAG8AYwAzADQANgA2ADYANwAwADkADABfAFQAbwBjADMANAA2ADYANgA3ADEAMACsBQAA4wgA
ANEJAADkCQAAcgsAAPIOAACLFQAAIyMAAMsnAADLJwAAqyoAAAcsAABQMQAAojEAALsxAAD5MQAA
+DMAAJ05AABVPAAAjzwAAM89AACIPgAAzD4AAKNDAABSSgAArkwAAOhMAACOTQAAnlQAAKJXAADe
VwAAtVkAAEpdAAAfXwAAWV8AAD5gAAC9YwAAB2QAAHVuAACDfgAAbYEAAJOGAADCiAAAe4kAAL6J
AADHiQAAy48AAKWTAADvngAAOKYAAF+nAACcpwAAM6oAANmtAAA2sAAAYrEAAGKxAAApsgAAKbIA
AGa4AABmuAAAAb4AAF7EAAAtyAAAnMsAAMbPAAA10wAAztUAAGncAACK5AAAEesAAG3xAACX8wAA
lvQAAOr1AAAAAAAAAQAAAAIAAAAGAAAAAwAAQAQAAEAFAABABwAAAAgAAEAJAAAACgAAAAsAAAAM
AAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoA
AAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAA
ACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAA
NwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABF
AAAARgAAAEcAAABIAAAASQAAAL8FAADrCAAA4gkAAHMLAADzDgAAjBUAACsjAAArIwAAyycAAN0n
AADIKgAAESwAAJExAACtMQAA+DEAAAcyAAAYNAAA1jkAAIo8AACyPAAA4D0AAMs+AADYPgAAw0MA
AItKAADjTAAAC00AAJxNAACvVAAA3VcAAPJXAADVWQAAg10AAFRfAAB8XwAAT2AAAAZkAAAVZAAA
lW4AALx+AACigQAAtoYAANOIAAC9iQAAxYkAAO+JAADejwAAwZMAAAufAAB4pgAAm6cAALCnAABP
qgAA9a0AAHawAAB5sQAAebEAADOyAAAzsgAAfrgAAH64AAAdvgAAesQAAG3IAAC4ywAA4s8AAHXT
AADq1QAAhdwAAMrkAAAx6wAApvEAAMzzAAC59AAA6vUAAAAAAAAFAgAACQIAAEcCAABPAgAArgIA
ALkCAAAzAwAANQMAAKwDAACwAwAAxAMAAMgDAAACBAAACgQAAA4FAAASBQAAawcAAHQHAAAsJgAA
LiYAAKkpAAC2KQAAFyoAACwqAAB1MQAAdzEAAOg0AADwNAAAfTUAAIU1AACENwAAjDcAAKk5AACy
OQAA1zkAAOA5AAALPAAADjwAAB09AAAlPQAARD4AAEY+AAB8PgAAhD4AAKA+AACqPgAAP0UAAEJF
AADySQAA9UkAADdKAAA6SgAAXkoAAGdKAACMSgAAlUoAAA9LAAASSwAAclEAAHVRAACxVAAAuVQA
ABZVAAAYVQAARVUAAE1VAAAvVwAAN1cAALtXAADFVwAA2FcAANxXAABkWgAAbFoAAFZdAABfXQAA
hF0AAI1dAABQYAAAWGAAALVgAAC3YAAA5GAAAOxgAABKYwAAUmMAAN5jAADoYwAA9WMAAP1jAAAB
ZAAABWQAAI9+AACYfgAAvX4AAMZ+AAAugAAAMoAAAHCAAACBgAAAYYEAAGWBAABogwAAboMAAPeH
AAD5hwAAN4kAADmJAABviQAAd4kAAJWJAACfiQAArIkAALGJAACyiQAAvIkAAMmXAAD0lwAAZKUA
AGelAAChpgAAvaYAAHmnAACDpwAAlqcAAJqnAAAXqQAAH6kAAMqpAADRqQAAz7IAANqyAAAbswAA
JbMAAF+0AABmtAAAZLUAAG61AAC1tQAAv7UAAPS2AAD5tgAA+rYAAAO3AADgtwAA5LcAAPW3AABf
uAAAyr8AAM6/AAB5wAAArcAAAErJAABmyQAAFs0AADzNAACBzQAAkc0AAJLNAACqzQAArM0AALXN
AAC2zQAAxs0AAMfNAADdzQAAT9QAAGvUAAD55gAAFecAAFPuAABX7gAAefEAAILxAACn8QAAsPEA
AGD0AABm9AAAhfQAAIv0AAAv9QAAkvUAAJb1AADC9QAAxvUAAOf1AADq9QAABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABQAHAAUABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcABQAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABQAHABwA
BwAFAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABQAH
ABwABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcAHAAHABwABwAcAAcA
HAAHABwABwAHABwABwAcAAcAAgAAAAAAsgEAALwBAAD8AQAABAIAAO0CAAD3AgAAiwMAAI8DAAC7
AwAAwwMAAGMJAAByCQAATSQAAE4kAACGJAAAjiQAAP0kAAD+JAAAnCsAAKErAAACMAAABDAAAF4x
AABnMQAAojEAAKcxAADDMQAAzDEAAEoyAABVMgAAGTMAACczAABKNwAATDcAACs5AAA1OQAA/jsA
ADc8AADhPQAA5j0AAJA+AACZPgAAWUAAAGZAAABVQQAAX0EAAC9IAAA9SAAAoU0AAN1NAACqVwAA
s1cAAMVjAADOYwAAUGQAAFZkAABYZAAAYWQAAJxkAACmZAAA4GQAAONkAADoZAAA6mQAAB5lAAAh
ZQAAWmUAAGNlAACeZQAApmUAAN5lAADsZQAAFGYAACBmAACAZgAAi2YAAMNmAADHZgAATWcAAFBn
AACVZwAAmWcAANpnAADjZwAA8mcAAPlnAAA0aAAAPGgAAHZoAAB/aAAAu2gAAMJoAAD+aAAA/2gA
AD5pAABFaQAAWGkAAF1pAACUaQAAmWkAAAxqAAATagAAUWoAAFRqAACsagAAsGoAAPBqAADyagAA
bGsAAHRrAACwawAAsmsAAPVrAAD3awAAOmwAAEBsAAB/bAAAhmwAANtsAADlbAAAH20AACFtAABj
bQAAam0AAKhtAACvbQAA7G0AAPFtAAB0bwAAiG8AAB9wAAAucAAA5nAAAOpwAAB+cQAAiHEAAM9x
AADScQAAD3gAABl4AABpeAAAbngAANV4AADYeAAAVnkAAGJ5AAAqegAAMnoAAKp8AADIfAAACn4A
ABZ+AABvfwAAe38AAGiFAABshQAANIcAAD2HAADUiAAA2YgAAISJAACNiQAAs4oAAL2KAAAbkgAA
H5IAAIKZAACWmQAA35oAAOSaAACAnAAAkJwAANOdAAD+nQAAaKcAAHGnAADfqwAA4qsAAE2vAABQ
rwAAOLQAAFi0AACXtQAAmrUAAD62AABDtgAArbYAAOy2AACDuAAArbgAAAy5AAASuQAAUbkAAFO5
AACUuQAAl7kAANW5AADZuQAAF7oAABq6AABcugAAZLoAAKC6AACjugAAILsAACq7AABfuwAAabsA
AJy7AACkuwAAIbwAACW8AABivAAAabwAAJi8AACevAAAkL4AAJK+AABHxQAAVMUAAP7HAAAryAAA
J8kAADTJAAAFywAAMssAABbNAAAozQAAKc0AADzNAAB+zQAAkc0AAJLNAACyzQAAs80AAMbNAADH
zQAA3M0AADzPAABDzwAApNIAAKvSAABP1AAAatQAAELVAAC21QAAK9wAADHcAAD53gAA+t4AAEfk
AABX5AAAvewAAL/sAABd7gAAYe4AALjuAAC77gAA7fMAAPLzAAAv9QAA5/UAAOr1AAAHADMABwAz
AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH
ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz
AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH
ADMABwAzAAcAMwAHADMABwAzAAcAMwAHAAUABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcABQAHAAUABwAF
AAcABQAHAAUABwAFAAcAMwAHADMABwAFAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA
BwAHAAIAAAAAADPRAAA00QAANtEAADbRAABR0QAAW9EAAGfRAACO0QAAltEAAJfRAACq0QAAq9EA
AN/RAADu0QAAJdIAACfSAAAp0gAAwdIAAI3TAACP0wAAkdMAAE7UAABr1AAAbdQAAG/UAAB91AAA
PtUAAEDVAABC1QAATdUAAHLVAACG1QAAstUAALbVAAC31QAAuNUAAITqAAAv9QAAV/UAAIz1AACS
9QAAsvUAAL31AAC+9QAAwvUAAOX1AADn9QAA6vUAAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMA
BAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABwAHAAQABwAF
AAcABQAHAAUABwACAP//FAAAAAoAQgByAGkAYQBuACAAVwB5AGwAZABZAEQAOgBcAHcAbwByAGsA
XABzAHAAZQBlAGMAaABzAGMAXABwAHIAbwB0AG8AYwBvAGwAXwBlAHYAYQBsAFwAZAByAGEAZgB0
AC0AaQBlAHQAZgAtAHMAcABlAGUAYwBoAHMAYwAtAHAAcgBvAHQAbwBjAG8AbAAtAGUAdgBhAGwA
dQBhAHQAaQBvAG4ALQAwADIALQB3AG8AcgBrAGkAbgBnAC0AdwAyAEsALgBkAG8AYwAKAEIAcgBp
AGEAbgAgAFcAeQBsAGQAWQBEADoAXAB3AG8AcgBrAFwAcwBwAGUAZQBjAGgAcwBjAFwAcAByAG8A
dABvAGMAbwBsAF8AZQB2AGEAbABcAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBzAHAAZQBlAGMAaABz
AGMALQBwAHIAbwB0AG8AYwBvAGwALQBlAHYAYQBsAHUAYQB0AGkAbwBuAC0AMAAyAC0AdwBvAHIA
awBpAG4AZwAtAHcAMgBLAC4AZABvAGMACgBCAHIAaQBhAG4AIABXAHkAbABkAFkARAA6AFwAdwBv
AHIAawBcAHMAcABlAGUAYwBoAHMAYwBcAHAAcgBvAHQAbwBjAG8AbABfAGUAdgBhAGwAXABkAHIA
YQBmAHQALQBpAGUAdABmAC0AcwBwAGUAZQBjAGgAcwBjAC0AcAByAG8AdABvAGMAbwBsAC0AZQB2
AGEAbAB1AGEAdABpAG8AbgAtADAAMgAtAHcAbwByAGsAaQBuAGcALQB3ADIASwAuAGQAbwBjAAcA
cgBhAGoAaQB2AGQAaACJAEMAOgBcAFcASQBOAE4AVABcAFAAcgBvAGYAaQBsAGUAcwBcAHIAYQBq
AGkAdgBkAGgAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABEAGEAdABhAFwATQBpAGMAcgBvAHMA
bwBmAHQAXABXAG8AcgBkAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBm
ACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAHMAcABlAGUAYwBoAHMAYwAtAHAAcgBvAHQAbwBjAG8A
bAAtAGUAdgBhAGwAdQBhAHQAaQBvAG4ALQAwADIALQB3AG8AcgBrAGkAbgBnAC0AdwAyAEsALgBh
AHMAZAAHAHIAYQBqAGkAdgBkAGgATQBFADoAXABkAG8AYwBzAFwAbQByAGMAcABcAGQAcgBhAGYA
dAAtAGkAZQB0AGYALQBzAHAAZQBlAGMAaABzAGMALQBwAHIAbwB0AG8AYwBvAGwALQBlAHYAYQBs
AHUAYQB0AGkAbwBuAC0AMAAyAC0AdwBvAHIAawBpAG4AZwAtAHcAMgBLAC0AUgBhAGoAaQB2AC4A
ZABvAGMABwByAGEAagBpAHYAZABoAE0ARQA6AFwAZABvAGMAcwBcAG0AcgBjAHAAXABkAHIAYQBm
AHQALQBpAGUAdABmAC0AcwBwAGUAZQBjAGgAcwBjAC0AcAByAG8AdABvAGMAbwBsAC0AZQB2AGEA
bAB1AGEAdABpAG8AbgAtADAAMgAtAHcAbwByAGsAaQBuAGcALQB3ADIASwAtAFIAYQBqAGkAdgAu
AGQAbwBjAAcAcgBhAGoAaQB2AGQAaACPAEMAOgBcAFcASQBOAE4AVABcAFAAcgBvAGYAaQBsAGUA
cwBcAHIAYQBqAGkAdgBkAGgAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABEAGEAdABhAFwATQBp
AGMAcgBvAHMAbwBmAHQAXABXAG8AcgBkAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEA
dgBlACAAbwBmACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAHMAcABlAGUAYwBoAHMAYwAtAHAAcgBv
AHQAbwBjAG8AbAAtAGUAdgBhAGwAdQBhAHQAaQBvAG4ALQAwADIALQB3AG8AcgBrAGkAbgBnAC0A
dwAyAEsALQBSAGEAagBpAHYALgBhAHMAZAAHAHIAYQBqAGkAdgBkAGgAjwBDADoAXABXAEkATgBO
AFQAXABQAHIAbwBmAGkAbABlAHMAXAByAGEAagBpAHYAZABoAFwAQQBwAHAAbABpAGMAYQB0AGkA
bwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABcAEEAdQB0AG8AUgBl
AGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBzAHAA
ZQBlAGMAaABzAGMALQBwAHIAbwB0AG8AYwBvAGwALQBlAHYAYQBsAHUAYQB0AGkAbwBuAC0AMAAy
AC0AdwBvAHIAawBpAG4AZwAtAHcAMgBLAC0AUgBhAGoAaQB2AC4AYQBzAGQABwByAGEAagBpAHYA
ZABoAI8AQwA6AFwAVwBJAE4ATgBUAFwAUAByAG8AZgBpAGwAZQBzAFwAcgBhAGoAaQB2AGQAaABc
AEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBvAGYAdABcAFcA
bwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABkAHIAYQBm
AHQALQBpAGUAdABmAC0AcwBwAGUAZQBjAGgAcwBjAC0AcAByAG8AdABvAGMAbwBsAC0AZQB2AGEA
bAB1AGEAdABpAG8AbgAtADAAMgAtAHcAbwByAGsAaQBuAGcALQB3ADIASwAtAFIAYQBqAGkAdgAu
AGEAcwBkAAcAcgBhAGoAaQB2AGQAaABNAEUAOgBcAGQAbwBjAHMAXABtAHIAYwBwAFwAZAByAGEA
ZgB0AC0AaQBlAHQAZgAtAHMAcABlAGUAYwBoAHMAYwAtAHAAcgBvAHQAbwBjAG8AbAAtAGUAdgBh
AGwAdQBhAHQAaQBvAG4ALQAwADIALQB3AG8AcgBrAGkAbgBnAC0AdwAyAEsALQBSAGEAagBpAHYA
LgBkAG8AYwAPAPv////4Y1wB/w//DwMABAAFAAYABwAIAAkAAAAZXE4Ewu5wBf8P/w//D/8P/w//
D/8P/w//DxAAJ3YQJu46hnj/DyYA/w//D/8P/w//D/8P/w8AANkWNCsPAAkE/w8AAAAAAAAAAAAA
AAAAAAAAAQCLKXorAueA4v8P/w//D/8P/w//D/8P/w//DxAA7g5VOtIiEnn/D/8P/w//D/8P/w//
D/8P/w8QAO9YVEWYVsqZEAAmACcA/w//D/8P/w//D/8PAACdMRVHamxqef8P/w//D/8P/w//D/8P
/w//DwAAXgwkTo4+slAmAP8P/w//D/8P/w//D/8P/w8AAC493k8w/1yU/w//D/8P/w//D/8P/w//
D/8PAADdb4Fhhp4Syv8P/w//D/8P/w//D/8P/w//DxAA41YRY0RnXh7/D/8P/w//D/8P/w//D/8P
/w8QANZ7e2zQ/N4l/w//D/8P/w//D/8P/w//D/8PEAD4cF9vDs5o+f8P/w//D/8P/w//D/8P/w//
DwAA8ClJeXAWNKL/D/8P/w//D/8P/w//D/8P/w8AAAAAAAD/AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAQAIAAAAAAAAAAAB4AAAA0AIA
AAAQAAAPhNACEYQw/V6E0AJghDD9AgAuAAIAAQAAAABAAgQAAAAAAAAAAHgAAABgAwAAABAAAA+E
YAMRhKD8XoRgA2CEoPwEAC4AAgAuAAMAAQAAAABAAgQGAAAAAAAAAHgAAADwAwAAABAAAA+E8AMR
hBD8XoTwA2CEEPwGAC4AAgAuAAMALgAEAAEAAAAAQAIEBggAAAAAAAB4AAAAgAQAAAAQAAAPhIAE
EYSA+16EgARghID7CAAuAAIALgADAC4ABAAuAAUAAQAAAABAAgQGCAoAAAAAAHgAAAAQBQAAABAA
AA+EEAURhPD6XoQQBWCE8PoKAC4AAgAuAAMALgAEAC4ABQAuAAYAAQAAAABAAgQGCAoMAAAAAHgA
AACgBQAAABAAAA+EoAURhGD6XoSgBWCEYPoMAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAAEAAAAA
QAIEBggKDA4AAAB4AAAAMAYAAAAQAAAPhDAGEYTQ+V6EMAZghND5DgAuAAIALgADAC4ABAAuAAUA
LgAGAC4ABwAuAAgABAAAABcAAAAAAAAAAAAAAAAAAAAAAAAAExgAAA+ErgMRhJj+FcYFAAGuAwZe
hK4DYISY/k9KAABQSgAAUUoAAF5KAABvKAABAC0AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgA
AA+EfgYRhJj+FcYFAAF+BgZehH4GYISY/k9KAwBRSgMAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAA
AAAAAAAAAAsYAAAPhE4JEYSY/hXGBQABTgkGXoROCWCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF4AA
AAAAAAAAAAAAAAAAAAAAAAALGAAAD4QeDBGEmP4VxgUAAR4MBl6EHgxghJj+T0oBAFFKAQBvKAAB
ALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E7g4RhJj+FcYFAAHuDgZehO4OYISY/k9K
AwBRSgMAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhL4REYSY/hXGBQABvhEG
XoS+EWCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SOFBGE
mP4VxgUAAY4UBl6EjhRghJj+T0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA
CxgAAA+EXhcRhJj+FcYFAAFeFwZehF4XYISY/k9KAwBRSgMAbygAAQBvAAEAAAAXgAAAAAAAAAAA
AAAAAAAAAAAAAAsYAAAPhC4aEYSY/hXGBQABLhoGXoQuGmCEmP5PSgYAUUoGAG8oAAEAp/ABAAAA
ABABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4QyBBGEmP4VxgUAATIEBl6EMgRghJj+AgAAAC4AAQAA
AAAQAQMAAAAAAAAAAGgBAAAAAAAAAxgBAA+EfQQRhFD+FcYFAAGdBQZehH0EYIRQ/m8oAAQAAAAu
AAEALgABAAAAABABAwUAAAAAAAAAaAEAAAAAAAADGAIAD4QtBhGECP4VxgUAAW0IBl6ELQZghAj+
bygABgAAAC4AAQAuAAIALgABAAAAABABAwUHAAAAAAAAaAEAAAAAAAADGAMAD4QlCBGEeP0VxgUA
Ad0QBl6EJQhghHj9bygACAAAAC4AAQAuAAIALgADAC4AAQAAAAAQAQMFBwkAAAAAAGgBAAAAAAAA
AxgEAA+EHQoRhOj8FcYFAAEVFQZehB0KYITo/G8oAAoAAAAuAAEALgACAC4AAwAuAAQALgABAAAA
ABABAwUHCQsAAAAAaAEAAAAAAAADGAUAD4QVDBGEWPwVxgUAAeUXBl6EFQxghFj8bygADAAAAC4A
AQAuAAIALgADAC4ABAAuAAUALgABAAAAABABAwUHCQsNAAAAaAEAAAAAAAADGAYAD4QNDhGEyPsV
xgUAAR0cBl6EDQ5ghMj7bygADgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4AAQAAAAAQAQMF
BwkLDQ8AAGgBAAAAAAAAAxgHAA+EBRARhDj7FcYFAAFVIAZehAUQYIQ4+28oABAAAAAuAAEALgAC
AC4AAwAuAAQALgAFAC4ABgAuAAcALgABAAAAABABAwUHCQsNDxEAaAEAAAAAAAADGAgAD4RFEhGE
YPoVxgUAAY0kBl6ERRJghGD6bygAEgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgA
LgADAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+bygA
AgAAAC4AAgAAABcAAAAAAAAAAAAAAAAAAAAAAAAAExgAAA+EywQRhJj+FcYFAAHLBAZehMsEYISY
/k9KAwBQSgAAUUoDAF5KAwBvKAABAC0AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EmwcR
hJj+FcYFAAGbBwZehJsHYISY/k9KAwBRSgMAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAA
AAsYAAAPhGsKEYSY/hXGBQABawoGXoRrCmCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF4AAAAAAAAAA
AAAAAAAAAAAAAAALGAAAD4Q7DRGEmP4VxgUAATsNBl6EOw1ghJj+T0oBAFFKAQBvKAABALfwAQAA
ABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+ECxARhJj+FcYFAAELEAZehAsQYISY/k9KAwBRSgMA
bygAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhNsSEYSY/hXGBQAB2xIGXoTbEmCE
mP5PSgYAUUoGAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SrFRGEmP4VxgUA
AasVBl6EqxVghJj+T0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E
exgRhJj+FcYFAAF7GAZehHsYYISY/k9KAwBRSgMAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAA
AAAAAAsYAAAPhEsbEYSY/hXGBQABSxsGXoRLG2CEmP5PSgYAUUoGAG8oAAEAp/ABAAAAAAABAAAA
AAAAAAAAAAAAAAAAAAADGAAAD4QWBRGETf4VxgUAARYFBl6EFgVghE3+bygAAgAAAC4AAQAAAAQA
AQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EmwcRhJj+FcYFAAGbBwZehJsHYISY/gIAAQAuAAEAAAAC
AgEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhGsKEYRM/xXGBQABawoGXoRrCmCETP8CAAIALgABAAAA
AAABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4Q7DRGEmP4VxgUAATsNBl6EOw1ghJj+AgADAC4AAQAA
AAQAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+ECxARhJj+FcYFAAELEAZehAsQYISY/gIABAAuAAEA
AAACAgEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhNsSEYRM/xXGBQAB2xIGXoTbEmCETP8CAAUALgAB
AAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SrFRGEmP4VxgUAAasVBl6EqxVghJj+AgAGAC4A
AQAAAAQAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EexgRhJj+FcYFAAF7GAZehHsYYISY/gIABwAu
AAEAAAACAgEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhEsbEYRM/xXGBQABSxsGXoRLG2CETP8CAAgA
LgABAAAAABABAAAAAAAAAAAAGAMAAAAAAAADGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+bygA
AgAAAC4AAQAAAAAQAQMAAAAAAAAAABgDAAAAAAAAAxgBAA+E6AURhFD+FcYFAAEIBwZehOgFYIRQ
/m8oAAQAAAAuAAEALgABAAAAABABAwUAAAAAAAAAGAMAAAAAAAADGAIAD4SYBxGECP4VxgUAAdgJ
Bl6EmAdghAj+bygABgAAAC4AAQAuAAIALgABAAAAABABAwUHAAAAAAAAGAMAAAAAAAADGAMAD4SQ
CRGEeP0VxgUAAUgSBl6EkAlghHj9bygACAAAAC4AAQAuAAIALgADAC4AAQAAAAAQAQMFBwkAAAAA
ABgDAAAAAAAAAxgEAA+EiAsRhOj8FcYFAAGAFgZehIgLYITo/G8oAAoAAAAuAAEALgACAC4AAwAu
AAQALgABAAAAABABAwUHCQsAAAAAGAMAAAAAAAADGAUAD4SADRGEWPwVxgUAAVAZBl6EgA1ghFj8
bygADAAAAC4AAQAuAAIALgADAC4ABAAuAAUALgABAAAAABABAwUHCQsNAAAAGAMAAAAAAAADGAYA
D4R4DxGEyPsVxgUAAYgdBl6EeA9ghMj7bygADgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4A
AQAAAAAQAQMFBwkLDQ8AABgDAAAAAAAAAxgHAA+EcBERhDj7FcYFAAHAIQZehHARYIQ4+28oABAA
AAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgABAAAAABABAwUHCQsNDxEAGAMAAAAAAAAD
GAgAD4SwExGEYPoVxgUAAfglBl6EsBNghGD6bygAEgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAG
AC4ABwAuAAgALgABAAAAABABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RoARGEmP4VxgUAAWgBBl6E
aAFghJj+AgAAAC4AAQAAAAAQAQMAAAAAAAAAAAAAAAAAAAAAABgAAA+EGAMRhFD+FcYFAAEYAwZe
hBgDYIRQ/gQAAAAuAAEALgABAAAAABABAwUAAAAAAAAAAAAAAAAAAAAAGAAAD4TIBBGECP4VxgUA
AaAFBl6EyARghAj+BgAAAC4AAQAuAAIALgABAAAAABABAwUHAAAAAAAAAAAAAAAAAAAAGAAAD4TA
BhGEeP0VxgUAAQgHBl6EwAZghHj9CAAAAC4AAQAuAAIALgADAC4AAQAAAAAQAQMFBwkAAAAAAAAA
AAAAAAAAABgAAA+EuAgRhOj8FcYFAAHYCQZehLgIYITo/AoAAAAuAAEALgACAC4AAwAuAAQALgAB
AAAAABABAwUHCQsAAAAAAAAAAAAAAAAAGAAAD4SwChGEWPwVxgUAAUALBl6EsApghFj8DAAAAC4A
AQAuAAIALgADAC4ABAAuAAUALgABAAAAABABAwUHCQsNAAAAAAAAAAAAAAAAGAAAD4SoDBGEyPsV
xgUAARAOBl6EqAxghMj7DgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4AAQAAAAAQAQMFBwkL
DQ8AAAAAAAAAAAAAABgAAA+EoA4RhDj7FcYFAAF4DwZehKAOYIQ4+xAAAAAuAAEALgACAC4AAwAu
AAQALgAFAC4ABgAuAAcALgABAAAAABABAwUHCQsNDxEAAAAAAAAAAAAAGAAAD4TgEBGEYPoVxgUA
AUgSBl6E4BBghGD6EgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgALgABAAAAABAB
AAAAAAAAAAAAaAEAAAAAAAADGAAAD4SgBRGEmP4VxgUAAQgHBl6EoAVghJj+bygAAgAAAC4AAQAA
AAAQAQMAAAAAAAAAAGgBAAAAAAAAAxgBAA+EUAcRhFD+FcYFAAFwCAZehFAHYIRQ/m8oAAQAAAAu
AAEALgABAAAAABABAwUAAAAAAAAAaAEAAAAAAAADGAIAD4QACRGECP4VxgUAAUALBl6EAAlghAj+
bygABgAAAC4AAQAuAAIALgABAAAAABABAwUHAAAAAAAAaAEAAAAAAAADGAMAD4T4ChGEeP0VxgUA
AbATBl6E+ApghHj9bygACAAAAC4AAQAuAAIALgADAC4AAQAAAAAQAQMFBwkAAAAAAGgBAAAAAAAA
AxgEAA+E8AwRhOj8FcYFAAHoFwZehPAMYITo/G8oAAoAAAAuAAEALgACAC4AAwAuAAQALgABAAAA
ABABAwUHCQsAAAAAaAEAAAAAAAADGAUAD4ToDhGEWPwVxgUAAbgaBl6E6A5ghFj8bygADAAAAC4A
AQAuAAIALgADAC4ABAAuAAUALgABAAAAABABAwUHCQsNAAAAaAEAAAAAAAADGAYAD4TgEBGEyPsV
xgUAAfAeBl6E4BBghMj7bygADgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4AAQAAAAAQAQMF
BwkLDQ8AAGgBAAAAAAAAAxgHAA+E2BIRhDj7FcYFAAEoIwZehNgSYIQ4+28oABAAAAAuAAEALgAC
AC4AAwAuAAQALgAFAC4ABgAuAAcALgABAAAAABABAwUHCQsNDxEAaAEAAAAAAAADGAgAD4QYFRGE
YPoVxgUAAWAnBl6EGBVghGD6bygAEgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgA
LgABAAAAAEABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAC4AAQAAAABAAQMAAAAAAAAAAAAAAAAA
AAAAAAAAAAMAAAAuAAEAAQAAAABAAQMFAAAAAAAAAAAAAAAAAAAAAAAAAAUAAAAuAAEALgACAAEA
AAAAQAEDBQcAAAAAAAAAAAAAAAAAAAAAAAAHAAAALgABAC4AAgAuAAMAAQAAAABAAQMFBwkAAAAA
AAAAAAAAAAAAAAAAAAkAAAAuAAEALgACAC4AAwAuAAQAAQAAAABAAQMFBwkLAAAAAAAAAAAAAAAA
AAAAAAsAAAAuAAEALgACAC4AAwAuAAQALgAFAAEAAAAAQAEDBQcJCw0AAAAAAAAAAAAAAAAAAAAN
AAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYAAQAAAABAAQMFBwkLDQ8AAAAAAAAAAAAAAAAAAA8A
AAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcAAQAAAABAAQMFBwkLDQ8RAHgAAAAwBgAAABAA
AA+EUBARhND5XoRQEGCE0PkRAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAAEAAAA
FwAAAAAAAAAAAAAAAAAAAAAAAAATGAAAD4QYAxGEmP4VxgUAARgDBl6EGANghJj+T0oAAFBKAABR
SgAAXkoAAG8oAAEALQABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4ToBRGEmP4VxgUAAegF
Bl6E6AVghJj+T0oDAFFKAwBvKAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EuAgR
hJj+FcYFAAG4CAZehLgIYISY/k9KBgBRSgYAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAA
AAsYAAAPhIgLEYSY/hXGBQABiAsGXoSIC2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAA
AAAAAAAAAAAAAAALGAAAD4RYDhGEmP4VxgUAAVgOBl6EWA5ghJj+T0oDAFFKAwBvKAABAG8AAQAA
ABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EKBERhJj+FcYFAAEoEQZehCgRYISY/k9KBgBRSgYA
bygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhPgTEYSY/hXGBQAB+BMGXoT4E2CE
mP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4TIFhGEmP4VxgUA
AcgWBl6EyBZghJj+T0oDAFFKAwBvKAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E
mBkRhJj+FcYFAAGYGQZehJgZYISY/k9KBgBRSgYAbygAAQCn8AEAAAAAEAEAAAAAAAAAAAAYAwAA
AAAAAAAYAAAPhDAGEYSY/hXGBQABMAYGXoQwBmCEmP4CAAAALgABAAAABJABAAAAAAAAAAAAGAMA
AAAAAAAAGAAAD4RQBxGEmP4VxgUAAVAHBl6EUAdghJj+AgABAC4AAQAAAAKSAQAAAAAAAAAAABgD
AAAAAAAAABgAAA+EIAoRhEz/FcYFAAEgCgZehCAKYIRM/wIAAgAuAAEAAAAAkAEAAAAAAAAAAAAY
AwAAAAAAAAAYAAAPhPAMEYSY/hXGBQAB8AwGXoTwDGCEmP4CAAMALgABAAAABJABAAAAAAAAAAAA
GAMAAAAAAAAAGAAAD4TADxGEmP4VxgUAAcAPBl6EwA9ghJj+AgAEAC4AAQAAAAKSAQAAAAAAAAAA
ABgDAAAAAAAAABgAAA+EkBIRhEz/FcYFAAGQEgZehJASYIRM/wIABQAuAAEAAAAAkAEAAAAAAAAA
AAAYAwAAAAAAAAAYAAAPhGAVEYSY/hXGBQABYBUGXoRgFWCEmP4CAAYALgABAAAABJABAAAAAAAA
AAAAGAMAAAAAAAAAGAAAD4QwGBGEmP4VxgUAATAYBl6EMBhghJj+AgAHAC4AAQAAAAKSAQAAAAAA
AAAAABgDAAAAAAAAABgAAA+EABsRhEz/FcYFAAEAGwZehAAbYIRM/wIACAAuAAEAAAAAEAEAAAAA
AAAAAABoAQAAAAAAAAAYAAAPhIAEEYSY/hXGBQABgAQGXoSABGCEmP4CAAAALgABAAAABJABAAAA
AAAAAAAAaAEAAAAAAAAAGAAAD4RQBxGEmP4VxgUAAVAHBl6EUAdghJj+AgABAC4AAQAAAAISAQAA
AAAAAAAAAGgBAAAAAAAAABgAAA+EIAoRhEz/FcYFAAEgCgZehCAKYIRM/wIAAgAuAAEAAAAAkAEA
AAAAAAAAAABoAQAAAAAAAAAYAAAPhPAMEYSY/hXGBQAB8AwGXoTwDGCEmP4CAAMALgABAAAABJAB
AAAAAAAAAAAAaAEAAAAAAAAAGAAAD4TADxGEmP4VxgUAAcAPBl6EwA9ghJj+AgAEAC4AAQAAAAKS
AQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EkBIRhEz/FcYFAAGQEgZehJASYIRM/wIABQAuAAEAAAAA
kAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhGAVEYSY/hXGBQABYBUGXoRgFWCEmP4CAAYALgABAAAA
BJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4QwGBGEmP4VxgUAATAYBl6EMBhghJj+AgAHAC4AAQAA
AAKSAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EABsRhEz/FcYFAAEAGwZehAAbYIRM/wIACAAuAAEA
AAAAAAEAAAAAAAAAAAEAAAAAAAAAAAMQAAAPhLABEYRQ/l6EsAFghFD+bygAAgAAAC4AAQAAAAAA
AQMAAAAAAAAAAQAAAAAAAAAAAxAAAA+EQAIRhMD9XoRAAmCEwP1vKAADAAAALgABAAEAAAAAAAED
BQAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw/RXGBQAB0AIGXoTQAmCEMP1vKAAFAAAALgABAC4A
AgABAAAAAAABAwUHAAAAAAAAAAAAAAAAAAADGAAAD4RgAxGEoPwVxgUAAWADBl6EYANghKD8bygA
BwAAAC4AAQAuAAIALgADAAEAAAAAAAEDBQcJAAAAAAAAAAAAAAAAAAMYAAAPhPADEYQQ/BXGBQAB
8AMGXoTwA2CEEPxvKAAJAAAALgABAC4AAgAuAAMALgAEAAEAAAAAAAEDBQcJCwAAAAAAAAAAAAAA
AAMYAAAPhIAEEYSA+xXGBQABgAQGXoSABGCEgPtvKAALAAAALgABAC4AAgAuAAMALgAEAC4ABQAB
AAAAAAABAwUHCQsNAAAAAAAAAAAAAAADGAAAD4QQBRGE8PoVxgUAARAFBl6EEAVghPD6bygADQAA
AC4AAQAuAAIALgADAC4ABAAuAAUALgAGAAEAAAAAAAEDBQcJCw0PAAAAAAAAAAAAAAMYAAAPhKAF
EYRg+hXGBQABoAUGXoSgBWCEYPpvKAAPAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAAEA
AAAAAAEDBQcJCw0PEQAAAAAAAAAAAAMYAAAPhDAGEYTQ+RXGBQABMAYGXoQwBmCE0PlvKAARAAAA
LgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAABAAAAABABAAAAAAAAAAAAaAEAAAAAAAAD
GAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+bygAAgAAAC4AAQAAAAAQAQMAAAAAAAAAAGgBAAAA
AAAAAxgBAA+E6AURhFD+FcYFAAEIBwZehOgFYIRQ/m8oAAQAAAAuAAEALgABAAAAABABAwUAAAAA
AAAAaAEAAAAAAAADGAIAD4SYBxGECP4VxgUAAdgJBl6EmAdghAj+bygABgAAAC4AAQAuAAIALgAB
AAAAABABAwUHAAAAAAAAaAEAAAAAAAADGAMAD4SQCRGEeP0VxgUAAagMBl6EkAlghHj9bygACAAA
AC4AAQAuAAIALgADAC4AAQAAAAAQAQMFBwkAAAAAAGgBAAAAAAAAAxgEAA+EiAsRhOj8FcYFAAGA
FgZehIgLYITo/G8oAAoAAAAuAAEALgACAC4AAwAuAAQALgABAAAAABABAwUHCQsAAAAAaAEAAAAA
AAADGAUAD4SADRGEWPwVxgUAAVAZBl6EgA1ghFj8bygADAAAAC4AAQAuAAIALgADAC4ABAAuAAUA
LgABAAAAABABAwUHCQsNAAAAaAEAAAAAAAADGAYAD4R4DxGEyPsVxgUAAbATBl6EeA9ghMj7bygA
DgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4AAQAAAAAQAQMFBwkLDQ8AAGgBAAAAAAAAAxgH
AA+EcBERhDj7FcYFAAHAIQZehHARYIQ4+28oABAAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAu
AAcALgABAAAAABABAwUHCQsNDxEAaAEAAAAAAAADGAgAD4SwExGEYPoVxgUAAfglBl6EsBNghGD6
bygAEgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgALgAPAAAA+////wAAAAAAAAAA
AAAAAC493k8AAAAAAAAAAAAAAADWe3tsAAAAAAAAAAAAAAAAnTEVRwAAAAAAAAAAAAAAACd2ECYA
AAAAAAAAAAAAAADjVhFjAAAAAAAAAAAAAAAAXgwkTgAAAAAAAAAAAAAAAPApSXkAAAAAAAAAAAAA
AADvWFRFAAAAAAAAAAAAAAAAGVxOBAAAAAAAAAAAAAAAAPhwX28AAAAAAAAAAAAAAADZFjQrAAAA
AAAAAAAAAAAA7g5VOgAAAAAAAAAAAAAAAIspeisAAAAAAAAAAAAAAADdb4FhAAAAAAAAAAAAAAAA
////////////////////////////////////////////////////////////////////////////
//////8PAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//8PAAAAAAASAHpv0GsDAAwE
BQAMBAEADAQDAAwEBQAMBAEADAQDAAwEBQAMBBIAYkNqPP//////////////////////////////
////////////AAASAKyDSAkDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIA5Cnq+RkA
CQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkEEgBchwIuGQAMBBsADAQPAAwEGQAMBBsADAQP
AAwEGQAMBBsADAQAABIA3gOuk///////////////////////////////////////////AAASAE7r
IpMDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIADwAMBBkADAQbAAwEDwAMBBkADAQb
AAwEDwAMBBkADAQbAAwEEgAPAAwEGQAMBBsADAQPAAwEGQAMBBsADAQPAAwEGQAMBBsADAQAABIA
NJIS0v//////////////////////////////////////////AAAAAA8AAAAXAAAAGAAAAEMAAABK
AAAASwAAAHYAAAB/AAAAgAAAAIsAAADBAAAAwgAAAC/1AADn9QAA6vUAAAAAAAACAQAAAgEAAJ4B
AAACAQAAAgEAAJ4BAAACAQAAAgEAAJ4BAAACAQAAAgEAAJYBAAAAAAAAAQAAAP9ARmluZVByaW50
IERyaXZlcgBGUFIxOgB3aW5zcG9vbABGaW5lUHJpbnQgRHJpdmVyAEZpbmVQcmludCBEcml2ZXIA
AAAAAAAAAAAAAAAAAAAAAQQ3A5wAXAADbAYAAQABAAAAAAAAAAAAAABYAgIAAABYAgMAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgCGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEZQAAABAAAAVwBJAE4AVwBPAFIARAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAABYAvoA2AD6APMAAQAA
AAEARmluZVByaW50IERyaXZlcgAAAAAAAAAAAAAAAAAAAAABBDcDnABcAANsBgABAAEAAAAAAAAA
AAAAAFgCAgAAAFgCAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAIYAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARlAAAAEAAABXAEkA
TgBXAE8AUgBEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA/wAAAFgC+gDYAPoA8wABAAAAAQABgAEAu9UAALvVAABownMAAQABALvVAAAAAAAAu9UAAAAA
AAACEAAAAAAAAADp9QAAoAAACABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAAAAAA
AAAAAP//AQAAAAAA//8AAAIA//8AAAAA//8AAAIA//8AAAAABwAAAEcWkAEAAAICBgMFBAUCAwSH
egAgAAAAgAgAAAAAAAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUW
kAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEA
AAILBgQCAgICAgSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAAA/NZABAAACBwMJ
AgIFAgQEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAAMxaQ
AQAAAgIGAwUEBQIDBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAAADsWkAGBBwID
BgAAAQEBAQGvAgCw+3zXaTAAAAAAAAAAnwAIAAAAAABCAGEAdABhAG4AZwAAABS81dAAADsGkAEC
AAUAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBnAGQAaQBuAGcAcwAAACIA
BABBAIgYAPDQAuQEaAEAAAAAjIx2Ro6cdoY1DWumBAAcCQAAdyMAACvKAAABAGcAAAAEAAAQrwEA
ACIEAACQFwAAAQAMAAAAMgAAAAAAAAAhAwDwEIQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACl
BsAHeAB4AIABMjAAABAAGQBkAAAAGQAAAEb4AACyGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAACk2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwyg3EA8BCE/wMA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAAFgBTAHAAZQBlAGMAaABTAEMA
IABXAG8AcgBrAGkAbgBnACAARwByAG8AdQBwAAAAAAAAAAQAVwB5AGwAZAAHAHIAYQBqAGkAdgBk
AGgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAAAAAA
AAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAIwBAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAADAAAAA
BAAAAMwAAAAFAAAA3AAAAAYAAADoAAAABwAAAPQAAAAIAAAABAEAAAkAAAAUAQAAEgAAACABAAAK
AAAAPAEAAAsAAABIAQAADAAAAFQBAAANAAAAYAEAAA4AAABsAQAADwAAAHQBAAAQAAAAfAEAABMA
AACEAQAAAgAAAOQEAAAeAAAAFwAAAFNwZWVjaFNDIFdvcmtpbmcgR3JvdXAAAB4AAAABAAAAAHBl
ZR4AAAAFAAAAV3lsZABoU0MeAAAAAQAAAAB5bGQeAAAAAQAAAAB5bGQeAAAABwAAAE5vcm1hbABD
HgAAAAgAAAByYWppdmRoAB4AAAACAAAANABqaR4AAAATAAAATWljcm9zb2Z0IFdvcmQgOS4wAG9A
AAAAAKjRxkUBAABAAAAAAPYcViOCwgFAAAAAAPB8njY1wwFAAAAAAPzWOsk2wwEDAAAAAQAAAAMA
AAB3IwAAAwAAACvKAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQACAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN
1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuTAEAAAgBAAAMAAAAAQAAAGgAAAAPAAAA
cAAAAAUAAACEAAAABgAAAIwAAAARAAAAlAAAABcAAACcAAAACwAAAKQAAAAQAAAArAAAABMAAAC0
AAAAFgAAALwAAAANAAAAxAAAAAwAAADnAAAAAgAAAOQEAAAeAAAACQAAAEVsb3F1YW50AAA2AAMA
AACvAQAAAwAAAGcAAAADAAAARvgAAAMAAADtDgkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAA
AAAAAAAeEAAAAQAAABcAAABTcGVlY2hTQyBXb3JraW5nIEdyb3VwAAwQAAACAAAAHgAAAAYAAABU
aXRsZQADAAAAAQAAAAAAAAwTAAADAAAAAAAAACAAAAABAAAAOAAAAAIAAABAAAAAAQAAAAIAAAAM
AAAAX1BJRF9ITElOS1MAAgAAAOQEAABBAAAAxBIAAGgBAAADAAAAMgASAAMAAABpAQAAAwAAAAAA
AAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAANAAAAXwBUAG8AYwAzADQANgA2ADYANwAxADAAAAAA
AAMAAAAzABsAAwAAAGMBAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAA0AAABfAFQA
bwBjADMANAA2ADYANgA3ADAAOQAAAAAAAwAAADMAGgADAAAAXQEAAAMAAAAAAAAAAwAAAAUAAAAf
AAAAAQAAAAAAAAAfAAAADQAAAF8AVABvAGMAMwA0ADYANgA2ADcAMAA4AAAAAAADAAAAMwAVAAMA
AABXAQAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAANAAAAXwBUAG8AYwAzADQANgA2
ADYANwAwADcAAAAAAAMAAAAzABQAAwAAAFEBAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAA
HwAAAA0AAABfAFQAbwBjADMANAA2ADYANgA3ADAANgAAAAAAAwAAADMAFwADAAAASwEAAAMAAAAA
AAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAADQAAAF8AVABvAGMAMwA0ADYANgA2ADcAMAA1AAAA
AAADAAAAMwAWAAMAAABFAQAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAANAAAAXwBU
AG8AYwAzADQANgA2ADYANwAwADQAAAAAAAMAAAAzABEAAwAAAD8BAAADAAAAAAAAAAMAAAAFAAAA
HwAAAAEAAAAAAAAAHwAAAA0AAABfAFQAbwBjADMANAA2ADYANgA3ADAAMwAAAAAAAwAAADMAEAAD
AAAAOQEAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAADQAAAF8AVABvAGMAMwA0ADYA
NgA2ADcAMAAyAAAAAAADAAAAMwATAAMAAAAzAQAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAA
AB8AAAANAAAAXwBUAG8AYwAzADQANgA2ADYANwAwADEAAAAAAAMAAAAzABIAAwAAAC0BAAADAAAA
AAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAA0AAABfAFQAbwBjADMANAA2ADYANgA3ADAAMAAA
AAAAAwAAADoAGgADAAAAJwEAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAADQAAAF8A
VABvAGMAMwA0ADYANgA2ADYAOQA5AAAAAAADAAAAOgAbAAMAAAAhAQAAAwAAAAAAAAADAAAABQAA
AB8AAAABAAAAAAAAAB8AAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA5ADgAAAAAAAMAAAA6ABQA
AwAAABsBAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAA0AAABfAFQAbwBjADMANAA2
ADYANgA2ADkANwAAAAAAAwAAADoAFQADAAAAFQEAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAA
AAAfAAAADQAAAF8AVABvAGMAMwA0ADYANgA2ADYAOQA2AAAAAAADAAAAOgAWAAMAAAAPAQAAAwAA
AAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA5ADUA
AAAAAAMAAAA6ABcAAwAAAAkBAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAA0AAABf
AFQAbwBjADMANAA2ADYANgA2ADkANAAAAAAAAwAAADoAEAADAAAAAwEAAAMAAAAAAAAAAwAAAAUA
AAAfAAAAAQAAAAAAAAAfAAAADQAAAF8AVABvAGMAMwA0ADYANgA2ADYAOQAzAAAAAAADAAAAOgAR
AAMAAAD9AAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAANAAAAXwBUAG8AYwAzADQA
NgA2ADYANgA5ADIAAAAAAAMAAAA6ABIAAwAAAPcAAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAA
AAAAHwAAAA0AAABfAFQAbwBjADMANAA2ADYANgA2ADkAMQAAAAAAAwAAADoAEwADAAAA8QAAAAMA
AAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAADQAAAF8AVABvAGMAMwA0ADYANgA2ADYAOQAw
AAAAAAADAAAAOwAaAAMAAADrAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAANAAAA
XwBUAG8AYwAzADQANgA2ADYANgA4ADkAAAAAAAMAAAA7ABsAAwAAAOUAAAADAAAAAAAAAAMAAAAF
AAAAHwAAAAEAAAAAAAAAHwAAAA0AAABfAFQAbwBjADMANAA2ADYANgA2ADgAOAAAAAAAAwAAADsA
FAADAAAA3wAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAADQAAAF8AVABvAGMAMwA0
ADYANgA2ADYAOAA3AAAAAAADAAAAOwAVAAMAAADZAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAA
AAAAAB8AAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA4ADYAAAAAAAMAAAA7ABYAAwAAANMAAAAD
AAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAA0AAABfAFQAbwBjADMANAA2ADYANgA2ADgA
NQAAAAAAAwAAADsAFwADAAAAzQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAADQAA
AF8AVABvAGMAMwA0ADYANgA2ADYAOAA0AAAAAAADAAAAOwAQAAMAAADHAAAAAwAAAAAAAAADAAAA
BQAAAB8AAAABAAAAAAAAAB8AAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA4ADMAAAAAAAMAAAA7
ABEAAwAAAMEAAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAA0AAABfAFQAbwBjADMA
NAA2ADYANgA2ADgAMgAAAAAAAwAAADsAEgADAAAAuwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAA
AAAAAAAfAAAADQAAAF8AVABvAGMAMwA0ADYANgA2ADYAOAAxAAAAAAADAAAAOwATAAMAAAC1AAAA
AwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA4
ADAAAAAAAAMAAAA0ABoAAwAAAK8AAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAA0A
AABfAFQAbwBjADMANAA2ADYANgA2ADcAOQAAAAAAAwAAADQAGwADAAAAqQAAAAMAAAAAAAAAAwAA
AAUAAAAfAAAAAQAAAAAAAAAfAAAADQAAAF8AVABvAGMAMwA0ADYANgA2ADYANwA4AAAAAAADAAAA
NAAUAAMAAACjAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAANAAAAXwBUAG8AYwAz
ADQANgA2ADYANgA3ADcAAAAAAAMAAAA0ABUAAwAAAJ0AAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEA
AAAAAAAAHwAAAA0AAABfAFQAbwBjADMANAA2ADYANgA2ADcANgAAAAAAAwAAADQAFgADAAAAlwAA
AAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAADQAAAF8AVABvAGMAMwA0ADYANgA2ADYA
NwA1AAAAAAADAAAANAAXAAMAAACRAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAN
AAAAXwBUAG8AYwAzADQANgA2ADYANgA3ADQAAAAAAAMAAAA0ABAAAwAAAIsAAAADAAAAAAAAAAMA
AAAFAAAAHwAAAAEAAAAAAAAAHwAAAA0AAABfAFQAbwBjADMANAA2ADYANgA2ADcAMwAAAAAAAwAA
ADQAEQADAAAAhQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAADQAAAF8AVABvAGMA
MwA0ADYANgA2ADYANwAyAAAAAAADAAAANAASAAMAAAB/AAAAAwAAAAAAAAADAAAABQAAAB8AAAAB
AAAAAAAAAB8AAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA3ADEAAAAAAAMAAAA0ABMAAwAAAHkA
AAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAA0AAABfAFQAbwBjADMANAA2ADYANgA2
ADcAMAAAAAAAAwAAADUAGgADAAAAcwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAA
DQAAAF8AVABvAGMAMwA0ADYANgA2ADYANgA5AAAAAAADAAAANQAbAAMAAABtAAAAAwAAAAAAAAAD
AAAABQAAAB8AAAABAAAAAAAAAB8AAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA2ADgAAAAAAAMA
AAA1ABQAAwAAAGcAAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAA0AAABfAFQAbwBj
ADMANAA2ADYANgA2ADYANwAAAAAAAwAAADUAFQADAAAAYQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAA
AQAAAAAAAAAfAAAADQAAAF8AVABvAGMAMwA0ADYANgA2ADYANgA2AAAAAAADAAAANQAWAAMAAABb
AAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAANAAAAXwBUAG8AYwAzADQANgA2ADYA
NgA2ADUAAAAAAAMAAAA1ABcAAwAAAFUAAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAA
AA0AAABfAFQAbwBjADMANAA2ADYANgA2ADYANAAAAAAAAwAAADUAEAADAAAATwAAAAMAAAAAAAAA
AwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAADQAAAF8AVABvAGMAMwA0ADYANgA2ADYANgAzAAAAAAAD
AAAANQARAAMAAABJAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAANAAAAXwBUAG8A
YwAzADQANgA2ADYANgA2ADIAAAAAAAMAAAA1ABIAAwAAAEMAAAADAAAAAAAAAAMAAAAFAAAAHwAA
AAEAAAAAAAAAHwAAAA0AAABfAFQAbwBjADMANAA2ADYANgA2ADYAMQAAAAAAAwAAADUAEwADAAAA
PQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAADQAAAF8AVABvAGMAMwA0ADYANgA2
ADYANgAwAAAAAAADAAAANgAaAAMAAAA3AAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8A
AAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA1ADkAAAAAAAMAAAA2ABsAAwAAADEAAAADAAAAAAAA
AAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAA0AAABfAFQAbwBjADMANAA2ADYANgA2ADUAOAAAAAAA
AwAAADYAFAADAAAAKwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAADQAAAF8AVABv
AGMAMwA0ADYANgA2ADYANQA3AAAAAAADAAAANgAVAAMAAAAlAAAAAwAAAAAAAAADAAAABQAAAB8A
AAABAAAAAAAAAB8AAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA1ADYAAAAAAAMAAAA2ABYAAwAA
AB8AAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAA0AAABfAFQAbwBjADMANAA2ADYA
NgA2ADUANQAAAAAAAwAAADYAFwADAAAAGQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAf
AAAADQAAAF8AVABvAGMAMwA0ADYANgA2ADYANQA0AAAAAAADAAAANgAQAAMAAAATAAAAAwAAAAAA
AAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAANAAAAXwBUAG8AYwAzADQANgA2ADYANgA1ADMAAAAA
AAMAAAA2ABEAAwAAAA0AAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAA0AAABfAFQA
bwBjADMANAA2ADYANgA2ADUAMgAAAAAAAwAAADYAEgADAAAABwAAAAMAAAAAAAAAAwAAAAUAAAAf
AAAAAQAAAAAAAAAfAAAADQAAAF8AVABvAGMAMwA0ADYANgA2ADYANQAxAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsA
AAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAA
ABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAA
KAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2
AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQA
AABFAAAARgAAAEcAAABIAAAASQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAA
AFMAAABUAAAAVQAAAFYAAABXAAAAWAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAA
YQAAAGIAAABjAAAAZAAAAGUAAABmAAAAZwAAAGgAAABpAAAAagAAAGsAAABsAAAAbQAAAG4AAABv
AAAAcAAAAHEAAAByAAAAcwAAAHQAAAB1AAAAdgAAAHcAAAB4AAAAeQAAAHoAAAB7AAAAfAAAAH0A
AAB+AAAAfwAAAIAAAACBAAAAggAAAIMAAACEAAAAhQAAAIYAAACHAAAAiAAAAIkAAACKAAAAiwAA
AIwAAACNAAAAjgAAAI8AAACQAAAAkQAAAJIAAACTAAAAlAAAAJUAAACWAAAAlwAAAJgAAACZAAAA
mgAAAJsAAACcAAAAnQAAAJ4AAACfAAAAoAAAAKEAAACiAAAAowAAAKQAAAClAAAApgAAAKcAAACo
AAAAqQAAAKoAAACrAAAArAAAAK0AAACuAAAArwAAALAAAACxAAAAsgAAALMAAAC0AAAAtQAAALYA
AAC3AAAAuAAAALkAAAC6AAAAuwAAALwAAAD+////vgAAAL8AAADAAAAAwQAAAMIAAADDAAAAxAAA
AMUAAADGAAAAxwAAAMgAAADJAAAAygAAAMsAAADMAAAAzQAAAM4AAADPAAAA0AAAANEAAADSAAAA
0wAAANQAAADVAAAA1gAAANcAAADYAAAA2QAAAP7////bAAAA3AAAAN0AAADeAAAA3wAAAOAAAADh
AAAA4gAAAOMAAADkAAAA5QAAAOYAAADnAAAA6AAAAOkAAADqAAAA6wAAAOwAAADtAAAA7gAAAO8A
AADwAAAA8QAAAPIAAADzAAAA9AAAAPUAAAD2AAAA9wAAAPgAAAD5AAAA+gAAAPsAAAD8AAAA/QAA
AP4AAAD/AAAAAAEAAAEBAAACAQAAAwEAAAQBAAAFAQAABgEAAAcBAAAIAQAACQEAAAoBAAALAQAA
DAEAAA0BAAAOAQAADwEAABABAAARAQAAEgEAABMBAAAUAQAAFQEAABYBAAAXAQAAGAEAABkBAAAa
AQAAGwEAABwBAAAdAQAAHgEAAB8BAAAgAQAAIQEAACIBAAAjAQAAJAEAACUBAAAmAQAAJwEAACgB
AAApAQAAKgEAACsBAAAsAQAALQEAAC4BAAAvAQAAMAEAADEBAAAyAQAA/v///zQBAAA1AQAANgEA
ADcBAAA4AQAAOQEAADoBAAD+////PAEAAD0BAAA+AQAAPwEAAEABAABBAQAAQgEAAEMBAABEAQAA
RQEAAP7////9/////f////3///9KAQAA/v////7////+////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAA
AAAAAAAA0MdFP8k2wwFMAQAAgAAAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf///////////////wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL0AAACoOQAAAAAAADEAVABhAGIAbABlAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIAAQAAAP//
////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2gAAAJ+wAAAAAAAAVwBv
AHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAABoAAgEGAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAMnkBAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAADMBAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkA
SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOwEAAFgUAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgECAAAABwAA
AP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAABPAGIA
agBlAGMAdABQAG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAFgABAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA0MdFP8k2wwHQx0U/yTbDAQAA
AAAAAAAAAAAAAAEAAAD+////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhgAAABNaWNyb3NvZnQgV29yZCBE
b2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAA=

------_=_NextPart_001_01C336CA.725411EF--

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From exim@www1.ietf.org  Fri Jun 27 19:47:03 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26550
	for ; Fri, 27 Jun 2003 19:47:02 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5RNkY831324
	for speechsc-archive@odin.ietf.org; Fri, 27 Jun 2003 19:46:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19W2vJ-000899-VN
	for speechsc-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 19:46:33 -0400
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26530
	for ; Fri, 27 Jun 2003 19:46:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19W2uo-00084m-Id; Fri, 27 Jun 2003 19:46:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19W0o4-0003la-Ro
	for speechsc@optimus.ietf.org; Fri, 27 Jun 2003 17:30:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21102;
	Fri, 27 Jun 2003 17:29:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19W0n6-0006XI-00; Fri, 27 Jun 2003 17:29:56 -0400
Received: from smtp-105-friday.noc.nerim.net ([62.4.17.105] helo=mallaury.noc.nerim.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 19W0mu-0006XD-00; Fri, 27 Jun 2003 17:29:44 -0400
Received: from weasel.hq.eloquant.com (styx.eloquant.com [80.65.227.37])
	by mallaury.noc.nerim.net (Postfix) with ESMTP
	id 9A94B62D15; Fri, 27 Jun 2003 23:29:33 +0200 (CEST)
Received: from polo (atalante.hq.eloquant.com [192.168.0.11])
	by weasel.hq.eloquant.com (Postfix) with SMTP
	id 13C7A3B6CA; Fri, 27 Jun 2003 17:39:55 -0400 (EDT)
Reply-To: 
From: "Brian Wyld" 
To: 
Cc: , "'Speechsc (E-mail)'" ,
        "Brian Wyld" 
Date: Fri, 27 Jun 2003 23:25:05 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0070_01C33D03.574A9E10"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: [Speechsc] speechsc WG Internet Draft submission : draft-ietf-speechsc-protocol-eval-02.txt  - Update to version 02 for  protocol evaluation document
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	

This is a multi-part message in MIME format.

------=_NextPart_000_0070_01C33D03.574A9E10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Attached is an update of the speechsc protocol evaluation draft 
for submission as Internet draft.

Thanks for processing this update.

A+

Brian

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services] 
 

------=_NextPart_000_0070_01C33D03.574A9E10
Content-Type: text/plain;
	name="draft-ietf-speechsc-protocol-eval-02.txt"
Content-Disposition: attachment;
	filename="draft-ietf-speechsc-protocol-eval-02.txt"
Content-Transfer-Encoding: quoted-printable


=0A=
 Internet Draft                                                 B. Wyld=20
 Document: draft-ietf-speechsc-protocol-evaluation-02            Editor=20
 Expires: October 2003                                         Eloquant=20
 Version 02                                                   June 2003=20
 =20
                        SPEECHSC Protocol Evaluation=20
 =20
 Status of this Memo =20
    =20
    This document is an Internet-Draft and is in full conformance with=20
    all provisions of Section 10 of RFC2026. =20
        =20
    Internet-Drafts are working documents of the Internet Engineering=20
    Task Force (IETF), its areas, and its working groups.  Note that=20
    other groups may also distribute working documents as Internet-
    Drafts. =20
        =20
    Internet-Drafts are draft documents valid for a maximum of six=20
    months and may be updated, replaced, or obsoleted by other=20
    documents at any time. It is inappropriate to use Internet-Drafts=20
    as reference material or to cite them other than as "work in=20
    progress." =20
        =20
    The list of current Internet-Drafts can be accessed at =20
         http://www.ietf.org/ietf/1id-abstracts.txt =20
    The list of Internet-Draft Shadow Directories can be accessed at =20
         http://www.ietf.org/shadow.html. =20
        =20
 Abstract =20
    =20
    This document is the Protocol Evaluation Document for the SPEECHSC=20
    Working Group.  Section 3 provides the summary of the  individual=20
    protocol comparisons (in the sections 4-N following) against the=20
    SPEECHSC requirements [1].=20
  =20
 Table of Contents=20
    =20
    1.   Overview...................................................2=20
    2.   Protocol Proposals.........................................3=20
    3.   Protocol Evaluation Summary and Conclusion.................3=20
    4.   Session Control : =93Beep=94 Compliance Evaluation (Jerry =
Carter)
         3=20
       4.1.   General notes:........................................3=20
       4.2.   Analysis of General Requirements......................4=20
       4.3.   Analysis of Duplexing and Parallel Operation=20
       Requirements..................................................4=20
       4.4.   Analysis of additional considerations (non-normative).5=20
       4.5.   Analysis of Security considerations...................5=20
       4.6.   Interaction Model.....................................5=20
    5.   Session Control : =93SIP=94 Complience Evaluation (Rajiv=20
    Dharmadhikari)...................................................5=20
       5.1.   Introduction..........................................5=20
       5.2.   Analysis of General Requirements......................6=20
       5.3.   Analysis of Duplexing and Parallel Operation=20
       Requirements..................................................7=20
       5.4.   Analysis of additional considerations (non-normative).7=20
       5.5.   Analysis of Security considerations...................7=20
       5.6.   Other Criteria........................................7=20
       5.7.   Interaction Model.....................................8=20
    6.   Session Control : =93RTSP=94 Complience Evaluation (Brian =
Wyld)8=20
       6.1.   General Introduction..................................8=20
 =20
 =20
 Wyld                    Expires =96 October 2003               [Page 1] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
       6.2.   Analysis of General Requirements......................9=20
       6.3.   Analysis of Duplexing and Parallel Operation=20
       Requirements..................................................9=20
       6.4.   Analysis of additional considerations (non-normative).9=20
       6.5.   Analysis of Security considerations..................10=20
       6.6.   Interaction Model....................................10=20
    7.   Session Control : =93Web Services=94 Complience Evaluation=20
    (Stephane H. Maes)..............................................10=20
       7.1.   General Notes:.......................................10=20
       7.2.   Analysis of General Requirements.....................11=20
       7.3.   Analysis of Duplexing and Parallel Operation=20
       Requirements.................................................13=20
       7.4.   Analysis of additional considerations (non-normative)13=20
       7.5.   Analysis of Security considerations..................14=20
       7.6.   Interaction Model....................................14=20
    8.   Resource Control : =93MRCP=94 Complience Evaluation (Sarvi=20
    Shanmugham).....................................................14=20
       8.1.   General..............................................14=20
       8.2.   Analysis of TTS requirements.........................15=20
       8.3.   Analysis of ASR requirements.........................16=20
       8.4.   Analysis of Speaker Identification and Verification=20
       Requirements.................................................17=20
    9.   Resource Control : =93RTSP=94 Complience Evaluation (Brian =
Wyld)
         18=20
       9.1.   General Introduction.................................18=20
       9.2.   Analysis of TTS requirements.........................18=20
       9.3.   Analysis of ASR requirements.........................18=20
       9.4.   Analysis of Speaker Identification and Verification=20
       Requirements.................................................19=20
    10.  Security Considerations...................................19=20
    11.  References................................................19=20
       =20
      1. Overview =20
        =20
    This document provides the template for the content for the=20
    SPEECHSC Protocol Evaluation document.   =20
        =20
    This section will contain an overview of the process.=20
    =20
    Section 2 contains a list of the proposed protocols submitted to=20
    WG. These protocols are in fact of 3 different natures:=20
       - a generic service/resource access system (Web Services)=20
       - =91classic=92 session control protocols for media channels =
(BEEP,=20
          SIP, RTSP), of which RTSP also provides resource control.=20
       - a specific ASR/TTS resource control message set designed to=20
          be tunneled in a session control protocol (MRCP)=20
 =20
    Section 3 provides a conclusion of the evaluations of the proposed=20
    protocols against the Requirements and framework, and recommends a=20
    direction for the creation of the speechsc protocol. =20
 =20
    Sections 4-7 provide the individual protocol evaluations for the=20
    protocols providing session control against the SPEECHSC=20
    requirements [1] that relate to these needs.=20
    =20
    Sections 8 and 9 provide individual protocol evaluations for=20
    protocols providing resource control against the SPEECHSC resource=20
    control requirements.=20
        =20
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003               [Page 2] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
      2. Protocol Proposals=20
 =20
    This section contains a list of the existing protocols submitted to=20
    the SPEECHSC WG for consideration by the deadline. =20
          1. BEEP=20
          2. SIP=20
          3. RTSP=20
          4. MRCP (initial submission)=20
          5. Web Services=20
    =20
    =20
    Each protocol section contains a review of the protocol=92s level of =

    compliance to each of the SPEECHSC Requirements [1] as derived from=20
    the proposed protocol documents. The following key will be used to=20
    identify the level of compliancy of each of the individual=20
    protocols:=20
    =20
    T =3D Total Complience.  Meets the requirement fully.=20
    P =3D Partial Compliance.  Meets some aspect of the requirement.=20
    P+ =3D Complience possible. Could meet the requirement with =
=93natural=94=20
    evolution of the protocol. =20
    F =3D Failed Compliance.  Does not meet the requirement. =20
    =20
      3. Protocol Evaluation Summary and Conclusion=20
    =20
    In summary, it appears that the decomposition of the problem into=20
    session control and resource control gives rise to:=20
    =20
     - SIP is a good fit for session control for the speechsc=20
    requirements=20
    =20
     - MRCP is a good start for resource control for the speechsc=20
    requirements=20
    =20
    The conclusion for the protocol evaluation is therefore to:=20
       - create a new speechsc specific resource control only=20
          protocol, based on MRCP=20
       - use sessions that have been established by SIP (and defines a=20
          means of referring to these sessions)=20
    =20
    =20
      4. Session Control : =93Beep=94 Compliance Evaluation (Jerry =
Carter)=20
=0A=
         4.1. General notes:=20
    =20
    The BEEP protocol provides a general framework for establishing =20
    connections, defining new channels, negotiating security, and=20
    performing user authentication. Protocols build on beep must define=20
    a profile detailing how connections are established and must define=20
    a set of messages which will be delivered using BEEP. The protocol=20
    is peer-to-peer although client-server style requests could be=20
    easily handled.=20
    =20
    The following sub-sections compare each individual requirement=20
    against the protocol.=20
=0A=
=0A=
=0A=
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003               [Page 3] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
         4.2. Analysis of General Requirements=20
=0A=
           4.2.1. Reuse existing protocols [5.1]=20
    =20
    T: Beep is a published protocol, listed as RFC 3080=20
    (http://www.ietf.org/rfc/rfc3080.txt).=20
=0A=
           4.2.2. Maintain Existing Protocol Integrity [5.2]=20
    =20
    P: BEEP assumes that protocols, such as SpeechSC, will add=20
    messages.=20
    =20
    Supporting multiple clients using TCP may require some effort.=20
=0A=
           4.2.3. Avoid Duplicating Existing Protocols [5.3]=20
    =20
    T: Building SpeechSC over BEEP would allow the specification to=20
    focus on managing the ASR, media server, and SI/SV resources and=20
    the possible interactions between them. The operations for=20
    establishing connections and defining new channels would be handled=20
    by BEEP.=20
=0A=
           4.2.4. Protocol efficiency [5.4]=20
    =20
    P+: BEEP imposes a small overhead (roughly 40 bytes per message).=20
    It provides a mechanism for supporting multiple communication=20
    channels over a single port. If grouping of requests is desired,=20
    this would need to be handled by grouping the SpeechSC messages.=20
=0A=
           4.2.5. Explicit invocation of services [5.5]=20
    =20
    T: Though it is primarily a peer-to-peer protocol, BEEP may act as=20
    a traditional client server protocol.=20
=0A=
           4.2.6. Server Location and Load Balancing [5.6]=20
    =20
    P+: This functionality is not provided by BEEP. This would need to=20
    be added as an extension.=20
=0A=
           4.2.7. Simultaneous services [5.7]=20
    =20
    T: Multiple channels providing different services is possible. Each=20
    service is simply a message type which is passed to the server=20
    using BEEP.=20
=0A=
           4.2.8. Multiple media sessions [5.8]=20
    =20
    F: BEEP assumes a 1:1 using TCP/IP.=20
=0A=
         4.3. Analysis of Duplexing and Parallel Operation Requirements=20
=0A=
           4.3.1. Duplexing and Parallel Operation Requirements [9]=20
    =20
    P+: Parallel operations may be obtained using multiple channels. A=20
    message on one channel could potentially interrupt activity=20
    happening on the second. BEEP is very flexible allowing the server=20
    to implement whatever behavior is desired.=20
 =20
 =20
 Wyld                    Expires =96 October 2003               [Page 4] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
           4.3.2. Full Duplex operation [9.1.1]=20
    =20
    T: BEEP is a peer-to-peer protocol allowing full duplex=20
    communication on a single channel or parallel communication on=20
    multiple channels.=20
=0A=
           4.3.3. Multiple services in parallel [9.1.2]=20
    =20
    P+: Multiple services may be run on separate channels. Merging or=20
    T-ing of RTP must be implemented by the server.=20
=0A=
           4.3.4. Combination of services=20
    TBD=20
=0A=
         4.4. Analysis of additional considerations (non-normative)=20
    TBD=20
=0A=
         4.5. Analysis of Security considerations=20
=0A=
           4.5.1. Security Considerations [11]=20
    =20
    P+: BEEP offers a mechanism for managing security and user=20
    authentication. =20
    SpeechSC requires managing multiple data streams and some form of=20
    unified authentication / security might be a goal. If so, BEEP=20
    security should be revisited with this in mind.=20
    =20
=0A=
         4.6. Interaction Model=20
    TBC : TO BE COMPLETED : Analysis of the interaction model of the=20
    protocol during the =91data=92 phase (ie after session =
establishment)=20
    and its suitability for speechsc.=20
    =20
    =20
      5. Session Control : =93SIP=94 Complience Evaluation (Rajiv=20
         Dharmadhikari)=20
=0A=
         5.1. Introduction=20
    SIP is a protocol for initiating, modifying, and terminating=20
    multimedia sessions. The protocol is considered an IETF standard=20
    and its specifications can be found in [2]. The following sections=20
    provide a general statement with regards to the applicability of=20
    SIP as the control protocol for SPEECHSC. =20
    =20
=0A=
           5.1.1. SIP General Applicability=20
    SIP is a pretty mature, well understood, and frequently used =20
    session establishment protocol. It has gone through multiple=20
    revisions in the IETF standard process. There are number of=20
    commercial and public domain implementations of SIP that are=20
    available. Because of its close resemblance to HTTP and being a=20
    text based protocol, there are large number of SIP application=20
    developers available. =20
    =20
=0A=
=0A=
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003               [Page 5] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
           5.1.2. SIP Use in VOIP environment=20
    SIP is already being used to establish and redirect RTP streams=20
    from various end points. The SPEECHSC requires a protocol for=20
    controlling ASR, TTS and SV resources. When these resources are=20
    deployed in a VOIP network that requires them to process media=20
    carried in RTP, the SIP protocol is used in lot of deployments.=20
    Rather than inventing a new control protocol and introducing=20
    operational aspects of the new protocol, SIP can be reused for=20
    controlling SPEECHSC resources. =20
    =20
=0A=
         5.2. Analysis of General Requirements=20
=0A=
           5.2.1. Reuse existing protocols [5.1]=20
    T: SIP is an existing, widely used, and mature protocol defined in=20
    [2].=20
=0A=
           5.2.2. Maintain Existing Protocol Integrity [5.2]=20
    T: Existing SIP methods and header fields will not be changed when=20
    SIP is used to control SPEECHSC resources. In case, if extensions=20
    are required, SIP allows carriage of custom payload in the body.=20
    This payload is understood only by UAs and it does not impact=20
    protocol integrity.=20
    =20
=0A=
           5.2.3. Avoid Duplicating Existing Protocols [5.3]=20
    T: Lot of the requirements for SPEECHSC operation can easily be=20
    satisfied by SIP, e.g. establishing RTP streams or redirecting=20
    them. Without SIP, new SPEECHSC protocol will have to duplicate lot=20
    of session management functionality.=20
    =20
=0A=
           5.2.4. Protocol efficiency [5.4]=20
    T: SIP is a very lightweight protocol when run over TCP or UDP. It=20
    leverages efficiency available in TCP and UDP protocols that have=20
    been around for over 20 years.=20
=0A=
           5.2.5. Explicit invocation of services [5.5]=20
    T: SIP URI mechanism allows invocation of different services.=20
=0A=
           5.2.6. Server Location and Load Balancing [5.6]=20
    P+: SIP employs standard DNS name resolution for locating=20
    resources. SIP itself does not provide load balancing features.=20
    Application level load balancers can be used to load balance SIP=20
    requests.=20
    =20
=0A=
           5.2.7. Simultaneous services [5.7]=20
    T: SIP allows simultaneous invocation of different services. SIP=20
    allows forking or splitting the same media stream to different end=20
    points as defined in [2].=20
    =20
=0A=
           5.2.8. Multiple media sessions [5.8]=20
    T: SIP uses SDP to describe RTP stream characteristics. This allows=20
    the control of direction of RTP stream such as bi-directional or=20
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003               [Page 6] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
    uni-directional. SIP allows a UA to establish sessions with=20
    multiple UAs for the same session.=20
    =20
=0A=
         5.3. Analysis of Duplexing and Parallel Operation Requirements=20
=0A=
           5.3.1. Duplexing and Parallel Operation Requirements [9]=20
    T: SPEECHSC resource is a SIP UA that can handle session requests=20
    from different UAs.=20
=0A=
           5.3.2. Full Duplex operation [9.1.1]=20
    T: Each SIP UA consists of a UAC and a UAS. This allows for full=20
    duplex operation.=20
=0A=
           5.3.3. Multiple services in parallel [9.1.2]=20
    T: SIP allows simultaneous invocation of different services. SIP=20
    allows forking or splitting the same media stream to different end=20
    points as defined in [2].=20
    =20
=0A=
           5.3.4. Combination of services=20
    T: See 5.6.3. SIP UA can invoke different services and combine the=20
    results.=20
=0A=
         5.4. Analysis of additional considerations (non-normative)=20
    TBD=20
=0A=
         5.5. Analysis of Security considerations=20
=0A=
           5.5.1. Security Considerations [11]=20
    T: SIP protocol employs different authentication schemes that are=20
    widely used in IP based protocols.=20
=0A=
         5.6. Other Criteria=20
    The following criteria were also defined by the evaluator of SIP.=20
=0A=
           5.6.1. Ability to establish session between SPEECHSC client=20
               and SPEECHSC resource=20
    T: SIP User Agent can establish a session with another SIP User=20
    Agent.=20
=0A=
           5.6.2. Ability to terminate session by either SPEECHSC=20
               client or SPEECHSC resource=20
    T: SIP User Agent can terminate a session with another SIP User=20
    Agent.=20
=0A=
           5.6.3. Support reliable sequencing and delivery between=20
               SPEECHSC client and SPEECHSC resource=20
    P: SIP can be run over TCP or UDP. When run over TCP, this=20
    requirement is easily satisfied. When run over UDP, SIP User Agent=20
    is required to implement logic to ensure reliable sequencing and=20
    delivery. =20
=0A=
=0A=
=0A=
=0A=
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003               [Page 7] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
           5.6.4. Ability for SPEECHSC client to coordinate SPEECHSC=20
               resources on different machines for a single session=20
    T: SPEECHSC client can use SIP to establish SIP sessions with=20
    different machines.=20
=0A=
           5.6.5. Ability for SPEECHSC resource to handle multiple=20
               SPEECHSC clients=20
    T: SPEECHSC resource is a SIP UA that can handle session requests=20
    from different UAs.=20
=0A=
           5.6.6. The SPEECHSC resource should be able to generate=20
               asynchronous events or unsolicited messages=20
    T: SIP allows asynchronous events or unsolicited messages to be=20
    generated using SUBSCRIBE/NOTIFY mechanism.=20
=0A=
           5.6.7. The SPEECHSC client and resource should have ability=20
               for authenticating each other=20
    T: SIP protocol employs different authentication schemes that are=20
    widely used in IP based protocols.=20
=0A=
           5.6.8. Ability to determine success or failure from both=20
               SPEECHSC client and SPEECHSC resource side=20
    T: The protocol has following response codes: 200 for success, 3xx,=20
    4xx, and 5xx for failure.=20
=0A=
           5.6.9. Support for versioning between SPEECHSC client and=20
               SPEECHSC resource=20
    P+: This will require an additional header or element in the   =20
    body of SIP message for versioning. The current version field is=20
    intended for SIP protocol version. =20
    =20
=0A=
         5.7. Interaction Model=20
    =20
    Speechsc has certain needs related to the interaction model of the=20
    protocol during the =91data=92 phase (ie after session =
establishment).=20
    Specifically, speechsc will require that the resource server can=20
    send unsolicited messages/transactions to the resource client to=20
    return results and indicate events.=20
    =20
    SIP messages in the data phase can flow in both directions (client=20
    to server as well as server to client). SIP INFO message can be=20
    used for this purpose. The SIP INFO is intended for mid-call=20
    message semantics. With this message, transactions can be=20
    initiated/defined by both ends. =20
    =20
    SIP therefore has an interaction model suited to the speechsc=20
    model, which supports peer-peer messaging with a basic=20
    transactional symmetrical request/response model.=20
    =20
      6. Session Control : =93RTSP=94 Complience Evaluation (Brian Wyld) =

=0A=
         6.1. General Introduction=20
    RTSP is an existing protocol, orientated towards audio playback and=20
    recording. As such, it has support for RTP session control, with=20
    SDP used for session description, and a message set allowing=20
    operation as a player/recorder with audio =93VCR=94 controls.=20
    =20
 =20
 =20
 Wyld                    Expires =96 October 2003               [Page 8] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
    Only the session control is evaluated here (see later section for=20
    evaluation of the resource control elements)=20
    =20
    The following sub-sections compare each individual requirement=20
    against the protocol.=20
=0A=
         6.2. Analysis of General Requirements=20
=0A=
           6.2.1. Reuse existing protocols [5.1]=20
    T: RTSP/RTP/SDP would be reused.=20
=0A=
           6.2.2. Maintain Existing Protocol Integrity [5.2]=20
    T: The extensions to RTSP to allow speechsc use would be in the=20
    spirit of the protocol, and would not break existing servers or=20
    clients.=20
=0A=
           6.2.3. Avoid Duplicating Existing Protocols [5.3]=20
    T: Using RTSP would not recreate it.=20
=0A=
           6.2.4. Protocol efficiency [5.4]=20
    T: RTSP is a text based protocol, but is relatively succinct as=20
    messages are specific to their operation.=20
=0A=
           6.2.5. Explicit invocation of services [5.5]=20
    T: RTSP service invocation is sufficient.=20
=0A=
           6.2.6. Server Location and Load Balancing [5.6]=20
    F: RTSP does not address this topic; however it can be used with=20
    other IETF protocols such as SLP or UDDI to do so.=20
=0A=
           6.2.7. Simultaneous services [5.7]=20
    T: RTSP allows simultaneous invocation of services on the same or=20
    different control channel.=20
=0A=
           6.2.8. Multiple media sessions [5.8]=20
    T: RTSP allows multiple media sessions.=20
=0A=
         6.3. Analysis of Duplexing and Parallel Operation Requirements=20
=0A=
           6.3.1. Duplexing and Parallel Operation Requirements [9]=20
    T: RTSP allows session setup that should fulfill these=20
    requirements.=20
=0A=
           6.3.2. Full Duplex operation [9.1.1]=20
    T: RTSP can create a full duplex session.=20
=0A=
           6.3.3. Multiple services in parallel [9.1.2]=20
    T: RTSP can request multiple operations of the same type on the=20
    same session.=20
=0A=
           6.3.4. Combination of services=20
    T: RTSP can request multiple operations of different types on the=20
    same session.=20
=0A=
         6.4. Analysis of additional considerations (non-normative)=20
    TBD=20
 =20
 =20
 Wyld                    Expires =96 October 2003               [Page 9] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
         6.5. Analysis of Security considerations=20
=0A=
           6.5.1. Security Considerations [11]=20
    F: RTSP provides no specific security functionality at all, but=20
    depends on other IETF security protocols (as it uses TCP) to pre-
    validate and protect the sessions.=20
=0A=
         6.6. Interaction Model=20
    Speechsc has certain needs related to the interaction model of the=20
    protocol during the =91data=92 phase (ie after session =
establishment).=20
    Specifically, speechsc will require that the resource server can=20
    send unsolicited messages/transactions to the resource client to=20
    return results and indicate events.=20
    =20
    RTSP messages in the data phase can flow in both directions (client=20
    to server as well as server to client). Transactions can be=20
    initiated/defined by both ends. Currently most of the defined=20
    transactions are C-S; however there already exists an ANNOUNCE=20
    message transaction that is used to transit general content in both=20
    directions (and is in fact used by MRCP to transport its resource=20
    control messages).=20
    =20
    RTSP has therefore an interaction model suited to the speechsc=20
    model, which supports peer-peer messaging with a basic=20
    transactional symmetrical request/response model.=20
    =20
      7. Session Control : =93Web Services=94 Complience Evaluation=20
         (Stephane H. Maes)=20
=0A=
         7.1. General Notes:=20
    Speech engines (speech recognition, speaker, recognition, speech =20
    synthesis, recorders and playback, NL parsers, and any other speech=20
    processing engines (e.g. speech detection, barge-in detection etc) =20
    etc...) as well as audio sub-systems (audio input and output =20
    sub-systems) can be considered as web services that can be =20
    described and asynchronously programmed via WSDL (on top of SOAP), =20
    combined in a flow described via WSFL, discovered via UDDI and =20
    asynchronously controlled via SOAP that also enables =20
    asynchronous exchanges between the engines.=20
     =20
    This solution presents the advantage to provide flexibility, =20
    scalability and extensibility while reusing an existing framework =20
    that fits the evolution of the web: web services and XML protocols=20
    [WS1]=20
    =20
    According to the web services framework, speech engines (audio =20
    sub-systems, engines, speech processors) can be defined as web=20
    services=20
    that are characterized by an interface that consists of some of the  =

    following ports:=20
        - "control in" port(s): It sets the engine context, i.e. all=20
    the=20
        settings required for a speech engine to run. It may include =20
        addresses where to get or send the streamed audio or results.=20
        - "control out" port(s): It produces the non-audio engine=20
    output=20
        (i.e. results and events). It may also involve some session =20
        control exchanges.=20
        - "audio in" port(s): It receives streamed input data. =20
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 10] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
        - "audio out" port(s): It produces streamed output data. =20
    =20
    Audio sub-systems can also be treated as web services that can =20
    produce streamed data or play incoming streamed data as specified=20
    by=20
    the control parameters.=20
    =20
    The "control in" or "control out" messages can be out-of-band or =20
    sent or received interleaved with "audio in or out" data. This can =20
    be determined in the context (setup) of the web services. =20
    =20
    Speech engines and audio sub-systems are pre-programmed as web =20
    services and composed into more advanced services. Once programmed =20
    by the application / controller, audio-sub-systems and engines=20
    await=20
    an incoming event (established audio session, etc...) to execute=20
    the=20
    speech processing that they have been programmed to do and send the  =

    results as programmed. =20
    =20
    Speech engines as web services are typically programmed to handle =20
    completely a particular speech processing task, including handling =20
    of possible errors. For example, as speech engine is programmed to =20
    perform recognition of the next incoming utterance with a=20
    particular=20
    grammar, to send result to a NL parser and to contact a particular =20
    error recovery process if particular errors occur.=20
    =20
    The following sub-sections compare each individual requirement=20
    against the protocol.=20
=0A=
         7.2. Analysis of General Requirements=20
=0A=
           7.2.1. Reuse existing protocols [5.1]=20
    T: Web services are is a class of protocols (framework) widely=20
    studied and developed across numerous standard bodies like W3C,=20
    OASIS, WS-I, Liberty, Parlay and adapted to numerous deployment=20
    environments  issues at IETF, OMA, 3GPP, 3GPP2, JCP, etc=85 As an=20
    entry point, we recommend consulting the work at W3C [WS1].=20
    =20
=0A=
           7.2.2. Maintain Existing Protocol Integrity [5.2]=20
    T: Web services is an XML-based framework that is by definition=20
    extensible to support appropriate syntax and semantics. =20
    =20
    Web services are bound on underlying transport protocols. Numerous=20
    such binding have been specified. Others are in development. By=20
    handling at SPEECHSC at the level of the =20
    Web services framework, the integrity is maintained for:=20
    - underlying transport protocols (to which the web service are=20
    bound (e.g. SOAP)=20
    - web service framework=20
    =20
    This does not prevent introducing bindings to new protocols if=20
    needed. For example, binding to SIP or BEEP could be advantageous=20
    for mobile deployments.=20
    =20
=0A=
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 11] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
           7.2.3. Avoid Duplicating Existing Protocols [5.3]=20
    T: By definition, the web service framework can be specified to=20
    remote control any web service. Specified syntax can be limited to=20
    avoid duplicating remote control functionalities offered by other=20
    protocols. =20
    =20
    At the same time, the extensibility inherent to the framework=20
    guarantees that it is possible to specify (standard) or define=20
    (application specific) remote control for other entities beyond the=20
    current scope of SPEECHSC. =20
    =20
    In that context and in view of unifying the remote control=20
    framework exposed to an application developer or a system=20
    integrator, it may be of interest to provide remote control syntax=20
    for special entities like prompt player etc=85=20
    =20
=0A=
           7.2.4. Protocol efficiency [5.4]=20
    P+ to P: Web services are by definition more verbose protocols.=20
    Hence, at this stage this does not qualify work a T mark. =20
    =20
    However work is in progress (e.g. OMA, JCP) to optimize the=20
    exchanges to handle:=20
    - Client with limited resources=20
    - Constrained bandwidth=20
    These rely on protocol compression and optimization, caching and=20
    gateways. =20
    =20
    As such the protocols qualify as P+.=20
    =20
    In addition, based on the qualification of efficiency provided in=20
    [WS8], the web service framework proposed for SPEECHSC and=20
    described in [WS1] relies indeed on known efficient techniques:=20
    - Asynchronous pre-programming of the engines as web services to=20
    reduce exchanges and avoid racing conditions=20
    - Possibility to piggy back on response message if transported on=20
    optimized protocols like SIP or BEEP. =20
    - state caching in the engines that are considered as stand-alone,=20
    pre-packaged and pre-programmed engines.=20
    - etc=85=20
    =20
=0A=
           7.2.5. Explicit invocation of services [5.5]=20
    T: Web service is typically used in a client-server environment.=20
    Solutions exist for peer to peer (service to service) etc=85 =20
    =20
    Web services have been deigned to support clients and servers at=20
    least one of which is operating directly on behalf of the user=20
    requesting the service.=20
    =20
    In addition, work on-going at OMA and JCP addresses some of these=20
    issues in mobile environment with the introduction of possible web=20
    service gateways. =20
    =20
=0A=
           7.2.6. Server Location and Load Balancing [5.6]=20
    T: Web services are widely developed for e-business applications.=20
    Numerous tools and mechanisms have been provided for service=20
    discovery ad advertisement. In addition, numerous offerings provide=20
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 12] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
    routing and load balancing capabilities as part of the web=20
    application server used to deploy the web service. =20
    =20
    Note that web services do not specify server location or load=20
    balancing; but they are deployed on systems that provide such=20
    functionalities. As web services are expected to be widely used in=20
    the future and central to most e-business offerings, it is to=20
    expect that such tools will become even more pervasive and=20
    efficient.=20
    =20
=0A=
           7.2.7. Simultaneous services [5.7]=20
    Web services allow control (interface) and composition of web=20
    services at will (e.g. WSFL).=20
=0A=
           7.2.8. Multiple media sessions [5.8]=20
    T: The framework proposed does not pre-supposes how many ports or=20
    streams are associated to the engine. Different inbound and=20
    outbound can be used at will=20
    =20
=0A=
         7.3. Analysis of Duplexing and Parallel Operation Requirements=20
=0A=
           7.3.1. Duplexing and Parallel Operation Requirements [9]=20
    T: As explained, web services allow control (interface) and=20
    composition of web services at will (e.g. WSFL).  Also, it does not=20
    pre-supposes how many ports or streams are associated to the=20
    engine. Different inbound and outbound can be used at will; in full=20
    duplex or even between engines as supported by WSFL [WS4] and WSXl=20
    [WS7].=20
=0A=
           7.3.2. Full Duplex operation [9.1.1]=20
    T:=20
=0A=
           7.3.3. Multiple services in parallel [9.1.2]=20
    T:=20
=0A=
           7.3.4. Combination of services=20
    T: As explained, web services allow control (interface) and=20
    composition of web services at will (e.g. WSFL) into complex=20
    parallel, serial or coordinated combinations as supported by WSFL=20
    [WS4] and WSXl [WS7].=20
=0A=
         7.4. Analysis of additional considerations (non-normative)=20
    The framework proposed supports:=20
    - Use of SDP to describe sessions and streams for the streamed=20
    channels =20
    - Time stamps could be transmitted as part of the control messages=20
    at the web service level or in band (e.g. with dynamic payload=20
    switch or within the payload).=20
    - The framework is compatible with any encoding scheme. This is=20
    illustrated by the work on SRF (Speech Recognition Framework)=20
    driven at 3GPP that supports conventional and DSR optimized codecs=20
    and possible exchange of speech meta-information (e.g. data that=20
    may be required to facilitate and enhance the server-side=20
    processing of the input speech and facilitate the dialog management=20
    in an automated voice service. These may include keypad events=20
    over-riding spoken input, notification that the UE is in hands-free=20
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 13] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
    mode, client-side collected information (speech/no-speech, barge-
    in), etc=85.).=20
    - SOAP over SIP or BEEP to support the framework described in=20
    section 1 can also support VCR controls.=20
    - real-time messaging between engine and control is supported=20
    within the framework (e.g. via SOAP or XML events). The framework=20
    also support exchange between engines (same process; see also WSXL=20
    [WS7]).=20
    =20
    Although non-normative, the web service framework described=20
    probably deserves marks of P+ to T.=20
 =20
=0A=
         7.5. Analysis of Security considerations=20
=0A=
           7.5.1. Security Considerations [11]=20
    Web services are evolving to provide security, authentication,=20
    encryption, trust management and privacy . Details can be found for=20
    example in [WS9] and explained in [WS10]. This is now an OASIS=20
    activity [WS11].=20
    =20
    This framework would enable SPEECHSC to employ the security=20
    mechanism provided bu WS-Security for the remote control aspects.=20
    Exchanged media can rely on security mechanism at the transport /=20
    streaming level.=20
    =20
    The web service framework described probably deserves marks of P+=20
    to T.=20
=0A=
         7.6. Interaction Model=20
    TBC : TO BE COMPLETED : Analysis of the interaction model of the=20
    protocol during the =91data=92 phase (ie after session =
establishment)=20
    and its suitability for speechsc.=20
    =20
    =20
      8. Resource Control : =93MRCP=94 Complience Evaluation (Sarvi=20
         Shanmugham)=20
=0A=
         8.1. General =20
=0A=
           8.1.1. MRCP Framework and General Applicability=20
    =20
    The overall MRCP framework, the components involved and their=20
    distribution and relationship to each other meet the framework=20
    specified by SPEECHSC. The primary advantage of MRCP is that it is=20
    a text based protocol designed to meet most of the requirements of=20
    SPEECHSC pertaining to speech recognition and Text to speech.=20
    Though Speaker Recognition (SR) and Speaker Verification (SV) are=20
    not supported in its current form, MRCP was explicitly designed to=20
    be extendable for such needs. The core MRCP definition only deals=20
    with the control of the ASR or TTS resource and the commands and=20
    responses needed to achieve it.=20
 =20
    There are multiple interoperable implementations of MRCP and hence=20
    is a proven technology. It leverages existing W3C XML standards for=20
    exchange of data between the client and the server resource. For=20
    Example, its uses the W3C XML grammar format (GRXML) along with W3C=20
    semantic attachments and Natural Language Semantic Markup Language=20
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 14] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
    to exchange data with speech recognition resource. The W3C Speech=20
    Markup Language is used when dealing with Text to speech engines.=20
     =20
    It was designed to work as a tunneled protocol, over RTSP or SIP.=20
    Hence it depends on the carrier protocol to establish a control and=20
    a media path between the client and the ASR or TTS server resource.=20
    Hence it gets most of the security and media pipe management=20
    operations for free. Once these are established, MRCP commands and=20
    responses are tunneled over, controlling the ASR or TTS resource on=20
    the server. =20
=0A=
           8.1.2. MRCP can be evolved=20
    =20
    Though MRCP directly meets many of the needs of SPEECHSC. The=20
    notion that it is a tunneled protocol disallows its independent=20
    operation. Further more the tunneled aspect is also a less=20
    efficient protocol design. =20
    =20
    But these can be addressed and the core MRCP messages can be=20
    evolved to either become standalone protocol by itself or=20
    extensions to an existing protocol such as SIP or RTSP.  To make=20
    this a standalone protocol and allow MRCP to operate by itself, new=20
    session and media management messages need to be defined to allow=20
    it to operate independently. To evolve MRCP as extensions to SIP or=20
    RTSP would also be relatively simple since it is also a text based=20
    protocol with message format and headers very similar to them.  In=20
    this protocol evaluation, the compliance evaluates MRCP from the=20
    perspective of evolution in one of these forms.=20
    =20
    The following sub-sections compare each individual requirement=20
    relating to resource management against the protocol.=20
=0A=
         8.2. Analysis of TTS requirements=20
=0A=
           8.2.1. Requesting Text Playback [6.1]=20
    T: MRCP has the SPEAK method for the client to request the TTS=20
    resource to playback text as an audio stream.=20
=0A=
           8.2.2. Text Formats [6.2]=20
    T: When the client requests the TTS resource to playback a text=20
    stream it can provide the content in the following formats and=20
    through the following mechanism.=20
    =20
       1. Plain text=20
       2. W3C XML based Speech Markup Language (SSML)=20
       3. This content to be spoken can be provided by value directly=20
          through the control path. =20
       4. It also supports passing the content by reference. This is=20
          achieved having an audio tag inside the SSML markup text.=20
          This URL is then fetched and played on the RTP stream in=20
          sequence with the rest of the text according to the SSML=20
          specification.=20
    When the client sends plain text, SSML or another format of speech=20
    text the content is coded as a mime-type. Hence the server knows=20
    what format the speech content is coded in, and does not have to=20
    figure it out from the content.=20
=0A=
=0A=
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 15] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
           8.2.3. Plain text [6.2.1]=20
    T: see above=20
=0A=
           8.2.4. SSML [6.2.2]=20
    T: see above=20
=0A=
           8.2.5. Text in Control Channel [6.2.3]=20
    T : see above=20
=0A=
           8.2.6. Document Type Indication [6.2.4]=20
    T: see above=20
=0A=
           8.2.7. Control Channel [6.3]=20
    T: In MRCP, this Reset-Audio-Channel header defined for the ASR=20
    resource allows the recognizer to re-initialize the audio=20
    characteristics that it has learnt till then. This allows a=20
    recognizer resource to be used for multiple recognition sessions.=20
    It can be used for short single utterance recognitions as well.=20
    This is by applying the Reset-Audio-Channel header to every=20
    recognition. I suspect the performance may not be as good, due to=20
    the lack of line characteristics, but this is a recognizer issue.=20
=0A=
           8.2.8. Playback Controls [6.4]=20
    T: MRCP supports the CONTROL method with the Jump-Target header can=20
    used to achieve, jumping in time or to an exact or relative=20
    location. It supports jumping in paragraphs, sentences, words and=20
    to specific markers that may be embedded in the speech content. The=20
    CONTROL method can be used with the Voice and Prosody parameters,=20
    derived from SSML, and can address the speed of speech or=20
    increasing/decreasing the volume. It also supports the PAUSE/RESUME=20
    methods to pause or resume a current SPEAK request.=20
=0A=
           8.2.9. Session Parameters [6.5]=20
    T: As mentioned the previous section, MRCP supports voice and=20
    prosody parameters which are directly derived from the W3C SSML=20
    specification. These headers can be sent using the SET-PARAMS=20
    method and applied as a default for the entire session. They can=20
    also be applied in SPEAK requests to apply per usage or in the=20
    CONTROL message to change the parameters of an active SPEAK=20
    request.=20
=0A=
           8.2.10. Speech Markers [6.6]=20
    T: Specifying speech markers in the content is supported through=20
    SSML. The CONTROL message can then be used to jump to specific=20
    marker points in the text. Also, when the TTS resource reaches=20
    specific markers in the text, the server would generate the SPEECH-
    MARKER method to the client.=20
=0A=
         8.3. Analysis of ASR requirements=20
=0A=
           8.3.1. Requesting Automatic Speech Recognition [7.1]=20
    T: The client uses the RECOGNIZE method in MRCP to request the=20
    recognition resource to process the audio stream in the pipe. The=20
    RECOGNIZE method also specifies parameters and grammars the=20
    recognizer should match against.=20
=0A=
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 16] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
           8.3.2. XML [7.2]=20
    T: Similar to the TTS resource in MRCP, ASR also uses XML data to=20
    exchange information between the client and the recognition=20
    resource. It supports the W3C GRXML to pass grammars from the=20
    client to the server. When the server is done recognizing, it uses=20
    the W3C Natural Language Semantic Markup Language (NLSML) to pass=20
    the results back to the client. It supports other grammar formats=20
    as well, as long as the server allows it. This is possible since,=20
    it uses mime-types to package this data and hence the format type=20
    is specified.=20
=0A=
           8.3.3. Grammar Specification [7.3.1]=20
    P+: MRCP supports specifying the grammar both by value and by=20
    reference. The RECOGNIZE method can carry with it grammar content=20
    and/or a URI referring to the grammar content. Since MRCP supports=20
    referring a grammar, the referred grammar could be located on the=20
    server itself. With respect to sharing of grammars, the grammars=20
    defined/compiled through the DEFINE-GRAMMAR primitive are not=20
    sharable across sessions on the same server. This needs to be=20
    addressed to meet this set of requirements in full.=20
=0A=
           8.3.4. Explicit Indication of Grammar Format [7.3.2]=20
    P+: see above=20
=0A=
           8.3.5. Grammar Sharing [7.3.3]=20
    TBD=20
=0A=
           8.3.6. Session Parameters [7.4]=20
    T: This requirement as defined is already fully met since MRCP is=20
    the referred standard for compliance.=20
=0A=
           8.3.7. Input Capture [7.5]=20
    T: This is achieved by setting the Waveform-url header in the=20
    RECOGNIZE method. This tells the server to record the audio of the=20
    recognition and will return a URI to the client in the completion=20
    event, which can be used to retrieve or play back the audio.=20
=0A=
         8.4. Analysis of Speaker Identification and Verification=20
            Requirements=20
=0A=
           8.4.1. Requesting SI/SV [8.1]=20
    F: not supported=20
=0A=
           8.4.2. Identifiers for SI/SV [8.2]=20
    F: not supported=20
=0A=
           8.4.3. State for multiple utterances [8.3]=20
    F: not supported=20
=0A=
           8.4.4. Input Capture [8.4]=20
    F: not supported=20
=0A=
           8.4.5. SI/SV functional extensibility [8.5]=20
    F: not supported=20
    =20
=0A=
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 17] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
      9. Resource Control : =93RTSP=94 Complience Evaluation (Brian =
Wyld)=20
=0A=
         9.1. General Introduction=20
    RTSP is an existing protocol, orientated towards audio playback and=20
    recording. As such, it has support for RTP session control, with=20
    SDP used for session description, and a message set allowing=20
    operation as a player/recorder with audio =93VCR=94 controls. This=20
    comparison only addresses the existing resource control elements=20
    here and their applicability to the speechsc requirements.=20
     =20
    The current PLAY state machine is exactly as required for TTS=20
    operation. Although by analogy RECORD could initiate an ASR=20
    session, with headers giving the grammer source or references, =
it=92s=20
    state machine is not nearly as compatible, and not at all for=20
    SV/SI. =20
=0A=
         9.2. Analysis of TTS requirements=20
=0A=
           9.2.1. Requesting Text Playback [6.1]=20
    P+: the RTSP PLAY message semantics would require minor extensions=20
=0A=
           9.2.2. Text Formats [6.2]=20
    P+: Text can be defined as all text types. =20
=0A=
           9.2.3. Plain text [6.2.1]=20
    T: Plain text may be carried directly in the message payload.=20
=0A=
           9.2.4. SSML [6.2.2]=20
    T: Text may be in any format.=20
=0A=
           9.2.5. Text in Control Channel [6.2.3]=20
    T: Text may be attached to the control messages.=20
=0A=
           9.2.6. Document Type Indication [6.2.4]=20
    T : Via the Content-Type header=20
=0A=
           9.2.7. Control Channel [6.3]=20
    T: RTSP sessions may use a private or shared TCP connection.=20
=0A=
           9.2.8. Playback Controls [6.4]=20
    T: RTSP defines playback control messages and a state machine.=20
=0A=
           9.2.9. Session Parameters [6.5]=20
    T: RTSP defines operations for session parameter control.=20
=0A=
           9.2.10. Speech Markers [6.6]=20
    P+: Markers may be inserted in the text, but to provide the=20
    required asynchronous events when a marker is synthesized will=20
    require use specific ANNOUNCE type messages for server->client=20
    notification.=20
=0A=
         9.3. Analysis of ASR requirements=20
=0A=
           9.3.1. Requesting Automatic Speech Recognition [7.1]=20
    P: The RECORD message and semantics could be used but would require=20
    extensions (stretching the current semantic quite a lot)=20
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 18] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
           9.3.2. XML [7.2]=20
    P+: Text can be defined as all text types.=20
=0A=
           9.3.3. Grammar Specification [7.3.1]=20
    P+: Text can be defined as all text types.=20
=0A=
           9.3.4. Explicit Indication of Grammar Format [7.3.2]=20
    T : Via the Content-Type headers=20
=0A=
           9.3.5. Grammar Sharing [7.3.3]=20
    F: TBD=20
=0A=
           9.3.6. Session Parameters [7.4]=20
    T: RTSP defines operations for session parameter control.=20
=0A=
           9.3.7. Input Capture [7.5]=20
    P+: would require addition of a header to the initiation message.=20
=0A=
         9.4. Analysis of Speaker Identification and Verification=20
            Requirements=20
=0A=
           9.4.1. Requesting SI/SV [8.1]=20
    F: not supported=20
=0A=
           9.4.2. Identifiers for SI/SV [8.2]=20
    F: not supported=20
=0A=
           9.4.3. State for multiple utterances [8.3]=20
    F: not supported=20
=0A=
           9.4.4. Input Capture [8.4]=20
    F: not supported=20
=0A=
           9.4.5. SI/SV functional extensibility [8.5]=20
    F: not supported=20
    =20
        =20
      10.  Security Considerations =20
     =20
    Security considerations for the SPEECHSC protocol are covered by=20
    the comparison against the specific Security requirements in the=20
    SPEECHSC requirements document [1]. =20
        =20
      11.  References =20
    [1] Oran, D., "Requirements for Distributed Control of ASR, SI/SV=20
    and TTS Resources", draft-ietf-speechsc-reqts-04, June 6, 2003,=20
    work in progress.=20
    =20
    [2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.=20
    Peterson, R. Sparks, M. Handley, E.Schooler, SIP: Session=20
    Initiation Protocol, RFC3265, June 2002. (Obsoletes RFC2543)=20
    =20
    [WS1] W3C Web Services, http://www.w3c.org/2002/ws/=20
    [WS2] Simple Object Access Protocol (SOAP)=20
    http://www.w3c.org/2002/ws/=20
    [WS3] Web Services Description Language (WSDL 1.1), W3C Note 15=20
    March =20
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 19] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
        2001, http://www.w3.org/TR/wsdl.=20
    [WS4] Leymann, F., Web Service Flow Language, WSFL 1.0, May 2001, =20
         http://www-
    4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf=20
    [WS5] UDDI, http://www.uddi.org/specification.html =20
    [WS6] W3C Voice Activity, http://www.w3c.org/Voice/ =20
    [WS7] WSXL - Web Service eXperience Language submitted to OASIS=20
    WSIA =20
          and WSRP - WSXL - Web Service eXperience Language submitted=20
    to =20
           OASIS WSIA and WSRP=20
    [WS8] Requirements for Distributed Control of ASR, SI/SV and TTS=20
    Resources, =20
    draft-ietf-speechsc-reqts-01.txt=20
    [WS9] Security in a Web Services World: A Proposed Architecture and=20
    Roadmap, =20
    April 7, 2002, Version 1.0, http://www.verisign.com/wss/wss.pdf=20
    [WS10] Kapil Apshankar, WS-Security, Security for Web Services,=20
    http://www.webservicesarchitect.com/content/articles/apshankar04.as
    p=20
    [WS11] OASIS Web Services Security TC, http://www.oasis-
    open.org/committees/wss/=20
    =20
 Author=92s Address=20
        =20
    Brian Wyld =20
    Eloquant SA=20
    ZA Malvaisin                   Phone:  +33 476 77 46 92 =20
    Le Versoud, France             Email:  brian.wyld@eloquant.com =20
     =20
     =20
 Full Copyright Statement=20
    =20
    Copyright (C) The Internet Society (2002).  All Rights Reserved.=20
       =20
    This document and translations of it may be copied and furnished to=20
    others, and derivative works that comment on or otherwise explain=20
    it=20
    or assist in its implementation may be prepared, copied, published=20
    and distributed, in whole or in part, without restriction of any=20
    kind, provided that the above copyright notice and this paragraph=20
    are included on all such copies and derivative works.  However,=20
    this=20
    document itself may not be modified in any way, such as by removing=20
    the copyright notice or references to the Internet Society or other=20
    Internet organizations, except as needed for the purpose of=20
    developing Internet standards in which case the procedures for=20
    copyrights defined in the Internet Standards process must be=20
    followed, or as required to translate it into languages other than=20
    English.  The limited permissions granted above are perpetual and=20
    will not be revoked by the Internet Society or its successors or=20
    assigns.  This document and the information contained=20
    herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND=20
    THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,=20
    EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT=20
    THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR=20
    ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A=20
    PARTICULAR PURPOSE."=20
 =20
    =20
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 20] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
    =20
    =20
    =20
    =20
 =20
    =20
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 21] =
=0C
------=_NextPart_000_0070_01C33D03.574A9E10--


_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From exim@www1.ietf.org  Fri Jun 27 19:47:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26568
	for ; Fri, 27 Jun 2003 19:47:18 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5RNknb31347
	for speechsc-archive@odin.ietf.org; Fri, 27 Jun 2003 19:46:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19W2vZ-00089W-22
	for speechsc-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 19:46:49 -0400
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26531
	for ; Fri, 27 Jun 2003 19:46:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19W2uo-00084e-9h; Fri, 27 Jun 2003 19:46:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19W0g7-0003MV-JD
	for speechsc@optimus.ietf.org; Fri, 27 Jun 2003 17:23:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21005
	for ; Fri, 27 Jun 2003 17:22:25 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19W0fq-0006VI-00
	for speechsc@ietf.org; Fri, 27 Jun 2003 17:22:26 -0400
Received: from smtp-105-friday.noc.nerim.net ([62.4.17.105] helo=mallaury.noc.nerim.net)
	by ietf-mx with esmtp (Exim 4.12)
	id 19W0fd-0006V3-00
	for speechsc@ietf.org; Fri, 27 Jun 2003 17:22:14 -0400
Received: from weasel.hq.eloquant.com (styx.eloquant.com [80.65.227.37])
	by mallaury.noc.nerim.net (Postfix) with ESMTP
	id 428C862D13; Fri, 27 Jun 2003 23:21:34 +0200 (CEST)
Received: from polo (atalante.hq.eloquant.com [192.168.0.11])
	by weasel.hq.eloquant.com (Postfix) with SMTP
	id 874143B6CA; Fri, 27 Jun 2003 17:31:53 -0400 (EDT)
Reply-To: 
From: "Brian Wyld" 
To: "Rajiv Dharmadhikari" ,
        "Sarvi Shanmugham" 
Cc: "Eric Burger" , 
Subject: RE: [Speechsc] Protocol proposal for SPEECHSC
Date: Fri, 27 Jun 2003 23:17:03 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_006B_01C33D02.3838C7A0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <52F49B5A0E5B0F4781C9C8F7159409E4839536@aster.us.int.genesyslab.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	

This is a multi-part message in MIME format.

------=_NextPart_000_006B_01C33D02.3838C7A0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_006C_01C33D02.3838C7A0"


------=_NextPart_001_006C_01C33D02.3838C7A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all,

Attached you have an updated draft that I propose to submit as 02 for the
next IETF. Essentially its the re-worked doc, with a very short
conclusion.....

Major missing part is the web services vs classic session control section=
 we
agreed to add in the last conf call.....

Brian



  -----Message d'origine-----
  De : Rajiv Dharmadhikari [mailto:rajivdh@genesyslab.com]
  Envoy=E9 : Friday, June 20, 2003 03:23
  =C0 : brian.wyld@eloquant.com; Sarvi Shanmugham
  Cc : Eric Burger; speechsc@ietf.org
  Objet : RE: [Speechsc] Protocol proposal for SPEECHSC


  Brian,

  Here is the updated protocol comparison document with my updates to the
SIP section. Session control and resource control sections have been upda=
ted
as per last conference call.

  Let me know if any changes are needed.

  -Rajiv
    -----Original Message-----
    From: Brian Wyld [mailto:brian.wyld@eloquant.com]
    Sent: Thursday, June 19, 2003 1:58 AM
    To: Sarvi Shanmugham
    Cc: Eric Burger; speechsc@ietf.org
    Subject: RE: [Speechsc] Protocol proposal for SPEECHSC


    Hi Sarvi,

    No, I think the MRCP section is ok.

    Eric, I have no other updates yet for the protocol comparison
document....

    Please note I am on holiday (real holiday, no computers) 28th June un=
til
15th July so won't be able to do any updates after 28th June.

    And finally, I'm afraid I won't be at IETF Vienna (budget, time
constraints). I hope you manage to get enough folk to make progress on
Sarvi's proposal....

    Brian


      -----Message d'origine-----
      De : Sarvi Shanmugham [mailto:sarvi@cisco.com]
      Envoy=E9 : Wednesday, June 11, 2003 00:12
      =C0 : brian.wyld@eloquant.com
      Cc : Eric Burger; speechsc@ietf.org
      Objet : Re: [Speechsc] Protocol proposal for SPEECHSC


      Hi Brian,
                  Does my section need updation(MRCP evalutation), if so =
let
me know and I will get back o you with the edits by the end of next week.

      Sarvi

      Brian Wyld wrote:

Ok, if I have time I will munge something thru a web services toolset and
produce an alternative proposal based on WS.....

Then again, maybe not.

To be frank, if you all want SIP, and I don't see many other viewpoints
here, then I'll go with your experience. As long as we can model all the
different session viewpoints (as already discussed here) that are needed =
for
usage of the resources then that's fine with me. (pointers to a good open
source java SIP stack gratefully received....)

So, is anyone going to update their sections for the protocol comparison
document before the 30th June or not?

Brian (another hapless victem crushed by the SIP juggernaught)

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

  -----Message d'origine-----
De : Eric Burger [mailto:eburger@snowshore.com]
Envoy=E9 : Tuesday, June 10, 2003 21:30
=C0 : brian.wyld@eloquant.com; speechsc@ietf.org
Objet : RE: [Speechsc] Protocol proposal for SPEECHSC


    -----Original Message----- From: Brian Wyld
      [mailto:brian.wyld@eloquant.com]
    Sent: Tue, June 10, 2003 12:16 PM
      [snip]

    Sorry, but I still think that it's easier to specify the media setup
specifically (maybe by cut-n-paste from RTSP) rather than
suck in the entire
SIP protocol.
      I would be very hesitant to create yet another "looks like
SIP/RTSP, smells like SIP/RTSP, operates like SIP/RTSP, but has a
different life and future than SIP/RTSP."

I'd much rather leverage the 974 engineer years of work over the
last 6 years put in to SIP than spend 3 engineer years explaining
what is the same and different in a new protocol.  Moreover, I
would not want to find myself wishing I had 500 engineer years of
resources to catch up when something useful gets introduced into
SIP/RTSP that I might want.

SIP is actually pretty good when dealing with small, embedded
implementations.  Most everything is an extension
("Accept/Allow").  You don't even need the list of extensions to
say, "I don't know what you are talking about."  Thus an
SPEECHSC-only implementation can be pretty light.  It is what we
do in the media server world, for example.

    Maybe we should instead specify the use of RTSP as the media
setup agent, as
most folks with MRCP experience will have such an
implementation already and
it is known to serve the needs of mrcp......
      I can go either way.  At this point one could submit a RTSP-based
SPEECHSC protocol proposal, similar to Sarvi's.  Alternately, one
could submit a "these are the reasons RTSP
works/interoperates/easier-to-implement than SIP" draft.

Do be aware that you have until 0900 USA-ET to submit a -00 draft.

    A+

Brian

PS> I note that to achieve an operation MRCP server today, it
is neccessary
to implement very little of RTSP and none of the media state
machinary (no
play, record etc). In fact, only SETUP and TEARDOWN are
really required, and
the 'tunnel message' ANNOUNCE......
      My point above, exactly...



_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



------=_NextPart_001_006C_01C33D02.3838C7A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Hi=20
all,


 


Attached you have an updated draft that I propose to submit as =
02 for the=20
next IETF. Essentially its the re-worked doc, with a very short =
conclusion.....=20



 


Major=20
missing part is the web services vs classic session control section we =
agreed to=20
add in the last conf call.....


 


Brian


 


 



  
-----Message d'origine-----
De : Rajiv =
Dharmadhikari=20
  [mailto:rajivdh@genesyslab.com]
Envoy=E9 : Friday, June =
20, 2003=20
  03:23
=C0 : brian.wyld@eloquant.com; Sarvi=20
  Shanmugham
Cc : Eric Burger;=20
  speechsc@ietf.org
Objet : RE: [Speechsc] Protocol =
proposal for=20
  SPEECHSC


  
Brian,

  
 

  
Here=20
  is the updated protocol comparison document with my updates to the SIP =

  section. Session control and resource control sections have been =
updated as=20
  per last conference call.

  
 

  
Let=20
  me know if any changes are needed.

  
 

  
-Rajiv

  

    
-----Original Message-----
From: Brian Wyld=20
    [mailto:brian.wyld@eloquant.com]
Sent: Thursday, June 19, =
2003=20
    1:58 AM
To: Sarvi Shanmugham
Cc: Eric Burger;=20
    speechsc@ietf.org
Subject: RE: [Speechsc] Protocol =
proposal for=20
    SPEECHSC


    
Hi=20
    Sarvi,

    
 

    
No, I think the MRCP section =
is ok.

    
 

    
Eric, I have no other updates yet for the protocol =
comparison=20
    document....

    
 

    
Please note I am on holiday (real holiday, no =
computers) 28th=20
    June until 15th July so won't be able to do any =
updates after=20
    28th June.

    
 

    
And finally, I'm afraid I won't be at IETF Vienna (budget, =
time=20
    constraints). I hope you manage to get enough folk to make progress =
on=20
    Sarvi's proposal....

    
 

    
Brian

    
 

    

    
      
-----Message d'origine-----
De : Sarvi =
Shanmugham=20
      [mailto:sarvi@cisco.com]
Envoy=E9 : Wednesday, June =
11, 2003=20
      00:12
=C0 : =
brian.wyld@eloquant.com
Cc : Eric=20
      Burger; speechsc@ietf.org
Objet : Re: [Speechsc] =
Protocol=20
      proposal for SPEECHSC

Hi Brian,
  =
 =20
              Does my section need updation(MRCP=20
      evalutation), if so let me know and I will get back o you with the =
edits=20
      by the end of next week.

Sarvi

Brian Wyld wrote:

      
Ok, if I have time I will munge =
something thru a web services toolset and
produce an alternative proposal based on WS.....

Then again, maybe not.

To be frank, if you all want SIP, and I don't see many other viewpoints
here, then I'll go with your experience. As long as we can model all the
different session viewpoints (as already discussed here) that are needed =
for
usage of the resources then that's fine with me. (pointers to a good =
open
source java SIP stack gratefully received....)

So, is anyone going to update their sections for the protocol comparison
document before the 30th June or not?

Brian (another hapless victem crushed by the SIP juggernaught)

[Brian Wyld] [brian.wyld@eloquant.com]
[Directeur General R&D]
[Eloquant SA] [+33 476 77 46 92] [www.eloquant.com]
[advanced solutions for telecoms and IT services]

  

        
-----Message =
d'origine-----
De : Eric Burger [mailto:eburger@snowshore.com]
Envoy=E9 : Tuesday, June 10, 2003 21:30
=C0 : brian.wyld@eloquant.com; speechsc@ietf.org
Objet : RE: [Speechsc] Protocol proposal for SPEECHSC


    

          
-----Original =
Message----- From: Brian Wyld
      
[mailto:brian.wyld@eloquant.com]
    

          
Sent: Tue, June 10, =
2003 12:16 PM
      
[snip]

    

          
Sorry, but I still =
think that it's easier to specify the media setup
specifically (maybe by cut-n-paste from RTSP) rather than
suck in the entire
SIP protocol.
      
I would be very hesitant to =
create yet another "looks like
SIP/RTSP, smells like SIP/RTSP, operates like SIP/RTSP, but has a
different life and future than SIP/RTSP."

I'd much rather leverage the 974 engineer years of work over the
last 6 years put in to SIP than spend 3 engineer years explaining
what is the same and different in a new protocol.  Moreover, I
would not want to find myself wishing I had 500 engineer years of
resources to catch up when something useful gets introduced into
SIP/RTSP that I might want.

SIP is actually pretty good when dealing with small, embedded
implementations.  Most everything is an extension
("Accept/Allow").  You don't even need the list of extensions to
say, "I don't know what you are talking about."  Thus an
SPEECHSC-only implementation can be pretty light.  It is what we
do in the media server world, for example.

    

          
Maybe we should =
instead specify the use of RTSP as the media
setup agent, as
most folks with MRCP experience will have such an
implementation already and
it is known to serve the needs of mrcp......
      
I can go either way.  At this =
point one could submit a RTSP-based
SPEECHSC protocol proposal, similar to Sarvi's.  Alternately, one
could submit a "these are the reasons RTSP
works/interoperates/easier-to-implement than SIP" draft.

Do be aware that you have until 0900 USA-ET to submit a -00 draft.

    

          
A+

Brian

PS> I note that to achieve an operation MRCP server today, it
is neccessary
to implement very little of RTSP and none of the media state
machinary (no
play, record etc). In fact, only SETUP and TEARDOWN are
really required, and
the 'tunnel message' ANNOUNCE......
      
My point above, exactly...


    

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.iet=
f.org/mailman/listinfo/speechsc

  =




------=_NextPart_001_006C_01C33D02.3838C7A0--

------=_NextPart_000_006B_01C33D02.3838C7A0
Content-Type: text/plain;
	name="draft-ietf-speechsc-protocol-eval-02.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-speechsc-protocol-eval-02.txt"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable


=0A=
 Internet Draft                                                 B. Wyld=20
 Document: draft-speechsc-protocol-eval.txt                      Editor=20
 Expires: October 2003                                         Eloquant=20
 Version 02                                                   June 2003=20
 =20
                        SPEECHSC Protocol Evaluation=20
 =20
 Status of this Memo =20
    =20
    This document is an Internet-Draft and is in full conformance with=20
    all provisions of Section 10 of RFC2026. =20
        =20
    Internet-Drafts are working documents of the Internet Engineering=20
    Task Force (IETF), its areas, and its working groups.  Note that=20
    other groups may also distribute working documents as Internet-
    Drafts. =20
        =20
    Internet-Drafts are draft documents valid for a maximum of six=20
    months and may be updated, replaced, or obsoleted by other=20
    documents at any time. It is inappropriate to use Internet-Drafts=20
    as reference material or to cite them other than as "work in=20
    progress." =20
        =20
    The list of current Internet-Drafts can be accessed at =20
         http://www.ietf.org/ietf/1id-abstracts.txt =20
    The list of Internet-Draft Shadow Directories can be accessed at =20
         http://www.ietf.org/shadow.html. =20
        =20
 Abstract =20
    =20
    This document is the Protocol Evaluation Document for the SPEECHSC=20
    Working Group.  Section 3 provides the summary of the  individual=20
    protocol comparisons (in the sections 4-N following) against the=20
    SPEECHSC requirements [1].=20
  =20
 Table of Contents=20
    =20
    1.   Overview...................................................2=20
    2.   Protocol Proposals.........................................3=20
    3.   Protocol Evaluation Summary and Conclusion.................3=20
    4.   Core Protocol Section : Web Services vs Session Control=20
    protocols (Jerry Carter).........................................3=20
    5.   Session Control : =93Beep=94 Compliance Evaluation (Jerry =
Carter)
         3=20
       5.1.   General notes:........................................3=20
       5.2.   Analysis of General Requirements......................4=20
       5.3.   Analysis of Duplexing and Parallel Operation=20
       Requirements..................................................5=20
       5.4.   Analysis of additional considerations (non-normative).5=20
       5.5.   Analysis of Security considerations...................5=20
       5.6.   Interaction Model.....................................5=20
    6.   Session Control : =93SIP=94 Complience Evaluation (Rajiv=20
    Dharmadhikari)...................................................5=20
       6.1.   Introduction..........................................5=20
       6.2.   Analysis of General Requirements......................6=20
       6.3.   Analysis of Duplexing and Parallel Operation=20
       Requirements..................................................7=20
       6.4.   Analysis of additional considerations (non-normative).7=20
       6.5.   Analysis of Security considerations...................7=20
       6.6.   Other Criteria........................................7=20
       6.7.   Interaction Model.....................................8=20
 =20
 =20
 Wyld                    Expires =96 October 2003               [Page 1] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
    7.   Session Control : =93RTSP=94 Complience Evaluation (Brian =
Wyld)9=20
       7.1.   General Introduction..................................9=20
       7.2.   Analysis of General Requirements......................9=20
       7.3.   Analysis of Duplexing and Parallel Operation=20
       Requirements..................................................9=20
       7.4.   Analysis of additional considerations (non-normative)10=20
       7.5.   Analysis of Security considerations..................10=20
       7.6.   Interaction Model....................................10=20
    8.   Session Control : =93Web Services=94 Complience Evaluation=20
    (Stephane H. Maes)..............................................10=20
       8.1.   General Notes:.......................................10=20
       8.2.   Analysis of General Requirements.....................11=20
       8.3.   Analysis of Duplexing and Parallel Operation=20
       Requirements.................................................13=20
       8.4.   Analysis of additional considerations (non-normative)14=20
       8.5.   Analysis of Security considerations..................14=20
       8.6.   Interaction Model....................................14=20
    9.   Resource Control : =93MRCP=94 Complience Evaluation (Sarvi=20
    Shanmugham).....................................................14=20
       9.1.   General..............................................14=20
       9.2.   Analysis of TTS requirements.........................15=20
       9.3.   Analysis of ASR requirements.........................17=20
       9.4.   Analysis of Speaker Identification and Verification=20
       Requirements.................................................17=20
    10.  Resource Control : =93RTSP=94 Complience Evaluation (Brian =
Wyld)
         18=20
       10.1.  General Introduction.................................18=20
       10.2.  Analysis of TTS requirements.........................18=20
       10.3.  Analysis of ASR requirements.........................19=20
       10.4.  Analysis of Speaker Identification and Verification=20
       Requirements.................................................19=20
    11.  Security Considerations...................................19=20
    12.  References................................................20=20
       =20
      1. Overview =20
        =20
    This document provides the template for the content for the=20
    SPEECHSC Protocol Evaluation document.   =20
        =20
    This section will contain an overview of the process.=20
    =20
    Section 2 contains a list of the proposed protocols submitted to=20
    WG. These protocols are in fact of 3 different natures:=20
       - a generic service/resource access system (Web Services)=20
       - =91classic=92 session control protocols for media channels =
(BEEP,=20
          SIP, RTSP), of which RTSP also provides resource control.=20
       - a specific ASR/TTS resource control message set designed to=20
          be tunneled in a session control protocol (MRCP)=20
 =20
    Section 3 provides a conclusion of the evaluations of the proposed=20
    protocols against the Requirements and framework, and recommends a=20
    direction for the creation of the speechsc protocol. =20
    =20
    Section 4 contains a comparison of the approaches of the classic=20
    session control type protocols vs a web services style with respect=20
    to their suitability for the basic control protocol.=20
    =20
    Sections 5-8 provide the individual protocol evaluations for the=20
    protocols providing session control against the SPEECHSC=20
    requirements [1] that relate to these needs.=20
 =20
 =20
 Wyld                    Expires =96 October 2003               [Page 2] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
    =20
    Sections 9 and 10 provide individual protocol evaluations for=20
    protocols providing resource control against the SPEECHSC resource=20
    control requirements.=20
        =20
      2. Protocol Proposals=20
 =20
    This section contains a list of the existing protocols submitted to=20
    the SPEECHSC WG for consideration by the deadline. =20
          1. BEEP=20
          2. SIP=20
          3. RTSP=20
          4. MRCP (initial submission)=20
          5. Web Services=20
    =20
    =20
    Each protocol section contains a review of the protocol=92s level of =

    compliance to each of the SPEECHSC Requirements [1] as derived from=20
    the proposed protocol documents. The following key will be used to=20
    identify the level of compliancy of each of the individual=20
    protocols:=20
    =20
    T =3D Total Complience.  Meets the requirement fully.=20
    P =3D Partial Compliance.  Meets some aspect of the requirement.=20
    P+ =3D Complience possible. Could meet the requirement with =
=93natural=94=20
    evolution of the protocol. =20
    F =3D Failed Compliance.  Does not meet the requirement. =20
    =20
      3. Protocol Evaluation Summary and Conclusion=20
    =20
    In summary, it appears that the decomposition of the problem into=20
    session control and resource control gives rise to:=20
    =20
     - SIP is a good fit for session control for the speechsc=20
    requirements=20
    =20
     - MRCP is a good start for resource control for the speechsc=20
    requirements=20
    =20
    The conclusion for the protocol evaluation is therefore to:=20
       - create a new speechsc specific resource control only=20
          protocol, based on MRCP=20
       - use sessions that have been established by SIP (and defines a=20
          means of referring to these sessions)=20
    =20
    =20
      4. Core Protocol Section : Web Services vs Session Control=20
         protocols (Jerry Carter)=20
      =20
    TBC : =20
    =20
      5. Session Control : =93Beep=94 Compliance Evaluation (Jerry =
Carter)=20
=0A=
         5.1. General notes:=20
    =20
    The BEEP protocol provides a general framework for establishing =20
    connections, defining new channels, negotiating security, and=20
    performing user authentication. Protocols build on beep must define=20
    a profile detailing how connections are established and must define=20
 =20
 =20
 Wyld                    Expires =96 October 2003               [Page 3] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
    a set of messages which will be delivered using BEEP. The protocol=20
    is peer-to-peer although client-server style requests could be=20
    easily handled.=20
    =20
    The following sub-sections compare each individual requirement=20
    against the protocol.=20
=0A=
         5.2. Analysis of General Requirements=20
=0A=
           5.2.1. Reuse existing protocols [5.1]=20
    =20
    T: Beep is a published protocol, listed as RFC 3080=20
    (http://www.ietf.org/rfc/rfc3080.txt).=20
=0A=
           5.2.2. Maintain Existing Protocol Integrity [5.2]=20
    =20
    P: BEEP assumes that protocols, such as SpeechSC, will add=20
    messages.=20
    =20
    Supporting multiple clients using TCP may require some effort.=20
=0A=
           5.2.3. Avoid Duplicating Existing Protocols [5.3]=20
    =20
    T: Building SpeechSC over BEEP would allow the specification to=20
    focus on managing the ASR, media server, and SI/SV resources and=20
    the possible interactions between them. The operations for=20
    establishing connections and defining new channels would be handled=20
    by BEEP.=20
=0A=
           5.2.4. Protocol efficiency [5.4]=20
    =20
    P+: BEEP imposes a small overhead (roughly 40 bytes per message).=20
    It provides a mechanism for supporting multiple communication=20
    channels over a single port. If grouping of requests is desired,=20
    this would need to be handled by grouping the SpeechSC messages.=20
=0A=
           5.2.5. Explicit invocation of services [5.5]=20
    =20
    T: Though it is primarily a peer-to-peer protocol, BEEP may act as=20
    a traditional client server protocol.=20
=0A=
           5.2.6. Server Location and Load Balancing [5.6]=20
    =20
    P+: This functionality is not provided by BEEP. This would need to=20
    be added as an extension.=20
=0A=
           5.2.7. Simultaneous services [5.7]=20
    =20
    T: Multiple channels providing different services is possible. Each=20
    service is simply a message type which is passed to the server=20
    using BEEP.=20
=0A=
           5.2.8. Multiple media sessions [5.8]=20
    =20
    F: BEEP assumes a 1:1 using TCP/IP.=20
=0A=
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003               [Page 4] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
         5.3. Analysis of Duplexing and Parallel Operation Requirements=20
=0A=
           5.3.1. Duplexing and Parallel Operation Requirements [9]=20
    =20
    P+: Parallel operations may be obtained using multiple channels. A=20
    message on one channel could potentially interrupt activity=20
    happening on the second. BEEP is very flexible allowing the server=20
    to implement whatever behavior is desired.=20
=0A=
           5.3.2. Full Duplex operation [9.1.1]=20
    =20
    T: BEEP is a peer-to-peer protocol allowing full duplex=20
    communication on a single channel or parallel communication on=20
    multiple channels.=20
=0A=
           5.3.3. Multiple services in parallel [9.1.2]=20
    =20
    P+: Multiple services may be run on separate channels. Merging or=20
    T-ing of RTP must be implemented by the server.=20
=0A=
           5.3.4. Combination of services=20
    TBD=20
=0A=
         5.4. Analysis of additional considerations (non-normative)=20
    TBD=20
=0A=
         5.5. Analysis of Security considerations=20
=0A=
           5.5.1. Security Considerations [11]=20
    =20
    P+: BEEP offers a mechanism for managing security and user=20
    authentication. =20
    SpeechSC requires managing multiple data streams and some form of=20
    unified authentication / security might be a goal. If so, BEEP=20
    security should be revisited with this in mind.=20
    =20
=0A=
         5.6. Interaction Model=20
    TBC : TO BE COMPLETED : Analysis of the interaction model of the=20
    protocol during the =91data=92 phase (ie after session =
establishment)=20
    and its suitability for speechsc.=20
    =20
    =20
      6. Session Control : =93SIP=94 Complience Evaluation (Rajiv=20
         Dharmadhikari)=20
=0A=
         6.1. Introduction=20
    SIP is a protocol for initiating, modifying, and terminating=20
    multimedia sessions. The protocol is considered an IETF standard=20
    and its specifications can be found in [2]. The following sections=20
    provide a general statement with regards to the applicability of=20
    SIP as the control protocol for SPEECHSC. =20
    =20
=0A=
           6.1.1. SIP General Applicability=20
    SIP is a pretty mature, well understood, and frequently used =20
    session establishment protocol. It has gone through multiple=20
 =20
 =20
 Wyld                    Expires =96 October 2003               [Page 5] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
    revisions in the IETF standard process. There are number of=20
    commercial and public domain implementations of SIP that are=20
    available. Because of its close resemblance to HTTP and being a=20
    text based protocol, there are large number of SIP application=20
    developers available. =20
    =20
=0A=
           6.1.2. SIP Use in VOIP environment=20
    SIP is already being used to establish and redirect RTP streams=20
    from various end points. The SPEECHSC requires a protocol for=20
    controlling ASR, TTS and SV resources. When these resources are=20
    deployed in a VOIP network that requires them to process media=20
    carried in RTP, the SIP protocol is used in lot of deployments.=20
    Rather than inventing a new control protocol and introducing=20
    operational aspects of the new protocol, SIP can be reused for=20
    controlling SPEECHSC resources. =20
    =20
=0A=
         6.2. Analysis of General Requirements=20
=0A=
           6.2.1. Reuse existing protocols [5.1]=20
    T: SIP is an existing, widely used, and mature protocol defined in=20
    [2].=20
=0A=
           6.2.2. Maintain Existing Protocol Integrity [5.2]=20
    T: Existing SIP methods and header fields will not be changed when=20
    SIP is used to control SPEECHSC resources. In case, if extensions=20
    are required, SIP allows carriage of custom payload in the body.=20
    This payload is understood only by UAs and it does not impact=20
    protocol integrity.=20
    =20
=0A=
           6.2.3. Avoid Duplicating Existing Protocols [5.3]=20
    T: Lot of the requirements for SPEECHSC operation can easily be=20
    satisfied by SIP, e.g. establishing RTP streams or redirecting=20
    them. Without SIP, new SPEECHSC protocol will have to duplicate lot=20
    of session management functionality.=20
    =20
=0A=
           6.2.4. Protocol efficiency [5.4]=20
    T: SIP is a very lightweight protocol when run over TCP or UDP. It=20
    leverages efficiency available in TCP and UDP protocols that have=20
    been around for over 20 years.=20
=0A=
           6.2.5. Explicit invocation of services [5.5]=20
    T: SIP URI mechanism allows invocation of different services.=20
=0A=
           6.2.6. Server Location and Load Balancing [5.6]=20
    P+: SIP employs standard DNS name resolution for locating=20
    resources. SIP itself does not provide load balancing features.=20
    Application level load balancers can be used to load balance SIP=20
    requests.=20
    =20
=0A=
=0A=
=0A=
=0A=
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003               [Page 6] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
           6.2.7. Simultaneous services [5.7]=20
    T: SIP allows simultaneous invocation of different services. SIP=20
    allows forking or splitting the same media stream to different end=20
    points as defined in [2].=20
    =20
=0A=
           6.2.8. Multiple media sessions [5.8]=20
    T: SIP uses SDP to describe RTP stream characteristics. This allows=20
    the control of direction of RTP stream such as bi-directional or=20
    uni-directional. SIP allows a UA to establish sessions with=20
    multiple UAs for the same session.=20
    =20
=0A=
         6.3. Analysis of Duplexing and Parallel Operation Requirements=20
=0A=
           6.3.1. Duplexing and Parallel Operation Requirements [9]=20
    T: SPEECHSC resource is a SIP UA that can handle session requests=20
    from different UAs.=20
=0A=
           6.3.2. Full Duplex operation [9.1.1]=20
    T: Each SIP UA consists of a UAC and a UAS. This allows for full=20
    duplex operation.=20
=0A=
           6.3.3. Multiple services in parallel [9.1.2]=20
    T: SIP allows simultaneous invocation of different services. SIP=20
    allows forking or splitting the same media stream to different end=20
    points as defined in [2].=20
    =20
=0A=
           6.3.4. Combination of services=20
    T: See 5.6.3. SIP UA can invoke different services and combine the=20
    results.=20
=0A=
         6.4. Analysis of additional considerations (non-normative)=20
    TBD=20
=0A=
         6.5. Analysis of Security considerations=20
=0A=
           6.5.1. Security Considerations [11]=20
    T: SIP protocol employs different authentication schemes that are=20
    widely used in IP based protocols.=20
=0A=
         6.6. Other Criteria=20
    The following criteria were also defined by the evaluator of SIP.=20
=0A=
           6.6.1. Ability to establish session between SPEECHSC client=20
               and SPEECHSC resource=20
    T: SIP User Agent can establish a session with another SIP User=20
    Agent.=20
=0A=
           6.6.2. Ability to terminate session by either SPEECHSC=20
               client or SPEECHSC resource=20
    T: SIP User Agent can terminate a session with another SIP User=20
    Agent.=20
=0A=
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003               [Page 7] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
           6.6.3. Support reliable sequencing and delivery between=20
               SPEECHSC client and SPEECHSC resource=20
    P: SIP can be run over TCP or UDP. When run over TCP, this=20
    requirement is easily satisfied. When run over UDP, SIP User Agent=20
    is required to implement logic to ensure reliable sequencing and=20
    delivery. =20
=0A=
           6.6.4. Ability for SPEECHSC client to coordinate SPEECHSC=20
               resources on different machines for a single session=20
    T: SPEECHSC client can use SIP to establish SIP sessions with=20
    different machines.=20
=0A=
           6.6.5. Ability for SPEECHSC resource to handle multiple=20
               SPEECHSC clients=20
    T: SPEECHSC resource is a SIP UA that can handle session requests=20
    from different UAs.=20
=0A=
           6.6.6. The SPEECHSC resource should be able to generate=20
               asynchronous events or unsolicited messages=20
    T: SIP allows asynchronous events or unsolicited messages to be=20
    generated using SUBSCRIBE/NOTIFY mechanism.=20
=0A=
           6.6.7. The SPEECHSC client and resource should have ability=20
               for authenticating each other=20
    T: SIP protocol employs different authentication schemes that are=20
    widely used in IP based protocols.=20
=0A=
           6.6.8. Ability to determine success or failure from both=20
               SPEECHSC client and SPEECHSC resource side=20
    T: The protocol has following response codes: 200 for success, 3xx,=20
    4xx, and 5xx for failure.=20
=0A=
           6.6.9. Support for versioning between SPEECHSC client and=20
               SPEECHSC resource=20
    P+: This will require an additional header or element in the   =20
    body of SIP message for versioning. The current version field is=20
    intended for SIP protocol version. =20
    =20
=0A=
         6.7. Interaction Model=20
    =20
    Speechsc has certain needs related to the interaction model of the=20
    protocol during the =91data=92 phase (ie after session =
establishment).=20
    Specifically, speechsc will require that the resource server can=20
    send unsolicited messages/transactions to the resource client to=20
    return results and indicate events.=20
    =20
    SIP messages in the data phase can flow in both directions (client=20
    to server as well as server to client). SIP INFO message can be=20
    used for this purpose. The SIP INFO is intended for mid-call=20
    message semantics. With this message, transactions can be=20
    initiated/defined by both ends. =20
    =20
    SIP therefore has an interaction model suited to the speechsc=20
    model, which supports peer-peer messaging with a basic=20
    transactional symmetrical request/response model.=20
    =20
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003               [Page 8] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
      7. Session Control : =93RTSP=94 Complience Evaluation (Brian Wyld) =

=0A=
         7.1. General Introduction=20
    RTSP is an existing protocol, orientated towards audio playback and=20
    recording. As such, it has support for RTP session control, with=20
    SDP used for session description, and a message set allowing=20
    operation as a player/recorder with audio =93VCR=94 controls.=20
    =20
    Only the session control is evaluated here (see later section for=20
    evaluation of the resource control elements)=20
    =20
    The following sub-sections compare each individual requirement=20
    against the protocol.=20
=0A=
         7.2. Analysis of General Requirements=20
=0A=
           7.2.1. Reuse existing protocols [5.1]=20
    T: RTSP/RTP/SDP would be reused.=20
=0A=
           7.2.2. Maintain Existing Protocol Integrity [5.2]=20
    T: The extensions to RTSP to allow speechsc use would be in the=20
    spirit of the protocol, and would not break existing servers or=20
    clients.=20
=0A=
           7.2.3. Avoid Duplicating Existing Protocols [5.3]=20
    T: Using RTSP would not recreate it.=20
=0A=
           7.2.4. Protocol efficiency [5.4]=20
    T: RTSP is a text based protocol, but is relatively succinct as=20
    messages are specific to their operation.=20
=0A=
           7.2.5. Explicit invocation of services [5.5]=20
    T: RTSP service invocation is sufficient.=20
=0A=
           7.2.6. Server Location and Load Balancing [5.6]=20
    F: RTSP does not address this topic; however it can be used with=20
    other IETF protocols such as SLP or UDDI to do so.=20
=0A=
           7.2.7. Simultaneous services [5.7]=20
    T: RTSP allows simultaneous invocation of services on the same or=20
    different control channel.=20
=0A=
           7.2.8. Multiple media sessions [5.8]=20
    T: RTSP allows multiple media sessions.=20
=0A=
         7.3. Analysis of Duplexing and Parallel Operation Requirements=20
=0A=
           7.3.1. Duplexing and Parallel Operation Requirements [9]=20
    T: RTSP allows session setup that should fulfill these=20
    requirements.=20
=0A=
           7.3.2. Full Duplex operation [9.1.1]=20
    T: RTSP can create a full duplex session.=20
=0A=
=0A=
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003               [Page 9] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
           7.3.3. Multiple services in parallel [9.1.2]=20
    T: RTSP can request multiple operations of the same type on the=20
    same session.=20
=0A=
           7.3.4. Combination of services=20
    T: RTSP can request multiple operations of different types on the=20
    same session.=20
=0A=
         7.4. Analysis of additional considerations (non-normative)=20
    TBD=20
=0A=
         7.5. Analysis of Security considerations=20
=0A=
           7.5.1. Security Considerations [11]=20
    F: RTSP provides no specific security functionality at all, but=20
    depends on other IETF security protocols (as it uses TCP) to pre-
    validate and protect the sessions.=20
=0A=
         7.6. Interaction Model=20
    Speechsc has certain needs related to the interaction model of the=20
    protocol during the =91data=92 phase (ie after session =
establishment).=20
    Specifically, speechsc will require that the resource server can=20
    send unsolicited messages/transactions to the resource client to=20
    return results and indicate events.=20
    =20
    RTSP messages in the data phase can flow in both directions (client=20
    to server as well as server to client). Transactions can be=20
    initiated/defined by both ends. Currently most of the defined=20
    transactions are C-S; however there already exists an ANNOUNCE=20
    message transaction that is used to transit general content in both=20
    directions (and is in fact used by MRCP to transport its resource=20
    control messages).=20
    =20
    RTSP has therefore an interaction model suited to the speechsc=20
    model, which supports peer-peer messaging with a basic=20
    transactional symmetrical request/response model.=20
    =20
      8. Session Control : =93Web Services=94 Complience Evaluation=20
         (Stephane H. Maes)=20
=0A=
         8.1. General Notes:=20
    Speech engines (speech recognition, speaker, recognition, speech =20
    synthesis, recorders and playback, NL parsers, and any other speech=20
    processing engines (e.g. speech detection, barge-in detection etc) =20
    etc...) as well as audio sub-systems (audio input and output =20
    sub-systems) can be considered as web services that can be =20
    described and asynchronously programmed via WSDL (on top of SOAP), =20
    combined in a flow described via WSFL, discovered via UDDI and =20
    asynchronously controlled via SOAP that also enables =20
    asynchronous exchanges between the engines.=20
     =20
    This solution presents the advantage to provide flexibility, =20
    scalability and extensibility while reusing an existing framework =20
    that fits the evolution of the web: web services and XML protocols=20
    [WS1]=20
    =20
    According to the web services framework, speech engines (audio =20
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 10] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
    sub-systems, engines, speech processors) can be defined as web=20
    services=20
    that are characterized by an interface that consists of some of the  =

    following ports:=20
        - "control in" port(s): It sets the engine context, i.e. all=20
    the=20
        settings required for a speech engine to run. It may include =20
        addresses where to get or send the streamed audio or results.=20
        - "control out" port(s): It produces the non-audio engine=20
    output=20
        (i.e. results and events). It may also involve some session =20
        control exchanges.=20
        - "audio in" port(s): It receives streamed input data. =20
        - "audio out" port(s): It produces streamed output data. =20
    =20
    Audio sub-systems can also be treated as web services that can =20
    produce streamed data or play incoming streamed data as specified=20
    by=20
    the control parameters.=20
    =20
    The "control in" or "control out" messages can be out-of-band or =20
    sent or received interleaved with "audio in or out" data. This can =20
    be determined in the context (setup) of the web services. =20
    =20
    Speech engines and audio sub-systems are pre-programmed as web =20
    services and composed into more advanced services. Once programmed =20
    by the application / controller, audio-sub-systems and engines=20
    await=20
    an incoming event (established audio session, etc...) to execute=20
    the=20
    speech processing that they have been programmed to do and send the  =

    results as programmed. =20
    =20
    Speech engines as web services are typically programmed to handle =20
    completely a particular speech processing task, including handling =20
    of possible errors. For example, as speech engine is programmed to =20
    perform recognition of the next incoming utterance with a=20
    particular=20
    grammar, to send result to a NL parser and to contact a particular =20
    error recovery process if particular errors occur.=20
    =20
    The following sub-sections compare each individual requirement=20
    against the protocol.=20
=0A=
         8.2. Analysis of General Requirements=20
=0A=
           8.2.1. Reuse existing protocols [5.1]=20
    T: Web services are is a class of protocols (framework) widely=20
    studied and developed across numerous standard bodies like W3C,=20
    OASIS, WS-I, Liberty, Parlay and adapted to numerous deployment=20
    environments  issues at IETF, OMA, 3GPP, 3GPP2, JCP, etc=85 As an=20
    entry point, we recommend consulting the work at W3C [WS1].=20
    =20
=0A=
           8.2.2. Maintain Existing Protocol Integrity [5.2]=20
    T: Web services is an XML-based framework that is by definition=20
    extensible to support appropriate syntax and semantics. =20
    =20
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 11] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
    Web services are bound on underlying transport protocols. Numerous=20
    such binding have been specified. Others are in development. By=20
    handling at SPEECHSC at the level of the =20
    Web services framework, the integrity is maintained for:=20
    - underlying transport protocols (to which the web service are=20
    bound (e.g. SOAP)=20
    - web service framework=20
    =20
    This does not prevent introducing bindings to new protocols if=20
    needed. For example, binding to SIP or BEEP could be advantageous=20
    for mobile deployments.=20
    =20
=0A=
           8.2.3. Avoid Duplicating Existing Protocols [5.3]=20
    T: By definition, the web service framework can be specified to=20
    remote control any web service. Specified syntax can be limited to=20
    avoid duplicating remote control functionalities offered by other=20
    protocols. =20
    =20
    At the same time, the extensibility inherent to the framework=20
    guarantees that it is possible to specify (standard) or define=20
    (application specific) remote control for other entities beyond the=20
    current scope of SPEECHSC. =20
    =20
    In that context and in view of unifying the remote control=20
    framework exposed to an application developer or a system=20
    integrator, it may be of interest to provide remote control syntax=20
    for special entities like prompt player etc=85=20
    =20
=0A=
           8.2.4. Protocol efficiency [5.4]=20
    P+ to P: Web services are by definition more verbose protocols.=20
    Hence, at this stage this does not qualify work a T mark. =20
    =20
    However work is in progress (e.g. OMA, JCP) to optimize the=20
    exchanges to handle:=20
    - Client with limited resources=20
    - Constrained bandwidth=20
    These rely on protocol compression and optimization, caching and=20
    gateways. =20
    =20
    As such the protocols qualify as P+.=20
    =20
    In addition, based on the qualification of efficiency provided in=20
    [WS8], the web service framework proposed for SPEECHSC and=20
    described in [WS1] relies indeed on known efficient techniques:=20
    - Asynchronous pre-programming of the engines as web services to=20
    reduce exchanges and avoid racing conditions=20
    - Possibility to piggy back on response message if transported on=20
    optimized protocols like SIP or BEEP. =20
    - state caching in the engines that are considered as stand-alone,=20
    pre-packaged and pre-programmed engines.=20
    - etc=85=20
    =20
=0A=
           8.2.5. Explicit invocation of services [5.5]=20
    T: Web service is typically used in a client-server environment.=20
    Solutions exist for peer to peer (service to service) etc=85 =20
    =20
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 12] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
    Web services have been deigned to support clients and servers at=20
    least one of which is operating directly on behalf of the user=20
    requesting the service.=20
    =20
    In addition, work on-going at OMA and JCP addresses some of these=20
    issues in mobile environment with the introduction of possible web=20
    service gateways. =20
    =20
=0A=
           8.2.6. Server Location and Load Balancing [5.6]=20
    T: Web services are widely developed for e-business applications.=20
    Numerous tools and mechanisms have been provided for service=20
    discovery ad advertisement. In addition, numerous offerings provide=20
    routing and load balancing capabilities as part of the web=20
    application server used to deploy the web service. =20
    =20
    Note that web services do not specify server location or load=20
    balancing; but they are deployed on systems that provide such=20
    functionalities. As web services are expected to be widely used in=20
    the future and central to most e-business offerings, it is to=20
    expect that such tools will become even more pervasive and=20
    efficient.=20
    =20
=0A=
           8.2.7. Simultaneous services [5.7]=20
    Web services allow control (interface) and composition of web=20
    services at will (e.g. WSFL).=20
=0A=
           8.2.8. Multiple media sessions [5.8]=20
    T: The framework proposed does not pre-supposes how many ports or=20
    streams are associated to the engine. Different inbound and=20
    outbound can be used at will=20
    =20
=0A=
         8.3. Analysis of Duplexing and Parallel Operation Requirements=20
=0A=
           8.3.1. Duplexing and Parallel Operation Requirements [9]=20
    T: As explained, web services allow control (interface) and=20
    composition of web services at will (e.g. WSFL).  Also, it does not=20
    pre-supposes how many ports or streams are associated to the=20
    engine. Different inbound and outbound can be used at will; in full=20
    duplex or even between engines as supported by WSFL [WS4] and WSXl=20
    [WS7].=20
=0A=
           8.3.2. Full Duplex operation [9.1.1]=20
    T:=20
=0A=
           8.3.3. Multiple services in parallel [9.1.2]=20
    T:=20
=0A=
           8.3.4. Combination of services=20
    T: As explained, web services allow control (interface) and=20
    composition of web services at will (e.g. WSFL) into complex=20
    parallel, serial or coordinated combinations as supported by WSFL=20
    [WS4] and WSXl [WS7].=20
=0A=
=0A=
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 13] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
         8.4. Analysis of additional considerations (non-normative)=20
    The framework proposed supports:=20
    - Use of SDP to describe sessions and streams for the streamed=20
    channels =20
    - Time stamps could be transmitted as part of the control messages=20
    at the web service level or in band (e.g. with dynamic payload=20
    switch or within the payload).=20
    - The framework is compatible with any encoding scheme. This is=20
    illustrated by the work on SRF (Speech Recognition Framework)=20
    driven at 3GPP that supports conventional and DSR optimized codecs=20
    and possible exchange of speech meta-information (e.g. data that=20
    may be required to facilitate and enhance the server-side=20
    processing of the input speech and facilitate the dialog management=20
    in an automated voice service. These may include keypad events=20
    over-riding spoken input, notification that the UE is in hands-free=20
    mode, client-side collected information (speech/no-speech, barge-
    in), etc=85.).=20
    - SOAP over SIP or BEEP to support the framework described in=20
    section 1 can also support VCR controls.=20
    - real-time messaging between engine and control is supported=20
    within the framework (e.g. via SOAP or XML events). The framework=20
    also support exchange between engines (same process; see also WSXL=20
    [WS7]).=20
    =20
    Although non-normative, the web service framework described=20
    probably deserves marks of P+ to T.=20
 =20
=0A=
         8.5. Analysis of Security considerations=20
=0A=
           8.5.1. Security Considerations [11]=20
    Web services are evolving to provide security, authentication,=20
    encryption, trust management and privacy . Details can be found for=20
    example in [WS9] and explained in [WS10]. This is now an OASIS=20
    activity [WS11].=20
    =20
    This framework would enable SPEECHSC to employ the security=20
    mechanism provided bu WS-Security for the remote control aspects.=20
    Exchanged media can rely on security mechanism at the transport /=20
    streaming level.=20
    =20
    The web service framework described probably deserves marks of P+=20
    to T.=20
=0A=
         8.6. Interaction Model=20
    TBC : TO BE COMPLETED : Analysis of the interaction model of the=20
    protocol during the =91data=92 phase (ie after session =
establishment)=20
    and its suitability for speechsc.=20
    =20
    =20
      9. Resource Control : =93MRCP=94 Complience Evaluation (Sarvi=20
         Shanmugham)=20
=0A=
         9.1. General =20
=0A=
           9.1.1. MRCP Framework and General Applicability=20
    =20
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 14] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
    The overall MRCP framework, the components involved and their=20
    distribution and relationship to each other meet the framework=20
    specified by SPEECHSC. The primary advantage of MRCP is that it is=20
    a text based protocol designed to meet most of the requirements of=20
    SPEECHSC pertaining to speech recognition and Text to speech.=20
    Though Speaker Recognition (SR) and Speaker Verification (SV) are=20
    not supported in its current form, MRCP was explicitly designed to=20
    be extendable for such needs. The core MRCP definition only deals=20
    with the control of the ASR or TTS resource and the commands and=20
    responses needed to achieve it.=20
 =20
    There are multiple interoperable implementations of MRCP and hence=20
    is a proven technology. It leverages existing W3C XML standards for=20
    exchange of data between the client and the server resource. For=20
    Example, its uses the W3C XML grammar format (GRXML) along with W3C=20
    semantic attachments and Natural Language Semantic Markup Language=20
    to exchange data with speech recognition resource. The W3C Speech=20
    Markup Language is used when dealing with Text to speech engines.=20
     =20
    It was designed to work as a tunneled protocol, over RTSP or SIP.=20
    Hence it depends on the carrier protocol to establish a control and=20
    a media path between the client and the ASR or TTS server resource.=20
    Hence it gets most of the security and media pipe management=20
    operations for free. Once these are established, MRCP commands and=20
    responses are tunneled over, controlling the ASR or TTS resource on=20
    the server. =20
=0A=
           9.1.2. MRCP can be evolved=20
    =20
    Though MRCP directly meets many of the needs of SPEECHSC. The=20
    notion that it is a tunneled protocol disallows its independent=20
    operation. Further more the tunneled aspect is also a less=20
    efficient protocol design. =20
    =20
    But these can be addressed and the core MRCP messages can be=20
    evolved to either become standalone protocol by itself or=20
    extensions to an existing protocol such as SIP or RTSP.  To make=20
    this a standalone protocol and allow MRCP to operate by itself, new=20
    session and media management messages need to be defined to allow=20
    it to operate independently. To evolve MRCP as extensions to SIP or=20
    RTSP would also be relatively simple since it is also a text based=20
    protocol with message format and headers very similar to them.  In=20
    this protocol evaluation, the compliance evaluates MRCP from the=20
    perspective of evolution in one of these forms.=20
    =20
    The following sub-sections compare each individual requirement=20
    relating to resource management against the protocol.=20
=0A=
         9.2. Analysis of TTS requirements=20
=0A=
           9.2.1. Requesting Text Playback [6.1]=20
    T: MRCP has the SPEAK method for the client to request the TTS=20
    resource to playback text as an audio stream.=20
=0A=
           9.2.2. Text Formats [6.2]=20
    T: When the client requests the TTS resource to playback a text=20
    stream it can provide the content in the following formats and=20
    through the following mechanism.=20
    =20
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 15] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
       1. Plain text=20
       2. W3C XML based Speech Markup Language (SSML)=20
       3. This content to be spoken can be provided by value directly=20
          through the control path. =20
       4. It also supports passing the content by reference. This is=20
          achieved having an audio tag inside the SSML markup text.=20
          This URL is then fetched and played on the RTP stream in=20
          sequence with the rest of the text according to the SSML=20
          specification.=20
    When the client sends plain text, SSML or another format of speech=20
    text the content is coded as a mime-type. Hence the server knows=20
    what format the speech content is coded in, and does not have to=20
    figure it out from the content.=20
=0A=
           9.2.3. Plain text [6.2.1]=20
    T: see above=20
=0A=
           9.2.4. SSML [6.2.2]=20
    T: see above=20
=0A=
           9.2.5. Text in Control Channel [6.2.3]=20
    T : see above=20
=0A=
           9.2.6. Document Type Indication [6.2.4]=20
    T: see above=20
=0A=
           9.2.7. Control Channel [6.3]=20
    T: In MRCP, this Reset-Audio-Channel header defined for the ASR=20
    resource allows the recognizer to re-initialize the audio=20
    characteristics that it has learnt till then. This allows a=20
    recognizer resource to be used for multiple recognition sessions.=20
    It can be used for short single utterance recognitions as well.=20
    This is by applying the Reset-Audio-Channel header to every=20
    recognition. I suspect the performance may not be as good, due to=20
    the lack of line characteristics, but this is a recognizer issue.=20
=0A=
           9.2.8. Playback Controls [6.4]=20
    T: MRCP supports the CONTROL method with the Jump-Target header can=20
    used to achieve, jumping in time or to an exact or relative=20
    location. It supports jumping in paragraphs, sentences, words and=20
    to specific markers that may be embedded in the speech content. The=20
    CONTROL method can be used with the Voice and Prosody parameters,=20
    derived from SSML, and can address the speed of speech or=20
    increasing/decreasing the volume. It also supports the PAUSE/RESUME=20
    methods to pause or resume a current SPEAK request.=20
=0A=
           9.2.9. Session Parameters [6.5]=20
    T: As mentioned the previous section, MRCP supports voice and=20
    prosody parameters which are directly derived from the W3C SSML=20
    specification. These headers can be sent using the SET-PARAMS=20
    method and applied as a default for the entire session. They can=20
    also be applied in SPEAK requests to apply per usage or in the=20
    CONTROL message to change the parameters of an active SPEAK=20
    request.=20
=0A=
           9.2.10. Speech Markers [6.6]=20
    T: Specifying speech markers in the content is supported through=20
    SSML. The CONTROL message can then be used to jump to specific=20
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 16] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
    marker points in the text. Also, when the TTS resource reaches=20
    specific markers in the text, the server would generate the SPEECH-
    MARKER method to the client.=20
=0A=
         9.3. Analysis of ASR requirements=20
=0A=
           9.3.1. Requesting Automatic Speech Recognition [7.1]=20
    T: The client uses the RECOGNIZE method in MRCP to request the=20
    recognition resource to process the audio stream in the pipe. The=20
    RECOGNIZE method also specifies parameters and grammars the=20
    recognizer should match against.=20
=0A=
           9.3.2. XML [7.2]=20
    T: Similar to the TTS resource in MRCP, ASR also uses XML data to=20
    exchange information between the client and the recognition=20
    resource. It supports the W3C GRXML to pass grammars from the=20
    client to the server. When the server is done recognizing, it uses=20
    the W3C Natural Language Semantic Markup Language (NLSML) to pass=20
    the results back to the client. It supports other grammar formats=20
    as well, as long as the server allows it. This is possible since,=20
    it uses mime-types to package this data and hence the format type=20
    is specified.=20
=0A=
           9.3.3. Grammar Specification [7.3.1]=20
    P+: MRCP supports specifying the grammar both by value and by=20
    reference. The RECOGNIZE method can carry with it grammar content=20
    and/or a URI referring to the grammar content. Since MRCP supports=20
    referring a grammar, the referred grammar could be located on the=20
    server itself. With respect to sharing of grammars, the grammars=20
    defined/compiled through the DEFINE-GRAMMAR primitive are not=20
    sharable across sessions on the same server. This needs to be=20
    addressed to meet this set of requirements in full.=20
=0A=
           9.3.4. Explicit Indication of Grammar Format [7.3.2]=20
    P+: see above=20
=0A=
           9.3.5. Grammar Sharing [7.3.3]=20
    TBD=20
=0A=
           9.3.6. Session Parameters [7.4]=20
    T: This requirement as defined is already fully met since MRCP is=20
    the referred standard for compliance.=20
=0A=
           9.3.7. Input Capture [7.5]=20
    T: This is achieved by setting the Waveform-url header in the=20
    RECOGNIZE method. This tells the server to record the audio of the=20
    recognition and will return a URI to the client in the completion=20
    event, which can be used to retrieve or play back the audio.=20
=0A=
         9.4. Analysis of Speaker Identification and Verification=20
            Requirements=20
=0A=
           9.4.1. Requesting SI/SV [8.1]=20
    F: not supported=20
=0A=
           9.4.2. Identifiers for SI/SV [8.2]=20
    F: not supported=20
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 17] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
           9.4.3. State for multiple utterances [8.3]=20
    F: not supported=20
=0A=
           9.4.4. Input Capture [8.4]=20
    F: not supported=20
=0A=
           9.4.5. SI/SV functional extensibility [8.5]=20
    F: not supported=20
    =20
      10.  Resource Control : =93RTSP=94 Complience Evaluation (Brian =
Wyld)=20
=0A=
         10.1.General Introduction=20
    RTSP is an existing protocol, orientated towards audio playback and=20
    recording. As such, it has support for RTP session control, with=20
    SDP used for session description, and a message set allowing=20
    operation as a player/recorder with audio =93VCR=94 controls. This=20
    comparison only addresses the existing resource control elements=20
    here and their applicability to the speechsc requirements.=20
     =20
    The current PLAY state machine is exactly as required for TTS=20
    operation. Although by analogy RECORD could initiate an ASR=20
    session, with headers giving the grammer source or references, =
it=92s=20
    state machine is not nearly as compatible, and not at all for=20
    SV/SI. =20
=0A=
         10.2.Analysis of TTS requirements=20
=0A=
           10.2.1. Requesting Text Playback [6.1]=20
    P+: the RTSP PLAY message semantics would require minor extensions=20
=0A=
           10.2.2. Text Formats [6.2]=20
    P+: Text can be defined as all text types. =20
=0A=
           10.2.3. Plain text [6.2.1]=20
    T: Plain text may be carried directly in the message payload.=20
=0A=
           10.2.4. SSML [6.2.2]=20
    T: Text may be in any format.=20
=0A=
           10.2.5. Text in Control Channel [6.2.3]=20
    T: Text may be attached to the control messages.=20
=0A=
           10.2.6. Document Type Indication [6.2.4]=20
    T : Via the Content-Type header=20
=0A=
           10.2.7. Control Channel [6.3]=20
    T: RTSP sessions may use a private or shared TCP connection.=20
=0A=
           10.2.8. Playback Controls [6.4]=20
    T: RTSP defines playback control messages and a state machine.=20
=0A=
           10.2.9. Session Parameters [6.5]=20
    T: RTSP defines operations for session parameter control.=20
=0A=
=0A=
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 18] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
           10.2.10.  Speech Markers [6.6]=20
    P+: Markers may be inserted in the text, but to provide the=20
    required asynchronous events when a marker is synthesized will=20
    require use specific ANNOUNCE type messages for server->client=20
    notification.=20
=0A=
         10.3.Analysis of ASR requirements=20
=0A=
           10.3.1. Requesting Automatic Speech Recognition [7.1]=20
    P: The RECORD message and semantics could be used but would require=20
    extensions (stretching the current semantic quite a lot)=20
=0A=
           10.3.2. XML [7.2]=20
    P+: Text can be defined as all text types.=20
=0A=
           10.3.3. Grammar Specification [7.3.1]=20
    P+: Text can be defined as all text types.=20
=0A=
           10.3.4. Explicit Indication of Grammar Format [7.3.2]=20
    T : Via the Content-Type headers=20
=0A=
           10.3.5. Grammar Sharing [7.3.3]=20
    F: TBD=20
=0A=
           10.3.6. Session Parameters [7.4]=20
    T: RTSP defines operations for session parameter control.=20
=0A=
           10.3.7. Input Capture [7.5]=20
    P+: would require addition of a header to the initiation message.=20
=0A=
         10.4.Analysis of Speaker Identification and Verification=20
            Requirements=20
=0A=
           10.4.1. Requesting SI/SV [8.1]=20
    F: not supported=20
=0A=
           10.4.2. Identifiers for SI/SV [8.2]=20
    F: not supported=20
=0A=
           10.4.3. State for multiple utterances [8.3]=20
    F: not supported=20
=0A=
           10.4.4. Input Capture [8.4]=20
    F: not supported=20
=0A=
           10.4.5. SI/SV functional extensibility [8.5]=20
    F: not supported=20
    =20
        =20
      11.  Security Considerations =20
     =20
    Security considerations for the SPEECHSC protocol are covered by=20
    the comparison against the specific Security requirements in the=20
    SPEECHSC requirements document [1]. =20
        =20
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 19] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
      12.  References =20
    [1] E. Burger, =93Requirements for Distributed Control of ASR, SR =
and=20
    TTS Resources" draft-ietf-speechsc-reqts-00.txt, July 31, 2002.=20
    =20
    [2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.=20
    Peterson, R. Sparks, M. Handley, E.Schooler, SIP: Session=20
    Initiation Protocol, RFC3265, June 2002. (Obsoletes RFC2543)=20
    =20
    [WS1] W3C Web Services, http://www.w3c.org/2002/ws/=20
    [WS2] Simple Object Access Protocol (SOAP)=20
    http://www.w3c.org/2002/ws/=20
    [WS3] Web Services Description Language (WSDL 1.1), W3C Note 15=20
    March =20
        2001, http://www.w3.org/TR/wsdl.=20
    [WS4] Leymann, F., Web Service Flow Language, WSFL 1.0, May 2001, =20
         http://www-
    4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf=20
    [WS5] UDDI, http://www.uddi.org/specification.html =20
    [WS6] W3C Voice Activity, http://www.w3c.org/Voice/ =20
    [WS7] WSXL - Web Service eXperience Language submitted to OASIS=20
    WSIA =20
          and WSRP - WSXL - Web Service eXperience Language submitted=20
    to =20
           OASIS WSIA and WSRP=20
    [WS8] Requirements for Distributed Control of ASR, SI/SV and TTS=20
    Resources, =20
    draft-ietf-speechsc-reqts-01.txt=20
    [WS9] Security in a Web Services World: A Proposed Architecture and=20
    Roadmap, =20
    April 7, 2002, Version 1.0, http://www.verisign.com/wss/wss.pdf=20
    [WS10] Kapil Apshankar, WS-Security, Security for Web Services,=20
    http://www.webservicesarchitect.com/content/articles/apshankar04.as
    p=20
    [WS11] OASIS Web Services Security TC, http://www.oasis-
    open.org/committees/wss/=20
    =20
 Author=92s Address=20
        =20
    Brian Wyld =20
    Eloquant SA=20
    ZA Malvaisin                   Phone:  +33 476 77 46 92 =20
    Le Versoud, France             Email:  brian.wyld@eloquant.com =20
     =20
     =20
 Full Copyright Statement=20
    =20
    Copyright (C) The Internet Society (2002).  All Rights Reserved.=20
       =20
    This document and translations of it may be copied and furnished to=20
    others, and derivative works that comment on or otherwise explain=20
    it=20
    or assist in its implementation may be prepared, copied, published=20
    and distributed, in whole or in part, without restriction of any=20
    kind, provided that the above copyright notice and this paragraph=20
    are included on all such copies and derivative works.  However,=20
    this=20
    document itself may not be modified in any way, such as by removing=20
    the copyright notice or references to the Internet Society or other=20
    Internet organizations, except as needed for the purpose of=20
    developing Internet standards in which case the procedures for=20
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 20] =
=0C
                 SPEECHSC Protocol Evaluation Template      June 2003=20
 =20
 =20
    copyrights defined in the Internet Standards process must be=20
    followed, or as required to translate it into languages other than=20
    English.  The limited permissions granted above are perpetual and=20
    will not be revoked by the Internet Society or its successors or=20
    assigns.  This document and the information contained=20
    herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND=20
    THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,=20
    EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT=20
    THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR=20
    ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A=20
    PARTICULAR PURPOSE."=20
 =20
    =20
    =20
    =20
    =20
    =20
 =20
    =20
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
 =20
 =20
 Wyld                    Expires =96 October 2003              [Page 21] =
=0C
------=_NextPart_000_006B_01C33D02.3838C7A0--


_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc



From exim@www1.ietf.org  Fri Jun 27 20:49:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28269
	for ; Fri, 27 Jun 2003 20:49:42 -0400 (EDT)
Received: (from exim@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h5S0nEY17630
	for speechsc-archive@odin.ietf.org; Fri, 27 Jun 2003 20:49:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19W3ty-0004aH-3J
	for speechsc-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 20:49:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28237
	for ; Fri, 27 Jun 2003 20:49:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19W3tv-00004t-00
	for speechsc-web-archive@ietf.org; Fri, 27 Jun 2003 20:49:11 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19W3tq-00004d-00
	for speechsc-web-archive@ietf.org; Fri, 27 Jun 2003 20:49:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19W3tl-0004Zg-1G; Fri, 27 Jun 2003 20:49:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19W3sv-0004YT-0E
	for speechsc@optimus.ietf.org; Fri, 27 Jun 2003 20:48:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28175
	for ; Fri, 27 Jun 2003 20:47:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19W3sd-000038-00
	for speechsc@ietf.org; Fri, 27 Jun 2003 20:47:51 -0400
Received: from krishna.genesyslab.com ([198.49.180.171])
	by ietf-mx with esmtp (Exim 4.12)
	id 19W3sR-00002h-00
	for speechsc@ietf.org; Fri, 27 Jun 2003 20:47:40 -0400
Received: from aster.us.int.genesyslab.com ([10.10.10.25.5794])
	by krishna.genesyslab.com with esmtp (Exim 3.36 #1)
	id 19W3qt-000POd-00; Fri, 27 Jun 2003 17:46:03 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64
Subject: RE: [Speechsc] Protocol proposal for SPEECHSC
Date: Fri, 27 Jun 2003 17:45:57 -0700
Message-ID: <52F49B5A0E5B0F4781C9C8F7159409E48059E7@aster.us.int.genesyslab.com>
Thread-Topic: [Speechsc] Protocol proposal for SPEECHSC
Thread-Index: AcM9BoXv723xF4YKT5e1joGsR3RKFQAB/fy/
From: "Rajiv Dharmadhikari" 
To: , "Sarvi Shanmugham" 
Cc: "Eric Burger" , 
Content-Transfer-Encoding: base64
Sender: speechsc-admin@ietf.org
Errors-To: speechsc-admin@ietf.org
X-BeenThere: speechsc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: ,
	
List-Id: Speech Services Control Working Group 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

QnJpYW4sDQogDQpSZXNvdXJjZSBjb250cm9sIHNlY3Rpb24gb24gU0lQIGlzIG1pc3NpbmcgaW4g
dGhpcyB2ZXJzaW9uLiBJIHByb3ZpZGVkIG15IHVwZGF0ZXMgbGFzdCB3ZWVrLiBJIGhvcGUgeW91
IGdldCBjaGFuY2UgdG8gaW5jbHVkZSB0aGF0IGluIHRoZSBmaW5hbCB2ZXJzaW9uLg0KIA0KVGhh
bmtzLA0KIA0KLVJhaml2DQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBC
cmlhbiBXeWxkIFttYWlsdG86YnJpYW4ud3lsZEBlbG9xdWFudC5jb21dIA0KCVNlbnQ6IEZyaSA2
LzI3LzIwMDMgMjoxNyBQTSANCglUbzogUmFqaXYgRGhhcm1hZGhpa2FyaTsgU2FydmkgU2hhbm11
Z2hhbSANCglDYzogRXJpYyBCdXJnZXI7IHNwZWVjaHNjQGlldGYub3JnIA0KCVN1YmplY3Q6IFJF
OiBbU3BlZWNoc2NdIFByb3RvY29sIHByb3Bvc2FsIGZvciBTUEVFQ0hTQw0KCQ0KCQ0KCUhpIGFs
bCwNCgkgDQoJQXR0YWNoZWQgeW91IGhhdmUgYW4gdXBkYXRlZCBkcmFmdCB0aGF0IEkgcHJvcG9z
ZSB0byBzdWJtaXQgYXMgMDIgZm9yIHRoZSBuZXh0IElFVEYuIEVzc2VudGlhbGx5IGl0cyB0aGUg
cmUtd29ya2VkIGRvYywgd2l0aCBhIHZlcnkgc2hvcnQgY29uY2x1c2lvbi4uLi4uIA0KCSANCglN
YWpvciBtaXNzaW5nIHBhcnQgaXMgdGhlIHdlYiBzZXJ2aWNlcyB2cyBjbGFzc2ljIHNlc3Npb24g
Y29udHJvbCBzZWN0aW9uIHdlIGFncmVlZCB0byBhZGQgaW4gdGhlIGxhc3QgY29uZiBjYWxsLi4u
Li4NCgkgDQoJQnJpYW4NCgkgDQoNCgkNCg0KCQktLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0N
CgkJRGUgOiBSYWppdiBEaGFybWFkaGlrYXJpIFttYWlsdG86cmFqaXZkaEBnZW5lc3lzbGFiLmNv
bV0NCgkJRW52b3nDqSA6IEZyaWRheSwgSnVuZSAyMCwgMjAwMyAwMzoyMw0KCQnDgCA6IGJyaWFu
Lnd5bGRAZWxvcXVhbnQuY29tOyBTYXJ2aSBTaGFubXVnaGFtDQoJCUNjIDogRXJpYyBCdXJnZXI7
IHNwZWVjaHNjQGlldGYub3JnDQoJCU9iamV0IDogUkU6IFtTcGVlY2hzY10gUHJvdG9jb2wgcHJv
cG9zYWwgZm9yIFNQRUVDSFNDDQoJCQ0KCQkNCgkJQnJpYW4sDQoJCSANCgkJSGVyZSBpcyB0aGUg
dXBkYXRlZCBwcm90b2NvbCBjb21wYXJpc29uIGRvY3VtZW50IHdpdGggbXkgdXBkYXRlcyB0byB0
aGUgU0lQIHNlY3Rpb24uIFNlc3Npb24gY29udHJvbCBhbmQgcmVzb3VyY2UgY29udHJvbCBzZWN0
aW9ucyBoYXZlIGJlZW4gdXBkYXRlZCBhcyBwZXIgbGFzdCBjb25mZXJlbmNlIGNhbGwuDQoJCSAN
CgkJTGV0IG1lIGtub3cgaWYgYW55IGNoYW5nZXMgYXJlIG5lZWRlZC4NCgkJIA0KCQktUmFqaXYN
Cg0KCQkJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgkJCUZyb206IEJyaWFuIFd5bGQgW21h
aWx0bzpicmlhbi53eWxkQGVsb3F1YW50LmNvbV0NCgkJCVNlbnQ6IFRodXJzZGF5LCBKdW5lIDE5
LCAyMDAzIDE6NTggQU0NCgkJCVRvOiBTYXJ2aSBTaGFubXVnaGFtDQoJCQlDYzogRXJpYyBCdXJn
ZXI7IHNwZWVjaHNjQGlldGYub3JnDQoJCQlTdWJqZWN0OiBSRTogW1NwZWVjaHNjXSBQcm90b2Nv
bCBwcm9wb3NhbCBmb3IgU1BFRUNIU0MNCgkJCQ0KCQkJDQoJCQlIaSBTYXJ2aSwNCgkJCSANCgkJ
CU5vLCBJIHRoaW5rIHRoZSBNUkNQIHNlY3Rpb24gaXMgb2suDQoJCQkgDQoJCQlFcmljLCBJIGhh
dmUgbm8gb3RoZXIgdXBkYXRlcyB5ZXQgZm9yIHRoZSBwcm90b2NvbCBjb21wYXJpc29uIGRvY3Vt
ZW50Li4uLg0KCQkJIA0KCQkJUGxlYXNlIG5vdGUgSSBhbSBvbiBob2xpZGF5IChyZWFsIGhvbGlk
YXksIG5vIGNvbXB1dGVycykgMjh0aCBKdW5lIHVudGlsIDE1dGggSnVseSBzbyB3b24ndCBiZSBh
YmxlIHRvIGRvIGFueSB1cGRhdGVzIGFmdGVyIDI4dGggSnVuZS4NCgkJCSANCgkJCUFuZCBmaW5h
bGx5LCBJJ20gYWZyYWlkIEkgd29uJ3QgYmUgYXQgSUVURiBWaWVubmEgKGJ1ZGdldCwgdGltZSBj
b25zdHJhaW50cykuIEkgaG9wZSB5b3UgbWFuYWdlIHRvIGdldCBlbm91Z2ggZm9sayB0byBtYWtl
IHByb2dyZXNzIG9uIFNhcnZpJ3MgcHJvcG9zYWwuLi4uDQoJCQkgDQoJCQlCcmlhbg0KCQkJIA0K
DQoJCQkNCg0KCQkJCS0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KCQkJCURlIDogU2Fydmkg
U2hhbm11Z2hhbSBbbWFpbHRvOnNhcnZpQGNpc2NvLmNvbV0NCgkJCQlFbnZvecOpIDogV2VkbmVz
ZGF5LCBKdW5lIDExLCAyMDAzIDAwOjEyDQoJCQkJw4AgOiBicmlhbi53eWxkQGVsb3F1YW50LmNv
bQ0KCQkJCUNjIDogRXJpYyBCdXJnZXI7IHNwZWVjaHNjQGlldGYub3JnDQoJCQkJT2JqZXQgOiBS
ZTogW1NwZWVjaHNjXSBQcm90b2NvbCBwcm9wb3NhbCBmb3IgU1BFRUNIU0MNCgkJCQkNCgkJCQkN
CgkJCQlIaSBCcmlhbiwNCgkJCQkgICAgICAgICAgICBEb2VzIG15IHNlY3Rpb24gbmVlZCB1cGRh
dGlvbihNUkNQIGV2YWx1dGF0aW9uKSwgaWYgc28gbGV0IG1lIGtub3cgYW5kIEkgd2lsbCBnZXQg
YmFjayBvIHlvdSB3aXRoIHRoZSBlZGl0cyBieSB0aGUgZW5kIG9mIG5leHQgd2Vlay4NCgkJCQkN
CgkJCQlTYXJ2aQ0KCQkJCQ0KCQkJCUJyaWFuIFd5bGQgd3JvdGU6DQoJCQkJDQoNCgkJCQkJT2ss
IGlmIEkgaGF2ZSB0aW1lIEkgd2lsbCBtdW5nZSBzb21ldGhpbmcgdGhydSBhIHdlYiBzZXJ2aWNl
cyB0b29sc2V0IGFuZA0KCQkJCQlwcm9kdWNlIGFuIGFsdGVybmF0aXZlIHByb3Bvc2FsIGJhc2Vk
IG9uIFdTLi4uLi4NCgkJCQkJDQoJCQkJCVRoZW4gYWdhaW4sIG1heWJlIG5vdC4NCgkJCQkJDQoJ
CQkJCVRvIGJlIGZyYW5rLCBpZiB5b3UgYWxsIHdhbnQgU0lQLCBhbmQgSSBkb24ndCBzZWUgbWFu
eSBvdGhlciB2aWV3cG9pbnRzDQoJCQkJCWhlcmUsIHRoZW4gSSdsbCBnbyB3aXRoIHlvdXIgZXhw
ZXJpZW5jZS4gQXMgbG9uZyBhcyB3ZSBjYW4gbW9kZWwgYWxsIHRoZQ0KCQkJCQlkaWZmZXJlbnQg
c2Vzc2lvbiB2aWV3cG9pbnRzIChhcyBhbHJlYWR5IGRpc2N1c3NlZCBoZXJlKSB0aGF0IGFyZSBu
ZWVkZWQgZm9yDQoJCQkJCXVzYWdlIG9mIHRoZSByZXNvdXJjZXMgdGhlbiB0aGF0J3MgZmluZSB3
aXRoIG1lLiAocG9pbnRlcnMgdG8gYSBnb29kIG9wZW4NCgkJCQkJc291cmNlIGphdmEgU0lQIHN0
YWNrIGdyYXRlZnVsbHkgcmVjZWl2ZWQuLi4uKQ0KCQkJCQkNCgkJCQkJU28sIGlzIGFueW9uZSBn
b2luZyB0byB1cGRhdGUgdGhlaXIgc2VjdGlvbnMgZm9yIHRoZSBwcm90b2NvbCBjb21wYXJpc29u
DQoJCQkJCWRvY3VtZW50IGJlZm9yZSB0aGUgMzB0aCBKdW5lIG9yIG5vdD8NCgkJCQkJDQoJCQkJ
CUJyaWFuIChhbm90aGVyIGhhcGxlc3MgdmljdGVtIGNydXNoZWQgYnkgdGhlIFNJUCBqdWdnZXJu
YXVnaHQpDQoJCQkJCQ0KCQkJCQlbQnJpYW4gV3lsZF0gW2JyaWFuLnd5bGRAZWxvcXVhbnQuY29t
XQ0KCQkJCQlbRGlyZWN0ZXVyIEdlbmVyYWwgUiZEXQ0KCQkJCQlbRWxvcXVhbnQgU0FdIFsrMzMg
NDc2IDc3IDQ2IDkyXSBbd3d3LmVsb3F1YW50LmNvbV0NCgkJCQkJW2FkdmFuY2VkIHNvbHV0aW9u
cyBmb3IgdGVsZWNvbXMgYW5kIElUIHNlcnZpY2VzXQ0KCQkJCQkNCgkJCQkJICANCg0KCQkJCQkt
LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCgkJCQkJRGUgOiBFcmljIEJ1cmdlciBbbWFpbHRv
OmVidXJnZXJAc25vd3Nob3JlLmNvbV0NCgkJCQkJRW52b3nDqSA6IFR1ZXNkYXksIEp1bmUgMTAs
IDIwMDMgMjE6MzANCgkJCQkJw4AgOiBicmlhbi53eWxkQGVsb3F1YW50LmNvbTsgc3BlZWNoc2NA
aWV0Zi5vcmcNCgkJCQkJT2JqZXQgOiBSRTogW1NwZWVjaHNjXSBQcm90b2NvbCBwcm9wb3NhbCBm
b3IgU1BFRUNIU0MNCgkJCQkJDQoJCQkJCQ0KCQkJCQkgICAgDQoNCgkJCQkJLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0gRnJvbTogQnJpYW4gV3lsZA0KCQkJCQkgICAgICANCg0KCQkJCQlbbWFp
bHRvOmJyaWFuLnd5bGRAZWxvcXVhbnQuY29tXQ0KCQkJCQkgICAgDQoNCgkJCQkJU2VudDogVHVl
LCBKdW5lIDEwLCAyMDAzIDEyOjE2IFBNDQoJCQkJCSAgICAgIA0KDQoJCQkJCVtzbmlwXQ0KCQkJ
CQkNCgkJCQkJICAgIA0KDQoJCQkJCVNvcnJ5LCBidXQgSSBzdGlsbCB0aGluayB0aGF0IGl0J3Mg
ZWFzaWVyIHRvIHNwZWNpZnkgdGhlIG1lZGlhIHNldHVwDQoJCQkJCXNwZWNpZmljYWxseSAobWF5
YmUgYnkgY3V0LW4tcGFzdGUgZnJvbSBSVFNQKSByYXRoZXIgdGhhbg0KCQkJCQlzdWNrIGluIHRo
ZSBlbnRpcmUNCgkJCQkJU0lQIHByb3RvY29sLg0KCQkJCQkgICAgICANCg0KCQkJCQlJIHdvdWxk
IGJlIHZlcnkgaGVzaXRhbnQgdG8gY3JlYXRlIHlldCBhbm90aGVyICJsb29rcyBsaWtlDQoJCQkJ
CVNJUC9SVFNQLCBzbWVsbHMgbGlrZSBTSVAvUlRTUCwgb3BlcmF0ZXMgbGlrZSBTSVAvUlRTUCwg
YnV0IGhhcyBhDQoJCQkJCWRpZmZlcmVudCBsaWZlIGFuZCBmdXR1cmUgdGhhbiBTSVAvUlRTUC4i
DQoJCQkJCQ0KCQkJCQlJJ2QgbXVjaCByYXRoZXIgbGV2ZXJhZ2UgdGhlIDk3NCBlbmdpbmVlciB5
ZWFycyBvZiB3b3JrIG92ZXIgdGhlDQoJCQkJCWxhc3QgNiB5ZWFycyBwdXQgaW4gdG8gU0lQIHRo
YW4gc3BlbmQgMyBlbmdpbmVlciB5ZWFycyBleHBsYWluaW5nDQoJCQkJCXdoYXQgaXMgdGhlIHNh
bWUgYW5kIGRpZmZlcmVudCBpbiBhIG5ldyBwcm90b2NvbC4gIE1vcmVvdmVyLCBJDQoJCQkJCXdv
dWxkIG5vdCB3YW50IHRvIGZpbmQgbXlzZWxmIHdpc2hpbmcgSSBoYWQgNTAwIGVuZ2luZWVyIHll
YXJzIG9mDQoJCQkJCXJlc291cmNlcyB0byBjYXRjaCB1cCB3aGVuIHNvbWV0aGluZyB1c2VmdWwg
Z2V0cyBpbnRyb2R1Y2VkIGludG8NCgkJCQkJU0lQL1JUU1AgdGhhdCBJIG1pZ2h0IHdhbnQuDQoJ
CQkJCQ0KCQkJCQlTSVAgaXMgYWN0dWFsbHkgcHJldHR5IGdvb2Qgd2hlbiBkZWFsaW5nIHdpdGgg
c21hbGwsIGVtYmVkZGVkDQoJCQkJCWltcGxlbWVudGF0aW9ucy4gIE1vc3QgZXZlcnl0aGluZyBp
cyBhbiBleHRlbnNpb24NCgkJCQkJKCJBY2NlcHQvQWxsb3ciKS4gIFlvdSBkb24ndCBldmVuIG5l
ZWQgdGhlIGxpc3Qgb2YgZXh0ZW5zaW9ucyB0bw0KCQkJCQlzYXksICJJIGRvbid0IGtub3cgd2hh
dCB5b3UgYXJlIHRhbGtpbmcgYWJvdXQuIiAgVGh1cyBhbg0KCQkJCQlTUEVFQ0hTQy1vbmx5IGlt
cGxlbWVudGF0aW9uIGNhbiBiZSBwcmV0dHkgbGlnaHQuICBJdCBpcyB3aGF0IHdlDQoJCQkJCWRv
IGluIHRoZSBtZWRpYSBzZXJ2ZXIgd29ybGQsIGZvciBleGFtcGxlLg0KCQkJCQkNCgkJCQkJICAg
IA0KDQoJCQkJCU1heWJlIHdlIHNob3VsZCBpbnN0ZWFkIHNwZWNpZnkgdGhlIHVzZSBvZiBSVFNQ
IGFzIHRoZSBtZWRpYQ0KCQkJCQlzZXR1cCBhZ2VudCwgYXMNCgkJCQkJbW9zdCBmb2xrcyB3aXRo
IE1SQ1AgZXhwZXJpZW5jZSB3aWxsIGhhdmUgc3VjaCBhbg0KCQkJCQlpbXBsZW1lbnRhdGlvbiBh
bHJlYWR5IGFuZA0KCQkJCQlpdCBpcyBrbm93biB0byBzZXJ2ZSB0aGUgbmVlZHMgb2YgbXJjcC4u
Li4uLg0KCQkJCQkgICAgICANCg0KCQkJCQlJIGNhbiBnbyBlaXRoZXIgd2F5LiAgQXQgdGhpcyBw
b2ludCBvbmUgY291bGQgc3VibWl0IGEgUlRTUC1iYXNlZA0KCQkJCQlTUEVFQ0hTQyBwcm90b2Nv
bCBwcm9wb3NhbCwgc2ltaWxhciB0byBTYXJ2aSdzLiAgQWx0ZXJuYXRlbHksIG9uZQ0KCQkJCQlj
b3VsZCBzdWJtaXQgYSAidGhlc2UgYXJlIHRoZSByZWFzb25zIFJUU1ANCgkJCQkJd29ya3MvaW50
ZXJvcGVyYXRlcy9lYXNpZXItdG8taW1wbGVtZW50IHRoYW4gU0lQIiBkcmFmdC4NCgkJCQkJDQoJ
CQkJCURvIGJlIGF3YXJlIHRoYXQgeW91IGhhdmUgdW50aWwgMDkwMCBVU0EtRVQgdG8gc3VibWl0
IGEgLTAwIGRyYWZ0Lg0KCQkJCQkNCgkJCQkJICAgIA0KDQoJCQkJCUErDQoJCQkJCQ0KCQkJCQlC
cmlhbg0KCQkJCQkNCgkJCQkJUFM+IEkgbm90ZSB0aGF0IHRvIGFjaGlldmUgYW4gb3BlcmF0aW9u
IE1SQ1Agc2VydmVyIHRvZGF5LCBpdA0KCQkJCQlpcyBuZWNjZXNzYXJ5DQoJCQkJCXRvIGltcGxl
bWVudCB2ZXJ5IGxpdHRsZSBvZiBSVFNQIGFuZCBub25lIG9mIHRoZSBtZWRpYSBzdGF0ZQ0KCQkJ
CQltYWNoaW5hcnkgKG5vDQoJCQkJCXBsYXksIHJlY29yZCBldGMpLiBJbiBmYWN0LCBvbmx5IFNF
VFVQIGFuZCBURUFSRE9XTiBhcmUNCgkJCQkJcmVhbGx5IHJlcXVpcmVkLCBhbmQNCgkJCQkJdGhl
ICd0dW5uZWwgbWVzc2FnZScgQU5OT1VOQ0UuLi4uLi4NCgkJCQkJICAgICAgDQoNCgkJCQkJTXkg
cG9pbnQgYWJvdmUsIGV4YWN0bHkuLi4NCgkJCQkJDQoJCQkJCQ0KCQkJCQkgICAgDQoNCgkJCQkJ
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgkJCQkJU3Bl
ZWNoc2MgbWFpbGluZyBsaXN0DQoJCQkJCVNwZWVjaHNjQGlldGYub3JnDQoJCQkJCWh0dHBzOi8v
d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwZWVjaHNjDQoJCQkJCQ0KCQkJCQkgIA0K
DQoNCg==

_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc