From pkyzivat@alum.mit.edu Sun Oct 2 16:01:42 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7552721F8541 for ; Sun, 2 Oct 2011 16:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTJodZHFSURt for ; Sun, 2 Oct 2011 16:01:42 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id CB88421F85A8 for ; Sun, 2 Oct 2011 16:01:41 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta09.westchester.pa.mail.comcast.net with comcast id fyo61h0041YDfWL59z4jSS; Sun, 02 Oct 2011 23:04:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta20.westchester.pa.mail.comcast.net with comcast id fz4h1h00Q0tdiYw3gz4iz8; Sun, 02 Oct 2011 23:04:42 +0000 Message-ID: <4E88EE08.4040600@alum.mit.edu> Date: Sun, 02 Oct 2011 19:04:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <4e7f387f.231b640a.7019.ffff9e63@mx.google.com> In-Reply-To: <4e7f387f.231b640a.7019.ffff9e63@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Support for information about the spacing between monitors. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 23:01:42 -0000 On 9/25/11 10:20 AM, Stephen Botzko wrote: > Ok. So the signaling that is needed is the gap between captures, not the gap between monitors. > > I don't think pixels is the right measure, since the relationship of pixels to distance depends on resolution. > > Steve > > -----Original Message----- > From: Roni Even > Sent: Sunday, September 25, 2011 8:41 AM > To: 'Stephen Botzko' > Cc: 'Duckworth, Mark'; clue@ietf.org > Subject: RE: [clue] Support for information about the spacing between monitors. > > Hi, > > What I mean is that the local capture is fixed based on the gap between the > local monitors such that a person that stands between two cameras will look > correct on the local two displays, There will be a missing part that is > proportional to the gap. This is based on the gaps between the local > monitors. AFAIK the local captures are not normally displayed on the local displays, so the above doesn't compute for me. ISTM that, currently, the local captures are arranged so that they will provide a view such as you describe at the remote room if the remote room as its displays arranged a particular way. (Which happens to be the same way the local displays are arranged.) But the point here is to add more flexibility in matching dissimilar room arrangements. ISTM that this could be handled by defining a virtual display for the scene, and then describing which portion of that virtual scene is covered by each capture. This could allow gaps between the captures, or overlaps. Thanks, Paul > Now if the remote monitors will have the same gap (In pixels) the rendering > on the receiver will look the same as the local display, otherwise the > renderer will need to adjust. > Roni > > > > From: Stephen Botzko [mailto:stephen.botzko@gmail.com] > Sent: Sunday, September 25, 2011 4:21 AM > > > [The entire original message is not included] > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From allyn@cisco.com Sun Oct 2 20:28:34 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E421F1F0C35 for ; Sun, 2 Oct 2011 20:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.833 X-Spam-Level: X-Spam-Status: No, score=-2.833 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xj6-QyvpjHY7 for ; Sun, 2 Oct 2011 20:28:34 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4903321F8634 for ; Sun, 2 Oct 2011 20:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=1076; q=dns/txt; s=iport; t=1317612695; x=1318822295; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=UjkwaT1yWoSIJWHFM/BAb7UTMJpNyoihbmYp+ff1gx0=; b=Bt9ZGFcBhEdhy/r6PWjmZ+i0C3duz584xTqOH5iqaOD+w1F7CdsmlSba WVfGJa7CMa2mo/gqxWroKer6M3e4U8rVgCpjPlT9HtvMhYGf/2rXhU8NV jyDGa1xOe74a8v7P5zhBu0uZ1PjgHCiydYDQfjp7IdbZeAE/J45EI4wGd 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEBAFUsiU6rRDoI/2dsb2JhbABBhGWUG0ONWXSBBYFTAQEBBBIBEA0ENAoFDgYBCBUBBAIGBhcBAgIDAUQHAQYEAQQTCBqgW4EmAYxFkByBLYRhMmEEh3eRF4ww X-IronPort-AV: E=Sophos;i="4.68,478,1312156800"; d="scan'208";a="5536236" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 03 Oct 2011 03:31:33 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p933VX8I020750 for ; Mon, 3 Oct 2011 03:31:33 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 2 Oct 2011 20:31:33 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 2 Oct 2011 20:31:36 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05B7DE73@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-romanow-clue-framework-01.txt Thread-Index: AcyBfNc209efl2npShC1uJ3ejqFLHgAAAs9A From: "Allyn Romanow (allyn)" To: X-OriginalArrivalTime: 03 Oct 2011 03:31:33.0495 (UTC) FILETIME=[F2B7A070:01CC817C] Subject: [clue] FW: New Version Notification for draft-romanow-clue-framework-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 03:28:35 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogU3VuZGF5LCBP Y3RvYmVyIDAyLCAyMDExIDg6MjggUE0NCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt cm9tYW5vdy1jbHVlLWZyYW1ld29yay0wMS50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBBbGx5biBSb21hbm93IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4N Cg0KRmlsZW5hbWU6CSBkcmFmdC1yb21hbm93LWNsdWUtZnJhbWV3b3JrDQpSZXZpc2lvbjoJIDAx DQpUaXRsZToJCSBGcmFtZXdvcmsgZm9yIFRlbGVwcmVzZW5jZSBNdWx0aS1TdHJlYW1zDQpDcmVh dGlvbiBkYXRlOgkgMjAxMS0xMC0wMw0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpO dW1iZXIgb2YgcGFnZXM6IDMyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBtZW1vIG9mZmVycyBhIGZy YW1ld29yayBmb3IgYSBwcm90b2NvbCB0aGF0IGVuYWJsZXMgZGV2aWNlcyBpbiBhDQogICB0ZWxl cHJlc2VuY2UgY29uZmVyZW5jZSB0byBpbnRlcm9wZXJhdGUgYnkgc3BlY2lmeWluZyB0aGUNCiAg IHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBtdWx0aXBsZSBSVFAgc3RyZWFtcy4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From stephen.botzko@gmail.com Mon Oct 3 06:00:46 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732F621F8B1F for ; Mon, 3 Oct 2011 06:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12DT71JVmN+r for ; Mon, 3 Oct 2011 06:00:45 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2676E21F8A96 for ; Mon, 3 Oct 2011 06:00:39 -0700 (PDT) Received: by vws5 with SMTP id 5so4280069vws.31 for ; Mon, 03 Oct 2011 06:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MLBuREmWyCVmz2OtFgoDSfWPwDhlhwVkv64oVp9bmlc=; b=t0N2AK9vsBMaGOWbwPFECpA/9ANkTunaPlhfl2pQj0Coao4118EaGBOA0GsmMOSUXQ BvkREgpkZZIyMdSWIIrOcIZwUS/TQrd2KHVXAfww2mOnNI/+H10m1DBmwfYos/Rn8r+2 2H4QjUnyHM6lSso7g5mtegQ2PT+P3p0pnMBss= MIME-Version: 1.0 Received: by 10.52.65.82 with SMTP id v18mr8680058vds.199.1317647021155; Mon, 03 Oct 2011 06:03:41 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Mon, 3 Oct 2011 06:03:40 -0700 (PDT) In-Reply-To: <4E88EE08.4040600@alum.mit.edu> References: <4e7f387f.231b640a.7019.ffff9e63@mx.google.com> <4E88EE08.4040600@alum.mit.edu> Date: Mon, 3 Oct 2011 09:03:40 -0400 Message-ID: From: Stephen Botzko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=20cf3071cc5ca2a4bc04ae649af3 Cc: clue@ietf.org Subject: Re: [clue] Support for information about the spacing between monitors. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 13:00:46 -0000 --20cf3071cc5ca2a4bc04ae649af3 Content-Type: text/plain; charset=ISO-8859-1 Note that section 5.2.4 in the 01 framework draft provides a mechanism for signaling gaps between captures. Regards, Steve On Sun, Oct 2, 2011 at 7:04 PM, Paul Kyzivat wrote: > On 9/25/11 10:20 AM, Stephen Botzko wrote: > >> Ok. So the signaling that is needed is the gap between captures, not the >> gap between monitors. >> >> I don't think pixels is the right measure, since the relationship of >> pixels to distance depends on resolution. >> >> Steve >> >> -----Original Message----- >> From: Roni Even >> Sent: Sunday, September 25, 2011 8:41 AM >> To: 'Stephen Botzko' >> > >> Cc: 'Duckworth, Mark'>; >> clue@ietf.org >> Subject: RE: [clue] Support for information about the spacing between >> monitors. >> >> Hi, >> >> What I mean is that the local capture is fixed based on the gap between >> the >> local monitors such that a person that stands between two cameras will >> look >> correct on the local two displays, There will be a missing part that is >> proportional to the gap. This is based on the gaps between the local >> monitors. >> > > AFAIK the local captures are not normally displayed on the local displays, > so the above doesn't compute for me. > > ISTM that, currently, the local captures are arranged so that they will > provide a view such as you describe at the remote room if the remote room as > its displays arranged a particular way. (Which happens to be the same way > the local displays are arranged.) > > But the point here is to add more flexibility in matching dissimilar room > arrangements. > > ISTM that this could be handled by defining a virtual display for the > scene, and then describing which portion of that virtual scene is covered by > each capture. This could allow gaps between the captures, or overlaps. > > Thanks, > Paul > > > Now if the remote monitors will have the same gap (In pixels) the >> rendering >> on the receiver will look the same as the local display, otherwise the >> renderer will need to adjust. >> > > > Roni >> >> >> >> From: Stephen Botzko [mailto:stephen.botzko@gmail.**com >> ] >> Sent: Sunday, September 25, 2011 4:21 AM >> >> >> [The entire original message is not included] >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/**listinfo/clue >> >> > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --20cf3071cc5ca2a4bc04ae649af3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Note that section 5.2.4 in the 01 framework draft provides a mechanism for = signaling gaps between captures.

Regards,
Steve

On Sun, Oct 2, 2011 at 7:04 PM, Paul Kyzivat <pkyzivat@alum.mit.edu= > wrote:
On 9/25/11 10:20 AM, Step= hen Botzko wrote:
Ok. =A0So the signaling that is needed is the gap between captures, not the= gap between monitors.

I don't think pixels is the right measure, since the relationship of pi= xels to distance depends on resolution.

Steve

-----Original Message-----
From: Roni Even<Even.roni@huawei.com>
Sent: Sunday, September 25, 2011 8:41 AM
To: 'Stephen Botzko'<stephen.botzko@gmail.com>
Cc: 'Duckworth, Mark'<Mark.Duckworth@polycom.com>; clue@ietf.org
Subject: RE: [clue] Support for information about the spacing between monit= ors.

Hi,

What I mean is that the local capture is fixed based on the gap between the=
local monitors such that a person that stands between two cameras will look=
correct on the local two displays, There will be a missing part that is
proportional =A0to the gap. This is based on the gaps between the local
monitors.

AFAIK the local captures are not normally displayed on the local displays, = so the above doesn't compute for me.

ISTM that, currently, the local captures are arranged so that they will pro= vide a view such as you describe at the remote room if the remote room as i= ts displays arranged a particular way. (Which happens to be the same way th= e local displays are arranged.)

But the point here is to add more flexibility in matching dissimilar room a= rrangements.

ISTM that this could be handled by defining a virtual display for the scene= , and then describing which portion of that virtual scene is covered by eac= h capture. This could allow gaps between the captures, or overlaps.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul


Now if the remote monitors will have the same gap (In pixels) the rendering=
on the receiver will look the same as the local display, otherwise the
renderer will need to adjust.


Roni



From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
Sent: Sunday, September 25, 2011 4:21 AM


[The entire original message is not included]
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf3071cc5ca2a4bc04ae649af3-- From Christian.Groves@nteczone.com Mon Oct 3 20:02:16 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FBD21F8E30 for ; Mon, 3 Oct 2011 20:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly50OcRnJgNE for ; Mon, 3 Oct 2011 20:02:16 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF5821F8E34 for ; Mon, 3 Oct 2011 20:02:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoAAJ11ik520T5j/2dsb2JhbAAMNphxkWsBAQEBAwEBATUbFQYEBQEBDAQLFQECCRYIBwkDAgECARUfCAkGDQEFAgEBh324JAOHIQSlNQ Received: from ppp118-209-62-99.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.62.99]) by ipmail04.adl6.internode.on.net with ESMTP; 04 Oct 2011 13:35:17 +1030 Message-ID: <4E8A77E1.1090608@nteczone.com> Date: Tue, 04 Oct 2011 14:05:05 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Allyn Romanow (allyn)" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05B7DE73@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05B7DE73@xmb-sjc-221.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-framework-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 03:02:16 -0000 Hello Allyn, all, Thanks for posting the updated version. Glad to see the inclusion of spatial information attributes. A few questions/comments: 5.2.1 Presentation (Nit) - I guess rather than talk about "stream" should it say "media capture"? 5.2.2 Audio Mixed / Video Composed - I wondering if it necessary to distinguish between these attributes particularly as they are both boolean. You know what type the media capture is, i.e. audio or video. The key point of the attribute is to indicate whether or not the media capture is made up from multiple sources. Could we simply have a "mixed/composed" attribute instead of two? i.e. auto switched applies to both ACs and VCs. 5.2.4 and 5.2.5, not explicitly stated in the text, I assume that both the area and point of capture must both have a common x,y,z origin? 5.2.4 and 5.2.5 also related to the origin and numbering, what is the assumption here? Area of Capture only stipulates that the numbers go from lower to higher this could mean positive (e.g. area_of_capture={xBegin=0, xEnd=100}) and/or negative numbers (e.g. area_of_capture={xBegin=-50, xEnd=50}) can be supported?? 5.2.4 - Do we need to consider the range start and end when determining the area of capture? Consider the example Capture Scene(VC0,VC1,VC2) where: o VC0- (the left camera stream), area_of_capture={xBegin=0, xEnd=33} o VC1- (the center camera stream), area_of_capture={xBegin=33, xEnd=66} o VC2- (the right camera stream), area_of_capture={xBegin=66, xEnd=99} This example is clear each capture relates to 1/3 of the overall capture scene. Now if instead the capture scene (VC1) was sent. How does the renderer put this in context? VC1 is the center capture (thus only 1/3 of the providers overall capability). The renderer will receieve xBegin=33 and xEnd=66 only and thus conclude its 100% of the capture scene. Do we need a means to indicate that the total area is 0 to 99 but the current capture only relates to a subset? 5.2.6 Just to clarify if "area scale millimeters" = FALSE, then numbers used are relational only? The text doesn't make this explicit. 6.1 : Is it intended that this same message flow be used for "re-negotiation" when media captures come and go as per the requirements document? Section 7.1 hints at this i.e. "the MCU might re-advertise the available media". It would be good if there could be some explicit text regarding re-negotiation. 6.1.x - Perhaps the section can be re-ordered to align with the message flow? 6.1.2 Consumer Capability Message - Is the intention to provide detailed information regarding the attribute values or simply a boolean to say which parameters are supported? 7.2.2 Nit : seems to be a superflous "v" above the list. Regards, Christian On 3/10/2011 2:31 PM, Allyn Romanow (allyn) wrote: > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Sunday, October 02, 2011 8:28 PM > > > A new version of I-D, draft-romanow-clue-framework-01.txt has been successfully submitted by Allyn Romanow and posted to the IETF repository. > > Filename: draft-romanow-clue-framework > Revision: 01 > Title: Framework for Telepresence Multi-Streams > Creation date: 2011-10-03 > WG ID: Individual Submission > Number of pages: 32 > > Abstract: > This memo offers a framework for a protocol that enables devices in a > telepresence conference to interoperate by specifying the > relationships between multiple RTP streams. > > > > > The IETF Secretariat > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Mon Oct 3 22:23:35 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B33D21F8F37 for ; Mon, 3 Oct 2011 22:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id il228HQM1fon for ; Mon, 3 Oct 2011 22:23:34 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by ietfa.amsl.com (Postfix) with ESMTP id 88A3421F8F15 for ; Mon, 3 Oct 2011 22:23:34 -0700 (PDT) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta13.emeryville.ca.mail.comcast.net with comcast id gVQH1h0051eYJf8ADVSY1P; Tue, 04 Oct 2011 05:26:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([205.168.243.143]) by omta19.emeryville.ca.mail.comcast.net with comcast id gVM51h00T36M3z901VM8AU; Tue, 04 Oct 2011 05:21:15 +0000 Message-ID: <4E8A9902.8000103@alum.mit.edu> Date: Tue, 04 Oct 2011 01:26:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Stephen Botzko References: <4e7f387f.231b640a.7019.ffff9e63@mx.google.com> <4E88EE08.4040600@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Support for information about the spacing between monitors. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 05:23:35 -0000 On 10/3/11 9:03 AM, Stephen Botzko wrote: > Note that section 5.2.4 in the 01 framework draft provides a mechanism > for signaling gaps between captures. OK, what that describes works for me. Thanks, Paul > Regards, > Steve > > On Sun, Oct 2, 2011 at 7:04 PM, Paul Kyzivat > wrote: > > On 9/25/11 10:20 AM, Stephen Botzko wrote: > > Ok. So the signaling that is needed is the gap between > captures, not the gap between monitors. > > I don't think pixels is the right measure, since the > relationship of pixels to distance depends on resolution. > > Steve > > -----Original Message----- > From: Roni Even> > Sent: Sunday, September 25, 2011 8:41 AM > To: 'Stephen Botzko' > > Cc: 'Duckworth, Mark' >; clue@ietf.org > > Subject: RE: [clue] Support for information about the spacing > between monitors. > > Hi, > > What I mean is that the local capture is fixed based on the gap > between the > local monitors such that a person that stands between two > cameras will look > correct on the local two displays, There will be a missing part > that is > proportional to the gap. This is based on the gaps between the > local > monitors. > > > AFAIK the local captures are not normally displayed on the local > displays, so the above doesn't compute for me. > > ISTM that, currently, the local captures are arranged so that they > will provide a view such as you describe at the remote room if the > remote room as its displays arranged a particular way. (Which > happens to be the same way the local displays are arranged.) > > But the point here is to add more flexibility in matching dissimilar > room arrangements. > > ISTM that this could be handled by defining a virtual display for > the scene, and then describing which portion of that virtual scene > is covered by each capture. This could allow gaps between the > captures, or overlaps. > > Thanks, > Paul > > > Now if the remote monitors will have the same gap (In pixels) > the rendering > on the receiver will look the same as the local display, > otherwise the > renderer will need to adjust. > > > > Roni > > > > From: Stephen Botzko [mailto:stephen.botzko@gmail.__com > ] > Sent: Sunday, September 25, 2011 4:21 AM > > > [The entire original message is not included] > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > From Mark.Duckworth@polycom.com Tue Oct 4 08:38:56 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C73021F8B07 for ; Tue, 4 Oct 2011 08:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqyXabHRYQjG for ; Tue, 4 Oct 2011 08:38:55 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 88AB021F8B08 for ; Tue, 4 Oct 2011 08:38:53 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Tue, 4 Oct 2011 08:41:53 -0700 From: "Duckworth, Mark" To: Christian Groves Date: Tue, 4 Oct 2011 08:41:50 -0700 Thread-Topic: [clue] FW: New Version Notification for draft-romanow-clue-framework-01.txt Thread-Index: AcyCQnZFM95kgzLBQBiynZVke8fdbgAZqe8A Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61CDF40F79@CRPMBOXPRD01.polycom.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05B7DE73@xmb-sjc-221.amer.cisco.com> <4E8A77E1.1090608@nteczone.com> In-Reply-To: <4E8A77E1.1090608@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-framework-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 15:38:56 -0000 Hello Christian, Thanks for the comments. My comments are inline. Mark Duckworth > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Monday, October 03, 2011 11:05 PM > To: Allyn Romanow (allyn) > Cc: clue@ietf.org > Subject: Re: [clue] FW: New Version Notification for draft-romanow- > clue-framework-01.txt >=20 > Hello Allyn, all, >=20 > Thanks for posting the updated version. Glad to see the inclusion of > spatial information attributes. A few questions/comments: > > 5.2.1 Presentation (Nit) - I guess rather than talk about "stream" > should it say "media capture"? [Duckworth, Mark] agreed =20 > 5.2.2 Audio Mixed / Video Composed - I wondering if it necessary to > distinguish between these attributes particularly as they are both > boolean. You know what type the media capture is, i.e. audio or video. > The key point of the attribute is to indicate whether or not the media > capture is made up from multiple sources. Could we simply have a > "mixed/composed" attribute instead of two? i.e. auto switched applies > to > both ACs and VCs. [Duckworth, Mark] I had the same thought. Audio Mixed and Video Composed a= re really the same concept, and it can be generalized to any media type. =20 > 5.2.4 and 5.2.5, not explicitly stated in the text, I assume that both > the area and point of capture must both have a common x,y,z origin? [Duckworth, Mark] Yes, I think that should be clarified. > 5.2.4 and 5.2.5 also related to the origin and numbering, what is the > assumption here? Area of Capture only stipulates that the numbers go > from lower to higher this could mean positive (e.g. > area_of_capture=3D{xBegin=3D0, xEnd=3D100}) and/or negative numbers (e.g. > area_of_capture=3D{xBegin=3D-50, xEnd=3D50}) can be supported?? [Duckworth, Mark] I agree this needs to be clarified. I'm not sure what th= e best answer is. At first, I was thinking we should restrict the numbers = to positive integers, but I'm not sure. > 5.2.4 - Do we need to consider the range start and end when determining > the area of capture? Consider the example Capture Scene(VC0,VC1,VC2) > where: > o VC0- (the left camera stream), area_of_capture=3D{xBegin=3D0, > xEnd=3D33} > o VC1- (the center camera stream), area_of_capture=3D{xBegin=3D33, > xEnd=3D66} > o VC2- (the right camera stream), area_of_capture=3D{xBegin=3D66, > xEnd=3D99} > This example is clear each capture relates to 1/3 of the overall > capture > scene. >=20 > Now if instead the capture scene (VC1) was sent. How does the renderer > put this in context? VC1 is the center capture (thus only 1/3 of the > providers overall capability). The renderer will receieve xBegin=3D33 and > xEnd=3D66 only and thus conclude its 100% of the capture scene. Do we > need > a means to indicate that the total area is 0 to 99 but the current > capture only relates to a subset? [Duckworth, Mark] I don't think the renderer will reach that conclusion. T= he immediate consumer will know about the whole range 0 to 99 from the capt= ure set. If the immediate consumer is also the renderer, then the renderer= knows. If the immediate consumer is a middlebox, then that middlebox beco= mes the provider for the next consumer (renderer). The middlebox construct= s its own media captures and capture set with its own area of capture attri= butes. These attributes may or may not be the same as from the original pr= oviders. The middlebox advertises captures and a capture set with attribut= es that make sense for whatever behavior the middlebox is trying to provide= . So the ultimate consumer (the renderer) will know about attributes that = make sense in this context from the middlebox. This consumer doesn't know = about any of the attributes from the original producer, it only knows the a= ttributes from the middle box. > 5.2.6 Just to clarify if "area scale millimeters" =3D FALSE, then numbers > used are relational only? The text doesn't make this explicit. [Duckworth, Mark] I think so. The text says "there is no physical scale". = Does that imply the same thing? > 6.1 : Is it intended that this same message flow be used for > "re-negotiation" when media captures come and go as per the > requirements > document? Section 7.1 hints at this i.e. "the MCU might re-advertise > the > available media". It would be good if there could be some explicit text > regarding re-negotiation. [Duckworth, Mark] Yes, this is mentioned in section 5.1, paragraph 2. Mayb= e that text from 5.1 really belongs in 6.1, with a bit more clarification. =20 > 6.1.x - Perhaps the section can be re-ordered to align with the message > flow? [Duckworth, Mark] I agree some re-ordering of sections might help. > 6.1.2 Consumer Capability Message - Is the intention to provide > detailed > information regarding the attribute values or simply a boolean to say > which parameters are supported? [Duckworth, Mark] We're not sure of the details yet. Needs more thought. =20 > 7.2.2 Nit : seems to be a superflous "v" above the list. [Duckworth, Mark] I noticed too. Regards, Mark Duckworth From Christian.Groves@nteczone.com Tue Oct 4 20:31:20 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296CC21F8B0C for ; Tue, 4 Oct 2011 20:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRTZR686mjB8 for ; Tue, 4 Oct 2011 20:31:19 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 23C5321F8A4E for ; Tue, 4 Oct 2011 20:31:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBABjPi0520d2X/2dsb2JhbAAMNqpoAQEBAQIBOBsfBQIQCyElDwI9CQYNAQcBAYd5txSHIwSlPw Received: from ppp118-209-221-151.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.221.151]) by ipmail05.adl6.internode.on.net with ESMTP; 05 Oct 2011 14:04:24 +1030 Message-ID: <4E8BD034.40300@nteczone.com> Date: Wed, 05 Oct 2011 14:34:12 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Duckworth, Mark" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05B7DE73@xmb-sjc-221.amer.cisco.com> <4E8A77E1.1090608@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A61CDF40F79@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61CDF40F79@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "clue@ietf.org" Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-framework-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 03:31:20 -0000 Hello Mark, Thanks for your reply please see my comments below marked [CNG]. Regards, Christian =2E.snip.. >> 5.2.4 and 5.2.5 also related to the origin and numbering, what is the >> assumption here? Area of Capture only stipulates that the numbers go >> from lower to higher this could mean positive (e.g. >> area_of_capture=3D{xBegin=3D0, xEnd=3D100}) and/or negative numbers (e= =2Eg. >> area_of_capture=3D{xBegin=3D-50, xEnd=3D50}) can be supported?? > [Duckworth, Mark] I agree this needs to be clarified. I'm not sure wha= t the best answer is. At first, I was thinking we should restrict the nu= mbers to positive integers, but I'm not sure. [CNG] I think this is also related to the point below about can the=20 start of a range be assumed? i.e. if we only support 0 and up, the=20 renderer could assume that the start of a range is always 0. > >> 5.2.4 - Do we need to consider the range start and end when determinin= g >> the area of capture? Consider the example Capture Scene(VC0,VC1,VC2) >> where: >> o VC0- (the left camera stream), area_of_capture=3D{xBegin=3D0, >> xEnd=3D33} >> o VC1- (the center camera stream), area_of_capture=3D{xBegin=3D3= 3, >> xEnd=3D66} >> o VC2- (the right camera stream), area_of_capture=3D{xBegin=3D66= , >> xEnd=3D99} >> This example is clear each capture relates to 1/3 of the overall >> capture >> scene. >> >> Now if instead the capture scene (VC1) was sent. How does the renderer= >> put this in context? VC1 is the center capture (thus only 1/3 of the >> providers overall capability). The renderer will receieve xBegin=3D33 = and >> xEnd=3D66 only and thus conclude its 100% of the capture scene. Do we >> need >> a means to indicate that the total area is 0 to 99 but the current >> capture only relates to a subset? > [Duckworth, Mark] I don't think the renderer will reach that conclusion= =2E The immediate consumer will know about the whole range 0 to 99 from = the capture set. If the immediate consumer is also the renderer, then th= e renderer knows. If the immediate consumer is a middlebox, then that mi= ddlebox becomes the provider for the next consumer (renderer). The middl= ebox constructs its own media captures and capture set with its own area = of capture attributes. These attributes may or may not be the same as fr= om the original providers. The middlebox advertises captures and a captu= re set with attributes that make sense for whatever behavior the middlebo= x is trying to provide. So the ultimate consumer (the renderer) will kno= w about attributes that make sense in this context from the middlebox. T= his consumer doesn't know about any of the attributes from the original p= roducer, it only knows the attributes from the middle box. [CNG] I think I wasn't clear in my example. What happens if the received = capture set only contains VC1 and the consumer didn't previously get a=20 capture set (VC0,VC1,VC2)? The middlebox, consumer etc. wouldn't know=20 that "area_of_capture=3D{xBegin=3D33,xEnd=3D66}" represents the centre re= gion=20 of a range (0..99). I agree these parameters may be altered along the signalling path. > >> 5.2.6 Just to clarify if "area scale millimeters" =3D FALSE, then numb= ers >> used are relational only? The text doesn't make this explicit. > [Duckworth, Mark] I think so. The text says "there is no physical scal= e". Does that imply the same thing? [CNG] I guess it a style things and being bitten before. If there's two=20 values (even boolean) I prefer to say what TRUE and FALSE mean rather=20 than deriving a meaning of a value from the other. > >> 6.1 : Is it intended that this same message flow be used for >> "re-negotiation" when media captures come and go as per the >> requirements >> document? Section 7.1 hints at this i.e. "the MCU might re-advertise >> the >> available media". It would be good if there could be some explicit tex= t >> regarding re-negotiation. > [Duckworth, Mark] Yes, this is mentioned in section 5.1, paragraph 2. = Maybe that text from 5.1 really belongs in 6.1, with a bit more clarifica= tion. [CNG] That would be good. > >> 6.1.x - Perhaps the section can be re-ordered to align with the messag= e >> flow? > [Duckworth, Mark] I agree some re-ordering of sections might help. > >> 6.1.2 Consumer Capability Message - Is the intention to provide >> detailed >> information regarding the attribute values or simply a boolean to say >> which parameters are supported? > [Duckworth, Mark] We're not sure of the details yet. Needs more though= t. [CNG] OK =2E.snip.. From Even.roni@huawei.com Tue Oct 4 23:03:00 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72AD21F8669 for ; Tue, 4 Oct 2011 23:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.328 X-Spam-Level: X-Spam-Status: No, score=-106.328 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw8n-3WUpi3X for ; Tue, 4 Oct 2011 23:02:59 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD0121F84A3 for ; Tue, 4 Oct 2011 23:02:59 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSK0075FWXYG6@szxga05-in.huawei.com> for clue@ietf.org; Wed, 05 Oct 2011 14:05:58 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSK00EA5WXX8E@szxga05-in.huawei.com> for clue@ietf.org; Wed, 05 Oct 2011 14:05:58 +0800 (CST) Received: from windows8d787f9 (bzq-109-64-200-234.red.bezeqint.net [109.64.200.234]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LSK00HA8WXSRR@szxml12-in.huawei.com> for clue@ietf.org; Wed, 05 Oct 2011 14:05:57 +0800 (CST) Date: Wed, 05 Oct 2011 08:03:11 +0200 From: Roni Even To: clue@ietf.org Message-id: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_3p8loXdAXmG/ewTnlJmm2w)" Content-language: en-us Thread-index: AcyDJHXTd/dmWtWGTle0G/txbwllmw== Subject: [clue] Area of capture attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 06:03:00 -0000 This is a multi-part message in MIME format. --Boundary_(ID_3p8loXdAXmG/ewTnlJmm2w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I read the new revision and I think that this attribute is a good starting point to address the discussion on the spatial description. I hope that we will be able to finalize the model in the Interim meeting. I started a new thread after seeing the comments from Christian and Mark. I will send more feedback on the draft in a separate email. I think that there is some information missing that will be helpful 1. The position of the origin of the axis and the full range of the area is needed probably as a capture set attribute in order to understand the view. For example having a VC that says (0,33) does not provide enough information to know what part of the room it covers. I do not think that saying that there will be one configuration for example (VC1 (0,33), VC2(33,66),VC3(66,99)) is the right way since it requires to have such configuration and it also means that the range is (0,99) while it may also be covering part of a (-10,110) range. The major requirement is not to use implied information but be explicit. 2. I think that it is important not only to have the X coordinates but also have the Y coordinates to be able to know if there is a gap or overlap at the relevant distance. Again the origin of the axes is crucial here. 3. I am not sure about the example in section 7 for the active speaker (VC3) "VC3- (the loudest panel stream), encoding group:EG1, attributes:purpose=main;auto-switched:yes; area_of_capture={xBegin=0, xEnd=99}". How do you know what is the area of capture you are really getting, my understanding is that it is implied that there are VC0,VC1 and VC2 and you get one of them. Again, I prefer explicit information for this case even if it means having at attribute that will specify that the switch is between VC0, VC1 and VC2 or have it as part of the auto-switch attribute. Regards Roni _____ --Boundary_(ID_3p8loXdAXmG/ewTnlJmm2w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

I read the new = revision and I think that this attribute is a good starting point to = address the discussion on the spatial description. I hope that we will = be able to finalize the model in the Interim meeting.

 

I started a = new thread after seeing the comments from Christian and = Mark.

I will send more feedback on = the draft in a separate email.

 

I think that = there is some information missing that will be helpful

 

1.       = The position of the = origin of the axis  and the full range of the area is needed = probably as a capture set attribute in order to understand the view. For = example having a VC that says (0,33) does not provide enough information = to know what part of the room it covers. I do not think that saying that = there will be one configuration for example (VC1 (0,33), = VC2(33,66),VC3(66,99)) is the right way since it requires to have such = configuration and it also means that the range is (0,99) while it may = also be covering part of a (-10,110) range. The major requirement is not = to use implied information but be explicit.

2.       = I think that it is = important not only to have the X coordinates but also have the Y = coordinates to be able to know if there is a gap or overlap at the = relevant distance. Again the origin of the axes is crucial = here.

3.       = I am not sure about the = example in section 7 for the active speaker (VC3) "VC3- (the = loudest panel stream), encoding group:EG1, = attributes:purpose=3Dmain;auto-switched:yes; = area_of_capture=3D{xBegin=3D0,  xEnd=3D99}". How do you know = what is the area of capture you are really getting, my understanding is = that it is  implied that there are VC0,VC1 and VC2 and you get one = of them. Again, I prefer explicit information for this case even if it = means having at attribute that will specify that the switch is between = VC0, VC1 and VC2 or have it as part of the auto-switch = attribute.

 

Regards

Roni

 

= --Boundary_(ID_3p8loXdAXmG/ewTnlJmm2w)-- From marshall.eubanks@gmail.com Wed Oct 5 07:02:00 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A3221F8BD7 for ; Wed, 5 Oct 2011 07:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.259 X-Spam-Level: X-Spam-Status: No, score=-103.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jqD9Rde8gWP for ; Wed, 5 Oct 2011 07:02:00 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 258EE21F8BCB for ; Wed, 5 Oct 2011 07:02:00 -0700 (PDT) Received: by yxt33 with SMTP id 33so1960246yxt.31 for ; Wed, 05 Oct 2011 07:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IkSTtpc067GqQJoRuNRP977/252Y0CCvMWrc904HUWE=; b=isgWnbw52wTgHAYbmB4j8lfGlftRv0zV+QBYQZtv1dgGjzEv3E0hwX0ir8kd2eyR7y QDvQbvsBigW20Bi9wdU7k1L3ZPVY00KjBpOfx28yXKA01XvIhCdaoQI0Zvyjy+UpIaoQ Xv0/mrBX57oEhfK6ot2gJP55iQQ1PqmQm9xaM= MIME-Version: 1.0 Received: by 10.150.73.31 with SMTP id v31mr2308755yba.26.1317823508050; Wed, 05 Oct 2011 07:05:08 -0700 (PDT) Received: by 10.151.98.20 with HTTP; Wed, 5 Oct 2011 07:05:07 -0700 (PDT) In-Reply-To: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> References: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> Date: Wed, 5 Oct 2011 10:05:08 -0400 Message-ID: From: Marshall Eubanks To: Roni Even Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: clue@ietf.org Subject: Re: [clue] Area of capture attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 14:02:00 -0000 On Wed, Oct 5, 2011 at 2:03 AM, Roni Even wrote: > Hi, > > I read the new revision and I think that this attribute is a good startin= g > point to address the discussion on the spatial description. I hope that w= e > will be able to finalize the model in the Interim meeting. > > > > I started a new thread after seeing the comments from Christian and Mark. > > I will send more feedback on the draft in a separate email. > > > > I think that there is some information missing that will be helpful > > > > 1.=A0=A0=A0=A0=A0=A0 The position of the origin of the axis =A0and the fu= ll range of the > area is needed probably as a capture set attribute in order to understand > the view. For example having a VC that says (0,33) does not provide enoug= h > information to know what part of the room it covers. I do not think that > saying that there will be one configuration for example (VC1 (0,33), > VC2(33,66),VC3(66,99)) is the right way since it requires to have such > configuration and it also means that the range is (0,99) while it may als= o > be covering part of a (-10,110) range. The major requirement is not to us= e > implied information but be explicit. > > 2.=A0=A0=A0=A0=A0=A0 I think that it is important not only to have the X = coordinates but > also have the Y coordinates to be able to know if there is a gap or overl= ap > at the relevant distance. Again the origin of the axes is crucial here. > I agree with both of these, which of course were both covered in my original message on this subject. Obviously, it takes 2 axes to define an area. (There are 4:3 and 16:9 capture / render devices out there, so already just knowing the horizontal doesn't mean you know the vertical. > 3.=A0=A0=A0=A0=A0=A0 I am not sure about the example in section 7 for the= active speaker > (VC3) "VC3- (the loudest panel stream), encoding group:EG1, > attributes:purpose=3Dmain;auto-switched:yes; area_of_capture=3D{xBegin=3D= 0, > xEnd=3D99}". How do you know what is the area of capture you are really > getting, my understanding is that it is =A0implied that there are VC0,VC1= and > VC2 and you get one of them. Again, I prefer explicit information for thi= s > case even if it means having at attribute that will specify that the swit= ch > is between VC0, VC1 and VC2 or have it as part of the auto-switch attribu= te. > I assumed that the 0-99 range meant that it was switched and could be anywhere within that range. I think that that is confusing and not very informative - wouldn't it make more sense to have a switched capture scene be virtual, something like VC3- (the loudest panel stream), encoding group:EG1, attributes: purpose=3Dmain;auto-switched:yes; area_of_capture=3D{one_of{VC0, VC1, VC2}} with a restriction that "one_of" lists MUST NOT be self-referential. Regards Marshall > > > Regards > > Roni > > > > ________________________________ > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From bbaldino@cisco.com Wed Oct 5 10:39:52 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBE41F0C68 for ; Wed, 5 Oct 2011 10:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_101=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVM4p6UriXn7 for ; Wed, 5 Oct 2011 10:39:49 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id BC83C1F0C49 for ; Wed, 5 Oct 2011 10:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bbaldino@cisco.com; l=18847; q=dns/txt; s=iport; t=1317836578; x=1319046178; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=p3O+/+1TSNFz/NL/vzzRtJTuh6fRgBOB4BQsIYA9BGA=; b=FO9c/JapRqxtVVwOLw907IxsoaXB3OOnt/vqrpGEbMqgmrgyMJ1624JD B404hUAry/gTDKsv1RumhqU0w62qxWreOzdeKhrYKjfKag9ZWUdab7cCL Nsk72KFOhhM7X9thcea1p5xxm1+mS52J+ixFj2quomwwdRSLrgasIV6OI s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUAANeVjE6rRDoH/2dsb2JhbABCgk2WM48UgQWBUwEBAQEDEgEJEQNZAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqhTAGeEoZIYQSHfJEhjDQ X-IronPort-AV: E=Sophos;i="4.68,492,1312156800"; d="scan'208,217";a="6112082" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 05 Oct 2011 17:42:58 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p95HgsRB011257; Wed, 5 Oct 2011 17:42:57 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 10:42:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: vIw= A+sY ClHz C+RB DTRj E+lU GC01 G7yq HWYX I81b KG9J LFcI PQLy Q9o7 RLrP V860; 2; YwBsAHUAZQBAAGkAZQB0AGYALgBvAHIAZwA7AGUAdgBlAG4ALgByAG8AbgBpAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Sosha1_v1; 7; {5E49CA3D-9A8A-4CC2-980B-E9FAC3A247E2}; YgBiAGEAbABkAGkAbgBvAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Wed, 05 Oct 2011 17:42:47 GMT; UgBFADoAIABbAGMAbAB1AGUAXQAgAEEAcgBlAGEAIABvAGYAIABjAGEAcAB0AHUAcgBlACAAYQB0AHQAcgBpAGIAdQB0AGUA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8386.3730CFDE" x-cr-puzzleid: {5E49CA3D-9A8A-4CC2-980B-E9FAC3A247E2} Content-class: urn:content-classes:message Date: Wed, 5 Oct 2011 10:42:47 -0700 Message-ID: In-Reply-To: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Area of capture attribute thread-index: AcyDJHXTd/dmWtWGTle0G/txbwllmwAWem4g References: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> From: "Brian Baldino (bbaldino)" To: "Roni Even" , X-OriginalArrivalTime: 05 Oct 2011 17:42:56.0719 (UTC) FILETIME=[378485F0:01CC8386] Subject: Re: [clue] Area of capture attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 17:39:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8386.3730CFDE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey Roni, Took my best shot inline. -Brian =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Tuesday, October 04, 2011 11:03 PM To: clue@ietf.org Subject: [clue] Area of capture attribute =20 Hi, I read the new revision and I think that this attribute is a good starting point to address the discussion on the spatial description. I hope that we will be able to finalize the model in the Interim meeting. =20 I started a new thread after seeing the comments from Christian and Mark. I will send more feedback on the draft in a separate email. =20 I think that there is some information missing that will be helpful =20 1. The position of the origin of the axis and the full range of the area is needed probably as a capture set attribute in order to understand the view. For example having a VC that says (0,33) does not provide enough information to know what part of the room it covers. I do not think that saying that there will be one configuration for example (VC1 (0,33), VC2(33,66),VC3(66,99)) is the right way since it requires to have such configuration and it also means that the range is (0,99) while it may also be covering part of a (-10,110) range. The major requirement is not to use implied information but be explicit. [BB] I think I agree that this might be useful, but, I'm not sure we've come up with a use case that really demands it yet. Let me see if what I have in mind for what you described (and why the origin and full range up front aren't needed there) makes sense: I'm not sure what you've described (an advertiser only offering a single video capture VC0(0,33)) would be that common (as, like you said, it isn't very useful) but if it did, I still think the renderer could render it sensibly. Since there are no other captures advertised, the renderer does not need to be careful about rendering the VC in a certain position relative to other captures from that same device because there are none. In your example: if a 3 camera endpoint only advertised its left camera as VC0(0,33) a 3 screen endpoint on the other end could render it wherever it wanted because its main concern (making sure cameras from a multi-camera transmitter are placed correctly relative to one another) is no longer an issue. Perhaps there is a scenario unlike what I've just described where, even though only one small subset of the entire device was advertised, it was important to render it in exactly one place. Do you know of an example where that may be the case? 2. I think that it is important not only to have the X coordinates but also have the Y coordinates to be able to know if there is a gap or overlap at the relevant distance. Again the origin of the axes is crucial here. [BB] The document provides for describing the area of capture in up to 3 dimensions(x, y and z); seems like that gives the flexibility you're looking for? =20 3. I am not sure about the example in section 7 for the active speaker (VC3) "VC3- (the loudest panel stream), encoding group:EG1, attributes:purpose=3Dmain;auto-switched:yes; = area_of_capture=3D{xBegin=3D0, xEnd=3D99}". How do you know what is the area of capture you are really getting, my understanding is that it is implied that there are VC0,VC1 and VC2 and you get one of them. Again, I prefer explicit information for this case even if it means having at attribute that will specify that the switch is between VC0, VC1 and VC2 or have it as part of the auto-switch attribute. [BB] The idea here is that the transmitter is showing you the most appropriate subset of that range. You're right the receiver doesn't know specifically what's being sent, but, why does it care? The receiver signed up for getting the most relevant stream in that range and that's what the transmitter will send it. What do you think the receiver needs to know?=20 =20 Regards=20 Roni =20 ------_=_NextPart_001_01CC8386.3730CFDE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey Roni,

Took my best shot inline.

-Brian

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Tuesday, October 04, 2011 11:03 PM
To: clue@ietf.org
Subject: [clue] Area of capture attribute

 

Hi,

I read the new revision and I think that this = attribute is a good starting point to address the discussion on the spatial = description. I hope that we will be able to finalize the model in the Interim = meeting.

 

I started a new thread after seeing the comments = from Christian and Mark.

I will send more feedback on the draft in a = separate email.

 

I think that there is some information missing that = will be helpful

 

1.       The position of the origin of the axis  and = the full range of the area is needed probably as a capture set attribute in = order to understand the view. For example having a VC that says (0,33) does = not provide enough information to know what part of the room it covers. I do = not think that saying that there will be one configuration for example (VC1 = (0,33), VC2(33,66),VC3(66,99)) is the right way since it requires to have such configuration and it also means that the range is (0,99) while it may = also be covering part of a (-10,110) range. The major requirement is not to use = implied information but be explicit.

[BB] I think I agree that this might be useful, but, = I’m not sure we’ve come up with a use case that really demands it = yet.  Let me see if what I have in mind for what you described (and why the origin = and full range up front aren’t needed there) makes = sense:

I’m not sure what = you’ve described (an advertiser only offering a single video capture VC0(0,33)) = would be that common (as, like you said, it isn’t very useful) but if it = did, I still think the renderer could render it sensibly.  Since there are = no other captures advertised, the renderer does not need to be careful = about rendering the VC in a certain position relative to other captures from = that same device because there are none.  In your example: if a 3 camera endpoint only advertised its left camera as VC0(0,33) a 3 screen = endpoint on the other end could render it wherever it wanted because its main = concern (making sure cameras from a multi-camera transmitter are placed = correctly relative to one another) is no longer an issue.  Perhaps there is a = scenario unlike what I’ve just described where, even though only one small = subset of the entire device was advertised, it was important to render it in = exactly one place.  Do you know of an example where that may be the = case?

2.       I think that it is important not only to have = the X coordinates but also have the Y coordinates to be able to know if there = is a gap or overlap at the relevant distance. Again the origin of the axes is crucial here.

[BB] The document provides for describing the area of = capture in up to 3 dimensions(x, y and z); seems like that gives the flexibility = you’re looking for? 

3.       I am not sure about the example in section 7 for = the active speaker (VC3) "VC3- (the loudest panel stream), encoding = group:EG1, attributes:purpose=3Dmain;auto-switched:yes; = area_of_capture=3D{xBegin=3D0,  xEnd=3D99}". How do you know what is the area of capture you are = really getting, my understanding is that it is  implied that there are = VC0,VC1 and VC2 and you get one of them. Again, I prefer explicit information = for this case even if it means having at attribute that will specify that the = switch is between VC0, VC1 and VC2 or have it as part of the auto-switch = attribute.

[BB] The idea here is that the transmitter is showing you = the most appropriate subset of that range.  You’re right the receiver = doesn’t know specifically what’s being sent, but, why does it care?  The = receiver signed up for getting the most relevant stream in that range and = that’s what the transmitter will send it.  What do you think the receiver = needs to know?

 

Regards

Roni

 

------_=_NextPart_001_01CC8386.3730CFDE-- From bbaldino@cisco.com Wed Oct 5 10:44:38 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648DA11E808B for ; Wed, 5 Oct 2011 10:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrfHqDvORYwP for ; Wed, 5 Oct 2011 10:44:37 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9046511E8083 for ; Wed, 5 Oct 2011 10:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bbaldino@cisco.com; l=3932; q=dns/txt; s=iport; t=1317836866; x=1319046466; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Bmrd7SkgIFrDDPLyowyfgBHfV7SSYSx07hQ7NKsCjFA=; b=OuL5uJVINF8b1jpdTLO/4MXap3EjEXW0wVAynmCTqi7jtg/qFCXkwKL5 wGB1LRqsW3sX1NVbzH8FXGoJ0U0blk4CFe0g8ysy2/GGytAxyj8c1byWU EclcGKEB5DqkeyB//HeqkaPX2MHRjlkNF8XHS6EBCXhL3555vu6paWLhi U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUAAAOXjE6rRDoJ/2dsb2JhbABCmQCPFIEFgVMBAQEBAgEBAQEPAR0+CwUHBAIBCBEEAQEBCgYXAQYBJh8JCAEBBAESCBqHWwaZbgGeDAOGSGEEh0wwkSGMNA X-IronPort-AV: E=Sophos;i="4.68,492,1312156800"; d="scan'208";a="6113178" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 05 Oct 2011 17:47:46 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p95HlkBS024772; Wed, 5 Oct 2011 17:47:46 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 10:47:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Oct 2011 10:47:40 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Area of capture attribute thread-index: AcyDZ8zSuXqlA9MDQ92iHK/DFbeMDAAHs4VA References: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> From: "Brian Baldino (bbaldino)" To: "Marshall Eubanks" , "Roni Even" X-OriginalArrivalTime: 05 Oct 2011 17:47:45.0880 (UTC) FILETIME=[E3DEFD80:01CC8386] Cc: clue@ietf.org Subject: Re: [clue] Area of capture attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 17:44:38 -0000 Hey Marshall, responded to your last point inline. -Brian -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Marshall Eubanks Sent: Wednesday, October 05, 2011 7:05 AM To: Roni Even Cc: clue@ietf.org Subject: Re: [clue] Area of capture attribute On Wed, Oct 5, 2011 at 2:03 AM, Roni Even wrote: > Hi, > > I read the new revision and I think that this attribute is a good = starting > point to address the discussion on the spatial description. I hope = that we > will be able to finalize the model in the Interim meeting. > > > > I started a new thread after seeing the comments from Christian and = Mark. > > I will send more feedback on the draft in a separate email. > > > > I think that there is some information missing that will be helpful > > > > 1.=A0=A0=A0=A0=A0=A0 The position of the origin of the axis =A0and the = full range of the > area is needed probably as a capture set attribute in order to = understand > the view. For example having a VC that says (0,33) does not provide = enough > information to know what part of the room it covers. I do not think = that > saying that there will be one configuration for example (VC1 (0,33), > VC2(33,66),VC3(66,99)) is the right way since it requires to have such > configuration and it also means that the range is (0,99) while it may = also > be covering part of a (-10,110) range. The major requirement is not to = use > implied information but be explicit. > > 2.=A0=A0=A0=A0=A0=A0 I think that it is important not only to have the = X coordinates but > also have the Y coordinates to be able to know if there is a gap or = overlap > at the relevant distance. Again the origin of the axes is crucial = here. > I agree with both of these, which of course were both covered in my original message on this subject. Obviously, it takes 2 axes to define an area. (There are 4:3 and 16:9 capture / render devices out there, so already just knowing the horizontal doesn't mean you know the vertical. > 3.=A0=A0=A0=A0=A0=A0 I am not sure about the example in section 7 for = the active speaker > (VC3) "VC3- (the loudest panel stream), encoding group:EG1, > attributes:purpose=3Dmain;auto-switched:yes; = area_of_capture=3D{xBegin=3D0, > xEnd=3D99}". How do you know what is the area of capture you are = really > getting, my understanding is that it is =A0implied that there are = VC0,VC1 and > VC2 and you get one of them. Again, I prefer explicit information for = this > case even if it means having at attribute that will specify that the = switch > is between VC0, VC1 and VC2 or have it as part of the auto-switch = attribute. > I assumed that the 0-99 range meant that it was switched and could be anywhere within that range. I think that that is confusing and not very informative - wouldn't it make more sense to have a switched capture scene be virtual, something like VC3- (the loudest panel stream), encoding group:EG1, attributes: purpose=3Dmain;auto-switched:yes; area_of_capture=3D{one_of{VC0, VC1, VC2}} with a restriction that "one_of" lists MUST NOT be self-referential. [BB] This seems a bit restrictive, what is the information we're really = looking to get here? What area of capture the switched stream currently = contains at any given point? What discrete areas of capture it could = possibly contain? How do we imagine this information would be used? = Would like to get a better idea of the use case. Regards Marshall > > > Regards > > Roni > > > > ________________________________ > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From marshall.eubanks@gmail.com Wed Oct 5 11:41:20 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A648B11E80B6 for ; Wed, 5 Oct 2011 11:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.959 X-Spam-Level: X-Spam-Status: No, score=-103.959 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPRHh5zibPS9 for ; Wed, 5 Oct 2011 11:41:19 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0E111E809A for ; Wed, 5 Oct 2011 11:41:19 -0700 (PDT) Received: by ggnk3 with SMTP id k3so1202679ggn.31 for ; Wed, 05 Oct 2011 11:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=m55nMT5sUQC3jfCkY0naJYlnVFfMxDegM724x4lvG+o=; b=DEeRlb4tYuOHqaIYlkoMbNj6kYOYZZvAK29tOGCt/xTkxRojJmoNytr0ixZoL77neY 6qkSd3oc/9U1FK973FZLOmPaEfbIY3DCQz/weHZ1eYvHZFiUO1/jg9D/xI3k2CMhs1sc uuU7oHP4l2C8KA2c+s8QvbbA0vJecwLYj+6CA= MIME-Version: 1.0 Received: by 10.150.53.12 with SMTP id b12mr2505044yba.140.1317840267799; Wed, 05 Oct 2011 11:44:27 -0700 (PDT) Received: by 10.151.98.20 with HTTP; Wed, 5 Oct 2011 11:44:27 -0700 (PDT) In-Reply-To: References: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> Date: Wed, 5 Oct 2011 14:44:27 -0400 Message-ID: From: Marshall Eubanks To: "Brian Baldino (bbaldino)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: clue@ietf.org Subject: Re: [clue] Area of capture attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 18:41:20 -0000 On Wed, Oct 5, 2011 at 1:42 PM, Brian Baldino (bbaldino) wrote: > Hey Roni, > > Took my best shot inline. > > -Brian > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of R= oni > Even > Sent: Tuesday, October 04, 2011 11:03 PM > To: clue@ietf.org > Subject: [clue] Area of capture attribute > > > > Hi, > > I read the new revision and I think that this attribute is a good startin= g > point to address the discussion on the spatial description. I hope that w= e > will be able to finalize the model in the Interim meeting. > > > > I started a new thread after seeing the comments from Christian and Mark. > > I will send more feedback on the draft in a separate email. > > > > I think that there is some information missing that will be helpful > > > > 1.=A0=A0=A0=A0=A0=A0 The position of the origin of the axis =A0and the fu= ll range of the > area is needed probably as a capture set attribute in order to understand > the view. For example having a VC that says (0,33) does not provide enoug= h > information to know what part of the room it covers. I do not think that > saying that there will be one configuration for example (VC1 (0,33), > VC2(33,66),VC3(66,99)) is the right way since it requires to have such > configuration and it also means that the range is (0,99) while it may als= o > be covering part of a (-10,110) range. The major requirement is not to us= e > implied information but be explicit. > > [BB] I think I agree that this might be useful, but, I=92m not sure we=92= ve come > up with a use case that really demands it yet.=A0 Let me see if what I ha= ve in > mind for what you described (and why the origin and full range up front > aren=92t needed there) makes sense: > > I=92m not sure what you=92ve described (an advertiser only offering a sin= gle > video capture VC0(0,33)) would be that common (as, like you said, it isn= =92t > very useful) but if it did, I still think the renderer could render it > sensibly.=A0 Since there are no other captures advertised, the renderer d= oes > not need to be careful about rendering the VC in a certain position relat= ive > to other captures from that same device because there are none.=A0 In you= r > example: if a 3 camera endpoint only advertised its left camera as VC0(0,= 33) > a 3 screen endpoint on the other end could render it wherever it wanted > because its main concern (making sure cameras from a multi-camera > transmitter are placed correctly relative to one another) is no longer an > issue.=A0 Perhaps there is a scenario unlike what I=92ve just described w= here, > even though only one small subset of the entire device was advertised, it > was important to render it in exactly one place.=A0 Do you know of an exa= mple > where that may be the case? > > 2.=A0=A0=A0=A0=A0=A0 I think that it is important not only to have the X = coordinates but > also have the Y coordinates to be able to know if there is a gap or overl= ap > at the relevant distance. Again the origin of the axes is crucial here. > > [BB] The document provides for describing the area of capture in up to 3 > dimensions(x, y and z); seems like that gives the flexibility you=92re lo= oking > for? > Ah, I missed that - it's implicit in 5.2.4. (I searched on vertical, which is nowhere mentioned.) Obviously, this could use some wording tweaks, which I promised to provide. In 5.2.4, I suggest you start with The area_of_capture attribute is used to describe the relevant area of which a media capture is "capturing". Area of capture is expressed as pairs of {x, y, z} coordinates to describe {left to right, front to back, low to high} ranges in that order where, as with point_of_capture, only the necessary dimensions need be expressed. In other words, it is specified that, as numbers move from lower to higher, the location is going from: left to right (in the case of the =92x=92 dimension), front to back (in the case of the =92y=92 dimension or low to high (in the case of the =92z=92 dimension). In 5.2.6. it says Area Scale Millimeters An optional Boolean variable indicating if the numbers used for area of capture and point of capture are in terms of millimeters. If this attribute is true, then the x,y,z numbers represent millimeters. If this attribute is false, then there is no physical scale. The default value is false. Note that "degrees" are not mentioned anywhere in the document. Degrees may not be a physical scale, but they are still a scale. (If you interpret {0,33} as radians or pixels, you are unlikely to get pleasing results.) There is another issue, as I don't know what the equivalent to angles are for front to back. I would change " If this attribute is false, then there is no physical scale." to " If this attribute is false, then the scale for x and z is degrees, and the scale for y remains mm." If you have another default scale for y, you should specify it (I can't imagine what it would be.) (BTW, I believe that I suggested y being up and down and z being front to back, precisely because most people will specify x, fewer up-down, and fewest front back distances. If you do that, you have to switch the definition of left and right to stage-left and stage-right to keep a right handed system.) In Section 3, it says. Left: For media captures, left and right is from the point of view of a person observing the rendered media. This is the opposite of stage-left and stage-right, and would be called camera-left and camera-right in American TV. In other words, "left" and "right" are camera-left and camera-right in theatrical parlance, and are the opposite of left and right for the person being observed. Actually, I would strongly urge the definition and _explicit_ use of camera-left and camera-right (or stage-left and stage-right) in EVERY occurrence of their use. If we don't do that, I am willing to bet someone will mess it up. So, if you do this, the definition becomes Camera-Left: For media captures, camera-left and camera-right is from the point of view of a person observing the rendered media. They are the opposite of stage-left and stage-right, which are the left and right of the person being observed. Note also that front and back are not defined. They should be. Up and down I think can go undefined. Front. Front is the portion of the room closest to the cameras. In going towards back you move away from the cameras. > 3.=A0=A0=A0=A0=A0=A0 I am not sure about the example in section 7 for the= active speaker > (VC3) "VC3- (the loudest panel stream), encoding group:EG1, > attributes:purpose=3Dmain;auto-switched:yes; area_of_capture=3D{xBegin=3D= 0, > xEnd=3D99}". How do you know what is the area of capture you are really > getting, my understanding is that it is =A0implied that there are VC0,VC1= and > VC2 and you get one of them. Again, I prefer explicit information for thi= s > case even if it means having at attribute that will specify that the swit= ch > is between VC0, VC1 and VC2 or have it as part of the auto-switch attribu= te. > > [BB] The idea here is that the transmitter is showing you the most > appropriate subset of that range.=A0 You=92re right the receiver doesn=92= t know > specifically what=92s being sent, but, why does it care?=A0 The receiver = signed > up for getting the most relevant stream in that range and that=92s what t= he > transmitter will send it.=A0 What do you think the receiver needs to know= ? > To scale the image appropriately. For example, if VC3 is really VC1, that could maybe be shown in full. If VC3 is really VC0+VC1+VC3 composited together, it should be letter boxed. I am also nervous about throwing away information when we don't have to. Regards Marshall > > > Regards > > Roni > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From Mark.Duckworth@polycom.com Wed Oct 5 13:13:15 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADDA911E80D5 for ; Wed, 5 Oct 2011 13:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTUPKWBaIJKQ for ; Wed, 5 Oct 2011 13:13:15 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 5E53B11E80C2 for ; Wed, 5 Oct 2011 13:13:13 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 5 Oct 2011 13:16:17 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 5 Oct 2011 13:16:16 -0700 Thread-Topic: [clue] FW: New Version Notification for draft-romanow-clue-framework-01.txt Thread-Index: AcyDD7FjVoQI7aLrRqiNY36qf6v2PAAivqJw Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61CDF41621@CRPMBOXPRD01.polycom.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05B7DE73@xmb-sjc-221.amer.cisco.com> <4E8A77E1.1090608@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A61CDF40F79@CRPMBOXPRD01.polycom.com> <4E8BD034.40300@nteczone.com> In-Reply-To: <4E8BD034.40300@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-framework-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 20:13:15 -0000 > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Tuesday, October 04, 2011 11:34 PM > To: Duckworth, Mark > Cc: clue@ietf.org > Subject: Re: [clue] FW: New Version Notification for draft-romanow- > clue-framework-01.txt >=20 ..snip.. >=20 > >> 5.2.4 - Do we need to consider the range start and end when determinin= g > >> the area of capture? Consider the example Capture Scene(VC0,VC1,VC2) > >> where: > >> o VC0- (the left camera stream), area_of_capture=3D{xBegin=3D0, = xEnd=3D33} > >> o VC1- (the center camera stream), area_of_capture=3D{xBegin=3D3= 3, xEnd=3D66} > >> o VC2- (the right camera stream), area_of_capture=3D{xBegin=3D66= , xEnd=3D99} > >> This example is clear each capture relates to 1/3 of the overall > >> capture scene. > >> > >> Now if instead the capture scene (VC1) was sent. How does the renderer > >> put this in context? VC1 is the center capture (thus only 1/3 of the > >> providers overall capability). The renderer will receieve xBegin=3D33 = and > >> xEnd=3D66 only and thus conclude its 100% of the capture scene. Do we = need > >> a means to indicate that the total area is 0 to 99 but the current > >> capture only relates to a subset? > > [Duckworth, Mark] I don't think the renderer will reach that > conclusion. The immediate consumer will know about the whole range 0 > to 99 from the capture set. If the immediate consumer is also the > renderer, then the renderer knows. If the immediate consumer is a > middlebox, then that middlebox becomes the provider for the next > consumer (renderer). The middlebox constructs its own media captures > and capture set with its own area of capture attributes. These > attributes may or may not be the same as from the original providers. > The middlebox advertises captures and a capture set with attributes > that make sense for whatever behavior the middlebox is trying to > provide. So the ultimate consumer (the renderer) will know about > attributes that make sense in this context from the middlebox. This > consumer doesn't know about any of the attributes from the original > producer, it only knows the attributes from the middle box. > [CNG] I think I wasn't clear in my example. What happens if the received > capture set only contains VC1 and the consumer didn't previously get a > capture set (VC0,VC1,VC2)? The middlebox, consumer etc. wouldn't know > that "area_of_capture=3D{xBegin=3D33,xEnd=3D66}" represents the centre re= gion > of a range (0..99). [Duckworth, Mark] I still don't understand the case you are asking about. = Are you saying a media producer advertises a capture set with only VC1 with= an area of capture from 33 to 66? No other video captures? If a media pro= ducer wants to do this, send only one stream, for some reason, then what do= es it matter what the area of capture is? There is nothing else to relate = it to, so it doesn't matter. Regards, Mark From Mark.Duckworth@polycom.com Wed Oct 5 14:12:47 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE0011E8080 for ; Wed, 5 Oct 2011 14:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.28 X-Spam-Level: X-Spam-Status: No, score=-7.28 tagged_above=-999 required=5 tests=[AWL=0.719, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAM5M0zOYRhD for ; Wed, 5 Oct 2011 14:12:46 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id AECD421F8AD8 for ; Wed, 5 Oct 2011 14:12:44 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 5 Oct 2011 14:15:53 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 5 Oct 2011 14:15:51 -0700 Thread-Topic: [clue] Area of capture attribute Thread-Index: AcyDjtRXzxQer9igSSGZI+YZDNNHPAAE3PxA Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61CDF41693@CRPMBOXPRD01.polycom.com> References: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Area of capture attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 21:12:47 -0000 I can see that degrees might be a useful scale for X and Z in addition to m= illimeters. Maybe it should be tenths of a degree, and use integers (no fl= oating point)? So if we allow that, then we need a way to indicate the sca= le of area of capture and point of capture numbers which would be one of: n= one, millimeters, degrees. And I think this scale indication applies to an= entire capture set, not individual media captures. Everything in a partic= ular capture set must use the same scale. When we introduced the area of capture concept, and using a millimeter scal= e, I thought that would eliminate the need for the Video Scale attribute we= had before. I now think we should bring back a separate Video Scale attri= bute, because the area of capture won't always be enough to tell the scale = in terms of how large to render it to make it seem the appropriate size at = the rendering side. One example is an auto-switched video capture that cov= ers 0 to 99 (area of capture), while at any one time it is only covering a = third of it (video scale), so having a separate video scale attribute allow= s the renderer to scale it accordingly if it wants. Now I wonder if the sc= ale attribute really should be associated with a video stream in RTP, rathe= r than with a video capture, because maybe it should be more dynamic than c= apture set advertisements. Marshall, your definition of left and right makes good sense to me. Mark Duckworth > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Marshall Eubanks > Sent: Wednesday, October 05, 2011 2:44 PM > To: Brian Baldino (bbaldino) > Cc: clue@ietf.org > Subject: Re: [clue] Area of capture attribute >=20 > On Wed, Oct 5, 2011 at 1:42 PM, Brian Baldino (bbaldino) > wrote: > > Hey Roni, > > > > Took my best shot inline. > > > > -Brian > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Roni > > Even > > Sent: Tuesday, October 04, 2011 11:03 PM > > To: clue@ietf.org > > Subject: [clue] Area of capture attribute > > > > Hi, > > > > I read the new revision and I think that this attribute is a good > starting > > point to address the discussion on the spatial description. I hope > that we > > will be able to finalize the model in the Interim meeting. > > > > I started a new thread after seeing the comments from Christian and > Mark. > > > > I will send more feedback on the draft in a separate email. > > > > I think that there is some information missing that will be helpful > > > > 1.=A0=A0=A0=A0=A0=A0 The position of the origin of the axis =A0and the = full range > of the > > area is needed probably as a capture set attribute in order to > understand > > the view. For example having a VC that says (0,33) does not provide > enough > > information to know what part of the room it covers. I do not think > that > > saying that there will be one configuration for example (VC1 (0,33), > > VC2(33,66),VC3(66,99)) is the right way since it requires to have > such > > configuration and it also means that the range is (0,99) while it may > also > > be covering part of a (-10,110) range. The major requirement is not > to use > > implied information but be explicit. > > > > [BB] I think I agree that this might be useful, but, I'm not sure > we've come > > up with a use case that really demands it yet.=A0 Let me see if what I > have in > > mind for what you described (and why the origin and full range up > front > > aren't needed there) makes sense: > > > > I'm not sure what you've described (an advertiser only offering a > single > > video capture VC0(0,33)) would be that common (as, like you said, it > isn't > > very useful) but if it did, I still think the renderer could render > it > > sensibly.=A0 Since there are no other captures advertised, the renderer > does > > not need to be careful about rendering the VC in a certain position > relative > > to other captures from that same device because there are none.=A0 In > your > > example: if a 3 camera endpoint only advertised its left camera as > VC0(0,33) > > a 3 screen endpoint on the other end could render it wherever it > wanted > > because its main concern (making sure cameras from a multi-camera > > transmitter are placed correctly relative to one another) is no > longer an > > issue.=A0 Perhaps there is a scenario unlike what I've just described > where, > > even though only one small subset of the entire device was > advertised, it > > was important to render it in exactly one place.=A0 Do you know of an > example > > where that may be the case? > > > > 2.=A0=A0=A0=A0=A0=A0 I think that it is important not only to have the = X > coordinates but > > also have the Y coordinates to be able to know if there is a gap or > overlap > > at the relevant distance. Again the origin of the axes is crucial > here. > > > > [BB] The document provides for describing the area of capture in up > to 3 > > dimensions(x, y and z); seems like that gives the flexibility you're > looking > > for? > > >=20 > Ah, I missed that - it's implicit in 5.2.4. (I searched on vertical, > which is nowhere mentioned.) Obviously, this could use some wording > tweaks, which I promised to provide. >=20 > In 5.2.4, I suggest you start with >=20 > The area_of_capture attribute is used to describe the relevant area of > which a media capture is "capturing". > Area of capture is expressed as pairs of {x, y, z} coordinates to > describe {left to right, front to back, low to high} ranges in that > order where, as with point_of_capture, only the necessary dimensions > need be expressed. In other words, it is specified that, as numbers > move from lower to higher, the location is going from: left to right > (in the case of the 'x' dimension), front to back (in the case of the > 'y' dimension or low to high (in the case of the 'z' dimension). >=20 >=20 > In 5.2.6. it says >=20 > Area Scale Millimeters > An optional Boolean variable indicating if the numbers used for area > of capture and point of capture are in terms of millimeters. If this > attribute is true, then the x,y,z numbers represent millimeters. If > this attribute is false, then there is no physical scale. The default > value is false. >=20 > Note that "degrees" are not mentioned anywhere in the document. > Degrees may not be a physical scale, but they are still a scale. (If > you interpret {0,33} as radians or pixels, you are unlikely to get > pleasing results.) There is another issue, as I don't know what the > equivalent to angles are for front to back. >=20 > I would change " If this attribute is false, then there is no physical > scale." to >=20 > " If this attribute is false, then the scale for x and z is degrees, > and the scale for y remains mm." >=20 > If you have another default scale for y, you should specify it (I > can't imagine what it would be.) >=20 > (BTW, I believe that I suggested y being up and down and z being front > to back, precisely because most people will specify x, fewer up-down, > and fewest front back distances. If you do that, you have to switch > the definition of left and right to stage-left and stage-right to keep > a right handed system.) >=20 > In Section 3, it says. >=20 > Left: For media captures, left and right is from the point of view of > a person observing the rendered media. >=20 > This is the opposite of stage-left and stage-right, and would be > called camera-left and camera-right in American TV. >=20 > In other words, "left" and "right" are camera-left and camera-right > in theatrical parlance, and are the opposite of left and right for the > person being observed. >=20 > Actually, I would strongly urge the definition and _explicit_ use of > camera-left and camera-right (or stage-left and stage-right) in EVERY > occurrence of their use. >=20 > If we don't do that, I am willing to bet someone will mess it up. >=20 > So, if you do this, the definition becomes >=20 > Camera-Left: For media captures, camera-left and camera-right is from > the point of view of a person observing the rendered media. They are > the opposite of stage-left and stage-right, which are the left and > right of the person being observed. >=20 > Note also that front and back are not defined. They should be. Up and > down I think can go undefined. >=20 > Front. Front is the portion of the room closest to the cameras. In > going towards back you move away from the cameras. >=20 >=20 > > 3.=A0=A0=A0=A0=A0=A0 I am not sure about the example in section 7 for t= he active > speaker > > (VC3) "VC3- (the loudest panel stream), encoding group:EG1, > > attributes:purpose=3Dmain;auto-switched:yes; area_of_capture=3D{xBegin= =3D0, > > xEnd=3D99}". How do you know what is the area of capture you are really > > getting, my understanding is that it is =A0implied that there are > VC0,VC1 and > > VC2 and you get one of them. Again, I prefer explicit information for > this > > case even if it means having at attribute that will specify that the > switch > > is between VC0, VC1 and VC2 or have it as part of the auto-switch > attribute. > > > > [BB] The idea here is that the transmitter is showing you the most > > appropriate subset of that range.=A0 You're right the receiver doesn't > know > > specifically what's being sent, but, why does it care?=A0 The receiver > signed > > up for getting the most relevant stream in that range and that's what > the > > transmitter will send it.=A0 What do you think the receiver needs to > know? > > >=20 > To scale the image appropriately. For example, if VC3 is really VC1, > that could maybe be shown > in full. If VC3 is really VC0+VC1+VC3 composited together, it should > be letter boxed. >=20 > I am also nervous about throwing away information when we don't have > to. >=20 > Regards > Marshall >=20 > > Regards > > Roni From Even.roni@huawei.com Wed Oct 5 14:22:13 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467B721F8C88 for ; Wed, 5 Oct 2011 14:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.036 X-Spam-Level: X-Spam-Status: No, score=-106.036 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Dgmz7I6o1p9 for ; Wed, 5 Oct 2011 14:22:09 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 392DE21F8C4A for ; Wed, 5 Oct 2011 14:22:00 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSM00JY33HVLU@szxga05-in.huawei.com> for clue@ietf.org; Thu, 06 Oct 2011 05:25:07 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSM008JZ3HUKN@szxga05-in.huawei.com> for clue@ietf.org; Thu, 06 Oct 2011 05:25:07 +0800 (CST) Received: from windows8d787f9 (bzq-109-64-200-234.red.bezeqint.net [109.64.200.234]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LSM00MR73HOCF@szxml11-in.huawei.com>; Thu, 06 Oct 2011 05:25:06 +0800 (CST) Date: Wed, 05 Oct 2011 23:22:18 +0200 From: Roni Even In-reply-to: To: "'Brian Baldino (bbaldino)'" , clue@ietf.org Message-id: <054401cc83a4$dfa6d670$9ef48350$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ZnUY4A76tHyFmI4BIwe5JA)" Content-language: en-us Thread-index: AcyDJHXTd/dmWtWGTle0G/txbwllmwAWem4gAAinSdA= References: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> Subject: Re: [clue] Area of capture attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 21:22:13 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ZnUY4A76tHyFmI4BIwe5JA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Brian, Inline Roni From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] Sent: Wednesday, October 05, 2011 7:43 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Area of capture attribute Hey Roni, Took my best shot inline. -Brian From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Tuesday, October 04, 2011 11:03 PM To: clue@ietf.org Subject: [clue] Area of capture attribute Hi, I read the new revision and I think that this attribute is a good starting point to address the discussion on the spatial description. I hope that we will be able to finalize the model in the Interim meeting. I started a new thread after seeing the comments from Christian and Mark. I will send more feedback on the draft in a separate email. I think that there is some information missing that will be helpful 1. The position of the origin of the axis and the full range of the area is needed probably as a capture set attribute in order to understand the view. For example having a VC that says (0,33) does not provide enough information to know what part of the room it covers. I do not think that saying that there will be one configuration for example (VC1 (0,33), VC2(33,66),VC3(66,99)) is the right way since it requires to have such configuration and it also means that the range is (0,99) while it may also be covering part of a (-10,110) range. The major requirement is not to use implied information but be explicit. [BB] I think I agree that this might be useful, but, I'm not sure we've come up with a use case that really demands it yet. Let me see if what I have in mind for what you described (and why the origin and full range up front aren't needed there) makes sense: I'm not sure what you've described (an advertiser only offering a single video capture VC0(0,33)) would be that common (as, like you said, it isn't very useful) but if it did, I still think the renderer could render it sensibly. Since there are no other captures advertised, the renderer does not need to be careful about rendering the VC in a certain position relative to other captures from that same device because there are none. In your example: if a 3 camera endpoint only advertised its left camera as VC0(0,33) a 3 screen endpoint on the other end could render it wherever it wanted because its main concern (making sure cameras from a multi-camera transmitter are placed correctly relative to one another) is no longer an issue. Perhaps there is a scenario unlike what I've just described where, even though only one small subset of the entire device was advertised, it was important to render it in exactly one place. Do you know of an example where that may be the case? [Roni] I hope you followed the discussion on the list about gaps between captures. This is a use case where you need the origin and the X,Y coordinates. I think that also the multiview use case will need it. It will not be needed if there is a hidden assumption that the area describes the range at the line where the first row of people is at. Some systems may decide that this measure is at the back of the room. You claim that by having all the different video captures I can learn the range of the room and I say why learn it from all the specified captures provide it separately. I am not sure why you are trying to optimize the provided information. 2. I think that it is important not only to have the X coordinates but also have the Y coordinates to be able to know if there is a gap or overlap at the relevant distance. Again the origin of the axes is crucial here. [BB] The document provides for describing the area of capture in up to 3 dimensions(x, y and z); seems like that gives the flexibility you're looking for? [Roni] My claim is that you must provide at least X and Y 3. I am not sure about the example in section 7 for the active speaker (VC3) "VC3- (the loudest panel stream), encoding group:EG1, attributes:purpose=main;auto-switched:yes; area_of_capture={xBegin=0, xEnd=99}". How do you know what is the area of capture you are really getting, my understanding is that it is implied that there are VC0,VC1 and VC2 and you get one of them. Again, I prefer explicit information for this case even if it means having at attribute that will specify that the switch is between VC0, VC1 and VC2 or have it as part of the auto-switch attribute. [BB] The idea here is that the transmitter is showing you the most appropriate subset of that range. You're right the receiver doesn't know specifically what's being sent, but, why does it care? The receiver signed up for getting the most relevant stream in that range and that's what the transmitter will send it. What do you think the receiver needs to know? [Roni} you want to know in order to choose between VC3, VC4, VC5 which offer similar proposal. The consumer will need to select the most relevant stream, for VC3 note that for auto-switch according to 5.2.8 "In this case the offered AC or VC varies depending on some rule" which hints that it may be not only loudest speaker so you do not really know what auto-switch means. I will continue to insist on providing explicit information from the provider to the consumer so he can make a sensible selection and to enable extensibility. In this case it will be the providing the auto switching algorithm. Regards Roni --Boundary_(ID_ZnUY4A76tHyFmI4BIwe5JA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Brian,

Inline

Roni

From:= = Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com]
Sent: = Wednesday, October 05, 2011 7:43 PM
To: Roni Even; = clue@ietf.org
Subject: RE: [clue] Area of capture = attribute

 

Hey = Roni,

Took my = best shot inline.

-Brian

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Tuesday, October 04, 2011 11:03 = PM
To: clue@ietf.org
Subject: [clue] Area of capture = attribute

 

Hi,

I read the new = revision and I think that this attribute is a good starting point to = address the discussion on the spatial description. I hope that we will = be able to finalize the model in the Interim meeting.

 

I started a = new thread after seeing the comments from Christian and = Mark.

I will send more feedback on = the draft in a separate email.

 

I think that = there is some information missing that will be helpful

 

1.       = The position of the = origin of the axis  and the full range of the area is needed = probably as a capture set attribute in order to understand the view. For = example having a VC that says (0,33) does not provide enough information = to know what part of the room it covers. I do not think that saying that = there will be one configuration for example (VC1 (0,33), = VC2(33,66),VC3(66,99)) is the right way since it requires to have such = configuration and it also means that the range is (0,99) while it may = also be covering part of a (-10,110) range. The major requirement is not = to use implied information but be explicit.

[BB] I = think I agree that this might be useful, but, I’m not sure = we’ve come up with a use case that really demands it yet.  = Let me see if what I have in mind for what you described (and why the = origin and full range up front aren’t needed there) makes = sense:

I’m not sure what you’ve described (an = advertiser only offering a single video capture VC0(0,33)) would be that = common (as, like you said, it isn’t very useful) but if it did, I = still think the renderer could render it sensibly.  Since there are = no other captures advertised, the renderer does not need to be careful = about rendering the VC in a certain position relative to other captures = from that same device because there are none.  In your example: if = a 3 camera endpoint only advertised its left camera as VC0(0,33) a 3 = screen endpoint on the other end could render it wherever it wanted = because its main concern (making sure cameras from a multi-camera = transmitter are placed correctly relative to one another) is no longer = an issue.  Perhaps there is a scenario unlike what I’ve just = described where, even though only one small subset of the entire device = was advertised, it was important to render it in exactly one = place.  Do you know of an example where that may be the = case?

 

 

[Roni] I hope you followed the discussion on the list = about gaps between captures. This is a use case where you need the = origin and the X,Y coordinates. I think that also the multiview use case = will need it. It will not be needed if there is a hidden =  assumption that the area describes the range at the line where the = first row of people is at. Some systems may decide that this measure is = at the back of the room.

You claim that by having all the different video = captures I can learn the range of the room and I say why learn it from = all the specified captures provide it separately. I am not sure why you = are trying to optimize the provided information.

 

 

2.       = I think that it is = important not only to have the X coordinates but also have the Y = coordinates to be able to know if there is a gap or overlap at the = relevant distance. Again the origin of the axes is crucial = here.

[BB] The = document provides for describing the area of capture in up to 3 = dimensions(x, y and z); seems like that gives the flexibility = you’re looking for? 

[Roni] My claim is that = you must provide at least X and Y

 

3.       = I am not sure about the = example in section 7 for the active speaker (VC3) "VC3- (the = loudest panel stream), encoding group:EG1, = attributes:purpose=3Dmain;auto-switched:yes; = area_of_capture=3D{xBegin=3D0,  xEnd=3D99}". How do you know = what is the area of capture you are really getting, my understanding is = that it is  implied that there are VC0,VC1 and VC2 and you get one = of them. Again, I prefer explicit information for this case even if it = means having at attribute that will specify that the switch is between = VC0, VC1 and VC2 or have it as part of the auto-switch = attribute.

[BB] The = idea here is that the transmitter is showing you the most appropriate = subset of that range.  You’re right the receiver = doesn’t know specifically what’s being sent, but, why does = it care?  The receiver signed up for getting the most relevant = stream in that range and that’s what the transmitter will send = it.  What do you think the receiver needs to know? =

[Roni} you = want to know in order to choose between VC3, VC4, VC5 which offer = similar proposal. The  consumer will need to select the most = relevant stream, for VC3 note that for auto-switch according to 5.2.8 “In = this case the offered AC or VC varies depending on some rule”  which hints = that it may be not only loudest speaker so you do not really know what = auto-switch means. I will continue to insist on providing explicit = information from the provider to the consumer so he can make a sensible = selection and to enable extensibility. In this case it will be the = providing the auto switching algorithm.

 

<= p class=3DMsoNormal> 

 

Regards =

Roni

 

= --Boundary_(ID_ZnUY4A76tHyFmI4BIwe5JA)-- From espeberg@cisco.com Thu Oct 6 00:25:13 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870B321F8C47 for ; Thu, 6 Oct 2011 00:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ai+ADb0xPhv for ; Thu, 6 Oct 2011 00:25:12 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4D76A21F8C48 for ; Thu, 6 Oct 2011 00:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=3707; q=dns/txt; s=iport; t=1317886102; x=1319095702; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=faanigIF7E9PB9ckkHv+myjaIWXoM/Mrqqo4/aFkaq4=; b=l1bxCdj7kJNIJgWGYbJufLAjrQjZYT7DehzaWDjY4dlWiFy1ODJ+mjoQ q8XhpyHnovTEqW//Bhu/Q9LxLyAQ4GIkPfftsAT4SWQ6BeIgBopWpkuyU r4vkqOvix9IlPGNUiIo7WT/Djc1DeTqtaS8B9m/5X4545op9IrDN1+UAR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgAAEJYjU6Q/khR/2dsb2JhbABEmROPFoEFgVMBAQEEAQEBDwEdCjQJDgQCAQgRBAEBCwYXAQYBJh8IAQgBAQQBEggah2OYOQGdfAOGS2EEmR+MFw X-IronPort-AV: E=Sophos;i="4.68,495,1312156800"; d="scan'208";a="57206923" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 06 Oct 2011 07:28:19 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p967SJOC031728; Thu, 6 Oct 2011 07:28:19 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Oct 2011 09:28:19 +0200 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Oct 2011 09:28:18 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E99556A@XMB-AMS-214.cisco.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61CDF41621@CRPMBOXPRD01.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] FW: New Version Notification for draft-romanow-clue-framework-01.txt Thread-Index: AcyDD7FjVoQI7aLrRqiNY36qf6v2PAAivqJwABdQ1WA= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05B7DE73@xmb-sjc-221.amer.cisco.com><4E8A77E1.1090608@nteczone.com><44C6B6B2D0CF424AA90B6055548D7A61CDF40F79@CRPMBOXPRD01.polycom.com><4E8BD034.40300@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A61CDF41621@CRPMBOXPRD01.polycom.com> From: "Espen Berger (espeberg)" To: "Duckworth, Mark" , X-OriginalArrivalTime: 06 Oct 2011 07:28:19.0694 (UTC) FILETIME=[8582D0E0:01CC83F9] Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-framework-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 07:25:13 -0000 Inline -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: 5. oktober 2011 22:16 To: clue@ietf.org Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-framework-01.txt > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Tuesday, October 04, 2011 11:34 PM > To: Duckworth, Mark > Cc: clue@ietf.org > Subject: Re: [clue] FW: New Version Notification for draft-romanow- > clue-framework-01.txt >=20 ..snip.. >=20 > >> 5.2.4 - Do we need to consider the range start and end when determining > >> the area of capture? Consider the example Capture Scene(VC0,VC1,VC2) > >> where: > >> o VC0- (the left camera stream), = area_of_capture=3D{xBegin=3D0, xEnd=3D33} > >> o VC1- (the center camera stream), area_of_capture=3D{xBegin=3D33, xEnd=3D66} > >> o VC2- (the right camera stream), = area_of_capture=3D{xBegin=3D66, xEnd=3D99} > >> This example is clear each capture relates to 1/3 of the overall > >> capture scene. > >> > >> Now if instead the capture scene (VC1) was sent. How does the renderer > >> put this in context? VC1 is the center capture (thus only 1/3 of the > >> providers overall capability). The renderer will receieve = xBegin=3D33 and > >> xEnd=3D66 only and thus conclude its 100% of the capture scene. Do = we need > >> a means to indicate that the total area is 0 to 99 but the current > >> capture only relates to a subset? > > [Duckworth, Mark] I don't think the renderer will reach that > conclusion. The immediate consumer will know about the whole range 0 > to 99 from the capture set. If the immediate consumer is also the > renderer, then the renderer knows. If the immediate consumer is a > middlebox, then that middlebox becomes the provider for the next > consumer (renderer). The middlebox constructs its own media captures > and capture set with its own area of capture attributes. These > attributes may or may not be the same as from the original providers. > The middlebox advertises captures and a capture set with attributes > that make sense for whatever behavior the middlebox is trying to > provide. So the ultimate consumer (the renderer) will know about > attributes that make sense in this context from the middlebox. This > consumer doesn't know about any of the attributes from the original > producer, it only knows the attributes from the middle box. > [CNG] I think I wasn't clear in my example. What happens if the received > capture set only contains VC1 and the consumer didn't previously get a > capture set (VC0,VC1,VC2)? The middlebox, consumer etc. wouldn't know > that "area_of_capture=3D{xBegin=3D33,xEnd=3D66}" represents the centre region > of a range (0..99). [Duckworth, Mark] I still don't understand the case you are asking about. Are you saying a media producer advertises a capture set with only VC1 with an area of capture from 33 to 66? No other video captures? If a media producer wants to do this, send only one stream, for some reason, then what does it matter what the area of capture is? There is nothing else to relate it to, so it doesn't matter. [Espen]I think its useful that the model support the use case where only a single camera in a row is announced, e.g. when there are only people in the central positions in a triple camera system. CLUE does not need to hide the fact that there is other available cameras that are not active.=20 Regards, Mark _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Thu Oct 6 04:17:44 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447D621F8562 for ; Thu, 6 Oct 2011 04:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.056 X-Spam-Level: X-Spam-Status: No, score=-4.056 tagged_above=-999 required=5 tests=[AWL=0.942, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zUXZtO+FGy0 for ; Thu, 6 Oct 2011 04:17:42 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 32D9B21F8560 for ; Thu, 6 Oct 2011 04:17:42 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so2611419vcb.31 for ; Thu, 06 Oct 2011 04:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bMC/ohz9CPTCclyAK7ZmJAtV4VujWe1FUZBZsxky8c8=; b=ioM1bew0dRa6zA8wDM6fZoFq3Y8Id47QoBmSfAqyhdaqeM71bsR80ZOkxOPgDeE9r9 KkZ2OkACj0Eq4YqH7AUqVcelGCvR9g6kyFukHv0wnoyINocPjB/bSUvQBz8mKEtGhT+O Uzkb0ClYGkSvtV39EqWE/mR+mU8QBUAfTQ+sY= MIME-Version: 1.0 Received: by 10.52.65.82 with SMTP id v18mr575077vds.199.1317900052338; Thu, 06 Oct 2011 04:20:52 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Thu, 6 Oct 2011 04:20:52 -0700 (PDT) In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61CDF41693@CRPMBOXPRD01.polycom.com> References: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61CDF41693@CRPMBOXPRD01.polycom.com> Date: Thu, 6 Oct 2011 07:20:52 -0400 Message-ID: From: Stephen Botzko To: "Duckworth, Mark" Content-Type: multipart/alternative; boundary=20cf3071cc5c78174504ae9f84e1 Cc: "clue@ietf.org" Subject: Re: [clue] Area of capture attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 11:17:44 -0000 --20cf3071cc5c78174504ae9f84e1 Content-Type: text/plain; charset=ISO-8859-1 In order to get actual-size information with field-of-view in degrees, you need to know the distance from the camera to the first row (which right now is implicit in the mm scale). This suggests a couple of mathematically equivalent alternatives: (a) provide both MM scale and field of view in degrees. If someone needed the distance to the first row, it could be computed. (b) provide MM scale and the distance to the first row. In this combination, field-of-view in degrees can be computed. (b) has an advantage in that it can be extended to include multiple rows. On Wed, Oct 5, 2011 at 5:15 PM, Duckworth, Mark wrote: > I can see that degrees might be a useful scale for X and Z in addition to > millimeters. Maybe it should be tenths of a degree, and use integers (no > floating point)? So if we allow that, then we need a way to indicate the > scale of area of capture and point of capture numbers which would be one of: > none, millimeters, degrees. And I think this scale indication applies to an > entire capture set, not individual media captures. Everything in a > particular capture set must use the same scale. > > When we introduced the area of capture concept, and using a millimeter > scale, I thought that would eliminate the need for the Video Scale attribute > we had before. I now think we should bring back a separate Video Scale > attribute, because the area of capture won't always be enough to tell the > scale in terms of how large to render it to make it seem the appropriate > size at the rendering side. One example is an auto-switched video capture > that covers 0 to 99 (area of capture), while at any one time it is only > covering a third of it (video scale), so having a separate video scale > attribute allows the renderer to scale it accordingly if it wants. Now I > wonder if the scale attribute really should be associated with a video > stream in RTP, rather than with a video capture, because maybe it should be > more dynamic than capture set advertisements. > > Marshall, your definition of left and right makes good sense to me. > > Mark Duckworth > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > > Marshall Eubanks > > Sent: Wednesday, October 05, 2011 2:44 PM > > To: Brian Baldino (bbaldino) > > Cc: clue@ietf.org > > Subject: Re: [clue] Area of capture attribute > > > > On Wed, Oct 5, 2011 at 1:42 PM, Brian Baldino (bbaldino) > > wrote: > > > Hey Roni, > > > > > > Took my best shot inline. > > > > > > -Brian > > > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Roni > > > Even > > > Sent: Tuesday, October 04, 2011 11:03 PM > > > To: clue@ietf.org > > > Subject: [clue] Area of capture attribute > > > > > > Hi, > > > > > > I read the new revision and I think that this attribute is a good > > starting > > > point to address the discussion on the spatial description. I hope > > that we > > > will be able to finalize the model in the Interim meeting. > > > > > > I started a new thread after seeing the comments from Christian and > > Mark. > > > > > > I will send more feedback on the draft in a separate email. > > > > > > I think that there is some information missing that will be helpful > > > > > > 1. The position of the origin of the axis and the full range > > of the > > > area is needed probably as a capture set attribute in order to > > understand > > > the view. For example having a VC that says (0,33) does not provide > > enough > > > information to know what part of the room it covers. I do not think > > that > > > saying that there will be one configuration for example (VC1 (0,33), > > > VC2(33,66),VC3(66,99)) is the right way since it requires to have > > such > > > configuration and it also means that the range is (0,99) while it may > > also > > > be covering part of a (-10,110) range. The major requirement is not > > to use > > > implied information but be explicit. > > > > > > [BB] I think I agree that this might be useful, but, I'm not sure > > we've come > > > up with a use case that really demands it yet. Let me see if what I > > have in > > > mind for what you described (and why the origin and full range up > > front > > > aren't needed there) makes sense: > > > > > > I'm not sure what you've described (an advertiser only offering a > > single > > > video capture VC0(0,33)) would be that common (as, like you said, it > > isn't > > > very useful) but if it did, I still think the renderer could render > > it > > > sensibly. Since there are no other captures advertised, the renderer > > does > > > not need to be careful about rendering the VC in a certain position > > relative > > > to other captures from that same device because there are none. In > > your > > > example: if a 3 camera endpoint only advertised its left camera as > > VC0(0,33) > > > a 3 screen endpoint on the other end could render it wherever it > > wanted > > > because its main concern (making sure cameras from a multi-camera > > > transmitter are placed correctly relative to one another) is no > > longer an > > > issue. Perhaps there is a scenario unlike what I've just described > > where, > > > even though only one small subset of the entire device was > > advertised, it > > > was important to render it in exactly one place. Do you know of an > > example > > > where that may be the case? > > > > > > 2. I think that it is important not only to have the X > > coordinates but > > > also have the Y coordinates to be able to know if there is a gap or > > overlap > > > at the relevant distance. Again the origin of the axes is crucial > > here. > > > > > > [BB] The document provides for describing the area of capture in up > > to 3 > > > dimensions(x, y and z); seems like that gives the flexibility you're > > looking > > > for? > > > > > > > Ah, I missed that - it's implicit in 5.2.4. (I searched on vertical, > > which is nowhere mentioned.) Obviously, this could use some wording > > tweaks, which I promised to provide. > > > > In 5.2.4, I suggest you start with > > > > The area_of_capture attribute is used to describe the relevant area of > > which a media capture is "capturing". > > Area of capture is expressed as pairs of {x, y, z} coordinates to > > describe {left to right, front to back, low to high} ranges in that > > order where, as with point_of_capture, only the necessary dimensions > > need be expressed. In other words, it is specified that, as numbers > > move from lower to higher, the location is going from: left to right > > (in the case of the 'x' dimension), front to back (in the case of the > > 'y' dimension or low to high (in the case of the 'z' dimension). > > > > > > In 5.2.6. it says > > > > Area Scale Millimeters > > An optional Boolean variable indicating if the numbers used for area > > of capture and point of capture are in terms of millimeters. If this > > attribute is true, then the x,y,z numbers represent millimeters. If > > this attribute is false, then there is no physical scale. The default > > value is false. > > > > Note that "degrees" are not mentioned anywhere in the document. > > Degrees may not be a physical scale, but they are still a scale. (If > > you interpret {0,33} as radians or pixels, you are unlikely to get > > pleasing results.) There is another issue, as I don't know what the > > equivalent to angles are for front to back. > > > > I would change " If this attribute is false, then there is no physical > > scale." to > > > > " If this attribute is false, then the scale for x and z is degrees, > > and the scale for y remains mm." > > > > If you have another default scale for y, you should specify it (I > > can't imagine what it would be.) > > > > (BTW, I believe that I suggested y being up and down and z being front > > to back, precisely because most people will specify x, fewer up-down, > > and fewest front back distances. If you do that, you have to switch > > the definition of left and right to stage-left and stage-right to keep > > a right handed system.) > > > > In Section 3, it says. > > > > Left: For media captures, left and right is from the point of view of > > a person observing the rendered media. > > > > This is the opposite of stage-left and stage-right, and would be > > called camera-left and camera-right in American TV. > > > > In other words, "left" and "right" are camera-left and camera-right > > in theatrical parlance, and are the opposite of left and right for the > > person being observed. > > > > Actually, I would strongly urge the definition and _explicit_ use of > > camera-left and camera-right (or stage-left and stage-right) in EVERY > > occurrence of their use. > > > > If we don't do that, I am willing to bet someone will mess it up. > > > > So, if you do this, the definition becomes > > > > Camera-Left: For media captures, camera-left and camera-right is from > > the point of view of a person observing the rendered media. They are > > the opposite of stage-left and stage-right, which are the left and > > right of the person being observed. > > > > Note also that front and back are not defined. They should be. Up and > > down I think can go undefined. > > > > Front. Front is the portion of the room closest to the cameras. In > > going towards back you move away from the cameras. > > > > > > > 3. I am not sure about the example in section 7 for the active > > speaker > > > (VC3) "VC3- (the loudest panel stream), encoding group:EG1, > > > attributes:purpose=main;auto-switched:yes; area_of_capture={xBegin=0, > > > xEnd=99}". How do you know what is the area of capture you are really > > > getting, my understanding is that it is implied that there are > > VC0,VC1 and > > > VC2 and you get one of them. Again, I prefer explicit information for > > this > > > case even if it means having at attribute that will specify that the > > switch > > > is between VC0, VC1 and VC2 or have it as part of the auto-switch > > attribute. > > > > > > [BB] The idea here is that the transmitter is showing you the most > > > appropriate subset of that range. You're right the receiver doesn't > > know > > > specifically what's being sent, but, why does it care? The receiver > > signed > > > up for getting the most relevant stream in that range and that's what > > the > > > transmitter will send it. What do you think the receiver needs to > > know? > > > > > > > To scale the image appropriately. For example, if VC3 is really VC1, > > that could maybe be shown > > in full. If VC3 is really VC0+VC1+VC3 composited together, it should > > be letter boxed. > > > > I am also nervous about throwing away information when we don't have > > to. > > > > Regards > > Marshall > > > > > Regards > > > Roni > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf3071cc5c78174504ae9f84e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In order to get actual-size information with field-of-view in degrees, you = need to know the distance from the camera to the first row (which right now= is implicit in the mm scale).

This suggests a couple of mathematica= lly equivalent alternatives:
(a) provide both MM scale and field of view in degrees.=A0 If someone neede= d the distance to the first row, it could be computed.
(b) provide MM sc= ale and the distance to the first row.=A0 In this combination, field-of-vie= w in degrees can be computed.

(b) has an advantage in that it can be extended to include multiple row= s.

On Wed, Oct 5, 2011 at 5:15 PM, Duckwo= rth, Mark <Mark.Duckworth@polycom.com> wrote:
I can see that degrees might be a useful sc= ale for X and Z in addition to millimeters. =A0Maybe it should be tenths of= a degree, and use integers (no floating point)? =A0So if we allow that, th= en we need a way to indicate the scale of area of capture and point of capt= ure numbers which would be one of: none, millimeters, degrees. =A0And I thi= nk this scale indication applies to an entire capture set, not individual m= edia captures. =A0Everything in a particular capture set must use the same = scale.

When we introduced the area of capture concept, and using a millimeter scal= e, I thought that would eliminate the need for the Video Scale attribute we= had before. =A0I now think we should bring back a separate Video Scale att= ribute, because the area of capture won't always be enough to tell the = scale in terms of how large to render it to make it seem the appropriate si= ze at the rendering side. =A0One example is an auto-switched video capture = that covers 0 to 99 (area of capture), while at any one time it is only cov= ering a third of it (video scale), so having a separate video scale attribu= te allows the renderer to scale it accordingly if it wants. =A0Now I wonder= if the scale attribute really should be associated with a video stream in = RTP, rather than with a video capture, because maybe it should be more dyna= mic than capture set advertisements.

Marshall, your definition of left and right makes good sense to me.

Mark Duckworth

> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Marshall Eubanks
> Sent: Wednesday, October 05, 2011 2:44 PM
> To: Brian Baldino (bbaldino)
> Cc: clue@ietf.org
> Subject: Re: [clue] Area of capture attribute
>
> On Wed, Oct 5, 2011 at 1:42 PM, Brian Baldino (bbaldino)
> <bbaldino@cisco.com> w= rote:
> > Hey Roni,
> >
> > Took my best shot inline.
> >
> > -Brian
> >
> > From: clue-bounces@ietf.= org [mailto:clue-bounces@ietf.= org] On Behalf
> Of Roni
> > Even
> > Sent: Tuesday, October 04, 2011 11:03 PM
> > To: clue@ietf.org
> > Subject: [clue] Area of capture attribute
> >
> > Hi,
> >
> > I read the new revision and I think that this attribute is a good=
> starting
> > point to address the discussion on the spatial description. I hop= e
> that we
> > will be able to finalize the model in the Interim meeting.
> >
> > I started a new thread after seeing the comments from Christian a= nd
> Mark.
> >
> > I will send more feedback on the draft in a separate email.
> >
> > I think that there is some information missing that will be helpf= ul
> >
> > 1.=A0=A0=A0=A0=A0=A0 The position of the origin of the axis =A0an= d the full range
> of the
> > area is needed probably as a capture set attribute in order to > understand
> > the view. For example having a VC that says (0,33) does not provi= de
> enough
> > information to know what part of the room it covers. I do not thi= nk
> that
> > saying that there will be one configuration for example (VC1 (0,3= 3),
> > VC2(33,66),VC3(66,99)) is the right way since it requires to have=
> such
> > configuration and it also means that the range is (0,99) while it= may
> also
> > be covering part of a (-10,110) range. The major requirement is n= ot
> to use
> > implied information but be explicit.
> >
> > [BB] I think I agree that this might be useful, but, I'm not = sure
> we've come
> > up with a use case that really demands it yet.=A0 Let me see if w= hat I
> have in
> > mind for what you described (and why the origin and full range up=
> front
> > aren't needed there) makes sense:
> >
> > I'm not sure what you've described (an advertiser only of= fering a
> single
> > video capture VC0(0,33)) would be that common (as, like you said,= it
> isn't
> > very useful) but if it did, I still think the renderer could rend= er
> it
> > sensibly.=A0 Since there are no other captures advertised, the re= nderer
> does
> > not need to be careful about rendering the VC in a certain positi= on
> relative
> > to other captures from that same device because there are none.= =A0 In
> your
> > example: if a 3 camera endpoint only advertised its left camera a= s
> VC0(0,33)
> > a 3 screen endpoint on the other end could render it wherever it<= br> > wanted
> > because its main concern (making sure cameras from a multi-camera=
> > transmitter are placed correctly relative to one another) is no > longer an
> > issue.=A0 Perhaps there is a scenario unlike what I've just d= escribed
> where,
> > even though only one small subset of the entire device was
> advertised, it
> > was important to render it in exactly one place.=A0 Do you know o= f an
> example
> > where that may be the case?
> >
> > 2.=A0=A0=A0=A0=A0=A0 I think that it is important not only to hav= e the X
> coordinates but
> > also have the Y coordinates to be able to know if there is a gap = or
> overlap
> > at the relevant distance. Again the origin of the axes is crucial=
> here.
> >
> > [BB] The document provides for describing the area of capture in = up
> to 3
> > dimensions(x, y and z); seems like that gives the flexibility you= 're
> looking
> > for?
> >
>
> Ah, I missed that - it's implicit in 5.2.4. (I searched on vertica= l,
> which is nowhere mentioned.) Obviously, this could use some wording > tweaks, which I promised to provide.
>
> In 5.2.4, I suggest you start with
>
> The area_of_capture attribute is used to describe the relevant area of=
> which a media capture is "capturing".
> Area of capture is expressed as pairs of =A0{x, y, z} coordinates to > describe {left to right, front to back, low to high} ranges in that > order where, as with point_of_capture, only the necessary dimensions > need be expressed. In other words, it is specified that, as numbers > move from lower to higher, the location is going from: left to right > (in the case of the 'x' dimension), front to back (in the case= of the
> 'y' dimension or low to high (in the case of the 'z' d= imension).
>
>
> =A0In 5.2.6. it says
>
> =A0Area Scale Millimeters
> An optional Boolean variable indicating if the numbers used for area > of capture and point of capture are in terms of millimeters. If this > attribute is true, then the x,y,z numbers represent millimeters. If > this attribute is false, then there is no physical scale. The default<= br> > value is false.
>
> Note that "degrees" are not mentioned anywhere in the docume= nt.
> Degrees may not be a physical scale, but they are still a scale. (If > you interpret {0,33} as radians or pixels, you are unlikely to get
> pleasing results.) There is another issue, as I don't know what th= e
> equivalent to angles are for front to back.
>
> I would change " If this attribute is false, then there is no phy= sical
> scale." =A0to
>
> =A0" If this attribute is false, then the =A0scale for x and z is= degrees,
> and the scale for y remains mm."
>
> If you have another default scale for y, you should specify it (I
> can't imagine what it would be.)
>
> (BTW, I believe that I suggested y being up and down and z being front=
> to back, precisely because most people will specify x, fewer up-down,<= br> > and fewest front back distances. If you do that, you have to switch > the definition of left and right to stage-left and stage-right to keep=
> a right handed system.)
>
> In Section 3, it says.
>
> Left: For media captures, left and right is from the point of view of<= br> > a person observing the rendered media.
>
> This is the opposite of stage-left and stage-right, and would be
> called camera-left =A0and camera-right in American TV.
>
> In other words, "left" and "right" are camera-left= =A0and camera-right
> in theatrical parlance, and are the opposite of left and right for the=
> person being observed.
>
> Actually, I would strongly urge the =A0definition and _explicit_ use o= f
> camera-left and camera-right (or stage-left and stage-right) =A0in EVE= RY
> occurrence of their use.
>
> If we don't do that, I am willing to bet someone will mess it up.<= br> >
> So, if you do this, the definition becomes
>
> Camera-Left: For media captures, camera-left and camera-right is from<= br> > the point of view of a person observing the rendered media. They are > the opposite of stage-left and stage-right, which are the left and
> right of the person being observed.
>
> Note also that front and back are not defined. They should be. Up and<= br> > down I think can go undefined.
>
> Front. Front is the portion of the room closest to the cameras. In
> going towards back you move away from the cameras.
>
>
> > 3.=A0=A0=A0=A0=A0=A0 I am not sure about the example in section 7= for the active
> speaker
> > (VC3) "VC3- (the loudest panel stream), encoding group:EG1,<= br> > > attributes:purpose=3Dmain;auto-switched:yes; area_of_capture=3D{x= Begin=3D0,
> > xEnd=3D99}". How do you know what is the area of capture you= are really
> > getting, my understanding is that it is =A0implied that there are=
> VC0,VC1 and
> > VC2 and you get one of them. Again, I prefer explicit information= for
> this
> > case even if it means having at attribute that will specify that = the
> switch
> > is between VC0, VC1 and VC2 or have it as part of the auto-switch=
> attribute.
> >
> > [BB] The idea here is that the transmitter is showing you the mos= t
> > appropriate subset of that range.=A0 You're right the receive= r doesn't
> know
> > specifically what's being sent, but, why does it care?=A0 The= receiver
> signed
> > up for getting the most relevant stream in that range and that= 9;s what
> the
> > transmitter will send it.=A0 What do you think the receiver needs= to
> know?
> >
>
> To scale the image appropriately. For example, if VC3 is really VC1, > that could maybe be shown
> in full. If VC3 is really VC0+VC1+VC3 composited together, it should > be letter boxed.
>
> I am also nervous about throwing away information when we don't ha= ve
> to.
>
> Regards
> Marshall
>
> > Regards
> > Roni
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf3071cc5c78174504ae9f84e1-- From Even.roni@huawei.com Thu Oct 6 05:09:14 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BCE21F8BE4 for ; Thu, 6 Oct 2011 05:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.335 X-Spam-Level: X-Spam-Status: No, score=-106.335 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHFTyMZ5r-iV for ; Thu, 6 Oct 2011 05:09:13 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5699221F8B87 for ; Thu, 6 Oct 2011 05:09:12 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSN00GH08KK23@szxga05-in.huawei.com> for clue@ietf.org; Thu, 06 Oct 2011 20:12:20 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSN001F68KJZ8@szxga05-in.huawei.com> for clue@ietf.org; Thu, 06 Oct 2011 20:12:20 +0800 (CST) Received: from windows8d787f9 ([109.64.200.234]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LSN009YL8KFYD@szxml11-in.huawei.com> for clue@ietf.org; Thu, 06 Oct 2011 20:12:19 +0800 (CST) Date: Thu, 06 Oct 2011 14:09:30 +0200 From: Roni Even To: clue@ietf.org Message-id: <05e801cc8420$d0761040$716230c0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_sX+BH+13xaLoh3CdqQaCcw)" Content-language: en-us Thread-index: AcyEIMxfyhM4Qm9RSo+gI1jz6YgJOg== Subject: [clue] Review of definition section of draft-romanow-clue-framework-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 12:09:14 -0000 This is a multi-part message in MIME format. --Boundary_(ID_sX+BH+13xaLoh3CdqQaCcw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Some comments on the definition section. 1. Capture Scene is defined as the scene that is captured by a collection of Capture Devices. When reading the Capture device definition it looks like it does not include presentation. Is presentation a Scene or maybe we should define the scene by the capture sets that may be also presentation. 2. When looking at the capture set definition there is no relation to the capture scene. Maybe we should say that a Capture scene may include more than one capture sets. 3. Can individual encodes be used for presentation? All the text ties it to a capture device and I am not sure that it includes presentation. 4. On the endpoint definition how does it relate to the TP room and the rest of the terms here. Maybe we can say that an EP is represented by a capture scene. I think that this is missing later in the document when the structure starts from a capture set and the relation to scene and endpoint is not specified. 5. I am not sure why we have the model term defined. If there is a wish to have such definition than it should talk about a virtual TP system that adhere to the mandatory parts of the Telepresence protocol. Thanks Roni Even --Boundary_(ID_sX+BH+13xaLoh3CdqQaCcw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

Some comments = on the definition section.

 

1.       = Capture = Scene is defined as the scene that is captured by a collection of = Capture  Devices.  When reading the Capture device definition = it looks like it does not include presentation. Is presentation a Scene = or maybe we should define the scene by the capture sets that may be also = presentation.

2.       = When = looking at the capture set definition there is no relation to the = capture scene. Maybe we should say that a Capture scene may include more = than one capture sets.

3.       = Can = individual encodes be used for presentation? All the text ties it to a = capture device and I am not sure that it includes = presentation.

4.       = On the = endpoint definition how does it relate to the TP room and the rest of = the terms here. Maybe we can say that an EP is represented by a capture = scene. I think that this is missing later in the document when the = structure starts from a capture set and the relation to scene and = endpoint is not specified.

5.       = I am not = sure why we have the model term defined. If there is a wish to have such = definition than it should talk about a virtual TP system that adhere to = the mandatory parts of the Telepresence = protocol.

 =

 =

Thanks=

Roni = Even

 =

 =

= --Boundary_(ID_sX+BH+13xaLoh3CdqQaCcw)-- From mphmmr@gmail.com Thu Oct 6 07:19:09 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90DF21F8C18 for ; Thu, 6 Oct 2011 07:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.18 X-Spam-Level: X-Spam-Status: No, score=-4.18 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgyoP48bAbh9 for ; Thu, 6 Oct 2011 07:19:08 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D23021F8D5D for ; Thu, 6 Oct 2011 07:19:07 -0700 (PDT) Received: by wyh21 with SMTP id 21so3320436wyh.31 for ; Thu, 06 Oct 2011 07:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pPjseh+nKIV7SLbyzXn+Rln8rOxCCY92GGm/nk9SbHQ=; b=cBlL6JNVzErJRjFL/YF+s0/3FRka2JMG4kcVlx9qvV21PkE3cQeOb6agfrMjltiZXU QNAuIgAVs0MwKySUR1FfSSLxQUgCwzOxKo+QY+L8S6xTJaHb8g+VisqahfeMw9Jya2CP CItGXUM0cd+7ykCBDA73KFcGiLM1cB+h6GEfY= MIME-Version: 1.0 Received: by 10.216.137.223 with SMTP id y73mr1055459wei.6.1317910937569; Thu, 06 Oct 2011 07:22:17 -0700 (PDT) Received: by 10.216.139.88 with HTTP; Thu, 6 Oct 2011 07:22:16 -0700 (PDT) In-Reply-To: References: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61CDF41693@CRPMBOXPRD01.polycom.com> Date: Thu, 6 Oct 2011 10:22:16 -0400 Message-ID: From: Michael Hammer To: Stephen Botzko Content-Type: multipart/alternative; boundary=0016e6d7e92147890e04aea20dac Cc: "clue@ietf.org" Subject: Re: [clue] Area of capture attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 14:19:10 -0000 --0016e6d7e92147890e04aea20dac Content-Type: text/plain; charset=ISO-8859-1 This discussion about the scale and distance to first row sounds a lot like the definition of the aperature of a camera lens. If so, lenses often have a focal point which could be up close or distant along with a depth of field. Sometimes stuff in the foreground or distance or both are out of focus. Presumable, the cameras used for capture have already built-in in such a range/depth determination that could be used. Zoom lenses that might be dynamic might also have some type of settings to exploit. Camera/lens vendors would be useful here. Mike On Thu, Oct 6, 2011 at 7:20 AM, Stephen Botzko wrote: > In order to get actual-size information with field-of-view in degrees, you > need to know the distance from the camera to the first row (which right now > is implicit in the mm scale). > > This suggests a couple of mathematically equivalent alternatives: > (a) provide both MM scale and field of view in degrees. If someone needed > the distance to the first row, it could be computed. > (b) provide MM scale and the distance to the first row. In this > combination, field-of-view in degrees can be computed. > > (b) has an advantage in that it can be extended to include multiple rows. > > > On Wed, Oct 5, 2011 at 5:15 PM, Duckworth, Mark < > Mark.Duckworth@polycom.com> wrote: > >> I can see that degrees might be a useful scale for X and Z in addition to >> millimeters. Maybe it should be tenths of a degree, and use integers (no >> floating point)? So if we allow that, then we need a way to indicate the >> scale of area of capture and point of capture numbers which would be one of: >> none, millimeters, degrees. And I think this scale indication applies to an >> entire capture set, not individual media captures. Everything in a >> particular capture set must use the same scale. >> >> When we introduced the area of capture concept, and using a millimeter >> scale, I thought that would eliminate the need for the Video Scale attribute >> we had before. I now think we should bring back a separate Video Scale >> attribute, because the area of capture won't always be enough to tell the >> scale in terms of how large to render it to make it seem the appropriate >> size at the rendering side. One example is an auto-switched video capture >> that covers 0 to 99 (area of capture), while at any one time it is only >> covering a third of it (video scale), so having a separate video scale >> attribute allows the renderer to scale it accordingly if it wants. Now I >> wonder if the scale attribute really should be associated with a video >> stream in RTP, rather than with a video capture, because maybe it should be >> more dynamic than capture set advertisements. >> >> Marshall, your definition of left and right makes good sense to me. >> >> Mark Duckworth >> >> > -----Original Message----- >> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> > Marshall Eubanks >> > Sent: Wednesday, October 05, 2011 2:44 PM >> > To: Brian Baldino (bbaldino) >> > Cc: clue@ietf.org >> > Subject: Re: [clue] Area of capture attribute >> > >> > On Wed, Oct 5, 2011 at 1:42 PM, Brian Baldino (bbaldino) >> > wrote: >> > > Hey Roni, >> > > >> > > Took my best shot inline. >> > > >> > > -Brian >> > > >> > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> > Of Roni >> > > Even >> > > Sent: Tuesday, October 04, 2011 11:03 PM >> > > To: clue@ietf.org >> > > Subject: [clue] Area of capture attribute >> > > >> > > Hi, >> > > >> > > I read the new revision and I think that this attribute is a good >> > starting >> > > point to address the discussion on the spatial description. I hope >> > that we >> > > will be able to finalize the model in the Interim meeting. >> > > >> > > I started a new thread after seeing the comments from Christian and >> > Mark. >> > > >> > > I will send more feedback on the draft in a separate email. >> > > >> > > I think that there is some information missing that will be helpful >> > > >> > > 1. The position of the origin of the axis and the full range >> > of the >> > > area is needed probably as a capture set attribute in order to >> > understand >> > > the view. For example having a VC that says (0,33) does not provide >> > enough >> > > information to know what part of the room it covers. I do not think >> > that >> > > saying that there will be one configuration for example (VC1 (0,33), >> > > VC2(33,66),VC3(66,99)) is the right way since it requires to have >> > such >> > > configuration and it also means that the range is (0,99) while it may >> > also >> > > be covering part of a (-10,110) range. The major requirement is not >> > to use >> > > implied information but be explicit. >> > > >> > > [BB] I think I agree that this might be useful, but, I'm not sure >> > we've come >> > > up with a use case that really demands it yet. Let me see if what I >> > have in >> > > mind for what you described (and why the origin and full range up >> > front >> > > aren't needed there) makes sense: >> > > >> > > I'm not sure what you've described (an advertiser only offering a >> > single >> > > video capture VC0(0,33)) would be that common (as, like you said, it >> > isn't >> > > very useful) but if it did, I still think the renderer could render >> > it >> > > sensibly. Since there are no other captures advertised, the renderer >> > does >> > > not need to be careful about rendering the VC in a certain position >> > relative >> > > to other captures from that same device because there are none. In >> > your >> > > example: if a 3 camera endpoint only advertised its left camera as >> > VC0(0,33) >> > > a 3 screen endpoint on the other end could render it wherever it >> > wanted >> > > because its main concern (making sure cameras from a multi-camera >> > > transmitter are placed correctly relative to one another) is no >> > longer an >> > > issue. Perhaps there is a scenario unlike what I've just described >> > where, >> > > even though only one small subset of the entire device was >> > advertised, it >> > > was important to render it in exactly one place. Do you know of an >> > example >> > > where that may be the case? >> > > >> > > 2. I think that it is important not only to have the X >> > coordinates but >> > > also have the Y coordinates to be able to know if there is a gap or >> > overlap >> > > at the relevant distance. Again the origin of the axes is crucial >> > here. >> > > >> > > [BB] The document provides for describing the area of capture in up >> > to 3 >> > > dimensions(x, y and z); seems like that gives the flexibility you're >> > looking >> > > for? >> > > >> > >> > Ah, I missed that - it's implicit in 5.2.4. (I searched on vertical, >> > which is nowhere mentioned.) Obviously, this could use some wording >> > tweaks, which I promised to provide. >> > >> > In 5.2.4, I suggest you start with >> > >> > The area_of_capture attribute is used to describe the relevant area of >> > which a media capture is "capturing". >> > Area of capture is expressed as pairs of {x, y, z} coordinates to >> > describe {left to right, front to back, low to high} ranges in that >> > order where, as with point_of_capture, only the necessary dimensions >> > need be expressed. In other words, it is specified that, as numbers >> > move from lower to higher, the location is going from: left to right >> > (in the case of the 'x' dimension), front to back (in the case of the >> > 'y' dimension or low to high (in the case of the 'z' dimension). >> > >> > >> > In 5.2.6. it says >> > >> > Area Scale Millimeters >> > An optional Boolean variable indicating if the numbers used for area >> > of capture and point of capture are in terms of millimeters. If this >> > attribute is true, then the x,y,z numbers represent millimeters. If >> > this attribute is false, then there is no physical scale. The default >> > value is false. >> > >> > Note that "degrees" are not mentioned anywhere in the document. >> > Degrees may not be a physical scale, but they are still a scale. (If >> > you interpret {0,33} as radians or pixels, you are unlikely to get >> > pleasing results.) There is another issue, as I don't know what the >> > equivalent to angles are for front to back. >> > >> > I would change " If this attribute is false, then there is no physical >> > scale." to >> > >> > " If this attribute is false, then the scale for x and z is degrees, >> > and the scale for y remains mm." >> > >> > If you have another default scale for y, you should specify it (I >> > can't imagine what it would be.) >> > >> > (BTW, I believe that I suggested y being up and down and z being front >> > to back, precisely because most people will specify x, fewer up-down, >> > and fewest front back distances. If you do that, you have to switch >> > the definition of left and right to stage-left and stage-right to keep >> > a right handed system.) >> > >> > In Section 3, it says. >> > >> > Left: For media captures, left and right is from the point of view of >> > a person observing the rendered media. >> > >> > This is the opposite of stage-left and stage-right, and would be >> > called camera-left and camera-right in American TV. >> > >> > In other words, "left" and "right" are camera-left and camera-right >> > in theatrical parlance, and are the opposite of left and right for the >> > person being observed. >> > >> > Actually, I would strongly urge the definition and _explicit_ use of >> > camera-left and camera-right (or stage-left and stage-right) in EVERY >> > occurrence of their use. >> > >> > If we don't do that, I am willing to bet someone will mess it up. >> > >> > So, if you do this, the definition becomes >> > >> > Camera-Left: For media captures, camera-left and camera-right is from >> > the point of view of a person observing the rendered media. They are >> > the opposite of stage-left and stage-right, which are the left and >> > right of the person being observed. >> > >> > Note also that front and back are not defined. They should be. Up and >> > down I think can go undefined. >> > >> > Front. Front is the portion of the room closest to the cameras. In >> > going towards back you move away from the cameras. >> > >> > >> > > 3. I am not sure about the example in section 7 for the active >> > speaker >> > > (VC3) "VC3- (the loudest panel stream), encoding group:EG1, >> > > attributes:purpose=main;auto-switched:yes; area_of_capture={xBegin=0, >> > > xEnd=99}". How do you know what is the area of capture you are really >> > > getting, my understanding is that it is implied that there are >> > VC0,VC1 and >> > > VC2 and you get one of them. Again, I prefer explicit information for >> > this >> > > case even if it means having at attribute that will specify that the >> > switch >> > > is between VC0, VC1 and VC2 or have it as part of the auto-switch >> > attribute. >> > > >> > > [BB] The idea here is that the transmitter is showing you the most >> > > appropriate subset of that range. You're right the receiver doesn't >> > know >> > > specifically what's being sent, but, why does it care? The receiver >> > signed >> > > up for getting the most relevant stream in that range and that's what >> > the >> > > transmitter will send it. What do you think the receiver needs to >> > know? >> > > >> > >> > To scale the image appropriately. For example, if VC3 is really VC1, >> > that could maybe be shown >> > in full. If VC3 is really VC0+VC1+VC3 composited together, it should >> > be letter boxed. >> > >> > I am also nervous about throwing away information when we don't have >> > to. >> > >> > Regards >> > Marshall >> > >> > > Regards >> > > Roni >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --0016e6d7e92147890e04aea20dac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This discussion about the scale and distance to first row sounds a lot= like the definition of the aperature of a camera lens.=A0 If so, lenses of= ten have a focal point which could be up close or distant along with a dept= h of field.=A0 Sometimes stuff in the foreground or distance or both are ou= t of focus.=A0 Presumable, the cameras used for capture have already built-= in in such a range/depth determination that could be used.=A0 Zoom lenses t= hat might be dynamic might also have some type of settings to exploit.
=A0
Camera/lens vendors would be useful here.
=A0<= /div>
Mike


=A0
On Thu= , Oct 6, 2011 at 7:20 AM, Stephen Botzko <stephen.botzko@gmail.com> wro= te:
In order to get actual-size information with f= ield-of-view in degrees, you need to know the distance from the camera to t= he first row (which right now is implicit in the mm scale).

This suggests a couple of mathematically equivalent alternatives:
(a) provide both MM scale and field of view in degrees.=A0 If someone neede= d the distance to the first row, it could be computed.
(b) provide MM sc= ale and the distance to the first row.=A0 In this combination, field-of-vie= w in degrees can be computed.

(b) has an advantage in that it can be extended to include multiple row= s.


On W= ed, Oct 5, 2011 at 5:15 PM, Duckworth, Mark <Mark.Duckworth@pol= ycom.com> wrote:
I can see that degrees might be a useful scale= for X and Z in addition to millimeters. =A0Maybe it should be tenths of a = degree, and use integers (no floating point)? =A0So if we allow that, then = we need a way to indicate the scale of area of capture and point of capture= numbers which would be one of: none, millimeters, degrees. =A0And I think = this scale indication applies to an entire capture set, not individual medi= a captures. =A0Everything in a particular capture set must use the same sca= le.

When we introduced the area of capture concept, and using a millimeter scal= e, I thought that would eliminate the need for the Video Scale attribute we= had before. =A0I now think we should bring back a separate Video Scale att= ribute, because the area of capture won't always be enough to tell the = scale in terms of how large to render it to make it seem the appropriate si= ze at the rendering side. =A0One example is an auto-switched video capture = that covers 0 to 99 (area of capture), while at any one time it is only cov= ering a third of it (video scale), so having a separate video scale attribu= te allows the renderer to scale it accordingly if it wants. =A0Now I wonder= if the scale attribute really should be associated with a video stream in = RTP, rather than with a video capture, because maybe it should be more dyna= mic than capture set advertisements.

Marshall, your definition of left and right makes good sense to me.

Mark Duckworth

> -----Original Message-----
> From: clue-= bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Marshall Eubanks
> Sent: Wednesday, October 05, 2011 2:44 PM
> To: Brian Baldino (bbaldino)
> Cc: clue@ietf.org
> Subject: Re: [clue] Area of capture attribute
>
> On Wed, Oct 5, 2011 at 1:42 PM, Brian Baldino (bbaldino)
> <bbaldino@c= isco.com> wrote:
> > Hey Roni,
> >
> > Took my best shot inline.
> >
> > -Brian
> >
> > From: = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
> Of Roni
> > Even
> > Sent: Tuesday, October 04, 2011 11:03 PM
> > To: clue@ietf.= org
> > Subject: [clue] Area of capture attribute
> >
> > Hi,
> >
> > I read the new revision and I think that this attribute is a good=
> starting
> > point to address the discussion on the spatial description. I hop= e
> that we
> > will be able to finalize the model in the Interim meeting.
> >
> > I started a new thread after seeing the comments from Christian a= nd
> Mark.
> >
> > I will send more feedback on the draft in a separate email.
> >
> > I think that there is some information missing that will be helpf= ul
> >
> > 1.=A0=A0=A0=A0=A0=A0 The position of the origin of the axis =A0an= d the full range
> of the
> > area is needed probably as a capture set attribute in order to > understand
> > the view. For example having a VC that says (0,33) does not provi= de
> enough
> > information to know what part of the room it covers. I do not thi= nk
> that
> > saying that there will be one configuration for example (VC1 (0,3= 3),
> > VC2(33,66),VC3(66,99)) is the right way since it requires to have=
> such
> > configuration and it also means that the range is (0,99) while it= may
> also
> > be covering part of a (-10,110) range. The major requirement is n= ot
> to use
> > implied information but be explicit.
> >
> > [BB] I think I agree that this might be useful, but, I'm not = sure
> we've come
> > up with a use case that really demands it yet.=A0 Let me see if w= hat I
> have in
> > mind for what you described (and why the origin and full range up=
> front
> > aren't needed there) makes sense:
> >
> > I'm not sure what you've described (an advertiser only of= fering a
> single
> > video capture VC0(0,33)) would be that common (as, like you said,= it
> isn't
> > very useful) but if it did, I still think the renderer could rend= er
> it
> > sensibly.=A0 Since there are no other captures advertised, the re= nderer
> does
> > not need to be careful about rendering the VC in a certain positi= on
> relative
> > to other captures from that same device because there are none.= =A0 In
> your
> > example: if a 3 camera endpoint only advertised its left camera a= s
> VC0(0,33)
> > a 3 screen endpoint on the other end could render it wherever it<= br> > wanted
> > because its main concern (making sure cameras from a multi-camera=
> > transmitter are placed correctly relative to one another) is no > longer an
> > issue.=A0 Perhaps there is a scenario unlike what I've just d= escribed
> where,
> > even though only one small subset of the entire device was
> advertised, it
> > was important to render it in exactly one place.=A0 Do you know o= f an
> example
> > where that may be the case?
> >
> > 2.=A0=A0=A0=A0=A0=A0 I think that it is important not only to hav= e the X
> coordinates but
> > also have the Y coordinates to be able to know if there is a gap = or
> overlap
> > at the relevant distance. Again the origin of the axes is crucial=
> here.
> >
> > [BB] The document provides for describing the area of capture in = up
> to 3
> > dimensions(x, y and z); seems like that gives the flexibility you= 're
> looking
> > for?
> >
>
> Ah, I missed that - it's implicit in 5.2.4. (I searched on vertica= l,
> which is nowhere mentioned.) Obviously, this could use some wording > tweaks, which I promised to provide.
>
> In 5.2.4, I suggest you start with
>
> The area_of_capture attribute is used to describe the relevant area of=
> which a media capture is "capturing".
> Area of capture is expressed as pairs of =A0{x, y, z} coordinates to > describe {left to right, front to back, low to high} ranges in that > order where, as with point_of_capture, only the necessary dimensions > need be expressed. In other words, it is specified that, as numbers > move from lower to higher, the location is going from: left to right > (in the case of the 'x' dimension), front to back (in the case= of the
> 'y' dimension or low to high (in the case of the 'z' d= imension).
>
>
> =A0In 5.2.6. it says
>
> =A0Area Scale Millimeters
> An optional Boolean variable indicating if the numbers used for area > of capture and point of capture are in terms of millimeters. If this > attribute is true, then the x,y,z numbers represent millimeters. If > this attribute is false, then there is no physical scale. The default<= br> > value is false.
>
> Note that "degrees" are not mentioned anywhere in the docume= nt.
> Degrees may not be a physical scale, but they are still a scale. (If > you interpret {0,33} as radians or pixels, you are unlikely to get
> pleasing results.) There is another issue, as I don't know what th= e
> equivalent to angles are for front to back.
>
> I would change " If this attribute is false, then there is no phy= sical
> scale." =A0to
>
> =A0" If this attribute is false, then the =A0scale for x and z is= degrees,
> and the scale for y remains mm."
>
> If you have another default scale for y, you should specify it (I
> can't imagine what it would be.)
>
> (BTW, I believe that I suggested y being up and down and z being front=
> to back, precisely because most people will specify x, fewer up-down,<= br> > and fewest front back distances. If you do that, you have to switch > the definition of left and right to stage-left and stage-right to keep=
> a right handed system.)
>
> In Section 3, it says.
>
> Left: For media captures, left and right is from the point of view of<= br> > a person observing the rendered media.
>
> This is the opposite of stage-left and stage-right, and would be
> called camera-left =A0and camera-right in American TV.
>
> In other words, "left" and "right" are camera-left= =A0and camera-right
> in theatrical parlance, and are the opposite of left and right for the=
> person being observed.
>
> Actually, I would strongly urge the =A0definition and _explicit_ use o= f
> camera-left and camera-right (or stage-left and stage-right) =A0in EVE= RY
> occurrence of their use.
>
> If we don't do that, I am willing to bet someone will mess it up.<= br> >
> So, if you do this, the definition becomes
>
> Camera-Left: For media captures, camera-left and camera-right is from<= br> > the point of view of a person observing the rendered media. They are > the opposite of stage-left and stage-right, which are the left and
> right of the person being observed.
>
> Note also that front and back are not defined. They should be. Up and<= br> > down I think can go undefined.
>
> Front. Front is the portion of the room closest to the cameras. In
> going towards back you move away from the cameras.
>
>
> > 3.=A0=A0=A0=A0=A0=A0 I am not sure about the example in section 7= for the active
> speaker
> > (VC3) "VC3- (the loudest panel stream), encoding group:EG1,<= br> > > attributes:purpose=3Dmain;auto-switched:yes; area_of_capture=3D{x= Begin=3D0,
> > xEnd=3D99}". How do you know what is the area of capture you= are really
> > getting, my understanding is that it is =A0implied that there are=
> VC0,VC1 and
> > VC2 and you get one of them. Again, I prefer explicit information= for
> this
> > case even if it means having at attribute that will specify that = the
> switch
> > is between VC0, VC1 and VC2 or have it as part of the auto-switch=
> attribute.
> >
> > [BB] The idea here is that the transmitter is showing you the mos= t
> > appropriate subset of that range.=A0 You're right the receive= r doesn't
> know
> > specifically what's being sent, but, why does it care?=A0 The= receiver
> signed
> > up for getting the most relevant stream in that range and that= 9;s what
> the
> > transmitter will send it.=A0 What do you think the receiver needs= to
> know?
> >
>
> To scale the image appropriately. For example, if VC3 is really VC1, > that could maybe be shown
> in full. If VC3 is really VC0+VC1+VC3 composited together, it should > be letter boxed.
>
> I am also nervous about throwing away information when we don't ha= ve
> to.
>
> Regards
> Marshall
>
> > Regards
> > Roni
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


--0016e6d7e92147890e04aea20dac-- From marshall.eubanks@gmail.com Thu Oct 6 07:54:16 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A1821F8C98 for ; Thu, 6 Oct 2011 07:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.968 X-Spam-Level: X-Spam-Status: No, score=-103.968 tagged_above=-999 required=5 tests=[AWL=1.031, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRMc5+T6mwEx for ; Thu, 6 Oct 2011 07:54:15 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF02421F8C92 for ; Thu, 6 Oct 2011 07:54:14 -0700 (PDT) Received: by ywm3 with SMTP id 3so3269185ywm.31 for ; Thu, 06 Oct 2011 07:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4noJnE0NFXwAKbbyB+uNShDqpO/zcQKxIFPsyhxrDgM=; b=K4F1xh141dxqEOQYLvjoPO5VAPWhtR+TfaHapXwXdjAcNu1l8jNXR+xYf1VnWWDEpd irELp/lxcIXxexIO55n9/FY4gD3y5+i3LljPstjoFXr+drMYGLuks18LxYjPKw65vdzl kCOl1ePoMv/WHuil/mD3clmnxuKnfv3JQY6s0= MIME-Version: 1.0 Received: by 10.150.53.12 with SMTP id b12mr614978yba.140.1317913045621; Thu, 06 Oct 2011 07:57:25 -0700 (PDT) Received: by 10.151.98.20 with HTTP; Thu, 6 Oct 2011 07:57:25 -0700 (PDT) In-Reply-To: References: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61CDF41693@CRPMBOXPRD01.polycom.com> Date: Thu, 6 Oct 2011 10:57:25 -0400 Message-ID: From: Marshall Eubanks To: Stephen Botzko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "clue@ietf.org" Subject: Re: [clue] Area of capture attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 14:54:16 -0000 On Thu, Oct 6, 2011 at 7:20 AM, Stephen Botzko w= rote: > In order to get actual-size information with field-of-view in degrees, yo= u > need to know the distance from the camera to the first row (which right n= ow > is implicit in the mm scale). > > This suggests a couple of mathematically equivalent alternatives: > (a) provide both MM scale and field of view in degrees.=A0 If someone nee= ded > the distance to the first row, it could be computed. > (b) provide MM scale and the distance to the first row.=A0 In this > combination, field-of-view in degrees can be computed. > > (b) has an advantage in that it can be extended to include multiple rows. In a kludgy way (mm means mm, except for the second row, when it doesn't). I prefer (c) Provide the FOV in degrees and a scale factor (standard length). Is there any reason why this shouldn't be (possibly) included for every scene captured, including possibly sub-scene. (In other words, how do you determine the distance to the second row without information about that scale factor.) I am also specifically interested in including podium type situations, which are not "rows." Regards Marshall > > On Wed, Oct 5, 2011 at 5:15 PM, Duckworth, Mark > wrote: >> >> I can see that degrees might be a useful scale for X and Z in addition t= o >> millimeters. =A0Maybe it should be tenths of a degree, and use integers = (no >> floating point)? =A0So if we allow that, then we need a way to indicate = the >> scale of area of capture and point of capture numbers which would be one= of: >> none, millimeters, degrees. =A0And I think this scale indication applies= to an >> entire capture set, not individual media captures. =A0Everything in a >> particular capture set must use the same scale. >> >> When we introduced the area of capture concept, and using a millimeter >> scale, I thought that would eliminate the need for the Video Scale attri= bute >> we had before. =A0I now think we should bring back a separate Video Scal= e >> attribute, because the area of capture won't always be enough to tell th= e >> scale in terms of how large to render it to make it seem the appropriate >> size at the rendering side. =A0One example is an auto-switched video cap= ture >> that covers 0 to 99 (area of capture), while at any one time it is only >> covering a third of it (video scale), so having a separate video scale >> attribute allows the renderer to scale it accordingly if it wants. =A0No= w I >> wonder if the scale attribute really should be associated with a video >> stream in RTP, rather than with a video capture, because maybe it should= be >> more dynamic than capture set advertisements. >> >> Marshall, your definition of left and right makes good sense to me. >> >> Mark Duckworth >> >> > -----Original Message----- >> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf O= f >> > Marshall Eubanks >> > Sent: Wednesday, October 05, 2011 2:44 PM >> > To: Brian Baldino (bbaldino) >> > Cc: clue@ietf.org >> > Subject: Re: [clue] Area of capture attribute >> > >> > On Wed, Oct 5, 2011 at 1:42 PM, Brian Baldino (bbaldino) >> > wrote: >> > > Hey Roni, >> > > >> > > Took my best shot inline. >> > > >> > > -Brian >> > > >> > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> > Of Roni >> > > Even >> > > Sent: Tuesday, October 04, 2011 11:03 PM >> > > To: clue@ietf.org >> > > Subject: [clue] Area of capture attribute >> > > >> > > Hi, >> > > >> > > I read the new revision and I think that this attribute is a good >> > starting >> > > point to address the discussion on the spatial description. I hope >> > that we >> > > will be able to finalize the model in the Interim meeting. >> > > >> > > I started a new thread after seeing the comments from Christian and >> > Mark. >> > > >> > > I will send more feedback on the draft in a separate email. >> > > >> > > I think that there is some information missing that will be helpful >> > > >> > > 1.=A0=A0=A0=A0=A0=A0 The position of the origin of the axis =A0and t= he full range >> > of the >> > > area is needed probably as a capture set attribute in order to >> > understand >> > > the view. For example having a VC that says (0,33) does not provide >> > enough >> > > information to know what part of the room it covers. I do not think >> > that >> > > saying that there will be one configuration for example (VC1 (0,33), >> > > VC2(33,66),VC3(66,99)) is the right way since it requires to have >> > such >> > > configuration and it also means that the range is (0,99) while it ma= y >> > also >> > > be covering part of a (-10,110) range. The major requirement is not >> > to use >> > > implied information but be explicit. >> > > >> > > [BB] I think I agree that this might be useful, but, I'm not sure >> > we've come >> > > up with a use case that really demands it yet.=A0 Let me see if what= I >> > have in >> > > mind for what you described (and why the origin and full range up >> > front >> > > aren't needed there) makes sense: >> > > >> > > I'm not sure what you've described (an advertiser only offering a >> > single >> > > video capture VC0(0,33)) would be that common (as, like you said, it >> > isn't >> > > very useful) but if it did, I still think the renderer could render >> > it >> > > sensibly.=A0 Since there are no other captures advertised, the rende= rer >> > does >> > > not need to be careful about rendering the VC in a certain position >> > relative >> > > to other captures from that same device because there are none.=A0 I= n >> > your >> > > example: if a 3 camera endpoint only advertised its left camera as >> > VC0(0,33) >> > > a 3 screen endpoint on the other end could render it wherever it >> > wanted >> > > because its main concern (making sure cameras from a multi-camera >> > > transmitter are placed correctly relative to one another) is no >> > longer an >> > > issue.=A0 Perhaps there is a scenario unlike what I've just describe= d >> > where, >> > > even though only one small subset of the entire device was >> > advertised, it >> > > was important to render it in exactly one place.=A0 Do you know of a= n >> > example >> > > where that may be the case? >> > > >> > > 2.=A0=A0=A0=A0=A0=A0 I think that it is important not only to have t= he X >> > coordinates but >> > > also have the Y coordinates to be able to know if there is a gap or >> > overlap >> > > at the relevant distance. Again the origin of the axes is crucial >> > here. >> > > >> > > [BB] The document provides for describing the area of capture in up >> > to 3 >> > > dimensions(x, y and z); seems like that gives the flexibility you're >> > looking >> > > for? >> > > >> > >> > Ah, I missed that - it's implicit in 5.2.4. (I searched on vertical, >> > which is nowhere mentioned.) Obviously, this could use some wording >> > tweaks, which I promised to provide. >> > >> > In 5.2.4, I suggest you start with >> > >> > The area_of_capture attribute is used to describe the relevant area of >> > which a media capture is "capturing". >> > Area of capture is expressed as pairs of =A0{x, y, z} coordinates to >> > describe {left to right, front to back, low to high} ranges in that >> > order where, as with point_of_capture, only the necessary dimensions >> > need be expressed. In other words, it is specified that, as numbers >> > move from lower to higher, the location is going from: left to right >> > (in the case of the 'x' dimension), front to back (in the case of the >> > 'y' dimension or low to high (in the case of the 'z' dimension). >> > >> > >> > =A0In 5.2.6. it says >> > >> > =A0Area Scale Millimeters >> > An optional Boolean variable indicating if the numbers used for area >> > of capture and point of capture are in terms of millimeters. If this >> > attribute is true, then the x,y,z numbers represent millimeters. If >> > this attribute is false, then there is no physical scale. The default >> > value is false. >> > >> > Note that "degrees" are not mentioned anywhere in the document. >> > Degrees may not be a physical scale, but they are still a scale. (If >> > you interpret {0,33} as radians or pixels, you are unlikely to get >> > pleasing results.) There is another issue, as I don't know what the >> > equivalent to angles are for front to back. >> > >> > I would change " If this attribute is false, then there is no physical >> > scale." =A0to >> > >> > =A0" If this attribute is false, then the =A0scale for x and z is degr= ees, >> > and the scale for y remains mm." >> > >> > If you have another default scale for y, you should specify it (I >> > can't imagine what it would be.) >> > >> > (BTW, I believe that I suggested y being up and down and z being front >> > to back, precisely because most people will specify x, fewer up-down, >> > and fewest front back distances. If you do that, you have to switch >> > the definition of left and right to stage-left and stage-right to keep >> > a right handed system.) >> > >> > In Section 3, it says. >> > >> > Left: For media captures, left and right is from the point of view of >> > a person observing the rendered media. >> > >> > This is the opposite of stage-left and stage-right, and would be >> > called camera-left =A0and camera-right in American TV. >> > >> > In other words, "left" and "right" are camera-left =A0and camera-right >> > in theatrical parlance, and are the opposite of left and right for the >> > person being observed. >> > >> > Actually, I would strongly urge the =A0definition and _explicit_ use o= f >> > camera-left and camera-right (or stage-left and stage-right) =A0in EVE= RY >> > occurrence of their use. >> > >> > If we don't do that, I am willing to bet someone will mess it up. >> > >> > So, if you do this, the definition becomes >> > >> > Camera-Left: For media captures, camera-left and camera-right is from >> > the point of view of a person observing the rendered media. They are >> > the opposite of stage-left and stage-right, which are the left and >> > right of the person being observed. >> > >> > Note also that front and back are not defined. They should be. Up and >> > down I think can go undefined. >> > >> > Front. Front is the portion of the room closest to the cameras. In >> > going towards back you move away from the cameras. >> > >> > >> > > 3.=A0=A0=A0=A0=A0=A0 I am not sure about the example in section 7 fo= r the active >> > speaker >> > > (VC3) "VC3- (the loudest panel stream), encoding group:EG1, >> > > attributes:purpose=3Dmain;auto-switched:yes; area_of_capture=3D{xBeg= in=3D0, >> > > xEnd=3D99}". How do you know what is the area of capture you are rea= lly >> > > getting, my understanding is that it is =A0implied that there are >> > VC0,VC1 and >> > > VC2 and you get one of them. Again, I prefer explicit information fo= r >> > this >> > > case even if it means having at attribute that will specify that the >> > switch >> > > is between VC0, VC1 and VC2 or have it as part of the auto-switch >> > attribute. >> > > >> > > [BB] The idea here is that the transmitter is showing you the most >> > > appropriate subset of that range.=A0 You're right the receiver doesn= 't >> > know >> > > specifically what's being sent, but, why does it care?=A0 The receiv= er >> > signed >> > > up for getting the most relevant stream in that range and that's wha= t >> > the >> > > transmitter will send it.=A0 What do you think the receiver needs to >> > know? >> > > >> > >> > To scale the image appropriately. For example, if VC3 is really VC1, >> > that could maybe be shown >> > in full. If VC3 is really VC0+VC1+VC3 composited together, it should >> > be letter boxed. >> > >> > I am also nervous about throwing away information when we don't have >> > to. >> > >> > Regards >> > Marshall >> > >> > > Regards >> > > Roni >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From stephen.botzko@gmail.com Thu Oct 6 08:06:24 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4727C21F8D8E for ; Thu, 6 Oct 2011 08:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.082 X-Spam-Level: X-Spam-Status: No, score=-4.082 tagged_above=-999 required=5 tests=[AWL=0.916, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjyD6EkBfJU9 for ; Thu, 6 Oct 2011 08:06:22 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DDA8521F8B7B for ; Thu, 6 Oct 2011 08:06:21 -0700 (PDT) Received: by vws5 with SMTP id 5so2880998vws.31 for ; Thu, 06 Oct 2011 08:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pPd/RybTf8OQ7e/kqwAgI+kIHVcGaWWExCoutY/e34g=; b=ZOxUm+fTcbsjN5jmqMtO9zlIYc96NUltiTsB2lva2ku9aAuUaBSksgzMjKAYiBLWj1 21uWdKac9je7EMaB5oMMCi1BnELwvpcn+WC2LNSsSecN4LDVkKmticRYg8qSElYy9D96 yFkiLF0z8jAoP5EvTJE+J14dH9imNYjEwLNg4= MIME-Version: 1.0 Received: by 10.52.65.82 with SMTP id v18mr830300vds.199.1317913772472; Thu, 06 Oct 2011 08:09:32 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Thu, 6 Oct 2011 08:09:32 -0700 (PDT) In-Reply-To: References: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61CDF41693@CRPMBOXPRD01.polycom.com> Date: Thu, 6 Oct 2011 11:09:32 -0400 Message-ID: From: Stephen Botzko To: Marshall Eubanks Content-Type: multipart/alternative; boundary=20cf3071cc5c40ba9604aea2b6ff Cc: "clue@ietf.org" Subject: Re: [clue] Area of capture attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 15:06:24 -0000 --20cf3071cc5c40ba9604aea2b6ff Content-Type: text/plain; charset=ISO-8859-1 >>> (c) Provide the FOV in degrees and a scale factor (standard length). >>> Not sure how that is different from (a); it seems the same to me. Maybe we can discuss next week Stephen Botzko On Thu, Oct 6, 2011 at 10:57 AM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > On Thu, Oct 6, 2011 at 7:20 AM, Stephen Botzko > wrote: > > In order to get actual-size information with field-of-view in degrees, > you > > need to know the distance from the camera to the first row (which right > now > > is implicit in the mm scale). > > > > This suggests a couple of mathematically equivalent alternatives: > > (a) provide both MM scale and field of view in degrees. If someone > needed > > the distance to the first row, it could be computed. > > (b) provide MM scale and the distance to the first row. In this > > combination, field-of-view in degrees can be computed. > > > > (b) has an advantage in that it can be extended to include multiple rows. > > In a kludgy way (mm means mm, except for the second row, when it > doesn't). I prefer > > (c) Provide the FOV in degrees and a scale factor (standard length). > > Is there any reason why this shouldn't be (possibly) included > for every scene captured, including possibly sub-scene. (In other > words, how do you determine the distance to the second row without > information about that scale factor.) > > I am also specifically interested in including podium type situations, > which are not "rows." > > Regards > Marshall > > > > > > > On Wed, Oct 5, 2011 at 5:15 PM, Duckworth, Mark < > Mark.Duckworth@polycom.com> > > wrote: > >> > >> I can see that degrees might be a useful scale for X and Z in addition > to > >> millimeters. Maybe it should be tenths of a degree, and use integers > (no > >> floating point)? So if we allow that, then we need a way to indicate > the > >> scale of area of capture and point of capture numbers which would be one > of: > >> none, millimeters, degrees. And I think this scale indication applies > to an > >> entire capture set, not individual media captures. Everything in a > >> particular capture set must use the same scale. > >> > >> When we introduced the area of capture concept, and using a millimeter > >> scale, I thought that would eliminate the need for the Video Scale > attribute > >> we had before. I now think we should bring back a separate Video Scale > >> attribute, because the area of capture won't always be enough to tell > the > >> scale in terms of how large to render it to make it seem the appropriate > >> size at the rendering side. One example is an auto-switched video > capture > >> that covers 0 to 99 (area of capture), while at any one time it is only > >> covering a third of it (video scale), so having a separate video scale > >> attribute allows the renderer to scale it accordingly if it wants. Now > I > >> wonder if the scale attribute really should be associated with a video > >> stream in RTP, rather than with a video capture, because maybe it should > be > >> more dynamic than capture set advertisements. > >> > >> Marshall, your definition of left and right makes good sense to me. > >> > >> Mark Duckworth > >> > >> > -----Original Message----- > >> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > >> > Marshall Eubanks > >> > Sent: Wednesday, October 05, 2011 2:44 PM > >> > To: Brian Baldino (bbaldino) > >> > Cc: clue@ietf.org > >> > Subject: Re: [clue] Area of capture attribute > >> > > >> > On Wed, Oct 5, 2011 at 1:42 PM, Brian Baldino (bbaldino) > >> > wrote: > >> > > Hey Roni, > >> > > > >> > > Took my best shot inline. > >> > > > >> > > -Brian > >> > > > >> > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > >> > Of Roni > >> > > Even > >> > > Sent: Tuesday, October 04, 2011 11:03 PM > >> > > To: clue@ietf.org > >> > > Subject: [clue] Area of capture attribute > >> > > > >> > > Hi, > >> > > > >> > > I read the new revision and I think that this attribute is a good > >> > starting > >> > > point to address the discussion on the spatial description. I hope > >> > that we > >> > > will be able to finalize the model in the Interim meeting. > >> > > > >> > > I started a new thread after seeing the comments from Christian and > >> > Mark. > >> > > > >> > > I will send more feedback on the draft in a separate email. > >> > > > >> > > I think that there is some information missing that will be helpful > >> > > > >> > > 1. The position of the origin of the axis and the full range > >> > of the > >> > > area is needed probably as a capture set attribute in order to > >> > understand > >> > > the view. For example having a VC that says (0,33) does not provide > >> > enough > >> > > information to know what part of the room it covers. I do not think > >> > that > >> > > saying that there will be one configuration for example (VC1 (0,33), > >> > > VC2(33,66),VC3(66,99)) is the right way since it requires to have > >> > such > >> > > configuration and it also means that the range is (0,99) while it > may > >> > also > >> > > be covering part of a (-10,110) range. The major requirement is not > >> > to use > >> > > implied information but be explicit. > >> > > > >> > > [BB] I think I agree that this might be useful, but, I'm not sure > >> > we've come > >> > > up with a use case that really demands it yet. Let me see if what I > >> > have in > >> > > mind for what you described (and why the origin and full range up > >> > front > >> > > aren't needed there) makes sense: > >> > > > >> > > I'm not sure what you've described (an advertiser only offering a > >> > single > >> > > video capture VC0(0,33)) would be that common (as, like you said, it > >> > isn't > >> > > very useful) but if it did, I still think the renderer could render > >> > it > >> > > sensibly. Since there are no other captures advertised, the > renderer > >> > does > >> > > not need to be careful about rendering the VC in a certain position > >> > relative > >> > > to other captures from that same device because there are none. In > >> > your > >> > > example: if a 3 camera endpoint only advertised its left camera as > >> > VC0(0,33) > >> > > a 3 screen endpoint on the other end could render it wherever it > >> > wanted > >> > > because its main concern (making sure cameras from a multi-camera > >> > > transmitter are placed correctly relative to one another) is no > >> > longer an > >> > > issue. Perhaps there is a scenario unlike what I've just described > >> > where, > >> > > even though only one small subset of the entire device was > >> > advertised, it > >> > > was important to render it in exactly one place. Do you know of an > >> > example > >> > > where that may be the case? > >> > > > >> > > 2. I think that it is important not only to have the X > >> > coordinates but > >> > > also have the Y coordinates to be able to know if there is a gap or > >> > overlap > >> > > at the relevant distance. Again the origin of the axes is crucial > >> > here. > >> > > > >> > > [BB] The document provides for describing the area of capture in up > >> > to 3 > >> > > dimensions(x, y and z); seems like that gives the flexibility you're > >> > looking > >> > > for? > >> > > > >> > > >> > Ah, I missed that - it's implicit in 5.2.4. (I searched on vertical, > >> > which is nowhere mentioned.) Obviously, this could use some wording > >> > tweaks, which I promised to provide. > >> > > >> > In 5.2.4, I suggest you start with > >> > > >> > The area_of_capture attribute is used to describe the relevant area of > >> > which a media capture is "capturing". > >> > Area of capture is expressed as pairs of {x, y, z} coordinates to > >> > describe {left to right, front to back, low to high} ranges in that > >> > order where, as with point_of_capture, only the necessary dimensions > >> > need be expressed. In other words, it is specified that, as numbers > >> > move from lower to higher, the location is going from: left to right > >> > (in the case of the 'x' dimension), front to back (in the case of the > >> > 'y' dimension or low to high (in the case of the 'z' dimension). > >> > > >> > > >> > In 5.2.6. it says > >> > > >> > Area Scale Millimeters > >> > An optional Boolean variable indicating if the numbers used for area > >> > of capture and point of capture are in terms of millimeters. If this > >> > attribute is true, then the x,y,z numbers represent millimeters. If > >> > this attribute is false, then there is no physical scale. The default > >> > value is false. > >> > > >> > Note that "degrees" are not mentioned anywhere in the document. > >> > Degrees may not be a physical scale, but they are still a scale. (If > >> > you interpret {0,33} as radians or pixels, you are unlikely to get > >> > pleasing results.) There is another issue, as I don't know what the > >> > equivalent to angles are for front to back. > >> > > >> > I would change " If this attribute is false, then there is no physical > >> > scale." to > >> > > >> > " If this attribute is false, then the scale for x and z is degrees, > >> > and the scale for y remains mm." > >> > > >> > If you have another default scale for y, you should specify it (I > >> > can't imagine what it would be.) > >> > > >> > (BTW, I believe that I suggested y being up and down and z being front > >> > to back, precisely because most people will specify x, fewer up-down, > >> > and fewest front back distances. If you do that, you have to switch > >> > the definition of left and right to stage-left and stage-right to keep > >> > a right handed system.) > >> > > >> > In Section 3, it says. > >> > > >> > Left: For media captures, left and right is from the point of view of > >> > a person observing the rendered media. > >> > > >> > This is the opposite of stage-left and stage-right, and would be > >> > called camera-left and camera-right in American TV. > >> > > >> > In other words, "left" and "right" are camera-left and camera-right > >> > in theatrical parlance, and are the opposite of left and right for the > >> > person being observed. > >> > > >> > Actually, I would strongly urge the definition and _explicit_ use of > >> > camera-left and camera-right (or stage-left and stage-right) in EVERY > >> > occurrence of their use. > >> > > >> > If we don't do that, I am willing to bet someone will mess it up. > >> > > >> > So, if you do this, the definition becomes > >> > > >> > Camera-Left: For media captures, camera-left and camera-right is from > >> > the point of view of a person observing the rendered media. They are > >> > the opposite of stage-left and stage-right, which are the left and > >> > right of the person being observed. > >> > > >> > Note also that front and back are not defined. They should be. Up and > >> > down I think can go undefined. > >> > > >> > Front. Front is the portion of the room closest to the cameras. In > >> > going towards back you move away from the cameras. > >> > > >> > > >> > > 3. I am not sure about the example in section 7 for the active > >> > speaker > >> > > (VC3) "VC3- (the loudest panel stream), encoding group:EG1, > >> > > attributes:purpose=main;auto-switched:yes; > area_of_capture={xBegin=0, > >> > > xEnd=99}". How do you know what is the area of capture you are > really > >> > > getting, my understanding is that it is implied that there are > >> > VC0,VC1 and > >> > > VC2 and you get one of them. Again, I prefer explicit information > for > >> > this > >> > > case even if it means having at attribute that will specify that the > >> > switch > >> > > is between VC0, VC1 and VC2 or have it as part of the auto-switch > >> > attribute. > >> > > > >> > > [BB] The idea here is that the transmitter is showing you the most > >> > > appropriate subset of that range. You're right the receiver doesn't > >> > know > >> > > specifically what's being sent, but, why does it care? The receiver > >> > signed > >> > > up for getting the most relevant stream in that range and that's > what > >> > the > >> > > transmitter will send it. What do you think the receiver needs to > >> > know? > >> > > > >> > > >> > To scale the image appropriately. For example, if VC3 is really VC1, > >> > that could maybe be shown > >> > in full. If VC3 is really VC0+VC1+VC3 composited together, it should > >> > be letter boxed. > >> > > >> > I am also nervous about throwing away information when we don't have > >> > to. > >> > > >> > Regards > >> > Marshall > >> > > >> > > Regards > >> > > Roni > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > > --20cf3071cc5c40ba9604aea2b6ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
(c) Provide the FOV in degrees and a scale factor (standard length).
>= ;>>
Not sure how that is different from (a); it seems the same to = me.=A0 Maybe we can discuss next week

Stephen Botzko

On Thu, Oct 6, 2011 at 10:57 AM, Marshall Eubanks <marshall.eubanks@gmail.com&g= t; wrote:
On Thu, Oct 6, 2011 at 7:20 AM, Stephen Botzko <stephen.botzko@gmail.com> wrot= e:
> In order to get actual-size information with f= ield-of-view in degrees, you
> need to know the distance from the camera to the first row (which righ= t now
> is implicit in the mm scale).
>
> This suggests a couple of mathematically equivalent alternatives:
> (a) provide both MM scale and field of view in degrees.=A0 If someone = needed
> the distance to the first row, it could be computed.
> (b) provide MM scale and the distance to the first row.=A0 In this
> combination, field-of-view in degrees can be computed.
>
> (b) has an advantage in that it can be extended to include multiple ro= ws.

In a kludgy way (mm means mm, except for the second row, when it
doesn't). I prefer

(c) Provide the FOV in degrees and a scale factor (standard length).

Is there any reason why this shouldn't be (possibly) included
for every scene captured, including possibly sub-scene. (In other
words, how do you determine the distance to the second row without
information about that scale factor.)

I am also specifically interested in including podium type situations,
which are not "rows."

Regards
Marshall



>
> On Wed, Oct 5, 2011 at 5:15 PM, Duckworth, Mark <Mark.Duckworth@polycom.com>
> wrote:
>>
>> I can see that degrees might be a useful scale for X and Z in addi= tion to
>> millimeters. =A0Maybe it should be tenths of a degree, and use int= egers (no
>> floating point)? =A0So if we allow that, then we need a way to ind= icate the
>> scale of area of capture and point of capture numbers which would = be one of:
>> none, millimeters, degrees. =A0And I think this scale indication a= pplies to an
>> entire capture set, not individual media captures. =A0Everything i= n a
>> particular capture set must use the same scale.
>>
>> When we introduced the area of capture concept, and using a millim= eter
>> scale, I thought that would eliminate the need for the Video Scale= attribute
>> we had before. =A0I now think we should bring back a separate Vide= o Scale
>> attribute, because the area of capture won't always be enough = to tell the
>> scale in terms of how large to render it to make it seem the appro= priate
>> size at the rendering side. =A0One example is an auto-switched vid= eo capture
>> that covers 0 to 99 (area of capture), while at any one time it is= only
>> covering a third of it (video scale), so having a separate video s= cale
>> attribute allows the renderer to scale it accordingly if it wants.= =A0Now I
>> wonder if the scale attribute really should be associated with a v= ideo
>> stream in RTP, rather than with a video capture, because maybe it = should be
>> more dynamic than capture set advertisements.
>>
>> Marshall, your definition of left and right makes good sense to me= .
>>
>> Mark Duckworth
>>
>> > -----Original Message-----
>> > From: clue-bounces@i= etf.org [mailto:clue-bounces@i= etf.org] On Behalf Of
>> > Marshall Eubanks
>> > Sent: Wednesday, October 05, 2011 2:44 PM
>> > To: Brian Baldino (bbaldino)
>> > Cc: clue@ietf.org
>> > Subject: Re: [clue] Area of capture attribute
>> >
>> > On Wed, Oct 5, 2011 at 1:42 PM, Brian Baldino (bbaldino)
>> > <bbaldino@cisco.com<= /a>> wrote:
>> > > Hey Roni,
>> > >
>> > > Took my best shot inline.
>> > >
>> > > -Brian
>> > >
>> > > From: clue-boun= ces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf
>> > Of Roni
>> > > Even
>> > > Sent: Tuesday, October 04, 2011 11:03 PM
>> > > To: clue@ietf.org >> > > Subject: [clue] Area of capture attribute
>> > >
>> > > Hi,
>> > >
>> > > I read the new revision and I think that this attribute = is a good
>> > starting
>> > > point to address the discussion on the spatial descripti= on. I hope
>> > that we
>> > > will be able to finalize the model in the Interim meetin= g.
>> > >
>> > > I started a new thread after seeing the comments from Ch= ristian and
>> > Mark.
>> > >
>> > > I will send more feedback on the draft in a separate ema= il.
>> > >
>> > > I think that there is some information missing that will= be helpful
>> > >
>> > > 1.=A0=A0=A0=A0=A0=A0 The position of the origin of the a= xis =A0and the full range
>> > of the
>> > > area is needed probably as a capture set attribute in or= der to
>> > understand
>> > > the view. For example having a VC that says (0,33) does = not provide
>> > enough
>> > > information to know what part of the room it covers. I d= o not think
>> > that
>> > > saying that there will be one configuration for example = (VC1 (0,33),
>> > > VC2(33,66),VC3(66,99)) is the right way since it require= s to have
>> > such
>> > > configuration and it also means that the range is (0,99)= while it may
>> > also
>> > > be covering part of a (-10,110) range. The major require= ment is not
>> > to use
>> > > implied information but be explicit.
>> > >
>> > > [BB] I think I agree that this might be useful, but, I&#= 39;m not sure
>> > we've come
>> > > up with a use case that really demands it yet.=A0 Let me= see if what I
>> > have in
>> > > mind for what you described (and why the origin and full= range up
>> > front
>> > > aren't needed there) makes sense:
>> > >
>> > > I'm not sure what you've described (an advertise= r only offering a
>> > single
>> > > video capture VC0(0,33)) would be that common (as, like = you said, it
>> > isn't
>> > > very useful) but if it did, I still think the renderer c= ould render
>> > it
>> > > sensibly.=A0 Since there are no other captures advertise= d, the renderer
>> > does
>> > > not need to be careful about rendering the VC in a certa= in position
>> > relative
>> > > to other captures from that same device because there ar= e none.=A0 In
>> > your
>> > > example: if a 3 camera endpoint only advertised its left= camera as
>> > VC0(0,33)
>> > > a 3 screen endpoint on the other end could render it whe= rever it
>> > wanted
>> > > because its main concern (making sure cameras from a mul= ti-camera
>> > > transmitter are placed correctly relative to one another= ) is no
>> > longer an
>> > > issue.=A0 Perhaps there is a scenario unlike what I'= ve just described
>> > where,
>> > > even though only one small subset of the entire device w= as
>> > advertised, it
>> > > was important to render it in exactly one place.=A0 Do y= ou know of an
>> > example
>> > > where that may be the case?
>> > >
>> > > 2.=A0=A0=A0=A0=A0=A0 I think that it is important not on= ly to have the X
>> > coordinates but
>> > > also have the Y coordinates to be able to know if there = is a gap or
>> > overlap
>> > > at the relevant distance. Again the origin of the axes i= s crucial
>> > here.
>> > >
>> > > [BB] The document provides for describing the area of ca= pture in up
>> > to 3
>> > > dimensions(x, y and z); seems like that gives the flexib= ility you're
>> > looking
>> > > for?
>> > >
>> >
>> > Ah, I missed that - it's implicit in 5.2.4. (I searched o= n vertical,
>> > which is nowhere mentioned.) Obviously, this could use some w= ording
>> > tweaks, which I promised to provide.
>> >
>> > In 5.2.4, I suggest you start with
>> >
>> > The area_of_capture attribute is used to describe the relevan= t area of
>> > which a media capture is "capturing".
>> > Area of capture is expressed as pairs of =A0{x, y, z} coordin= ates to
>> > describe {left to right, front to back, low to high} ranges i= n that
>> > order where, as with point_of_capture, only the necessary dim= ensions
>> > need be expressed. In other words, it is specified that, as n= umbers
>> > move from lower to higher, the location is going from: left t= o right
>> > (in the case of the 'x' dimension), front to back (in= the case of the
>> > 'y' dimension or low to high (in the case of the '= ;z' dimension).
>> >
>> >
>> > =A0In 5.2.6. it says
>> >
>> > =A0Area Scale Millimeters
>> > An optional Boolean variable indicating if the numbers used f= or area
>> > of capture and point of capture are in terms of millimeters. = If this
>> > attribute is true, then the x,y,z numbers represent millimete= rs. If
>> > this attribute is false, then there is no physical scale. The= default
>> > value is false.
>> >
>> > Note that "degrees" are not mentioned anywhere in t= he document.
>> > Degrees may not be a physical scale, but they are still a sca= le. (If
>> > you interpret {0,33} as radians or pixels, you are unlikely t= o get
>> > pleasing results.) There is another issue, as I don't kno= w what the
>> > equivalent to angles are for front to back.
>> >
>> > I would change " If this attribute is false, then there = is no physical
>> > scale." =A0to
>> >
>> > =A0" If this attribute is false, then the =A0scale for x= and z is degrees,
>> > and the scale for y remains mm."
>> >
>> > If you have another default scale for y, you should specify i= t (I
>> > can't imagine what it would be.)
>> >
>> > (BTW, I believe that I suggested y being up and down and z be= ing front
>> > to back, precisely because most people will specify x, fewer = up-down,
>> > and fewest front back distances. If you do that, you have to = switch
>> > the definition of left and right to stage-left and stage-righ= t to keep
>> > a right handed system.)
>> >
>> > In Section 3, it says.
>> >
>> > Left: For media captures, left and right is from the point of= view of
>> > a person observing the rendered media.
>> >
>> > This is the opposite of stage-left and stage-right, and would= be
>> > called camera-left =A0and camera-right in American TV.
>> >
>> > In other words, "left" and "right" are ca= mera-left =A0and camera-right
>> > in theatrical parlance, and are the opposite of left and righ= t for the
>> > person being observed.
>> >
>> > Actually, I would strongly urge the =A0definition and _explic= it_ use of
>> > camera-left and camera-right (or stage-left and stage-right) = =A0in EVERY
>> > occurrence of their use.
>> >
>> > If we don't do that, I am willing to bet someone will mes= s it up.
>> >
>> > So, if you do this, the definition becomes
>> >
>> > Camera-Left: For media captures, camera-left and camera-right= is from
>> > the point of view of a person observing the rendered media. T= hey are
>> > the opposite of stage-left and stage-right, which are the lef= t and
>> > right of the person being observed.
>> >
>> > Note also that front and back are not defined. They should be= . Up and
>> > down I think can go undefined.
>> >
>> > Front. Front is the portion of the room closest to the camera= s. In
>> > going towards back you move away from the cameras.
>> >
>> >
>> > > 3.=A0=A0=A0=A0=A0=A0 I am not sure about the example in = section 7 for the active
>> > speaker
>> > > (VC3) "VC3- (the loudest panel stream), encoding gr= oup:EG1,
>> > > attributes:purpose=3Dmain;auto-switched:yes; area_of_cap= ture=3D{xBegin=3D0,
>> > > xEnd=3D99}". How do you know what is the area of ca= pture you are really
>> > > getting, my understanding is that it is =A0implied that = there are
>> > VC0,VC1 and
>> > > VC2 and you get one of them. Again, I prefer explicit in= formation for
>> > this
>> > > case even if it means having at attribute that will spec= ify that the
>> > switch
>> > > is between VC0, VC1 and VC2 or have it as part of the au= to-switch
>> > attribute.
>> > >
>> > > [BB] The idea here is that the transmitter is showing yo= u the most
>> > > appropriate subset of that range.=A0 You're right th= e receiver doesn't
>> > know
>> > > specifically what's being sent, but, why does it car= e?=A0 The receiver
>> > signed
>> > > up for getting the most relevant stream in that range an= d that's what
>> > the
>> > > transmitter will send it.=A0 What do you think the recei= ver needs to
>> > know?
>> > >
>> >
>> > To scale the image appropriately. For example, if VC3 is real= ly VC1,
>> > that could maybe be shown
>> > in full. If VC3 is really VC0+VC1+VC3 composited together, it= should
>> > be letter boxed.
>> >
>> > I am also nervous about throwing away information when we don= 't have
>> > to.
>> >
>> > Regards
>> > Marshall
>> >
>> > > Regards
>> > > Roni
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>
>

--20cf3071cc5c40ba9604aea2b6ff-- From marshall.eubanks@gmail.com Thu Oct 6 08:21:00 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6573521F8E1D for ; Thu, 6 Oct 2011 08:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.974 X-Spam-Level: X-Spam-Status: No, score=-103.974 tagged_above=-999 required=5 tests=[AWL=1.025, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGr-kZTEhGBO for ; Thu, 6 Oct 2011 08:20:59 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 163E621F8E12 for ; Thu, 6 Oct 2011 08:20:58 -0700 (PDT) Received: by yxt33 with SMTP id 33so3312218yxt.31 for ; Thu, 06 Oct 2011 08:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BYuMW7HSNcFoXFQ8Wd4tYkfUtxTmjoI+ptZn7HpHj9w=; b=NqHdBhK6uqO7sfbyBv0HdMrEAT7Dhw6bXQEOZSHN0gbJd3+dmCbqETjLklQSEbzaR8 1JjIubXeV1kxSJ5WEX6F81+i58OqNCmZn+xbt139iksni9Bymp1AX49w+6gWO5wqssDK 2IOhH3Bt1Tjvp37C+HttzNIsiaqdp4UbGofkg= MIME-Version: 1.0 Received: by 10.150.163.5 with SMTP id l5mr676582ybe.83.1317914648723; Thu, 06 Oct 2011 08:24:08 -0700 (PDT) Received: by 10.151.98.20 with HTTP; Thu, 6 Oct 2011 08:24:08 -0700 (PDT) In-Reply-To: References: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61CDF41693@CRPMBOXPRD01.polycom.com> Date: Thu, 6 Oct 2011 11:24:08 -0400 Message-ID: From: Marshall Eubanks To: Stephen Botzko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "clue@ietf.org" Subject: Re: [clue] Area of capture attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 15:21:00 -0000 On Thu, Oct 6, 2011 at 11:09 AM, Stephen Botzko wrote: >>>> > (c) Provide the FOV in degrees and a scale factor (standard length). >>>> > Not sure how that is different from (a); it seems the same to me.=A0 Mayb= e we > can discuss next week > a) provide both MM scale and field of view in degrees. I interpreted this as something like area_of_capture for Camera 1 is (0, 33 degrees) OR (0, 245 mm) I am proposing something like FOV for Camera 1 is area_of_capture=3D{xBegin=3D0, xEnd=3D33} point_of_interest=3D(ypoint=3D"425" , type=3D"Row 1") If this is done I would suggest certain specific default "types" - "Row {i}", "Podium {i}", etc. If area of capture is defined in angular units, then point_of_interest can always be in mm. Regards Marshall P.S. In preparing this email I noticed that the point_of_capture _format_ seems to be defined nowhere. I would suggest point_of_capture=3D(xpoint=3D"15") as a suitable format. > Stephen Botzko > > On Thu, Oct 6, 2011 at 10:57 AM, Marshall Eubanks > wrote: >> >> On Thu, Oct 6, 2011 at 7:20 AM, Stephen Botzko >> wrote: >> > In order to get actual-size information with field-of-view in degrees, >> > you >> > need to know the distance from the camera to the first row (which righ= t >> > now >> > is implicit in the mm scale). >> > >> > This suggests a couple of mathematically equivalent alternatives: >> > (a) provide both MM scale and field of view in degrees.=A0 If someone >> > needed >> > the distance to the first row, it could be computed. >> > (b) provide MM scale and the distance to the first row.=A0 In this >> > combination, field-of-view in degrees can be computed. >> > >> > (b) has an advantage in that it can be extended to include multiple >> > rows. >> >> In a kludgy way (mm means mm, except for the second row, when it >> doesn't). I prefer >> >> (c) Provide the FOV in degrees and a scale factor (standard length). >> >> Is there any reason why this shouldn't be (possibly) included >> for every scene captured, including possibly sub-scene. (In other >> words, how do you determine the distance to the second row without >> information about that scale factor.) >> >> I am also specifically interested in including podium type situations, >> which are not "rows." >> >> Regards >> Marshall >> >> >> >> > >> > On Wed, Oct 5, 2011 at 5:15 PM, Duckworth, Mark >> > >> > wrote: >> >> >> >> I can see that degrees might be a useful scale for X and Z in additio= n >> >> to >> >> millimeters. =A0Maybe it should be tenths of a degree, and use intege= rs >> >> (no >> >> floating point)? =A0So if we allow that, then we need a way to indica= te >> >> the >> >> scale of area of capture and point of capture numbers which would be >> >> one of: >> >> none, millimeters, degrees. =A0And I think this scale indication appl= ies >> >> to an >> >> entire capture set, not individual media captures. =A0Everything in a >> >> particular capture set must use the same scale. >> >> >> >> When we introduced the area of capture concept, and using a millimete= r >> >> scale, I thought that would eliminate the need for the Video Scale >> >> attribute >> >> we had before. =A0I now think we should bring back a separate Video S= cale >> >> attribute, because the area of capture won't always be enough to tell >> >> the >> >> scale in terms of how large to render it to make it seem the >> >> appropriate >> >> size at the rendering side. =A0One example is an auto-switched video >> >> capture >> >> that covers 0 to 99 (area of capture), while at any one time it is on= ly >> >> covering a third of it (video scale), so having a separate video scal= e >> >> attribute allows the renderer to scale it accordingly if it wants. = =A0Now >> >> I >> >> wonder if the scale attribute really should be associated with a vide= o >> >> stream in RTP, rather than with a video capture, because maybe it >> >> should be >> >> more dynamic than capture set advertisements. >> >> >> >> Marshall, your definition of left and right makes good sense to me. >> >> >> >> Mark Duckworth >> >> >> >> > -----Original Message----- >> >> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behal= f >> >> > Of >> >> > Marshall Eubanks >> >> > Sent: Wednesday, October 05, 2011 2:44 PM >> >> > To: Brian Baldino (bbaldino) >> >> > Cc: clue@ietf.org >> >> > Subject: Re: [clue] Area of capture attribute >> >> > >> >> > On Wed, Oct 5, 2011 at 1:42 PM, Brian Baldino (bbaldino) >> >> > wrote: >> >> > > Hey Roni, >> >> > > >> >> > > Took my best shot inline. >> >> > > >> >> > > -Brian >> >> > > >> >> > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> >> > > Behalf >> >> > Of Roni >> >> > > Even >> >> > > Sent: Tuesday, October 04, 2011 11:03 PM >> >> > > To: clue@ietf.org >> >> > > Subject: [clue] Area of capture attribute >> >> > > >> >> > > Hi, >> >> > > >> >> > > I read the new revision and I think that this attribute is a good >> >> > starting >> >> > > point to address the discussion on the spatial description. I hop= e >> >> > that we >> >> > > will be able to finalize the model in the Interim meeting. >> >> > > >> >> > > I started a new thread after seeing the comments from Christian a= nd >> >> > Mark. >> >> > > >> >> > > I will send more feedback on the draft in a separate email. >> >> > > >> >> > > I think that there is some information missing that will be helpf= ul >> >> > > >> >> > > 1.=A0=A0=A0=A0=A0=A0 The position of the origin of the axis =A0an= d the full range >> >> > of the >> >> > > area is needed probably as a capture set attribute in order to >> >> > understand >> >> > > the view. For example having a VC that says (0,33) does not provi= de >> >> > enough >> >> > > information to know what part of the room it covers. I do not thi= nk >> >> > that >> >> > > saying that there will be one configuration for example (VC1 >> >> > > (0,33), >> >> > > VC2(33,66),VC3(66,99)) is the right way since it requires to have >> >> > such >> >> > > configuration and it also means that the range is (0,99) while it >> >> > > may >> >> > also >> >> > > be covering part of a (-10,110) range. The major requirement is n= ot >> >> > to use >> >> > > implied information but be explicit. >> >> > > >> >> > > [BB] I think I agree that this might be useful, but, I'm not sure >> >> > we've come >> >> > > up with a use case that really demands it yet.=A0 Let me see if w= hat >> >> > > I >> >> > have in >> >> > > mind for what you described (and why the origin and full range up >> >> > front >> >> > > aren't needed there) makes sense: >> >> > > >> >> > > I'm not sure what you've described (an advertiser only offering a >> >> > single >> >> > > video capture VC0(0,33)) would be that common (as, like you said, >> >> > > it >> >> > isn't >> >> > > very useful) but if it did, I still think the renderer could rend= er >> >> > it >> >> > > sensibly.=A0 Since there are no other captures advertised, the >> >> > > renderer >> >> > does >> >> > > not need to be careful about rendering the VC in a certain positi= on >> >> > relative >> >> > > to other captures from that same device because there are none.= =A0 In >> >> > your >> >> > > example: if a 3 camera endpoint only advertised its left camera a= s >> >> > VC0(0,33) >> >> > > a 3 screen endpoint on the other end could render it wherever it >> >> > wanted >> >> > > because its main concern (making sure cameras from a multi-camera >> >> > > transmitter are placed correctly relative to one another) is no >> >> > longer an >> >> > > issue.=A0 Perhaps there is a scenario unlike what I've just descr= ibed >> >> > where, >> >> > > even though only one small subset of the entire device was >> >> > advertised, it >> >> > > was important to render it in exactly one place.=A0 Do you know o= f an >> >> > example >> >> > > where that may be the case? >> >> > > >> >> > > 2.=A0=A0=A0=A0=A0=A0 I think that it is important not only to hav= e the X >> >> > coordinates but >> >> > > also have the Y coordinates to be able to know if there is a gap = or >> >> > overlap >> >> > > at the relevant distance. Again the origin of the axes is crucial >> >> > here. >> >> > > >> >> > > [BB] The document provides for describing the area of capture in = up >> >> > to 3 >> >> > > dimensions(x, y and z); seems like that gives the flexibility >> >> > > you're >> >> > looking >> >> > > for? >> >> > > >> >> > >> >> > Ah, I missed that - it's implicit in 5.2.4. (I searched on vertical= , >> >> > which is nowhere mentioned.) Obviously, this could use some wording >> >> > tweaks, which I promised to provide. >> >> > >> >> > In 5.2.4, I suggest you start with >> >> > >> >> > The area_of_capture attribute is used to describe the relevant area >> >> > of >> >> > which a media capture is "capturing". >> >> > Area of capture is expressed as pairs of =A0{x, y, z} coordinates t= o >> >> > describe {left to right, front to back, low to high} ranges in that >> >> > order where, as with point_of_capture, only the necessary dimension= s >> >> > need be expressed. In other words, it is specified that, as numbers >> >> > move from lower to higher, the location is going from: left to righ= t >> >> > (in the case of the 'x' dimension), front to back (in the case of t= he >> >> > 'y' dimension or low to high (in the case of the 'z' dimension). >> >> > >> >> > >> >> > =A0In 5.2.6. it says >> >> > >> >> > =A0Area Scale Millimeters >> >> > An optional Boolean variable indicating if the numbers used for are= a >> >> > of capture and point of capture are in terms of millimeters. If thi= s >> >> > attribute is true, then the x,y,z numbers represent millimeters. If >> >> > this attribute is false, then there is no physical scale. The defau= lt >> >> > value is false. >> >> > >> >> > Note that "degrees" are not mentioned anywhere in the document. >> >> > Degrees may not be a physical scale, but they are still a scale. (I= f >> >> > you interpret {0,33} as radians or pixels, you are unlikely to get >> >> > pleasing results.) There is another issue, as I don't know what the >> >> > equivalent to angles are for front to back. >> >> > >> >> > I would change " If this attribute is false, then there is no >> >> > physical >> >> > scale." =A0to >> >> > >> >> > =A0" If this attribute is false, then the =A0scale for x and z is >> >> > degrees, >> >> > and the scale for y remains mm." >> >> > >> >> > If you have another default scale for y, you should specify it (I >> >> > can't imagine what it would be.) >> >> > >> >> > (BTW, I believe that I suggested y being up and down and z being >> >> > front >> >> > to back, precisely because most people will specify x, fewer up-dow= n, >> >> > and fewest front back distances. If you do that, you have to switch >> >> > the definition of left and right to stage-left and stage-right to >> >> > keep >> >> > a right handed system.) >> >> > >> >> > In Section 3, it says. >> >> > >> >> > Left: For media captures, left and right is from the point of view = of >> >> > a person observing the rendered media. >> >> > >> >> > This is the opposite of stage-left and stage-right, and would be >> >> > called camera-left =A0and camera-right in American TV. >> >> > >> >> > In other words, "left" and "right" are camera-left =A0and camera-ri= ght >> >> > in theatrical parlance, and are the opposite of left and right for >> >> > the >> >> > person being observed. >> >> > >> >> > Actually, I would strongly urge the =A0definition and _explicit_ us= e of >> >> > camera-left and camera-right (or stage-left and stage-right) =A0in >> >> > EVERY >> >> > occurrence of their use. >> >> > >> >> > If we don't do that, I am willing to bet someone will mess it up. >> >> > >> >> > So, if you do this, the definition becomes >> >> > >> >> > Camera-Left: For media captures, camera-left and camera-right is fr= om >> >> > the point of view of a person observing the rendered media. They ar= e >> >> > the opposite of stage-left and stage-right, which are the left and >> >> > right of the person being observed. >> >> > >> >> > Note also that front and back are not defined. They should be. Up a= nd >> >> > down I think can go undefined. >> >> > >> >> > Front. Front is the portion of the room closest to the cameras. In >> >> > going towards back you move away from the cameras. >> >> > >> >> > >> >> > > 3.=A0=A0=A0=A0=A0=A0 I am not sure about the example in section 7= for the >> >> > > active >> >> > speaker >> >> > > (VC3) "VC3- (the loudest panel stream), encoding group:EG1, >> >> > > attributes:purpose=3Dmain;auto-switched:yes; >> >> > > area_of_capture=3D{xBegin=3D0, >> >> > > xEnd=3D99}". How do you know what is the area of capture you are >> >> > > really >> >> > > getting, my understanding is that it is =A0implied that there are >> >> > VC0,VC1 and >> >> > > VC2 and you get one of them. Again, I prefer explicit information >> >> > > for >> >> > this >> >> > > case even if it means having at attribute that will specify that >> >> > > the >> >> > switch >> >> > > is between VC0, VC1 and VC2 or have it as part of the auto-switch >> >> > attribute. >> >> > > >> >> > > [BB] The idea here is that the transmitter is showing you the mos= t >> >> > > appropriate subset of that range.=A0 You're right the receiver >> >> > > doesn't >> >> > know >> >> > > specifically what's being sent, but, why does it care?=A0 The >> >> > > receiver >> >> > signed >> >> > > up for getting the most relevant stream in that range and that's >> >> > > what >> >> > the >> >> > > transmitter will send it.=A0 What do you think the receiver needs= to >> >> > know? >> >> > > >> >> > >> >> > To scale the image appropriately. For example, if VC3 is really VC1= , >> >> > that could maybe be shown >> >> > in full. If VC3 is really VC0+VC1+VC3 composited together, it shoul= d >> >> > be letter boxed. >> >> > >> >> > I am also nervous about throwing away information when we don't hav= e >> >> > to. >> >> > >> >> > Regards >> >> > Marshall >> >> > >> >> > > Regards >> >> > > Roni >> >> _______________________________________________ >> >> clue mailing list >> >> clue@ietf.org >> >> https://www.ietf.org/mailman/listinfo/clue >> > >> > >> > _______________________________________________ >> > clue mailing list >> > clue@ietf.org >> > https://www.ietf.org/mailman/listinfo/clue >> > >> > > > From pkyzivat@alum.mit.edu Thu Oct 6 09:13:16 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AFA21F8CCF for ; Thu, 6 Oct 2011 09:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe7+Vhg0c9Sx for ; Thu, 6 Oct 2011 09:13:16 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id D748321F8CF1 for ; Thu, 6 Oct 2011 09:13:15 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta15.westchester.pa.mail.comcast.net with comcast id hPGV1h0051YDfWL5FUGTWy; Thu, 06 Oct 2011 16:16:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta20.westchester.pa.mail.comcast.net with comcast id hUGS1h0100tdiYw3gUGSru; Thu, 06 Oct 2011 16:16:27 +0000 Message-ID: <4E8DD45D.8020002@alum.mit.edu> Date: Thu, 06 Oct 2011 12:16:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Area of capture attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 16:13:16 -0000 (As individual) Comment on one point. I've trimmed out the rest of the discussion. On 10/5/11 1:42 PM, Brian Baldino (bbaldino) wrote: > Hey Roni, > > Took my best shot inline. > > -Brian > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Roni Even > *Sent:* Tuesday, October 04, 2011 11:03 PM > *To:* clue@ietf.org > *Subject:* [clue] Area of capture attribute > > Hi, > > I read the new revision and I think that this attribute is a good > starting point to address the discussion on the spatial description. I > hope that we will be able to finalize the model in the Interim meeting. > > I started a new thread after seeing the comments from Christian and Mark. > > I will send more feedback on the draft in a separate email. > > I think that there is some information missing that will be helpful > > 1.The position of the origin of the axis and the full range of the area > is needed probably as a capture set attribute in order to understand the > view. For example having a VC that says (0,33) does not provide enough > information to know what part of the room it covers. I do not think that > saying that there will be one configuration for example (VC1 (0,33), > VC2(33,66),VC3(66,99)) is the right way since it requires to have such > configuration and it also means that the range is (0,99) while it may > also be covering part of a (-10,110) range. The major requirement is not > to use implied information but be explicit. > > */[BB] I think I agree that this might be useful, but, I’m not sure > we’ve come up with a use case that really demands it yet. Let me see if > what I have in mind for what you described (and why the origin and full > range up front aren’t needed there) makes sense:/* > > */I’m not sure what you’ve described (an advertiser only offering a > single video capture VC0(0,33)) would be that common (as, like you said, > it isn’t very useful) but if it did, I still think the renderer could > render it sensibly. Since there are no other captures advertised, the > renderer does not need to be careful about rendering the VC in a certain > position relative to other captures from that same device because there > are none. In your example: if a 3 camera endpoint only advertised its > left camera as VC0(0,33) a 3 screen endpoint on the other end could > render it wherever it wanted because its main concern (making sure > cameras from a multi-camera transmitter are placed correctly relative to > one another) is no longer an issue. Perhaps there is a scenario unlike > what I’ve just described where, even though only one small subset of the > entire device was advertised, it was important to render it in exactly > one place. Do you know of an example where that may be the case?/* Suppose someone is alone in a three-screen, three-capture room. He has turned off the cameras other than the one showing him. Depending on where he is sitting, it might be (0,33), (33,66), or (66,99). If the receiving room also has three screens, it might chose to display this on any of its screens - perhaps by default the center one. Later some other people come into the first room and the other cameras are turned on. This could result in the receiving room having to change the screen on which the first person is displayed. That could be a little annoying. That wouldn't happen if the "proper" screen had been used in the first place. Thanks, Paul From bbaldino@cisco.com Thu Oct 6 09:50:23 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965B111E807F for ; Thu, 6 Oct 2011 09:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_101=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUvRKeTfSt7y for ; Thu, 6 Oct 2011 09:50:19 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BABAE21F8D0B for ; Thu, 6 Oct 2011 09:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bbaldino@cisco.com; l=26786; q=dns/txt; s=iport; t=1317920011; x=1319129611; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=XJVk3hKvQ+gpulksOM8OXJATlSmQWO4p/OkS/BBdDdw=; b=dgfEn+d2LiCGbfBuCDHbAUdrmhhUn47JZopmDC1QCL7Bsy+wHnb6T41u e3d4MJYPWc4piKCr+TxBIgH7AnDCuDlTrL2cPIf/CgHYxhKxYWkagS7gB +8pqsWIMl+sxZD/kUwvmN3TmGbQwfqywzB4UhwW0n4DvTzfNd4tu0x9w3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIAAJrcjU6rRDoH/2dsb2JhbABDgk2WSo8cgQWBUwEBAQQSAQkRA1kCAQgRBAEBCwYQBwEGAUUJCAEBBAESCBqiSgGeIIZLYQSHfZEijDU X-IronPort-AV: E=Sophos;i="4.68,497,1312156800"; d="scan'208,217";a="6317318" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 06 Oct 2011 16:53:30 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p96GrScG004184; Thu, 6 Oct 2011 16:53:28 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Oct 2011 09:53:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: AlfJ BYnK Cp6t ExFl F3O8 Gg3A H9oX Jw2t J6AN LYvx Mmob NrEA PWlz SYgH TanR TzKh; 2; YwBsAHUAZQBAAGkAZQB0AGYALgBvAHIAZwA7AGUAdgBlAG4ALgByAG8AbgBpAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Sosha1_v1; 7; {260BC3FE-1078-43FB-8CDD-A0B8B481C9F7}; YgBiAGEAbABkAGkAbgBvAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Thu, 06 Oct 2011 16:53:23 GMT; UgBFADoAIABbAGMAbAB1AGUAXQAgAEEAcgBlAGEAIABvAGYAIABjAGEAcAB0AHUAcgBlACAAYQB0AHQAcgBpAGIAdQB0AGUA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8448.784D2151" x-cr-puzzleid: {260BC3FE-1078-43FB-8CDD-A0B8B481C9F7} Content-class: urn:content-classes:message Date: Thu, 6 Oct 2011 09:53:23 -0700 Message-ID: In-Reply-To: <054401cc83a4$dfa6d670$9ef48350$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Area of capture attribute thread-index: AcyDJHXTd/dmWtWGTle0G/txbwllmwAWem4gAAinSdAAKb5WMA== References: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> <054401cc83a4$dfa6d670$9ef48350$%roni@huawei.com> From: "Brian Baldino (bbaldino)" To: "Roni Even" , X-OriginalArrivalTime: 06 Oct 2011 16:53:28.0234 (UTC) FILETIME=[789368A0:01CC8448] Subject: Re: [clue] Area of capture attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 16:50:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8448.784D2151 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey Roni, inline again. =20 From: Roni Even [mailto:Even.roni@huawei.com]=20 Sent: Wednesday, October 05, 2011 2:22 PM To: Brian Baldino (bbaldino); clue@ietf.org Subject: RE: [clue] Area of capture attribute =20 Brian, Inline Roni From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com]=20 Sent: Wednesday, October 05, 2011 7:43 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Area of capture attribute =20 Hey Roni, Took my best shot inline. -Brian =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Tuesday, October 04, 2011 11:03 PM To: clue@ietf.org Subject: [clue] Area of capture attribute =20 Hi, I read the new revision and I think that this attribute is a good starting point to address the discussion on the spatial description. I hope that we will be able to finalize the model in the Interim meeting. =20 I started a new thread after seeing the comments from Christian and Mark. I will send more feedback on the draft in a separate email. =20 I think that there is some information missing that will be helpful =20 1. The position of the origin of the axis and the full range of the area is needed probably as a capture set attribute in order to understand the view. For example having a VC that says (0,33) does not provide enough information to know what part of the room it covers. I do not think that saying that there will be one configuration for example (VC1 (0,33), VC2(33,66),VC3(66,99)) is the right way since it requires to have such configuration and it also means that the range is (0,99) while it may also be covering part of a (-10,110) range. The major requirement is not to use implied information but be explicit. [BB] I think I agree that this might be useful, but, I'm not sure we've come up with a use case that really demands it yet. Let me see if what I have in mind for what you described (and why the origin and full range up front aren't needed there) makes sense: I'm not sure what you've described (an advertiser only offering a single video capture VC0(0,33)) would be that common (as, like you said, it isn't very useful) but if it did, I still think the renderer could render it sensibly. Since there are no other captures advertised, the renderer does not need to be careful about rendering the VC in a certain position relative to other captures from that same device because there are none. In your example: if a 3 camera endpoint only advertised its left camera as VC0(0,33) a 3 screen endpoint on the other end could render it wherever it wanted because its main concern (making sure cameras from a multi-camera transmitter are placed correctly relative to one another) is no longer an issue. Perhaps there is a scenario unlike what I've just described where, even though only one small subset of the entire device was advertised, it was important to render it in exactly one place. Do you know of an example where that may be the case? =20 =20 [Roni] I hope you followed the discussion on the list about gaps between captures. This is a use case where you need the origin and the X,Y coordinates. I think that also the multiview use case will need it. It will not be needed if there is a hidden assumption that the area describes the range at the line where the first row of people is at. Some systems may decide that this measure is at the back of the room. You claim that by having all the different video captures I can learn the range of the room and I say why learn it from all the specified captures provide it separately. I am not sure why you are trying to optimize the provided information. [BB] I'm not saying we can't provide the entire range of the room up front, maybe there's a good reason for it. I still haven't heard why the origin is necessary though to determine the gap between captures?=20 =20 =20 2. I think that it is important not only to have the X coordinates but also have the Y coordinates to be able to know if there is a gap or overlap at the relevant distance. Again the origin of the axes is crucial here. [BB] The document provides for describing the area of capture in up to 3 dimensions(x, y and z); seems like that gives the flexibility you're looking for? =20 [Roni] My claim is that you must provide at least X and Y [BB] If my producer only has captures which vary in 1 dimension, why must I provide the Y coordinate? =20 3. I am not sure about the example in section 7 for the active speaker (VC3) "VC3- (the loudest panel stream), encoding group:EG1, attributes:purpose=3Dmain;auto-switched:yes; = area_of_capture=3D{xBegin=3D0, xEnd=3D99}". How do you know what is the area of capture you are really getting, my understanding is that it is implied that there are VC0,VC1 and VC2 and you get one of them. Again, I prefer explicit information for this case even if it means having at attribute that will specify that the switch is between VC0, VC1 and VC2 or have it as part of the auto-switch attribute. [BB] The idea here is that the transmitter is showing you the most appropriate subset of that range. You're right the receiver doesn't know specifically what's being sent, but, why does it care? The receiver signed up for getting the most relevant stream in that range and that's what the transmitter will send it. What do you think the receiver needs to know?=20 [Roni} you want to know in order to choose between VC3, VC4, VC5 which offer similar proposal. The consumer will need to select the most relevant stream, for VC3 note that for auto-switch according to 5.2.8 "In this case the offered AC or VC varies depending on some rule" which hints that it may be not only loudest speaker so you do not really know what auto-switch means. I will continue to insist on providing explicit information from the provider to the consumer so he can make a sensible selection and to enable extensibility. In this case it will be the providing the auto switching algorithm. [BB] Ok, I think we're on the same page here...I think we may need a more solid definition of 'auto-switched' or we'll need to enable the producer to be more explicit. =20 =20 =20 Regards=20 Roni =20 ------_=_NextPart_001_01CC8448.784D2151 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey Roni, inline again.

 

From:= Roni Even [mailto:Even.roni@huawei.com]
Sent: Wednesday, October 05, 2011 2:22 PM
To: Brian Baldino (bbaldino); clue@ietf.org
Subject: RE: [clue] Area of capture = attribute

 

Brian,

Inline

Roni

From:= Brian = Baldino (bbaldino) [mailto:bbaldino@cisco.com]
Sent: Wednesday, October 05, 2011 7:43 PM
To: Roni Even; clue@ietf.org
Subject: RE: [clue] Area of capture = attribute

 

Hey Roni,

Took my best shot = inline.

-Brian

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Tuesday, October 04, 2011 11:03 PM
To: clue@ietf.org
Subject: [clue] Area of capture attribute

 

Hi,

I read the new revision and I think that this = attribute is a good starting point to address the discussion on the spatial = description. I hope that we will be able to finalize the model in the Interim = meeting.

 

I started a new thread after seeing the comments = from Christian and Mark.

I will send more feedback on the draft in a = separate email.

 

I think that there is some information missing that = will be helpful

 

1.       The position of the origin of the axis  and = the full range of the area is needed probably as a capture set attribute in = order to understand the view. For example having a VC that says (0,33) does = not provide enough information to know what part of the room it covers. I do = not think that saying that there will be one configuration for example (VC1 = (0,33), VC2(33,66),VC3(66,99)) is the right way since it requires to have such configuration and it also means that the range is (0,99) while it may = also be covering part of a (-10,110) range. The major requirement is not to use = implied information but be explicit.

[BB] I think I agree that this might be useful, but, = I’m not sure we’ve come up with a use case that really demands it = yet.  Let me see if what I have in mind for what you described (and why the origin = and full range up front aren’t needed there) makes = sense:

I’m not sure what = you’ve described (an advertiser only offering a single video capture VC0(0,33)) would be = that common (as, like you said, it isn’t very useful) but if it did, I = still think the renderer could render it sensibly.  Since there are no = other captures advertised, the renderer does not need to be careful about = rendering the VC in a certain position relative to other captures from that same = device because there are none.  In your example: if a 3 camera endpoint = only advertised its left camera as VC0(0,33) a 3 screen endpoint on the other = end could render it wherever it wanted because its main concern (making sure cameras from a multi-camera transmitter are placed correctly relative to = one another) is no longer an issue.  Perhaps there is a scenario unlike = what I’ve just described where, even though only one small subset of the entire = device was advertised, it was important to render it in exactly one = place.  Do you know of an example where that may be the = case?

 

 

[Roni] I hope you followed the discussion on the list = about gaps between captures. This is a use case where you need the origin and the = X,Y coordinates. I think that also the multiview use case will need it. It = will not be needed if there is a hidden  assumption that the area describes = the range at the line where the first row of people is at. Some systems may = decide that this measure is at the back of the room.

You claim that by = having all the different video captures I can learn the range of the room and I say why = learn it from all the specified captures provide it separately. I am not sure = why you are trying to optimize the provided information.

[BB] I’m not saying we can’t provide the entire = range of the room up front, maybe there’s a good reason for it.  I = still haven’t heard why the origin is necessary though to determine the = gap between captures?

 

 

2.       I think that it is important not only to have = the X coordinates but also have the Y coordinates to be able to know if there = is a gap or overlap at the relevant distance. Again the origin of the axes is crucial here.

[BB] The document provides for describing the area of = capture in up to 3 dimensions(x, y and z); seems like that gives the flexibility = you’re looking for? 

[Roni] My claim is = that you must provide at least X and Y

[BB] If my producer only has captures which vary in 1 = dimension, why must I provide the Y coordinate?

 

3.       I am not sure about the example in section 7 for = the active speaker (VC3) "VC3- (the loudest panel stream), encoding = group:EG1, attributes:purpose=3Dmain;auto-switched:yes; = area_of_capture=3D{xBegin=3D0,  xEnd=3D99}". How do you know what is the area of capture you are = really getting, my understanding is that it is  implied that there are = VC0,VC1 and VC2 and you get one of them. Again, I prefer explicit information = for this case even if it means having at attribute that will specify that the = switch is between VC0, VC1 and VC2 or have it as part of the auto-switch = attribute.

[BB] The idea here is that the transmitter is showing you = the most appropriate subset of that range.  You’re right the receiver doesn’t know specifically what’s being sent, but, why does = it care?  The receiver signed up for getting the most relevant stream = in that range and that’s what the transmitter will send it.  What do = you think the receiver needs to know?

[Roni} you want to know in order to choose between VC3, = VC4, VC5 which offer similar proposal. The  consumer will need to select the = most relevant stream, for VC3 note that for auto-switch according to 5.2.8 “In = this case the offered AC or VC varies depending on some rule”  which = hints that it may be not only loudest speaker so you do not really know what auto-switch means. I will continue to insist on providing explicit = information from the provider to the consumer so he can make a sensible selection = and to enable extensibility. In this case it will be the providing the auto = switching algorithm.

[BB] Ok, I think we’re on the same page here...I think = we may need a more solid definition of ‘auto-switched’ or = we’ll need to enable the producer to be more explicit.

 

 

 

Regards

Roni

 

------_=_NextPart_001_01CC8448.784D2151-- From stephen.botzko@gmail.com Thu Oct 6 11:59:10 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70A411E80B5 for ; Thu, 6 Oct 2011 11:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.106 X-Spam-Level: X-Spam-Status: No, score=-4.106 tagged_above=-999 required=5 tests=[AWL=0.892, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDULgX20Q1iF for ; Thu, 6 Oct 2011 11:59:08 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3D50C11E80C1 for ; Thu, 6 Oct 2011 11:59:08 -0700 (PDT) Received: by vws5 with SMTP id 5so3163281vws.31 for ; Thu, 06 Oct 2011 12:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UiEH0cVVW/pOgBR3VCAAS3nzjr+EC1fXspaDQYnC+vw=; b=RZw2Tivc9DmjJoPAfg12B31zThHFk8ogr2qyKq4pgOumgBel3bplF6efn2iaPRVJX8 favx5VokuvS1Rw9l6O7Y605Y7tFyJkF+/JA+7LMfMiYvXOQX80NYa1rKFO+at90MbxoU DbpW1+KyBjxYrR8qd5lSgUVegLtY23Y3VSujI= MIME-Version: 1.0 Received: by 10.52.93.1 with SMTP id cq1mr1018191vdb.400.1317927739328; Thu, 06 Oct 2011 12:02:19 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Thu, 6 Oct 2011 12:02:19 -0700 (PDT) In-Reply-To: References: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61CDF41693@CRPMBOXPRD01.polycom.com> Date: Thu, 6 Oct 2011 15:02:19 -0400 Message-ID: From: Stephen Botzko To: Marshall Eubanks Content-Type: multipart/alternative; boundary=20cf307cfbbcbe092d04aea5f64d Cc: "clue@ietf.org" Subject: Re: [clue] Area of capture attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 18:59:10 -0000 --20cf307cfbbcbe092d04aea5f64d Content-Type: text/plain; charset=ISO-8859-1 in-line On Thu, Oct 6, 2011 at 11:24 AM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > On Thu, Oct 6, 2011 at 11:09 AM, Stephen Botzko > wrote: > >>>> > > (c) Provide the FOV in degrees and a scale factor (standard length). > > >>>> > > Not sure how that is different from (a); it seems the same to me. Maybe > we > > can discuss next week > > > > a) provide both MM scale and field of view in degrees. > > I interpreted this as something like > > area_of_capture for Camera 1 is (0, 33 degrees) OR (0, 245 mm) > [sb] For (a) I meant "AND" not "OR", which would allow the ypoint to be computed. That is for a 33 degree field of view, you can compute the distance to the plane where the capture is 245 mm wide. > I am proposing something like > > FOV for Camera 1 is > area_of_capture={xBegin=0, xEnd=33} > point_of_interest=(ypoint="425" , type="Row 1") > [sb] I guess for scale, you are thinking that I should compute the size of the capture at ypoint as (2*425) * arctan (0.5 * (xEnd-xBegin))? For most of our envisioned use cases I need to know scale and adjacency, and not FoV. I'd prefer to limit the trig to the rarer scenarios if possible. I am also envisioning bugs related to degrees/radians... Perhaps more importantly, I think this representation assumes that all cameras are co-located. At least, with angular units I do not see how to relate xBegin and xEnd of camera 1 with the xBegin and Xend of camera 2 unless I assume that the cameras are co-located. BTW, unless I made a math mistake, 245 mm capture width at a distance of 425 mm works out to a 34 degree FoV. If I got this wrong, let me know. > If this is done I would suggest certain specific default "types" - > "Row {i}", "Podium {i}", etc. > > If area of capture is defined in angular units, then point_of_interest > can always be in mm. > > Regards > Marshall > > P.S. In preparing this email I noticed that the point_of_capture > _format_ seems to be defined nowhere. > I would suggest > > point_of_capture=(xpoint="15") > > as a suitable format. > > > > Stephen Botzko > > > > On Thu, Oct 6, 2011 at 10:57 AM, Marshall Eubanks > > wrote: > >> > >> On Thu, Oct 6, 2011 at 7:20 AM, Stephen Botzko < > stephen.botzko@gmail.com> > >> wrote: > >> > In order to get actual-size information with field-of-view in degrees, > >> > you > >> > need to know the distance from the camera to the first row (which > right > >> > now > >> > is implicit in the mm scale). > >> > > >> > This suggests a couple of mathematically equivalent alternatives: > >> > (a) provide both MM scale and field of view in degrees. If someone > >> > needed > >> > the distance to the first row, it could be computed. > >> > (b) provide MM scale and the distance to the first row. In this > >> > combination, field-of-view in degrees can be computed. > >> > > >> > (b) has an advantage in that it can be extended to include multiple > >> > rows. > >> > >> In a kludgy way (mm means mm, except for the second row, when it > >> doesn't). I prefer > >> > >> (c) Provide the FOV in degrees and a scale factor (standard length). > >> > >> Is there any reason why this shouldn't be (possibly) included > >> for every scene captured, including possibly sub-scene. (In other > >> words, how do you determine the distance to the second row without > >> information about that scale factor.) > >> > >> I am also specifically interested in including podium type situations, > >> which are not "rows." > >> > >> Regards > >> Marshall > >> > >> > >> > >> > > >> > On Wed, Oct 5, 2011 at 5:15 PM, Duckworth, Mark > >> > > >> > wrote: > >> >> > >> >> I can see that degrees might be a useful scale for X and Z in > addition > >> >> to > >> >> millimeters. Maybe it should be tenths of a degree, and use integers > >> >> (no > >> >> floating point)? So if we allow that, then we need a way to indicate > >> >> the > >> >> scale of area of capture and point of capture numbers which would be > >> >> one of: > >> >> none, millimeters, degrees. And I think this scale indication > applies > >> >> to an > >> >> entire capture set, not individual media captures. Everything in a > >> >> particular capture set must use the same scale. > >> >> > >> >> When we introduced the area of capture concept, and using a > millimeter > >> >> scale, I thought that would eliminate the need for the Video Scale > >> >> attribute > >> >> we had before. I now think we should bring back a separate Video > Scale > >> >> attribute, because the area of capture won't always be enough to tell > >> >> the > >> >> scale in terms of how large to render it to make it seem the > >> >> appropriate > >> >> size at the rendering side. One example is an auto-switched video > >> >> capture > >> >> that covers 0 to 99 (area of capture), while at any one time it is > only > >> >> covering a third of it (video scale), so having a separate video > scale > >> >> attribute allows the renderer to scale it accordingly if it wants. > Now > >> >> I > >> >> wonder if the scale attribute really should be associated with a > video > >> >> stream in RTP, rather than with a video capture, because maybe it > >> >> should be > >> >> more dynamic than capture set advertisements. > >> >> > >> >> Marshall, your definition of left and right makes good sense to me. > >> >> > >> >> Mark Duckworth > >> >> > >> >> > -----Original Message----- > >> >> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > >> >> > Of > >> >> > Marshall Eubanks > >> >> > Sent: Wednesday, October 05, 2011 2:44 PM > >> >> > To: Brian Baldino (bbaldino) > >> >> > Cc: clue@ietf.org > >> >> > Subject: Re: [clue] Area of capture attribute > >> >> > > >> >> > On Wed, Oct 5, 2011 at 1:42 PM, Brian Baldino (bbaldino) > >> >> > wrote: > >> >> > > Hey Roni, > >> >> > > > >> >> > > Took my best shot inline. > >> >> > > > >> >> > > -Brian > >> >> > > > >> >> > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >> >> > > Behalf > >> >> > Of Roni > >> >> > > Even > >> >> > > Sent: Tuesday, October 04, 2011 11:03 PM > >> >> > > To: clue@ietf.org > >> >> > > Subject: [clue] Area of capture attribute > >> >> > > > >> >> > > Hi, > >> >> > > > >> >> > > I read the new revision and I think that this attribute is a good > >> >> > starting > >> >> > > point to address the discussion on the spatial description. I > hope > >> >> > that we > >> >> > > will be able to finalize the model in the Interim meeting. > >> >> > > > >> >> > > I started a new thread after seeing the comments from Christian > and > >> >> > Mark. > >> >> > > > >> >> > > I will send more feedback on the draft in a separate email. > >> >> > > > >> >> > > I think that there is some information missing that will be > helpful > >> >> > > > >> >> > > 1. The position of the origin of the axis and the full > range > >> >> > of the > >> >> > > area is needed probably as a capture set attribute in order to > >> >> > understand > >> >> > > the view. For example having a VC that says (0,33) does not > provide > >> >> > enough > >> >> > > information to know what part of the room it covers. I do not > think > >> >> > that > >> >> > > saying that there will be one configuration for example (VC1 > >> >> > > (0,33), > >> >> > > VC2(33,66),VC3(66,99)) is the right way since it requires to have > >> >> > such > >> >> > > configuration and it also means that the range is (0,99) while it > >> >> > > may > >> >> > also > >> >> > > be covering part of a (-10,110) range. The major requirement is > not > >> >> > to use > >> >> > > implied information but be explicit. > >> >> > > > >> >> > > [BB] I think I agree that this might be useful, but, I'm not sure > >> >> > we've come > >> >> > > up with a use case that really demands it yet. Let me see if > what > >> >> > > I > >> >> > have in > >> >> > > mind for what you described (and why the origin and full range up > >> >> > front > >> >> > > aren't needed there) makes sense: > >> >> > > > >> >> > > I'm not sure what you've described (an advertiser only offering a > >> >> > single > >> >> > > video capture VC0(0,33)) would be that common (as, like you said, > >> >> > > it > >> >> > isn't > >> >> > > very useful) but if it did, I still think the renderer could > render > >> >> > it > >> >> > > sensibly. Since there are no other captures advertised, the > >> >> > > renderer > >> >> > does > >> >> > > not need to be careful about rendering the VC in a certain > position > >> >> > relative > >> >> > > to other captures from that same device because there are none. > In > >> >> > your > >> >> > > example: if a 3 camera endpoint only advertised its left camera > as > >> >> > VC0(0,33) > >> >> > > a 3 screen endpoint on the other end could render it wherever it > >> >> > wanted > >> >> > > because its main concern (making sure cameras from a multi-camera > >> >> > > transmitter are placed correctly relative to one another) is no > >> >> > longer an > >> >> > > issue. Perhaps there is a scenario unlike what I've just > described > >> >> > where, > >> >> > > even though only one small subset of the entire device was > >> >> > advertised, it > >> >> > > was important to render it in exactly one place. Do you know of > an > >> >> > example > >> >> > > where that may be the case? > >> >> > > > >> >> > > 2. I think that it is important not only to have the X > >> >> > coordinates but > >> >> > > also have the Y coordinates to be able to know if there is a gap > or > >> >> > overlap > >> >> > > at the relevant distance. Again the origin of the axes is crucial > >> >> > here. > >> >> > > > >> >> > > [BB] The document provides for describing the area of capture in > up > >> >> > to 3 > >> >> > > dimensions(x, y and z); seems like that gives the flexibility > >> >> > > you're > >> >> > looking > >> >> > > for? > >> >> > > > >> >> > > >> >> > Ah, I missed that - it's implicit in 5.2.4. (I searched on > vertical, > >> >> > which is nowhere mentioned.) Obviously, this could use some wording > >> >> > tweaks, which I promised to provide. > >> >> > > >> >> > In 5.2.4, I suggest you start with > >> >> > > >> >> > The area_of_capture attribute is used to describe the relevant area > >> >> > of > >> >> > which a media capture is "capturing". > >> >> > Area of capture is expressed as pairs of {x, y, z} coordinates to > >> >> > describe {left to right, front to back, low to high} ranges in that > >> >> > order where, as with point_of_capture, only the necessary > dimensions > >> >> > need be expressed. In other words, it is specified that, as numbers > >> >> > move from lower to higher, the location is going from: left to > right > >> >> > (in the case of the 'x' dimension), front to back (in the case of > the > >> >> > 'y' dimension or low to high (in the case of the 'z' dimension). > >> >> > > >> >> > > >> >> > In 5.2.6. it says > >> >> > > >> >> > Area Scale Millimeters > >> >> > An optional Boolean variable indicating if the numbers used for > area > >> >> > of capture and point of capture are in terms of millimeters. If > this > >> >> > attribute is true, then the x,y,z numbers represent millimeters. If > >> >> > this attribute is false, then there is no physical scale. The > default > >> >> > value is false. > >> >> > > >> >> > Note that "degrees" are not mentioned anywhere in the document. > >> >> > Degrees may not be a physical scale, but they are still a scale. > (If > >> >> > you interpret {0,33} as radians or pixels, you are unlikely to get > >> >> > pleasing results.) There is another issue, as I don't know what the > >> >> > equivalent to angles are for front to back. > >> >> > > >> >> > I would change " If this attribute is false, then there is no > >> >> > physical > >> >> > scale." to > >> >> > > >> >> > " If this attribute is false, then the scale for x and z is > >> >> > degrees, > >> >> > and the scale for y remains mm." > >> >> > > >> >> > If you have another default scale for y, you should specify it (I > >> >> > can't imagine what it would be.) > >> >> > > >> >> > (BTW, I believe that I suggested y being up and down and z being > >> >> > front > >> >> > to back, precisely because most people will specify x, fewer > up-down, > >> >> > and fewest front back distances. If you do that, you have to switch > >> >> > the definition of left and right to stage-left and stage-right to > >> >> > keep > >> >> > a right handed system.) > >> >> > > >> >> > In Section 3, it says. > >> >> > > >> >> > Left: For media captures, left and right is from the point of view > of > >> >> > a person observing the rendered media. > >> >> > > >> >> > This is the opposite of stage-left and stage-right, and would be > >> >> > called camera-left and camera-right in American TV. > >> >> > > >> >> > In other words, "left" and "right" are camera-left and > camera-right > >> >> > in theatrical parlance, and are the opposite of left and right for > >> >> > the > >> >> > person being observed. > >> >> > > >> >> > Actually, I would strongly urge the definition and _explicit_ use > of > >> >> > camera-left and camera-right (or stage-left and stage-right) in > >> >> > EVERY > >> >> > occurrence of their use. > >> >> > > >> >> > If we don't do that, I am willing to bet someone will mess it up. > >> >> > > >> >> > So, if you do this, the definition becomes > >> >> > > >> >> > Camera-Left: For media captures, camera-left and camera-right is > from > >> >> > the point of view of a person observing the rendered media. They > are > >> >> > the opposite of stage-left and stage-right, which are the left and > >> >> > right of the person being observed. > >> >> > > >> >> > Note also that front and back are not defined. They should be. Up > and > >> >> > down I think can go undefined. > >> >> > > >> >> > Front. Front is the portion of the room closest to the cameras. In > >> >> > going towards back you move away from the cameras. > >> >> > > >> >> > > >> >> > > 3. I am not sure about the example in section 7 for the > >> >> > > active > >> >> > speaker > >> >> > > (VC3) "VC3- (the loudest panel stream), encoding group:EG1, > >> >> > > attributes:purpose=main;auto-switched:yes; > >> >> > > area_of_capture={xBegin=0, > >> >> > > xEnd=99}". How do you know what is the area of capture you are > >> >> > > really > >> >> > > getting, my understanding is that it is implied that there are > >> >> > VC0,VC1 and > >> >> > > VC2 and you get one of them. Again, I prefer explicit information > >> >> > > for > >> >> > this > >> >> > > case even if it means having at attribute that will specify that > >> >> > > the > >> >> > switch > >> >> > > is between VC0, VC1 and VC2 or have it as part of the auto-switch > >> >> > attribute. > >> >> > > > >> >> > > [BB] The idea here is that the transmitter is showing you the > most > >> >> > > appropriate subset of that range. You're right the receiver > >> >> > > doesn't > >> >> > know > >> >> > > specifically what's being sent, but, why does it care? The > >> >> > > receiver > >> >> > signed > >> >> > > up for getting the most relevant stream in that range and that's > >> >> > > what > >> >> > the > >> >> > > transmitter will send it. What do you think the receiver needs > to > >> >> > know? > >> >> > > > >> >> > > >> >> > To scale the image appropriately. For example, if VC3 is really > VC1, > >> >> > that could maybe be shown > >> >> > in full. If VC3 is really VC0+VC1+VC3 composited together, it > should > >> >> > be letter boxed. > >> >> > > >> >> > I am also nervous about throwing away information when we don't > have > >> >> > to. > >> >> > > >> >> > Regards > >> >> > Marshall > >> >> > > >> >> > > Regards > >> >> > > Roni > >> >> _______________________________________________ > >> >> clue mailing list > >> >> clue@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/clue > >> > > >> > > >> > _______________________________________________ > >> > clue mailing list > >> > clue@ietf.org > >> > https://www.ietf.org/mailman/listinfo/clue > >> > > >> > > > > > > --20cf307cfbbcbe092d04aea5f64d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable in-line

On Thu, Oct 6, 2011 at 11:24 AM, = Marshall Eubanks <marshall.eubanks@gmail.com> wrote:
On Thu, Oct 6, 2011 at 11:09 AM, Stephen Botzko
<stephen.botzko@gmail.com> wrote:
>>>>
> (c) Provide the FOV in degrees and a scale factor (standard length).
>>>>
> Not sure how that is different from (a); it seems the same to me.=A0 M= aybe we
> can discuss next week
>

a) provide both MM scale and field of view in degre= es.

I interpreted this as something like

area_of_capture =A0for Camera 1 is (0, 33 degrees) OR (0, 245 mm)
[sb] For (a) I meant "AND" not "OR", which = would allow the ypoint to be computed.=A0 That is for a 33 degree field of = view, you can compute the distance to the plane where the capture is 245 mm= wide.=A0


I am proposing something like

FOV for Camera 1 is
area_of_capture=3D{xBegin=3D0, xEnd=3D33}
point_of_interest=3D(ypoint=3D"425" , type=3D"Row 1")
[sb] I guess for scale, you are thinking that I should = compute the size of the capture at ypoint as (2*425) * arctan (0.5 * (xEnd-= xBegin))?=A0 For most of our envisioned use cases I need to know scale and = adjacency, and not FoV.=A0 I'd prefer to limit the trig to the rarer sc= enarios if possible.=A0 I am also envisioning bugs related to degrees/radia= ns...
=A0
Perhaps more importantly, I think this representation assumes= that all cameras are co-located.=A0 At least, with angular units I do not = see how to relate xBegin and xEnd of camera 1 with the xBegin and Xend of c= amera 2 unless I assume that the cameras are co-located.

BTW, unless I made a math mistake, 245 mm capture width at a distance o= f 425 mm works out to a 34 degree FoV.=A0 If I got this wrong, let me know.=



If this is done I would suggest certain specific default "types" = -
"Row {i}", "Podium {i}", etc.

If area of capture is defined in angular units, then point_of_interest
can always be in mm.

Regards
Marshall

P.S. In preparing this email I noticed that the point_of_capture
_format_ seems to be defined nowhere.
I would suggest

point_of_capture=3D(xpoint=3D"15")

as a suitable format.


> Stephen Botzko
>
> On Thu, Oct 6, 2011 at 10:57 AM, Marshall Eubanks
> <marshall.eubanks@gma= il.com> wrote:
>>
>> On Thu, Oct 6, 2011 at 7:20 AM, Stephen Botzko <stephen.botzko@gmail.com>
>> wrote:
>> > In order to get actual-size information with field-of-view in= degrees,
>> > you
>> > need to know the distance from the camera to the first row (w= hich right
>> > now
>> > is implicit in the mm scale).
>> >
>> > This suggests a couple of mathematically equivalent alternati= ves:
>> > (a) provide both MM scale and field of view in degrees.=A0 If= someone
>> > needed
>> > the distance to the first row, it could be computed.
>> > (b) provide MM scale and the distance to the first row.=A0 In= this
>> > combination, field-of-view in degrees can be computed.
>> >
>> > (b) has an advantage in that it can be extended to include mu= ltiple
>> > rows.
>>
>> In a kludgy way (mm means mm, except for the second row, when it >> doesn't). I prefer
>>
>> (c) Provide the FOV in degrees and a scale factor (standard length= ).
>>
>> Is there any reason why this shouldn't be (possibly) included<= br> >> for every scene captured, including possibly sub-scene. (In other<= br> >> words, how do you determine the distance to the second row without=
>> information about that scale factor.)
>>
>> I am also specifically interested in including podium type situati= ons,
>> which are not "rows."
>>
>> Regards
>> Marshall
>>
>>
>>
>> >
>> > On Wed, Oct 5, 2011 at 5:15 PM, Duckworth, Mark
>> > <Mark.Duckwo= rth@polycom.com>
>> > wrote:
>> >>
>> >> I can see that degrees might be a useful scale for X and = Z in addition
>> >> to
>> >> millimeters. =A0Maybe it should be tenths of a degree, an= d use integers
>> >> (no
>> >> floating point)? =A0So if we allow that, then we need a w= ay to indicate
>> >> the
>> >> scale of area of capture and point of capture numbers whi= ch would be
>> >> one of:
>> >> none, millimeters, degrees. =A0And I think this scale ind= ication applies
>> >> to an
>> >> entire capture set, not individual media captures. =A0Eve= rything in a
>> >> particular capture set must use the same scale.
>> >>
>> >> When we introduced the area of capture concept, and using= a millimeter
>> >> scale, I thought that would eliminate the need for the Vi= deo Scale
>> >> attribute
>> >> we had before. =A0I now think we should bring back a sepa= rate Video Scale
>> >> attribute, because the area of capture won't always b= e enough to tell
>> >> the
>> >> scale in terms of how large to render it to make it seem = the
>> >> appropriate
>> >> size at the rendering side. =A0One example is an auto-swi= tched video
>> >> capture
>> >> that covers 0 to 99 (area of capture), while at any one t= ime it is only
>> >> covering a third of it (video scale), so having a separat= e video scale
>> >> attribute allows the renderer to scale it accordingly if = it wants. =A0Now
>> >> I
>> >> wonder if the scale attribute really should be associated= with a video
>> >> stream in RTP, rather than with a video capture, because = maybe it
>> >> should be
>> >> more dynamic than capture set advertisements.
>> >>
>> >> Marshall, your definition of left and right makes good se= nse to me.
>> >>
>> >> Mark Duckworth
>> >>
>> >> > -----Original Message-----
>> >> > From: clue-= bounces@ietf.org [mailto:clue-= bounces@ietf.org] On Behalf
>> >> > Of
>> >> > Marshall Eubanks
>> >> > Sent: Wednesday, October 05, 2011 2:44 PM
>> >> > To: Brian Baldino (bbaldino)
>> >> > Cc: clue@ietf.org
>> >> > Subject: Re: [clue] Area of capture attribute
>> >> >
>> >> > On Wed, Oct 5, 2011 at 1:42 PM, Brian Baldino (bbald= ino)
>> >> > <bbaldino@c= isco.com> wrote:
>> >> > > Hey Roni,
>> >> > >
>> >> > > Took my best shot inline.
>> >> > >
>> >> > > -Brian
>> >> > >
>> >> > > From: = clue-bounces@ietf.org [mailto:= clue-bounces@ietf.org] On
>> >> > > Behalf
>> >> > Of Roni
>> >> > > Even
>> >> > > Sent: Tuesday, October 04, 2011 11:03 PM
>> >> > > To: clue@ietf.= org
>> >> > > Subject: [clue] Area of capture attribute
>> >> > >
>> >> > > Hi,
>> >> > >
>> >> > > I read the new revision and I think that this a= ttribute is a good
>> >> > starting
>> >> > > point to address the discussion on the spatial = description. I hope
>> >> > that we
>> >> > > will be able to finalize the model in the Inter= im meeting.
>> >> > >
>> >> > > I started a new thread after seeing the comment= s from Christian and
>> >> > Mark.
>> >> > >
>> >> > > I will send more feedback on the draft in a sep= arate email.
>> >> > >
>> >> > > I think that there is some information missing = that will be helpful
>> >> > >
>> >> > > 1.=A0=A0=A0=A0=A0=A0 The position of the origin= of the axis =A0and the full range
>> >> > of the
>> >> > > area is needed probably as a capture set attrib= ute in order to
>> >> > understand
>> >> > > the view. For example having a VC that says (0,= 33) does not provide
>> >> > enough
>> >> > > information to know what part of the room it co= vers. I do not think
>> >> > that
>> >> > > saying that there will be one configuration for= example (VC1
>> >> > > (0,33),
>> >> > > VC2(33,66),VC3(66,99)) is the right way since i= t requires to have
>> >> > such
>> >> > > configuration and it also means that the range = is (0,99) while it
>> >> > > may
>> >> > also
>> >> > > be covering part of a (-10,110) range. The majo= r requirement is not
>> >> > to use
>> >> > > implied information but be explicit.
>> >> > >
>> >> > > [BB] I think I agree that this might be useful,= but, I'm not sure
>> >> > we've come
>> >> > > up with a use case that really demands it yet.= =A0 Let me see if what
>> >> > > I
>> >> > have in
>> >> > > mind for what you described (and why the origin= and full range up
>> >> > front
>> >> > > aren't needed there) makes sense:
>> >> > >
>> >> > > I'm not sure what you've described (an = advertiser only offering a
>> >> > single
>> >> > > video capture VC0(0,33)) would be that common (= as, like you said,
>> >> > > it
>> >> > isn't
>> >> > > very useful) but if it did, I still think the r= enderer could render
>> >> > it
>> >> > > sensibly.=A0 Since there are no other captures = advertised, the
>> >> > > renderer
>> >> > does
>> >> > > not need to be careful about rendering the VC i= n a certain position
>> >> > relative
>> >> > > to other captures from that same device because= there are none.=A0 In
>> >> > your
>> >> > > example: if a 3 camera endpoint only advertised= its left camera as
>> >> > VC0(0,33)
>> >> > > a 3 screen endpoint on the other end could rend= er it wherever it
>> >> > wanted
>> >> > > because its main concern (making sure cameras f= rom a multi-camera
>> >> > > transmitter are placed correctly relative to on= e another) is no
>> >> > longer an
>> >> > > issue.=A0 Perhaps there is a scenario unlike wh= at I've just described
>> >> > where,
>> >> > > even though only one small subset of the entire= device was
>> >> > advertised, it
>> >> > > was important to render it in exactly one place= .=A0 Do you know of an
>> >> > example
>> >> > > where that may be the case?
>> >> > >
>> >> > > 2.=A0=A0=A0=A0=A0=A0 I think that it is importa= nt not only to have the X
>> >> > coordinates but
>> >> > > also have the Y coordinates to be able to know = if there is a gap or
>> >> > overlap
>> >> > > at the relevant distance. Again the origin of t= he axes is crucial
>> >> > here.
>> >> > >
>> >> > > [BB] The document provides for describing the a= rea of capture in up
>> >> > to 3
>> >> > > dimensions(x, y and z); seems like that gives t= he flexibility
>> >> > > you're
>> >> > looking
>> >> > > for?
>> >> > >
>> >> >
>> >> > Ah, I missed that - it's implicit in 5.2.4. (I s= earched on vertical,
>> >> > which is nowhere mentioned.) Obviously, this could u= se some wording
>> >> > tweaks, which I promised to provide.
>> >> >
>> >> > In 5.2.4, I suggest you start with
>> >> >
>> >> > The area_of_capture attribute is used to describe th= e relevant area
>> >> > of
>> >> > which a media capture is "capturing".
>> >> > Area of capture is expressed as pairs of =A0{x, y, z= } coordinates to
>> >> > describe {left to right, front to back, low to high}= ranges in that
>> >> > order where, as with point_of_capture, only the nece= ssary dimensions
>> >> > need be expressed. In other words, it is specified t= hat, as numbers
>> >> > move from lower to higher, the location is going fro= m: left to right
>> >> > (in the case of the 'x' dimension), front to= back (in the case of the
>> >> > 'y' dimension or low to high (in the case of= the 'z' dimension).
>> >> >
>> >> >
>> >> > =A0In 5.2.6. it says
>> >> >
>> >> > =A0Area Scale Millimeters
>> >> > An optional Boolean variable indicating if the numbe= rs used for area
>> >> > of capture and point of capture are in terms of mill= imeters. If this
>> >> > attribute is true, then the x,y,z numbers represent = millimeters. If
>> >> > this attribute is false, then there is no physical s= cale. The default
>> >> > value is false.
>> >> >
>> >> > Note that "degrees" are not mentioned anyw= here in the document.
>> >> > Degrees may not be a physical scale, but they are st= ill a scale. (If
>> >> > you interpret {0,33} as radians or pixels, you are u= nlikely to get
>> >> > pleasing results.) There is another issue, as I don&= #39;t know what the
>> >> > equivalent to angles are for front to back.
>> >> >
>> >> > I would change " If this attribute is false, th= en there is no
>> >> > physical
>> >> > scale." =A0to
>> >> >
>> >> > =A0" If this attribute is false, then the =A0sc= ale for x and z is
>> >> > degrees,
>> >> > and the scale for y remains mm."
>> >> >
>> >> > If you have another default scale for y, you should = specify it (I
>> >> > can't imagine what it would be.)
>> >> >
>> >> > (BTW, I believe that I suggested y being up and down= and z being
>> >> > front
>> >> > to back, precisely because most people will specify = x, fewer up-down,
>> >> > and fewest front back distances. If you do that, you= have to switch
>> >> > the definition of left and right to stage-left and s= tage-right to
>> >> > keep
>> >> > a right handed system.)
>> >> >
>> >> > In Section 3, it says.
>> >> >
>> >> > Left: For media captures, left and right is from the= point of view of
>> >> > a person observing the rendered media.
>> >> >
>> >> > This is the opposite of stage-left and stage-right, = and would be
>> >> > called camera-left =A0and camera-right in American T= V.
>> >> >
>> >> > In other words, "left" and "right&quo= t; are camera-left =A0and camera-right
>> >> > in theatrical parlance, and are the opposite of left= and right for
>> >> > the
>> >> > person being observed.
>> >> >
>> >> > Actually, I would strongly urge the =A0definition an= d _explicit_ use of
>> >> > camera-left and camera-right (or stage-left and stag= e-right) =A0in
>> >> > EVERY
>> >> > occurrence of their use.
>> >> >
>> >> > If we don't do that, I am willing to bet someone= will mess it up.
>> >> >
>> >> > So, if you do this, the definition becomes
>> >> >
>> >> > Camera-Left: For media captures, camera-left and cam= era-right is from
>> >> > the point of view of a person observing the rendered= media. They are
>> >> > the opposite of stage-left and stage-right, which ar= e the left and
>> >> > right of the person being observed.
>> >> >
>> >> > Note also that front and back are not defined. They = should be. Up and
>> >> > down I think can go undefined.
>> >> >
>> >> > Front. Front is the portion of the room closest to t= he cameras. In
>> >> > going towards back you move away from the cameras. >> >> >
>> >> >
>> >> > > 3.=A0=A0=A0=A0=A0=A0 I am not sure about the ex= ample in section 7 for the
>> >> > > active
>> >> > speaker
>> >> > > (VC3) "VC3- (the loudest panel stream), en= coding group:EG1,
>> >> > > attributes:purpose=3Dmain;auto-switched:yes; >> >> > > area_of_capture=3D{xBegin=3D0,
>> >> > > xEnd=3D99}". How do you know what is the a= rea of capture you are
>> >> > > really
>> >> > > getting, my understanding is that it is =A0impl= ied that there are
>> >> > VC0,VC1 and
>> >> > > VC2 and you get one of them. Again, I prefer ex= plicit information
>> >> > > for
>> >> > this
>> >> > > case even if it means having at attribute that = will specify that
>> >> > > the
>> >> > switch
>> >> > > is between VC0, VC1 and VC2 or have it as part = of the auto-switch
>> >> > attribute.
>> >> > >
>> >> > > [BB] The idea here is that the transmitter is s= howing you the most
>> >> > > appropriate subset of that range.=A0 You're= right the receiver
>> >> > > doesn't
>> >> > know
>> >> > > specifically what's being sent, but, why do= es it care?=A0 The
>> >> > > receiver
>> >> > signed
>> >> > > up for getting the most relevant stream in that= range and that's
>> >> > > what
>> >> > the
>> >> > > transmitter will send it.=A0 What do you think = the receiver needs to
>> >> > know?
>> >> > >
>> >> >
>> >> > To scale the image appropriately. For example, if VC= 3 is really VC1,
>> >> > that could maybe be shown
>> >> > in full. If VC3 is really VC0+VC1+VC3 composited tog= ether, it should
>> >> > be letter boxed.
>> >> >
>> >> > I am also nervous about throwing away information wh= en we don't have
>> >> > to.
>> >> >
>> >> > Regards
>> >> > Marshall
>> >> >
>> >> > > Regards
>> >> > > Roni
>> >> _______________________________________________
>> >> clue mailing list
>> >> clue@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/clue
>> >
>> >
>> > _______________________________________________
>> > clue mailing list
>> > clue@ietf.org
>> > https://www.ietf.org/mailman/listinfo/clue
>> >
>> >
>
>

--20cf307cfbbcbe092d04aea5f64d-- From marshall.eubanks@gmail.com Thu Oct 6 15:10:17 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF8521F8C63 for ; Thu, 6 Oct 2011 15:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.984 X-Spam-Level: X-Spam-Status: No, score=-103.984 tagged_above=-999 required=5 tests=[AWL=1.015, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeNLafwbTGMj for ; Thu, 6 Oct 2011 15:10:15 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE4C21F8C5E for ; Thu, 6 Oct 2011 15:10:15 -0700 (PDT) Received: by ywm3 with SMTP id 3so3733592ywm.31 for ; Thu, 06 Oct 2011 15:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cmUkqfbHiFsYJ/SYLCD2WxDCVpWS3tyDtkMqMrUx15M=; b=P4clsPv19uD8IzkAyxuE7l4R/dAHPJgn8OK5SdcbW6XX3Fla+1UpbXqOxq+zMrkDI+ p0Q29M18OM/syx0mvnooLHQDpobXr61ILJB0enwFV9MSHKgmFwfhJlA9kCTv3c1vM6ng iXcOiwT/DwquFPoplxcpjz1rlGgRjAiKWdX+s= MIME-Version: 1.0 Received: by 10.150.143.2 with SMTP id q2mr983427ybd.368.1317939206666; Thu, 06 Oct 2011 15:13:26 -0700 (PDT) Received: by 10.151.98.20 with HTTP; Thu, 6 Oct 2011 15:13:26 -0700 (PDT) In-Reply-To: References: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61CDF41693@CRPMBOXPRD01.polycom.com> Date: Thu, 6 Oct 2011 18:13:26 -0400 Message-ID: From: Marshall Eubanks To: Stephen Botzko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "clue@ietf.org" Subject: Re: [clue] Area of capture attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 22:10:18 -0000 On Thu, Oct 6, 2011 at 3:02 PM, Stephen Botzko w= rote: > in-line > > On Thu, Oct 6, 2011 at 11:24 AM, Marshall Eubanks > wrote: >> >> On Thu, Oct 6, 2011 at 11:09 AM, Stephen Botzko >> wrote: >> >>>> >> > (c) Provide the FOV in degrees and a scale factor (standard length). >> >> >>>> >> > Not sure how that is different from (a); it seems the same to me.=A0 M= aybe >> > we >> > can discuss next week >> > >> >> a) provide both MM scale and field of view in degrees. >> >> I interpreted this as something like >> >> area_of_capture =A0for Camera 1 is (0, 33 degrees) OR (0, 245 mm) > > [sb] For (a) I meant "AND" not "OR", which would allow the ypoint to be > computed.=A0 That is for a 33 degree field of view, you can compute the > distance to the plane where the capture is 245 mm wide. > OK, so we are really proposing the same things, and just discussing the most parsimonious representation. >> >> I am proposing something like >> >> FOV for Camera 1 is >> area_of_capture=3D{xBegin=3D0, xEnd=3D33} >> point_of_interest=3D(ypoint=3D"425" , type=3D"Row 1") > > [sb] I guess for scale, you are thinking that I should compute the size o= f > the capture at ypoint as (2*425) * arctan (0.5 * (xEnd-xBegin))?=A0 For m= ost > of our envisioned use cases I need to know scale and adjacency, and not > FoV.=A0 I'd prefer to limit the trig to the rarer scenarios if possible.= =A0 I am > also envisioning bugs related to degrees/radians... > > Perhaps more importantly, I think this representation assumes that all > cameras are co-located.=A0 At least, with angular units I do not see how = to > relate xBegin and xEnd of camera 1 with the xBegin and Xend of camera 2 > unless I assume that the cameras are co-located. I don't see how the stating that area_of_capture =A0for Camera 1 is (0, 33 degrees) AND (0, 245 mm) avoids these issues. > > BTW, unless I made a math mistake, 245 mm capture width at a distance of = 425 > mm works out to a 34 degree FoV.=A0 If I got this wrong, let me know. > Well, here is another area of fuzziness - are these FOV in mm chords or circular segments ? I _bet_ that most will interpret FOV in degrees as circular segments and FOV in mm as chords (those being the easiest to measure). Now, 33 deg =3D .57596 radians so at a distance of 425 mm this corresponds to a circular segment of 244.8 mm and a chord of 241.4 mm Is it possible you were calculating using the chord versus the circular segment ? (I was using the circular segment.) At any rate, all of this needs to be very precisely specified, unless you go to my idea of specifying distances. Regards Marshall > >> >> If this is done I would suggest certain specific default "types" - >> "Row {i}", "Podium {i}", etc. >> >> If area of capture is defined in angular units, then point_of_interest >> can always be in mm. >> >> Regards >> Marshall >> >> P.S. In preparing this email I noticed that the point_of_capture >> _format_ seems to be defined nowhere. >> I would suggest >> >> point_of_capture=3D(xpoint=3D"15") >> >> as a suitable format. >> >> >> > Stephen Botzko >> > >> > On Thu, Oct 6, 2011 at 10:57 AM, Marshall Eubanks >> > wrote: >> >> >> >> On Thu, Oct 6, 2011 at 7:20 AM, Stephen Botzko >> >> >> >> wrote: >> >> > In order to get actual-size information with field-of-view in >> >> > degrees, >> >> > you >> >> > need to know the distance from the camera to the first row (which >> >> > right >> >> > now >> >> > is implicit in the mm scale). >> >> > >> >> > This suggests a couple of mathematically equivalent alternatives: >> >> > (a) provide both MM scale and field of view in degrees.=A0 If someo= ne >> >> > needed >> >> > the distance to the first row, it could be computed. >> >> > (b) provide MM scale and the distance to the first row.=A0 In this >> >> > combination, field-of-view in degrees can be computed. >> >> > >> >> > (b) has an advantage in that it can be extended to include multiple >> >> > rows. >> >> >> >> In a kludgy way (mm means mm, except for the second row, when it >> >> doesn't). I prefer >> >> >> >> (c) Provide the FOV in degrees and a scale factor (standard length). >> >> >> >> Is there any reason why this shouldn't be (possibly) included >> >> for every scene captured, including possibly sub-scene. (In other >> >> words, how do you determine the distance to the second row without >> >> information about that scale factor.) >> >> >> >> I am also specifically interested in including podium type situations= , >> >> which are not "rows." >> >> >> >> Regards >> >> Marshall >> >> >> >> >> >> >> >> > >> >> > On Wed, Oct 5, 2011 at 5:15 PM, Duckworth, Mark >> >> > >> >> > wrote: >> >> >> >> >> >> I can see that degrees might be a useful scale for X and Z in >> >> >> addition >> >> >> to >> >> >> millimeters. =A0Maybe it should be tenths of a degree, and use >> >> >> integers >> >> >> (no >> >> >> floating point)? =A0So if we allow that, then we need a way to >> >> >> indicate >> >> >> the >> >> >> scale of area of capture and point of capture numbers which would = be >> >> >> one of: >> >> >> none, millimeters, degrees. =A0And I think this scale indication >> >> >> applies >> >> >> to an >> >> >> entire capture set, not individual media captures. =A0Everything i= n a >> >> >> particular capture set must use the same scale. >> >> >> >> >> >> When we introduced the area of capture concept, and using a >> >> >> millimeter >> >> >> scale, I thought that would eliminate the need for the Video Scale >> >> >> attribute >> >> >> we had before. =A0I now think we should bring back a separate Vide= o >> >> >> Scale >> >> >> attribute, because the area of capture won't always be enough to >> >> >> tell >> >> >> the >> >> >> scale in terms of how large to render it to make it seem the >> >> >> appropriate >> >> >> size at the rendering side. =A0One example is an auto-switched vid= eo >> >> >> capture >> >> >> that covers 0 to 99 (area of capture), while at any one time it is >> >> >> only >> >> >> covering a third of it (video scale), so having a separate video >> >> >> scale >> >> >> attribute allows the renderer to scale it accordingly if it wants. >> >> >> =A0Now >> >> >> I >> >> >> wonder if the scale attribute really should be associated with a >> >> >> video >> >> >> stream in RTP, rather than with a video capture, because maybe it >> >> >> should be >> >> >> more dynamic than capture set advertisements. >> >> >> >> >> >> Marshall, your definition of left and right makes good sense to me= . >> >> >> >> >> >> Mark Duckworth >> >> >> >> >> >> > -----Original Message----- >> >> >> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> >> >> > Behalf >> >> >> > Of >> >> >> > Marshall Eubanks >> >> >> > Sent: Wednesday, October 05, 2011 2:44 PM >> >> >> > To: Brian Baldino (bbaldino) >> >> >> > Cc: clue@ietf.org >> >> >> > Subject: Re: [clue] Area of capture attribute >> >> >> > >> >> >> > On Wed, Oct 5, 2011 at 1:42 PM, Brian Baldino (bbaldino) >> >> >> > wrote: >> >> >> > > Hey Roni, >> >> >> > > >> >> >> > > Took my best shot inline. >> >> >> > > >> >> >> > > -Brian >> >> >> > > >> >> >> > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> >> >> > > Behalf >> >> >> > Of Roni >> >> >> > > Even >> >> >> > > Sent: Tuesday, October 04, 2011 11:03 PM >> >> >> > > To: clue@ietf.org >> >> >> > > Subject: [clue] Area of capture attribute >> >> >> > > >> >> >> > > Hi, >> >> >> > > >> >> >> > > I read the new revision and I think that this attribute is a >> >> >> > > good >> >> >> > starting >> >> >> > > point to address the discussion on the spatial description. I >> >> >> > > hope >> >> >> > that we >> >> >> > > will be able to finalize the model in the Interim meeting. >> >> >> > > >> >> >> > > I started a new thread after seeing the comments from Christia= n >> >> >> > > and >> >> >> > Mark. >> >> >> > > >> >> >> > > I will send more feedback on the draft in a separate email. >> >> >> > > >> >> >> > > I think that there is some information missing that will be >> >> >> > > helpful >> >> >> > > >> >> >> > > 1.=A0=A0=A0=A0=A0=A0 The position of the origin of the axis = =A0and the full >> >> >> > > range >> >> >> > of the >> >> >> > > area is needed probably as a capture set attribute in order to >> >> >> > understand >> >> >> > > the view. For example having a VC that says (0,33) does not >> >> >> > > provide >> >> >> > enough >> >> >> > > information to know what part of the room it covers. I do not >> >> >> > > think >> >> >> > that >> >> >> > > saying that there will be one configuration for example (VC1 >> >> >> > > (0,33), >> >> >> > > VC2(33,66),VC3(66,99)) is the right way since it requires to >> >> >> > > have >> >> >> > such >> >> >> > > configuration and it also means that the range is (0,99) while >> >> >> > > it >> >> >> > > may >> >> >> > also >> >> >> > > be covering part of a (-10,110) range. The major requirement i= s >> >> >> > > not >> >> >> > to use >> >> >> > > implied information but be explicit. >> >> >> > > >> >> >> > > [BB] I think I agree that this might be useful, but, I'm not >> >> >> > > sure >> >> >> > we've come >> >> >> > > up with a use case that really demands it yet.=A0 Let me see i= f >> >> >> > > what >> >> >> > > I >> >> >> > have in >> >> >> > > mind for what you described (and why the origin and full range >> >> >> > > up >> >> >> > front >> >> >> > > aren't needed there) makes sense: >> >> >> > > >> >> >> > > I'm not sure what you've described (an advertiser only offerin= g >> >> >> > > a >> >> >> > single >> >> >> > > video capture VC0(0,33)) would be that common (as, like you >> >> >> > > said, >> >> >> > > it >> >> >> > isn't >> >> >> > > very useful) but if it did, I still think the renderer could >> >> >> > > render >> >> >> > it >> >> >> > > sensibly.=A0 Since there are no other captures advertised, the >> >> >> > > renderer >> >> >> > does >> >> >> > > not need to be careful about rendering the VC in a certain >> >> >> > > position >> >> >> > relative >> >> >> > > to other captures from that same device because there are none= . >> >> >> > > In >> >> >> > your >> >> >> > > example: if a 3 camera endpoint only advertised its left camer= a >> >> >> > > as >> >> >> > VC0(0,33) >> >> >> > > a 3 screen endpoint on the other end could render it wherever = it >> >> >> > wanted >> >> >> > > because its main concern (making sure cameras from a >> >> >> > > multi-camera >> >> >> > > transmitter are placed correctly relative to one another) is n= o >> >> >> > longer an >> >> >> > > issue.=A0 Perhaps there is a scenario unlike what I've just >> >> >> > > described >> >> >> > where, >> >> >> > > even though only one small subset of the entire device was >> >> >> > advertised, it >> >> >> > > was important to render it in exactly one place.=A0 Do you kno= w of >> >> >> > > an >> >> >> > example >> >> >> > > where that may be the case? >> >> >> > > >> >> >> > > 2.=A0=A0=A0=A0=A0=A0 I think that it is important not only to = have the X >> >> >> > coordinates but >> >> >> > > also have the Y coordinates to be able to know if there is a g= ap >> >> >> > > or >> >> >> > overlap >> >> >> > > at the relevant distance. Again the origin of the axes is >> >> >> > > crucial >> >> >> > here. >> >> >> > > >> >> >> > > [BB] The document provides for describing the area of capture = in >> >> >> > > up >> >> >> > to 3 >> >> >> > > dimensions(x, y and z); seems like that gives the flexibility >> >> >> > > you're >> >> >> > looking >> >> >> > > for? >> >> >> > > >> >> >> > >> >> >> > Ah, I missed that - it's implicit in 5.2.4. (I searched on >> >> >> > vertical, >> >> >> > which is nowhere mentioned.) Obviously, this could use some >> >> >> > wording >> >> >> > tweaks, which I promised to provide. >> >> >> > >> >> >> > In 5.2.4, I suggest you start with >> >> >> > >> >> >> > The area_of_capture attribute is used to describe the relevant >> >> >> > area >> >> >> > of >> >> >> > which a media capture is "capturing". >> >> >> > Area of capture is expressed as pairs of =A0{x, y, z} coordinate= s to >> >> >> > describe {left to right, front to back, low to high} ranges in >> >> >> > that >> >> >> > order where, as with point_of_capture, only the necessary >> >> >> > dimensions >> >> >> > need be expressed. In other words, it is specified that, as >> >> >> > numbers >> >> >> > move from lower to higher, the location is going from: left to >> >> >> > right >> >> >> > (in the case of the 'x' dimension), front to back (in the case o= f >> >> >> > the >> >> >> > 'y' dimension or low to high (in the case of the 'z' dimension). >> >> >> > >> >> >> > >> >> >> > =A0In 5.2.6. it says >> >> >> > >> >> >> > =A0Area Scale Millimeters >> >> >> > An optional Boolean variable indicating if the numbers used for >> >> >> > area >> >> >> > of capture and point of capture are in terms of millimeters. If >> >> >> > this >> >> >> > attribute is true, then the x,y,z numbers represent millimeters. >> >> >> > If >> >> >> > this attribute is false, then there is no physical scale. The >> >> >> > default >> >> >> > value is false. >> >> >> > >> >> >> > Note that "degrees" are not mentioned anywhere in the document. >> >> >> > Degrees may not be a physical scale, but they are still a scale. >> >> >> > (If >> >> >> > you interpret {0,33} as radians or pixels, you are unlikely to g= et >> >> >> > pleasing results.) There is another issue, as I don't know what >> >> >> > the >> >> >> > equivalent to angles are for front to back. >> >> >> > >> >> >> > I would change " If this attribute is false, then there is no >> >> >> > physical >> >> >> > scale." =A0to >> >> >> > >> >> >> > =A0" If this attribute is false, then the =A0scale for x and z i= s >> >> >> > degrees, >> >> >> > and the scale for y remains mm." >> >> >> > >> >> >> > If you have another default scale for y, you should specify it (= I >> >> >> > can't imagine what it would be.) >> >> >> > >> >> >> > (BTW, I believe that I suggested y being up and down and z being >> >> >> > front >> >> >> > to back, precisely because most people will specify x, fewer >> >> >> > up-down, >> >> >> > and fewest front back distances. If you do that, you have to >> >> >> > switch >> >> >> > the definition of left and right to stage-left and stage-right t= o >> >> >> > keep >> >> >> > a right handed system.) >> >> >> > >> >> >> > In Section 3, it says. >> >> >> > >> >> >> > Left: For media captures, left and right is from the point of vi= ew >> >> >> > of >> >> >> > a person observing the rendered media. >> >> >> > >> >> >> > This is the opposite of stage-left and stage-right, and would be >> >> >> > called camera-left =A0and camera-right in American TV. >> >> >> > >> >> >> > In other words, "left" and "right" are camera-left =A0and >> >> >> > camera-right >> >> >> > in theatrical parlance, and are the opposite of left and right f= or >> >> >> > the >> >> >> > person being observed. >> >> >> > >> >> >> > Actually, I would strongly urge the =A0definition and _explicit_= use >> >> >> > of >> >> >> > camera-left and camera-right (or stage-left and stage-right) =A0= in >> >> >> > EVERY >> >> >> > occurrence of their use. >> >> >> > >> >> >> > If we don't do that, I am willing to bet someone will mess it up= . >> >> >> > >> >> >> > So, if you do this, the definition becomes >> >> >> > >> >> >> > Camera-Left: For media captures, camera-left and camera-right is >> >> >> > from >> >> >> > the point of view of a person observing the rendered media. They >> >> >> > are >> >> >> > the opposite of stage-left and stage-right, which are the left a= nd >> >> >> > right of the person being observed. >> >> >> > >> >> >> > Note also that front and back are not defined. They should be. U= p >> >> >> > and >> >> >> > down I think can go undefined. >> >> >> > >> >> >> > Front. Front is the portion of the room closest to the cameras. = In >> >> >> > going towards back you move away from the cameras. >> >> >> > >> >> >> > >> >> >> > > 3.=A0=A0=A0=A0=A0=A0 I am not sure about the example in sectio= n 7 for the >> >> >> > > active >> >> >> > speaker >> >> >> > > (VC3) "VC3- (the loudest panel stream), encoding group:EG1, >> >> >> > > attributes:purpose=3Dmain;auto-switched:yes; >> >> >> > > area_of_capture=3D{xBegin=3D0, >> >> >> > > xEnd=3D99}". How do you know what is the area of capture you a= re >> >> >> > > really >> >> >> > > getting, my understanding is that it is =A0implied that there = are >> >> >> > VC0,VC1 and >> >> >> > > VC2 and you get one of them. Again, I prefer explicit >> >> >> > > information >> >> >> > > for >> >> >> > this >> >> >> > > case even if it means having at attribute that will specify th= at >> >> >> > > the >> >> >> > switch >> >> >> > > is between VC0, VC1 and VC2 or have it as part of the >> >> >> > > auto-switch >> >> >> > attribute. >> >> >> > > >> >> >> > > [BB] The idea here is that the transmitter is showing you the >> >> >> > > most >> >> >> > > appropriate subset of that range.=A0 You're right the receiver >> >> >> > > doesn't >> >> >> > know >> >> >> > > specifically what's being sent, but, why does it care?=A0 The >> >> >> > > receiver >> >> >> > signed >> >> >> > > up for getting the most relevant stream in that range and that= 's >> >> >> > > what >> >> >> > the >> >> >> > > transmitter will send it.=A0 What do you think the receiver ne= eds >> >> >> > > to >> >> >> > know? >> >> >> > > >> >> >> > >> >> >> > To scale the image appropriately. For example, if VC3 is really >> >> >> > VC1, >> >> >> > that could maybe be shown >> >> >> > in full. If VC3 is really VC0+VC1+VC3 composited together, it >> >> >> > should >> >> >> > be letter boxed. >> >> >> > >> >> >> > I am also nervous about throwing away information when we don't >> >> >> > have >> >> >> > to. >> >> >> > >> >> >> > Regards >> >> >> > Marshall >> >> >> > >> >> >> > > Regards >> >> >> > > Roni >> >> >> _______________________________________________ >> >> >> clue mailing list >> >> >> clue@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/clue >> >> > >> >> > >> >> > _______________________________________________ >> >> > clue mailing list >> >> > clue@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/clue >> >> > >> >> > >> > >> > > > From stephen.botzko@gmail.com Thu Oct 6 15:37:00 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892E521F8457 for ; Thu, 6 Oct 2011 15:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.129 X-Spam-Level: X-Spam-Status: No, score=-4.129 tagged_above=-999 required=5 tests=[AWL=0.869, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2Ii0UqiQdnh for ; Thu, 6 Oct 2011 15:36:44 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2412D21F8CA7 for ; Thu, 6 Oct 2011 15:36:44 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so3345871vcb.31 for ; Thu, 06 Oct 2011 15:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xV74hOKiEdafHn/kwUylGsktbFK3lmMaHxcp0aP8Skg=; b=hQVNk4UxBQBMwsMxJl+cHHO2yx7og/V1wu61PQqx8DImVm0h5J51i1vI6+2/VIUn4O /K27ccnmYM0oqZOamYJUQNR/ntxC+d1+pSXDlRQJVMpdtAelotfN+JUkXJ6wcmxSXP9o QkPiDwq5O7bvg7zYrMmyoblbtbP+aWkm6bzZQ= MIME-Version: 1.0 Received: by 10.52.36.237 with SMTP id t13mr83918vdj.45.1317940794532; Thu, 06 Oct 2011 15:39:54 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Thu, 6 Oct 2011 15:39:54 -0700 (PDT) In-Reply-To: References: <045201cc8324$793a0a90$6bae1fb0$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61CDF41693@CRPMBOXPRD01.polycom.com> Date: Thu, 6 Oct 2011 18:39:54 -0400 Message-ID: From: Stephen Botzko To: Marshall Eubanks Content-Type: multipart/alternative; boundary=20cf30780d00e4a41104aea9000f Cc: "clue@ietf.org" Subject: Re: [clue] Area of capture attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 22:37:00 -0000 --20cf30780d00e4a41104aea9000f Content-Type: text/plain; charset=ISO-8859-1 In-line On Thu, Oct 6, 2011 at 6:13 PM, Marshall Eubanks wrote: > On Thu, Oct 6, 2011 at 3:02 PM, Stephen Botzko > wrote: > > in-line > > > > On Thu, Oct 6, 2011 at 11:24 AM, Marshall Eubanks > > wrote: > >> > >> On Thu, Oct 6, 2011 at 11:09 AM, Stephen Botzko > >> wrote: > >> >>>> > >> > (c) Provide the FOV in degrees and a scale factor (standard length). > >> > >> >>>> > >> > Not sure how that is different from (a); it seems the same to me. > Maybe > >> > we > >> > can discuss next week > >> > > >> > >> a) provide both MM scale and field of view in degrees. > >> > >> I interpreted this as something like > >> > >> area_of_capture for Camera 1 is (0, 33 degrees) OR (0, 245 mm) > > > > [sb] For (a) I meant "AND" not "OR", which would allow the ypoint to be > > computed. That is for a 33 degree field of view, you can compute the > > distance to the plane where the capture is 245 mm wide. > > > > OK, so we are really proposing the same things, and just discussing > the most parsimonious representation. > Yes, I think we are actually pretty close. > > >> > >> I am proposing something like > >> > >> FOV for Camera 1 is > >> area_of_capture={xBegin=0, xEnd=33} > >> point_of_interest=(ypoint="425" , type="Row 1") > > > > [sb] I guess for scale, you are thinking that I should compute the size > of > > the capture at ypoint as (2*425) * arctan (0.5 * (xEnd-xBegin))? For > most > > of our envisioned use cases I need to know scale and adjacency, and not > > FoV. I'd prefer to limit the trig to the rarer scenarios if possible. I > am > > also envisioning bugs related to degrees/radians... > > > > Perhaps more importantly, I think this representation assumes that all > > cameras are co-located. At least, with angular units I do not see how to > > relate xBegin and xEnd of camera 1 with the xBegin and Xend of camera 2 > > unless I assume that the cameras are co-located. > > I don't see how the stating that > > area_of_capture for Camera 1 is (0, 33 degrees) AND (0, 245 mm) > > avoids these issues. > > I believe the xBegin, xEnd framework in MM would avoid them, assuming the distance (ypoint) defined the same plane for all cameras in the scene - which is a plausible assumption in present commercial systems. > > > > BTW, unless I made a math mistake, 245 mm capture width at a distance of > 425 > > mm works out to a 34 degree FoV. If I got this wrong, let me know. > > > > Well, here is another area of fuzziness - are these FOV in mm chords > or circular segments ? I _bet_ that most will interpret FOV in degrees > as circular segments and FOV in mm as chords (those being the easiest > to measure). Now, > > 33 deg = .57596 radians so at a distance of 425 mm this corresponds to > a circular segment of 244.8 mm > and a chord of 241.4 mm > > Is it possible you were calculating using the chord versus the > circular segment ? (I was using the circular segment.) > I calculated the chord (I specified the formula in the earlier post) 34 deg works out to a chord of 245.16... > > At any rate, all of this needs to be very precisely specified, unless > you go to my idea of specifying distances. > > Regards > Marshall > > > > > >> > >> If this is done I would suggest certain specific default "types" - > >> "Row {i}", "Podium {i}", etc. > >> > >> If area of capture is defined in angular units, then point_of_interest > >> can always be in mm. > >> > >> Regards > >> Marshall > >> > >> P.S. In preparing this email I noticed that the point_of_capture > >> _format_ seems to be defined nowhere. > >> I would suggest > >> > >> point_of_capture=(xpoint="15") > >> > >> as a suitable format. > >> > >> > >> > Stephen Botzko > >> > > >> > On Thu, Oct 6, 2011 at 10:57 AM, Marshall Eubanks > >> > wrote: > >> >> > >> >> On Thu, Oct 6, 2011 at 7:20 AM, Stephen Botzko > >> >> > >> >> wrote: > >> >> > In order to get actual-size information with field-of-view in > >> >> > degrees, > >> >> > you > >> >> > need to know the distance from the camera to the first row (which > >> >> > right > >> >> > now > >> >> > is implicit in the mm scale). > >> >> > > >> >> > This suggests a couple of mathematically equivalent alternatives: > >> >> > (a) provide both MM scale and field of view in degrees. If someone > >> >> > needed > >> >> > the distance to the first row, it could be computed. > >> >> > (b) provide MM scale and the distance to the first row. In this > >> >> > combination, field-of-view in degrees can be computed. > >> >> > > >> >> > (b) has an advantage in that it can be extended to include multiple > >> >> > rows. > >> >> > >> >> In a kludgy way (mm means mm, except for the second row, when it > >> >> doesn't). I prefer > >> >> > >> >> (c) Provide the FOV in degrees and a scale factor (standard length). > >> >> > >> >> Is there any reason why this shouldn't be (possibly) included > >> >> for every scene captured, including possibly sub-scene. (In other > >> >> words, how do you determine the distance to the second row without > >> >> information about that scale factor.) > >> >> > >> >> I am also specifically interested in including podium type > situations, > >> >> which are not "rows." > >> >> > >> >> Regards > >> >> Marshall > >> >> > >> >> > >> >> > >> >> > > >> >> > On Wed, Oct 5, 2011 at 5:15 PM, Duckworth, Mark > >> >> > > >> >> > wrote: > >> >> >> > >> >> >> I can see that degrees might be a useful scale for X and Z in > >> >> >> addition > >> >> >> to > >> >> >> millimeters. Maybe it should be tenths of a degree, and use > >> >> >> integers > >> >> >> (no > >> >> >> floating point)? So if we allow that, then we need a way to > >> >> >> indicate > >> >> >> the > >> >> >> scale of area of capture and point of capture numbers which would > be > >> >> >> one of: > >> >> >> none, millimeters, degrees. And I think this scale indication > >> >> >> applies > >> >> >> to an > >> >> >> entire capture set, not individual media captures. Everything in > a > >> >> >> particular capture set must use the same scale. > >> >> >> > >> >> >> When we introduced the area of capture concept, and using a > >> >> >> millimeter > >> >> >> scale, I thought that would eliminate the need for the Video Scale > >> >> >> attribute > >> >> >> we had before. I now think we should bring back a separate Video > >> >> >> Scale > >> >> >> attribute, because the area of capture won't always be enough to > >> >> >> tell > >> >> >> the > >> >> >> scale in terms of how large to render it to make it seem the > >> >> >> appropriate > >> >> >> size at the rendering side. One example is an auto-switched video > >> >> >> capture > >> >> >> that covers 0 to 99 (area of capture), while at any one time it is > >> >> >> only > >> >> >> covering a third of it (video scale), so having a separate video > >> >> >> scale > >> >> >> attribute allows the renderer to scale it accordingly if it wants. > >> >> >> Now > >> >> >> I > >> >> >> wonder if the scale attribute really should be associated with a > >> >> >> video > >> >> >> stream in RTP, rather than with a video capture, because maybe it > >> >> >> should be > >> >> >> more dynamic than capture set advertisements. > >> >> >> > >> >> >> Marshall, your definition of left and right makes good sense to > me. > >> >> >> > >> >> >> Mark Duckworth > >> >> >> > >> >> >> > -----Original Message----- > >> >> >> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >> >> >> > Behalf > >> >> >> > Of > >> >> >> > Marshall Eubanks > >> >> >> > Sent: Wednesday, October 05, 2011 2:44 PM > >> >> >> > To: Brian Baldino (bbaldino) > >> >> >> > Cc: clue@ietf.org > >> >> >> > Subject: Re: [clue] Area of capture attribute > >> >> >> > > >> >> >> > On Wed, Oct 5, 2011 at 1:42 PM, Brian Baldino (bbaldino) > >> >> >> > wrote: > >> >> >> > > Hey Roni, > >> >> >> > > > >> >> >> > > Took my best shot inline. > >> >> >> > > > >> >> >> > > -Brian > >> >> >> > > > >> >> >> > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >> >> >> > > Behalf > >> >> >> > Of Roni > >> >> >> > > Even > >> >> >> > > Sent: Tuesday, October 04, 2011 11:03 PM > >> >> >> > > To: clue@ietf.org > >> >> >> > > Subject: [clue] Area of capture attribute > >> >> >> > > > >> >> >> > > Hi, > >> >> >> > > > >> >> >> > > I read the new revision and I think that this attribute is a > >> >> >> > > good > >> >> >> > starting > >> >> >> > > point to address the discussion on the spatial description. I > >> >> >> > > hope > >> >> >> > that we > >> >> >> > > will be able to finalize the model in the Interim meeting. > >> >> >> > > > >> >> >> > > I started a new thread after seeing the comments from > Christian > >> >> >> > > and > >> >> >> > Mark. > >> >> >> > > > >> >> >> > > I will send more feedback on the draft in a separate email. > >> >> >> > > > >> >> >> > > I think that there is some information missing that will be > >> >> >> > > helpful > >> >> >> > > > >> >> >> > > 1. The position of the origin of the axis and the full > >> >> >> > > range > >> >> >> > of the > >> >> >> > > area is needed probably as a capture set attribute in order to > >> >> >> > understand > >> >> >> > > the view. For example having a VC that says (0,33) does not > >> >> >> > > provide > >> >> >> > enough > >> >> >> > > information to know what part of the room it covers. I do not > >> >> >> > > think > >> >> >> > that > >> >> >> > > saying that there will be one configuration for example (VC1 > >> >> >> > > (0,33), > >> >> >> > > VC2(33,66),VC3(66,99)) is the right way since it requires to > >> >> >> > > have > >> >> >> > such > >> >> >> > > configuration and it also means that the range is (0,99) while > >> >> >> > > it > >> >> >> > > may > >> >> >> > also > >> >> >> > > be covering part of a (-10,110) range. The major requirement > is > >> >> >> > > not > >> >> >> > to use > >> >> >> > > implied information but be explicit. > >> >> >> > > > >> >> >> > > [BB] I think I agree that this might be useful, but, I'm not > >> >> >> > > sure > >> >> >> > we've come > >> >> >> > > up with a use case that really demands it yet. Let me see if > >> >> >> > > what > >> >> >> > > I > >> >> >> > have in > >> >> >> > > mind for what you described (and why the origin and full range > >> >> >> > > up > >> >> >> > front > >> >> >> > > aren't needed there) makes sense: > >> >> >> > > > >> >> >> > > I'm not sure what you've described (an advertiser only > offering > >> >> >> > > a > >> >> >> > single > >> >> >> > > video capture VC0(0,33)) would be that common (as, like you > >> >> >> > > said, > >> >> >> > > it > >> >> >> > isn't > >> >> >> > > very useful) but if it did, I still think the renderer could > >> >> >> > > render > >> >> >> > it > >> >> >> > > sensibly. Since there are no other captures advertised, the > >> >> >> > > renderer > >> >> >> > does > >> >> >> > > not need to be careful about rendering the VC in a certain > >> >> >> > > position > >> >> >> > relative > >> >> >> > > to other captures from that same device because there are > none. > >> >> >> > > In > >> >> >> > your > >> >> >> > > example: if a 3 camera endpoint only advertised its left > camera > >> >> >> > > as > >> >> >> > VC0(0,33) > >> >> >> > > a 3 screen endpoint on the other end could render it wherever > it > >> >> >> > wanted > >> >> >> > > because its main concern (making sure cameras from a > >> >> >> > > multi-camera > >> >> >> > > transmitter are placed correctly relative to one another) is > no > >> >> >> > longer an > >> >> >> > > issue. Perhaps there is a scenario unlike what I've just > >> >> >> > > described > >> >> >> > where, > >> >> >> > > even though only one small subset of the entire device was > >> >> >> > advertised, it > >> >> >> > > was important to render it in exactly one place. Do you know > of > >> >> >> > > an > >> >> >> > example > >> >> >> > > where that may be the case? > >> >> >> > > > >> >> >> > > 2. I think that it is important not only to have the X > >> >> >> > coordinates but > >> >> >> > > also have the Y coordinates to be able to know if there is a > gap > >> >> >> > > or > >> >> >> > overlap > >> >> >> > > at the relevant distance. Again the origin of the axes is > >> >> >> > > crucial > >> >> >> > here. > >> >> >> > > > >> >> >> > > [BB] The document provides for describing the area of capture > in > >> >> >> > > up > >> >> >> > to 3 > >> >> >> > > dimensions(x, y and z); seems like that gives the flexibility > >> >> >> > > you're > >> >> >> > looking > >> >> >> > > for? > >> >> >> > > > >> >> >> > > >> >> >> > Ah, I missed that - it's implicit in 5.2.4. (I searched on > >> >> >> > vertical, > >> >> >> > which is nowhere mentioned.) Obviously, this could use some > >> >> >> > wording > >> >> >> > tweaks, which I promised to provide. > >> >> >> > > >> >> >> > In 5.2.4, I suggest you start with > >> >> >> > > >> >> >> > The area_of_capture attribute is used to describe the relevant > >> >> >> > area > >> >> >> > of > >> >> >> > which a media capture is "capturing". > >> >> >> > Area of capture is expressed as pairs of {x, y, z} coordinates > to > >> >> >> > describe {left to right, front to back, low to high} ranges in > >> >> >> > that > >> >> >> > order where, as with point_of_capture, only the necessary > >> >> >> > dimensions > >> >> >> > need be expressed. In other words, it is specified that, as > >> >> >> > numbers > >> >> >> > move from lower to higher, the location is going from: left to > >> >> >> > right > >> >> >> > (in the case of the 'x' dimension), front to back (in the case > of > >> >> >> > the > >> >> >> > 'y' dimension or low to high (in the case of the 'z' dimension). > >> >> >> > > >> >> >> > > >> >> >> > In 5.2.6. it says > >> >> >> > > >> >> >> > Area Scale Millimeters > >> >> >> > An optional Boolean variable indicating if the numbers used for > >> >> >> > area > >> >> >> > of capture and point of capture are in terms of millimeters. If > >> >> >> > this > >> >> >> > attribute is true, then the x,y,z numbers represent millimeters. > >> >> >> > If > >> >> >> > this attribute is false, then there is no physical scale. The > >> >> >> > default > >> >> >> > value is false. > >> >> >> > > >> >> >> > Note that "degrees" are not mentioned anywhere in the document. > >> >> >> > Degrees may not be a physical scale, but they are still a scale. > >> >> >> > (If > >> >> >> > you interpret {0,33} as radians or pixels, you are unlikely to > get > >> >> >> > pleasing results.) There is another issue, as I don't know what > >> >> >> > the > >> >> >> > equivalent to angles are for front to back. > >> >> >> > > >> >> >> > I would change " If this attribute is false, then there is no > >> >> >> > physical > >> >> >> > scale." to > >> >> >> > > >> >> >> > " If this attribute is false, then the scale for x and z is > >> >> >> > degrees, > >> >> >> > and the scale for y remains mm." > >> >> >> > > >> >> >> > If you have another default scale for y, you should specify it > (I > >> >> >> > can't imagine what it would be.) > >> >> >> > > >> >> >> > (BTW, I believe that I suggested y being up and down and z being > >> >> >> > front > >> >> >> > to back, precisely because most people will specify x, fewer > >> >> >> > up-down, > >> >> >> > and fewest front back distances. If you do that, you have to > >> >> >> > switch > >> >> >> > the definition of left and right to stage-left and stage-right > to > >> >> >> > keep > >> >> >> > a right handed system.) > >> >> >> > > >> >> >> > In Section 3, it says. > >> >> >> > > >> >> >> > Left: For media captures, left and right is from the point of > view > >> >> >> > of > >> >> >> > a person observing the rendered media. > >> >> >> > > >> >> >> > This is the opposite of stage-left and stage-right, and would be > >> >> >> > called camera-left and camera-right in American TV. > >> >> >> > > >> >> >> > In other words, "left" and "right" are camera-left and > >> >> >> > camera-right > >> >> >> > in theatrical parlance, and are the opposite of left and right > for > >> >> >> > the > >> >> >> > person being observed. > >> >> >> > > >> >> >> > Actually, I would strongly urge the definition and _explicit_ > use > >> >> >> > of > >> >> >> > camera-left and camera-right (or stage-left and stage-right) in > >> >> >> > EVERY > >> >> >> > occurrence of their use. > >> >> >> > > >> >> >> > If we don't do that, I am willing to bet someone will mess it > up. > >> >> >> > > >> >> >> > So, if you do this, the definition becomes > >> >> >> > > >> >> >> > Camera-Left: For media captures, camera-left and camera-right is > >> >> >> > from > >> >> >> > the point of view of a person observing the rendered media. They > >> >> >> > are > >> >> >> > the opposite of stage-left and stage-right, which are the left > and > >> >> >> > right of the person being observed. > >> >> >> > > >> >> >> > Note also that front and back are not defined. They should be. > Up > >> >> >> > and > >> >> >> > down I think can go undefined. > >> >> >> > > >> >> >> > Front. Front is the portion of the room closest to the cameras. > In > >> >> >> > going towards back you move away from the cameras. > >> >> >> > > >> >> >> > > >> >> >> > > 3. I am not sure about the example in section 7 for the > >> >> >> > > active > >> >> >> > speaker > >> >> >> > > (VC3) "VC3- (the loudest panel stream), encoding group:EG1, > >> >> >> > > attributes:purpose=main;auto-switched:yes; > >> >> >> > > area_of_capture={xBegin=0, > >> >> >> > > xEnd=99}". How do you know what is the area of capture you are > >> >> >> > > really > >> >> >> > > getting, my understanding is that it is implied that there > are > >> >> >> > VC0,VC1 and > >> >> >> > > VC2 and you get one of them. Again, I prefer explicit > >> >> >> > > information > >> >> >> > > for > >> >> >> > this > >> >> >> > > case even if it means having at attribute that will specify > that > >> >> >> > > the > >> >> >> > switch > >> >> >> > > is between VC0, VC1 and VC2 or have it as part of the > >> >> >> > > auto-switch > >> >> >> > attribute. > >> >> >> > > > >> >> >> > > [BB] The idea here is that the transmitter is showing you the > >> >> >> > > most > >> >> >> > > appropriate subset of that range. You're right the receiver > >> >> >> > > doesn't > >> >> >> > know > >> >> >> > > specifically what's being sent, but, why does it care? The > >> >> >> > > receiver > >> >> >> > signed > >> >> >> > > up for getting the most relevant stream in that range and > that's > >> >> >> > > what > >> >> >> > the > >> >> >> > > transmitter will send it. What do you think the receiver > needs > >> >> >> > > to > >> >> >> > know? > >> >> >> > > > >> >> >> > > >> >> >> > To scale the image appropriately. For example, if VC3 is really > >> >> >> > VC1, > >> >> >> > that could maybe be shown > >> >> >> > in full. If VC3 is really VC0+VC1+VC3 composited together, it > >> >> >> > should > >> >> >> > be letter boxed. > >> >> >> > > >> >> >> > I am also nervous about throwing away information when we don't > >> >> >> > have > >> >> >> > to. > >> >> >> > > >> >> >> > Regards > >> >> >> > Marshall > >> >> >> > > >> >> >> > > Regards > >> >> >> > > Roni > >> >> >> _______________________________________________ > >> >> >> clue mailing list > >> >> >> clue@ietf.org > >> >> >> https://www.ietf.org/mailman/listinfo/clue > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > clue mailing list > >> >> > clue@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/clue > >> >> > > >> >> > > >> > > >> > > > > > > --20cf30780d00e4a41104aea9000f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In-line

On Thu, Oct 6, 2011 at 6:13 PM, M= arshall Eubanks <marshall.eubanks@gmail.com> wrote:
On Thu, Oct 6, 2011 at 3:02 PM, Stephen Botzko <stephen.botzko@gmail.com> wrot= e:
> in-line
>
> On Thu, Oct 6, 2011 at 11:24 AM, Marshall Eubanks
> <marshall.eubanks@gma= il.com> wrote:
>>
>> On Thu, Oct 6, 2011 at 11:09 AM, Stephen Botzko
>> <stephen.botzko@gma= il.com> wrote:
>> >>>>
>> > (c) Provide the FOV in degrees and a scale factor (standard l= ength).
>>
>> >>>>
>> > Not sure how that is different from (a); it seems the same to= me.=A0 Maybe
>> > we
>> > can discuss next week
>> >
>>
>> a) provide both MM scale and field of view in degrees.
>>
>> I interpreted this as something like
>>
>> area_of_capture =A0for Camera 1 is (0, 33 degrees) OR (0, 245 mm)<= br> >
> [sb] For (a) I meant "AND" not "OR", which would a= llow the ypoint to be
> computed.=A0 That is for a 33 degree field of view, you can compute th= e
> distance to the plane where the capture is 245 mm wide.
>

OK, so we are really proposing the same things, and just discussing the most parsimonious representation.
=A0
Ye= s, I think we are actually pretty close.

>>
>> I am proposing something like
>>
>> FOV for Camera 1 is
>> area_of_capture=3D{xBegin=3D0, xEnd=3D33}
>> point_of_interest=3D(ypoint=3D"425" , type=3D"Row 1= ")
>
> [sb] I guess for scale, you are thinking that I should compute the siz= e of
> the capture at ypoint as (2*425) * arctan (0.5 * (xEnd-xBegin))?=A0 Fo= r most
> of our envisioned use cases I need to know scale and adjacency, and no= t
> FoV.=A0 I'd prefer to limit the trig to the rarer scenarios if pos= sible.=A0 I am
> also envisioning bugs related to degrees/radians...
>
> Perhaps more importantly, I think this representation assumes that all=
> cameras are co-located.=A0 At least, with angular units I do not see h= ow to
> relate xBegin and xEnd of camera 1 with the xBegin and Xend of camera = 2
> unless I assume that the cameras are co-located.

I don't see how the stating that

area_of_capture =A0for Camera 1 is (0, 33 degrees) AND (0, 245 mm)

avoids these issues.

I believe the xBegin, xEnd fr= amework in MM would avoid them, assuming the distance (ypoint) defined the = same plane for all cameras in the scene - which is a plausible assumption i= n present commercial systems.
>
> BTW, unless I made a math mistake, 245 mm capture width at a distance = of 425
> mm works out to a 34 degree FoV.=A0 If I got this wrong, let me know.<= br> >

Well, here is another area of fuzziness - are these FOV in mm chords<= br> or circular segments ? I _bet_ that most will interpret FOV in degrees
as circular segments and FOV in mm as chords (those being the easiest
to measure). Now,

33 deg =3D .57596 radians so at a distance of 425 mm this corresponds to a circular segment of 244.8 mm
and a chord of 241.4 mm

Is it possible you were calculating using the chord versus the
circular segment ? (I was using the circular segment.)
I calculated the chord (I specified the formula in the earlier post)=A0 34= deg works out to a chord of 245.16...

At any rate, all of this needs to be very precisely specified, unless
you go to my idea of specifying distances.=A0

Regards
Marshall


>
>>
>> If this is done I would suggest certain specific default "typ= es" -
>> "Row {i}", "Podium {i}", etc.
>>
>> If area of capture is defined in angular units, then point_of_inte= rest
>> can always be in mm.
>>
>> Regards
>> Marshall
>>
>> P.S. In preparing this email I noticed that the point_of_capture >> _format_ seems to be defined nowhere.
>> I would suggest
>>
>> point_of_capture=3D(xpoint=3D"15")
>>
>> as a suitable format.
>>
>>
>> > Stephen Botzko
>> >
>> > On Thu, Oct 6, 2011 at 10:57 AM, Marshall Eubanks
>> > <marshall.eu= banks@gmail.com> wrote:
>> >>
>> >> On Thu, Oct 6, 2011 at 7:20 AM, Stephen Botzko
>> >> <stephen.b= otzko@gmail.com>
>> >> wrote:
>> >> > In order to get actual-size information with field-o= f-view in
>> >> > degrees,
>> >> > you
>> >> > need to know the distance from the camera to the fir= st row (which
>> >> > right
>> >> > now
>> >> > is implicit in the mm scale).
>> >> >
>> >> > This suggests a couple of mathematically equivalent = alternatives:
>> >> > (a) provide both MM scale and field of view in degre= es.=A0 If someone
>> >> > needed
>> >> > the distance to the first row, it could be computed.=
>> >> > (b) provide MM scale and the distance to the first r= ow.=A0 In this
>> >> > combination, field-of-view in degrees can be compute= d.
>> >> >
>> >> > (b) has an advantage in that it can be extended to i= nclude multiple
>> >> > rows.
>> >>
>> >> In a kludgy way (mm means mm, except for the second row, = when it
>> >> doesn't). I prefer
>> >>
>> >> (c) Provide the FOV in degrees and a scale factor (standa= rd length).
>> >>
>> >> Is there any reason why this shouldn't be (possibly) = included
>> >> for every scene captured, including possibly sub-scene. (= In other
>> >> words, how do you determine the distance to the second ro= w without
>> >> information about that scale factor.)
>> >>
>> >> I am also specifically interested in including podium typ= e situations,
>> >> which are not "rows."
>> >>
>> >> Regards
>> >> Marshall
>> >>
>> >>
>> >>
>> >> >
>> >> > On Wed, Oct 5, 2011 at 5:15 PM, Duckworth, Mark
>> >> > <Ma= rk.Duckworth@polycom.com>
>> >> > wrote:
>> >> >>
>> >> >> I can see that degrees might be a useful scale f= or X and Z in
>> >> >> addition
>> >> >> to
>> >> >> millimeters. =A0Maybe it should be tenths of a d= egree, and use
>> >> >> integers
>> >> >> (no
>> >> >> floating point)? =A0So if we allow that, then we= need a way to
>> >> >> indicate
>> >> >> the
>> >> >> scale of area of capture and point of capture nu= mbers which would be
>> >> >> one of:
>> >> >> none, millimeters, degrees. =A0And I think this = scale indication
>> >> >> applies
>> >> >> to an
>> >> >> entire capture set, not individual media capture= s. =A0Everything in a
>> >> >> particular capture set must use the same scale.<= br> >> >> >>
>> >> >> When we introduced the area of capture concept, = and using a
>> >> >> millimeter
>> >> >> scale, I thought that would eliminate the need f= or the Video Scale
>> >> >> attribute
>> >> >> we had before. =A0I now think we should bring ba= ck a separate Video
>> >> >> Scale
>> >> >> attribute, because the area of capture won't= always be enough to
>> >> >> tell
>> >> >> the
>> >> >> scale in terms of how large to render it to make= it seem the
>> >> >> appropriate
>> >> >> size at the rendering side. =A0One example is an= auto-switched video
>> >> >> capture
>> >> >> that covers 0 to 99 (area of capture), while at = any one time it is
>> >> >> only
>> >> >> covering a third of it (video scale), so having = a separate video
>> >> >> scale
>> >> >> attribute allows the renderer to scale it accord= ingly if it wants.
>> >> >> =A0Now
>> >> >> I
>> >> >> wonder if the scale attribute really should be a= ssociated with a
>> >> >> video
>> >> >> stream in RTP, rather than with a video capture,= because maybe it
>> >> >> should be
>> >> >> more dynamic than capture set advertisements. >> >> >>
>> >> >> Marshall, your definition of left and right make= s good sense to me.
>> >> >>
>> >> >> Mark Duckworth
>> >> >>
>> >> >> > -----Original Message-----
>> >> >> > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On
>> >> >> > Behalf
>> >> >> > Of
>> >> >> > Marshall Eubanks
>> >> >> > Sent: Wednesday, October 05, 2011 2:44 PM >> >> >> > To: Brian Baldino (bbaldino)
>> >> >> > Cc: clue@i= etf.org
>> >> >> > Subject: Re: [clue] Area of capture attribu= te
>> >> >> >
>> >> >> > On Wed, Oct 5, 2011 at 1:42 PM, Brian Baldi= no (bbaldino)
>> >> >> > <b= baldino@cisco.com> wrote:
>> >> >> > > Hey Roni,
>> >> >> > >
>> >> >> > > Took my best shot inline.
>> >> >> > >
>> >> >> > > -Brian
>> >> >> > >
>> >> >> > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On
>> >> >> > > Behalf
>> >> >> > Of Roni
>> >> >> > > Even
>> >> >> > > Sent: Tuesday, October 04, 2011 11:03 = PM
>> >> >> > > To: c= lue@ietf.org
>> >> >> > > Subject: [clue] Area of capture attrib= ute
>> >> >> > >
>> >> >> > > Hi,
>> >> >> > >
>> >> >> > > I read the new revision and I think th= at this attribute is a
>> >> >> > > good
>> >> >> > starting
>> >> >> > > point to address the discussion on the= spatial description. I
>> >> >> > > hope
>> >> >> > that we
>> >> >> > > will be able to finalize the model in = the Interim meeting.
>> >> >> > >
>> >> >> > > I started a new thread after seeing th= e comments from Christian
>> >> >> > > and
>> >> >> > Mark.
>> >> >> > >
>> >> >> > > I will send more feedback on the draft= in a separate email.
>> >> >> > >
>> >> >> > > I think that there is some information= missing that will be
>> >> >> > > helpful
>> >> >> > >
>> >> >> > > 1.=A0=A0=A0=A0=A0=A0 The position of t= he origin of the axis =A0and the full
>> >> >> > > range
>> >> >> > of the
>> >> >> > > area is needed probably as a capture s= et attribute in order to
>> >> >> > understand
>> >> >> > > the view. For example having a VC that= says (0,33) does not
>> >> >> > > provide
>> >> >> > enough
>> >> >> > > information to know what part of the r= oom it covers. I do not
>> >> >> > > think
>> >> >> > that
>> >> >> > > saying that there will be one configur= ation for example (VC1
>> >> >> > > (0,33),
>> >> >> > > VC2(33,66),VC3(66,99)) is the right wa= y since it requires to
>> >> >> > > have
>> >> >> > such
>> >> >> > > configuration and it also means that t= he range is (0,99) while
>> >> >> > > it
>> >> >> > > may
>> >> >> > also
>> >> >> > > be covering part of a (-10,110) range.= The major requirement is
>> >> >> > > not
>> >> >> > to use
>> >> >> > > implied information but be explicit. >> >> >> > >
>> >> >> > > [BB] I think I agree that this might b= e useful, but, I'm not
>> >> >> > > sure
>> >> >> > we've come
>> >> >> > > up with a use case that really demands= it yet.=A0 Let me see if
>> >> >> > > what
>> >> >> > > I
>> >> >> > have in
>> >> >> > > mind for what you described (and why t= he origin and full range
>> >> >> > > up
>> >> >> > front
>> >> >> > > aren't needed there) makes sense:<= br> >> >> >> > >
>> >> >> > > I'm not sure what you've descr= ibed (an advertiser only offering
>> >> >> > > a
>> >> >> > single
>> >> >> > > video capture VC0(0,33)) would be that= common (as, like you
>> >> >> > > said,
>> >> >> > > it
>> >> >> > isn't
>> >> >> > > very useful) but if it did, I still th= ink the renderer could
>> >> >> > > render
>> >> >> > it
>> >> >> > > sensibly.=A0 Since there are no other = captures advertised, the
>> >> >> > > renderer
>> >> >> > does
>> >> >> > > not need to be careful about rendering= the VC in a certain
>> >> >> > > position
>> >> >> > relative
>> >> >> > > to other captures from that same devic= e because there are none.
>> >> >> > > In
>> >> >> > your
>> >> >> > > example: if a 3 camera endpoint only a= dvertised its left camera
>> >> >> > > as
>> >> >> > VC0(0,33)
>> >> >> > > a 3 screen endpoint on the other end c= ould render it wherever it
>> >> >> > wanted
>> >> >> > > because its main concern (making sure = cameras from a
>> >> >> > > multi-camera
>> >> >> > > transmitter are placed correctly relat= ive to one another) is no
>> >> >> > longer an
>> >> >> > > issue.=A0 Perhaps there is a scenario = unlike what I've just
>> >> >> > > described
>> >> >> > where,
>> >> >> > > even though only one small subset of t= he entire device was
>> >> >> > advertised, it
>> >> >> > > was important to render it in exactly = one place.=A0 Do you know of
>> >> >> > > an
>> >> >> > example
>> >> >> > > where that may be the case?
>> >> >> > >
>> >> >> > > 2.=A0=A0=A0=A0=A0=A0 I think that it i= s important not only to have the X
>> >> >> > coordinates but
>> >> >> > > also have the Y coordinates to be able= to know if there is a gap
>> >> >> > > or
>> >> >> > overlap
>> >> >> > > at the relevant distance. Again the or= igin of the axes is
>> >> >> > > crucial
>> >> >> > here.
>> >> >> > >
>> >> >> > > [BB] The document provides for describ= ing the area of capture in
>> >> >> > > up
>> >> >> > to 3
>> >> >> > > dimensions(x, y and z); seems like tha= t gives the flexibility
>> >> >> > > you're
>> >> >> > looking
>> >> >> > > for?
>> >> >> > >
>> >> >> >
>> >> >> > Ah, I missed that - it's implicit in 5.= 2.4. (I searched on
>> >> >> > vertical,
>> >> >> > which is nowhere mentioned.) Obviously, thi= s could use some
>> >> >> > wording
>> >> >> > tweaks, which I promised to provide.
>> >> >> >
>> >> >> > In 5.2.4, I suggest you start with
>> >> >> >
>> >> >> > The area_of_capture attribute is used to de= scribe the relevant
>> >> >> > area
>> >> >> > of
>> >> >> > which a media capture is "capturing&qu= ot;.
>> >> >> > Area of capture is expressed as pairs of = =A0{x, y, z} coordinates to
>> >> >> > describe {left to right, front to back, low= to high} ranges in
>> >> >> > that
>> >> >> > order where, as with point_of_capture, only= the necessary
>> >> >> > dimensions
>> >> >> > need be expressed. In other words, it is sp= ecified that, as
>> >> >> > numbers
>> >> >> > move from lower to higher, the location is = going from: left to
>> >> >> > right
>> >> >> > (in the case of the 'x' dimension),= front to back (in the case of
>> >> >> > the
>> >> >> > 'y' dimension or low to high (in th= e case of the 'z' dimension).
>> >> >> >
>> >> >> >
>> >> >> > =A0In 5.2.6. it says
>> >> >> >
>> >> >> > =A0Area Scale Millimeters
>> >> >> > An optional Boolean variable indicating if = the numbers used for
>> >> >> > area
>> >> >> > of capture and point of capture are in term= s of millimeters. If
>> >> >> > this
>> >> >> > attribute is true, then the x,y,z numbers r= epresent millimeters.
>> >> >> > If
>> >> >> > this attribute is false, then there is no p= hysical scale. The
>> >> >> > default
>> >> >> > value is false.
>> >> >> >
>> >> >> > Note that "degrees" are not menti= oned anywhere in the document.
>> >> >> > Degrees may not be a physical scale, but th= ey are still a scale.
>> >> >> > (If
>> >> >> > you interpret {0,33} as radians or pixels, = you are unlikely to get
>> >> >> > pleasing results.) There is another issue, = as I don't know what
>> >> >> > the
>> >> >> > equivalent to angles are for front to back.=
>> >> >> >
>> >> >> > I would change " If this attribute is = false, then there is no
>> >> >> > physical
>> >> >> > scale." =A0to
>> >> >> >
>> >> >> > =A0" If this attribute is false, then = the =A0scale for x and z is
>> >> >> > degrees,
>> >> >> > and the scale for y remains mm."
>> >> >> >
>> >> >> > If you have another default scale for y, yo= u should specify it (I
>> >> >> > can't imagine what it would be.)
>> >> >> >
>> >> >> > (BTW, I believe that I suggested y being up= and down and z being
>> >> >> > front
>> >> >> > to back, precisely because most people will= specify x, fewer
>> >> >> > up-down,
>> >> >> > and fewest front back distances. If you do = that, you have to
>> >> >> > switch
>> >> >> > the definition of left and right to stage-l= eft and stage-right to
>> >> >> > keep
>> >> >> > a right handed system.)
>> >> >> >
>> >> >> > In Section 3, it says.
>> >> >> >
>> >> >> > Left: For media captures, left and right is= from the point of view
>> >> >> > of
>> >> >> > a person observing the rendered media.
>> >> >> >
>> >> >> > This is the opposite of stage-left and stag= e-right, and would be
>> >> >> > called camera-left =A0and camera-right in A= merican TV.
>> >> >> >
>> >> >> > In other words, "left" and "= right" are camera-left =A0and
>> >> >> > camera-right
>> >> >> > in theatrical parlance, and are the opposit= e of left and right for
>> >> >> > the
>> >> >> > person being observed.
>> >> >> >
>> >> >> > Actually, I would strongly urge the =A0defi= nition and _explicit_ use
>> >> >> > of
>> >> >> > camera-left and camera-right (or stage-left= and stage-right) =A0in
>> >> >> > EVERY
>> >> >> > occurrence of their use.
>> >> >> >
>> >> >> > If we don't do that, I am willing to be= t someone will mess it up.
>> >> >> >
>> >> >> > So, if you do this, the definition becomes<= br> >> >> >> >
>> >> >> > Camera-Left: For media captures, camera-lef= t and camera-right is
>> >> >> > from
>> >> >> > the point of view of a person observing the= rendered media. They
>> >> >> > are
>> >> >> > the opposite of stage-left and stage-right,= which are the left and
>> >> >> > right of the person being observed.
>> >> >> >
>> >> >> > Note also that front and back are not defin= ed. They should be. Up
>> >> >> > and
>> >> >> > down I think can go undefined.
>> >> >> >
>> >> >> > Front. Front is the portion of the room clo= sest to the cameras. In
>> >> >> > going towards back you move away from the c= ameras.
>> >> >> >
>> >> >> >
>> >> >> > > 3.=A0=A0=A0=A0=A0=A0 I am not sure abo= ut the example in section 7 for the
>> >> >> > > active
>> >> >> > speaker
>> >> >> > > (VC3) "VC3- (the loudest panel st= ream), encoding group:EG1,
>> >> >> > > attributes:purpose=3Dmain;auto-switche= d:yes;
>> >> >> > > area_of_capture=3D{xBegin=3D0,
>> >> >> > > xEnd=3D99}". How do you know what= is the area of capture you are
>> >> >> > > really
>> >> >> > > getting, my understanding is that it i= s =A0implied that there are
>> >> >> > VC0,VC1 and
>> >> >> > > VC2 and you get one of them. Again, I = prefer explicit
>> >> >> > > information
>> >> >> > > for
>> >> >> > this
>> >> >> > > case even if it means having at attrib= ute that will specify that
>> >> >> > > the
>> >> >> > switch
>> >> >> > > is between VC0, VC1 and VC2 or have it= as part of the
>> >> >> > > auto-switch
>> >> >> > attribute.
>> >> >> > >
>> >> >> > > [BB] The idea here is that the transmi= tter is showing you the
>> >> >> > > most
>> >> >> > > appropriate subset of that range.=A0 Y= ou're right the receiver
>> >> >> > > doesn't
>> >> >> > know
>> >> >> > > specifically what's being sent, bu= t, why does it care?=A0 The
>> >> >> > > receiver
>> >> >> > signed
>> >> >> > > up for getting the most relevant strea= m in that range and that's
>> >> >> > > what
>> >> >> > the
>> >> >> > > transmitter will send it.=A0 What do y= ou think the receiver needs
>> >> >> > > to
>> >> >> > know?
>> >> >> > >
>> >> >> >
>> >> >> > To scale the image appropriately. For examp= le, if VC3 is really
>> >> >> > VC1,
>> >> >> > that could maybe be shown
>> >> >> > in full. If VC3 is really VC0+VC1+VC3 compo= sited together, it
>> >> >> > should
>> >> >> > be letter boxed.
>> >> >> >
>> >> >> > I am also nervous about throwing away infor= mation when we don't
>> >> >> > have
>> >> >> > to.
>> >> >> >
>> >> >> > Regards
>> >> >> > Marshall
>> >> >> >
>> >> >> > > Regards
>> >> >> > > Roni
>> >> >> _______________________________________________<= br> >> >> >> clue mailing list
>> >> >> clue@ietf.org
>> >> >> https://www.ietf.org/mailman/listinfo/clue
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > clue mailing list
>> >> > clue@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/clue
>> >> >
>> >> >
>> >
>> >
>
>

--20cf30780d00e4a41104aea9000f-- From allyn@cisco.com Thu Oct 6 15:39:27 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B143A21F8B6E for ; Thu, 6 Oct 2011 15:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.804 X-Spam-Level: X-Spam-Status: No, score=-2.804 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylEopOQmC-eZ for ; Thu, 6 Oct 2011 15:39:27 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 21BB721F8AFD for ; Thu, 6 Oct 2011 15:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=2506; q=dns/txt; s=iport; t=1317940959; x=1319150559; h=mime-version:subject:date:message-id:from:to; bh=9mT88Jh56CiHtSdX08CrfkMEIMgjE6iDAVwnD80SWLY=; b=RGNqTDEw5xCU9rTlfRac7wRU3N2PNO0AC2nlePbe2Rrt6wKg1kD3Tw+V JnMVt7GU7tqXbO4p1RKfV7WlUVSVvfunE/bJzz8bugsWjbx9Sh3AcmdlC ps2WWjKi1lb9vb1NL+XC1DVQyDaBTzodQvmunVCracbLw09riaMEe1cf2 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngGAL0ujk6rRDoG/2dsb2JhbABCgk2XEoc0hyWBBYFVAQQSAQkRA1sBDB4GGAdXAQQbGqBFgSYBngqGS2EEh32RIow1 X-IronPort-AV: E=Sophos;i="4.68,499,1312156800"; d="scan'208,217";a="6386117" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 06 Oct 2011 22:42:34 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p96MgY00021471 for ; Thu, 6 Oct 2011 22:42:34 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Oct 2011 15:42:34 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8479.3DA05D20" Date: Thu, 6 Oct 2011 15:42:34 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C85189@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: interim meeting-- Requirements doc Thread-Index: AcyEeT1pPM+31/UZQFWlIxcTTnA5lg== From: "Allyn Romanow (allyn)" To: X-OriginalArrivalTime: 06 Oct 2011 22:42:34.0730 (UTC) FILETIME=[3DA90CA0:01CC8479] Subject: [clue] interim meeting-- Requirements doc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 22:39:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8479.3DA05D20 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Folks, Are there issues that people would like to discuss about the requirements doc at the interim meeting next week? =20 Thanks, Allyn ------_=_NextPart_001_01CC8479.3DA05D20 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Folks,

Are there issues that people would like to discuss = about the requirements doc at the interim meeting next week?

 

Thanks,

Allyn

------_=_NextPart_001_01CC8479.3DA05D20-- From Christian.Groves@nteczone.com Thu Oct 6 19:42:32 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02A921F8888 for ; Thu, 6 Oct 2011 19:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfsMcFxgFb6d for ; Thu, 6 Oct 2011 19:42:32 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by ietfa.amsl.com (Postfix) with ESMTP id 6382F21F8ABB for ; Thu, 6 Oct 2011 19:42:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0AAIJmjk520aDu/2dsb2JhbAAMN5kekXQBAQEEAQEBNRsbBAUBAQwECxEEAQEBCRYIBwkDAgECARUfCAEIBg0BBQIBAYgBuEoDhywEpUg Received: from ppp118-209-160-238.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.160.238]) by ipmail06.adl2.internode.on.net with ESMTP; 07 Oct 2011 13:15:40 +1030 Message-ID: <4E8E67C6.7030603@nteczone.com> Date: Fri, 07 Oct 2011 13:45:26 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Duckworth, Mark" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05B7DE73@xmb-sjc-221.amer.cisco.com> <4E8A77E1.1090608@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A61CDF40F79@CRPMBOXPRD01.polycom.com> <4E8BD034.40300@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A61CDF41621@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61CDF41621@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-framework-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 02:42:32 -0000 Hello Mark, Paul Kyzivat's latest email highlights the situation I was thinking about. Whilst the producer only produces one stream it would be advantageous to know how this stream fits into the producers overall system. If the producer sent VC0- (the left camera stream), area_of_capture={xBegin=0, xEnd=33}, a 3 display consumer may assume that 0-33 represents the entire field of view and place the stream in the centre position when instead it would be more appropriate on the left screen. I think it would be good if the producer could send the capture range for the capture set rather than trying to deduce the range from the individual captures. Currently we only have individual capture attributes, perhaps we need to introduce attributes associated with the capture set? capture area range could be one. Range format (depending on what is decided): i.e. metric, degrees, relational could be another one. Regards, Christian On 6/10/2011 7:16 AM, Duckworth, Mark wrote: >> -----Original Message----- >> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >> Sent: Tuesday, October 04, 2011 11:34 PM >> To: Duckworth, Mark >> Cc: clue@ietf.org >> Subject: Re: [clue] FW: New Version Notification for draft-romanow- >> clue-framework-01.txt >> > ..snip.. >>>> 5.2.4 - Do we need to consider the range start and end when determining >>>> the area of capture? Consider the example Capture Scene(VC0,VC1,VC2) >>>> where: >>>> o VC0- (the left camera stream), area_of_capture={xBegin=0, xEnd=33} >>>> o VC1- (the center camera stream), area_of_capture={xBegin=33, xEnd=66} >>>> o VC2- (the right camera stream), area_of_capture={xBegin=66, xEnd=99} >>>> This example is clear each capture relates to 1/3 of the overall >>>> capture scene. >>>> >>>> Now if instead the capture scene (VC1) was sent. How does the renderer >>>> put this in context? VC1 is the center capture (thus only 1/3 of the >>>> providers overall capability). The renderer will receieve xBegin=33 and >>>> xEnd=66 only and thus conclude its 100% of the capture scene. Do we need >>>> a means to indicate that the total area is 0 to 99 but the current >>>> capture only relates to a subset? >>> [Duckworth, Mark] I don't think the renderer will reach that >> conclusion. The immediate consumer will know about the whole range 0 >> to 99 from the capture set. If the immediate consumer is also the >> renderer, then the renderer knows. If the immediate consumer is a >> middlebox, then that middlebox becomes the provider for the next >> consumer (renderer). The middlebox constructs its own media captures >> and capture set with its own area of capture attributes. These >> attributes may or may not be the same as from the original providers. >> The middlebox advertises captures and a capture set with attributes >> that make sense for whatever behavior the middlebox is trying to >> provide. So the ultimate consumer (the renderer) will know about >> attributes that make sense in this context from the middlebox. This >> consumer doesn't know about any of the attributes from the original >> producer, it only knows the attributes from the middle box. >> [CNG] I think I wasn't clear in my example. What happens if the received >> capture set only contains VC1 and the consumer didn't previously get a >> capture set (VC0,VC1,VC2)? The middlebox, consumer etc. wouldn't know >> that "area_of_capture={xBegin=33,xEnd=66}" represents the centre region >> of a range (0..99). > [Duckworth, Mark] I still don't understand the case you are asking about. Are you saying a media producer advertises a capture set with only VC1 with an area of capture from 33 to 66? No other video captures? If a media producer wants to do this, send only one stream, for some reason, then what does it matter what the area of capture is? There is nothing else to relate it to, so it doesn't matter. > > Regards, > Mark > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Thu Oct 6 19:57:13 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535A921F85B8 for ; Thu, 6 Oct 2011 19:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pc-QuE0ubFx1 for ; Thu, 6 Oct 2011 19:57:12 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by ietfa.amsl.com (Postfix) with ESMTP id 50FB521F85AA for ; Thu, 6 Oct 2011 19:57:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAAxqjk520aDu/2dsb2JhbAAMN6sSAQEBBAEBATUbGwoBEAsYCRYPCQMCAQIBFTAGDQEFAgEBiAG4SAOHLASlSA Received: from ppp118-209-160-238.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.160.238]) by ipmail06.adl2.internode.on.net with ESMTP; 07 Oct 2011 13:30:22 +1030 Message-ID: <4E8E6B36.9000106@nteczone.com> Date: Fri, 07 Oct 2011 14:00:06 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Allyn Romanow (allyn)" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C85189@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C85189@xmb-sjc-221.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] interim meeting-- Requirements doc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 02:57:13 -0000 Hello Allyn, Unfortunately I won't be at next weeks interim. I'd spend more time in the air than at the meeting :-(. I had two comments on the use cases draft that I didn't get a response to which relate to the requirements documents. 5) Section 3: [CNG] Will there be any attempt to link the requirements to certain uses cases?? For example: The RTCWEB requirements document indicates which requirements are derived from which use cases. 6) Section 3.x: [CNG] The framework draft sect 6.1 indicates that media descriptions are dynamic. I.e. capabilities may change. There's nothing explicit in the requirements to support this. Likewise there doesn't appear to be a use case to support that. Do we need to add one for that? Also a couple of additional comments on draft-ietf-clue-telepresence-requirements: REQMT-1b : This talks about two dimensions x,y. Given the recent discussions on capture area do we also need to a third dimension z? REQMT-2 :Is it also appropriate to add capture area x,y,z General : Point of Capture? I couldn't see where this is in the requirements? Regards, Christian On 7/10/2011 9:42 AM, Allyn Romanow (allyn) wrote: > > Hi Folks, > > Are there issues that people would like to discuss about the > requirements doc at the interim meeting next week? > > Thanks, > > Allyn > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From allyn@cisco.com Thu Oct 6 21:37:53 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B3E21F8B0F for ; Thu, 6 Oct 2011 21:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.792 X-Spam-Level: X-Spam-Status: No, score=-2.792 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6nP1iMQkAte for ; Thu, 6 Oct 2011 21:37:52 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2A02D21F8B0A for ; Thu, 6 Oct 2011 21:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=3165; q=dns/txt; s=iport; t=1317962465; x=1319172065; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=0YbHYUFuAYYyRFlp4K65VBkl1AOaBJSLKcNbUOwdk1Q=; b=lTrlFMuTr4CWyiQBIDV4dQAhG1/qWZI3i6Ltqs/hoVZwhmSVH49MvRKm s4641riZoq5aa4ycDsoYtMAR1RsR3bduVzkeMhhmmhOSVWp9HeYRMIxuw G+galkKhV0myH33PsESx88HC/Pyoybzo/4XlTaxvVIJ0oLhlRh71LVs9c k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEAAIyBjk6rRDoH/2dsb2JhbABDmR6PHIEFgVMBAQEDAQEBAQ8BHQo0CwUHBAIBCBEEAQEBCgYXAQYBJh8JCAEBBBMIEweHXAeaLwGeDQOGS2EEh32RIow1 X-IronPort-AV: E=Sophos;i="4.68,499,1312156800"; d="scan'208";a="6449146" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 07 Oct 2011 04:41:04 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p974f4ku024335; Fri, 7 Oct 2011 04:41:04 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Oct 2011 21:41:04 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Oct 2011 21:41:03 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C8527D@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4E8E6B36.9000106@nteczone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] interim meeting-- Requirements doc Thread-Index: AcyEnUPAMNgqnTbZR3uOwnMSm9dopwAA7pOA References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C85189@xmb-sjc-221.amer.cisco.com> <4E8E6B36.9000106@nteczone.com> From: "Allyn Romanow (allyn)" To: "Christian Groves" X-OriginalArrivalTime: 07 Oct 2011 04:41:04.0542 (UTC) FILETIME=[5281E3E0:01CC84AB] Cc: clue@ietf.org Subject: Re: [clue] interim meeting-- Requirements doc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 04:37:53 -0000 Hi Christian,=20 Thanks for your comments- Here are my thoughts on them-=20 Please see inline. > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Thursday, October 06, 2011 8:00 PM > To: Allyn Romanow (allyn) > Cc: clue@ietf.org > Subject: Re: [clue] interim meeting-- Requirements doc >=20 > Hello Allyn, >=20 > Unfortunately I won't be at next weeks interim. I'd spend more time in > the air than at the meeting :-(. >=20 > I had two comments on the use cases draft that I didn't get a response > to which relate to the requirements documents. >=20 > 5) Section 3: [CNG] Will there be any attempt to link the requirements > to certain uses cases?? For example: The RTCWEB requirements document > indicates which requirements are derived from which use cases. AR- I don't feel it is necessary, although I know it is a style that some folks use. If the WG feels it is worthwhile, it can be done. We had done this in earlier versions as a tool, but removed it in the most recent draft. What would be the advantage or usefulness for adding doing it now? >=20 > 6) Section 3.x: [CNG] The framework draft sect 6.1 indicates that media > descriptions are dynamic. I.e. capabilities may change. There's nothing > explicit in the requirements to support this. Likewise there doesn't > appear to be a use case to support that. Do we need to add one for > that? >=20 AR- Yes, I agree with you that there isn't a use case that describes a receiver taking advantage of a change in encoding characteristics, or other attributes. I don't feel that there needs to a use case, but we could add one if people feel it is necessary.=20 If you were to put in a requirement for this, it would not be to make capabilities dynamic, as that is tied to the particular solution mechanism we are proposing. It would be more along the lines that endpoints may change the characteristics of what they send.. which doesn't seem to me to be much of a requirement. > Also a couple of additional comments on > draft-ietf-clue-telepresence-requirements: >=20 > REQMT-1b : This talks about two dimensions x,y. Given the recent > discussions on capture area do we also need to a third dimension z? AR- I don't think this has been settled yet. > REQMT-2 :Is it also appropriate to add capture area x,y,z AR - Again, I don't think this has been settled. > General : Point of Capture? I couldn't see where this is in the > requirements? AR - I think point of capture wouldn't be in the requirements.. it is part of the necessary mechanism for this proposed solution which enables spatial arrangement, which is in the requirements. Regards, Allyn >=20 > Regards, Christian >=20 > On 7/10/2011 9:42 AM, Allyn Romanow (allyn) wrote: > > > > Hi Folks, > > > > Are there issues that people would like to discuss about the > > requirements doc at the interim meeting next week? > > > > Thanks, > > > > Allyn > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue From allyn@cisco.com Thu Oct 6 23:43:29 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FD321F8797 for ; Thu, 6 Oct 2011 23:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.781 X-Spam-Level: X-Spam-Status: No, score=-2.781 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqMKG+Kxw6R8 for ; Thu, 6 Oct 2011 23:43:28 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2526221F85D1 for ; Thu, 6 Oct 2011 23:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=12883; q=dns/txt; s=iport; t=1317970001; x=1319179601; h=mime-version:subject:date:message-id:from:to; bh=Ye5EagmcFfhwoTcju9/K0wQ1WZhliIEl1UJS960kN3I=; b=Ws1qYMU7UWpQsNxYtxE7gTKOpSmjf7JQm7wZAnSzidaH1Vz4Hb61iKjw 1NipY0kvjiIiw+uPuzR7UadytjA8US6HfU6gcCnmr3CeGHG2UYxeXLE+G OCFT95llYozEwcZtA3mSmGBJbkgTlFhoV9UsR6HWqlatOo1tQhrOm67QA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4GAGefjk6rRDoJ/2dsb2JhbABDgk2XFI5ZgQWBVQEBAxIBCREDWwEqBhgHUAcBBBsaoD2BJgGeFYZRYQSHfZEjjDY X-IronPort-AV: E=Sophos;i="4.68,500,1312156800"; d="scan'208,217";a="6450846" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 07 Oct 2011 06:46:40 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p976keO6019548 for ; Fri, 7 Oct 2011 06:46:40 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Oct 2011 23:46:40 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC84BC.DE18ACFC" Date: Thu, 6 Oct 2011 23:46:39 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42A75@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: interim meeting agenda for framework doc discussion Thread-Index: AcyEvN2LtpQ15NyOSBe1zBiEsesWUg== From: "Allyn Romanow (allyn)" To: X-OriginalArrivalTime: 07 Oct 2011 06:46:40.0718 (UTC) FILETIME=[DE6B16E0:01CC84BC] Subject: [clue] interim meeting agenda for framework doc discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 06:43:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC84BC.DE18ACFC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable HI Folks, =20 Here is a proposal for the framework portion of the interim meeting. =20 =20 Goal: Move the draft-romanow-clue-framework toward acceptance as a WG draft =20 Agenda: Overview - 50 minutes Overview - presentation by draft authors of new material * Area of capture * Segment switching. VAD. What information in VAD =20 Issues =20 * Area of Capture * 3 message exchange - provider and consumer. Devices are both.=20 o Initial capabilities message * Measurements - are degrees, radians necessary * Definitions - Roni's email (unless it is sorted out on email) =20 What are additional issues people feel need to be agreed upon that stand in the way of the document becoming a WG draft? In order to make progress, the discussion will be kept to identified issues. New ones can be added during the meeting, of course. =20 If you have a particular viewpoint on an issue, it would help to have some slides to describe it ------_=_NextPart_001_01CC84BC.DE18ACFC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

HI Folks,

 

Here is a proposal for the framework portion of the = interim meeting.

 

 

Goal:  Move the draft-romanow-clue-framework = toward acceptance as a WG draft

 

Agenda:

Overview – 50 minutes

Overview – presentation by draft authors = of new material

·         Area of capture

·         Segment switching. VAD. What information = in VAD

 

Issues

 

·         Area of Capture

·         3 message exchange – provider and consumer. Devices are both.

o   Initial capabilities = message

·         Measurements – are degrees, radians necessary

·         Definitions – Roni’s =  email (unless it is sorted out on email)

 

What  are additional issues people feel need = to be agreed upon that stand in the way of the document becoming a WG draft? = In order to make progress, the discussion will be kept to identified issues. New = ones can be added during the meeting, of course.

 

If you have a particular viewpoint on an issue, it = would help to have some slides to describe it

------_=_NextPart_001_01CC84BC.DE18ACFC-- From espeberg@cisco.com Fri Oct 7 08:13:55 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE9721F8C14 for ; Fri, 7 Oct 2011 08:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM8qWFYUxYHp for ; Fri, 7 Oct 2011 08:13:51 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E4D5621F8B2A for ; Fri, 7 Oct 2011 08:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=2475; q=dns/txt; s=iport; t=1318000625; x=1319210225; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Jy6PDRDVPrvFyz0nE/4j0andSWgjjpCvfxgOhzy12No=; b=K27qJ7OcfKV4DSLhcVjBWzcW1yLQEyFOkijto7wuJ3AXGOF1Ou1ZOGnI kuZmln7UXTIhxEsDOYQ07Y5hMqPYbxt0ZII4JMu9T0nvxr8jVVGgWbrv9 shpVmqW1kYRkvVA7Vch6JNmzToi7XA/rBNheY3Dc8T1AWHl7nGRJQqGBe 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoAAOQWj06Q/khR/2dsb2JhbABEmR6PH4EFgVMBAQEBAwEBAQ8BHQouBgQFDgQCAQgRBAEBCwYXAQYBJh8IAQgBAQQBEggah2OaFwGeKwOGUGEEmSCMGQ X-IronPort-AV: E=Sophos;i="4.68,502,1312156800"; d="scan'208";a="57331432" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 07 Oct 2011 15:17:03 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p97FH21s028372 for ; Fri, 7 Oct 2011 15:17:02 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 17:17:02 +0200 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Oct 2011 17:17:02 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9EA250D3@XMB-AMS-214.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05B7DE73@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] FW: New Version Notification fordraft-romanow-clue-framework-01.txt Thread-Index: AcyBfNc209efl2npShC1uJ3ejqFLHgAAAs9AAOEn9XA= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05B7DE73@xmb-sjc-221.amer.cisco.com> From: "Espen Berger (espeberg)" To: "Allyn Romanow (allyn)" , X-OriginalArrivalTime: 07 Oct 2011 15:17:02.0933 (UTC) FILETIME=[2AAE4850:01CC8504] Subject: Re: [clue] FW: New Version Notification fordraft-romanow-clue-framework-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 15:13:55 -0000 Some question related to the framework-1 document.=20 5.2. Media capture attributes=20 I think we should avoid boolean attributes specifying policies like video-compose and auto-switched. A sender can choose to forward a single video stream from a room with different policies for selecting the video stream. Multiple policies is not easy to express in a Boolean.=20 5. Capture scene=20 As I read the framework a capture set is always inside a capture scene, which holds the logical scene information (e.g. name)=20 Maybe write out information about capture scene attributes, e.g. to name scenes like 'Speaker', 'Audience', 'Whiteboard' and so on. I used the names from the lecture use cases, where the video capture sources are independent and should be named to be properly indentified on the receive side.=20 6.3.2=20 * How to handle different aspect ratios? If you only specify width and height, you do not really know if the cameras are able to deliver 4:3 or 16:9?=20 6.3.3=20 * Can the encoder groups be shared by media captures? E.g. examples might be endpoints with multiple sources, but only one can be encoded at the time. =20 6.3.4=20 * I assume that the Configure Request can be used to specify attributes for a stream and concrete encoder that is below what is specified in the announce?=20 Regards=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Allyn Romanow (allyn) Sent: 3. oktober 2011 05:32 To: clue@ietf.org Subject: [clue] FW: New Version Notification fordraft-romanow-clue-framework-01.txt -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Sunday, October 02, 2011 8:28 PM A new version of I-D, draft-romanow-clue-framework-01.txt has been successfully submitted by Allyn Romanow and posted to the IETF repository. Filename: draft-romanow-clue-framework Revision: 01 Title: Framework for Telepresence Multi-Streams Creation date: 2011-10-03 WG ID: Individual Submission Number of pages: 32 Abstract: This memo offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple RTP streams. =20 The IETF Secretariat _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Fri Oct 7 08:37:56 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DD621F8ADC for ; Fri, 7 Oct 2011 08:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.349 X-Spam-Level: X-Spam-Status: No, score=-106.349 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72QRpV08PV8k for ; Fri, 7 Oct 2011 08:37:54 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3E32821F8AE6 for ; Fri, 7 Oct 2011 08:37:53 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSP00KLZCWHBF@szxga04-in.huawei.com> for clue@ietf.org; Fri, 07 Oct 2011 23:41:05 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSP00G7GCWHTW@szxga04-in.huawei.com> for clue@ietf.org; Fri, 07 Oct 2011 23:41:05 +0800 (CST) Received: from windows8d787f9 ([109.64.200.234]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LSP00LJNCVVRB@szxml12-in.huawei.com> for clue@ietf.org; Fri, 07 Oct 2011 23:41:05 +0800 (CST) Date: Fri, 07 Oct 2011 17:37:43 +0200 From: Roni Even To: clue@ietf.org Message-id: <072c01cc8507$1ec4a1d0$5c4de570$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_V0FfwRrhV1d422A9jI928A)" Content-language: en-us Thread-index: AcyFBwysRmxYuIh+Swq+vFNyr2ZqIg== Subject: [clue] framework draft - comments on section 5 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 15:37:56 -0000 This is a multi-part message in MIME format. --Boundary_(ID_V0FfwRrhV1d422A9jI928A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, These are my comments on section 5, some are purely editorial and have some relation to the comments on the definitions. 1. In section 5.1 " The model uses the terms "video capture" (VC) and "audio capture" (AC) to refer to sources of media streams". What about presentation is it a VC? Need to clarify. This is also true for section 5.2 that disucss VC spatial relation. 2. Section 5.2 defines attributes, I am wondering if the attribute should be part of the framework or part of a protocol document. In any case there need to be a way to specify which attributes are supported. My assumption that an implementation MUST support all attributes specified in a document and declare it. This means that there will be a name for each document with extensions. (This is similar to csup in RFC5939 section 3.3.1) 3. There is an editor note about duplication of SDP parameters yet "purpose" for example duplicate the "content" attribute. 4. Audio mix is defined as true/false - what about parameter like mix level (how many speakers are mixed) - why make this parameter a Boolean? 5. There is a separate thread on area, point and scale so I am not discussing these attribute in this thread. 6. Video composed (true/false), why Boolean, what does the mix include? The definition is section 5.2.7 says what this is not, it is not saying what the video composed is, and how to use it. I am not talking about layout but also for example in a three camera system which cameras are mixed. 7. The general comment is that the document defines the attribute to be Booleans, enumerated (for purpose attribute), This should be part of the protocol decision, for example if we want to us text. 8. Auto switch is Boolean but according to 5.2.8 there may be different option to do the auto switch, not only loudest speaker. I think that it should allow also to define the auto switch mode used, maybe allowing a provider to offer more than one switching option. 9. In section 5.2, how should an MCU convey that you can see room1 (video and audio) or room2 (video and audio) is this two scenes or two sets or two captures? Regards Roni _____ --Boundary_(ID_V0FfwRrhV1d422A9jI928A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

These are my = comments on section 5, some are purely editorial and have some relation = to the comments on the definitions.

 

1.       = In section 5.1 " The = model uses the terms "video capture" (VC) and "audio = capture" (AC) to refer to sources of media streams". What = about presentation is it a VC? Need to clarify. This is also true for = section 5.2 that disucss VC spatial relation.

2.       = Section 5.2 defines = attributes, I am wondering if the attribute should be part of the = framework or part of a protocol document. In any case there need to be a = way to specify which attributes are supported. My assumption that an = implementation MUST support all attributes specified in a document and = declare it. This means that there will be a name for each document with = extensions. (This is similar to csup in RFC5939 section = 3.3.1)

3.       = There is an editor note = about duplication of SDP parameters yet "purpose" for example = duplicate the "content" attribute.

4.       = Audio mix is defined as = true/false – what about parameter like mix level (how many = speakers are mixed) – why make this parameter a = Boolean?

5.       = There is a separate = thread on area, point and scale so I am not discussing these attribute = in this thread.

6.       = Video composed = (true/false), why Boolean, what does the mix include? The definition is = section 5.2.7 says what this is not, it is not saying what the video = composed is, and how to use it. I am not talking about layout but also = for example in a three camera system which cameras are = mixed.

7.       = The general comment is = that the document defines the attribute to be Booleans, enumerated (for = purpose attribute), This should be part of the protocol decision, for = example if we want to us text.

8.       = Auto switch is Boolean = but according to 5.2.8 there may be different option to do the auto = switch, not only loudest speaker. I think that it should allow also to = define the auto switch mode used, maybe allowing a provider to offer = more than one switching option.

9.       = In section 5.2, how = should an MCU convey that you can see room1 (video and audio) or room2 = (video and audio) is this two scenes or two sets or two = captures?

 

 

Regards

Roni

 

 

= --Boundary_(ID_V0FfwRrhV1d422A9jI928A)-- From stephen.botzko@gmail.com Fri Oct 7 08:39:24 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CB321F8C59 for ; Fri, 7 Oct 2011 08:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bLkJsb5ekiC for ; Fri, 7 Oct 2011 08:39:23 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A619521F8C58 for ; Fri, 7 Oct 2011 08:39:23 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4015736vcb.31 for ; Fri, 07 Oct 2011 08:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LFMX/r4PjK1DnOG6MPnqdiIv8qJlA1fIghF54qlcPQY=; b=TVWT3PZyV1CSLF0rGr2PYYqYXInznXOTsqORCGx+Cjem6oxGKl800s4Mmu7I0zWGK0 TawAMvj28uKCsZ9nU4KGTlZzXyge4JV580KNQdVLz1mTKOilx65oa4oS4T0aeQoLrWqM YLgUYDUIX7TewrPV2oQNUEnWZcRkMZHshWJY0= MIME-Version: 1.0 Received: by 10.52.117.233 with SMTP id kh9mr3160729vdb.117.1318002157152; Fri, 07 Oct 2011 08:42:37 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Fri, 7 Oct 2011 08:42:34 -0700 (PDT) In-Reply-To: <92DF9533227FC14F946C7321074B8C9EA250D3@XMB-AMS-214.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05B7DE73@xmb-sjc-221.amer.cisco.com> <92DF9533227FC14F946C7321074B8C9EA250D3@XMB-AMS-214.cisco.com> Date: Fri, 7 Oct 2011 11:42:34 -0400 Message-ID: From: Stephen Botzko To: "Espen Berger (espeberg)" Content-Type: multipart/alternative; boundary=bcaec547c57963e9ad04aeb74a60 Cc: clue@ietf.org Subject: Re: [clue] FW: New Version Notification fordraft-romanow-clue-framework-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 15:39:24 -0000 --bcaec547c57963e9ad04aeb74a60 Content-Type: text/plain; charset=ISO-8859-1 in-line On Fri, Oct 7, 2011 at 11:17 AM, Espen Berger (espeberg) wrote: > Some question related to the framework-1 document. > > 5.2. Media capture attributes > > I think we should avoid boolean attributes specifying policies like > video-compose and auto-switched. A sender can choose to forward a single > video stream from a room with different policies for selecting the video > stream. Multiple policies is not easy to express in a Boolean. > > 5. Capture scene > As I read the framework a capture set is always inside a capture scene, > which holds the logical scene information (e.g. name) > > Maybe write out information about capture scene attributes, e.g. to name > scenes like 'Speaker', 'Audience', 'Whiteboard' and so on. I used the > names from the lecture use cases, where the video capture sources are > independent and should be named to be properly indentified on the > receive side. > > 6.3.2 > * How to handle different aspect ratios? If you only specify width > and height, you do not really know if the cameras are able to deliver > 4:3 or 16:9? > [sb]The capture aspect ratio is width:height, so in fact you do know if the capture is 4:3 or 16:9. The pixel aspect ratio can be computed from that, although with H.264 it is generally signaled in the VUI message as well. > > 6.3.3 > * Can the encoder groups be shared by media captures? E.g. > examples might be endpoints with multiple sources, but only one can be > encoded at the time. > > 6.3.4 > * I assume that the Configure Request can be used to specify attributes > for a stream and concrete encoder that is below what is specified in the > announce? > > Regards > > -Espen > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Allyn Romanow (allyn) > Sent: 3. oktober 2011 05:32 > To: clue@ietf.org > Subject: [clue] FW: New Version Notification > fordraft-romanow-clue-framework-01.txt > > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Sunday, October 02, 2011 8:28 PM > > > A new version of I-D, draft-romanow-clue-framework-01.txt has been > successfully submitted by Allyn Romanow and posted to the IETF > repository. > > Filename: draft-romanow-clue-framework > Revision: 01 > Title: Framework for Telepresence Multi-Streams > Creation date: 2011-10-03 > WG ID: Individual Submission > Number of pages: 32 > > Abstract: > This memo offers a framework for a protocol that enables devices in a > telepresence conference to interoperate by specifying the > relationships between multiple RTP streams. > > > > > > The IETF Secretariat > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --bcaec547c57963e9ad04aeb74a60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable in-line

On Fri, Oct 7, 2011 at 11:17 AM, = Espen Berger (espeberg) <espeberg@cisco.com> wrote:
Some question related to the framework-1 document.

5.2. Media capture attributes

I think we should avoid boolean attributes specifying policies like
video-compose and auto-switched. A sender can choose to forward a single video stream from a room with different policies for selecting the video stream. Multiple policies is not easy to express in a Boolean.

5. Capture scene
As I read the framework a capture set is always inside a capture scene,
which holds the logical scene information (e.g. name)

Maybe write out information about capture scene attributes, e.g. to name scenes like 'Speaker', 'Audience', 'Whiteboard' and= so on. I used the
names from the lecture use cases, where the video capture sources are
independent and should be named to be properly indentified on the
receive side.

6.3.2
* =A0 =A0 =A0 How to handle different aspect ratios? If you only specify wi= dth
and height, you do not really know if the cameras are able to deliver
4:3 or 16:9?
[sb]The capture aspect ratio is width:hei= ght, so in fact you do know if the capture is 4:3 or 16:9.=A0 The pixel asp= ect ratio can be computed from that, although with H.264 it is generally si= gnaled in the VUI message as well.

6.3.3
* =A0 =A0 =A0 Can the encoder groups be shared by media captures? E.g.
examples might be endpoints with multiple sources, but only one can be
encoded at the time.

6.3.4
* I assume that the Configure Request can be used to specify attributes
for a stream and concrete encoder that is below what is specified in the announce?

Regards

-Espen


-----Original Message-----
From: clue-bounces@ietf.org [m= ailto:clue-bounces@ietf.org] O= n Behalf Of
Allyn Romanow (allyn)
Sent: 3. oktober 2011 05:32
To: clue@ietf.org
Subject: [clue] FW: New Version Notification
fordraft-romanow-clue-framework-01.txt



-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Sunday, October 02, 2011 8:28 PM


A new version of I-D, draft-romanow-clue-framework-01.txt has been
successfully submitted by Allyn Romanow and posted to the IETF
repository.

Filename: =A0 =A0 =A0 =A0draft-romanow-clue-framework
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Framework for Telepresence Multi-Streams
Creation date: =A0 2011-10-03
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 32

Abstract:
=A0 This memo offers a framework for a protocol that enables devices in a<= br> =A0 telepresence conference to interoperate by specifying the
=A0 relationships between multiple RTP streams.





The IETF Secretariat
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--bcaec547c57963e9ad04aeb74a60-- From mary.ietf.barnes@gmail.com Fri Oct 7 08:41:36 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA3021F8C6B for ; Fri, 7 Oct 2011 08:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.474 X-Spam-Level: X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnH7xtIm0PP0 for ; Fri, 7 Oct 2011 08:41:32 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E20C721F8C58 for ; Fri, 7 Oct 2011 08:41:31 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4018091vcb.31 for ; Fri, 07 Oct 2011 08:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=os6+NI8QM2eesu6egWo3tM/33hM6tcvle6ACjwLf60c=; b=wQzVjDRv+55Cv6dvQKW8u/HbcT0Esdl3alD+Zr0N/SYMjysV+q2bJSR4kjbiqsALKQ NacMXMI+TXEtuvqkNVTej8eFuj55UJbMh60RjjO2TYQL6YG27HNqOf663RvjP8+4cBMs uCy+Co0v79aMLD/C9iCPFgmkPvfw9gSpobnPM= MIME-Version: 1.0 Received: by 10.52.21.67 with SMTP id t3mr3172003vde.104.1318002285490; Fri, 07 Oct 2011 08:44:45 -0700 (PDT) Received: by 10.52.75.198 with HTTP; Fri, 7 Oct 2011 08:44:45 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Oct 2011 10:44:45 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307d00ca0a319d04aeb7522b Subject: Re: [clue] CLUE WG Interim Meeting, Oct. 11-12th, 2011 (includes Webex info) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 15:41:36 -0000 --20cf307d00ca0a319d04aeb7522b Content-Type: text/plain; charset=ISO-8859-1 For folks attending the interim meeting next week, just a reminder that there is a map for getting to the facility on the CLUE wg wiki (you will need to download the file that you can access by clicking on the address): http://trac.tools.ietf.org/wg/clue/trac/wiki The logistics for getting to the hotels/meeting location from the airport are also available on the wiki (again downloading the file pointed to by the "Hotels and other info" link. Per the agenda, folks can start arriving at 8:30. You will need to stop at the reception desk, sign in and get a visitors badge. One of the Polycom employees that will be at the meeting (myself, Stephen Botzko or Mark Duckworth) will need to take you to the meeting room. If you arrive between 8:30 and 8:55, please wait in the lobby as one of us should be there shortly. If you arrive later, the receptionist will need to contact us to come escort you. Please let me know if you have further questions. Regards, Mary. On Tue, Sep 27, 2011 at 6:08 PM, Mary Barnes wrote: > Hi all, > > > As previously posted, the CLUE WG has scheduled an interim meeting for Oct. > 11th-12th, 2011 (1.5 days). The f2f meeting will be held at the Polycom > facility located at 100 Minuteman Road, Andover, Massachusetts. The > Webex details for remote participation are below. > > > The proposed agenda is as follows. Note, that the authors plan to have an > updated framework document submitted by the end of this week (Sept. 30th) to > allow enough time for review of the document before the meeting. Anyone > else that would like agenda time, please contact the chairs no later than > Sept. 30th, 2011. > > > Oct. 11th, 2011 > -------------------- > 9:00-9:10 Chair - status, agenda bash > 9:10-09:50 Discussion of any remaining open issues for the use cases and > requirements > 09:50-10:00 Short coffee break > 10:00-11:30 Proposed framework discussion > 11:30-13:00 Lunch > 13:30-15:00 Proposed framework discussion > 15:00-15:20 Break > 15:20-17:00 CLUE and RTCWEB > 17:00-18:00 Summary and identification of key items for discussion on > Tuesday > > Oct. 12th, 2011 (note this agenda will be finalized based on the outcome of > Tuesday's meeting) > --------------------------- > 08:30-08:45 Plans for the day > 08:45-10:30 Discussion > 10:30-10:45 Break > 10:45-12:30 Discussion > 12:30-13:00 Discussion of way forward and summary of action items > > > > Webex: > > ======== > > > Topic: CLUE WG Interim Meeting > Date: Every 1 day, from Tuesday, October 11, 2011 to Wednesday, October 12, > 2011 > Time: 8:30 am, Eastern Daylight Time (New York, GMT-04:00) > Meeting Number: 969 145 615 > Meeting Password: (This meeting does not require a password.) > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://workgreen.webex.com/workgreen/j.php?ED=182521792&UID=1251996147&RT=MiMxMQ%3D%3D > 2. If requested, enter your name and email address. > 3. If a password is required, enter the meeting password: (This meeting > does not require a password.) > 4. Click "Join". > > To view in other time zones or languages, please click the link: > > https://workgreen.webex.com/workgreen/j.php?ED=182521792&UID=1251996147&ORT=MiMxMQ%3D%3D > > ------------------------------------------------------- > To join the audio conference only > ------------------------------------------------------- > To receive a call back, provide your phone number when you join the > meeting, or call the number below and enter the access code. > Call-in toll number (US/Canada): 1-408-792-6300 > Global call-in numbers: > https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=182521792&tollFree=0 > > Access code:969 145 615 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://workgreen.webex.com/workgreen/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > cmorgan@amsl.com > 1-510-492-4085 > > To update this meeting to your calendar program (for example Microsoft > Outlook), click this link: > > https://workgreen.webex.com/workgreen/j.php?ED=182521792&UID=1251996147&ICS=MRS1&LD=1&RD=2&ST=1&SHA2=xBjAAyKlGU5WtZwaNwAEZK1vCvOPzxE9heViyuR6muc=&RT=MiMxMQ%3D%3D > > > WebEx will automatically setup Meeting Manager for Windows the first time > you join a meeting. To save time, you can setup prior to the meeting by > clicking this link: > https://workgreen.webex.com/workgreen/meetingcenter/mcsetup.php > > > The playback of UCF (Universal Communications Format) rich media files > requires appropriate players. To view this type of rich media files in the > meeting, please check whether you have the players installed on your > computer by going to > https://workgreen.webex.com/workgreen/systemdiagnosis.php. > > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial > > http://www.webex.com > > CCP:+14087926300x969145615# > > IMPORTANT NOTICE: This WebEx service includes a feature that allows audio > and any documents and other materials exchanged or viewed during the session > to be recorded. By joining this session, you automatically consent to such > recordings. If you do not consent to the recording, discuss your concerns > with the meeting host prior to the start of the recording or do not join the > session. Please note that any such recordings may be subject to discovery in > the event of litigation. **** > > --20cf307d00ca0a319d04aeb7522b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable For folks attending the interim meeting next week, just a reminder that the= re is a map for getting to the facility on the CLUE wg wiki (you will need = to download the file that you can access by clicking on the address):

The logistics for g= etting to the hotels/meeting location from the airport are also available o= n the wiki (again downloading the file pointed to by the "Hotels and o= ther info" link.=A0

Per the agenda, folks can start arriving at 8:30. =A0Yo= u will need to stop at the reception desk, sign in and get a visitors badge= . One of the Polycom employees that will be at the meeting (myself, Stephen= Botzko or Mark Duckworth) will need to take you to the meeting room. =A0If= you arrive between 8:30 and 8:55, please wait in the lobby as one of us sh= ould be there shortly. If you arrive later, the receptionist will need to c= ontact us to come escort you. =A0=A0

Please let me know if you have further questions.
=

Regards,
Mary.

On Tue, Sep 27, 2011 at 6:08 PM, Mary Barnes &= lt;mary.ietf.barnes@gmail.com= > wrote:

Hi all,


As previously posted, the CLUE WG has scheduled an interim meeting for Oct.= 11th-12th, 2011 (1.5 days). =A0 The f2f meeting will be held at the Polyco= m facility located at =A0100 =A0Minuteman Road, Andover, Massachusetts. =A0= The Webex details for remote participation are below. =A0


The proposed agenda is as follows. Note, that the authors plan to= have an updated framework document submitted by the end of this week (Sept= . 30th) to allow enough time for review of the document before the meeting.= =A0Anyone else that would like agenda time, please contact the chairs no l= ater than Sept. 30th, 2011.=A0


Oct. 1= 1th, 2011
--------------------
9:00-9:10 Chair - statu= s, agenda bash
9:10-09:50 Discussion of any remaining open issues for the use cases = and requirements
09:50-10:00 Short coffee break
10:00-11:30 P= roposed framework discussion
11:30-13:00 Lunch=A0
13:30-15:00 =A0=A0Propo= sed framework discussion
15:00-15:20 =A0Break
15:20-17:00 =A0CLUE and= RTCWEB=A0
17:00-18:00 =A0Summary and identification of key items for discussion= on Tuesday

Oct. 12th, 2011 (note this agenda will = be finalized based on the outcome of Tuesday's meeting)
---------------------------
08:30-08:45 =A0P= lans for the day
08:45-10:30 =A0Discussion
10:30-10:45 =A0Bre= ak
10:45-12:30 =A0Discussion
12:30-13:00 =A0Dis= cussion of way forward and summary of action items



Webex:

=3D=3D=3D=3D= =3D=3D=3D=3D


Topic: CLUE WG Interim Meeting
Date: Every= 1 day, from Tuesday, October 11, 2011 to Wednesday, October 12, 2011
T= ime: 8:30 am, Eastern Daylight Time (New York, GMT-04:00)
Meeting Number: 969 145 615
Meeting Password: (This meeting does not re= quire a password.)


--------------------------------------------= -----------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://workgreen.webex.= com/workgreen/j.php?ED=3D182521792&UID=3D1251996147&RT=3DMiMxMQ%3D%= 3D
2. If requested, enter your name and email address.
3. If a password is= required, enter the meeting password: (This meeting does not require a pas= sword.)
4. Click "Join".

To view in other time zones = or languages, please click the link:
https://workgreen= .webex.com/workgreen/j.php?ED=3D182521792&UID=3D1251996147&ORT=3DMi= MxMQ%3D%3D

-------------------------------------------------------
To join the= audio conference only
------------------------------------------------= -------
To receive a call back, provide your phone number when you join= the meeting, or call the number below and enter the access code.
Call-in toll number (US/Canada): 1-408-792-6300
Global call-in numbers= : https://wo= rkgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&ED=3D1825= 21792&tollFree=3D0

Access code:969 145 615

---------------------------------------= ----------------
For assistance
-----------------------------------= --------------------
1. Go to https://workgreen.webex.com/workgreen/mc =
2. On the left navigation bar, click "Support".

You can c= ontact me at:
cmo= rgan@amsl.com
1-510-492-4085

To update this meeting to your calendar program (for example Microsoft = Outlook), click this link:
https://workgreen.webex.com/wo= rkgreen/j.php?ED=3D182521792&UID=3D1251996147&ICS=3DMRS1&LD=3D1= &RD=3D2&ST=3D1&SHA2=3DxBjAAyKlGU5WtZwaNwAEZK1vCvOPzxE9heViyuR6m= uc=3D&RT=3DMiMxMQ%3D%3D


WebEx will automatically setup Meeting Manager for Windows the firs= t time you join a meeting. To save time, you can setup prior to the meeting= by clicking this link:
https://workgreen.webex.com/= workgreen/meetingcenter/mcsetup.php


The playback of UCF (Universal Communications Format) rich media fi= les requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your co= mputer by going to https://workgreen.webex.com/workgreen/syste= mdiagnosis.php.

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.web= ex.com

CCP:+14087926300x969145615#

IMPORTANT NOTICE: This WebEx servic= e includes a feature that allows audio and any documents and other material= s exchanged or viewed during the session to be recorded. By joining this se= ssion, you automatically consent to such recordings. If you do not consent = to the recording, discuss your concerns with the meeting host prior to the = start of the recording or do not join the session. Please note that any suc= h recordings may be subject to discovery in the event of litigation.



--20cf307d00ca0a319d04aeb7522b-- From stephane.cazeaux@orange.com Fri Oct 7 04:22:07 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE0B21F8A62 for ; Fri, 7 Oct 2011 04:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XKi+Lmp6Lh2 for ; Fri, 7 Oct 2011 04:22:06 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id C3D5B21F8997 for ; Fri, 7 Oct 2011 04:22:05 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 601BC8B8006 for ; Fri, 7 Oct 2011 13:26:39 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 4FFBE8B8003 for ; Fri, 7 Oct 2011 13:26:39 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr ([10.194.32.11]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 13:25:16 +0200 Received: from FTRDMB03.rd.francetelecom.fr ([fe80::4c06:6ece:ed2d:797e]) by FTRDCH01.rd.francetelecom.fr ([::1]) with mapi id 14.01.0270.001; Fri, 7 Oct 2011 13:25:16 +0200 From: To: Thread-Topic: [clue] the presentation use case Thread-Index: AcxHlL8VW+C7KhbYQU2HJX/U8MKZpAFFKK/A///k6YCAAFO3gIAACg4AgAAqsQCAAFTQgP/uhI7ggCNGD4D/+k3aoIALuqeA/6gpJ1A= Date: Fri, 7 Oct 2011 11:25:16 +0000 Message-ID: References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com><4E309135.7070408@alum.mit.edu><001b01cc4cd6$77d28760$67779620$%roni@huawei.com> <4E30DFDE.3040601@alum.mit.edu> <9ECCF01B52E7AB408A7EB85352642141031F2E5E@ftrdmel0.rd.francetelecom.fr> <4E314AD3.1030406@alum.mit.edu> <4E403783.70706@alum.mit.edu> <4E454723.4080501@alum.mit.edu> In-Reply-To: <4E454723.4080501@alum.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.193.118] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Oct 2011 11:25:16.0606 (UTC) FILETIME=[C9DD2DE0:01CC84E3] Subject: [clue] the presentation use case X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 16:00:26 -0000 Hi I will not be able to attend physically to the interim meeting. However I had a comment on the presentation use case, which I still conside= r we need to agree on.=20 In the use case draft, the presentation use case is restricted to the video= based solution. To me, it should be modified so that: - It does not restrict the solution to the video - It includes the need to share any kind of documents (including complex do= cuments such as excel sheets) and the ability to have remote control See below the discussion. Regards, St=E9phane. -----Message d'origine----- De=A0: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Envoy=E9=A0: vendredi 12 ao=FBt 2011 17:31 =C0=A0: CAZEAUX Stephane RD-BIZZ-CAE Cc=A0: clue@ietf.org Objet=A0: Re: [clue] Comment on the presentation use case On 8/12/11 4:48 AM, stephane.cazeaux@orange-ftgroup.com wrote: > Hi Paul, > > I understand your suggestion, and I am aware that it could be a solution.= It certainly makes sense, but I am not sure of how it could be integrated = in CLUE. To me, this is a matter of application integration, at application= level. > > My suggestion is that we should think of a solution that provides more sa= tisfying collaboration within telepresence, with the same level of interope= rability and multistream interaction as presentation video stream provides,= but with more satisfying quality (video is not suitable for all kinds of s= hared documents) and more collaborative features. > I don't think that the kind of relationship that you suggest is the only = solution. IMO the main thing is to not constrain the mechanism used for=20 collaboration/web sharing. That stuff is evolving at "web speed".=20 Anything you nail down that is constraining will be obsolete before it=20 gets out. (I've been looking more at RTCWEB recently, and I'm wondering if perhaps=20 CLUE ought to be based on that.) Thanks, Paul (as individual) > Stephane. > > > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Envoy=E9 : lundi 8 ao=FBt 2011 21:23 > =C0 : CAZEAUX Stephane RD-BIZZ-CAE > Cc : clue@ietf.org > Objet : Re: [clue] Comment on the presentation use case > > On 8/8/11 11:56 AM, stephane.cazeaux@orange-ftgroup.com wrote: >> Hi, >> >> To me, it should be part of the telepresence protocols at least to enabl= e the interoperability, as the presentation based on video stream allows it= . >> >> The point is that video stream is not convenient for the use cases I sug= gested. But it does not necessarily mean that we should bundle a full data = sharing protocol with telepresence. Something simpler, like the RFB option = of draft-garcia-mmusic-sdp-collaboration, could be a candidate. > > What I was suggesting is that maybe it would make sense to turn those > relationships "inside out". > > For instance when I use a collaboration tool like Webex, the > collaboration is set up first via the web, and defines the set of > participants. Then a voice session can be added. For pragmatic reasons, > the voice conferencing seems to be pretty distinct. (I'm not certain how > webex handles video. I suspect it is doing it via the web, not the > telephony conference.) > > Its not hard to imagine the same sort of setup, but with a multiparty > telepresence session instead of the traditional voice conference. In > such a case, you would probably want the collaboration tool (webex, or > whatever) to mediate the UI for the web collaboration, the roster, etc. > It might delegate a lot of that to the telepresence infrastructure. > > But that does raise some questions about how all the components fit > together. Is there a single screen for the collaboration session in a > telepresence room? What about input to that - keyboard, mouse, etc.? Or > do we assume that each person in the room has their own computer with > input, display, etc. and maybe a way to slave the web collaboration > session to one or more of the big displays in the room? > > What probably *can't* be done right now is nail down a particular web > collaboration service (e.g. Webex) or protocol. That does complicate > slaving the collaboration session to a screen, unless its done by having > someone connect a video connection to their own computer. > > Thanks, > Paul > >> Stephane. >> >> >> -----Message d'origine----- >> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de = Paul Kyzivat >> Envoy=E9 : jeudi 28 juillet 2011 13:41 >> =C0 : CHATRAS Bruno RD-CORE-ISS >> Cc : clue@ietf.org >> Objet : Re: [clue] Comment on the presentation use case >> >> On 7/28/11 2:37 AM, bruno.chatras@orange-ftgroup.com wrote: >>> I think we should take a look to >>> http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration-00 >> >> Maybe. But that is almost orthogonal to what I was suggesting. >> >> THanks, >> Paul >> (as individual) >> >>> Bruno >>> >>>> -----Message d'origine----- >>>> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part d= e >>>> Paul Kyzivat >>>> Envoy=E9 : jeudi 28 juillet 2011 06:05 >>>> =C0 : Roni Even >>>> Cc : clue@ietf.org >>>> Objet : Re: [clue] Comment on the presentation use case >>>> >>>> On 7/27/11 11:28 PM, Roni Even wrote: >>>>> Hi, >>>>> HTTP is not defining a common data sharing protocol. WebEx may be >>>> carried >>>>> over HTTP but the data sharing application is not standard. What I >>>> meant is >>>>> that it can either be something that is a common data sharing >>>> protocol or >>>>> something that is carried as an RTP payload which require some common >>>>> defined protocol on top. >>>> >>>> I was being a bit tongue in cheek, though not entirely. >>>> Of course you are right - that if you want to push data to everybody >>>> you >>>> need more. >>>> >>>> But data sharing by pointing a video camera at a piece of paper is a >>>> tad >>>> out of date. Connecting the video port on a user's computer as a video >>>> source and distributing it with the other video is better than that. >>>> But >>>> its not nearly as convenient as webex or any of its competitors. >>>> >>>> It isn't entirely clear that its *necessary* to bundle the data sharin= g >>>> application with the telepresence protocols. Its kind of limiting sinc= e >>>> the web apps evolve very rapidly. Perhaps we should be doing the >>>> opposite of that: providing a way to embed the control of the >>>> telepresence system into a web app. >>>> >>>> Thanks, >>>> Paul >>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of >>>>>> Paul Kyzivat >>>>>> Sent: Thursday, July 28, 2011 1:29 AM >>>>>> To: clue@ietf.org >>>>>> Subject: Re: [clue] Comment on the presentation use case >>>>>> >>>>>> On 7/27/11 6:07 PM, Roni Even wrote: >>>>>>> Hi Stephane, >>>>>>> >>>>>>> Is there a standard protocol that is used for conveying this >>>>>>> information, is it RTP based. >>>>>> >>>>>> AFAIK this is often http. (E.g. webex) >>>>>> >>>>>>> To me this is a separate application that can be integrated in the >>>>>>> application level and not as part of the multistream. >>>>>> >>>>>> I guess this depends on whether the support for it is integrated >>>> into >>>>>> the "room", or is just incidental equipment brought by the users, >>>> not >>>>>> formally related to the telepresence session. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> (speaking as an individual) >>>>>> >>>>>>> Roni >>>>>>> >>>>>>> *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of >>>>>>> *stephane.cazeaux@orange-ftgroup.com >>>>>>> *Sent:* Thursday, July 21, 2011 2:33 PM >>>>>>> *To:* clue@ietf.org >>>>>>> *Subject:* [clue] Comment on the presentation use case* >>>>>>> >>>>>>> ** >>>>>>> >>>>>>> *Hi,* >>>>>>> >>>>>>> ** >>>>>>> >>>>>>> *The presentation use case as described in the use-cases document >>>> is >>>>>>> based on the assumption that the presentation stream relies on a >>>>>> video >>>>>>> stream, and is limited to usage of presentation video streams. But >>>> we >>>>>>> could also consider collaborative use cases, meaningful for >>>>>>> telepresence, which are not covered by the existing text.* >>>>>>> >>>>>>> *I propose to complete the existing text as follows:* >>>>>>> >>>>>>> ** >>>>>>> >>>>>>> *Furthermore, although most today's systems use video streams for >>>>>>> presentations, there are use cases where this is not suitable. For >>>>>> example:* >>>>>>> >>>>>>> *- The professor which shares an electronic whiteboard (could be a >>>>>>> whiteboard application on a PC, with screen capture of the PC) >>>> where >>>>>> all >>>>>>> students can participate. Students will take control of the shared >>>>>>> whiteboard in turns.* >>>>>>> >>>>>>> *- In a multipoint meeting, a shared document can be kept always >>>>>> visible >>>>>>> in a screen, while other documents are presented on other screens >>>>>> (with >>>>>>> possible in turns presentation). For instance, for the purpose of >>>>>> shared >>>>>>> design document, notes taking, polls, etc. A shared document >>>> implies >>>>>>> that all participants can modify it in turns.* >>>>>>> >>>>>>> *"* >>>>>>> >>>>>>> ** >>>>>>> >>>>>>> ** >>>>>>> >>>>>>> *St ephane. v> >>>>>>> * >>>>>>> >>>>>>> * >>>>>>> * >>>>>>> >>>>>>> *_______________________________________________ >>>>>>> clue mailing list >>>>>>> clue@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>> * >>>>>> >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > From mary.ietf.barnes@gmail.com Fri Oct 7 09:49:31 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A3821F8CC3 for ; Fri, 7 Oct 2011 09:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.475 X-Spam-Level: X-Spam-Status: No, score=-103.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3LG1hIAjThH for ; Fri, 7 Oct 2011 09:49:30 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7531421F8CC2 for ; Fri, 7 Oct 2011 09:49:30 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4091431vcb.31 for ; Fri, 07 Oct 2011 09:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FEVpcg3pPeMpLTDXP1r/zLVJhPyFUj3pr6g1T3t7eso=; b=vXcxYgNGoJJQf83YyskwhVI/MUgVpFxzhrDeV/PD2gpGhiGMuyNrexkDYMOrQ/D/j0 Jvhw3NSbbw8tfisUsDsRn+Zb9NqPKRYo0P5e+6Zl2Qwhdo418KTz+XJHzpgO985U7zlO FIAVQF89oek5P2GxBdW4Id99Gi5AF7SSC1tng= MIME-Version: 1.0 Received: by 10.52.36.197 with SMTP id s5mr3554809vdj.36.1318006364049; Fri, 07 Oct 2011 09:52:44 -0700 (PDT) Received: by 10.52.75.198 with HTTP; Fri, 7 Oct 2011 09:52:44 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C8527D@xmb-sjc-221.amer.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C85189@xmb-sjc-221.amer.cisco.com> <4E8E6B36.9000106@nteczone.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C8527D@xmb-sjc-221.amer.cisco.com> Date: Fri, 7 Oct 2011 11:52:44 -0500 Message-ID: From: Mary Barnes To: "Allyn Romanow (allyn)" Content-Type: multipart/alternative; boundary=20cf307f30782411e004aeb845a3 Cc: clue@ietf.org Subject: Re: [clue] interim meeting-- Requirements doc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 16:49:32 -0000 --20cf307f30782411e004aeb845a3 Content-Type: text/plain; charset=ISO-8859-1 One comment inline below [MB]. Mary. On Thu, Oct 6, 2011 at 11:41 PM, Allyn Romanow (allyn) wrote: > Hi Christian, > Thanks for your comments- > Here are my thoughts on them- > Please see inline. > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > > Sent: Thursday, October 06, 2011 8:00 PM > > To: Allyn Romanow (allyn) > > Cc: clue@ietf.org > > Subject: Re: [clue] interim meeting-- Requirements doc > > > > Hello Allyn, > > > > Unfortunately I won't be at next weeks interim. I'd spend more time in > > the air than at the meeting :-(. > > > > I had two comments on the use cases draft that I didn't get a response > > to which relate to the requirements documents. > > > > 5) Section 3: [CNG] Will there be any attempt to link the requirements > > to certain uses cases?? For example: The RTCWEB requirements document > > indicates which requirements are derived from which use cases. > AR- I don't feel it is necessary, although I know it is a style that > some folks use. If the WG feels it is worthwhile, it can be done. > We had done this in earlier versions as a tool, but removed it in the > most recent draft. > What would be the advantage or usefulness for adding doing it now? > [MB] It would be useful for folks that haven't been involved in the development of the docs that later are trying to understand the work. Given that the text linking the use cases was in the individual version (-03) that was agreed as the basis for the WG document and there was no agreement on the mailing list to remove that text, I think it needs to be added back in until there is WG consensus that the text is not necessarily. [/MB] > > 6) Section 3.x: [CNG] The framework draft sect 6.1 indicates that media > descriptions are dynamic. I.e. capabilities may change. There's nothing > explicit in the requirements to support this. Likewise there doesn't > appear to be a use case to support that. Do we need to add one for > that? > > AR- Yes, I agree with you that there isn't a use case that describes a > receiver taking advantage of a change in encoding characteristics, or > other attributes. I don't feel that there needs to a use case, but we > could add one if people feel it is necessary. > > If you were to put in a requirement for this, it would not be to make > capabilities dynamic, as that is tied to the particular solution > mechanism we are proposing. It would be more along the lines that > endpoints may change the characteristics of what they send.. which > doesn't seem to me to be much of a requirement. > > > Also a couple of additional comments on > > draft-ietf-clue-telepresence-requirements: > > > > REQMT-1b : This talks about two dimensions x,y. Given the recent > > discussions on capture area do we also need to a third dimension z? > > AR- I don't think this has been settled yet. > > > REQMT-2 :Is it also appropriate to add capture area x,y,z > AR - Again, I don't think this has been settled. > > > General : Point of Capture? I couldn't see where this is in the > > requirements? > AR - I think point of capture wouldn't be in the requirements.. it is > part of the necessary mechanism for this proposed solution which enables > spatial arrangement, which is in the requirements. > > Regards, > Allyn > > > > > > Regards, Christian > > > > On 7/10/2011 9:42 AM, Allyn Romanow (allyn) wrote: > > > > > > Hi Folks, > > > > > > Are there issues that people would like to discuss about the > > > requirements doc at the interim meeting next week? > > > > > > Thanks, > > > > > > Allyn > > > > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf307f30782411e004aeb845a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
One comment inline below [MB].
=A0
Mary.

On Thu, Oct 6, 2011 at 11:41 PM, Allyn Romanow (= allyn) <allyn@cisco= .com> wrote:
Hi Christian,
Thanks for your= comments-
Here are my thoughts on them-
Please see inline.

> -----Original Message-----
> From: Christi= an Groves [mailto:Christia= n.Groves@nteczone.com]
> Sent: Thursday, October 06, 2011 8:00 PM=
> To: Allyn Romanow (allyn)
> Cc: clue@ietf.org
> Subject: Re: [clue] interim meeting-- Requiremen= ts doc
>
> Hello Allyn,
>
> Unfortunately I won'= ;t be at next weeks interim. I'd spend more time in
> the air than at the meeting :-(.
>
> I had two comments on= the use cases draft that I didn't get a response
> to which rela= te to the requirements documents.
>
> 5) Section 3: [CNG] Will = there be any attempt to link the requirements
> to certain uses cases?? For example: The RTCWEB requirements document<= br>> indicates which requirements are derived from which use cases.
<= /div>AR- I don't feel it is necessary, although I know it is a style th= at
some folks use. If the WG feels it is worthwhile, it can be done.
We had= done this in earlier versions as a tool, but removed it in the
most rec= ent draft.
What would be the advantage or usefulness for adding doing it= now?
[MB] It would be useful for folks that haven't been involved in th= e=A0development of the docs=A0that later are trying to understand the work.= =A0 Given that the text linking the use cases was in the individual version= (-03) that was agreed as the basis for the WG document and there was no ag= reement on the mailing list to remove that text, I think it needs to be add= ed back in=A0until there is WG consensus that the text is not necessarily. = =A0[/MB]
>
> 6) Section 3.x: [CNG] The framework draft sect 6.1 indicates t= hat
media
> descriptions are dynamic. I.e. capabilities may change= . There's
nothing
> explicit in the requirements to support th= is. Likewise there doesn't
> appear to be a use case to support that. Do we need to add one for
= > that?
>
AR- Yes, I agree with you that t= here isn't a use case that describes a
receiver taking advantage of = a change in encoding characteristics, or
other attributes. I don't feel that there needs to a use case, but wecould add one if people feel it is necessary.

If you were to put i= n a requirement for this, it would not be to make
capabilities dynamic, = as that is tied to the particular solution
mechanism we are proposing. It would be more along the lines that
endpoi= nts may change the characteristics of what they send.. which
doesn't= seem to me to be much of a requirement.

> Also a couple of additional comments on
> = draft-ietf-clue-telepresence-requirements:
>
> REQMT-1b : This = talks about two dimensions x,y. Given the recent
> discussions on cap= ture area do we also need to a third dimension z?

AR- I don't think this has been settled yet.

> REQMT-2 :Is it also appropriate to add capture a= rea x,y,z
AR - Again, I don't think this has been settled.

> General : Point of Capture? I couldn't see w= here this is in the
> requirements?
AR - I think point of ca= pture wouldn't be in the requirements.. it is
part of the necessary = mechanism for this proposed solution which enables
spatial arrangement, which is in the requirements.

Regards,
Allyn


>
> Regards, Christian
>
> O= n 7/10/2011 9:42 AM, Allyn Romanow (allyn) wrote:
> >
> >= Hi Folks,
> >
> > Are there issues that people would lik= e to discuss about the
> > requirements doc at the interim meeting next week?
> >> > Thanks,
> >
> > Allyn
> >
> &g= t;
> >
> > ______________________________________________= _
> > clue mailing list
> > c= lue@ietf.org
> > https://www.ietf.org/mailman/listinfo/clue<= br> _______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailm= an/listinfo/clue

--20cf307f30782411e004aeb845a3-- From bbaldino@cisco.com Fri Oct 7 09:50:55 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5267421F8CC5 for ; Fri, 7 Oct 2011 09:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jMsdKvdWrXy for ; Fri, 7 Oct 2011 09:50:54 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 62D9021F8CC2 for ; Fri, 7 Oct 2011 09:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bbaldino@cisco.com; l=4800; q=dns/txt; s=iport; t=1318006448; x=1319216048; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=d5KNDihJvnpfz1NKlthNIe8xYQCaZbB8rl3TQYvTyDo=; b=F9i3DcR/WkXmzXa2Zq574Xj7CJAI5laxPkb6Il9cHSgG6piDkS2sJa2a 8itHaIh4GNlEGdrD4rrMQ+deyjI+DYtSuxjeMqHvwQepY3lmAgz6RA3/g gtfbTfMScdEsjWZAr9D/OuDnlQK2TPpwYy2qf2cIhDyCF6zzQF3u0Ihrq I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoAAEkuj06rRDoG/2dsb2JhbABEmR+PH4EFgVMBAQEBAwEBAQ8BHQo0BAUCDAQCAQgRBAEBAQoGFwEGASYfCAEIAQEEEwgah2OaDgGeKQOGUGEEh32RI4w3 X-IronPort-AV: E=Sophos;i="4.68,503,1312156800"; d="scan'208";a="6554750" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 07 Oct 2011 16:54:08 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p97Gs4VR003245; Fri, 7 Oct 2011 16:54:06 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 09:54:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Oct 2011 09:54:05 -0700 Message-ID: In-Reply-To: <4E8E67C6.7030603@nteczone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] FW: New Version Notification fordraft-romanow-clue-framework-01.txt thread-index: AcyEmzjHQt0jSTnzQyqb1ehjM+7w+AAdjyoQ References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05B7DE73@xmb-sjc-221.amer.cisco.com><4E8A77E1.1090608@nteczone.com><44C6B6B2D0CF424AA90B6055548D7A61CDF40F79@CRPMBOXPRD01.polycom.com><4E8BD034.40300@nteczone.com><44C6B6B2D0CF424AA90B6055548D7A61CDF41621@CRPMBOXPRD01.polycom.com> <4E8E67C6.7030603@nteczone.com> From: "Brian Baldino (bbaldino)" To: "Christian Groves" , "Duckworth, Mark" X-OriginalArrivalTime: 07 Oct 2011 16:54:06.0435 (UTC) FILETIME=[B9C22B30:01CC8511] Cc: clue@ietf.org Subject: Re: [clue] FW: New Version Notification fordraft-romanow-clue-framework-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 16:50:55 -0000 Forgot to reply directly to Paul but I'd agree that his use case is one where it'd be advantageous to have an up-front description of the entire 'range'. -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves Sent: Thursday, October 06, 2011 7:45 PM To: Duckworth, Mark Cc: clue@ietf.org Subject: Re: [clue] FW: New Version Notification fordraft-romanow-clue-framework-01.txt Hello Mark, Paul Kyzivat's latest email highlights the situation I was thinking=20 about. Whilst the producer only produces one stream it would be=20 advantageous to know how this stream fits into the producers overall=20 system. If the producer sent VC0- (the left camera stream), area_of_capture=3D{xBegin=3D0, = xEnd=3D33}, a 3=20 display consumer may assume that 0-33 represents the entire field of=20 view and place the stream in the centre position when instead it would=20 be more appropriate on the left screen. I think it would be good if the producer could send the capture range=20 for the capture set rather than trying to deduce the range from the=20 individual captures. Currently we only have individual capture attributes, perhaps we need to introduce attributes associated with the capture set? capture area range could be one. Range format (depending on what is decided): i.e. metric,=20 degrees, relational could be another one. Regards, Christian On 6/10/2011 7:16 AM, Duckworth, Mark wrote: >> -----Original Message----- >> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >> Sent: Tuesday, October 04, 2011 11:34 PM >> To: Duckworth, Mark >> Cc: clue@ietf.org >> Subject: Re: [clue] FW: New Version Notification for draft-romanow- >> clue-framework-01.txt >> > ..snip.. >>>> 5.2.4 - Do we need to consider the range start and end when determining >>>> the area of capture? Consider the example Capture Scene(VC0,VC1,VC2) >>>> where: >>>> o VC0- (the left camera stream), = area_of_capture=3D{xBegin=3D0, xEnd=3D33} >>>> o VC1- (the center camera stream), area_of_capture=3D{xBegin=3D33, xEnd=3D66} >>>> o VC2- (the right camera stream), area_of_capture=3D{xBegin=3D66, xEnd=3D99} >>>> This example is clear each capture relates to 1/3 of the overall >>>> capture scene. >>>> >>>> Now if instead the capture scene (VC1) was sent. How does the renderer >>>> put this in context? VC1 is the center capture (thus only 1/3 of the >>>> providers overall capability). The renderer will receieve = xBegin=3D33 and >>>> xEnd=3D66 only and thus conclude its 100% of the capture scene. Do = we need >>>> a means to indicate that the total area is 0 to 99 but the current >>>> capture only relates to a subset? >>> [Duckworth, Mark] I don't think the renderer will reach that >> conclusion. The immediate consumer will know about the whole range 0 >> to 99 from the capture set. If the immediate consumer is also the >> renderer, then the renderer knows. If the immediate consumer is a >> middlebox, then that middlebox becomes the provider for the next >> consumer (renderer). The middlebox constructs its own media captures >> and capture set with its own area of capture attributes. These >> attributes may or may not be the same as from the original providers. >> The middlebox advertises captures and a capture set with attributes >> that make sense for whatever behavior the middlebox is trying to >> provide. So the ultimate consumer (the renderer) will know about >> attributes that make sense in this context from the middlebox. This >> consumer doesn't know about any of the attributes from the original >> producer, it only knows the attributes from the middle box. >> [CNG] I think I wasn't clear in my example. What happens if the received >> capture set only contains VC1 and the consumer didn't previously get a >> capture set (VC0,VC1,VC2)? The middlebox, consumer etc. wouldn't know >> that "area_of_capture=3D{xBegin=3D33,xEnd=3D66}" represents the = centre region >> of a range (0..99). > [Duckworth, Mark] I still don't understand the case you are asking about. Are you saying a media producer advertises a capture set with only VC1 with an area of capture from 33 to 66? No other video captures? If a media producer wants to do this, send only one stream, for some reason, then what does it matter what the area of capture is? There is nothing else to relate it to, so it doesn't matter. > > Regards, > Mark > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From allyn@cisco.com Fri Oct 7 09:55:29 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0277D21F8CCD for ; Fri, 7 Oct 2011 09:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.771 X-Spam-Level: X-Spam-Status: No, score=-2.771 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgDQ9dbwTXF9 for ; Fri, 7 Oct 2011 09:55:26 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 19C6521F8C95 for ; Fri, 7 Oct 2011 09:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=16926; q=dns/txt; s=iport; t=1318006720; x=1319216320; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=f/tJdJn20j8kPcyrsPsjTpijybanKe9UEaQMudA0R44=; b=LaD+at2cKpvUhSGVCmOTyucqgJ2u8ISeG10ZkWQzTFjIOZrgvn612R+w ntfAAayfDBCnseDsD8POn66QSvPRH3Q349sz51yE9yIHgUlZvLPTUDE5y xLr80zVmGUsFu6/3ABz6+EGCcmwJX7SuADC1bs/ZavmDA4jJEAWCqDuOY s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoAAAEvj06rRDoH/2dsb2JhbABEgk2WUo8fgQWBUwEBAQECAQEBAQ8BCREDPgsFBwQCAQgRBAEBAQoGFwEGASAGHwkIAQEEEwgTB4dcB5oWAZ4pA4ZQYQSHfZEjhHGHRg X-IronPort-AV: E=Sophos;i="4.68,503,1312156800"; d="scan'208,217";a="6543824" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 07 Oct 2011 16:58:40 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p97GwduD024661; Fri, 7 Oct 2011 16:58:39 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 09:58:39 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8512.5C57B5A7" Date: Fri, 7 Oct 2011 09:58:36 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42B91@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] interim meeting-- Requirements doc Thread-Index: AcyFEY/rKkUyZE/bTKWn5Ox4L+Lb5wAAHIyA References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C85189@xmb-sjc-221.amer.cisco.com><4E8E6B36.9000106@nteczone.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C8527D@xmb-sjc-221.amer.cisco.com> From: "Allyn Romanow (allyn)" To: "Mary Barnes" X-OriginalArrivalTime: 07 Oct 2011 16:58:39.0513 (UTC) FILETIME=[5C869090:01CC8512] Cc: clue@ietf.org Subject: Re: [clue] interim meeting-- Requirements doc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 16:55:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8512.5C57B5A7 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Mary, It was taken out before it was a WG doc, not after. I'm not even sure if it was in a pre-working group i.e., private draft, it may have been only in pre-submission versions. =20 I'd suggest adding it in, only if there is WG consensus that it is valuable, rather than adding it and then taking it out. =20 From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 Sent: Friday, October 07, 2011 9:53 AM To: Allyn Romanow (allyn) Cc: Christian Groves; clue@ietf.org Subject: Re: [clue] interim meeting-- Requirements doc =20 One comment inline below [MB]. =20 Mary. On Thu, Oct 6, 2011 at 11:41 PM, Allyn Romanow (allyn) wrote: Hi Christian, Thanks for your comments- Here are my thoughts on them- Please see inline. > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Thursday, October 06, 2011 8:00 PM > To: Allyn Romanow (allyn) > Cc: clue@ietf.org > Subject: Re: [clue] interim meeting-- Requirements doc > > Hello Allyn, > > Unfortunately I won't be at next weeks interim. I'd spend more time in > the air than at the meeting :-(. > > I had two comments on the use cases draft that I didn't get a response > to which relate to the requirements documents. > > 5) Section 3: [CNG] Will there be any attempt to link the requirements > to certain uses cases?? For example: The RTCWEB requirements document > indicates which requirements are derived from which use cases. AR- I don't feel it is necessary, although I know it is a style that some folks use. If the WG feels it is worthwhile, it can be done. We had done this in earlier versions as a tool, but removed it in the most recent draft. What would be the advantage or usefulness for adding doing it now? [MB] It would be useful for folks that haven't been involved in the development of the docs that later are trying to understand the work. Given that the text linking the use cases was in the individual version (-03) that was agreed as the basis for the WG document and there was no agreement on the mailing list to remove that text, I think it needs to be added back in until there is WG consensus that the text is not necessarily. [/MB] > > 6) Section 3.x: [CNG] The framework draft sect 6.1 indicates that media > descriptions are dynamic. I.e. capabilities may change. There's nothing > explicit in the requirements to support this. Likewise there doesn't > appear to be a use case to support that. Do we need to add one for > that? > AR- Yes, I agree with you that there isn't a use case that describes a receiver taking advantage of a change in encoding characteristics, or other attributes. I don't feel that there needs to a use case, but we could add one if people feel it is necessary. =09 If you were to put in a requirement for this, it would not be to make capabilities dynamic, as that is tied to the particular solution mechanism we are proposing. It would be more along the lines that endpoints may change the characteristics of what they send.. which doesn't seem to me to be much of a requirement. =09 > Also a couple of additional comments on > draft-ietf-clue-telepresence-requirements: > > REQMT-1b : This talks about two dimensions x,y. Given the recent > discussions on capture area do we also need to a third dimension z? AR- I don't think this has been settled yet. =09 > REQMT-2 :Is it also appropriate to add capture area x,y,z AR - Again, I don't think this has been settled. =09 > General : Point of Capture? I couldn't see where this is in the > requirements? AR - I think point of capture wouldn't be in the requirements.. it is part of the necessary mechanism for this proposed solution which enables spatial arrangement, which is in the requirements. =09 Regards, Allyn =09 =09 > > Regards, Christian > > On 7/10/2011 9:42 AM, Allyn Romanow (allyn) wrote: > > > > Hi Folks, > > > > Are there issues that people would like to discuss about the > > requirements doc at the interim meeting next week? > > > > Thanks, > > > > Allyn > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 ------_=_NextPart_001_01CC8512.5C57B5A7 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Mary,

It was taken out before it was a WG doc, not = after.

I’m not even sure if it was in a pre-working group i.e., = private  draft, it may have been only in pre-submission = versions.

 

I’d suggest adding it in, only if there is WG consensus that it = is valuable, rather than adding it and then taking it = out.

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: Friday, = October 07, 2011 9:53 AM
To: Allyn Romanow = (allyn)
Cc: Christian Groves; clue@ietf.org
Subject: = Re: [clue] interim meeting-- Requirements = doc

 

One = comment inline below [MB].

 

Mary.

On Thu, Oct 6, 2011 at 11:41 PM, Allyn Romanow (allyn) = <allyn@cisco.com> = wrote:

Hi Christian,
Thanks for = your comments-
Here are my thoughts on them-
Please see = inline.


> -----Original = Message-----
> From: Christian Groves [mailto:Christian.Groves@nteczone.c= om]
> Sent: Thursday, October 06, 2011 8:00 PM
> To: = Allyn Romanow (allyn)
> Cc: clue@ietf.org
> Subject: Re: = [clue] interim meeting-- Requirements doc
>
> Hello = Allyn,
>
> Unfortunately I won't be at next weeks interim. = I'd spend more time in
> the air than at the meeting = :-(.
>
> I had two comments on the use cases draft that I = didn't get a response
> to which relate to the requirements = documents.
>
> 5) Section 3: [CNG] Will there be any attempt = to link the requirements
> to certain uses cases?? For example: = The RTCWEB requirements document
> indicates which requirements = are derived from which use cases.

AR- I don't feel it is necessary, although I know it = is a style that
some folks use. If the WG feels it is worthwhile, it = can be done.
We had done this in earlier versions as a tool, but = removed it in the
most recent draft.
What would be the advantage = or usefulness for adding doing it now?

[MB] It would be useful for folks that haven't been = involved in the development of the docs that later are trying = to understand the work.  Given that the text linking the use cases = was in the individual version (-03) that was agreed as the basis for the = WG document and there was no agreement on the mailing list to remove = that text, I think it needs to be added back in until there is WG = consensus that the text is not necessarily.  [/MB]
>
> = 6) Section 3.x: [CNG] The framework draft sect 6.1 indicates = that
media
> descriptions are dynamic. I.e. capabilities may = change. There's
nothing
> explicit in the requirements to = support this. Likewise there doesn't
> appear to be a use case to = support that. Do we need to add one for
> = that?
>

AR- Yes, = I agree with you that there isn't a use case that describes = a
receiver taking advantage of a change in encoding characteristics, = or
other attributes. I don't feel that there needs to a use case, but = we
could add one if people feel it is necessary.

If you were = to put in a requirement for this, it would not be to = make
capabilities dynamic, as that is tied to the particular = solution
mechanism we are proposing. It would be more along the lines = that
endpoints may change the characteristics of what they send.. = which
doesn't seem to me to be much of a = requirement.


> Also a couple of additional = comments on
> = draft-ietf-clue-telepresence-requirements:
>
> REQMT-1b : = This talks about two dimensions x,y. Given the recent
> = discussions on capture area do we also need to a third dimension = z?

AR- I don't think this has = been settled yet.


> = REQMT-2 :Is it also appropriate to add capture area = x,y,z

AR - Again, I don't think = this has been settled.


> = General : Point of Capture? I couldn't see where this is in the
> = requirements?

AR - I think = point of capture wouldn't be in the requirements.. it is
part of the = necessary mechanism for this proposed solution which enables
spatial = arrangement, which is in the requirements.

Regards,
Allyn



>
> Regards, = Christian
>
> On 7/10/2011 9:42 AM, Allyn Romanow (allyn) = wrote:
> >
> > Hi Folks,
> >
> > Are = there issues that people would like to discuss about the
> > = requirements doc at the interim meeting next week?
> >
> = > Thanks,
> >
> > Allyn
> >
> = >
> >
> > = _______________________________________________
> > clue = mailing list
> > clue@ietf.org
> > https://www.ietf.org/mailman/listinfo/clue
_____= __________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

 

------_=_NextPart_001_01CC8512.5C57B5A7-- From mary.ietf.barnes@gmail.com Fri Oct 7 10:25:08 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E3821F8C86 for ; Fri, 7 Oct 2011 10:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.477 X-Spam-Level: X-Spam-Status: No, score=-103.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mT+j4pPlPGVL for ; Fri, 7 Oct 2011 10:25:07 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA1F21F8C73 for ; Fri, 7 Oct 2011 10:25:07 -0700 (PDT) Received: by vws5 with SMTP id 5so4124532vws.31 for ; Fri, 07 Oct 2011 10:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+umoXp+sYH6IMTGPJ1wiO+2ojDOy9QxP7dkQr1Y67wo=; b=NUVf8BV2VqOVJn6G31pCimcksPqWlWjLfU0a7rBQAbzoR4KC+NBhwJSOWVGhkaqtq0 PqUWAL393sgj1W6EDA5shyTs1bVRuxPy3M5zqtl90RX/KzZfGvG2KystaZk3BDuHI+k3 8bw1YQlL7vfu/rUyvuYYWLwYR7R+gBuatGoQ0= MIME-Version: 1.0 Received: by 10.52.113.67 with SMTP id iw3mr3646433vdb.121.1318008500913; Fri, 07 Oct 2011 10:28:20 -0700 (PDT) Received: by 10.52.75.198 with HTTP; Fri, 7 Oct 2011 10:28:20 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42B91@xmb-sjc-221.amer.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C85189@xmb-sjc-221.amer.cisco.com> <4E8E6B36.9000106@nteczone.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C8527D@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42B91@xmb-sjc-221.amer.cisco.com> Date: Fri, 7 Oct 2011 12:28:20 -0500 Message-ID: From: Mary Barnes To: "Allyn Romanow (allyn)" Content-Type: multipart/alternative; boundary=bcaec547ca0182061704aeb8c4e0 Cc: clue@ietf.org Subject: Re: [clue] interim meeting-- Requirements doc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 17:25:09 -0000 --bcaec547ca0182061704aeb8c4e0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The diff shows that the text was removed between the -03 of the individual and the -00 of the WG document: http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-clue-te= lepresence-requirements-00.txt It was the - 03 that was agreed as the basis of the WG document, which mean= s that any changes beyond those discussed/agreed at the meeting (per the minutes) should have been discussed on the mailing list: http://tools.ietf.org/wg/clue/minutes?item=3Dminutes81.html Mary. On Fri, Oct 7, 2011 at 11:58 AM, Allyn Romanow (allyn) wro= te: > Hi Mary,**** > > It was taken out before it was a WG doc, not after.**** > > I=92m not even sure if it was in a pre-working group i.e., private draft= , it > may have been only in pre-submission versions.**** > > ** ** > > I=92d suggest adding it in, only if there is WG consensus that it is > valuable, rather than adding it and then taking it out.**** > > ** ** > > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* Friday, October 07, 2011 9:53 AM > *To:* Allyn Romanow (allyn) > *Cc:* Christian Groves; clue@ietf.org > > *Subject:* Re: [clue] interim meeting-- Requirements doc**** > > ** ** > > One comment inline below [MB].**** > > **** > > Mary.**** > > On Thu, Oct 6, 2011 at 11:41 PM, Allyn Romanow (allyn) > wrote:**** > > Hi Christian, > Thanks for your comments- > Here are my thoughts on them- > Please see inline.**** > > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > > Sent: Thursday, October 06, 2011 8:00 PM > > To: Allyn Romanow (allyn) > > Cc: clue@ietf.org > > Subject: Re: [clue] interim meeting-- Requirements doc > > > > Hello Allyn, > > > > Unfortunately I won't be at next weeks interim. I'd spend more time in > > the air than at the meeting :-(. > > > > I had two comments on the use cases draft that I didn't get a response > > to which relate to the requirements documents. > > > > 5) Section 3: [CNG] Will there be any attempt to link the requirements > > to certain uses cases?? For example: The RTCWEB requirements document > > indicates which requirements are derived from which use cases.**** > > AR- I don't feel it is necessary, although I know it is a style that > some folks use. If the WG feels it is worthwhile, it can be done. > We had done this in earlier versions as a tool, but removed it in the > most recent draft. > What would be the advantage or usefulness for adding doing it now?**** > > [MB] It would be useful for folks that haven't been involved in > the development of the docs that later are trying to understand the work. > Given that the text linking the use cases was in the individual version > (-03) that was agreed as the basis for the WG document and there was no > agreement on the mailing list to remove that text, I think it needs to be > added back in until there is WG consensus that the text is not necessaril= y. > [/MB] > > > > 6) Section 3.x: [CNG] The framework draft sect 6.1 indicates that > media > > descriptions are dynamic. I.e. capabilities may change. There's > nothing > > explicit in the requirements to support this. Likewise there doesn't > > appear to be a use case to support that. Do we need to add one for > > that? > >**** > > AR- Yes, I agree with you that there isn't a use case that describes a > receiver taking advantage of a change in encoding characteristics, or > other attributes. I don't feel that there needs to a use case, but we > could add one if people feel it is necessary. > > If you were to put in a requirement for this, it would not be to make > capabilities dynamic, as that is tied to the particular solution > mechanism we are proposing. It would be more along the lines that > endpoints may change the characteristics of what they send.. which > doesn't seem to me to be much of a requirement.**** > > > > Also a couple of additional comments on > > draft-ietf-clue-telepresence-requirements: > > > > REQMT-1b : This talks about two dimensions x,y. Given the recent > > discussions on capture area do we also need to a third dimension z?**** > > AR- I don't think this has been settled yet.**** > > > > REQMT-2 :Is it also appropriate to add capture area x,y,z**** > > AR - Again, I don't think this has been settled.**** > > > > General : Point of Capture? I couldn't see where this is in the > > requirements?**** > > AR - I think point of capture wouldn't be in the requirements.. it is > part of the necessary mechanism for this proposed solution which enables > spatial arrangement, which is in the requirements. > > Regards, > Allyn**** > > > > > > > Regards, Christian > > > > On 7/10/2011 9:42 AM, Allyn Romanow (allyn) wrote: > > > > > > Hi Folks, > > > > > > Are there issues that people would like to discuss about the > > > requirements doc at the interim meeting next week? > > > > > > Thanks, > > > > > > Allyn > > > > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > ** ** > --bcaec547ca0182061704aeb8c4e0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The diff shows that the text was removed between the -03 of the individual = and the -00 of the WG document:=A0
http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddra= ft-ietf-clue-telepresence-requirements-00.txt

It was the - 03 that was agreed as the basis of the WG = document, which means that any changes beyond those discussed/agreed at the= meeting (per the minutes) should have been discussed on the mailing list:<= /div>
http://tools.ietf.org/wg/clue/minutes?item=3Dminutes81.html
<= br>
Mary.=A0

On Fri, Oct 7, 2011 at 11:58 AM, Allyn Romanow (= allyn) <allyn@cisco.com> wrote:

Hi Mary= ,

It was = taken out before it was a WG doc, not after.

I=92m n= ot even sure if it was in a pre-working group i.e., private =A0draft, it ma= y have been only in pre-submission versions.

= =A0

I=92d s= uggest adding it in, only if there is WG consensus that it is valuable, rat= her than adding it and then taking it out.

= =A0

From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
= Sent: Friday, October 07, 2011 9:53 AM
To: Allyn Romanow (allyn)
Cc: Christian Groves; clue@ietf.org=20


Subject: Re: [clue] interim meeting-- Requirements doc

=A0

One comment inline below [MB].

=A0

Mary.

=

On Thu, Oct 6, 2011 at 11:41 PM, Allyn Romanow (ally= n) <allyn@cisco.com= > wrote:

Hi Christian,
Thanks for your comments-
Here a= re my thoughts on them-
Please see inline.


> -----Original Message-----
> From: Ch= ristian Groves [mailto:Christian.Groves@nteczone.com]
> Sent: Thursday, O= ctober 06, 2011 8:00 PM
> To: Allyn Romanow (allyn)
> Cc: clue@ietf.org
> Subject: Re: [clue] interim me= eting-- Requirements doc
>
> Hello Allyn,
>
> Unfor= tunately I won't be at next weeks interim. I'd spend more time in > the air than at the meeting :-(.
>
> I had two comments on= the use cases draft that I didn't get a response
> to which rela= te to the requirements documents.
>
> 5) Section 3: [CNG] Will = there be any attempt to link the requirements
> to certain uses cases?? For example: The RTCWEB requirements document<= br>> indicates which requirements are derived from which use cases.

AR- I don't feel it is necessary, although I kno= w it is a style that
some folks use. If the WG feels it is worthwhile, i= t can be done.
We had done this in earlier versions as a tool, but remov= ed it in the
most recent draft.
What would be the advantage or usefulness for adding = doing it now?

[MB] It would be useful for folks that haven't b= een involved in the=A0development of the docs=A0that later are trying to un= derstand the work.=A0 Given that the text linking the use cases was in the = individual version (-03) that was agreed as the basis for the WG document a= nd there was no agreement on the mailing list to remove that text, I think = it needs to be added back in=A0until there is WG consensus that the text is= not necessarily. =A0[/MB]
>
> 6) Section 3.x: [CNG] The framework draft sect 6.1 indicates t= hat
media
> descriptions are dynamic. I.e. capabilities may change= . There's
nothing
> explicit in the requirements to support th= is. Likewise there doesn't
> appear to be a use case to support that. Do we need to add one for
= > that?
>

AR- Yes, I agree with you that there isn't a use= case that describes a
receiver taking advantage of a change in encoding= characteristics, or
other attributes. I don't feel that there needs= to a use case, but we
could add one if people feel it is necessary.

If you were to put in = a requirement for this, it would not be to make
capabilities dynamic, as= that is tied to the particular solution
mechanism we are proposing. It = would be more along the lines that
endpoints may change the characteristics of what they send.. which
doesn= 't seem to me to be much of a requirement.


> Also a couple = of additional comments on
> draft-ietf-clue-telepresence-requirements= :
>
> REQMT-1b : This talks about two dimensions x,y. Given the= recent
> discussions on capture area do we also need to a third dimension z?=

AR- I don't think this has been settled yet.<= /u>


> REQMT-2 :Is it also appropriate to add capt= ure area x,y,z

AR - Again, I don't think this has been settled.=


> General : Point of Capture? I couldn't = see where this is in the
> requirements?

AR - I think point of capture wouldn't be in the= requirements.. it is
part of the necessary mechanism for this proposed = solution which enables
spatial arrangement, which is in the requirements= .

Regards,
Allyn



>
> Regards, Christian
>
&= gt; On 7/10/2011 9:42 AM, Allyn Romanow (allyn) wrote:
> >
>= > Hi Folks,
> >
> > Are there issues that people woul= d like to discuss about the
> > requirements doc at the interim meeting next week?
> >> > Thanks,
> >
> > Allyn
> >
> &g= t;
> >
> > ______________________________________________= _
> > clue mailing list
> > clue@ietf.org
> > https://www.ietf.org/mailman/= listinfo/clue
_______________________________________________
clue mailing list
clue@ietf.org
https://= www.ietf.org/mailman/listinfo/clue

=A0


--bcaec547ca0182061704aeb8c4e0-- From Mark.Duckworth@polycom.com Fri Oct 7 10:47:43 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D3C21F8AF7 for ; Fri, 7 Oct 2011 10:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.622 X-Spam-Level: X-Spam-Status: No, score=-6.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lx9JCwy7bOC for ; Fri, 7 Oct 2011 10:47:42 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADA121F8A69 for ; Fri, 7 Oct 2011 10:47:40 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Fri, 7 Oct 2011 10:50:53 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 7 Oct 2011 10:50:50 -0700 Thread-Topic: [clue] the presentation use case Thread-Index: AcxHlL8VW+C7KhbYQU2HJX/U8MKZpAFFKK/A///k6YCAAFO3gIAACg4AgAAqsQCAAFTQgP/uhI7ggCNGD4D/+k3aoIALuqeA/6gpJ1D/T+EmUA== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61CE060BFF@CRPMBOXPRD01.polycom.com> References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com><4E309135.7070408@alum.mit.edu><001b01cc4cd6$77d28760$67779620$%roni@huawei.com> <4E30DFDE.3040601@alum.mit.edu> <9ECCF01B52E7AB408A7EB85352642141031F2E5E@ftrdmel0.rd.francetelecom.fr> <4E314AD3.1030406@alum.mit.edu> <4E403783.70706@alum.mit.edu> <4E454723.4080501@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_44C6B6B2D0CF424AA90B6055548D7A61CE060BFFCRPMBOXPRD01pol_" MIME-Version: 1.0 Subject: Re: [clue] the presentation use case X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 17:47:43 -0000 --_002_44C6B6B2D0CF424AA90B6055548D7A61CE060BFFCRPMBOXPRD01pol_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi St=E9phane, The CLUE framework is intended to handle any media type that is carried ove= r RTP. The framework document should be relating to "media captures" and "= media streams" in general, except when there is a need to be more specific = about video or audio or any other media type. There are probably some plac= es in the document where it would be better to be more general, to make sur= e it applies to any media type where appropriate. So if you want to send excel sheet data over RTP, then CLUE should be able = to handle it regarding associating it with audio or giving it some spatial = relationship to other media streams, for example. I think this is as far as CLUE should go with regard to document sharing. = I think additional use cases about document sharing are not relevant to CLU= E. My thinking is based on this statement from the CLUE charter: "The focus of this work is on multiple RTP audio and video streams. Other = media types may be considered, however development of methodologies for the= m is not within the scope of this work." Regards, Mark Duckworth > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > stephane.cazeaux@orange.com > Sent: Friday, October 07, 2011 7:25 AM > To: clue@ietf.org > Subject: [clue] the presentation use case >=20 > Hi >=20 > I will not be able to attend physically to the interim meeting. >=20 > However I had a comment on the presentation use case, which I still > consider we need to agree on. > In the use case draft, the presentation use case is restricted to the > video based solution. To me, it should be modified so that: > - It does not restrict the solution to the video > - It includes the need to share any kind of documents (including > complex documents such as excel sheets) and the ability to have remote > control >=20 > See below the discussion. >=20 > Regards, > St=E9phane. >=20 >=20 >=20 > -----Message d'origine----- > De=A0: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Envoy=E9=A0: vendredi 12 ao=FBt 2011 17:31 > =C0=A0: CAZEAUX Stephane RD-BIZZ-CAE > Cc=A0: clue@ietf.org > Objet=A0: Re: [clue] Comment on the presentation use case >=20 > On 8/12/11 4:48 AM, stephane.cazeaux@orange-ftgroup.com wrote: > > Hi Paul, > > > > I understand your suggestion, and I am aware that it could be a > solution. It certainly makes sense, but I am not sure of how it could > be integrated in CLUE. To me, this is a matter of application > integration, at application level. > > > > My suggestion is that we should think of a solution that provides > more satisfying collaboration within telepresence, with the same level > of interoperability and multistream interaction as presentation video > stream provides, but with more satisfying quality (video is not > suitable for all kinds of shared documents) and more collaborative > features. > > I don't think that the kind of relationship that you suggest is the > only solution. >=20 > IMO the main thing is to not constrain the mechanism used for > collaboration/web sharing. That stuff is evolving at "web speed". > Anything you nail down that is constraining will be obsolete before it > gets out. >=20 > (I've been looking more at RTCWEB recently, and I'm wondering if > perhaps > CLUE ought to be based on that.) >=20 > Thanks, > Paul (as individual) >=20 > > Stephane. > > > > > > -----Message d'origine----- > > De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Envoy=E9 : lundi 8 ao=FBt 2011 21:23 > > =C0 : CAZEAUX Stephane RD-BIZZ-CAE > > Cc : clue@ietf.org > > Objet : Re: [clue] Comment on the presentation use case > > > > On 8/8/11 11:56 AM, stephane.cazeaux@orange-ftgroup.com wrote: > >> Hi, > >> > >> To me, it should be part of the telepresence protocols at least to > enable the interoperability, as the presentation based on video stream > allows it. > >> > >> The point is that video stream is not convenient for the use cases I > suggested. But it does not necessarily mean that we should bundle a > full data sharing protocol with telepresence. Something simpler, like > the RFB option of draft-garcia-mmusic-sdp-collaboration, could be a > candidate. > > > > What I was suggesting is that maybe it would make sense to turn those > > relationships "inside out". > > > > For instance when I use a collaboration tool like Webex, the > > collaboration is set up first via the web, and defines the set of > > participants. Then a voice session can be added. For pragmatic > reasons, > > the voice conferencing seems to be pretty distinct. (I'm not certain > how > > webex handles video. I suspect it is doing it via the web, not the > > telephony conference.) > > > > Its not hard to imagine the same sort of setup, but with a multiparty > > telepresence session instead of the traditional voice conference. In > > such a case, you would probably want the collaboration tool (webex, > or > > whatever) to mediate the UI for the web collaboration, the roster, > etc. > > It might delegate a lot of that to the telepresence infrastructure. > > > > But that does raise some questions about how all the components fit > > together. Is there a single screen for the collaboration session in a > > telepresence room? What about input to that - keyboard, mouse, etc.? > Or > > do we assume that each person in the room has their own computer with > > input, display, etc. and maybe a way to slave the web collaboration > > session to one or more of the big displays in the room? > > > > What probably *can't* be done right now is nail down a particular web > > collaboration service (e.g. Webex) or protocol. That does complicate > > slaving the collaboration session to a screen, unless its done by > having > > someone connect a video connection to their own computer. > > > > Thanks, > > Paul > > > >> Stephane. > >> > >> > >> -----Message d'origine----- > >> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part > de Paul Kyzivat > >> Envoy=E9 : jeudi 28 juillet 2011 13:41 > >> =C0 : CHATRAS Bruno RD-CORE-ISS > >> Cc : clue@ietf.org > >> Objet : Re: [clue] Comment on the presentation use case > >> > >> On 7/28/11 2:37 AM, bruno.chatras@orange-ftgroup.com wrote: > >>> I think we should take a look to > >>> http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration-00 > >> > >> Maybe. But that is almost orthogonal to what I was suggesting. > >> > >> THanks, > >> Paul > >> (as individual) > >> > >>> Bruno > >>> > >>>> -----Message d'origine----- > >>>> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la > part de > >>>> Paul Kyzivat > >>>> Envoy=E9 : jeudi 28 juillet 2011 06:05 > >>>> =C0 : Roni Even > >>>> Cc : clue@ietf.org > >>>> Objet : Re: [clue] Comment on the presentation use case > >>>> > >>>> On 7/27/11 11:28 PM, Roni Even wrote: > >>>>> Hi, > >>>>> HTTP is not defining a common data sharing protocol. WebEx may be > >>>> carried > >>>>> over HTTP but the data sharing application is not standard. What > I > >>>> meant is > >>>>> that it can either be something that is a common data sharing > >>>> protocol or > >>>>> something that is carried as an RTP payload which require some > common > >>>>> defined protocol on top. > >>>> > >>>> I was being a bit tongue in cheek, though not entirely. > >>>> Of course you are right - that if you want to push data to > everybody > >>>> you > >>>> need more. > >>>> > >>>> But data sharing by pointing a video camera at a piece of paper is > a > >>>> tad > >>>> out of date. Connecting the video port on a user's computer as a > video > >>>> source and distributing it with the other video is better than > that. > >>>> But > >>>> its not nearly as convenient as webex or any of its competitors. > >>>> > >>>> It isn't entirely clear that its *necessary* to bundle the data > sharing > >>>> application with the telepresence protocols. Its kind of limiting > since > >>>> the web apps evolve very rapidly. Perhaps we should be doing the > >>>> opposite of that: providing a way to embed the control of the > >>>> telepresence system into a web app. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>>> -----Original Message----- > >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > >>>> Of > >>>>>> Paul Kyzivat > >>>>>> Sent: Thursday, July 28, 2011 1:29 AM > >>>>>> To: clue@ietf.org > >>>>>> Subject: Re: [clue] Comment on the presentation use case > >>>>>> > >>>>>> On 7/27/11 6:07 PM, Roni Even wrote: > >>>>>>> Hi Stephane, > >>>>>>> > >>>>>>> Is there a standard protocol that is used for conveying this > >>>>>>> information, is it RTP based. > >>>>>> > >>>>>> AFAIK this is often http. (E.g. webex) > >>>>>> > >>>>>>> To me this is a separate application that can be integrated in > the > >>>>>>> application level and not as part of the multistream. > >>>>>> > >>>>>> I guess this depends on whether the support for it is integrated > >>>> into > >>>>>> the "room", or is just incidental equipment brought by the > users, > >>>> not > >>>>>> formally related to the telepresence session. > >>>>>> > >>>>>> Thanks, > >>>>>> Paul > >>>>>> (speaking as an individual) > >>>>>> > >>>>>>> Roni > >>>>>>> > >>>>>>> *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > Behalf Of > >>>>>>> *stephane.cazeaux@orange-ftgroup.com > >>>>>>> *Sent:* Thursday, July 21, 2011 2:33 PM > >>>>>>> *To:* clue@ietf.org > >>>>>>> *Subject:* [clue] Comment on the presentation use case* > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> *Hi,* > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> *The presentation use case as described in the use-cases > document > >>>> is > >>>>>>> based on the assumption that the presentation stream relies on > a > >>>>>> video > >>>>>>> stream, and is limited to usage of presentation video streams. > But > >>>> we > >>>>>>> could also consider collaborative use cases, meaningful for > >>>>>>> telepresence, which are not covered by the existing text.* > >>>>>>> > >>>>>>> *I propose to complete the existing text as follows:* > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> *Furthermore, although most today's systems use video streams > for > >>>>>>> presentations, there are use cases where this is not suitable. > For > >>>>>> example:* > >>>>>>> > >>>>>>> *- The professor which shares an electronic whiteboard (could > be a > >>>>>>> whiteboard application on a PC, with screen capture of the PC) > >>>> where > >>>>>> all > >>>>>>> students can participate. Students will take control of the > shared > >>>>>>> whiteboard in turns.* > >>>>>>> > >>>>>>> *- In a multipoint meeting, a shared document can be kept > always > >>>>>> visible > >>>>>>> in a screen, while other documents are presented on other > screens > >>>>>> (with > >>>>>>> possible in turns presentation). For instance, for the purpose > of > >>>>>> shared > >>>>>>> design document, notes taking, polls, etc. A shared document > >>>> implies > >>>>>>> that all participants can modify it in turns.* > >>>>>>> > >>>>>>> *"* > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> *St ephane. v> > >>>>>>> * > >>>>>>> > >>>>>>> * > >>>>>>> * > >>>>>>> > >>>>>>> *_______________________________________________ > >>>>>>> clue mailing list > >>>>>>> clue@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>>>> * > >>>>>> > >>>>>> _______________________________________________ > >>>>>> clue mailing list > >>>>>> clue@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --_002_44C6B6B2D0CF424AA90B6055548D7A61CE060BFFCRPMBOXPRD01pol_ Content-Type: message/rfc822 Received: from polycom.com (192.168.33.25) by crpehubprd02.polycom.com (10.236.0.154) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 7 Oct 2011 09:03:45 -0700 Received: from ([12.22.58.30]) by mailgate1.polycom.com with ESMTP id 3HWXDG1.144249895; Fri, 07 Oct 2011 09:03:42 -0700 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C993B21F8C96; Fri, 7 Oct 2011 09:00:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE0B21F8A62 for ; Fri, 7 Oct 2011 04:22:07 -0700 (PDT) Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XKi+Lmp6Lh2 for ; Fri, 7 Oct 2011 04:22:06 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id C3D5B21F8997 for ; Fri, 7 Oct 2011 04:22:05 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 601BC8B8006 for ; Fri, 7 Oct 2011 13:26:39 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 4FFBE8B8003 for ; Fri, 7 Oct 2011 13:26:39 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr ([10.194.32.11]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 13:25:16 +0200 Received: from FTRDMB03.rd.francetelecom.fr ([fe80::4c06:6ece:ed2d:797e]) by FTRDCH01.rd.francetelecom.fr ([::1]) with mapi id 14.01.0270.001; Fri, 7 Oct 2011 13:25:16 +0200 From: "stephane.cazeaux@orange.com" To: "clue@ietf.org" Sender: "clue-bounces@ietf.org" Date: Fri, 7 Oct 2011 04:25:16 -0700 Subject: [clue] the presentation use case Thread-Topic: [clue] the presentation use case Thread-Index: AcxHlL8VW+C7KhbYQU2HJX/U8MKZpAFFKK/A///k6YCAAFO3gIAACg4AgAAqsQCAAFTQgP/uhI7ggCNGD4D/+k3aoIALuqeA/6gpJ1A= Message-ID: References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com><4E309135.7070408@alum.mit.edu><001b01cc4cd6$77d28760$67779620$%roni@huawei.com> <4E30DFDE.3040601@alum.mit.edu> <9ECCF01B52E7AB408A7EB85352642141031F2E5E@ftrdmel0.rd.francetelecom.fr> <4E314AD3.1030406@alum.mit.edu> <4E403783.70706@alum.mit.edu> <4E454723.4080501@alum.mit.edu> List-Help: List-Subscribe: , List-Unsubscribe: , In-Reply-To: <4E454723.4080501@alum.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: crpehubprd02.polycom.com X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US x-originalarrivaltime: 07 Oct 2011 11:25:16.0606 (UTC) FILETIME=[C9DD2DE0:01CC84E3] x-esp: ESP<-41>= SHA:<0> SHA_FLAGS:<0> UHA:<9> ISC:<0> BAYES:<-1> SenderID:<-1> DKIM:<1> TS:<-49> SIG: DSC:<0> TRU_spam1: <0> TRU_scam_spam: <0> TRU_money_spam: <0> TRU_profanity_spam: <0> TRU_medical_spam: <0> TRU_urllinks: <0> URL Real-Time Signatures: <0> TRU_html_image_spam: <0> TRU_ru_spamsubj: <0> TRU_freehosting: <0> TRU_watch_spam: <0> TRU_embedded_image_spam: <0> TRU_lotto_spam: <0> TRU_legal_spam: <0> TRU_adult_spam: <0> TRU_stock_spam: <0> TRU_spam2: <0> TRU_playsites: <0> TRU_misc_spam: <0> TRU_marketing_spam: <0> TRU_phish_spam: <0> x-originating-ip: [10.193.193.118] delivered-to: clue@ietfa.amsl.com errors-to: clue-bounces@ietf.org dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1318003227; bh=5DyQhvrTS4xN4rHuRyEOsJDUI0w7YlD97uxDxGT28lk=; h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=YrDFgCq7GHLR3bIY9XEqwCW61LBToJBPbrvHLWgmoOgbPPV507FLtl0eXtNWCFU0R vdB/6OMRjy0xCTIzVhMZLDQB/8J1eyPm5rOiaqYzH/PwpVLAj/s2BekZ0dkAObxxn5 X1mYDoApOiu2uHVU+POT6COJGZUc0xL42kHS/QzA= x-spam-flag: NO x-spam-status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] x-spam-level: x-virus-scanned: amavisd-new at amsl.com x-spam-score: -2.249 list-id: CLUE - ControLling mUltiple streams for TElepresence list-archive: list-post: x-original-to: clue@ietfa.amsl.com x-beenthere: clue@ietf.org x-mailman-version: 2.1.12 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hi I will not be able to attend physically to the interim meeting. However I had a comment on the presentation use case, which I still conside= r we need to agree on. In the use case draft, the presentation use case is restricted to the video= based solution. To me, it should be modified so that: - It does not restrict the solution to the video - It includes the need to share any kind of documents (including complex do= cuments such as excel sheets) and the ability to have remote control See below the discussion. Regards, St=E9phane. -----Message d'origine----- De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Envoy=E9 : vendredi 12 ao=FBt 2011 17:31 =C0 : CAZEAUX Stephane RD-BIZZ-CAE Cc : clue@ietf.org Objet : Re: [clue] Comment on the presentation use case On 8/12/11 4:48 AM, stephane.cazeaux@orange-ftgroup.com wrote: > Hi Paul, > > I understand your suggestion, and I am aware that it could be a solution.= It certainly makes sense, but I am not sure of how it could be integrated = in CLUE. To me, this is a matter of application integration, at application= level. > > My suggestion is that we should think of a solution that provides more sa= tisfying collaboration within telepresence, with the same level of interope= rability and multistream interaction as presentation video stream provides,= but with more satisfying quality (video is not suitable for all kinds of s= hared documents) and more collaborative features. > I don't think that the kind of relationship that you suggest is the only = solution. IMO the main thing is to not constrain the mechanism used for collaboration/web sharing. That stuff is evolving at "web speed". Anything you nail down that is constraining will be obsolete before it gets out. (I've been looking more at RTCWEB recently, and I'm wondering if perhaps CLUE ought to be based on that.) Thanks, Paul (as individual) > Stephane. > > > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Envoy=E9 : lundi 8 ao=FBt 2011 21:23 > =C0 : CAZEAUX Stephane RD-BIZZ-CAE > Cc : clue@ietf.org > Objet : Re: [clue] Comment on the presentation use case > > On 8/8/11 11:56 AM, stephane.cazeaux@orange-ftgroup.com wrote: >> Hi, >> >> To me, it should be part of the telepresence protocols at least to enabl= e the interoperability, as the presentation based on video stream allows it= . >> >> The point is that video stream is not convenient for the use cases I sug= gested. But it does not necessarily mean that we should bundle a full data = sharing protocol with telepresence. Something simpler, like the RFB option = of draft-garcia-mmusic-sdp-collaboration, could be a candidate. > > What I was suggesting is that maybe it would make sense to turn those > relationships "inside out". > > For instance when I use a collaboration tool like Webex, the > collaboration is set up first via the web, and defines the set of > participants. Then a voice session can be added. For pragmatic reasons, > the voice conferencing seems to be pretty distinct. (I'm not certain how > webex handles video. I suspect it is doing it via the web, not the > telephony conference.) > > Its not hard to imagine the same sort of setup, but with a multiparty > telepresence session instead of the traditional voice conference. In > such a case, you would probably want the collaboration tool (webex, or > whatever) to mediate the UI for the web collaboration, the roster, etc. > It might delegate a lot of that to the telepresence infrastructure. > > But that does raise some questions about how all the components fit > together. Is there a single screen for the collaboration session in a > telepresence room? What about input to that - keyboard, mouse, etc.? Or > do we assume that each person in the room has their own computer with > input, display, etc. and maybe a way to slave the web collaboration > session to one or more of the big displays in the room? > > What probably *can't* be done right now is nail down a particular web > collaboration service (e.g. Webex) or protocol. That does complicate > slaving the collaboration session to a screen, unless its done by having > someone connect a video connection to their own computer. > > Thanks, > Paul > >> Stephane. >> >> >> -----Message d'origine----- >> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de = Paul Kyzivat >> Envoy=E9 : jeudi 28 juillet 2011 13:41 >> =C0 : CHATRAS Bruno RD-CORE-ISS >> Cc : clue@ietf.org >> Objet : Re: [clue] Comment on the presentation use case >> >> On 7/28/11 2:37 AM, bruno.chatras@orange-ftgroup.com wrote: >>> I think we should take a look to >>> http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration-00 >> >> Maybe. But that is almost orthogonal to what I was suggesting. >> >> THanks, >> Paul >> (as individual) >> >>> Bruno >>> >>>> -----Message d'origine----- >>>> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part d= e >>>> Paul Kyzivat >>>> Envoy=E9 : jeudi 28 juillet 2011 06:05 >>>> =C0 : Roni Even >>>> Cc : clue@ietf.org >>>> Objet : Re: [clue] Comment on the presentation use case >>>> >>>> On 7/27/11 11:28 PM, Roni Even wrote: >>>>> Hi, >>>>> HTTP is not defining a common data sharing protocol. WebEx may be >>>> carried >>>>> over HTTP but the data sharing application is not standard. What I >>>> meant is >>>>> that it can either be something that is a common data sharing >>>> protocol or >>>>> something that is carried as an RTP payload which require some common >>>>> defined protocol on top. >>>> >>>> I was being a bit tongue in cheek, though not entirely. >>>> Of course you are right - that if you want to push data to everybody >>>> you >>>> need more. >>>> >>>> But data sharing by pointing a video camera at a piece of paper is a >>>> tad >>>> out of date. Connecting the video port on a user's computer as a video >>>> source and distributing it with the other video is better than that. >>>> But >>>> its not nearly as convenient as webex or any of its competitors. >>>> >>>> It isn't entirely clear that its *necessary* to bundle the data sharin= g >>>> application with the telepresence protocols. Its kind of limiting sinc= e >>>> the web apps evolve very rapidly. Perhaps we should be doing the >>>> opposite of that: providing a way to embed the control of the >>>> telepresence system into a web app. >>>> >>>> Thanks, >>>> Paul >>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of >>>>>> Paul Kyzivat >>>>>> Sent: Thursday, July 28, 2011 1:29 AM >>>>>> To: clue@ietf.org >>>>>> Subject: Re: [clue] Comment on the presentation use case >>>>>> >>>>>> On 7/27/11 6:07 PM, Roni Even wrote: >>>>>>> Hi Stephane, >>>>>>> >>>>>>> Is there a standard protocol that is used for conveying this >>>>>>> information, is it RTP based. >>>>>> >>>>>> AFAIK this is often http. (E.g. webex) >>>>>> >>>>>>> To me this is a separate application that can be integrated in the >>>>>>> application level and not as part of the multistream. >>>>>> >>>>>> I guess this depends on whether the support for it is integrated >>>> into >>>>>> the "room", or is just incidental equipment brought by the users, >>>> not >>>>>> formally related to the telepresence session. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> (speaking as an individual) >>>>>> >>>>>>> Roni >>>>>>> >>>>>>> *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of >>>>>>> *stephane.cazeaux@orange-ftgroup.com >>>>>>> *Sent:* Thursday, July 21, 2011 2:33 PM >>>>>>> *To:* clue@ietf.org >>>>>>> *Subject:* [clue] Comment on the presentation use case* >>>>>>> >>>>>>> ** >>>>>>> >>>>>>> *Hi,* >>>>>>> >>>>>>> ** >>>>>>> >>>>>>> *The presentation use case as described in the use-cases document >>>> is >>>>>>> based on the assumption that the presentation stream relies on a >>>>>> video >>>>>>> stream, and is limited to usage of presentation video streams. But >>>> we >>>>>>> could also consider collaborative use cases, meaningful for >>>>>>> telepresence, which are not covered by the existing text.* >>>>>>> >>>>>>> *I propose to complete the existing text as follows:* >>>>>>> >>>>>>> ** >>>>>>> >>>>>>> *Furthermore, although most today's systems use video streams for >>>>>>> presentations, there are use cases where this is not suitable. For >>>>>> example:* >>>>>>> >>>>>>> *- The professor which shares an electronic whiteboard (could be a >>>>>>> whiteboard application on a PC, with screen capture of the PC) >>>> where >>>>>> all >>>>>>> students can participate. Students will take control of the shared >>>>>>> whiteboard in turns.* >>>>>>> >>>>>>> *- In a multipoint meeting, a shared document can be kept always >>>>>> visible >>>>>>> in a screen, while other documents are presented on other screens >>>>>> (with >>>>>>> possible in turns presentation). For instance, for the purpose of >>>>>> shared >>>>>>> design document, notes taking, polls, etc. A shared document >>>> implies >>>>>>> that all participants can modify it in turns.* >>>>>>> >>>>>>> *"* >>>>>>> >>>>>>> ** >>>>>>> >>>>>>> ** >>>>>>> >>>>>>> *St ephane. v> >>>>>>> * >>>>>>> >>>>>>> * >>>>>>> * >>>>>>> >>>>>>> *_______________________________________________ >>>>>>> clue mailing list >>>>>>> clue@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>> * >>>>>> >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_002_44C6B6B2D0CF424AA90B6055548D7A61CE060BFFCRPMBOXPRD01pol_-- From mary.ietf.barnes@gmail.com Fri Oct 7 11:01:24 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4D821F8BE7 for ; Fri, 7 Oct 2011 11:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.478 X-Spam-Level: X-Spam-Status: No, score=-103.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Osf2TUjTetT for ; Fri, 7 Oct 2011 11:01:23 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 91C1021F8BDC for ; Fri, 7 Oct 2011 11:01:23 -0700 (PDT) Received: by vws5 with SMTP id 5so4158726vws.31 for ; Fri, 07 Oct 2011 11:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7eSGpab/QAUxjUnvbqb3RX3mV0A6wuCg2595V2VZ77w=; b=v0GOh1ool/FcZ/YRleQS4X7WK5542AR7tSI/OBJR9MZ2oodNVLieZdEmM9N7uOXYMv nltEnHEWO5oGNqn1nuitJZb0BnyvsQCwOUZ6nlit/yNXm3FIe8fP+AFFXbRR5sWI2Lp5 zAthtINCUe21oenzgOji7uD+S2EM9gJ7fwU+c= MIME-Version: 1.0 Received: by 10.52.37.44 with SMTP id v12mr3864502vdj.53.1318010676491; Fri, 07 Oct 2011 11:04:36 -0700 (PDT) Received: by 10.52.75.198 with HTTP; Fri, 7 Oct 2011 11:04:36 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42A75@xmb-sjc-221.amer.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42A75@xmb-sjc-221.amer.cisco.com> Date: Fri, 7 Oct 2011 13:04:36 -0500 Message-ID: From: Mary Barnes To: "Allyn Romanow (allyn)" Content-Type: multipart/alternative; boundary=20cf3079bf4e2eb5e904aeb9461f Cc: clue@ietf.org Subject: Re: [clue] interim meeting agenda for framework doc discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 18:01:24 -0000 --20cf3079bf4e2eb5e904aeb9461f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi folks, Per Allyn's note below, if you do have some ideas (which we very much welcome) on particular issues that you would like to present, charts would be most helpful as we will have some remote participants. The chairs will need all charts (including for the framework) no later than 5pm Eastern on Monday, October 10th. Any charts received after that time may not be able to be presented as the chairs need to get them uploaded and will be busy with other logistics prior to the meeting. Thanks, Mary. On Fri, Oct 7, 2011 at 1:46 AM, Allyn Romanow (allyn) wrot= e: > HI Folks,**** > > ** ** > > Here is a proposal for the framework portion of the interim meeting.**** > > ** ** > > ** ** > > Goal: Move the draft-romanow-clue-framework toward acceptance as a WG > draft**** > > ** ** > > Agenda:**** > > Overview =96 50 minutes**** > > *Overview =96 presentation by draft authors of new material* > > **=B7 **Area of capture**** > > **=B7 **Segment switching. VAD. What information in VAD**** > > ** ** > > *Issues* > > ** ** > > **=B7 **Area of Capture**** > > **=B7 **3 message exchange =96 provider and consumer. Devices are > both. **** > > **o **Initial capabilities message**** > > **=B7 **Measurements =96 are degrees, radians necessary**** > > **=B7 **Definitions =96 Roni=92s email (unless it is sorted out = on > email)**** > > ** ** > > What are additional issues people feel need to be agreed upon that stand > in the way of the document becoming a WG draft? In order to make progress= , > the discussion will be kept to identified issues. New ones can be added > during the meeting, of course.**** > > ** ** > > If you have a particular viewpoint on an issue, it would help to have som= e > slides to describe it**** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --20cf3079bf4e2eb5e904aeb9461f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi folks,

Per Allyn's note below, if you do have som= e ideas (which we very much welcome) on particular issues that you would li= ke to present, charts would be most helpful as we will have some remote par= ticipants. =A0The chairs will need all charts (including for the framework)= no later than 5pm Eastern on Monday, =A0October 10th. =A0Any charts receiv= ed after that time may not be able to be presented as the chairs need to ge= t them uploaded and will be busy with other logistics prior to the meeting.= =A0

Thanks,
Mary.=A0

On Fri, Oct 7, 2011 at 1:46 AM, Allyn Romanow (allyn) <allyn@cisco.com> wr= ote:

HI Folks,

=A0

Here is a proposal for the framework portion of the = interim meeting.

=A0

=A0

Goal: =A0Move the draft-romanow-clue-framework towar= d acceptance as a WG draft

=A0

Agenda:

Overview =96 50 minutes

Overview =96 presentation by draft authors of new material

=B7=A0=A0=A0=A0=A0=A0=A0=A0 Area of capture

=B7=A0=A0=A0=A0=A0=A0=A0=A0 Segment switching. VAD. What information in VAD=

=A0

Issues

=A0

=B7=A0=A0=A0=A0=A0=A0=A0=A0 Area of Capture

=B7=A0=A0=A0=A0=A0=A0=A0=A0 3 message exchange =96 provider and consumer. Devices are both.

o=B7=A0=A0=A0=A0=A0=A0=A0=A0 Measurements =96 are degrees, radians necessary

=B7=A0=A0=A0=A0=A0=A0=A0=A0 Definitions =96 Roni=92s =A0email (unless it is sorted out on email)

=A0

What =A0are additional issues people feel need to be agreed upon that stand in the way of the document becoming a WG draft? In o= rder to make progress, the discussion will be kept to identified issues. New one= s can be added during the meeting, of course.

=A0

If you have a particular viewpoint on an issue, it w= ould help to have some slides to describe it


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


--20cf3079bf4e2eb5e904aeb9461f-- From Even.roni@huawei.com Fri Oct 7 11:15:23 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE6921F8AE1 for ; Fri, 7 Oct 2011 11:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.356 X-Spam-Level: X-Spam-Status: No, score=-106.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQDZbULRRQnJ for ; Fri, 7 Oct 2011 11:15:22 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id F0FFB21F8A57 for ; Fri, 7 Oct 2011 11:15:21 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSP00B3XK6WHE@szxga05-in.huawei.com> for clue@ietf.org; Sat, 08 Oct 2011 02:18:32 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSP00J66K6VNV@szxga05-in.huawei.com> for clue@ietf.org; Sat, 08 Oct 2011 02:18:32 +0800 (CST) Received: from windows8d787f9 ([109.64.200.234]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LSP00INMK6NPN@szxml11-in.huawei.com>; Sat, 08 Oct 2011 02:18:31 +0800 (CST) Date: Fri, 07 Oct 2011 20:15:33 +0200 From: Roni Even In-reply-to: To: stephane.cazeaux@orange.com, clue@ietf.org Message-id: <077f01cc851d$1fb20d10$5f162730$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcxHlL8VW+C7KhbYQU2HJX/U8MKZpAFFKK/A///k6YCAAFO3gIAACg4AgAAqsQCAAFTQgP/uhI7ggCNGD4D/+k3aoIALuqeA/6gpJ1D/T9hggA== References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com> <4E309135.7070408@alum.mit.edu> <001b01cc4cd6$77d28760$67779620$%roni@huawei.com> <4E30DFDE.3040601@alum.mit.edu> <9ECCF01B52E7AB408A7EB85352642141031F2E5E@ftrdmel0.rd.francetelecom.fr> <4E314AD3.1030406@alum.mit.edu> <4E403783.70706@alum.mit.edu> <4E454723.4080501@alum.mit.edu> Subject: Re: [clue] the presentation use case X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 18:15:23 -0000 Hi, Stephane, I think that by saying video, audio and real-time text we mean any media that is carried over RTP starting with a SIP call. When talking about = other collaboration I am not sure how they are negotiate the sharing protocol = and what is the call setup. Can you provide more input on the call flow to establish other data transport that is not using RTP. This will be = helpful if we want to describe a use case. Thanks Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > stephane.cazeaux@orange.com > Sent: Friday, October 07, 2011 1:25 PM > To: clue@ietf.org > Subject: [clue] the presentation use case >=20 > Hi >=20 > I will not be able to attend physically to the interim meeting. >=20 > However I had a comment on the presentation use case, which I still > consider we need to agree on. > In the use case draft, the presentation use case is restricted to the > video based solution. To me, it should be modified so that: > - It does not restrict the solution to the video > - It includes the need to share any kind of documents (including > complex documents such as excel sheets) and the ability to have remote > control >=20 > See below the discussion. >=20 > Regards, > St=E9phane. >=20 >=20 >=20 > -----Message d'origine----- > De=A0: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Envoy=E9=A0: vendredi 12 ao=FBt 2011 17:31 > =C0=A0: CAZEAUX Stephane RD-BIZZ-CAE > Cc=A0: clue@ietf.org > Objet=A0: Re: [clue] Comment on the presentation use case >=20 > On 8/12/11 4:48 AM, stephane.cazeaux@orange-ftgroup.com wrote: > > Hi Paul, > > > > I understand your suggestion, and I am aware that it could be a > solution. It certainly makes sense, but I am not sure of how it could > be integrated in CLUE. To me, this is a matter of application > integration, at application level. > > > > My suggestion is that we should think of a solution that provides > more satisfying collaboration within telepresence, with the same level > of interoperability and multistream interaction as presentation video > stream provides, but with more satisfying quality (video is not > suitable for all kinds of shared documents) and more collaborative > features. > > I don't think that the kind of relationship that you suggest is the > only solution. >=20 > IMO the main thing is to not constrain the mechanism used for > collaboration/web sharing. That stuff is evolving at "web speed". > Anything you nail down that is constraining will be obsolete before it > gets out. >=20 > (I've been looking more at RTCWEB recently, and I'm wondering if > perhaps > CLUE ought to be based on that.) >=20 > Thanks, > Paul (as individual) >=20 > > Stephane. > > > > > > -----Message d'origine----- > > De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Envoy=E9 : lundi 8 ao=FBt 2011 21:23 > > =C0 : CAZEAUX Stephane RD-BIZZ-CAE > > Cc : clue@ietf.org > > Objet : Re: [clue] Comment on the presentation use case > > > > On 8/8/11 11:56 AM, stephane.cazeaux@orange-ftgroup.com wrote: > >> Hi, > >> > >> To me, it should be part of the telepresence protocols at least to > enable the interoperability, as the presentation based on video stream > allows it. > >> > >> The point is that video stream is not convenient for the use cases = I > suggested. But it does not necessarily mean that we should bundle a > full data sharing protocol with telepresence. Something simpler, like > the RFB option of draft-garcia-mmusic-sdp-collaboration, could be a > candidate. > > > > What I was suggesting is that maybe it would make sense to turn = those > > relationships "inside out". > > > > For instance when I use a collaboration tool like Webex, the > > collaboration is set up first via the web, and defines the set of > > participants. Then a voice session can be added. For pragmatic > reasons, > > the voice conferencing seems to be pretty distinct. (I'm not certain > how > > webex handles video. I suspect it is doing it via the web, not the > > telephony conference.) > > > > Its not hard to imagine the same sort of setup, but with a = multiparty > > telepresence session instead of the traditional voice conference. In > > such a case, you would probably want the collaboration tool (webex, > or > > whatever) to mediate the UI for the web collaboration, the roster, > etc. > > It might delegate a lot of that to the telepresence infrastructure. > > > > But that does raise some questions about how all the components fit > > together. Is there a single screen for the collaboration session in = a > > telepresence room? What about input to that - keyboard, mouse, etc.? > Or > > do we assume that each person in the room has their own computer = with > > input, display, etc. and maybe a way to slave the web collaboration > > session to one or more of the big displays in the room? > > > > What probably *can't* be done right now is nail down a particular = web > > collaboration service (e.g. Webex) or protocol. That does complicate > > slaving the collaboration session to a screen, unless its done by > having > > someone connect a video connection to their own computer. > > > > Thanks, > > Paul > > > >> Stephane. > >> > >> > >> -----Message d'origine----- > >> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la = part > de Paul Kyzivat > >> Envoy=E9 : jeudi 28 juillet 2011 13:41 > >> =C0 : CHATRAS Bruno RD-CORE-ISS > >> Cc : clue@ietf.org > >> Objet : Re: [clue] Comment on the presentation use case > >> > >> On 7/28/11 2:37 AM, bruno.chatras@orange-ftgroup.com wrote: > >>> I think we should take a look to > >>> = http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration-00 > >> > >> Maybe. But that is almost orthogonal to what I was suggesting. > >> > >> THanks, > >> Paul > >> (as individual) > >> > >>> Bruno > >>> > >>>> -----Message d'origine----- > >>>> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la > part de > >>>> Paul Kyzivat > >>>> Envoy=E9 : jeudi 28 juillet 2011 06:05 > >>>> =C0 : Roni Even > >>>> Cc : clue@ietf.org > >>>> Objet : Re: [clue] Comment on the presentation use case > >>>> > >>>> On 7/27/11 11:28 PM, Roni Even wrote: > >>>>> Hi, > >>>>> HTTP is not defining a common data sharing protocol. WebEx may = be > >>>> carried > >>>>> over HTTP but the data sharing application is not standard. What > I > >>>> meant is > >>>>> that it can either be something that is a common data sharing > >>>> protocol or > >>>>> something that is carried as an RTP payload which require some > common > >>>>> defined protocol on top. > >>>> > >>>> I was being a bit tongue in cheek, though not entirely. > >>>> Of course you are right - that if you want to push data to > everybody > >>>> you > >>>> need more. > >>>> > >>>> But data sharing by pointing a video camera at a piece of paper = is > a > >>>> tad > >>>> out of date. Connecting the video port on a user's computer as a > video > >>>> source and distributing it with the other video is better than > that. > >>>> But > >>>> its not nearly as convenient as webex or any of its competitors. > >>>> > >>>> It isn't entirely clear that its *necessary* to bundle the data > sharing > >>>> application with the telepresence protocols. Its kind of limiting > since > >>>> the web apps evolve very rapidly. Perhaps we should be doing the > >>>> opposite of that: providing a way to embed the control of the > >>>> telepresence system into a web app. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>>> -----Original Message----- > >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > >>>> Of > >>>>>> Paul Kyzivat > >>>>>> Sent: Thursday, July 28, 2011 1:29 AM > >>>>>> To: clue@ietf.org > >>>>>> Subject: Re: [clue] Comment on the presentation use case > >>>>>> > >>>>>> On 7/27/11 6:07 PM, Roni Even wrote: > >>>>>>> Hi Stephane, > >>>>>>> > >>>>>>> Is there a standard protocol that is used for conveying this > >>>>>>> information, is it RTP based. > >>>>>> > >>>>>> AFAIK this is often http. (E.g. webex) > >>>>>> > >>>>>>> To me this is a separate application that can be integrated in > the > >>>>>>> application level and not as part of the multistream. > >>>>>> > >>>>>> I guess this depends on whether the support for it is = integrated > >>>> into > >>>>>> the "room", or is just incidental equipment brought by the > users, > >>>> not > >>>>>> formally related to the telepresence session. > >>>>>> > >>>>>> Thanks, > >>>>>> Paul > >>>>>> (speaking as an individual) > >>>>>> > >>>>>>> Roni > >>>>>>> > >>>>>>> *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > Behalf Of > >>>>>>> *stephane.cazeaux@orange-ftgroup.com > >>>>>>> *Sent:* Thursday, July 21, 2011 2:33 PM > >>>>>>> *To:* clue@ietf.org > >>>>>>> *Subject:* [clue] Comment on the presentation use case* > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> *Hi,* > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> *The presentation use case as described in the use-cases > document > >>>> is > >>>>>>> based on the assumption that the presentation stream relies on > a > >>>>>> video > >>>>>>> stream, and is limited to usage of presentation video streams. > But > >>>> we > >>>>>>> could also consider collaborative use cases, meaningful for > >>>>>>> telepresence, which are not covered by the existing text.* > >>>>>>> > >>>>>>> *I propose to complete the existing text as follows:* > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> *Furthermore, although most today's systems use video streams > for > >>>>>>> presentations, there are use cases where this is not suitable. > For > >>>>>> example:* > >>>>>>> > >>>>>>> *- The professor which shares an electronic whiteboard (could > be a > >>>>>>> whiteboard application on a PC, with screen capture of the PC) > >>>> where > >>>>>> all > >>>>>>> students can participate. Students will take control of the > shared > >>>>>>> whiteboard in turns.* > >>>>>>> > >>>>>>> *- In a multipoint meeting, a shared document can be kept > always > >>>>>> visible > >>>>>>> in a screen, while other documents are presented on other > screens > >>>>>> (with > >>>>>>> possible in turns presentation). For instance, for the purpose > of > >>>>>> shared > >>>>>>> design document, notes taking, polls, etc. A shared document > >>>> implies > >>>>>>> that all participants can modify it in turns.* > >>>>>>> > >>>>>>> *"* > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> *St ephane. v> > >>>>>>> * > >>>>>>> > >>>>>>> * > >>>>>>> * > >>>>>>> > >>>>>>> *_______________________________________________ > >>>>>>> clue mailing list > >>>>>>> clue@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>>>> * > >>>>>> > >>>>>> _______________________________________________ > >>>>>> clue mailing list > >>>>>> clue@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Fri Oct 7 11:16:32 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8704121F8AE1 for ; Fri, 7 Oct 2011 11:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.361 X-Spam-Level: X-Spam-Status: No, score=-106.361 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPltI2UDZQAG for ; Fri, 7 Oct 2011 11:16:31 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id B6DDE21F8A57 for ; Fri, 7 Oct 2011 11:16:30 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSP005XWK8V61@szxga04-in.huawei.com> for clue@ietf.org; Sat, 08 Oct 2011 02:19:43 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSP009IOK8VFK@szxga04-in.huawei.com> for clue@ietf.org; Sat, 08 Oct 2011 02:19:43 +0800 (CST) Received: from windows8d787f9 ([109.64.200.234]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LSP00ILDK8QU1@szxml11-in.huawei.com>; Sat, 08 Oct 2011 02:19:43 +0800 (CST) Date: Fri, 07 Oct 2011 20:16:48 +0200 From: Roni Even In-reply-to: To: 'Mary Barnes' , "'Allyn Romanow (allyn)'" Message-id: <078001cc851d$4a9a1720$dfce4560$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/KIvAgieBO6RWNs0itHwLQ)" Content-language: en-us Thread-index: AcyFG5ntaoGx3RTOTCGMyYnxRUMk8gAAZpIg References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42A75@xmb-sjc-221.amer.cisco.com> Cc: clue@ietf.org Subject: Re: [clue] interim meeting agenda for framework doc discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 18:16:32 -0000 This is a multi-part message in MIME format. --Boundary_(ID_/KIvAgieBO6RWNs0itHwLQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Mary, I assume that the comments sent to the list before Monday will also be discussed. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Friday, October 07, 2011 8:05 PM To: Allyn Romanow (allyn) Cc: clue@ietf.org Subject: Re: [clue] interim meeting agenda for framework doc discussion Hi folks, Per Allyn's note below, if you do have some ideas (which we very much welcome) on particular issues that you would like to present, charts would be most helpful as we will have some remote participants. The chairs will need all charts (including for the framework) no later than 5pm Eastern on Monday, October 10th. Any charts received after that time may not be able to be presented as the chairs need to get them uploaded and will be busy with other logistics prior to the meeting. Thanks, Mary. On Fri, Oct 7, 2011 at 1:46 AM, Allyn Romanow (allyn) wrote: HI Folks, Here is a proposal for the framework portion of the interim meeting. Goal: Move the draft-romanow-clue-framework toward acceptance as a WG draft Agenda: Overview - 50 minutes Overview - presentation by draft authors of new material . Area of capture . Segment switching. VAD. What information in VAD Issues . Area of Capture . 3 message exchange - provider and consumer. Devices are both. o Initial capabilities message . Measurements - are degrees, radians necessary . Definitions - Roni's email (unless it is sorted out on email) What are additional issues people feel need to be agreed upon that stand in the way of the document becoming a WG draft? In order to make progress, the discussion will be kept to identified issues. New ones can be added during the meeting, of course. If you have a particular viewpoint on an issue, it would help to have some slides to describe it _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --Boundary_(ID_/KIvAgieBO6RWNs0itHwLQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Mary,

I assume that the comments sent to the list before Monday will also = be discussed.

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: Friday, October 07, 2011 8:05 = PM
To: Allyn Romanow (allyn)
Cc: = clue@ietf.org
Subject: Re: [clue] interim meeting agenda for = framework doc discussion

 

Hi = folks,

 

Per Allyn's note below, if you do have some ideas = (which we very much welcome) on particular issues that you would like to = present, charts would be most helpful as we will have some remote = participants.  The chairs will need all charts (including for the = framework) no later than 5pm Eastern on Monday,  October 10th. =  Any charts received after that time may not be able to be = presented as the chairs need to get them uploaded and will be busy with = other logistics prior to the meeting. 

 

Thanks,

Mary. 

On Fri, Oct 7, 2011 at 1:46 AM, Allyn Romanow (allyn) = <allyn@cisco.com> = wrote:

HI = Folks,

 <= /o:p>

Here is a = proposal for the framework portion of the interim = meeting.

 <= /o:p>

 <= /o:p>

Goal: =  Move the draft-romanow-clue-framework toward acceptance as a WG = draft

 <= /o:p>

Agenda:=

Overview = – 50 minutes

Overview = – presentation by draft authors of new = material

·        = ; Area of capture

·        = ; Segment switching. VAD. What information in = VAD

 <= /o:p>

Issues

 <= /o:p>

·        = ; Area of Capture

·        = ; 3 message exchange – provider and consumer. Devices are = both.

o   Initial capabilities = message

·        = ; Measurements – are degrees, radians = necessary

·        = ; Definitions – Roni’s  email (unless it is = sorted out on email)

 <= /o:p>

What =  are additional issues people feel need to be agreed upon that = stand in the way of the document becoming a WG draft? In order to make = progress, the discussion will be kept to identified issues. New ones can = be added during the meeting, of course.

 <= /o:p>

If you have = a particular viewpoint on an issue, it would help to have some slides to = describe it


______________________________________= _________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

 

= --Boundary_(ID_/KIvAgieBO6RWNs0itHwLQ)-- From pkyzivat@alum.mit.edu Fri Oct 7 11:59:36 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960BB21F8BB8 for ; Fri, 7 Oct 2011 11:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6nyGscSJw-3 for ; Fri, 7 Oct 2011 11:59:36 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id D2B0721F8BB7 for ; Fri, 7 Oct 2011 11:59:35 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta05.westchester.pa.mail.comcast.net with comcast id hoyi1h00527AodY55v2qWU; Fri, 07 Oct 2011 19:02:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta19.westchester.pa.mail.comcast.net with comcast id hv2p1h00W0tdiYw3fv2qhD; Fri, 07 Oct 2011 19:02:50 +0000 Message-ID: <4E8F4CD7.20407@alum.mit.edu> Date: Fri, 07 Oct 2011 15:02:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42A75@xmb-sjc-221.amer.cisco.com> <078001cc851d$4a9a1720$dfce4560$%roni@huawei.com> In-Reply-To: <078001cc851d$4a9a1720$dfce4560$%roni@huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] interim meeting agenda for framework doc discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 18:59:36 -0000 Roni, On 10/7/11 2:16 PM, Roni Even wrote: > Hi Mary, > > I assume that the comments sent to the list before Monday will also be > discussed. It may be logistically difficult to formally address them all, since they may be happening concurrently with the development of the charts used to guide discussion. People who have provided comments recently would be well advised to be prepared to bring them up again in context during the meeting. Thanks, Paul > Roni > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* Friday, October 07, 2011 8:05 PM > *To:* Allyn Romanow (allyn) > *Cc:* clue@ietf.org > *Subject:* Re: [clue] interim meeting agenda for framework doc discussion > > Hi folks, > > Per Allyn's note below, if you do have some ideas (which we very much > welcome) on particular issues that you would like to present, charts > would be most helpful as we will have some remote participants. The > chairs will need all charts (including for the framework) no later than > 5pm Eastern on Monday, October 10th. Any charts received after that time > may not be able to be presented as the chairs need to get them uploaded > and will be busy with other logistics prior to the meeting. > > Thanks, > > Mary. > > On Fri, Oct 7, 2011 at 1:46 AM, Allyn Romanow (allyn) > wrote: > > HI Folks, > > Here is a proposal for the framework portion of the interim meeting. > > Goal: Move the draft-romanow-clue-framework toward acceptance as a WG draft > > Agenda: > > Overview – 50 minutes > > *Overview – presentation by draft authors of new material* > > ·Area of capture > > ·Segment switching. VAD. What information in VAD > > *Issues* > > ·Area of Capture > > ·3 message exchange – provider and consumer. Devices are both. > > oInitial capabilities message > > ·Measurements – are degrees, radians necessary > > ·Definitions – Roni’s email (unless it is sorted out on email) > > What are additional issues people feel need to be agreed upon that stand > in the way of the document becoming a WG draft? In order to make > progress, the discussion will be kept to identified issues. New ones can > be added during the meeting, of course. > > If you have a particular viewpoint on an issue, it would help to have > some slides to describe it > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From marshall.eubanks@gmail.com Fri Oct 7 13:33:37 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2980121F8BF3 for ; Fri, 7 Oct 2011 13:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.3 X-Spam-Level: X-Spam-Status: No, score=-103.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KS48CJ-vUzSl for ; Fri, 7 Oct 2011 13:33:36 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06BA621F8B26 for ; Fri, 7 Oct 2011 13:33:35 -0700 (PDT) Received: by gyd12 with SMTP id 12so4813396gyd.31 for ; Fri, 07 Oct 2011 13:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Unyv3pyAy2UH9x4mwOStK6bDFGsGz2lpRnOTTlxt0bI=; b=lENWHB2RTsRUR7MCaUNm9OeEYRL0byv4sotGpuqCT8aBPVtgQIJJ34eZ11nfmhNIsw eXXM9JC3lKPEIetApKvBFUFWbLSy3sWqZ2bl7mo0BnKBhWaWc03US0cNzJSPPZk+JwG7 k0XF3WWQlmqtxdkk+PBRtAh5qZAcISrY/oh5U= MIME-Version: 1.0 Received: by 10.150.163.5 with SMTP id l5mr1992143ybe.83.1318019810269; Fri, 07 Oct 2011 13:36:50 -0700 (PDT) Received: by 10.151.98.20 with HTTP; Fri, 7 Oct 2011 13:36:50 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Oct 2011 16:36:50 -0400 Message-ID: From: Marshall Eubanks To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] CLUE WG Interim Meeting, Oct. 11-12th, 2011 (includes Webex info) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 20:33:37 -0000 Dear Mary; Could I have a little time to discuss "Locating scenes in 3-D" ? Regards Marshall On Fri, Oct 7, 2011 at 11:44 AM, Mary Barnes w= rote: > For folks attending the interim meeting next week, just a reminder that > there is a map for getting to the facility on the CLUE wg wiki (you will > need to download the file that you can access by clicking on the address)= : > http://trac.tools.ietf.org/wg/clue/trac/wiki > The logistics for getting to the hotels/meeting location from the airport > are also available on the wiki (again downloading the file pointed to by = the > "Hotels and other info" link. > > Per the agenda, folks can start arriving at 8:30. =A0You will need to sto= p at > the reception desk, sign in and get a visitors badge. One of the Polycom > employees that will be at the meeting (myself, Stephen Botzko or Mark > Duckworth) will need to take you to the meeting room. =A0If you arrive be= tween > 8:30 and 8:55, please wait in the lobby as one of us should be there > shortly. If you arrive later, the receptionist will need to contact us to > come escort you. > Please let me know if you have further questions. > Regards, > Mary. > On Tue, Sep 27, 2011 at 6:08 PM, Mary Barnes > wrote: >> >> Hi all, >> >> As previously posted, the CLUE WG has scheduled an interim meeting for >> Oct. 11th-12th, 2011 (1.5 days). =A0 The f2f meeting will be held at the >> Polycom facility located at =A0100 =A0Minuteman Road, Andover, Massachus= etts. >> The Webex details for remote participation are below. >> >> The proposed agenda is as follows. Note, that the authors plan to have a= n >> updated framework document submitted by the end of this week (Sept. 30th= ) to >> allow enough time for review of the document before the meeting. =A0Anyo= ne >> else that would like agenda time, please contact the chairs no later tha= n >> Sept. 30th, 2011. >> >> Oct. 11th, 2011 >> -------------------- >> 9:00-9:10 Chair - status, agenda bash >> 9:10-09:50 Discussion of any remaining open issues for the use cases and >> requirements >> 09:50-10:00 Short coffee break >> 10:00-11:30 Proposed framework discussion >> 11:30-13:00 Lunch >> 13:30-15:00 =A0=A0Proposed framework discussion >> 15:00-15:20 =A0Break >> 15:20-17:00 =A0CLUE and RTCWEB >> 17:00-18:00 =A0Summary and identification of key items for discussion on >> Tuesday >> Oct. 12th, 2011 (note this agenda will be finalized based on the outcome >> of Tuesday's meeting) >> --------------------------- >> 08:30-08:45 =A0Plans for the day >> 08:45-10:30 =A0Discussion >> 10:30-10:45 =A0Break >> 10:45-12:30 =A0Discussion >> 12:30-13:00 =A0Discussion of way forward and summary of action items >> >> Webex: >> >> =3D=3D=3D=3D=3D=3D=3D=3D >> >> Topic: CLUE WG Interim Meeting >> Date: Every 1 day, from Tuesday, October 11, 2011 to Wednesday, October >> 12, 2011 >> Time: 8:30 am, Eastern Daylight Time (New York, GMT-04:00) >> Meeting Number: 969 145 615 >> Meeting Password: (This meeting does not require a password.) >> >> >> ------------------------------------------------------- >> To join the online meeting (Now from mobile devices!) >> ------------------------------------------------------- >> 1. Go to >> https://workgreen.webex.com/workgreen/j.php?ED=3D182521792&UID=3D1251996= 147&RT=3DMiMxMQ%3D%3D >> 2. If requested, enter your name and email address. >> 3. If a password is required, enter the meeting password: (This meeting >> does not require a password.) >> 4. Click "Join". >> >> To view in other time zones or languages, please click the link: >> >> https://workgreen.webex.com/workgreen/j.php?ED=3D182521792&UID=3D1251996= 147&ORT=3DMiMxMQ%3D%3D >> >> ------------------------------------------------------- >> To join the audio conference only >> ------------------------------------------------------- >> To receive a call back, provide your phone number when you join the >> meeting, or call the number below and enter the access code. >> Call-in toll number (US/Canada): 1-408-792-6300 >> Global call-in numbers: >> https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&= ED=3D182521792&tollFree=3D0 >> >> Access code:969 145 615 >> >> ------------------------------------------------------- >> For assistance >> ------------------------------------------------------- >> 1. Go to https://workgreen.webex.com/workgreen/mc >> 2. On the left navigation bar, click "Support". >> >> You can contact me at: >> cmorgan@amsl.com >> 1-510-492-4085 >> >> To update this meeting to your calendar program (for example Microsoft >> Outlook), click this link: >> >> https://workgreen.webex.com/workgreen/j.php?ED=3D182521792&UID=3D1251996= 147&ICS=3DMRS1&LD=3D1&RD=3D2&ST=3D1&SHA2=3DxBjAAyKlGU5WtZwaNwAEZK1vCvOPzxE9= heViyuR6muc=3D&RT=3DMiMxMQ%3D%3D >> >> >> WebEx will automatically setup Meeting Manager for Windows the first tim= e >> you join a meeting. To save time, you can setup prior to the meeting by >> clicking this link: >> https://workgreen.webex.com/workgreen/meetingcenter/mcsetup.php >> >> >> The playback of UCF (Universal Communications Format) rich media files >> requires appropriate players. To view this type of rich media files in t= he >> meeting, please check whether you have the players installed on your >> computer by going to >> https://workgreen.webex.com/workgreen/systemdiagnosis.php. >> >> Sign up for a free trial of WebEx >> http://www.webex.com/go/mcemfreetrial >> >> http://www.webex.com >> >> CCP:+14087926300x969145615# >> >> IMPORTANT NOTICE: This WebEx service includes a feature that allows audi= o >> and any documents and other materials exchanged or viewed during the ses= sion >> to be recorded. By joining this session, you automatically consent to su= ch >> recordings. If you do not consent to the recording, discuss your concern= s >> with the meeting host prior to the start of the recording or do not join= the >> session. Please note that any such recordings may be subject to discover= y in >> the event of litigation. > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From Even.roni@huawei.com Fri Oct 7 14:31:35 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D4221F8BF3 for ; Fri, 7 Oct 2011 14:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.368 X-Spam-Level: X-Spam-Status: No, score=-106.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MBdcuzmS9LS for ; Fri, 7 Oct 2011 14:31:34 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD5F21F8BF0 for ; Fri, 7 Oct 2011 14:31:34 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSP00FZHT9Z3S@szxga05-in.huawei.com> for clue@ietf.org; Sat, 08 Oct 2011 05:34:47 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSP00H57T9XRL@szxga05-in.huawei.com> for clue@ietf.org; Sat, 08 Oct 2011 05:34:47 +0800 (CST) Received: from windows8d787f9 ([109.64.200.234]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LSP00LBUT9JT6@szxml12-in.huawei.com>; Sat, 08 Oct 2011 05:34:45 +0800 (CST) Date: Fri, 07 Oct 2011 23:31:38 +0200 From: Roni Even In-reply-to: <4E8F4CD7.20407@alum.mit.edu> To: 'Paul Kyzivat' , clue@ietf.org Message-id: <07b601cc8538$89c51880$9d4f4980$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcyFI+k3fE8/xsRNR/SrBxz6A+QdcwAEnqrg References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42A75@xmb-sjc-221.amer.cisco.com> <078001cc851d$4a9a1720$dfce4560$%roni@huawei.com> <4E8F4CD7.20407@alum.mit.edu> Subject: Re: [clue] interim meeting agenda for framework doc discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 21:31:35 -0000 Hi, I think that the major topics I see for discussion are: 1. The capture area, point and scale attributes. 2. The architecture, relation between EPs, Scene, capture set and how does presentation or presentations fit in the model. 3. Hierarchy of attributes, should they be available for each layer of the model. Scene, capture set, media captures? 4. Where should the protocol be specified, do we split this document to two? And what is the extensibility mechanism. 5. Relation of attributes and encoding parameters to SDP (duplicate?) I can prepare a presentation but is this the chairs want to do it. I was thinking that the chairs will define the discussion topics, I know that the framework is an individual draft but I was under the impression that the chairs will treat it as if we are discussing a WG document and not an individual draft and this was the major reason for having the interim meeting, discussing a WG document. I was considering to prepare an individual draft with other members of the group, was told to wait and see the new revision of the individual draft which is better than the previous one but I expect the discussion to be managed by the WG chairs and based on the document and other inputs including comments that were sent to the list. Please let me know if I should prepare a presentation or are the chairs going to accumulate the issues and present them for better efficiency Regards Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Friday, October 07, 2011 9:03 PM > To: clue@ietf.org > Subject: Re: [clue] interim meeting agenda for framework doc discussion > > Roni, > > On 10/7/11 2:16 PM, Roni Even wrote: > > Hi Mary, > > > > I assume that the comments sent to the list before Monday will also > be > > discussed. > > It may be logistically difficult to formally address them all, since > they may be happening concurrently with the development of the charts > used to guide discussion. People who have provided comments recently > would be well advised to be prepared to bring them up again in context > during the meeting. > > Thanks, > Paul > > > Roni > > > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > Behalf > > Of *Mary Barnes > > *Sent:* Friday, October 07, 2011 8:05 PM > > *To:* Allyn Romanow (allyn) > > *Cc:* clue@ietf.org > > *Subject:* Re: [clue] interim meeting agenda for framework doc > discussion > > > > Hi folks, > > > > Per Allyn's note below, if you do have some ideas (which we very much > > welcome) on particular issues that you would like to present, charts > > would be most helpful as we will have some remote participants. The > > chairs will need all charts (including for the framework) no later > than > > 5pm Eastern on Monday, October 10th. Any charts received after that > time > > may not be able to be presented as the chairs need to get them > uploaded > > and will be busy with other logistics prior to the meeting. > > > > Thanks, > > > > Mary. > > > > On Fri, Oct 7, 2011 at 1:46 AM, Allyn Romanow (allyn) > > > wrote: > > > > HI Folks, > > > > Here is a proposal for the framework portion of the interim meeting. > > > > Goal: Move the draft-romanow-clue-framework toward acceptance as a WG > draft > > > > Agenda: > > > > Overview - 50 minutes > > > > *Overview - presentation by draft authors of new material* > > > > .Area of capture > > > > .Segment switching. VAD. What information in VAD > > > > *Issues* > > > > .Area of Capture > > > > .3 message exchange - provider and consumer. Devices are both. > > > > oInitial capabilities message > > > > .Measurements - are degrees, radians necessary > > > > .Definitions - Roni's email (unless it is sorted out on email) > > > > What are additional issues people feel need to be agreed upon that > stand > > in the way of the document becoming a WG draft? In order to make > > progress, the discussion will be kept to identified issues. New ones > can > > be added during the meeting, of course. > > > > If you have a particular viewpoint on an issue, it would help to have > > some slides to describe it > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Fri Oct 7 14:41:12 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A6421F8BF7 for ; Fri, 7 Oct 2011 14:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.479 X-Spam-Level: X-Spam-Status: No, score=-103.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGaosPeAw6mL for ; Fri, 7 Oct 2011 14:41:11 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B959021F8BF6 for ; Fri, 7 Oct 2011 14:41:10 -0700 (PDT) Received: by vws5 with SMTP id 5so4325489vws.31 for ; Fri, 07 Oct 2011 14:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D+JnWs7UcuBveUgEqOHxDWepX381KyDo9lZcXNiW+6Y=; b=dH/oeIxtodt3meUNLJu4hTSU1jzQ4Uip3hRHYhz/p6fGbw46BDBbtupqlJQjBxYSOL X5Dkua867hn4y6Z232qPB+BPmznNjQKmzKQ9jf6bnMnXQRp0lRUdAuLhUFDPjc46+UMz iTpErnxszMMH21q+MeKjL+lBr2iB1006d6n4M= MIME-Version: 1.0 Received: by 10.52.65.205 with SMTP id z13mr4528136vds.87.1318023864920; Fri, 07 Oct 2011 14:44:24 -0700 (PDT) Received: by 10.52.75.198 with HTTP; Fri, 7 Oct 2011 14:44:24 -0700 (PDT) In-Reply-To: <07b601cc8538$89c51880$9d4f4980$%roni@huawei.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42A75@xmb-sjc-221.amer.cisco.com> <078001cc851d$4a9a1720$dfce4560$%roni@huawei.com> <4E8F4CD7.20407@alum.mit.edu> <07b601cc8538$89c51880$9d4f4980$%roni@huawei.com> Date: Fri, 7 Oct 2011 16:44:24 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=20cf307f36b6462d5504aebc58b4 Cc: clue@ietf.org Subject: Re: [clue] interim meeting agenda for framework doc discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 21:41:12 -0000 --20cf307f36b6462d5504aebc58b4 Content-Type: text/plain; charset=ISO-8859-1 We would very much appreciate it if you could prepare a presentation. The chairs have a proposed agenda in terms of order of topics to be discussed, but it was the expectation that the document authors lead the discussion, with the chairs facilitating in order to get consensus on specific issues. Really, no different than how we do things during the WG sessions - we just have more time to discuss issues and we'll have the opportunity to revisit things if we get stuck on a specific issue. I apologize as I should have put names against the agenda items to make that more clear. I don't recall that we told anyone to wait to submit ideas/drafts until the romanow-dispatch-framework document was updated. That document is not a WG document - it is just the only proposal we have on the table that could be considered as a WG deliverable, but that decision has not been made by the WG. We do need input from all WG members to determine the best approach for the CLUE framework deliverable. Thanks, Mary. On Fri, Oct 7, 2011 at 4:31 PM, Roni Even wrote: > Hi, > I think that the major topics I see for discussion are: > > 1. The capture area, point and scale attributes. > 2. The architecture, relation between EPs, Scene, capture set and how does > presentation or presentations fit in the model. > 3. Hierarchy of attributes, should they be available for each layer of the > model. Scene, capture set, media captures? > 4. Where should the protocol be specified, do we split this document to > two? > And what is the extensibility mechanism. > 5. Relation of attributes and encoding parameters to SDP (duplicate?) > > I can prepare a presentation but is this the chairs want to do it. I was > thinking that the chairs will define the discussion topics, I know that the > framework is an individual draft but I was under the impression that the > chairs will treat it as if we are discussing a WG document and not an > individual draft and this was the major reason for having the interim > meeting, discussing a WG document. I was considering to prepare an > individual draft with other members of the group, was told to wait and see > the new revision of the individual draft which is better than the previous > one but I expect the discussion to be managed by the WG chairs and based on > the document and other inputs including comments that were sent to the > list. > > Please let me know if I should prepare a presentation or are the chairs > going to accumulate the issues and present them for better efficiency > > Regards > Roni > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > > Paul Kyzivat > > Sent: Friday, October 07, 2011 9:03 PM > > To: clue@ietf.org > > Subject: Re: [clue] interim meeting agenda for framework doc discussion > > > > Roni, > > > > On 10/7/11 2:16 PM, Roni Even wrote: > > > Hi Mary, > > > > > > I assume that the comments sent to the list before Monday will also > > be > > > discussed. > > > > It may be logistically difficult to formally address them all, since > > they may be happening concurrently with the development of the charts > > used to guide discussion. People who have provided comments recently > > would be well advised to be prepared to bring them up again in context > > during the meeting. > > > > Thanks, > > Paul > > > > > Roni > > > > > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > > Behalf > > > Of *Mary Barnes > > > *Sent:* Friday, October 07, 2011 8:05 PM > > > *To:* Allyn Romanow (allyn) > > > *Cc:* clue@ietf.org > > > *Subject:* Re: [clue] interim meeting agenda for framework doc > > discussion > > > > > > Hi folks, > > > > > > Per Allyn's note below, if you do have some ideas (which we very much > > > welcome) on particular issues that you would like to present, charts > > > would be most helpful as we will have some remote participants. The > > > chairs will need all charts (including for the framework) no later > > than > > > 5pm Eastern on Monday, October 10th. Any charts received after that > > time > > > may not be able to be presented as the chairs need to get them > > uploaded > > > and will be busy with other logistics prior to the meeting. > > > > > > Thanks, > > > > > > Mary. > > > > > > On Fri, Oct 7, 2011 at 1:46 AM, Allyn Romanow (allyn) > > > > > wrote: > > > > > > HI Folks, > > > > > > Here is a proposal for the framework portion of the interim meeting. > > > > > > Goal: Move the draft-romanow-clue-framework toward acceptance as a WG > > draft > > > > > > Agenda: > > > > > > Overview - 50 minutes > > > > > > *Overview - presentation by draft authors of new material* > > > > > > .Area of capture > > > > > > .Segment switching. VAD. What information in VAD > > > > > > *Issues* > > > > > > .Area of Capture > > > > > > .3 message exchange - provider and consumer. Devices are both. > > > > > > oInitial capabilities message > > > > > > .Measurements - are degrees, radians necessary > > > > > > .Definitions - Roni's email (unless it is sorted out on email) > > > > > > What are additional issues people feel need to be agreed upon that > > stand > > > in the way of the document becoming a WG draft? In order to make > > > progress, the discussion will be kept to identified issues. New ones > > can > > > be added during the meeting, of course. > > > > > > If you have a particular viewpoint on an issue, it would help to have > > > some slides to describe it > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf307f36b6462d5504aebc58b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We would very much appreciate it if you could prepare a presentation. =A0Th= e chairs have a proposed agenda in terms of order of topics to be discussed= , but it was the expectation that the document authors lead the discussion,= with the chairs facilitating in order to get consensus on specific issues.= =A0Really, no different than how we do things during the WG sessions - we = just have more time to discuss issues and we'll have the opportunity to= revisit things if we get stuck on a specific issue. =A0 I apologize as I s= hould have put names against the agenda items to make that more clear. =A0<= div>
I don't recall that we told anyone to wait to submit ide= as/drafts until the romanow-dispatch-framework document was updated. =A0Tha= t document is not a WG document - it is just the only proposal we have on t= he table that could be considered as a WG deliverable, but that decision ha= s not been made by the WG. =A0We do need input from all WG members to deter= mine the best approach for the CLUE framework deliverable. =A0

Thanks,
Mary.=A0

On Fri, Oct 7, 2011 at 4:31 PM, Roni Even <Even.roni@huawei.com> wrot= e:
Hi,
I think that the major topics I see for discussion are:

1. The capture area, point and scale attributes.
2. The architecture, relation between EPs, Scene, capture set and how does<= br> presentation or presentations fit in the model.
3. Hierarchy of attributes, should they be available for each layer of the<= br> model. Scene, capture set, media captures?
4. Where should the protocol be specified, do we split this document to two= ?
And what is the extensibility mechanism.
5. Relation of attributes and encoding parameters to SDP (duplicate?)

I can prepare a presentation but is this the chairs want to do it. I was thinking that the chairs will define the discussion topics, I know that the=
framework is an individual draft but I was under the impression that the chairs will treat it as if we are discussing a WG document and not an
individual draft and this was the major reason for having the interim
meeting, discussing a WG document. I was considering to prepare an
individual draft with other members of the group, was told to wait and see<= br> the new revision of the individual draft which is better than the previous<= br> one but I expect the discussion to be managed by the WG chairs and based on=
the document and other inputs including comments that were sent to the list= .

Please let me know if I should prepare a presentation or are the chairs
going to accumulate the issues and present them for better efficiency

Regards
Roni


> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Paul Kyzivat
> Sent: Friday, October 07, 2011 9:03 PM
> To: clue@ietf.org
> Subject: Re: [clue] interim meeting agenda for framework doc discussio= n
>
> Roni,
>
> On 10/7/11 2:16 PM, Roni Even wrote:
> > Hi Mary,
> >
> > I assume that the comments sent to the list before Monday will al= so
> be
> > discussed.
>
> It may be logistically difficult to formally address them all, since > they may be happening concurrently with the development of the charts<= br> > used to guide discussion. People who have provided comments recently > would be well advised to be prepared to bring them up again in context=
> during the meeting.
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
> > Roni
> >
> > *From:*clue-bounces@ietf= .org [mailto:clue-bounces@ietf= .org] *On
> Behalf
> > Of *Mary Barnes
> > *Sent:* Friday, October 07, 2011 8:05 PM
> > *To:* Allyn Romanow (allyn)
> > *Cc:* clue@ietf.org
> > *Subject:* Re: [clue] interim meeting agenda for framework doc > discussion
> >
> > Hi folks,
> >
> > Per Allyn's note below, if you do have some ideas (which we v= ery much
> > welcome) on particular issues that you would like to present, cha= rts
> > would be most helpful as we will have some remote participants. T= he
> > chairs will need all charts (including for the framework) no late= r
> than
> > 5pm Eastern on Monday, October 10th. Any charts received after th= at
> time
> > may not be able to be presented as the chairs need to get them > uploaded
> > and will be busy with other logistics prior to the meeting.
> >
> > Thanks,
> >
> > Mary.
> >
> > On Fri, Oct 7, 2011 at 1:46 AM, Allyn Romanow (allyn)
> <allyn@cisco.com
> > <mailto:allyn@cisco.com= >> wrote:
> >
> > HI Folks,
> >
> > Here is a proposal for the framework portion of the interim meeti= ng.
> >
> > Goal: Move the draft-romanow-clue-framework toward acceptance as = a WG
> draft
> >
> > Agenda:
> >
> > Overview - 50 minutes
> >
> > *Overview - presentation by draft authors of new material*
> >
> > .Area of capture
> >
> > .Segment switching. VAD. What information in VAD
> >
> > *Issues*
> >
> > .Area of Capture
> >
> > .3 message exchange - provider and consumer. Devices are both. > >
> > oInitial capabilities message
> >
> > .Measurements - are degrees, radians necessary
> >
> > .Definitions - Roni's email (unless it is sorted out on email= )
> >
> > What are additional issues people feel need to be agreed upon tha= t
> stand
> > in the way of the document becoming a WG draft? In order to make<= br> > > progress, the discussion will be kept to identified issues. New o= nes
> can
> > be added during the meeting, of course.
> >
> > If you have a particular viewpoint on an issue, it would help to = have
> > some slides to describe it
> >
> >
> > _______________________________________________
> > clue mailing list
> > clue@ietf.org <mailto:clue@ietf.org>
> > https://www.ietf.org/mailman/listinfo/clue
> >
> >
> >
> > _______________________________________________
> > clue mailing list
> > clue@ietf.org
> > https://www.ietf.org/mailman/listinfo/clue
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf307f36b6462d5504aebc58b4-- From Even.roni@huawei.com Fri Oct 7 16:57:50 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC4D21F858C for ; Fri, 7 Oct 2011 16:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.373 X-Spam-Level: X-Spam-Status: No, score=-106.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7OnH2LiWXwJ for ; Fri, 7 Oct 2011 16:57:49 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id D0C0621F86EE for ; Fri, 7 Oct 2011 16:57:48 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSQ008UI01Q7U@szxga04-in.huawei.com> for clue@ietf.org; Sat, 08 Oct 2011 08:01:03 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSQ003DP01Q75@szxga04-in.huawei.com> for clue@ietf.org; Sat, 08 Oct 2011 08:01:02 +0800 (CST) Received: from windows8d787f9 ([109.64.200.234]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LSQ00IR501GTB@szxml11-in.huawei.com>; Sat, 08 Oct 2011 08:01:02 +0800 (CST) Date: Sat, 08 Oct 2011 01:58:01 +0200 From: Roni Even In-reply-to: To: 'Mary Barnes' Message-id: <07bd01cc854c$f7c085e0$e74191a0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ge1YhRgR/2tXAVVsrwcT8w)" Content-language: en-us Thread-index: AcyFOkzMQ4x5sIB0SNCHGFjJpV+F8wAEf6Yg References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42A75@xmb-sjc-221.amer.cisco.com> <078001cc851d$4a9a1720$dfce4560$%roni@huawei.com> <4E8F4CD7.20407@alum.mit.edu> <07b601cc8538$89c51880$9d4f4980$%roni@huawei.com> Cc: clue@ietf.org Subject: Re: [clue] interim meeting agenda for framework doc discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 23:57:50 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ge1YhRgR/2tXAVVsrwcT8w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT OK, I will prepare a presentation on issues with the framework version 01 and the way forward and would like to get some time to present it. It will be based on the issues I mentioned here and the comments I sent to the list. I am afraid that part of it will repeat other presentations but this is how you want to handle it. Roni From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: Friday, October 07, 2011 11:44 PM To: Roni Even Cc: Paul Kyzivat; clue@ietf.org Subject: Re: [clue] interim meeting agenda for framework doc discussion We would very much appreciate it if you could prepare a presentation. The chairs have a proposed agenda in terms of order of topics to be discussed, but it was the expectation that the document authors lead the discussion, with the chairs facilitating in order to get consensus on specific issues. Really, no different than how we do things during the WG sessions - we just have more time to discuss issues and we'll have the opportunity to revisit things if we get stuck on a specific issue. I apologize as I should have put names against the agenda items to make that more clear. I don't recall that we told anyone to wait to submit ideas/drafts until the romanow-dispatch-framework document was updated. That document is not a WG document - it is just the only proposal we have on the table that could be considered as a WG deliverable, but that decision has not been made by the WG. We do need input from all WG members to determine the best approach for the CLUE framework deliverable. Thanks, Mary. On Fri, Oct 7, 2011 at 4:31 PM, Roni Even wrote: Hi, I think that the major topics I see for discussion are: 1. The capture area, point and scale attributes. 2. The architecture, relation between EPs, Scene, capture set and how does presentation or presentations fit in the model. 3. Hierarchy of attributes, should they be available for each layer of the model. Scene, capture set, media captures? 4. Where should the protocol be specified, do we split this document to two? And what is the extensibility mechanism. 5. Relation of attributes and encoding parameters to SDP (duplicate?) I can prepare a presentation but is this the chairs want to do it. I was thinking that the chairs will define the discussion topics, I know that the framework is an individual draft but I was under the impression that the chairs will treat it as if we are discussing a WG document and not an individual draft and this was the major reason for having the interim meeting, discussing a WG document. I was considering to prepare an individual draft with other members of the group, was told to wait and see the new revision of the individual draft which is better than the previous one but I expect the discussion to be managed by the WG chairs and based on the document and other inputs including comments that were sent to the list. Please let me know if I should prepare a presentation or are the chairs going to accumulate the issues and present them for better efficiency Regards Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Friday, October 07, 2011 9:03 PM > To: clue@ietf.org > Subject: Re: [clue] interim meeting agenda for framework doc discussion > > Roni, > > On 10/7/11 2:16 PM, Roni Even wrote: > > Hi Mary, > > > > I assume that the comments sent to the list before Monday will also > be > > discussed. > > It may be logistically difficult to formally address them all, since > they may be happening concurrently with the development of the charts > used to guide discussion. People who have provided comments recently > would be well advised to be prepared to bring them up again in context > during the meeting. > > Thanks, > Paul > > > Roni > > > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > Behalf > > Of *Mary Barnes > > *Sent:* Friday, October 07, 2011 8:05 PM > > *To:* Allyn Romanow (allyn) > > *Cc:* clue@ietf.org > > *Subject:* Re: [clue] interim meeting agenda for framework doc > discussion > > > > Hi folks, > > > > Per Allyn's note below, if you do have some ideas (which we very much > > welcome) on particular issues that you would like to present, charts > > would be most helpful as we will have some remote participants. The > > chairs will need all charts (including for the framework) no later > than > > 5pm Eastern on Monday, October 10th. Any charts received after that > time > > may not be able to be presented as the chairs need to get them > uploaded > > and will be busy with other logistics prior to the meeting. > > > > Thanks, > > > > Mary. > > > > On Fri, Oct 7, 2011 at 1:46 AM, Allyn Romanow (allyn) > > > wrote: > > > > HI Folks, > > > > Here is a proposal for the framework portion of the interim meeting. > > > > Goal: Move the draft-romanow-clue-framework toward acceptance as a WG > draft > > > > Agenda: > > > > Overview - 50 minutes > > > > *Overview - presentation by draft authors of new material* > > > > .Area of capture > > > > .Segment switching. VAD. What information in VAD > > > > *Issues* > > > > .Area of Capture > > > > .3 message exchange - provider and consumer. Devices are both. > > > > oInitial capabilities message > > > > .Measurements - are degrees, radians necessary > > > > .Definitions - Roni's email (unless it is sorted out on email) > > > > What are additional issues people feel need to be agreed upon that > stand > > in the way of the document becoming a WG draft? In order to make > > progress, the discussion will be kept to identified issues. New ones > can > > be added during the meeting, of course. > > > > If you have a particular viewpoint on an issue, it would help to have > > some slides to describe it > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --Boundary_(ID_ge1YhRgR/2tXAVVsrwcT8w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

OK,

I will prepare a presentation on issues with the framework version 01 = and the way forward and would like to get some time to present it. It = will be based on the issues I mentioned here and the comments I sent to = the list.

I am afraid that part of it will repeat other presentations but this = is how you want to handle it.

Roni

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: Friday, = October 07, 2011 11:44 PM
To: Roni Even
Cc: Paul = Kyzivat; clue@ietf.org
Subject: Re: [clue] interim meeting = agenda for framework doc discussion

 

We would = very much appreciate it if you could prepare a presentation.  The = chairs have a proposed agenda in terms of order of topics to be = discussed, but it was the expectation that the document authors lead the = discussion, with the chairs facilitating in order to get consensus on = specific issues.  Really, no different than how we do things during = the WG sessions - we just have more time to discuss issues and we'll = have the opportunity to revisit things if we get stuck on a specific = issue.   I apologize as I should have put names against the agenda = items to make that more clear.  

 

I = don't recall that we told anyone to wait to submit ideas/drafts until = the romanow-dispatch-framework document was updated.  That document = is not a WG document - it is just the only proposal we have on the table = that could be considered as a WG deliverable, but that decision has not = been made by the WG.  We do need input from all WG members to = determine the best approach for the CLUE framework deliverable. =  

 

Thanks,

Mary. 

On Fri, Oct 7, 2011 at 4:31 PM, Roni Even <Even.roni@huawei.com> = wrote:

Hi,
I think that the major = topics I see for discussion are:

1. The capture area, point and = scale attributes.
2. The architecture, relation between EPs, Scene, = capture set and how does
presentation or presentations fit in the = model.
3. Hierarchy of attributes, should they be available for each = layer of the
model. Scene, capture set, media captures?
4. Where = should the protocol be specified, do we split this document to = two?
And what is the extensibility mechanism.
5. Relation of = attributes and encoding parameters to SDP (duplicate?)

I can = prepare a presentation but is this the chairs want to do it. I = was
thinking that the chairs will define the discussion topics, I = know that the
framework is an individual draft but I was under the = impression that the
chairs will treat it as if we are discussing a WG = document and not an
individual draft and this was the major reason = for having the interim
meeting, discussing a WG document. I was = considering to prepare an
individual draft with other members of the = group, was told to wait and see
the new revision of the individual = draft which is better than the previous
one but I expect the = discussion to be managed by the WG chairs and based on
the document = and other inputs including comments that were sent to the = list.

Please let me know if I should prepare a presentation or = are the chairs
going to accumulate the issues and present them for = better efficiency

Regards
Roni



> -----Original Message-----
> From: = clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] On = Behalf Of

> Paul = Kyzivat
> Sent: Friday, October 07, 2011 9:03 PM
> To: clue@ietf.org
> Subject: Re: = [clue] interim meeting agenda for framework doc = discussion

>
> = Roni,
>
> On 10/7/11 2:16 PM, Roni Even wrote:
> > = Hi Mary,
> >
> > I assume that the comments sent to = the list before Monday will also
> be
> > = discussed.
>
> It may be logistically difficult to formally = address them all, since
> they may be happening concurrently with = the development of the charts
> used to guide discussion. People = who have provided comments recently
> would be well advised to be = prepared to bring them up again in context
> during the = meeting.
>
>       Thanks,
>   =     Paul
>
> > Roni
> >
> > = *From:*clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] = *On
> Behalf
> > Of *Mary Barnes
> > *Sent:* = Friday, October 07, 2011 8:05 PM
> > *To:* Allyn Romanow = (allyn)
> > *Cc:* clue@ietf.org
> > *Subject:* = Re: [clue] interim meeting agenda for framework doc
> = discussion
> >
> > Hi folks,
> >
> > = Per Allyn's note below, if you do have some ideas (which we very = much
> > welcome) on particular issues that you would like to = present, charts
> > would be most helpful as we will have some = remote participants. The
> > chairs will need all charts = (including for the framework) no later
> than
> > 5pm = Eastern on Monday, October 10th. Any charts received after that
> = time
> > may not be able to be presented as the chairs need to = get them
> uploaded
> > and will be busy with other = logistics prior to the meeting.
> >
> > = Thanks,
> >
> > Mary.
> >
> > On = Fri, Oct 7, 2011 at 1:46 AM, Allyn Romanow (allyn)
> <allyn@cisco.com
> > = <mailto:allyn@cisco.com>> = wrote:
> >
> > HI Folks,
> >
> > = Here is a proposal for the framework portion of the interim = meeting.
> >
> > Goal: Move the = draft-romanow-clue-framework toward acceptance as a WG
> = draft
> >
> > Agenda:
> >
> > = Overview - 50 minutes
> >
> > *Overview - presentation = by draft authors of new material*
> >
> > .Area of = capture
> >
> > .Segment switching. VAD. What = information in VAD
> >
> > *Issues*
> = >
> > .Area of Capture
> >
> > .3 message = exchange - provider and consumer. Devices are both.
> >
> = > oInitial capabilities message
> >
> > = .Measurements - are degrees, radians necessary
> >
> > = .Definitions - Roni's email (unless it is sorted out on email)
> = >
> > What are additional issues people feel need to be = agreed upon that
> stand
> > in the way of the document = becoming a WG draft? In order to make
> > progress, the = discussion will be kept to identified issues. New ones
> = can
> > be added during the meeting, of course.
> = >
> > If you have a particular viewpoint on an issue, it = would help to have
> > some slides to describe it
> = >
> >
> > = _______________________________________________
> > clue = mailing list
> > clue@ietf.org <mailto:clue@ietf.org>
> > https://www.ietf.org/mailman/listinfo/clue
> = >
> >
> >
> > = _______________________________________________
> > clue = mailing list
> > clue@ietf.org
> > https://www.ietf.org/mailman/listinfo/clue
><= br>> _______________________________________________
> clue = mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue

_= ______________________________________________
clue mailing = list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

 

= --Boundary_(ID_ge1YhRgR/2tXAVVsrwcT8w)-- From allyn@cisco.com Fri Oct 7 23:00:31 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDFA21F8B4C for ; Fri, 7 Oct 2011 23:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.763 X-Spam-Level: X-Spam-Status: No, score=-2.763 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EH2-T5FIy7j for ; Fri, 7 Oct 2011 23:00:30 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4695621F8B42 for ; Fri, 7 Oct 2011 23:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=7552; q=dns/txt; s=iport; t=1318053826; x=1319263426; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=IG7cei8zdkkf4IjBKNtkVWsXz/PMJWqSzIdbT9M0wSE=; b=ZaI6WcB2RvOlP+PgLICvcHKtvzvduZ/vCdPmD5MXD3stdF99aXWSC+Xt /e3XRVABJMVCgXVvVACjUAuUDijZM813WsL3j6YUwMycGkBfJi2hg8atw 6XQaqM290KCupmKuyLQPridPjULwaoZ0swJrlJRjJhkKLVQVjIO0y/rUx M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0AAIrnj06rRDoI/2dsb2JhbABEDphujyGBBYFTAQEBAQIBAQEBDwEdCjQEDAcEAgEIEQEDAQEBCgYXAQYBJh8DBggBAQQBEggah1wHl2sBngcDhk9hBId9hlUCik+LYFc X-IronPort-AV: E=Sophos;i="4.68,507,1312156800"; d="scan'208";a="6676801" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 08 Oct 2011 06:03:43 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9863hAr029522; Sat, 8 Oct 2011 06:03:43 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 23:03:43 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Oct 2011 23:03:38 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42DE8@xmb-sjc-221.amer.cisco.com> In-Reply-To: <07b601cc8538$89c51880$9d4f4980$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] interim meeting agenda for framework doc discussion Thread-Index: AcyFI+k3fE8/xsRNR/SrBxz6A+QdcwAEnqrgABGTk1A= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42A75@xmb-sjc-221.amer.cisco.com><078001cc851d$4a9a1720$dfce4560$%roni@huawei.com><4E8F4CD7.20407@alum.mit.edu> <07b601cc8538$89c51880$9d4f4980$%roni@huawei.com> From: "Allyn Romanow (allyn)" To: "Roni Even" , "Paul Kyzivat" , X-OriginalArrivalTime: 08 Oct 2011 06:03:43.0474 (UTC) FILETIME=[08AC9D20:01CC8580] Subject: Re: [clue] interim meeting agenda for framework doc discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 06:00:31 -0000 Hi Roni and folks, I'm really glad that you will prepare slides on your thoughts. Similarly that Marshall will do a presentation on his views of locating scenes.=20 Here are some further thoughts in the hope of preparing a good list of issues in advance of the meeting. I had listed as an issue the messaging model-- the fact that an entity has to be both sender and receiver. We had thought that might need to be gone over, since the model is different than the SDP offer answer messaging style. But perhaps it is not necessary? What do people think? If it's clear and not an issue, then we don't need to spend time on it. I'm fine either way, but I'm not sure if there is a desire/need for this? #1 below I believe this is what we have identified as capture area, mostly. Brian will do a presentation based on the new material on this in the draft. Then we also listed it as a primarily issue to discuss. It will be good to have your thoughts laid out as a basis for discussion. I think #2 - architecture and #3 - attributes didn't really show up in the issues that I proposed. I'm not sure specifically what you have in mind and I'm glad you will bring these issues up fully. =20 #4 seems two issues to me. One is extensibility. We have mostly thought of this in terms of attributes, so it will be good to hear your thoughts. The second issues is specifying the protocol. #5 relation to SDP On Specifying the protocol and relation to SDP, until now I have been trying to defer talking much about these -- Saying that we should settle on a framework and data model, before talking about how we would implement it in IETF protocols. However, time is passing and it is certainly getting to be time to talk about this. I think that it may be easier to have this discussion in face of a particular proposal. I'm not sure how the chairs want to prioritize these 2 issues for this interim meeting. =20 Best, Allyn > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Roni Even > Sent: Friday, October 07, 2011 2:32 PM > To: 'Paul Kyzivat'; clue@ietf.org > Subject: Re: [clue] interim meeting agenda for framework doc discussion >=20 > Hi, > I think that the major topics I see for discussion are: >=20 > 1. The capture area, point and scale attributes. > 2. The architecture, relation between EPs, Scene, capture set and how > does > presentation or presentations fit in the model. > 3. Hierarchy of attributes, should they be available for each layer of > the > model. Scene, capture set, media captures? > 4. Where should the protocol be specified, do we split this document to > two? > And what is the extensibility mechanism. > 5. Relation of attributes and encoding parameters to SDP (duplicate?) >=20 > I can prepare a presentation but is this the chairs want to do it. I > was > thinking that the chairs will define the discussion topics, I know that > the > framework is an individual draft but I was under the impression that > the > chairs will treat it as if we are discussing a WG document and not an > individual draft and this was the major reason for having the interim > meeting, discussing a WG document. I was considering to prepare an > individual draft with other members of the group, was told to wait and > see > the new revision of the individual draft which is better than the > previous > one but I expect the discussion to be managed by the WG chairs and > based on > the document and other inputs including comments that were sent to the > list. >=20 > Please let me know if I should prepare a presentation or are the chairs > going to accumulate the issues and present them for better efficiency >=20 > Regards > Roni >=20 >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > > Paul Kyzivat > > Sent: Friday, October 07, 2011 9:03 PM > > To: clue@ietf.org > > Subject: Re: [clue] interim meeting agenda for framework doc > discussion > > > > Roni, > > > > On 10/7/11 2:16 PM, Roni Even wrote: > > > Hi Mary, > > > > > > I assume that the comments sent to the list before Monday will also > > be > > > discussed. > > > > It may be logistically difficult to formally address them all, since > > they may be happening concurrently with the development of the charts > > used to guide discussion. People who have provided comments recently > > would be well advised to be prepared to bring them up again in > context > > during the meeting. > > > > Thanks, > > Paul > > > > > Roni > > > > > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > > Behalf > > > Of *Mary Barnes > > > *Sent:* Friday, October 07, 2011 8:05 PM > > > *To:* Allyn Romanow (allyn) > > > *Cc:* clue@ietf.org > > > *Subject:* Re: [clue] interim meeting agenda for framework doc > > discussion > > > > > > Hi folks, > > > > > > Per Allyn's note below, if you do have some ideas (which we very > much > > > welcome) on particular issues that you would like to present, > charts > > > would be most helpful as we will have some remote participants. The > > > chairs will need all charts (including for the framework) no later > > than > > > 5pm Eastern on Monday, October 10th. Any charts received after that > > time > > > may not be able to be presented as the chairs need to get them > > uploaded > > > and will be busy with other logistics prior to the meeting. > > > > > > Thanks, > > > > > > Mary. > > > > > > On Fri, Oct 7, 2011 at 1:46 AM, Allyn Romanow (allyn) > > > > > wrote: > > > > > > HI Folks, > > > > > > Here is a proposal for the framework portion of the interim > meeting. > > > > > > Goal: Move the draft-romanow-clue-framework toward acceptance as a > WG > > draft > > > > > > Agenda: > > > > > > Overview - 50 minutes > > > > > > *Overview - presentation by draft authors of new material* > > > > > > .Area of capture > > > > > > .Segment switching. VAD. What information in VAD > > > > > > *Issues* > > > > > > .Area of Capture > > > > > > .3 message exchange - provider and consumer. Devices are both. > > > > > > oInitial capabilities message > > > > > > .Measurements - are degrees, radians necessary > > > > > > .Definitions - Roni's email (unless it is sorted out on email) > > > > > > What are additional issues people feel need to be agreed upon that > > stand > > > in the way of the document becoming a WG draft? In order to make > > > progress, the discussion will be kept to identified issues. New > ones > > can > > > be added during the meeting, of course. > > > > > > If you have a particular viewpoint on an issue, it would help to > have > > > some slides to describe it > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Sat Oct 8 10:21:25 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18B621F8B89 for ; Sat, 8 Oct 2011 10:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.481 X-Spam-Level: X-Spam-Status: No, score=-103.481 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kze5-YXQsHS5 for ; Sat, 8 Oct 2011 10:21:23 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB0D421F8BE5 for ; Sat, 8 Oct 2011 10:21:22 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4731231vcb.31 for ; Sat, 08 Oct 2011 10:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pTaY6+SPOf5Oif/VFwPzYYDqfdXc80Pfsb9T13m39Uk=; b=kKL8Er//x5/Jtt75vIjRuNUVXj41obBWWumfAmypUTzm8TzGO5DI14FuAfhYsi4c16 KI7J43x53SSCq5Kryv1+Qw6OGLxaOcC5TZ39zhNmQXpyVla+yna29zGJOdnBojG3wo8L FxjB0eoOAhMlSrm0S3YDxR/9zIFjh2C808poA= MIME-Version: 1.0 Received: by 10.52.36.197 with SMTP id s5mr7316329vdj.36.1318094678893; Sat, 08 Oct 2011 10:24:38 -0700 (PDT) Received: by 10.52.75.198 with HTTP; Sat, 8 Oct 2011 10:24:38 -0700 (PDT) In-Reply-To: <07bd01cc854c$f7c085e0$e74191a0$%roni@huawei.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42A75@xmb-sjc-221.amer.cisco.com> <078001cc851d$4a9a1720$dfce4560$%roni@huawei.com> <4E8F4CD7.20407@alum.mit.edu> <07b601cc8538$89c51880$9d4f4980$%roni@huawei.com> <07bd01cc854c$f7c085e0$e74191a0$%roni@huawei.com> Date: Sat, 8 Oct 2011 12:24:38 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=20cf307f30781da41604aeccd592 Cc: clue@ietf.org Subject: Re: [clue] interim meeting agenda for framework doc discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 17:21:36 -0000 --20cf307f30781da41604aeccd592 Content-Type: text/plain; charset=ISO-8859-1 It's not a problem if there might be some duplication at this point as it's very important to get multiple perspectives on the issues. Discussing two different viewpoints might help us coalesce into a single one that we could then put on the table to revisit on Wed. morning. The advantage of the presentation is that we'll have your thoughts and ideas more precisely recorded as part of the proceedings and that should also be helpful for remote participants. Thanks much, Mary. On Fri, Oct 7, 2011 at 6:58 PM, Roni Even wrote: > OK,**** > > I will prepare a presentation on issues with the framework version 01 and > the way forward and would like to get some time to present it. It will be > based on the issues I mentioned here and the comments I sent to the list.* > *** > > I am afraid that part of it will repeat other presentations but this is how > you want to handle it.**** > > Roni**** > > ** ** > > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* Friday, October 07, 2011 11:44 PM > *To:* Roni Even > *Cc:* Paul Kyzivat; clue@ietf.org > > *Subject:* Re: [clue] interim meeting agenda for framework doc discussion* > *** > > ** ** > > We would very much appreciate it if you could prepare a presentation. The > chairs have a proposed agenda in terms of order of topics to be discussed, > but it was the expectation that the document authors lead the discussion, > with the chairs facilitating in order to get consensus on specific issues. > Really, no different than how we do things during the WG sessions - we just > have more time to discuss issues and we'll have the opportunity to revisit > things if we get stuck on a specific issue. I apologize as I should have > put names against the agenda items to make that more clear. **** > > ** ** > > I don't recall that we told anyone to wait to submit ideas/drafts until the > romanow-dispatch-framework document was updated. That document is not a WG > document - it is just the only proposal we have on the table that could be > considered as a WG deliverable, but that decision has not been made by the > WG. We do need input from all WG members to determine the best approach for > the CLUE framework deliverable. **** > > ** ** > > Thanks,**** > > Mary. **** > > On Fri, Oct 7, 2011 at 4:31 PM, Roni Even wrote:*** > * > > Hi, > I think that the major topics I see for discussion are: > > 1. The capture area, point and scale attributes. > 2. The architecture, relation between EPs, Scene, capture set and how does > presentation or presentations fit in the model. > 3. Hierarchy of attributes, should they be available for each layer of the > model. Scene, capture set, media captures? > 4. Where should the protocol be specified, do we split this document to > two? > And what is the extensibility mechanism. > 5. Relation of attributes and encoding parameters to SDP (duplicate?) > > I can prepare a presentation but is this the chairs want to do it. I was > thinking that the chairs will define the discussion topics, I know that the > framework is an individual draft but I was under the impression that the > chairs will treat it as if we are discussing a WG document and not an > individual draft and this was the major reason for having the interim > meeting, discussing a WG document. I was considering to prepare an > individual draft with other members of the group, was told to wait and see > the new revision of the individual draft which is better than the previous > one but I expect the discussion to be managed by the WG chairs and based on > the document and other inputs including comments that were sent to the > list. > > Please let me know if I should prepare a presentation or are the chairs > going to accumulate the issues and present them for better efficiency > > Regards > Roni**** > > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of* > *** > > > Paul Kyzivat > > Sent: Friday, October 07, 2011 9:03 PM > > To: clue@ietf.org > > Subject: Re: [clue] interim meeting agenda for framework doc discussion* > *** > > > > > Roni, > > > > On 10/7/11 2:16 PM, Roni Even wrote: > > > Hi Mary, > > > > > > I assume that the comments sent to the list before Monday will also > > be > > > discussed. > > > > It may be logistically difficult to formally address them all, since > > they may be happening concurrently with the development of the charts > > used to guide discussion. People who have provided comments recently > > would be well advised to be prepared to bring them up again in context > > during the meeting. > > > > Thanks, > > Paul > > > > > Roni > > > > > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > > Behalf > > > Of *Mary Barnes > > > *Sent:* Friday, October 07, 2011 8:05 PM > > > *To:* Allyn Romanow (allyn) > > > *Cc:* clue@ietf.org > > > *Subject:* Re: [clue] interim meeting agenda for framework doc > > discussion > > > > > > Hi folks, > > > > > > Per Allyn's note below, if you do have some ideas (which we very much > > > welcome) on particular issues that you would like to present, charts > > > would be most helpful as we will have some remote participants. The > > > chairs will need all charts (including for the framework) no later > > than > > > 5pm Eastern on Monday, October 10th. Any charts received after that > > time > > > may not be able to be presented as the chairs need to get them > > uploaded > > > and will be busy with other logistics prior to the meeting. > > > > > > Thanks, > > > > > > Mary. > > > > > > On Fri, Oct 7, 2011 at 1:46 AM, Allyn Romanow (allyn) > > > > > wrote: > > > > > > HI Folks, > > > > > > Here is a proposal for the framework portion of the interim meeting. > > > > > > Goal: Move the draft-romanow-clue-framework toward acceptance as a WG > > draft > > > > > > Agenda: > > > > > > Overview - 50 minutes > > > > > > *Overview - presentation by draft authors of new material* > > > > > > .Area of capture > > > > > > .Segment switching. VAD. What information in VAD > > > > > > *Issues* > > > > > > .Area of Capture > > > > > > .3 message exchange - provider and consumer. Devices are both. > > > > > > oInitial capabilities message > > > > > > .Measurements - are degrees, radians necessary > > > > > > .Definitions - Roni's email (unless it is sorted out on email) > > > > > > What are additional issues people feel need to be agreed upon that > > stand > > > in the way of the document becoming a WG draft? In order to make > > > progress, the discussion will be kept to identified issues. New ones > > can > > > be added during the meeting, of course. > > > > > > If you have a particular viewpoint on an issue, it would help to have > > > some slides to describe it > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > ** ** > --20cf307f30781da41604aeccd592 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It's not a problem if there might be some duplication at this point as = it's very important to get multiple perspectives on the issues. =A0Disc= ussing two different viewpoints might help us coalesce into a single one th= at we could then put on the table to revisit on Wed. morning. =A0 The advan= tage of the presentation is that we'll have your thoughts and ideas mor= e precisely recorded as part of the proceedings and that should also be hel= pful for remote participants.

Thanks much,
 --20cf307f30781da41604aeccd592-- From mary.ietf.barnes@gmail.com Sat Oct 8 10:30:58 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7A221F8C34 for ; Sat, 8 Oct 2011 10:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.482 X-Spam-Level: X-Spam-Status: No, score=-103.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stnh-z99Oc1h for ; Sat, 8 Oct 2011 10:30:57 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2B721F8C31 for ; Sat, 8 Oct 2011 10:30:57 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4734632vcb.31 for ; Sat, 08 Oct 2011 10:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JNJaRg31CY4MWLVtB4fWjNQXi9VAFacl/RrjjM8h3vE=; b=t3CkHRGFYseHijOO4E8eHPTRB7AJCcmneGsDRtRmxOAma/0tbzmf7+eZ2SiAyWPiFJ xr/2sNMrwAR8jWp0Dv0ct2gqHaRNBBu03djYHcoIh/9ZfyAtnP+SIahToXnOElQ6/F4d J0hdYbTrfe2G5UYO2edV29gj420lFzTThEVj8= MIME-Version: 1.0 Received: by 10.52.34.207 with SMTP id b15mr7277499vdj.19.1318095253968; Sat, 08 Oct 2011 10:34:13 -0700 (PDT) Received: by 10.52.75.198 with HTTP; Sat, 8 Oct 2011 10:34:13 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42DE8@xmb-sjc-221.amer.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42A75@xmb-sjc-221.amer.cisco.com> <078001cc851d$4a9a1720$dfce4560$%roni@huawei.com> <4E8F4CD7.20407@alum.mit.edu> <07b601cc8538$89c51880$9d4f4980$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42DE8@xmb-sjc-221.amer.cisco.com> Date: Sat, 8 Oct 2011 12:34:13 -0500 Message-ID: From: Mary Barnes To: "Allyn Romanow (allyn)" Content-Type: multipart/alternative; boundary=20cf3079be9064983a04aeccf71b Cc: clue@ietf.org Subject: Re: [clue] interim meeting agenda for framework doc discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 17:30:59 -0000 --20cf3079be9064983a04aeccf71b Content-Type: text/plain; charset=ISO-8859-1 Hi Allyn, Responses inline below [MB]. Thanks, Mary. On Sat, Oct 8, 2011 at 1:03 AM, Allyn Romanow (allyn) wrote: > Hi Roni and folks, > > I'm really glad that you will prepare slides on your thoughts. Similarly > that Marshall will do a presentation on his views of locating scenes. > > Here are some further thoughts in the hope of preparing a good list of > issues in advance of the meeting. > > > I had listed as an issue the messaging model-- the fact that an entity > has to be both sender and receiver. We had thought that might need to be > gone over, since the model is different than the SDP offer answer > messaging style. But perhaps it is not necessary? What do people think? > If it's clear and not an issue, then we don't need to spend time on it. > I'm fine either way, but I'm not sure if there is a desire/need for > this? > [MB] I think it would be worthwhile to have some discussion on this. We will need to be very clear about this in the framework document as folks outside CLUE will want to know why it is different - in particular since the solution will (most likely) use SDP for describing the information about the streams and their relationships. It might actually be useful to add a section in the framework around all of this. [/MB] > > #1 below I believe this is what we have identified as capture area, > mostly. Brian will do a presentation based on the new material on this > in the draft. > Then we also listed it as a primarily issue to discuss. It will be good > to have your thoughts laid out as a basis for discussion. > > I think #2 - architecture and > #3 - attributes didn't really show up in the issues that I proposed. > I'm not sure specifically what you have in mind and I'm glad you will > bring these issues up fully. > > #4 seems two issues to me. > One is extensibility. We have mostly thought of this in terms of > attributes, so it will be good to hear your thoughts. > > The second issues is specifying the protocol. > > #5 relation to SDP > > On Specifying the protocol and relation to SDP, until now I have been > trying to defer talking much about these -- Saying that we should settle > on a framework and data model, before talking about how we would > implement it in IETF protocols. However, time is passing and it is > certainly getting to be time to talk about this. I think that it may be > easier to have this discussion in face of a particular proposal. I'm not > sure how the chairs want to prioritize these 2 issues for this interim > meeting. > [MB] While the other items are higher priority (we really want to ensure we leave this meeting with resolution to issues identified thus far), starting to think about this is a good idea. In particular given that RTCWEB is looking at the relationship to SDP as well. If someone does have a strawman proposal to put forth, that would be great. [/MB] > > > Best, > Allyn > > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > > Roni Even > > Sent: Friday, October 07, 2011 2:32 PM > > To: 'Paul Kyzivat'; clue@ietf.org > > Subject: Re: [clue] interim meeting agenda for framework doc > discussion > > > > Hi, > > I think that the major topics I see for discussion are: > > > > 1. The capture area, point and scale attributes. > > 2. The architecture, relation between EPs, Scene, capture set and how > > does > > presentation or presentations fit in the model. > > 3. Hierarchy of attributes, should they be available for each layer of > > the > > model. Scene, capture set, media captures? > > 4. Where should the protocol be specified, do we split this document > to > > two? > > And what is the extensibility mechanism. > > 5. Relation of attributes and encoding parameters to SDP (duplicate?) > > > > I can prepare a presentation but is this the chairs want to do it. I > > was > > thinking that the chairs will define the discussion topics, I know > that > > the > > framework is an individual draft but I was under the impression that > > the > > chairs will treat it as if we are discussing a WG document and not an > > individual draft and this was the major reason for having the interim > > meeting, discussing a WG document. I was considering to prepare an > > individual draft with other members of the group, was told to wait and > > see > > the new revision of the individual draft which is better than the > > previous > > one but I expect the discussion to be managed by the WG chairs and > > based on > > the document and other inputs including comments that were sent to the > > list. > > > > Please let me know if I should prepare a presentation or are the > chairs > > going to accumulate the issues and present them for better efficiency > > > > Regards > > Roni > > > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of > > > Paul Kyzivat > > > Sent: Friday, October 07, 2011 9:03 PM > > > To: clue@ietf.org > > > Subject: Re: [clue] interim meeting agenda for framework doc > > discussion > > > > > > Roni, > > > > > > On 10/7/11 2:16 PM, Roni Even wrote: > > > > Hi Mary, > > > > > > > > I assume that the comments sent to the list before Monday will > also > > > be > > > > discussed. > > > > > > It may be logistically difficult to formally address them all, since > > > they may be happening concurrently with the development of the > charts > > > used to guide discussion. People who have provided comments recently > > > would be well advised to be prepared to bring them up again in > > context > > > during the meeting. > > > > > > Thanks, > > > Paul > > > > > > > Roni > > > > > > > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > > > Behalf > > > > Of *Mary Barnes > > > > *Sent:* Friday, October 07, 2011 8:05 PM > > > > *To:* Allyn Romanow (allyn) > > > > *Cc:* clue@ietf.org > > > > *Subject:* Re: [clue] interim meeting agenda for framework doc > > > discussion > > > > > > > > Hi folks, > > > > > > > > Per Allyn's note below, if you do have some ideas (which we very > > much > > > > welcome) on particular issues that you would like to present, > > charts > > > > would be most helpful as we will have some remote participants. > The > > > > chairs will need all charts (including for the framework) no later > > > than > > > > 5pm Eastern on Monday, October 10th. Any charts received after > that > > > time > > > > may not be able to be presented as the chairs need to get them > > > uploaded > > > > and will be busy with other logistics prior to the meeting. > > > > > > > > Thanks, > > > > > > > > Mary. > > > > > > > > On Fri, Oct 7, 2011 at 1:46 AM, Allyn Romanow (allyn) > > > > > > > wrote: > > > > > > > > HI Folks, > > > > > > > > Here is a proposal for the framework portion of the interim > > meeting. > > > > > > > > Goal: Move the draft-romanow-clue-framework toward acceptance as a > > WG > > > draft > > > > > > > > Agenda: > > > > > > > > Overview - 50 minutes > > > > > > > > *Overview - presentation by draft authors of new material* > > > > > > > > .Area of capture > > > > > > > > .Segment switching. VAD. What information in VAD > > > > > > > > *Issues* > > > > > > > > .Area of Capture > > > > > > > > .3 message exchange - provider and consumer. Devices are both. > > > > > > > > oInitial capabilities message > > > > > > > > .Measurements - are degrees, radians necessary > > > > > > > > .Definitions - Roni's email (unless it is sorted out on email) > > > > > > > > What are additional issues people feel need to be agreed upon that > > > stand > > > > in the way of the document becoming a WG draft? In order to make > > > > progress, the discussion will be kept to identified issues. New > > ones > > > can > > > > be added during the meeting, of course. > > > > > > > > If you have a particular viewpoint on an issue, it would help to > > have > > > > some slides to describe it > > > > > > > > > > > > _______________________________________________ > > > > clue mailing list > > > > clue@ietf.org > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > > > > > > > > _______________________________________________ > > > > clue mailing list > > > > clue@ietf.org > > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf3079be9064983a04aeccf71b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Allyn,

Responses inline below [MB].

Thanks,
Mary.=A0

On Sat= , Oct 8, 2011 at 1:03 AM, Allyn Romanow (allyn) <allyn@cisco.com> wrote:
Hi Roni and folks,

I'm really glad that you will prepare slides on your thoughts. Similarl= y
that Marshall will do a presentation on his views of locating scenes.

Here are some further thoughts in the hope of preparing a good list of
issues in advance of the meeting.


I had listed as an issue the messaging model-- the fact that an entity
has to be both sender and receiver. We had thought that might need to be gone over, since the model is different than the SDP offer answer
messaging style. But perhaps it is not necessary? What do people think?
If it's clear and not an issue, then we don't need to spend time on= it.
I'm fine either way, but I'm not sure if there is a desire/need for=
this?
[MB] I think it would be worthwhile to have some= discussion on this. =A0We will need to be very clear about this in the fra= mework document as folks outside CLUE will want to know why it is different= - in particular since the solution will (most likely) use SDP for describi= ng the information about the streams and their relationships. It might actu= ally be useful to add a section in the framework around all of this. [/MB]= =A0

#1 below I believe this is what we have identified as capture area,
mostly. Brian will do a presentation based on the new material on this
in the draft.
Then we also listed it as a primarily issue to discuss. It will be good
to have your thoughts laid out as a basis for discussion.

I think #2 - architecture and
#3 - attributes =A0didn't really show up in the issues that I proposed.=
I'm not sure specifically what you have in mind and I'm glad you wi= ll
bring these issues up fully.

#4 seems two issues to me.
One is extensibility. We have mostly thought of this in terms of
attributes, so it will be good to hear your thoughts.

The second issues is specifying the protocol.

#5 relation to SDP

On Specifying the protocol and relation to SDP, until now I have been
trying to defer talking much about these -- Saying that we should settle on a framework and data model, before talking about how we would
implement it in IETF protocols. =A0However, time is passing and it is
certainly getting to be time to talk about this. =A0I think that it may be<= br> easier to have this discussion in face of a particular proposal. I'm no= t
sure how the chairs want to prioritize these 2 issues for this interim
meeting.
[MB] While the other items are higher priorit= y (we really want to ensure we leave this meeting with resolution to issues= identified thus far), starting to think about this is a good idea. In part= icular given that RTCWEB is looking at the relationship to SDP as well. =A0= If someone does have a strawman proposal to put forth, that would be great.= =A0[/MB]


Best,
Allyn



> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
Of
> Roni Even
> Sent: Friday, October 07, 2011 2:32 PM
> To: 'Paul Kyzivat'; clue@ietf= .org
> Subject: Re: [clue] interim meeting = agenda for framework doc
discussion
>
> Hi,
> I think that the major topics I see for discussion are:
>
> 1. The capture area, point and scale attributes.
> 2. The architecture, relation between EPs, Scene, capture set and how<= br> > does
> presentation or presentations fit in the model.
> 3. Hierarchy of attributes, should they be available for each layer of=
> the
> model. Scene, capture set, media captures?
> 4. Where should the protocol be specified, do we split this document to
> two?
> And what is the extensibility mechanism.
> 5. Relation of attributes and encoding parameters to SDP (duplicate?)<= br> >
> I can prepare a presentation but is this the chairs want to do it. I > was
> thinking that the chairs will define the discussion topics, I know
that
> the
> framework is an individual draft but I was under the impression that > the
> chairs will treat it as if we are discussing a WG document and not an<= br> > individual draft and this was the major reason for having the interim<= br> > meeting, discussing a WG document. I was considering to prepare an
> individual draft with other members of the group, was told to wait and=
> see
> the new revision of the individual draft which is better than the
> previous
> one but I expect the discussion to be managed by the WG chairs and
> based on
> the document and other inputs including comments that were sent to the=
> list.
>
> Please let me know if I should prepare a presentation or are the
chairs
> going to accumulate the issues and present them for better efficiency<= br> >
> Regards
> Roni
>
>
> > -----Original Message-----
> > From: clue-bounces@ietf.= org [mailto:clue-bounces@ietf.= org] On Behalf
> Of
> > Paul Kyzivat
> > Sent: Friday, October 07, 2011 9:03 PM
> > To: clue@ietf.org
> > Subject: Re: [clue] interim meeting agenda for framework doc
> discussion
> >
> > Roni,
> >
> > On 10/7/11 2:16 PM, Roni Even wrote:
> > > Hi Mary,
> > >
> > > I assume that the comments sent to the list before Monday wi= ll
also
> > be
> > > discussed.
> >
> > It may be logistically difficult to formally address them all, si= nce
> > they may be happening concurrently with the development of the charts
> > used to guide discussion. People who have provided comments recen= tly
> > would be well advised to be prepared to bring them up again in > context
> > during the meeting.
> >
> > =A0 =A0 Thanks,
> > =A0 =A0 Paul
> >
> > > Roni
> > >
> > > *From:*clue-bounces= @ietf.org [mailto:clue-bounces= @ietf.org] *On
> > Behalf
> > > Of *Mary Barnes
> > > *Sent:* Friday, October 07, 2011 8:05 PM
> > > *To:* Allyn Romanow (allyn)
> > > *Cc:* clue@ietf.org
> > > *Subject:* Re: [clue] interim meeting agenda for framework d= oc
> > discussion
> > >
> > > Hi folks,
> > >
> > > Per Allyn's note below, if you do have some ideas (which= we very
> much
> > > welcome) on particular issues that you would like to present= ,
> charts
> > > would be most helpful as we will have some remote participan= ts.
The
> > > chairs will need all charts (including for the framework) no= later
> > than
> > > 5pm Eastern on Monday, October 10th. Any charts received aft= er
that
> > time
> > > may not be able to be presented as the chairs need to get th= em
> > uploaded
> > > and will be busy with other logistics prior to the meeting.<= br> > > >
> > > Thanks,
> > >
> > > Mary.
> > >
> > > On Fri, Oct 7, 2011 at 1:46 AM, Allyn Romanow (allyn)
> > <allyn@cisco.com
> > > <mailto:allyn@cisco.co= m>> wrote:
> > >
> > > HI Folks,
> > >
> > > Here is a proposal for the framework portion of the interim<= br> > meeting.
> > >
> > > Goal: Move the draft-romanow-clue-framework toward acceptanc= e as a
> WG
> > draft
> > >
> > > Agenda:
> > >
> > > Overview - 50 minutes
> > >
> > > *Overview - presentation by draft authors of new material* > > >
> > > .Area of capture
> > >
> > > .Segment switching. VAD. What information in VAD
> > >
> > > *Issues*
> > >
> > > .Area of Capture
> > >
> > > .3 message exchange - provider and consumer. Devices are bot= h.
> > >
> > > oInitial capabilities message
> > >
> > > .Measurements - are degrees, radians necessary
> > >
> > > .Definitions - Roni's email (unless it is sorted out on = email)
> > >
> > > What are additional issues people feel need to be agreed upo= n that
> > stand
> > > in the way of the document becoming a WG draft? In order to = make
> > > progress, the discussion will be kept to identified issues. = New
> ones
> > can
> > > be added during the meeting, of course.
> > >
> > > If you have a particular viewpoint on an issue, it would hel= p to
> have
> > > some slides to describe it
> > >
> > >
> > > _______________________________________________
> > > clue mailing list
> > > clue@ietf.org <mailt= o:clue@ietf.org>
> > > https://www.ietf.org/mailman/listinfo/clue
> > >
> > >
> > >
> > > _______________________________________________
> > > clue mailing list
> > > clue@ietf.org
> > > https://www.ietf.org/mailman/listinfo/clue
> >
> > _______________________________________________
> > clue mailing list
> > clue@ietf.org
> > https://www.ietf.org/mailman/listinfo/clue
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf3079be9064983a04aeccf71b-- From Christian.Groves@nteczone.com Sun Oct 9 17:41:55 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D111A21F8B6C for ; Sun, 9 Oct 2011 17:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTzmM2md0sYa for ; Sun, 9 Oct 2011 17:41:55 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id E202521F8B4C for ; Sun, 9 Oct 2011 17:41:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcAAEE+kk520fOd/2dsb2JhbAAMN5hwkgABAQEDAQEBATUbGwoBDAQLEQQBAQEJFggHCQMCAQIBFR8JCAYNAQUCAQEXh2MHtjIDh0MEjlcClwM Received: from ppp118-209-243-157.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.243.157]) by ipmail07.adl2.internode.on.net with ESMTP; 10 Oct 2011 11:11:52 +1030 Message-ID: <4E923F4C.5090902@nteczone.com> Date: Mon, 10 Oct 2011 11:41:48 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Allyn Romanow (allyn)" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C85189@xmb-sjc-221.amer.cisco.com> <4E8E6B36.9000106@nteczone.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C8527D@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C8527D@xmb-sjc-221.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] interim meeting-- Requirements doc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 00:41:55 -0000 Hello Allyn, Please see my response below. Regards, Christian On 7/10/2011 3:41 PM, Allyn Romanow (allyn) wrote: > Hi Christian, > Thanks for your comments- > Here are my thoughts on them- > Please see inline. > >> -----Original Message----- >> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >> Sent: Thursday, October 06, 2011 8:00 PM >> To: Allyn Romanow (allyn) >> Cc: clue@ietf.org >> Subject: Re: [clue] interim meeting-- Requirements doc >> >> Hello Allyn, >> >> Unfortunately I won't be at next weeks interim. I'd spend more time in >> the air than at the meeting :-(. >> >> I had two comments on the use cases draft that I didn't get a response >> to which relate to the requirements documents. >> >> 5) Section 3: [CNG] Will there be any attempt to link the requirements >> to certain uses cases?? For example: The RTCWEB requirements document >> indicates which requirements are derived from which use cases. > AR- I don't feel it is necessary, although I know it is a style that > some folks use. If the WG feels it is worthwhile, it can be done. > We had done this in earlier versions as a tool, but removed it in the > most recent draft. > What would be the advantage or usefulness for adding doing it now? [CNG] I think the advantage is traceability. As Mary mentioned it helps new people figure out the link between requirements and use cases. It I think would also provide us with a checklist to ensure that both the use cases and requirements align. > >> 6) Section 3.x: [CNG] The framework draft sect 6.1 indicates that > media >> descriptions are dynamic. I.e. capabilities may change. There's > nothing >> explicit in the requirements to support this. Likewise there doesn't >> appear to be a use case to support that. Do we need to add one for >> that? >> > AR- Yes, I agree with you that there isn't a use case that describes a > receiver taking advantage of a change in encoding characteristics, or > other attributes. I don't feel that there needs to a use case, but we > could add one if people feel it is necessary. > > If you were to put in a requirement for this, it would not be to make > capabilities dynamic, as that is tied to the particular solution > mechanism we are proposing. It would be more along the lines that > endpoints may change the characteristics of what they send.. which > doesn't seem to me to be much of a requirement. [CNG] Why isn't it much of a requirement? It does have eventual non-neglible protocol and system impacts about described how data is removed, replaced, flow are co-ordinated etc. > >> Also a couple of additional comments on >> draft-ietf-clue-telepresence-requirements: >> >> REQMT-1b : This talks about two dimensions x,y. Given the recent >> discussions on capture area do we also need to a third dimension z? > AR- I don't think this has been settled yet. [CNG] Its in the current framework document. I guess if the framework is accepted as a WG document then it is settled? > >> REQMT-2 :Is it also appropriate to add capture area x,y,z > AR - Again, I don't think this has been settled. [CNG] As above. > >> General : Point of Capture? I couldn't see where this is in the >> requirements? > AR - I think point of capture wouldn't be in the requirements.. it is > part of the necessary mechanism for this proposed solution which enables > spatial arrangement, which is in the requirements. [CNG] I guess I don't have a good understanding of what should be in the requirements and what shouldn't be. For me point of capture doesn't come from the "spatial" arrangement requirement but from the need to support the "multiview" use case (at least according to the framework draft text). I.e. multiple cameras pointed at the same capture area. I didn't find a clear requirement in the requirements document linking to the multiview use case in the use case document. > > Regards, > Allyn > > >> Regards, Christian >> >> On 7/10/2011 9:42 AM, Allyn Romanow (allyn) wrote: >>> Hi Folks, >>> >>> Are there issues that people would like to discuss about the >>> requirements doc at the interim meeting next week? >>> >>> Thanks, >>> >>> Allyn >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue From jonathan@vidyo.com Sun Oct 9 19:20:36 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718F021F8593 for ; Sun, 9 Oct 2011 19:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.206, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eur3DIhviRs0 for ; Sun, 9 Oct 2011 19:20:36 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id DD00221F8591 for ; Sun, 9 Oct 2011 19:20:35 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 98FBA8BE291; Sun, 9 Oct 2011 22:20:35 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 41B9F8BE2B0; Sun, 9 Oct 2011 22:20:35 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Sun, 9 Oct 2011 22:20:13 -0400 From: Jonathan Lennox To: "Allyn Romanow (allyn)" Date: Sun, 9 Oct 2011 22:20:33 -0400 Thread-Topic: [clue] interim meeting agenda for framework doc discussion Thread-Index: AcyG8y3L6lGdqI4PRkOVlc9A8mVCIg== Message-ID: <5DCFFFE1-A69B-4FA1-9F83-E5CCA9EE0092@vidyo.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42A75@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42A75@xmb-sjc-221.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5DCFFFE1A69B4FA19F83E5CCA9EE0092vidyocom_" MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] interim meeting agenda for framework doc discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 02:20:36 -0000 --_000_5DCFFFE1A69B4FA19F83E5CCA9EE0092vidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 7, 2011, at 2:46 AM, Allyn Romanow (allyn) wrote: What are additional issues people feel need to be agreed upon that stand i= n the way of the document becoming a WG draft? In order to make progress, t= he discussion will be kept to identified issues. New ones can be added duri= ng the meeting, of course. One issue which I think would be useful to discuss would be a clearer expla= nation of what the framework signaling looks like in a multi-point session,= specifically down from an MCU to a receiver. I think it's important that the protocol support, at least, a mode where th= ere's full "transparency" of all the participants in a conference -- so tha= t a receiver can say, for instance, "I want to see this scene, permanently"= , it can, and it has enough information to do so meaningfully. -- Jonathan Lennox jonathan@vidyo.com --_000_5DCFFFE1A69B4FA19F83E5CCA9EE0092vidyocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On Oct 7, 2011, at 2:46 AM, Allyn Romanow (allyn) wrote:

What  are addi= tional issues people feel need to be agreed upon that stand in the way of t= he document becoming a WG draft? In order to make progress, the discussion = will be kept to identified issues. New ones can be added during the meeting= , of course.

One issue = which I think would be useful to discuss would be a clearer explanation of = what the framework signaling looks like in a multi-point session, specifica= lly down from an MCU to a receiver.

I think it's i= mportant that the protocol support, at least, a mode where there's full "tr= ansparency" of all the participants in a conference -- so that a receiver c= an say, for instance, "I want to see this scene, permanently", it can, and = it has enough information to do so meaningfully. 

--
Jonathan Lennox
jonathan@vidyo.com

= --_000_5DCFFFE1A69B4FA19F83E5CCA9EE0092vidyocom_-- From allyn@cisco.com Sun Oct 9 20:30:28 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA1221F8593 for ; Sun, 9 Oct 2011 20:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYJsSJRaJmde for ; Sun, 9 Oct 2011 20:30:27 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9508021F8560 for ; Sun, 9 Oct 2011 20:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=6312; q=dns/txt; s=iport; t=1318217427; x=1319427027; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=f5MLQfjqN80GbUiJRLlgvsGXfPUT8b5gPcyGdYQ3n1A=; b=DcQnyVomfyZa7jWXSFgqlhTLyyWgrNM3wb+Ai2G1peeVOobG9aAV+YVQ 1fbFBF17QWpfINURiOo3GslWKsAKHVoecwkHJebDx7jDMUzVRUOMxdPGL xZFFFaZ+xQSNL9SUDc0qvvXip5dkC3rj+VuXk5qvfswCk5lVxKqit1Qmp c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogAAFxmkk6rRDoG/2dsb2JhbABDmHCPK4EFgVMBAQEBAgEBAQEPAR0KNAsMBAIBCBEEAQEBCgYXAQYBJh8JCAEBBBMIEweHXAeYcgGdLwOGYmEEh32GWgKGE4Q9jEA X-IronPort-AV: E=Sophos;i="4.68,515,1312156800"; d="scan'208";a="6867117" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 10 Oct 2011 03:30:27 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9A3URtb019449; Mon, 10 Oct 2011 03:30:27 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 9 Oct 2011 20:30:27 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 9 Oct 2011 20:30:25 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42E72@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4E923F4C.5090902@nteczone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] interim meeting-- Requirements doc Thread-Index: AcyG5Wmb8xVcN5xlQTabGGX069aKQAAEE72g References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C85189@xmb-sjc-221.amer.cisco.com> <4E8E6B36.9000106@nteczone.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C8527D@xmb-sjc-221.amer.cisco.com> <4E923F4C.5090902@nteczone.com> From: "Allyn Romanow (allyn)" To: "Christian Groves" X-OriginalArrivalTime: 10 Oct 2011 03:30:27.0078 (UTC) FILETIME=[F4057260:01CC86FC] Cc: clue@ietf.org Subject: Re: [clue] interim meeting-- Requirements doc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 03:30:28 -0000 Hi Christian, Comments inline > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Sunday, October 09, 2011 5:42 PM > To: Allyn Romanow (allyn) > Cc: clue@ietf.org > Subject: Re: [clue] interim meeting-- Requirements doc >=20 > Hello Allyn, >=20 > Please see my response below. >=20 > Regards, Christian >=20 > On 7/10/2011 3:41 PM, Allyn Romanow (allyn) wrote: > > Hi Christian, > > Thanks for your comments- > > Here are my thoughts on them- > > Please see inline. > > > >> -----Original Message----- > >> From: Christian Groves [mailto:Christian.Groves@nteczone.com] > >> Sent: Thursday, October 06, 2011 8:00 PM > >> To: Allyn Romanow (allyn) > >> Cc: clue@ietf.org > >> Subject: Re: [clue] interim meeting-- Requirements doc > >> > >> Hello Allyn, > >> > >> Unfortunately I won't be at next weeks interim. I'd spend more time > in > >> the air than at the meeting :-(. > >> > >> I had two comments on the use cases draft that I didn't get a > response > >> to which relate to the requirements documents. > >> > >> 5) Section 3: [CNG] Will there be any attempt to link the > requirements > >> to certain uses cases?? For example: The RTCWEB requirements > document > >> indicates which requirements are derived from which use cases. > > AR- I don't feel it is necessary, although I know it is a style that > > some folks use. If the WG feels it is worthwhile, it can be done. > > We had done this in earlier versions as a tool, but removed it in the > > most recent draft. > > What would be the advantage or usefulness for adding doing it now? > [CNG] I think the advantage is traceability. As Mary mentioned it helps > new people figure out the link between requirements and use cases. It I > think would also provide us with a checklist to ensure that both the > use > cases and requirements align. AR- yes, Mary has asked for this, so it is settled to put it in the document. >=20 > > > >> 6) Section 3.x: [CNG] The framework draft sect 6.1 indicates that > > media > >> descriptions are dynamic. I.e. capabilities may change. There's > > nothing > >> explicit in the requirements to support this. Likewise there doesn't > >> appear to be a use case to support that. Do we need to add one for > >> that? > >> > > AR- Yes, I agree with you that there isn't a use case that describes > a > > receiver taking advantage of a change in encoding characteristics, or > > other attributes. I don't feel that there needs to a use case, but we > > could add one if people feel it is necessary. > > > > If you were to put in a requirement for this, it would not be to make > > capabilities dynamic, as that is tied to the particular solution > > mechanism we are proposing. It would be more along the lines that > > endpoints may change the characteristics of what they send.. which > > doesn't seem to me to be much of a requirement. > [CNG] Why isn't it much of a requirement? It does have eventual > non-neglible protocol and system impacts about described how data is > removed, replaced, flow are co-ordinated etc. Okay, I think the best thing would be if you draft the requirement that you would like, and then we could discuss that. thanks > > > >> Also a couple of additional comments on > >> draft-ietf-clue-telepresence-requirements: > >> > >> REQMT-1b : This talks about two dimensions x,y. Given the recent > >> discussions on capture area do we also need to a third dimension z? > > AR- I don't think this has been settled yet. > [CNG] Its in the current framework document. I guess if the framework > is > accepted as a WG document then it is settled? > > > >> REQMT-2 :Is it also appropriate to add capture area x,y,z > > AR - Again, I don't think this has been settled. > [CNG] As above. > > AR - yes you are quite right that a third dimension is in the draft, I overlooked that in responding to you.=20 If you wish to have a requirement that includes a third dimension, please draft one, and it can be discussed. > >> General : Point of Capture? I couldn't see where this is in the > >> requirements? > > AR - I think point of capture wouldn't be in the requirements.. it is > > part of the necessary mechanism for this proposed solution which > enables > > spatial arrangement, which is in the requirements. > [CNG] I guess I don't have a good understanding of what should be in > the > requirements and what shouldn't be. For me point of capture doesn't > come > from the "spatial" arrangement requirement but from the need to support > the "multiview" use case (at least according to the framework draft > text). I.e. multiple cameras pointed at the same capture area. I didn't > find a clear requirement in the requirements document linking to the > multiview use case in the use case document. > > AR - What should be in the requirements is general functionality that the protocol needs to accomplish, rather than the mechanisms to make that function happen. The requirements were re-written many times to get away from mechanisms toward functionality. There was a requirement for multi-view in the personal draft -03. If you want to add a requirement to support multi-view functionality, would you draft what you have in mind? In general, not all the functionality in the spec needs to be in the requirements, though any functions in the requirement do need to be in the spec. If there are functions in requirements that are not wanted in the spec, the requirements should be updated.=20 There is no problem with seeking to add to the requirements - if you would suggest the text you want to add it would be better because we could then discuss exactly what you would like to add. Thanks, Allyn > > Regards, > > Allyn > > > > > >> Regards, Christian > >> > >> On 7/10/2011 9:42 AM, Allyn Romanow (allyn) wrote: > >>> Hi Folks, > >>> > >>> Are there issues that people would like to discuss about the > >>> requirements doc at the interim meeting next week? > >>> > >>> Thanks, > >>> > >>> Allyn > >>> > >>> > >>> > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue From allyn@cisco.com Sun Oct 9 20:33:11 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5ADD21F8B09 for ; Sun, 9 Oct 2011 20:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mypMceBnMscb for ; Sun, 9 Oct 2011 20:33:11 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 099A221F8B0C for ; Sun, 9 Oct 2011 20:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=6635; q=dns/txt; s=iport; t=1318217591; x=1319427191; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=+6uHKM+k5yRURBBPmcmsaIKOPsGP6ioThL/kQC4ryTo=; b=QWOcrS6D5pqRXM08HKu0+uTjP4090oVL284bxLDyd9QrItOIt8YF7RU6 +mEaHrltxKX3E7pX9ZZrmKQoaoF69bYAESWiwStIAaDPYkt5AxbNo82j2 uuu2QND4VeVdDk4q0wTLwqh6TvcutuubHXx95pgyFe12b8a9FdDEAAcEI k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogAAFxmkk6rRDoG/2dsb2JhbABDgk2WI48rgQWBUwEBAQEDEgEJEQM4ERACAQgRBAEBCwYXAQYBRQkIAQEEEwgaoFUBnTKGYmEEh32Mb4Q9jEA X-IronPort-AV: E=Sophos;i="4.68,515,1312156800"; d="scan'208,217";a="6867442" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 10 Oct 2011 03:33:10 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9A3XATG020526; Mon, 10 Oct 2011 03:33:10 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 9 Oct 2011 20:33:10 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC86FD.554BCC7A" Date: Sun, 9 Oct 2011 20:33:09 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42E73@xmb-sjc-221.amer.cisco.com> In-Reply-To: <5DCFFFE1-A69B-4FA1-9F83-E5CCA9EE0092@vidyo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] interim meeting agenda for framework doc discussion Thread-Index: AcyG8y3L6lGdqI4PRkOVlc9A8mVCIgACiR1A References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42A75@xmb-sjc-221.amer.cisco.com> <5DCFFFE1-A69B-4FA1-9F83-E5CCA9EE0092@vidyo.com> From: "Allyn Romanow (allyn)" To: "Jonathan Lennox" X-OriginalArrivalTime: 10 Oct 2011 03:33:10.0480 (UTC) FILETIME=[556A9D00:01CC86FD] Cc: clue@ietf.org Subject: Re: [clue] interim meeting agenda for framework doc discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 03:33:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC86FD.554BCC7A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Sounds good. =20 From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 Sent: Sunday, October 09, 2011 7:21 PM To: Allyn Romanow (allyn) Cc: clue@ietf.org Subject: Re: [clue] interim meeting agenda for framework doc discussion =20 =20 On Oct 7, 2011, at 2:46 AM, Allyn Romanow (allyn) wrote: =20 What are additional issues people feel need to be agreed upon that stand in the way of the document becoming a WG draft? In order to make progress, the discussion will be kept to identified issues. New ones can be added during the meeting, of course. =20 One issue which I think would be useful to discuss would be a clearer explanation of what the framework signaling looks like in a multi-point session, specifically down from an MCU to a receiver. =20 I think it's important that the protocol support, at least, a mode where there's full "transparency" of all the participants in a conference -- so that a receiver can say, for instance, "I want to see this scene, permanently", it can, and it has enough information to do so meaningfully.=20 =20 -- Jonathan Lennox jonathan@vidyo.com =20 ------_=_NextPart_001_01CC86FD.554BCC7A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Sounds good.

 

From:= Jonathan = Lennox [mailto:jonathan@vidyo.com]
Sent: Sunday, October 09, 2011 7:21 PM
To: Allyn Romanow (allyn)
Cc: clue@ietf.org
Subject: Re: [clue] interim meeting agenda for framework doc = discussion

 

 

On Oct 7, 2011, at 2:46 AM, Allyn Romanow (allyn) = wrote:

&nbs= p;

What  are additional issues people feel need to be agreed upon that = stand in the way of the document becoming a WG draft? In order to make progress, = the discussion will be kept to identified issues. New ones can be added = during the meeting, of course.

 

One issue which I think would be useful to discuss = would be a clearer explanation of what the framework signaling looks like in a multi-point session, specifically down from an MCU to a = receiver.

 

I think it's important that the protocol support, = at least, a mode where there's full "transparency" of all the = participants in a conference -- so that a receiver can say, for instance, "I want to = see this scene, permanently", it can, and it has enough information to = do so meaningfully. 

 

--

Jonathan Lennox
jonathan@vidyo.com

 

------_=_NextPart_001_01CC86FD.554BCC7A-- From even.roni@huawei.com Mon Oct 10 08:42:56 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8623621F8BE7 for ; Mon, 10 Oct 2011 08:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.532 X-Spam-Level: X-Spam-Status: No, score=-98.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpJr6DQgWSiD for ; Mon, 10 Oct 2011 08:42:55 -0700 (PDT) Received: from p1222.supreclick.com (75-147-4-157-NewEngland.hfc.comcastbusiness.net [75.147.4.157]) by ietfa.amsl.com (Postfix) with ESMTP id 83E6921F8549 for ; Mon, 10 Oct 2011 08:42:55 -0700 (PDT) Received: from YOUR6108 ([10.1.200.196]) (authenticated bits=0) by p1222.supreclick.com (8.13.6/8.13.6) with ESMTP id p9AFh01L004778; Mon, 10 Oct 2011 11:43:00 -0400 From: "Roni Even" To: "'Jonathan Lennox'" , "'Allyn Romanow \(allyn\)'" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42A75@xmb-sjc-221.amer.cisco.com> <5DCFFFE1-A69B-4FA1-9F83-E5CCA9EE0092@vidyo.com> In-Reply-To: <5DCFFFE1-A69B-4FA1-9F83-E5CCA9EE0092@vidyo.com> Date: Mon, 10 Oct 2011 17:42:50 +0200 Message-ID: <000301cc8763$46559e30$d300da90$@roni@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01CC8774.09DE6E30" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcyG8y3L6lGdqI4PRkOVlc9A8mVCIgAb+ysQ Content-Language: he Cc: clue@ietf.org Subject: Re: [clue] interim meeting agenda for framework doc discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 15:42:56 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01CC8774.09DE6E30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jonathan, I fully agree that the current section on MCU is very basic and need more information. I have included some issue in my presentation Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Jonathan Lennox Sent: Monday, October 10, 2011 4:21 AM To: Allyn Romanow (allyn) Cc: clue@ietf.org Subject: Re: [clue] interim meeting agenda for framework doc discussion On Oct 7, 2011, at 2:46 AM, Allyn Romanow (allyn) wrote: What are additional issues people feel need to be agreed upon that stand in the way of the document becoming a WG draft? In order to make progress, the discussion will be kept to identified issues. New ones can be added during the meeting, of course. One issue which I think would be useful to discuss would be a clearer explanation of what the framework signaling looks like in a multi-point session, specifically down from an MCU to a receiver. I think it's important that the protocol support, at least, a mode where there's full "transparency" of all the participants in a conference -- so that a receiver can say, for instance, "I want to see this scene, permanently", it can, and it has enough information to do so meaningfully. -- Jonathan Lennox jonathan@vidyo.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 6528 (20111009) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 6528 (20111009) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ------=_NextPart_000_0004_01CC8774.09DE6E30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jonathan,

I fully agree that the current section on MCU is very basic and need = more information. I have included some issue in my = presentation

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Jonathan Lennox
Sent: Monday, October 10, 2011 4:21 = AM
To: Allyn Romanow (allyn)
Cc: = clue@ietf.org
Subject: Re: [clue] interim meeting agenda for = framework doc discussion

 

 

On = Oct 7, 2011, at 2:46 AM, Allyn Romanow (allyn) = wrote:

&nbs= p;

What =  are additional issues people feel need to be agreed upon that = stand in the way of the document becoming a WG draft? In order to make = progress, the discussion will be kept to identified issues. New ones can = be added during the meeting, of = course.

 

One issue which I think would be useful to discuss = would be a clearer explanation of what the framework signaling looks = like in a multi-point session, specifically down from an MCU to a = receiver.

 

I = think it's important that the protocol support, at least, a mode where = there's full "transparency" of all the participants in a = conference -- so that a receiver can say, for instance, "I want to = see this scene, permanently", it can, and it has enough information = to do so meaningfully. 

 

--

Jonathan Lennox
jonathan@vidyo.com




__________ = Information from ESET NOD32 Antivirus, version of virus signature = database 6528 (20111009) __________

The message was checked by = ESET NOD32 Antivirus.

http://www.eset.com


_________= _ Information from ESET NOD32 Antivirus, version of virus signature = database 6528 (20111009) __________

The message was checked by = ESET NOD32 Antivirus.

http://www.eset.com

=


__________ Information from ESET NOD32 Antivirus, version = of virus signature database 6528 (20111009) __________

The = message was checked by ESET NOD32 Antivirus.

http://www.eset.com
------=_NextPart_000_0004_01CC8774.09DE6E30-- From stephane.cazeaux@orange.com Mon Oct 10 10:46:26 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFD621F8C0C for ; Mon, 10 Oct 2011 10:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBVGYuiIM13s for ; Mon, 10 Oct 2011 10:46:25 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id AC26321F8BFE for ; Mon, 10 Oct 2011 10:46:24 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EA37B8B807A for ; Mon, 10 Oct 2011 19:47:45 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id DD4DC8B8067 for ; Mon, 10 Oct 2011 19:47:45 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr ([10.194.32.11]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 19:29:49 +0200 Received: from FTRDMB03.rd.francetelecom.fr ([fe80::4c06:6ece:ed2d:797e]) by FTRDCH01.rd.francetelecom.fr ([::1]) with mapi id 14.01.0270.001; Mon, 10 Oct 2011 19:29:48 +0200 From: To: Thread-Topic: [clue] the presentation use case Thread-Index: AcxHlL8VW+C7KhbYQU2HJX/U8MKZpAFFKK/A///k6YCAAFO3gIAACg4AgAAqsQCAAFTQgP/uhI7ggCNGD4D/+k3aoIALuqeA/6gpJ1D/T+EmUP6bGiVA Date: Mon, 10 Oct 2011 17:29:48 +0000 Message-ID: References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com><4E309135.7070408@alum.mit.edu><001b01cc4cd6$77d28760$67779620$%roni@huawei.com> <4E30DFDE.3040601@alum.mit.edu> <9ECCF01B52E7AB408A7EB85352642141031F2E5E@ftrdmel0.rd.francetelecom.fr> <4E314AD3.1030406@alum.mit.edu> <4E403783.70706@alum.mit.edu> <4E454723.4080501@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A61CE060BFF@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61CE060BFF@CRPMBOXPRD01.polycom.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.193.118] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Oct 2011 17:29:49.0801 (UTC) FILETIME=[368B1D90:01CC8772] Subject: Re: [clue] the presentation use case X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 17:46:26 -0000 Hi, Thus I still think that the use case, as currently described, is too restri= ctive. One could think that only the video based presentation is considered= within the use cases, while we probably all agree that CLUE is more generi= c. Could it be appropriate to indicate explicitly in the use case that othe= r solutions for document sharing could also be considered in the future? St=E9phane. -----Message d'origine----- De=A0: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de D= uckworth, Mark Envoy=E9=A0: vendredi 7 octobre 2011 19:51 =C0=A0: clue@ietf.org Objet=A0: Re: [clue] the presentation use case Hi St=E9phane, The CLUE framework is intended to handle any media type that is carried ove= r RTP. The framework document should be relating to "media captures" and "= media streams" in general, except when there is a need to be more specific = about video or audio or any other media type. There are probably some plac= es in the document where it would be better to be more general, to make sur= e it applies to any media type where appropriate. So if you want to send excel sheet data over RTP, then CLUE should be able = to handle it regarding associating it with audio or giving it some spatial = relationship to other media streams, for example. I think this is as far as CLUE should go with regard to document sharing. = I think additional use cases about document sharing are not relevant to CLU= E. My thinking is based on this statement from the CLUE charter: "The focus of this work is on multiple RTP audio and video streams. Other = media types may be considered, however development of methodologies for the= m is not within the scope of this work." Regards, Mark Duckworth > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of stephane.cazeaux@orange.com > Sent: Friday, October 07, 2011 7:25 AM > To: clue@ietf.org > Subject: [clue] the presentation use case >=20 > Hi >=20 > I will not be able to attend physically to the interim meeting. >=20 > However I had a comment on the presentation use case, which I still=20 > consider we need to agree on. > In the use case draft, the presentation use case is restricted to the=20 > video based solution. To me, it should be modified so that: > - It does not restrict the solution to the video > - It includes the need to share any kind of documents (including=20 > complex documents such as excel sheets) and the ability to have remote=20 > control >=20 > See below the discussion. >=20 > Regards, > St=E9phane. >=20 >=20 >=20 > -----Message d'origine----- > De=A0: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Envoy=E9=A0: vendredi = 12=20 > ao=FBt 2011 17:31 =C0=A0: CAZEAUX Stephane RD-BIZZ-CAE Cc=A0: clue@ietf.o= rg=20 > Objet=A0: Re: [clue] Comment on the presentation use case >=20 > On 8/12/11 4:48 AM, stephane.cazeaux@orange-ftgroup.com wrote: > > Hi Paul, > > > > I understand your suggestion, and I am aware that it could be a > solution. It certainly makes sense, but I am not sure of how it could=20 > be integrated in CLUE. To me, this is a matter of application=20 > integration, at application level. > > > > My suggestion is that we should think of a solution that provides > more satisfying collaboration within telepresence, with the same level=20 > of interoperability and multistream interaction as presentation video=20 > stream provides, but with more satisfying quality (video is not=20 > suitable for all kinds of shared documents) and more collaborative=20 > features. > > I don't think that the kind of relationship that you suggest is the > only solution. >=20 > IMO the main thing is to not constrain the mechanism used for=20 > collaboration/web sharing. That stuff is evolving at "web speed". > Anything you nail down that is constraining will be obsolete before it=20 > gets out. >=20 > (I've been looking more at RTCWEB recently, and I'm wondering if=20 > perhaps CLUE ought to be based on that.) >=20 > Thanks, > Paul (as individual) >=20 > > Stephane. > > > > > > -----Message d'origine----- > > De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Envoy=E9 : lundi 8=20 > > ao=FBt 2011 21:23 =C0 : CAZEAUX Stephane RD-BIZZ-CAE Cc : clue@ietf.org= =20 > > Objet : Re: [clue] Comment on the presentation use case > > > > On 8/8/11 11:56 AM, stephane.cazeaux@orange-ftgroup.com wrote: > >> Hi, > >> > >> To me, it should be part of the telepresence protocols at least to > enable the interoperability, as the presentation based on video stream=20 > allows it. > >> > >> The point is that video stream is not convenient for the use cases=20 > >> I > suggested. But it does not necessarily mean that we should bundle a=20 > full data sharing protocol with telepresence. Something simpler, like=20 > the RFB option of draft-garcia-mmusic-sdp-collaboration, could be a=20 > candidate. > > > > What I was suggesting is that maybe it would make sense to turn=20 > > those relationships "inside out". > > > > For instance when I use a collaboration tool like Webex, the=20 > > collaboration is set up first via the web, and defines the set of=20 > > participants. Then a voice session can be added. For pragmatic > reasons, > > the voice conferencing seems to be pretty distinct. (I'm not certain > how > > webex handles video. I suspect it is doing it via the web, not the=20 > > telephony conference.) > > > > Its not hard to imagine the same sort of setup, but with a=20 > > multiparty telepresence session instead of the traditional voice=20 > > conference. In such a case, you would probably want the=20 > > collaboration tool (webex, > or > > whatever) to mediate the UI for the web collaboration, the roster, > etc. > > It might delegate a lot of that to the telepresence infrastructure. > > > > But that does raise some questions about how all the components fit=20 > > together. Is there a single screen for the collaboration session in=20 > > a telepresence room? What about input to that - keyboard, mouse, etc.? > Or > > do we assume that each person in the room has their own computer=20 > > with input, display, etc. and maybe a way to slave the web=20 > > collaboration session to one or more of the big displays in the room? > > > > What probably *can't* be done right now is nail down a particular=20 > > web collaboration service (e.g. Webex) or protocol. That does=20 > > complicate slaving the collaboration session to a screen, unless its=20 > > done by > having > > someone connect a video connection to their own computer. > > > > Thanks, > > Paul > > > >> Stephane. > >> > >> > >> -----Message d'origine----- > >> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la=20 > >> part > de Paul Kyzivat > >> Envoy=E9 : jeudi 28 juillet 2011 13:41 =C0 : CHATRAS Bruno RD-CORE-ISS= =20 > >> Cc : clue@ietf.org Objet : Re: [clue] Comment on the presentation=20 > >> use case > >> > >> On 7/28/11 2:37 AM, bruno.chatras@orange-ftgroup.com wrote: > >>> I think we should take a look to > >>> http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration-0 > >>> 0 > >> > >> Maybe. But that is almost orthogonal to what I was suggesting. > >> > >> THanks, > >> Paul > >> (as individual) > >> > >>> Bruno > >>> > >>>> -----Message d'origine----- > >>>> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la > part de > >>>> Paul Kyzivat > >>>> Envoy=E9 : jeudi 28 juillet 2011 06:05 =C0 : Roni Even Cc :=20 > >>>> clue@ietf.org Objet : Re: [clue] Comment on the presentation use=20 > >>>> case > >>>> > >>>> On 7/27/11 11:28 PM, Roni Even wrote: > >>>>> Hi, > >>>>> HTTP is not defining a common data sharing protocol. WebEx may=20 > >>>>> be > >>>> carried > >>>>> over HTTP but the data sharing application is not standard. What > I > >>>> meant is > >>>>> that it can either be something that is a common data sharing > >>>> protocol or > >>>>> something that is carried as an RTP payload which require some > common > >>>>> defined protocol on top. > >>>> > >>>> I was being a bit tongue in cheek, though not entirely. > >>>> Of course you are right - that if you want to push data to > everybody > >>>> you > >>>> need more. > >>>> > >>>> But data sharing by pointing a video camera at a piece of paper=20 > >>>> is > a > >>>> tad > >>>> out of date. Connecting the video port on a user's computer as a > video > >>>> source and distributing it with the other video is better than > that. > >>>> But > >>>> its not nearly as convenient as webex or any of its competitors. > >>>> > >>>> It isn't entirely clear that its *necessary* to bundle the data > sharing > >>>> application with the telepresence protocols. Its kind of limiting > since > >>>> the web apps evolve very rapidly. Perhaps we should be doing the=20 > >>>> opposite of that: providing a way to embed the control of the=20 > >>>> telepresence system into a web app. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>>> -----Original Message----- > >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > >>>> Of > >>>>>> Paul Kyzivat > >>>>>> Sent: Thursday, July 28, 2011 1:29 AM > >>>>>> To: clue@ietf.org > >>>>>> Subject: Re: [clue] Comment on the presentation use case > >>>>>> > >>>>>> On 7/27/11 6:07 PM, Roni Even wrote: > >>>>>>> Hi Stephane, > >>>>>>> > >>>>>>> Is there a standard protocol that is used for conveying this=20 > >>>>>>> information, is it RTP based. > >>>>>> > >>>>>> AFAIK this is often http. (E.g. webex) > >>>>>> > >>>>>>> To me this is a separate application that can be integrated in > the > >>>>>>> application level and not as part of the multistream. > >>>>>> > >>>>>> I guess this depends on whether the support for it is=20 > >>>>>> integrated > >>>> into > >>>>>> the "room", or is just incidental equipment brought by the > users, > >>>> not > >>>>>> formally related to the telepresence session. > >>>>>> > >>>>>> Thanks, > >>>>>> Paul > >>>>>> (speaking as an individual) > >>>>>> > >>>>>>> Roni > >>>>>>> > >>>>>>> *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > Behalf Of > >>>>>>> *stephane.cazeaux@orange-ftgroup.com > >>>>>>> *Sent:* Thursday, July 21, 2011 2:33 PM > >>>>>>> *To:* clue@ietf.org > >>>>>>> *Subject:* [clue] Comment on the presentation use case* > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> *Hi,* > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> *The presentation use case as described in the use-cases > document > >>>> is > >>>>>>> based on the assumption that the presentation stream relies on > a > >>>>>> video > >>>>>>> stream, and is limited to usage of presentation video streams. > But > >>>> we > >>>>>>> could also consider collaborative use cases, meaningful for=20 > >>>>>>> telepresence, which are not covered by the existing text.* > >>>>>>> > >>>>>>> *I propose to complete the existing text as follows:* > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> *Furthermore, although most today's systems use video streams > for > >>>>>>> presentations, there are use cases where this is not suitable. > For > >>>>>> example:* > >>>>>>> > >>>>>>> *- The professor which shares an electronic whiteboard (could > be a > >>>>>>> whiteboard application on a PC, with screen capture of the PC) > >>>> where > >>>>>> all > >>>>>>> students can participate. Students will take control of the > shared > >>>>>>> whiteboard in turns.* > >>>>>>> > >>>>>>> *- In a multipoint meeting, a shared document can be kept > always > >>>>>> visible > >>>>>>> in a screen, while other documents are presented on other > screens > >>>>>> (with > >>>>>>> possible in turns presentation). For instance, for the purpose > of > >>>>>> shared > >>>>>>> design document, notes taking, polls, etc. A shared document > >>>> implies > >>>>>>> that all participants can modify it in turns.* > >>>>>>> > >>>>>>> *"* > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> *St ephane. v> > >>>>>>> * > >>>>>>> > >>>>>>> * > >>>>>>> * > >>>>>>> > >>>>>>> *_______________________________________________ > >>>>>>> clue mailing list > >>>>>>> clue@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>>>> * > >>>>>> > >>>>>> _______________________________________________ > >>>>>> clue mailing list > >>>>>> clue@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From allyn@cisco.com Mon Oct 10 11:33:43 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A82F21F8C40 for ; Mon, 10 Oct 2011 11:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zekiLpzvk+Ga for ; Mon, 10 Oct 2011 11:33:42 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0686C21F8C3C for ; Mon, 10 Oct 2011 11:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=14619; q=dns/txt; s=iport; t=1318271622; x=1319481222; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=3Jy7XWhytyqTUxKVPQYP4qtTET/4dT1axeRvMdtPwGY=; b=P3TGy5bLu/QG9GobscmCoE4t7gyLaBx/Nm0FFEXVSiHdw0+aRSgmm3Zd spcz4y2rGjDDPKlhRkPicnUipF71+wPaD9lQWwHiqmbTKnjOCQ4ee24oi IZfyq1efO/IR4mEskUKqV11sj+cDcUifeZCsPUF8XOqAkaRUG8QfesF4Y 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIAABk6k06rRDoJ/2dsb2JhbABDmHePKYEFgVMBAQEBAwEBAQ8BHTcBBgQTBAIBCBEEAQEBCgYXAQYBJh8JCAIEARIIEweHY5o2AZ4rhmJhBIdNMIZaAQGGE4Q9jEA X-IronPort-AV: E=Sophos;i="4.68,518,1312156800"; d="scan'208";a="7024464" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 10 Oct 2011 18:33:41 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9AIXe5h024174; Mon, 10 Oct 2011 18:33:41 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 11:33:41 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Oct 2011 11:33:36 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D43087@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] the presentation use case Thread-Index: AcxHlL8VW+C7KhbYQU2HJX/U8MKZpAFFKK/A///k6YCAAFO3gIAACg4AgAAqsQCAAFTQgP/uhI7ggCNGD4D/+k3aoIALuqeA/6gpJ1D/T+EmUP6bGiVA/TYXO6A= References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com><4E309135.7070408@alum.mit.edu><001b01cc4cd6$77d28760$67779620$%roni@huawei.com><4E30DFDE.3040601@alum.mit.edu><9ECCF01B52E7AB408A7EB85352642141031F2E5E@ftrdmel0.rd.francetelecom.fr><4E314AD3.1030406@alum.mit.edu><4E403783.70706@alum.mit.edu><4E454723.4080501@alum.mit.edu><44C6B6B2D0CF424AA90B6055548D7A61CE060BFF@CRPMBOXPRD01.polycom.com> From: "Allyn Romanow (allyn)" To: , X-OriginalArrivalTime: 10 Oct 2011 18:33:41.0334 (UTC) FILETIME=[2250A760:01CC877B] Subject: Re: [clue] the presentation use case X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 18:33:43 -0000 Hi Stephane,=20 Could you supply the text that you would like to have added? It would = good to be very specific, rather than general, since that what the use = cases are - the specific scenarios of interest to you. Since xcel (over RTP) was your example, and as Mark said, it is = currently covered, I'm not sure exactly what case you have in mind that = is either not already covered or in scope for the current charter. Thanks, Allyn > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > stephane.cazeaux@orange.com > Sent: Monday, October 10, 2011 10:30 AM > To: clue@ietf.org > Subject: Re: [clue] the presentation use case >=20 > Hi, >=20 > Thus I still think that the use case, as currently described, is too > restrictive. One could think that only the video based presentation is > considered within the use cases, while we probably all agree that CLUE > is more generic. Could it be appropriate to indicate explicitly in the > use case that other solutions for document sharing could also be > considered in the future? >=20 > St=E9phane. >=20 > -----Message d'origine----- > De=A0: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part = de > Duckworth, Mark > Envoy=E9=A0: vendredi 7 octobre 2011 19:51 > =C0=A0: clue@ietf.org > Objet=A0: Re: [clue] the presentation use case >=20 > Hi St=E9phane, >=20 > The CLUE framework is intended to handle any media type that is = carried > over RTP. The framework document should be relating to "media > captures" and "media streams" in general, except when there is a need > to be more specific about video or audio or any other media type. > There are probably some places in the document where it would be = better > to be more general, to make sure it applies to any media type where > appropriate. >=20 > So if you want to send excel sheet data over RTP, then CLUE should be > able to handle it regarding associating it with audio or giving it = some > spatial relationship to other media streams, for example. >=20 > I think this is as far as CLUE should go with regard to document > sharing. I think additional use cases about document sharing are not > relevant to CLUE. My thinking is based on this statement from the = CLUE > charter: >=20 > "The focus of this work is on multiple RTP audio and video streams. > Other media types may be considered, however development of > methodologies for them is not within the scope of this work." >=20 > Regards, > Mark Duckworth >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of stephane.cazeaux@orange.com > > Sent: Friday, October 07, 2011 7:25 AM > > To: clue@ietf.org > > Subject: [clue] the presentation use case > > > > Hi > > > > I will not be able to attend physically to the interim meeting. > > > > However I had a comment on the presentation use case, which I still > > consider we need to agree on. > > In the use case draft, the presentation use case is restricted to = the > > video based solution. To me, it should be modified so that: > > - It does not restrict the solution to the video > > - It includes the need to share any kind of documents (including > > complex documents such as excel sheets) and the ability to have > remote > > control > > > > See below the discussion. > > > > Regards, > > St=E9phane. > > > > > > > > -----Message d'origine----- > > De=A0: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Envoy=E9=A0: = vendredi 12 > > ao=FBt 2011 17:31 =C0=A0: CAZEAUX Stephane RD-BIZZ-CAE Cc=A0: = clue@ietf.org > > Objet=A0: Re: [clue] Comment on the presentation use case > > > > On 8/12/11 4:48 AM, stephane.cazeaux@orange-ftgroup.com wrote: > > > Hi Paul, > > > > > > I understand your suggestion, and I am aware that it could be a > > solution. It certainly makes sense, but I am not sure of how it = could > > be integrated in CLUE. To me, this is a matter of application > > integration, at application level. > > > > > > My suggestion is that we should think of a solution that provides > > more satisfying collaboration within telepresence, with the same > level > > of interoperability and multistream interaction as presentation = video > > stream provides, but with more satisfying quality (video is not > > suitable for all kinds of shared documents) and more collaborative > > features. > > > I don't think that the kind of relationship that you suggest is = the > > only solution. > > > > IMO the main thing is to not constrain the mechanism used for > > collaboration/web sharing. That stuff is evolving at "web speed". > > Anything you nail down that is constraining will be obsolete before > it > > gets out. > > > > (I've been looking more at RTCWEB recently, and I'm wondering if > > perhaps CLUE ought to be based on that.) > > > > Thanks, > > Paul (as individual) > > > > > Stephane. > > > > > > > > > -----Message d'origine----- > > > De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Envoy=E9 : lundi = 8 > > > ao=FBt 2011 21:23 =C0 : CAZEAUX Stephane RD-BIZZ-CAE Cc : = clue@ietf.org > > > Objet : Re: [clue] Comment on the presentation use case > > > > > > On 8/8/11 11:56 AM, stephane.cazeaux@orange-ftgroup.com wrote: > > >> Hi, > > >> > > >> To me, it should be part of the telepresence protocols at least = to > > enable the interoperability, as the presentation based on video > stream > > allows it. > > >> > > >> The point is that video stream is not convenient for the use = cases > > >> I > > suggested. But it does not necessarily mean that we should bundle a > > full data sharing protocol with telepresence. Something simpler, = like > > the RFB option of draft-garcia-mmusic-sdp-collaboration, could be a > > candidate. > > > > > > What I was suggesting is that maybe it would make sense to turn > > > those relationships "inside out". > > > > > > For instance when I use a collaboration tool like Webex, the > > > collaboration is set up first via the web, and defines the set of > > > participants. Then a voice session can be added. For pragmatic > > reasons, > > > the voice conferencing seems to be pretty distinct. (I'm not > certain > > how > > > webex handles video. I suspect it is doing it via the web, not the > > > telephony conference.) > > > > > > Its not hard to imagine the same sort of setup, but with a > > > multiparty telepresence session instead of the traditional voice > > > conference. In such a case, you would probably want the > > > collaboration tool (webex, > > or > > > whatever) to mediate the UI for the web collaboration, the roster, > > etc. > > > It might delegate a lot of that to the telepresence = infrastructure. > > > > > > But that does raise some questions about how all the components = fit > > > together. Is there a single screen for the collaboration session = in > > > a telepresence room? What about input to that - keyboard, mouse, > etc.? > > Or > > > do we assume that each person in the room has their own computer > > > with input, display, etc. and maybe a way to slave the web > > > collaboration session to one or more of the big displays in the > room? > > > > > > What probably *can't* be done right now is nail down a particular > > > web collaboration service (e.g. Webex) or protocol. That does > > > complicate slaving the collaboration session to a screen, unless > its > > > done by > > having > > > someone connect a video connection to their own computer. > > > > > > Thanks, > > > Paul > > > > > >> Stephane. > > >> > > >> > > >> -----Message d'origine----- > > >> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la > > >> part > > de Paul Kyzivat > > >> Envoy=E9 : jeudi 28 juillet 2011 13:41 =C0 : CHATRAS Bruno = RD-CORE-ISS > > >> Cc : clue@ietf.org Objet : Re: [clue] Comment on the presentation > > >> use case > > >> > > >> On 7/28/11 2:37 AM, bruno.chatras@orange-ftgroup.com wrote: > > >>> I think we should take a look to > > >>> = http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration- > 0 > > >>> 0 > > >> > > >> Maybe. But that is almost orthogonal to what I was suggesting. > > >> > > >> THanks, > > >> Paul > > >> (as individual) > > >> > > >>> Bruno > > >>> > > >>>> -----Message d'origine----- > > >>>> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la > > part de > > >>>> Paul Kyzivat > > >>>> Envoy=E9 : jeudi 28 juillet 2011 06:05 =C0 : Roni Even Cc : > > >>>> clue@ietf.org Objet : Re: [clue] Comment on the presentation = use > > >>>> case > > >>>> > > >>>> On 7/27/11 11:28 PM, Roni Even wrote: > > >>>>> Hi, > > >>>>> HTTP is not defining a common data sharing protocol. WebEx may > > >>>>> be > > >>>> carried > > >>>>> over HTTP but the data sharing application is not standard. > What > > I > > >>>> meant is > > >>>>> that it can either be something that is a common data sharing > > >>>> protocol or > > >>>>> something that is carried as an RTP payload which require some > > common > > >>>>> defined protocol on top. > > >>>> > > >>>> I was being a bit tongue in cheek, though not entirely. > > >>>> Of course you are right - that if you want to push data to > > everybody > > >>>> you > > >>>> need more. > > >>>> > > >>>> But data sharing by pointing a video camera at a piece of paper > > >>>> is > > a > > >>>> tad > > >>>> out of date. Connecting the video port on a user's computer as = a > > video > > >>>> source and distributing it with the other video is better than > > that. > > >>>> But > > >>>> its not nearly as convenient as webex or any of its = competitors. > > >>>> > > >>>> It isn't entirely clear that its *necessary* to bundle the data > > sharing > > >>>> application with the telepresence protocols. Its kind of > limiting > > since > > >>>> the web apps evolve very rapidly. Perhaps we should be doing = the > > >>>> opposite of that: providing a way to embed the control of the > > >>>> telepresence system into a web app. > > >>>> > > >>>> Thanks, > > >>>> Paul > > >>>> > > >>>>>> -----Original Message----- > > >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf > > >>>> Of > > >>>>>> Paul Kyzivat > > >>>>>> Sent: Thursday, July 28, 2011 1:29 AM > > >>>>>> To: clue@ietf.org > > >>>>>> Subject: Re: [clue] Comment on the presentation use case > > >>>>>> > > >>>>>> On 7/27/11 6:07 PM, Roni Even wrote: > > >>>>>>> Hi Stephane, > > >>>>>>> > > >>>>>>> Is there a standard protocol that is used for conveying this > > >>>>>>> information, is it RTP based. > > >>>>>> > > >>>>>> AFAIK this is often http. (E.g. webex) > > >>>>>> > > >>>>>>> To me this is a separate application that can be integrated > in > > the > > >>>>>>> application level and not as part of the multistream. > > >>>>>> > > >>>>>> I guess this depends on whether the support for it is > > >>>>>> integrated > > >>>> into > > >>>>>> the "room", or is just incidental equipment brought by the > > users, > > >>>> not > > >>>>>> formally related to the telepresence session. > > >>>>>> > > >>>>>> Thanks, > > >>>>>> Paul > > >>>>>> (speaking as an individual) > > >>>>>> > > >>>>>>> Roni > > >>>>>>> > > >>>>>>> *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > > Behalf Of > > >>>>>>> *stephane.cazeaux@orange-ftgroup.com > > >>>>>>> *Sent:* Thursday, July 21, 2011 2:33 PM > > >>>>>>> *To:* clue@ietf.org > > >>>>>>> *Subject:* [clue] Comment on the presentation use case* > > >>>>>>> > > >>>>>>> ** > > >>>>>>> > > >>>>>>> *Hi,* > > >>>>>>> > > >>>>>>> ** > > >>>>>>> > > >>>>>>> *The presentation use case as described in the use-cases > > document > > >>>> is > > >>>>>>> based on the assumption that the presentation stream relies > on > > a > > >>>>>> video > > >>>>>>> stream, and is limited to usage of presentation video > streams. > > But > > >>>> we > > >>>>>>> could also consider collaborative use cases, meaningful for > > >>>>>>> telepresence, which are not covered by the existing text.* > > >>>>>>> > > >>>>>>> *I propose to complete the existing text as follows:* > > >>>>>>> > > >>>>>>> ** > > >>>>>>> > > >>>>>>> *Furthermore, although most today's systems use video = streams > > for > > >>>>>>> presentations, there are use cases where this is not > suitable. > > For > > >>>>>> example:* > > >>>>>>> > > >>>>>>> *- The professor which shares an electronic whiteboard = (could > > be a > > >>>>>>> whiteboard application on a PC, with screen capture of the > PC) > > >>>> where > > >>>>>> all > > >>>>>>> students can participate. Students will take control of the > > shared > > >>>>>>> whiteboard in turns.* > > >>>>>>> > > >>>>>>> *- In a multipoint meeting, a shared document can be kept > > always > > >>>>>> visible > > >>>>>>> in a screen, while other documents are presented on other > > screens > > >>>>>> (with > > >>>>>>> possible in turns presentation). For instance, for the > purpose > > of > > >>>>>> shared > > >>>>>>> design document, notes taking, polls, etc. A shared document > > >>>> implies > > >>>>>>> that all participants can modify it in turns.* > > >>>>>>> > > >>>>>>> *"* > > >>>>>>> > > >>>>>>> ** > > >>>>>>> > > >>>>>>> ** > > >>>>>>> > > >>>>>>> *St ephane. v> > > >>>>>>> * > > >>>>>>> > > >>>>>>> * > > >>>>>>> * > > >>>>>>> > > >>>>>>> *_______________________________________________ > > >>>>>>> clue mailing list > > >>>>>>> clue@ietf.org > > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > > >>>>>>> * > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> clue mailing list > > >>>>>> clue@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/clue > > >>>>> > > >>>>> > > >>>> > > >>>> _______________________________________________ > > >>>> clue mailing list > > >>>> clue@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/clue > > >>> > > >> > > >> _______________________________________________ > > >> clue mailing list > > >> clue@ietf.org > > >> https://www.ietf.org/mailman/listinfo/clue > > >> > > > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From stephane.cazeaux@orange.com Mon Oct 10 12:26:31 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00E621F8C9D for ; Mon, 10 Oct 2011 12:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1LF9-Yqym9n for ; Mon, 10 Oct 2011 12:26:30 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0F44721F8B8A for ; Mon, 10 Oct 2011 12:26:30 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B155714004B; Mon, 10 Oct 2011 19:07:53 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 7FF39140357; Mon, 10 Oct 2011 18:53:30 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr ([10.194.32.11]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 18:53:28 +0200 Received: from FTRDMB03.rd.francetelecom.fr ([fe80::4c06:6ece:ed2d:797e]) by FTRDCH01.rd.francetelecom.fr ([::1]) with mapi id 14.01.0270.001; Mon, 10 Oct 2011 18:53:27 +0200 From: To: , Thread-Topic: [clue] the presentation use case Thread-Index: AcxHlL8VW+C7KhbYQU2HJX/U8MKZpAFFKK/A///k6YCAAFO3gIAACg4AgAAqsQCAAFTQgP/uhI7ggCNGD4D/+k3aoIALuqeA/6gpJ1D/T+EmUP6bGiVA Date: Mon, 10 Oct 2011 16:53:26 +0000 Message-ID: References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com><4E309135.7070408@alum.mit.edu><001b01cc4cd6$77d28760$67779620$%roni@huawei.com> <4E30DFDE.3040601@alum.mit.edu> <9ECCF01B52E7AB408A7EB85352642141031F2E5E@ftrdmel0.rd.francetelecom.fr> <4E314AD3.1030406@alum.mit.edu> <4E403783.70706@alum.mit.edu> <4E454723.4080501@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A61CE060BFF@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61CE060BFF@CRPMBOXPRD01.polycom.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.193.118] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Oct 2011 16:53:28.0751 (UTC) FILETIME=[22894BF0:01CC876D] Subject: Re: [clue] the presentation use case X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 19:26:31 -0000 Hi, Thus I still think that the use case, as currently described, is too restri= ctive. One could think that only the video based presentation is considered= within the use cases, while we probably all agree that CLUE is more generi= c. Could it be appropriate to indicate explicitly in the use case that othe= r solutions for document sharing could also be considered in the future? St=E9phane. -----Message d'origine----- De=A0: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de D= uckworth, Mark Envoy=E9=A0: vendredi 7 octobre 2011 19:51 =C0=A0: clue@ietf.org Objet=A0: Re: [clue] the presentation use case Hi St=E9phane, The CLUE framework is intended to handle any media type that is carried ove= r RTP. The framework document should be relating to "media captures" and "= media streams" in general, except when there is a need to be more specific = about video or audio or any other media type. There are probably some plac= es in the document where it would be better to be more general, to make sur= e it applies to any media type where appropriate. So if you want to send excel sheet data over RTP, then CLUE should be able = to handle it regarding associating it with audio or giving it some spatial = relationship to other media streams, for example. I think this is as far as CLUE should go with regard to document sharing. = I think additional use cases about document sharing are not relevant to CLU= E. My thinking is based on this statement from the CLUE charter: "The focus of this work is on multiple RTP audio and video streams. Other = media types may be considered, however development of methodologies for the= m is not within the scope of this work." Regards, Mark Duckworth > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of stephane.cazeaux@orange.com > Sent: Friday, October 07, 2011 7:25 AM > To: clue@ietf.org > Subject: [clue] the presentation use case >=20 > Hi >=20 > I will not be able to attend physically to the interim meeting. >=20 > However I had a comment on the presentation use case, which I still=20 > consider we need to agree on. > In the use case draft, the presentation use case is restricted to the=20 > video based solution. To me, it should be modified so that: > - It does not restrict the solution to the video > - It includes the need to share any kind of documents (including=20 > complex documents such as excel sheets) and the ability to have remote=20 > control >=20 > See below the discussion. >=20 > Regards, > St=E9phane. >=20 >=20 >=20 > -----Message d'origine----- > De=A0: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Envoy=E9=A0: vendredi = 12=20 > ao=FBt 2011 17:31 =C0=A0: CAZEAUX Stephane RD-BIZZ-CAE Cc=A0: clue@ietf.o= rg=20 > Objet=A0: Re: [clue] Comment on the presentation use case >=20 > On 8/12/11 4:48 AM, stephane.cazeaux@orange-ftgroup.com wrote: > > Hi Paul, > > > > I understand your suggestion, and I am aware that it could be a > solution. It certainly makes sense, but I am not sure of how it could=20 > be integrated in CLUE. To me, this is a matter of application=20 > integration, at application level. > > > > My suggestion is that we should think of a solution that provides > more satisfying collaboration within telepresence, with the same level=20 > of interoperability and multistream interaction as presentation video=20 > stream provides, but with more satisfying quality (video is not=20 > suitable for all kinds of shared documents) and more collaborative=20 > features. > > I don't think that the kind of relationship that you suggest is the > only solution. >=20 > IMO the main thing is to not constrain the mechanism used for=20 > collaboration/web sharing. That stuff is evolving at "web speed". > Anything you nail down that is constraining will be obsolete before it=20 > gets out. >=20 > (I've been looking more at RTCWEB recently, and I'm wondering if=20 > perhaps CLUE ought to be based on that.) >=20 > Thanks, > Paul (as individual) >=20 > > Stephane. > > > > > > -----Message d'origine----- > > De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Envoy=E9 : lundi 8=20 > > ao=FBt 2011 21:23 =C0 : CAZEAUX Stephane RD-BIZZ-CAE Cc : clue@ietf.org= =20 > > Objet : Re: [clue] Comment on the presentation use case > > > > On 8/8/11 11:56 AM, stephane.cazeaux@orange-ftgroup.com wrote: > >> Hi, > >> > >> To me, it should be part of the telepresence protocols at least to > enable the interoperability, as the presentation based on video stream=20 > allows it. > >> > >> The point is that video stream is not convenient for the use cases=20 > >> I > suggested. But it does not necessarily mean that we should bundle a=20 > full data sharing protocol with telepresence. Something simpler, like=20 > the RFB option of draft-garcia-mmusic-sdp-collaboration, could be a=20 > candidate. > > > > What I was suggesting is that maybe it would make sense to turn=20 > > those relationships "inside out". > > > > For instance when I use a collaboration tool like Webex, the=20 > > collaboration is set up first via the web, and defines the set of=20 > > participants. Then a voice session can be added. For pragmatic > reasons, > > the voice conferencing seems to be pretty distinct. (I'm not certain > how > > webex handles video. I suspect it is doing it via the web, not the=20 > > telephony conference.) > > > > Its not hard to imagine the same sort of setup, but with a=20 > > multiparty telepresence session instead of the traditional voice=20 > > conference. In such a case, you would probably want the=20 > > collaboration tool (webex, > or > > whatever) to mediate the UI for the web collaboration, the roster, > etc. > > It might delegate a lot of that to the telepresence infrastructure. > > > > But that does raise some questions about how all the components fit=20 > > together. Is there a single screen for the collaboration session in=20 > > a telepresence room? What about input to that - keyboard, mouse, etc.? > Or > > do we assume that each person in the room has their own computer=20 > > with input, display, etc. and maybe a way to slave the web=20 > > collaboration session to one or more of the big displays in the room? > > > > What probably *can't* be done right now is nail down a particular=20 > > web collaboration service (e.g. Webex) or protocol. That does=20 > > complicate slaving the collaboration session to a screen, unless its=20 > > done by > having > > someone connect a video connection to their own computer. > > > > Thanks, > > Paul > > > >> Stephane. > >> > >> > >> -----Message d'origine----- > >> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la=20 > >> part > de Paul Kyzivat > >> Envoy=E9 : jeudi 28 juillet 2011 13:41 =C0 : CHATRAS Bruno RD-CORE-ISS= =20 > >> Cc : clue@ietf.org Objet : Re: [clue] Comment on the presentation=20 > >> use case > >> > >> On 7/28/11 2:37 AM, bruno.chatras@orange-ftgroup.com wrote: > >>> I think we should take a look to > >>> http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration-0 > >>> 0 > >> > >> Maybe. But that is almost orthogonal to what I was suggesting. > >> > >> THanks, > >> Paul > >> (as individual) > >> > >>> Bruno > >>> > >>>> -----Message d'origine----- > >>>> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la > part de > >>>> Paul Kyzivat > >>>> Envoy=E9 : jeudi 28 juillet 2011 06:05 =C0 : Roni Even Cc :=20 > >>>> clue@ietf.org Objet : Re: [clue] Comment on the presentation use=20 > >>>> case > >>>> > >>>> On 7/27/11 11:28 PM, Roni Even wrote: > >>>>> Hi, > >>>>> HTTP is not defining a common data sharing protocol. WebEx may=20 > >>>>> be > >>>> carried > >>>>> over HTTP but the data sharing application is not standard. What > I > >>>> meant is > >>>>> that it can either be something that is a common data sharing > >>>> protocol or > >>>>> something that is carried as an RTP payload which require some > common > >>>>> defined protocol on top. > >>>> > >>>> I was being a bit tongue in cheek, though not entirely. > >>>> Of course you are right - that if you want to push data to > everybody > >>>> you > >>>> need more. > >>>> > >>>> But data sharing by pointing a video camera at a piece of paper=20 > >>>> is > a > >>>> tad > >>>> out of date. Connecting the video port on a user's computer as a > video > >>>> source and distributing it with the other video is better than > that. > >>>> But > >>>> its not nearly as convenient as webex or any of its competitors. > >>>> > >>>> It isn't entirely clear that its *necessary* to bundle the data > sharing > >>>> application with the telepresence protocols. Its kind of limiting > since > >>>> the web apps evolve very rapidly. Perhaps we should be doing the=20 > >>>> opposite of that: providing a way to embed the control of the=20 > >>>> telepresence system into a web app. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>>> -----Original Message----- > >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > >>>> Of > >>>>>> Paul Kyzivat > >>>>>> Sent: Thursday, July 28, 2011 1:29 AM > >>>>>> To: clue@ietf.org > >>>>>> Subject: Re: [clue] Comment on the presentation use case > >>>>>> > >>>>>> On 7/27/11 6:07 PM, Roni Even wrote: > >>>>>>> Hi Stephane, > >>>>>>> > >>>>>>> Is there a standard protocol that is used for conveying this=20 > >>>>>>> information, is it RTP based. > >>>>>> > >>>>>> AFAIK this is often http. (E.g. webex) > >>>>>> > >>>>>>> To me this is a separate application that can be integrated in > the > >>>>>>> application level and not as part of the multistream. > >>>>>> > >>>>>> I guess this depends on whether the support for it is=20 > >>>>>> integrated > >>>> into > >>>>>> the "room", or is just incidental equipment brought by the > users, > >>>> not > >>>>>> formally related to the telepresence session. > >>>>>> > >>>>>> Thanks, > >>>>>> Paul > >>>>>> (speaking as an individual) > >>>>>> > >>>>>>> Roni > >>>>>>> > >>>>>>> *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > Behalf Of > >>>>>>> *stephane.cazeaux@orange-ftgroup.com > >>>>>>> *Sent:* Thursday, July 21, 2011 2:33 PM > >>>>>>> *To:* clue@ietf.org > >>>>>>> *Subject:* [clue] Comment on the presentation use case* > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> *Hi,* > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> *The presentation use case as described in the use-cases > document > >>>> is > >>>>>>> based on the assumption that the presentation stream relies on > a > >>>>>> video > >>>>>>> stream, and is limited to usage of presentation video streams. > But > >>>> we > >>>>>>> could also consider collaborative use cases, meaningful for=20 > >>>>>>> telepresence, which are not covered by the existing text.* > >>>>>>> > >>>>>>> *I propose to complete the existing text as follows:* > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> *Furthermore, although most today's systems use video streams > for > >>>>>>> presentations, there are use cases where this is not suitable. > For > >>>>>> example:* > >>>>>>> > >>>>>>> *- The professor which shares an electronic whiteboard (could > be a > >>>>>>> whiteboard application on a PC, with screen capture of the PC) > >>>> where > >>>>>> all > >>>>>>> students can participate. Students will take control of the > shared > >>>>>>> whiteboard in turns.* > >>>>>>> > >>>>>>> *- In a multipoint meeting, a shared document can be kept > always > >>>>>> visible > >>>>>>> in a screen, while other documents are presented on other > screens > >>>>>> (with > >>>>>>> possible in turns presentation). For instance, for the purpose > of > >>>>>> shared > >>>>>>> design document, notes taking, polls, etc. A shared document > >>>> implies > >>>>>>> that all participants can modify it in turns.* > >>>>>>> > >>>>>>> *"* > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> ** > >>>>>>> > >>>>>>> *St ephane. v> > >>>>>>> * > >>>>>>> > >>>>>>> * > >>>>>>> * > >>>>>>> > >>>>>>> *_______________________________________________ > >>>>>>> clue mailing list > >>>>>>> clue@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>>>> * > >>>>>> > >>>>>> _______________________________________________ > >>>>>> clue mailing list > >>>>>> clue@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Mon Oct 10 13:47:09 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C5121F8CE8 for ; Mon, 10 Oct 2011 13:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2-6J3M5AoRY for ; Mon, 10 Oct 2011 13:47:08 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 3E11B21F8CE7 for ; Mon, 10 Oct 2011 13:47:08 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta14.westchester.pa.mail.comcast.net with comcast id j8bN1h00617dt5G5E8n8u5; Mon, 10 Oct 2011 20:47:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta13.westchester.pa.mail.comcast.net with comcast id j8n71h00P0tdiYw3Z8n7Yu; Mon, 10 Oct 2011 20:47:08 +0000 Message-ID: <4E9359C9.3080701@alum.mit.edu> Date: Mon, 10 Oct 2011 16:47:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Mary Barnes References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42A75@xmb-sjc-221.amer.cisco.com> <078001cc851d$4a9a1720$dfce4560$%roni@huawei.com> <4E8F4CD7.20407@alum.mit.edu> <07b601cc8538$89c51880$9d4f4980$%roni@huawei.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42DE8@xmb-sjc-221.amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] interim meeting agenda for framework doc discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 20:47:09 -0000 On 10/8/11 1:34 PM, Mary Barnes wrote: ... > > On Sat, Oct 8, 2011 at 1:03 AM, Allyn Romanow (allyn) > wrote: ... > I had listed as an issue the messaging model-- the fact that an entity > has to be both sender and receiver. We had thought that might need to be > gone over, since the model is different than the SDP offer answer > messaging style. But perhaps it is not necessary? What do people think? > If it's clear and not an issue, then we don't need to spend time on it. > I'm fine either way, but I'm not sure if there is a desire/need for > this? > > [MB] I think it would be worthwhile to have some discussion on this. We > will need to be very clear about this in the framework document as folks > outside CLUE will want to know why it is different - in particular since > the solution will (most likely) use SDP for describing the information > about the streams and their relationships. It might actually be useful > to add a section in the framework around all of this. [/MB] Hand waving can only go on for so long. While its not rocket science, there will be some knotty issues to sort out around this. For instance: - will the messaging for (sender:A,receiver:B) be interleaved with that for (sender:B,receiver:A)? - Is there any synchronization of those two sets of exchanges? - Is there any required coupling between those exchanges and the O/A exchanges between A and B? Some of this could probably be resolved at the framework level, independent of mechanism. ... > On Specifying the protocol and relation to SDP, until now I have been > trying to defer talking much about these -- Saying that we should settle > on a framework and data model, before talking about how we would > implement it in IETF protocols. However, time is passing and it is > certainly getting to be time to talk about this. I think that it may be > easier to have this discussion in face of a particular proposal. I'm not > sure how the chairs want to prioritize these 2 issues for this interim > meeting. > > [MB] While the other items are higher priority (we really want to ensure > we leave this meeting with resolution to issues identified thus far), > starting to think about this is a good idea. In particular given that > RTCWEB is looking at the relationship to SDP as well. If someone does > have a strawman proposal to put forth, that would be great. [/MB] At the very least, I think it would be good to identify who is interested in working on this, and then encourage getting started on some individual drafts covering it. A little informal brainstorming might help kick this off. Thanks, Paul From pkyzivat@alum.mit.edu Mon Oct 10 13:48:56 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F4221F8C9B for ; Mon, 10 Oct 2011 13:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mH6Y0pfDtwXs for ; Mon, 10 Oct 2011 13:48:56 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4F321F8CC2 for ; Mon, 10 Oct 2011 13:48:55 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta13.westchester.pa.mail.comcast.net with comcast id j5vk1h0041wpRvQ5D8ow3G; Mon, 10 Oct 2011 20:48:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta18.westchester.pa.mail.comcast.net with comcast id j8ov1h00d0tdiYw3e8ov26; Mon, 10 Oct 2011 20:48:56 +0000 Message-ID: <4E935A36.1050807@alum.mit.edu> Date: Mon, 10 Oct 2011 16:48:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42A75@xmb-sjc-221.amer.cisco.com> <5DCFFFE1-A69B-4FA1-9F83-E5CCA9EE0092@vidyo.com> In-Reply-To: <5DCFFFE1-A69B-4FA1-9F83-E5CCA9EE0092@vidyo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] interim meeting agenda for framework doc discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 20:48:56 -0000 Jonathan, On 10/9/11 10:20 PM, Jonathan Lennox wrote: > > On Oct 7, 2011, at 2:46 AM, Allyn Romanow (allyn) wrote: >> >> What are additional issues people feel need to be agreed upon that >> stand in the way of the document becoming a WG draft? In order to make >> progress, the discussion will be kept to identified issues. New ones >> can be added during the meeting, of course. > > One issue which I think would be useful to discuss would be a clearer > explanation of what the framework signaling looks like in a multi-point > session, specifically down from an MCU to a receiver. > > I think it's important that the protocol support, at least, a mode where > there's full "transparency" of all the participants in a conference -- > so that a receiver can say, for instance, "I want to see this scene, > permanently", it can, and it has enough information to do so meaningfully. This is starting to smell like a new requirement. Can you frame it that way? Thanks, Paul From stephen.botzko@gmail.com Mon Oct 10 15:29:12 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C6C21F8B52 for ; Mon, 10 Oct 2011 15:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Y8Fs3z6g2AA for ; Mon, 10 Oct 2011 15:29:10 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7985F21F8B4A for ; Mon, 10 Oct 2011 15:29:10 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so6240624vcb.31 for ; Mon, 10 Oct 2011 15:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BA2V2xujHBHDWE1U5Di8ojZxPLU+WX/OJDs4ecDnKTg=; b=uw8yud01avyfjX92SkOLK8QSwRs99lJpa8RPxZLffFX4qvVoA0rIpI1mM8fxtZ3rp1 AKcM1Mc0G98aZCvgPBn9lKceXRXJj4f89Tpv2l9aU6aUZi1gDQZO5zWpZ8eoiis2yW9L BTNWL8UxzlnmLP4J6lN8392yei7hh/1gwxZ9o= MIME-Version: 1.0 Received: by 10.52.34.100 with SMTP id y4mr15581349vdi.66.1318285749879; Mon, 10 Oct 2011 15:29:09 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Mon, 10 Oct 2011 15:29:09 -0700 (PDT) In-Reply-To: References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com> <4E309135.7070408@alum.mit.edu> <001b01cc4cd6$77d28760$67779620$%roni@huawei.com> <4E30DFDE.3040601@alum.mit.edu> <9ECCF01B52E7AB408A7EB85352642141031F2E5E@ftrdmel0.rd.francetelecom.fr> <4E314AD3.1030406@alum.mit.edu> <4E403783.70706@alum.mit.edu> <4E454723.4080501@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A61CE060BFF@CRPMBOXPRD01.polycom.com> Date: Mon, 10 Oct 2011 18:29:09 -0400 Message-ID: From: Stephen Botzko To: stephane.cazeaux@orange.com Content-Type: multipart/alternative; boundary=20cf3079bb06d5823904aef95122 Cc: clue@ietf.org Subject: Re: [clue] the presentation use case X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 22:29:12 -0000 --20cf3079bb06d5823904aef95122 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think the reason for considering video-based presentations within CLUE is that they create additional RTP media streams (potentially audio and video) that need to be accounted for. Other methods are certainly not precluded. I am not sure why you think a note is needed, or how it would influence protocol design. Stephen Botzko On Mon, Oct 10, 2011 at 12:53 PM, wrote: > Hi, > > Thus I still think that the use case, as currently described, is too > restrictive. One could think that only the video based presentation is > considered within the use cases, while we probably all agree that CLUE is > more generic. Could it be appropriate to indicate explicitly in the use c= ase > that other solutions for document sharing could also be considered in the > future? > > St=E9phane. > > -----Message d'origine----- > De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de > Duckworth, Mark > Envoy=E9 : vendredi 7 octobre 2011 19:51 > =C0 : clue@ietf.org > Objet : Re: [clue] the presentation use case > > Hi St=E9phane, > > The CLUE framework is intended to handle any media type that is carried > over RTP. The framework document should be relating to "media captures" = and > "media streams" in general, except when there is a need to be more specif= ic > about video or audio or any other media type. There are probably some > places in the document where it would be better to be more general, to ma= ke > sure it applies to any media type where appropriate. > > So if you want to send excel sheet data over RTP, then CLUE should be abl= e > to handle it regarding associating it with audio or giving it some spatia= l > relationship to other media streams, for example. > > I think this is as far as CLUE should go with regard to document sharing. > I think additional use cases about document sharing are not relevant to > CLUE. My thinking is based on this statement from the CLUE charter: > > "The focus of this work is on multiple RTP audio and video streams. Othe= r > media types may be considered, however development of methodologies for t= hem > is not within the scope of this work." > > Regards, > Mark Duckworth > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of stephane.cazeaux@orange.com > > Sent: Friday, October 07, 2011 7:25 AM > > To: clue@ietf.org > > Subject: [clue] the presentation use case > > > > Hi > > > > I will not be able to attend physically to the interim meeting. > > > > However I had a comment on the presentation use case, which I still > > consider we need to agree on. > > In the use case draft, the presentation use case is restricted to the > > video based solution. To me, it should be modified so that: > > - It does not restrict the solution to the video > > - It includes the need to share any kind of documents (including > > complex documents such as excel sheets) and the ability to have remote > > control > > > > See below the discussion. > > > > Regards, > > St=E9phane. > > > > > > > > -----Message d'origine----- > > De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Envoy=E9 : vendredi 12 > > ao=FBt 2011 17:31 =C0 : CAZEAUX Stephane RD-BIZZ-CAE Cc : clue@ietf.org > > Objet : Re: [clue] Comment on the presentation use case > > > > On 8/12/11 4:48 AM, stephane.cazeaux@orange-ftgroup.com wrote: > > > Hi Paul, > > > > > > I understand your suggestion, and I am aware that it could be a > > solution. It certainly makes sense, but I am not sure of how it could > > be integrated in CLUE. To me, this is a matter of application > > integration, at application level. > > > > > > My suggestion is that we should think of a solution that provides > > more satisfying collaboration within telepresence, with the same level > > of interoperability and multistream interaction as presentation video > > stream provides, but with more satisfying quality (video is not > > suitable for all kinds of shared documents) and more collaborative > > features. > > > I don't think that the kind of relationship that you suggest is the > > only solution. > > > > IMO the main thing is to not constrain the mechanism used for > > collaboration/web sharing. That stuff is evolving at "web speed". > > Anything you nail down that is constraining will be obsolete before it > > gets out. > > > > (I've been looking more at RTCWEB recently, and I'm wondering if > > perhaps CLUE ought to be based on that.) > > > > Thanks, > > Paul (as individual) > > > > > Stephane. > > > > > > > > > -----Message d'origine----- > > > De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Envoy=E9 : lundi 8 > > > ao=FBt 2011 21:23 =C0 : CAZEAUX Stephane RD-BIZZ-CAE Cc : clue@ietf.o= rg > > > Objet : Re: [clue] Comment on the presentation use case > > > > > > On 8/8/11 11:56 AM, stephane.cazeaux@orange-ftgroup.com wrote: > > >> Hi, > > >> > > >> To me, it should be part of the telepresence protocols at least to > > enable the interoperability, as the presentation based on video stream > > allows it. > > >> > > >> The point is that video stream is not convenient for the use cases > > >> I > > suggested. But it does not necessarily mean that we should bundle a > > full data sharing protocol with telepresence. Something simpler, like > > the RFB option of draft-garcia-mmusic-sdp-collaboration, could be a > > candidate. > > > > > > What I was suggesting is that maybe it would make sense to turn > > > those relationships "inside out". > > > > > > For instance when I use a collaboration tool like Webex, the > > > collaboration is set up first via the web, and defines the set of > > > participants. Then a voice session can be added. For pragmatic > > reasons, > > > the voice conferencing seems to be pretty distinct. (I'm not certain > > how > > > webex handles video. I suspect it is doing it via the web, not the > > > telephony conference.) > > > > > > Its not hard to imagine the same sort of setup, but with a > > > multiparty telepresence session instead of the traditional voice > > > conference. In such a case, you would probably want the > > > collaboration tool (webex, > > or > > > whatever) to mediate the UI for the web collaboration, the roster, > > etc. > > > It might delegate a lot of that to the telepresence infrastructure. > > > > > > But that does raise some questions about how all the components fit > > > together. Is there a single screen for the collaboration session in > > > a telepresence room? What about input to that - keyboard, mouse, etc.= ? > > Or > > > do we assume that each person in the room has their own computer > > > with input, display, etc. and maybe a way to slave the web > > > collaboration session to one or more of the big displays in the room? > > > > > > What probably *can't* be done right now is nail down a particular > > > web collaboration service (e.g. Webex) or protocol. That does > > > complicate slaving the collaboration session to a screen, unless its > > > done by > > having > > > someone connect a video connection to their own computer. > > > > > > Thanks, > > > Paul > > > > > >> Stephane. > > >> > > >> > > >> -----Message d'origine----- > > >> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la > > >> part > > de Paul Kyzivat > > >> Envoy=E9 : jeudi 28 juillet 2011 13:41 =C0 : CHATRAS Bruno RD-CORE-I= SS > > >> Cc : clue@ietf.org Objet : Re: [clue] Comment on the presentation > > >> use case > > >> > > >> On 7/28/11 2:37 AM, bruno.chatras@orange-ftgroup.com wrote: > > >>> I think we should take a look to > > >>> http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration-0 > > >>> 0 > > >> > > >> Maybe. But that is almost orthogonal to what I was suggesting. > > >> > > >> THanks, > > >> Paul > > >> (as individual) > > >> > > >>> Bruno > > >>> > > >>>> -----Message d'origine----- > > >>>> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la > > part de > > >>>> Paul Kyzivat > > >>>> Envoy=E9 : jeudi 28 juillet 2011 06:05 =C0 : Roni Even Cc : > > >>>> clue@ietf.org Objet : Re: [clue] Comment on the presentation use > > >>>> case > > >>>> > > >>>> On 7/27/11 11:28 PM, Roni Even wrote: > > >>>>> Hi, > > >>>>> HTTP is not defining a common data sharing protocol. WebEx may > > >>>>> be > > >>>> carried > > >>>>> over HTTP but the data sharing application is not standard. What > > I > > >>>> meant is > > >>>>> that it can either be something that is a common data sharing > > >>>> protocol or > > >>>>> something that is carried as an RTP payload which require some > > common > > >>>>> defined protocol on top. > > >>>> > > >>>> I was being a bit tongue in cheek, though not entirely. > > >>>> Of course you are right - that if you want to push data to > > everybody > > >>>> you > > >>>> need more. > > >>>> > > >>>> But data sharing by pointing a video camera at a piece of paper > > >>>> is > > a > > >>>> tad > > >>>> out of date. Connecting the video port on a user's computer as a > > video > > >>>> source and distributing it with the other video is better than > > that. > > >>>> But > > >>>> its not nearly as convenient as webex or any of its competitors. > > >>>> > > >>>> It isn't entirely clear that its *necessary* to bundle the data > > sharing > > >>>> application with the telepresence protocols. Its kind of limiting > > since > > >>>> the web apps evolve very rapidly. Perhaps we should be doing the > > >>>> opposite of that: providing a way to embed the control of the > > >>>> telepresence system into a web app. > > >>>> > > >>>> Thanks, > > >>>> Paul > > >>>> > > >>>>>> -----Original Message----- > > >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf > > >>>> Of > > >>>>>> Paul Kyzivat > > >>>>>> Sent: Thursday, July 28, 2011 1:29 AM > > >>>>>> To: clue@ietf.org > > >>>>>> Subject: Re: [clue] Comment on the presentation use case > > >>>>>> > > >>>>>> On 7/27/11 6:07 PM, Roni Even wrote: > > >>>>>>> Hi Stephane, > > >>>>>>> > > >>>>>>> Is there a standard protocol that is used for conveying this > > >>>>>>> information, is it RTP based. > > >>>>>> > > >>>>>> AFAIK this is often http. (E.g. webex) > > >>>>>> > > >>>>>>> To me this is a separate application that can be integrated in > > the > > >>>>>>> application level and not as part of the multistream. > > >>>>>> > > >>>>>> I guess this depends on whether the support for it is > > >>>>>> integrated > > >>>> into > > >>>>>> the "room", or is just incidental equipment brought by the > > users, > > >>>> not > > >>>>>> formally related to the telepresence session. > > >>>>>> > > >>>>>> Thanks, > > >>>>>> Paul > > >>>>>> (speaking as an individual) > > >>>>>> > > >>>>>>> Roni > > >>>>>>> > > >>>>>>> *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > > Behalf Of > > >>>>>>> *stephane.cazeaux@orange-ftgroup.com > > >>>>>>> *Sent:* Thursday, July 21, 2011 2:33 PM > > >>>>>>> *To:* clue@ietf.org > > >>>>>>> *Subject:* [clue] Comment on the presentation use case* > > >>>>>>> > > >>>>>>> ** > > >>>>>>> > > >>>>>>> *Hi,* > > >>>>>>> > > >>>>>>> ** > > >>>>>>> > > >>>>>>> *The presentation use case as described in the use-cases > > document > > >>>> is > > >>>>>>> based on the assumption that the presentation stream relies on > > a > > >>>>>> video > > >>>>>>> stream, and is limited to usage of presentation video streams. > > But > > >>>> we > > >>>>>>> could also consider collaborative use cases, meaningful for > > >>>>>>> telepresence, which are not covered by the existing text.* > > >>>>>>> > > >>>>>>> *I propose to complete the existing text as follows:* > > >>>>>>> > > >>>>>>> ** > > >>>>>>> > > >>>>>>> *Furthermore, although most today's systems use video streams > > for > > >>>>>>> presentations, there are use cases where this is not suitable. > > For > > >>>>>> example:* > > >>>>>>> > > >>>>>>> *- The professor which shares an electronic whiteboard (could > > be a > > >>>>>>> whiteboard application on a PC, with screen capture of the PC) > > >>>> where > > >>>>>> all > > >>>>>>> students can participate. Students will take control of the > > shared > > >>>>>>> whiteboard in turns.* > > >>>>>>> > > >>>>>>> *- In a multipoint meeting, a shared document can be kept > > always > > >>>>>> visible > > >>>>>>> in a screen, while other documents are presented on other > > screens > > >>>>>> (with > > >>>>>>> possible in turns presentation). For instance, for the purpose > > of > > >>>>>> shared > > >>>>>>> design document, notes taking, polls, etc. A shared document > > >>>> implies > > >>>>>>> that all participants can modify it in turns.* > > >>>>>>> > > >>>>>>> *"* > > >>>>>>> > > >>>>>>> ** > > >>>>>>> > > >>>>>>> ** > > >>>>>>> > > >>>>>>> *St ephane. v> > > >>>>>>> * > > >>>>>>> > > >>>>>>> * > > >>>>>>> * > > >>>>>>> > > >>>>>>> *_______________________________________________ > > >>>>>>> clue mailing list > > >>>>>>> clue@ietf.org > > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > > >>>>>>> * > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> clue mailing list > > >>>>>> clue@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/clue > > >>>>> > > >>>>> > > >>>> > > >>>> _______________________________________________ > > >>>> clue mailing list > > >>>> clue@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/clue > > >>> > > >> > > >> _______________________________________________ > > >> clue mailing list > > >> clue@ietf.org > > >> https://www.ietf.org/mailman/listinfo/clue > > >> > > > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf3079bb06d5823904aef95122 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think the reason for considering video-based presentations within CLUE is= that they create additional RTP media streams (potentially audio and video= ) that need to be accounted for.=A0 Other methods are certainly not preclud= ed.=A0 I am not sure why you think a note is needed, or how it would influe= nce protocol design.

Stephen Botzko

On Mon, Oct 10, 2011 a= t 12:53 PM, <stephane.cazeaux@orange.com> wrote:
Hi,

Thus I still think that the use case, as currently described, is too restri= ctive. One could think that only the video based presentation is considered= within the use cases, while we probably all agree that CLUE is more generi= c. Could it be appropriate to indicate explicitly in the use case that othe= r solutions for document sharing could also be considered in the future?
St=E9phane.

-----Message d'origine-----
De=A0: clue-bounces@ietf.org [= mailto:clue-bounces@ietf.org] = De la part de Duckworth, Mark
Envoy=E9=A0: vendredi 7 octobre 2011 19:51
=C0=A0: clue@ietf.org
Objet=A0: Re: [clue] the presentation use case

Hi St=E9phane,

The CLUE framework is intended to handle any media type that is carried ove= r RTP. =A0The framework document should be relating to "media captures= " and "media streams" in general, except when there is a nee= d to be more specific about video or audio or any other media type. =A0Ther= e are probably some places in the document where it would be better to be m= ore general, to make sure it applies to any media type where appropriate.
So if you want to send excel sheet data over RTP, then CLUE should be able = to handle it regarding associating it with audio or giving it some spatial = relationship to other media streams, for example.

I think this is as far as CLUE should go with regard to document sharing. = =A0I think additional use cases about document sharing are not relevant to = CLUE. =A0My thinking is based on this statement from the CLUE charter:

"The focus of this work is on multiple RTP audio and video streams. = =A0Other media types may be considered, however development of methodologie= s for them is not within the scope of this work."

Regards,
Mark Duckworth

> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
> Of stephane.cazeaux@ora= nge.com
> Sent: Friday, October 07, 2011 7:25 AM
> To: clue@ietf.org
> Subject: [clue] the presentation use case
>
> Hi
>
> I will not be able to attend physically to the interim meeting.
>
> However I had a comment on the presentation use case, which I still > consider we need to agree on.
> In the use case draft, the presentation use case is restricted to the<= br> > video based solution. To me, it should be modified so that:
> - It does not restrict the solution to the video
> - It includes the need to share any kind of documents (including
> complex documents such as excel sheets) and the ability to have remote=
> control
>
> See below the discussion.
>
> Regards,
> St=E9phane.
>
>
>
> -----Message d'origine-----
> De=A0: Paul Kyzivat [mailto:p= kyzivat@alum.mit.edu] Envoy=E9=A0: vendredi 12
> ao=FBt 2011 17:31 =C0=A0: CAZEAUX Stephane RD-BIZZ-CAE Cc=A0: clue@ietf.org
> Objet=A0: Re: [clue] Comment on the presentation use case
>
> On 8/12/11 4:48 AM, stephane.cazeaux@orange-ftgroup.com wrote:
> > Hi Paul,
> >
> > I understand your suggestion, and I am aware that it could be a > solution. It certainly makes sense, but I am not sure of how it could<= br> > be integrated in CLUE. To me, this is a matter of application
> integration, at application level.
> >
> > My suggestion is that we should think of a solution that provides=
> more satisfying collaboration within telepresence, with the same level=
> of interoperability and multistream interaction as presentation video<= br> > stream provides, but with more satisfying quality (video is not
> suitable for all kinds of shared documents) and more collaborative
> features.
> > I don't think that the kind of relationship that you suggest = is the
> only solution.
>
> IMO the main thing is to not constrain the mechanism used for
> collaboration/web sharing. That stuff is evolving at "web speed&q= uot;.
> Anything you nail down that is constraining will be obsolete before it=
> gets out.
>
> (I've been looking more at RTCWEB recently, and I'm wondering = if
> perhaps CLUE ought to be based on that.)
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul (as individual)
>
> > Stephane.
> >
> >
> > -----Message d'origine-----
> > De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Envoy=E9 : lundi 8
> > ao=FBt 2011 21:23 =C0 : CAZEAUX Stephane RD-BIZZ-CAE Cc : clue@ietf.org
> > Objet : Re: [clue] Comment on the presentation use case
> >
> > On 8/8/11 11:56 AM, stephane.cazeaux@orange-ftgroup.com wrote:
> >> Hi,
> >>
> >> To me, it should be part of the telepresence protocols at lea= st to
> enable the interoperability, as the presentation based on video stream=
> allows it.
> >>
> >> The point is that video stream is not convenient for the use = cases
> >> I
> suggested. But it does not necessarily mean that we should bundle a > full data sharing protocol with telepresence. Something simpler, like<= br> > the RFB option of draft-garcia-mmusic-sdp-collaboration, could be a > candidate.
> >
> > What I was suggesting is that maybe it would make sense to turn > > those relationships "inside out".
> >
> > For instance when I use a collaboration tool like Webex, the
> > collaboration is set up first via the web, and defines the set of=
> > participants. Then a voice session can be added. For pragmatic > reasons,
> > the voice conferencing seems to be pretty distinct. (I'm not = certain
> how
> > webex handles video. I suspect it is doing it via the web, not th= e
> > telephony conference.)
> >
> > Its not hard to imagine the same sort of setup, but with a
> > multiparty telepresence session instead of the traditional voice<= br> > > conference. In such a case, you would probably want the
> > collaboration tool (webex,
> or
> > whatever) to mediate the UI for the web collaboration, the roster= ,
> etc.
> > It might delegate a lot of that to the telepresence infrastructur= e.
> >
> > But that does raise some questions about how all the components f= it
> > together. Is there a single screen for the collaboration session = in
> > a telepresence room? What about input to that - keyboard, mouse, = etc.?
> Or
> > do we assume that each person in the room has their own computer<= br> > > with input, display, etc. and maybe a way to slave the web
> > collaboration session to one or more of the big displays in the r= oom?
> >
> > What probably *can't* be done right now is nail down a partic= ular
> > web collaboration service (e.g. Webex) or protocol. That does
> > complicate slaving the collaboration session to a screen, unless = its
> > done by
> having
> > someone connect a video connection to their own computer.
> >
> > =A0 =A0 Thanks,
> > =A0 =A0 Paul
> >
> >> Stephane.
> >>
> >>
> >> -----Message d'origine-----
> >> De : clue-bounces@ie= tf.org [mailto:clue-bounces@ie= tf.org] De la
> >> part
> de Paul Kyzivat
> >> Envoy=E9 : jeudi 28 juillet 2011 13:41 =C0 : CHATRAS Bruno RD= -CORE-ISS
> >> Cc : clue@ietf.org Objet= : Re: [clue] Comment on the presentation
> >> use case
> >>
> >> On 7/28/11 2:37 AM, bruno.chatras@orange-ftgroup.com wrote:
> >>> I think we should take a look to
> >>> http://tools.ietf.org/html/draft-ga= rcia-mmusic-sdp-collaboration-0
> >>> 0
> >>
> >> Maybe. But that is almost orthogonal to what I was suggesting= .
> >>
> >> =A0 =A0THanks,
> >> =A0 =A0Paul
> >> =A0 =A0(as individual)
> >>
> >>> Bruno
> >>>
> >>>> -----Message d'origine-----
> >>>> De : clue-bo= unces@ietf.org [mailto:clue-bo= unces@ietf.org] De la
> part de
> >>>> Paul Kyzivat
> >>>> Envoy=E9 : jeudi 28 juillet 2011 06:05 =C0 : Roni Eve= n Cc :
> >>>> clue@ietf.org Ob= jet : Re: [clue] Comment on the presentation use
> >>>> case
> >>>>
> >>>> On 7/27/11 11:28 PM, Roni Even wrote:
> >>>>> Hi,
> >>>>> HTTP is not defining a common data sharing protoc= ol. WebEx may
> >>>>> be
> >>>> carried
> >>>>> over HTTP but the data sharing application is not= standard. What
> I
> >>>> meant is
> >>>>> that it can either be something that is a common = data sharing
> >>>> protocol or
> >>>>> something that is carried as an RTP payload which= require some
> common
> >>>>> defined protocol on top.
> >>>>
> >>>> I was being a bit tongue in cheek, though not entirel= y.
> >>>> Of course you are right - that if you want to push da= ta to
> everybody
> >>>> you
> >>>> need more.
> >>>>
> >>>> But data sharing by pointing a video camera at a piec= e of paper
> >>>> is
> a
> >>>> tad
> >>>> out of date. Connecting the video port on a user'= s computer as a
> video
> >>>> source and distributing it with the other video is be= tter than
> that.
> >>>> But
> >>>> its not nearly as convenient as webex or any of its c= ompetitors.
> >>>>
> >>>> It isn't entirely clear that its *necessary* to b= undle the data
> sharing
> >>>> application with the telepresence protocols. Its kind= of limiting
> since
> >>>> the web apps evolve very rapidly. Perhaps we should b= e doing the
> >>>> opposite of that: providing a way to embed the contro= l of the
> >>>> telepresence system into a web app.
> >>>>
> >>>> =A0Thanks,
> >>>> =A0Paul
> >>>>
> >>>>>> -----Original Message-----
> >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On
> Behalf
> >>>> Of
> >>>>>> Paul Kyzivat
> >>>>>> Sent: Thursday, July 28, 2011 1:29 AM
> >>>>>> To: clue@iet= f.org
> >>>>>> Subject: Re: [clue] Comment on the presentati= on use case
> >>>>>>
> >>>>>> On 7/27/11 6:07 PM, Roni Even wrote:
> >>>>>>> Hi Stephane,
> >>>>>>>
> >>>>>>> Is there a standard protocol that is used= for conveying this
> >>>>>>> information, is it RTP based.
> >>>>>>
> >>>>>> AFAIK this is often http. (E.g. webex)
> >>>>>>
> >>>>>>> To me this is a separate application that= can be integrated in
> the
> >>>>>>> application level and not as part of the = multistream.
> >>>>>>
> >>>>>> I guess this depends on whether the support f= or it is
> >>>>>> integrated
> >>>> into
> >>>>>> the "room", or is just incidental e= quipment brought by the
> users,
> >>>> not
> >>>>>> formally related to the telepresence session.=
> >>>>>>
> >>>>>> =A0 =A0 =A0 =A0Thanks,
> >>>>>> =A0 =A0 =A0 =A0Paul
> >>>>>> =A0 =A0 =A0 =A0(speaking as an individual) > >>>>>>
> >>>>>>> Roni
> >>>>>>>
> >>>>>>> *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On
> Behalf Of
> >>>>>>> *stephane.cazeaux@orange-ftgroup.com
> >>>>>>> *Sent:* Thursday, July 21, 2011 2:33 PM > >>>>>>> *To:* cl= ue@ietf.org
> >>>>>>> *Subject:* [clue] Comment on the presenta= tion use case*
> >>>>>>>
> >>>>>>> **
> >>>>>>>
> >>>>>>> *Hi,*
> >>>>>>>
> >>>>>>> **
> >>>>>>>
> >>>>>>> *The presentation use case as described i= n the use-cases
> document
> >>>> is
> >>>>>>> based on the assumption that the presenta= tion stream relies on
> a
> >>>>>> video
> >>>>>>> stream, and is limited to usage of presen= tation video streams.
> But
> >>>> we
> >>>>>>> could also consider collaborative use cas= es, meaningful for
> >>>>>>> telepresence, which are not covered by th= e existing text.*
> >>>>>>>
> >>>>>>> *I propose to complete the existing text = as follows:*
> >>>>>>>
> >>>>>>> **
> >>>>>>>
> >>>>>>> *Furthermore, although most today's s= ystems use video streams
> for
> >>>>>>> presentations, there are use cases where = this is not suitable.
> For
> >>>>>> example:*
> >>>>>>>
> >>>>>>> *- The professor which shares an electron= ic whiteboard (could
> be a
> >>>>>>> whiteboard application on a PC, with scre= en capture of the PC)
> >>>> where
> >>>>>> all
> >>>>>>> students can participate. Students will t= ake control of the
> shared
> >>>>>>> whiteboard in turns.*
> >>>>>>>
> >>>>>>> *- In a multipoint meeting, a shared docu= ment can be kept
> always
> >>>>>> visible
> >>>>>>> in a screen, while other documents are pr= esented on other
> screens
> >>>>>> (with
> >>>>>>> possible in turns presentation). For inst= ance, for the purpose
> of
> >>>>>> shared
> >>>>>>> design document, notes taking, polls, etc= . A shared document
> >>>> implies
> >>>>>>> that all participants can modify it in tu= rns.*
> >>>>>>>
> >>>>>>> *"*
> >>>>>>>
> >>>>>>> **
> >>>>>>>
> >>>>>>> **
> >>>>>>>
> >>>>>>> *St ephane. v>
> >>>>>>> *
> >>>>>>>
> >>>>>>> *
> >>>>>>> *
> >>>>>>>
> >>>>>>> *________________________________________= _______
> >>>>>>> clue mailing list
> >>>>>>> clue@iet= f.org
> >>>>>>> https://www.ietf.org/mailman/listinfo/clue<= /a>
> >>>>>>> *
> >>>>>>
> >>>>>> _____________________________________________= __
> >>>>>> clue mailing list
> >>>>>> clue@ietf.or= g
> >>>>>> https://www.ietf.org/mailman/listinfo/clue<= br> > >>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> clue mailing list
> >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue
> >>>
> >>
> >> _______________________________________________
> >> clue mailing list
> >> clue@ietf.org
> >> https://www.ietf.org/mailman/listinfo/clue
> >>
> >
> >
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf3079bb06d5823904aef95122-- From Christian.Groves@nteczone.com Mon Oct 10 17:44:03 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC8421F8C8A for ; Mon, 10 Oct 2011 17:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8sNM9G5W3rG for ; Mon, 10 Oct 2011 17:44:02 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id B8FBD21F8C84 for ; Mon, 10 Oct 2011 17:44:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAPeNk0520RZI/2dsb2JhbAAMN6p8AQEBAwEBAQE1GxsKAQULCxgJFg8JAwIBAgEVMAYNAQUCAQEXh2MHugkDh0MEjlcClwQ Received: from ppp118-209-22-72.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.22.72]) by ipmail05.adl6.internode.on.net with ESMTP; 11 Oct 2011 11:13:59 +1030 Message-ID: <4E93914B.4000002@nteczone.com> Date: Tue, 11 Oct 2011 11:43:55 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Allyn Romanow (allyn)" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C85189@xmb-sjc-221.amer.cisco.com> <4E8E6B36.9000106@nteczone.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C8527D@xmb-sjc-221.amer.cisco.com> <4E923F4C.5090902@nteczone.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42E72@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42E72@xmb-sjc-221.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] interim meeting-- Requirements doc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 00:44:03 -0000 Hello Allyn, Please see my replies below. Regards, Christian On 10/10/2011 2:30 PM, Allyn Romanow (allyn) wrote: ..snip.. >>>> 6) Section 3.x: [CNG] The framework draft sect 6.1 indicates that >>> media >>>> descriptions are dynamic. I.e. capabilities may change. There's >>> nothing >>>> explicit in the requirements to support this. Likewise there > doesn't >>>> appear to be a use case to support that. Do we need to add one for >>>> that? >>>> >>> AR- Yes, I agree with you that there isn't a use case that describes >> a >>> receiver taking advantage of a change in encoding characteristics, > or >>> other attributes. I don't feel that there needs to a use case, but > we >>> could add one if people feel it is necessary. >>> >>> If you were to put in a requirement for this, it would not be to > make >>> capabilities dynamic, as that is tied to the particular solution >>> mechanism we are proposing. It would be more along the lines that >>> endpoints may change the characteristics of what they send.. which >>> doesn't seem to me to be much of a requirement. >> [CNG] Why isn't it much of a requirement? It does have eventual >> non-neglible protocol and system impacts about described how data is >> removed, replaced, flow are co-ordinated etc. > Okay, I think the best thing would be if you draft the requirement that > you would like, and then we could discuss that. > thanks [CNG] How about something like? REQMT-17 The solution MUST allow the endpoints (including MCU) involved in a telepresence session to negotiate the characteristics at the start of a session and to add/modify/remove characteristics whilst the session is ongoing. Note 1: Negotiation Requirement from use case 3.2 last paragraph. Note 2: Add/Modify/Move requirement from use case 3.5 first paragraph. >>>> Also a couple of additional comments on >>>> draft-ietf-clue-telepresence-requirements: >>>> >>>> REQMT-1b : This talks about two dimensions x,y. Given the recent >>>> discussions on capture area do we also need to a third dimension z? >>> AR- I don't think this has been settled yet. >> [CNG] Its in the current framework document. I guess if the framework >> is >> accepted as a WG document then it is settled? >>>> REQMT-2 :Is it also appropriate to add capture area x,y,z >>> AR - Again, I don't think this has been settled. >> [CNG] As above. > AR - yes you are quite right that a third dimension is in the draft, I > overlooked that in responding to you. > If you wish to have a requirement that includes a third dimension, > please draft one, and it can be discussed. [CNG] There's also requirements that discuss dimensional aspects I would propose simply amending these, i.e. REQMT-1b: The solution MUST support a means of allowing the preservation of order of images in the scene in three dimensions- horizontal and vertical and depth. I'm not sure if we need to be explicit as to depth in the audio requirements? > >>>> General : Point of Capture? I couldn't see where this is in the >>>> requirements? >>> AR - I think point of capture wouldn't be in the requirements.. it > is >>> part of the necessary mechanism for this proposed solution which >> enables >>> spatial arrangement, which is in the requirements. >> [CNG] I guess I don't have a good understanding of what should be in >> the >> requirements and what shouldn't be. For me point of capture doesn't >> come >> from the "spatial" arrangement requirement but from the need to > support >> the "multiview" use case (at least according to the framework draft >> text). I.e. multiple cameras pointed at the same capture area. I > didn't >> find a clear requirement in the requirements document linking to the >> multiview use case in the use case document. > AR - What should be in the requirements is general functionality that > the protocol needs to accomplish, rather than the mechanisms to make > that function happen. The requirements were re-written many times to > get away from mechanisms toward functionality. [CNG] I agree requirements should concentrate on functionality rather than the protocol mechanisms. > There was a requirement for multi-view in the personal draft -03. > If you want to add a requirement to support multi-view functionality, > would you draft what you have in mind? > > > In general, not all the functionality in the spec needs to be in the > requirements, though any functions in the requirement do need to be in > the spec. If there are functions in requirements that are not wanted in > the spec, the requirements should be updated. [CNG] I don't follow. You say there may be additional functionality in the spec that's not in the requirements, then how does it get added if we don't agree that there is a requirement for it? Then you say functions in the requirements do not need to be in the spec? Then why are they in the requirements? I would think the goal would be to have the requirements and the spec aligned? > > There is no problem with seeking to add to the requirements - if you > would suggest the text you want to add it would be better because we > could then discuss exactly what you would like to add. [CNG] For the multiview case how does this sound? REQMT-18 The solution MUST support a multi-view case where multiple cameras are focussed on the same area of view. Note: Multiview requirement from use case 3.7 paragraph 2. > > Thanks, > Allyn > >>> Regards, >>> Allyn >>> >>> >>>> Regards, Christian >>>> >>>> On 7/10/2011 9:42 AM, Allyn Romanow (allyn) wrote: >>>>> Hi Folks, >>>>> >>>>> Are there issues that people would like to discuss about the >>>>> requirements doc at the interim meeting next week? >>>>> >>>>> Thanks, >>>>> >>>>> Allyn >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Mon Oct 10 18:23:38 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31BC21F8CB0 for ; Mon, 10 Oct 2011 18:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+pcAO4hwDgv for ; Mon, 10 Oct 2011 18:23:37 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 43EEA21F8C74 for ; Mon, 10 Oct 2011 18:23:37 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so6329199vcb.31 for ; Mon, 10 Oct 2011 18:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8Es5EWouORTlklXC8OaJ1mfvvYJExesDSqjQ+voa7qA=; b=per/6vcM0ut5VVv5ZrQ/ifymEPclPbdZqvyB6Jt5olVOlkagls0aCY0NuIZMWwwuvX kiaEp+Bn0gcG75jTe2ixQ6h3KGc1DRCEjyer6sFlxSXPeTaB6wzIuuOlT0eX0M7iJcMo VEfgSR+SknvjihUf/xMTu0DYiR0Fzip+0hi6E= MIME-Version: 1.0 Received: by 10.52.34.100 with SMTP id y4mr16018416vdi.66.1318296216590; Mon, 10 Oct 2011 18:23:36 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Mon, 10 Oct 2011 18:23:36 -0700 (PDT) In-Reply-To: <4E93914B.4000002@nteczone.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C85189@xmb-sjc-221.amer.cisco.com> <4E8E6B36.9000106@nteczone.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C8527D@xmb-sjc-221.amer.cisco.com> <4E923F4C.5090902@nteczone.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42E72@xmb-sjc-221.amer.cisco.com> <4E93914B.4000002@nteczone.com> Date: Mon, 10 Oct 2011 21:23:36 -0400 Message-ID: From: Stephen Botzko To: Christian Groves Content-Type: multipart/alternative; boundary=20cf3079bb06b2d8ff04aefbc12b Cc: clue@ietf.org Subject: Re: [clue] interim meeting-- Requirements doc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 01:23:38 -0000 --20cf3079bb06b2d8ff04aefbc12b Content-Type: text/plain; charset=ISO-8859-1 in-lint On Mon, Oct 10, 2011 at 8:43 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Allyn, > > Please see my replies below. > > Regards, Christian > > On 10/10/2011 2:30 PM, Allyn Romanow (allyn) wrote: > ..snip.. > > 6) Section 3.x: [CNG] The framework draft sect 6.1 indicates that >>>>> >>>> media >>>> >>>>> descriptions are dynamic. I.e. capabilities may change. There's >>>>> >>>> nothing >>>> >>>>> explicit in the requirements to support this. Likewise there >>>>> >>>> doesn't >> >>> appear to be a use case to support that. Do we need to add one for >>>>> that? >>>>> >>>>> AR- Yes, I agree with you that there isn't a use case that describes >>>> >>> a >>> >>>> receiver taking advantage of a change in encoding characteristics, >>>> >>> or >> >>> other attributes. I don't feel that there needs to a use case, but >>>> >>> we >> >>> could add one if people feel it is necessary. >>>> >>>> If you were to put in a requirement for this, it would not be to >>>> >>> make >> >>> capabilities dynamic, as that is tied to the particular solution >>>> mechanism we are proposing. It would be more along the lines that >>>> endpoints may change the characteristics of what they send.. which >>>> doesn't seem to me to be much of a requirement. >>>> >>> [CNG] Why isn't it much of a requirement? It does have eventual >>> non-neglible protocol and system impacts about described how data is >>> removed, replaced, flow are co-ordinated etc. >>> >> Okay, I think the best thing would be if you draft the requirement that >> you would like, and then we could discuss that. >> thanks >> > [CNG] How about something like? > > REQMT-17 The solution MUST allow the endpoints (including MCU) involved in > a telepresence session to negotiate the characteristics at the start of a > session and to add/modify/remove characteristics whilst the session is > ongoing. > Note 1: Negotiation Requirement from use case 3.2 last paragraph. > Note 2: Add/Modify/Move requirement from use case 3.5 first paragraph. > > > Also a couple of additional comments on >>>>> draft-ietf-clue-telepresence-**requirements: >>>>> >>>>> REQMT-1b : This talks about two dimensions x,y. Given the recent >>>>> discussions on capture area do we also need to a third dimension z? >>>>> >>>> AR- I don't think this has been settled yet. >>>> >>> [CNG] Its in the current framework document. I guess if the framework >>> is >>> accepted as a WG document then it is settled? >>> >>>> REQMT-2 :Is it also appropriate to add capture area x,y,z >>>>> >>>> AR - Again, I don't think this has been settled. >>>> >>> [CNG] As above. >>> >> AR - yes you are quite right that a third dimension is in the draft, I >> overlooked that in responding to you. >> If you wish to have a requirement that includes a third dimension, >> please draft one, and it can be discussed. >> > [CNG] There's also requirements that discuss dimensional aspects I would > propose simply amending these, i.e. > > REQMT-1b: The solution MUST support a means of allowing > the preservation of order of images in the > scene in three dimensions- horizontal and > vertical and depth. > [sb] I'm not sure what this even means, I don't think that we should adopt this language without more thought. How are you thinking this is rendered? If we can't think up some reasonable way to render it, why should we require it in the solution? > > I'm not sure if we need to be explicit as to depth in the audio > requirements? > > [sb] I'm even more confused on rendering audio with depth - as I mentioned in previous posts, you'd need to be able to place the audio at the specified apparent depths behind wall-mounted monitors. I don't think that's possible, certainly not in an interoperable way. I also don't think its needed. > > >> General : Point of Capture? I couldn't see where this is in the >>>>> requirements? >>>>> >>>> AR - I think point of capture wouldn't be in the requirements.. it >>>> >>> is >> >>> part of the necessary mechanism for this proposed solution which >>>> >>> enables >>> >>>> spatial arrangement, which is in the requirements. >>>> >>> [CNG] I guess I don't have a good understanding of what should be in >>> the >>> requirements and what shouldn't be. For me point of capture doesn't >>> come >>> from the "spatial" arrangement requirement but from the need to >>> >> support >> >>> the "multiview" use case (at least according to the framework draft >>> text). I.e. multiple cameras pointed at the same capture area. I >>> >> didn't >> >>> find a clear requirement in the requirements document linking to the >>> multiview use case in the use case document. >>> >> AR - What should be in the requirements is general functionality that >> the protocol needs to accomplish, rather than the mechanisms to make >> that function happen. The requirements were re-written many times to >> get away from mechanisms toward functionality. >> > [CNG] I agree requirements should concentrate on functionality rather than > the protocol mechanisms. > > > There was a requirement for multi-view in the personal draft -03. >> If you want to add a requirement to support multi-view functionality, >> would you draft what you have in mind? >> >> >> In general, not all the functionality in the spec needs to be in the >> requirements, though any functions in the requirement do need to be in >> the spec. If there are functions in requirements that are not wanted in >> the spec, the requirements should be updated. >> > [CNG] I don't follow. You say there may be additional functionality in the > spec that's not in the requirements, then how does it get added if we don't > agree that there is a requirement for it? Then you say functions in the > requirements do not need to be in the spec? Then why are they in the > requirements? I would think the goal would be to have the requirements and > the spec aligned? > > >> There is no problem with seeking to add to the requirements - if you >> would suggest the text you want to add it would be better because we >> could then discuss exactly what you would like to add. >> > [CNG] For the multiview case how does this sound? > REQMT-18 The solution MUST support a multi-view case where multiple cameras > are focussed on the same area of view. > Note: Multiview requirement from use case 3.7 paragraph 2. > > >> Thanks, >> Allyn >> >> Regards, >>>> Allyn >>>> >>>> >>>> Regards, Christian >>>>> >>>>> On 7/10/2011 9:42 AM, Allyn Romanow (allyn) wrote: >>>>> >>>>>> Hi Folks, >>>>>> >>>>>> Are there issues that people would like to discuss about the >>>>>> requirements doc at the interim meeting next week? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Allyn >>>>>> >>>>>> >>>>>> >>>>>> ______________________________**_________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/**listinfo/clue >>>>>> >>>>> ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --20cf3079bb06b2d8ff04aefbc12b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable in-lint

On Mon, Oct 10, 2011 at 8:43 PM, = Christian Groves <Christian.Groves@nteczone.com> wrote:
Hello Allyn,

Please see my replies below.

Regards, Christian

On 10/10/2011 2:30 PM, Allyn Romanow (allyn) wrote:
..snip..

6) Section 3.x: [CNG] The framework draft sect 6.1 indicates that
media
descriptions are dynamic. I.e. capabilities may change. There's
nothing
explicit in the requirements to support this. Likewise there
doesn't
appear to be a use case to support that. Do we need to add one for
that?

AR- Yes, I agree with you that there isn't a use case that describes
a
receiver taking advantage of a change in encoding characteristics,
or
other attributes. I don't feel that there needs to a use case, but
we
could add one if people feel it is necessary.

If you were to put in a requirement for this, it would not be to
make
capabilities dynamic, as that is tied to the particular solution
mechanism we are proposing. It would be more along the lines that
endpoints may change the characteristics of what they send.. which
doesn't seem to me to be much of a requirement.
[CNG] Why isn't it much of a requirement? It does have eventual
non-neglible protocol and system impacts about described how data is
removed, replaced, flow are co-ordinated etc.
Okay, I think the best thing would be if you draft the requirement that
you would like, and then we could discuss that.
thanks
[CNG] How about something like?

REQMT-17 The solution MUST allow the endpoints (including MCU) involved in = a telepresence session to negotiate the characteristics at the start of a s= ession and to add/modify/remove characteristics whilst the session is ongoi= ng.
Note 1: Negotiation Requirement from use case 3.2 last paragraph.
Note 2: Add/Modify/Move requirement from use case 3.5 first paragraph.


Also a couple of additional comments on
draft-ietf-clue-telepresence-requirements:

REQMT-1b : This talks about two dimensions x,y. Given the recent
discussions on capture area do we also need to a third dimension z?
AR- I don't think this has been settled yet.
[CNG] Its in the current framework document. I guess if the framework
is
accepted as a WG document then it is settled?
REQMT-2 :Is it also appropriate to add capture area x,y,z
AR - Again, I don't think this has been settled.
[CNG] As above.
AR - yes you are quite right that a third dimension is in the draft, I
overlooked that in responding to you.
If you wish to have a requirement that includes a third dimension,
please draft one, and it can be discussed.
[CNG] There's also requirements that discuss dimensional aspects I woul= d propose simply amending these, i.e.

=A0 =A0 =A0 =A0 =A0 =A0 =A0REQMT-1b: =A0The solution MUST support a means = of allowing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the preservation of order = of images in the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 scene in three dimensions-= horizontal and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vertical and depth.
[sb] I'm not sure what this even means, I don't thin= k that we should adopt this language without more thought.=A0 How are you t= hinking this is rendered?=A0 If we can't think up some reasonable way t= o render it, why should we require it in the solution?

I'm not sure if we need to be explicit as to depth in the audio require= ments?

[sb] I'm even more = confused on rendering audio with depth - as I mentioned in previous posts, = you'd need to be able to place the audio at the specified apparent dept= hs behind wall-mounted monitors.=A0 I don't think that's possible, = certainly not in an interoperable way.=A0 I also don't think its needed= .


General : Point of Capture? I couldn't see where this is in the
requirements?
AR - I think point of capture wouldn't be in the requirements.. it
is
part of the necessary mechanism for this proposed solution which
enables
spatial arrangement, which is in the requirements.
[CNG] I guess I don't have a good understanding of what should be in the
requirements and what shouldn't be. For me point of capture doesn't=
come
from the "spatial" arrangement requirement but from the need to
support
the "multiview" use case (at least according to the framework dra= ft
text). I.e. multiple cameras pointed at the same capture area. I
didn't
find a clear requirement in the requirements document linking to the
multiview use case in the use case document.
AR - What should be in the requirements is general functionality that
the protocol needs to accomplish, rather than the mechanisms to make
that function happen. =A0The requirements were re-written many times to
get away from mechanisms toward functionality.
[CNG] I agree requirements should concentrate on functionality rather than = the protocol mechanisms.


There was a requirement for multi-view in the personal draft -03.
If you want to add a requirement to support multi-view functionality,
would you draft what you have in mind?


In general, not all the functionality in the spec needs to be in the
requirements, though any functions in the requirement =A0do need to be in the spec. If there are functions in requirements that are not wanted in
the spec, the requirements should be updated.
[CNG] I don't follow. You say there may be additional functionality in = the spec that's not in the requirements, then how does it get added if = we don't agree that there is a requirement for it? Then you say functio= ns in the requirements do not need to be in the spec? Then why are they in = the requirements? I would think the goal would be to have the requirements = and the spec aligned?


There is no problem with seeking to add to the requirements - if you
would suggest the text you want to add it would be better because we
could then discuss exactly what you would like to add.
[CNG] For the multiview case how does this sound?
REQMT-18 The solution MUST support a multi-view case where multiple cameras= are focussed on the same area of view.
Note: Multiview requirement from use case 3.7 paragraph 2.
<= div class=3D"h5">

Thanks,
Allyn

Regards,
Allyn


Regards, Christian

On 7/10/2011 9:42 AM, Allyn Romanow (allyn) wrote:
Hi Folks,

Are there issues that people would like to discuss about the
requirements doc at the interim meeting next week?

Thanks,

Allyn



_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf3079bb06b2d8ff04aefbc12b-- From pkyzivat@alum.mit.edu Mon Oct 10 19:05:48 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B91421F8B13 for ; Mon, 10 Oct 2011 19:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCFzvjE+ro3F for ; Mon, 10 Oct 2011 19:05:47 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id AF7D121F8AA8 for ; Mon, 10 Oct 2011 19:05:47 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta13.westchester.pa.mail.comcast.net with comcast id jDxH1h00917dt5G5DE5oEU; Tue, 11 Oct 2011 02:05:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta13.westchester.pa.mail.comcast.net with comcast id jE5n1h0020tdiYw3ZE5ntG; Tue, 11 Oct 2011 02:05:47 +0000 Message-ID: <4E93A479.5020905@alum.mit.edu> Date: Mon, 10 Oct 2011 22:05:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C85189@xmb-sjc-221.amer.cisco.com> <4E8E6B36.9000106@nteczone.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C8527D@xmb-sjc-221.amer.cisco.com> <4E923F4C.5090902@nteczone.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42E72@xmb-sjc-221.amer.cisco.com> <4E93914B.4000002@nteczone.com> In-Reply-To: <4E93914B.4000002@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] interim meeting-- Requirements doc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 02:05:48 -0000 On 10/10/11 8:43 PM, Christian Groves wrote: >> In general, not all the functionality in the spec needs to be in the >> requirements, though any functions in the requirement do need to be in >> the spec. If there are functions in requirements that are not wanted in >> the spec, the requirements should be updated. > [CNG] I don't follow. You say there may be additional functionality in > the spec that's not in the requirements, then how does it get added if > we don't agree that there is a requirement for it? Then you say > functions in the requirements do not need to be in the spec? Then why > are they in the requirements? I would think the goal would be to have > the requirements and the spec aligned? IMO it is best that the functionality derive from the requirements. But there probably will come a time when the requirements have been finalized and we are still working on the mechanism. At that point, if we find something else that is needed, we can be obsessive-compulsive and reopen the the requirements, or we can just go ahead and add what is needed. Realistically I expect we will do the latter. But while the requirements are still open, it makes sense to establish requirements for the intended functions. Thanks, Paul From Christian.Groves@nteczone.com Mon Oct 10 19:17:59 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFDA21F8CB0 for ; Mon, 10 Oct 2011 19:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tnw4OGpvBJrk for ; Mon, 10 Oct 2011 19:17:59 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 89AB521F8CA3 for ; Mon, 10 Oct 2011 19:17:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAIqmk0520RZI/2dsb2JhbAAMNw6qZQEBAQQBAQE1GxsKARALDgoJFg8JAwIBAgEVMAYNAQUCAQGIAbl6A4dMBKUPSw Received: from ppp118-209-22-72.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.22.72]) by ipmail05.adl6.internode.on.net with ESMTP; 11 Oct 2011 12:47:56 +1030 Message-ID: <4E93A750.6010609@nteczone.com> Date: Tue, 11 Oct 2011 13:17:52 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C85189@xmb-sjc-221.amer.cisco.com> <4E8E6B36.9000106@nteczone.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C8527D@xmb-sjc-221.amer.cisco.com> <4E923F4C.5090902@nteczone.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42E72@xmb-sjc-221.amer.cisco.com> <4E93914B.4000002@nteczone.com> <4E93A479.5020905@alum.mit.edu> In-Reply-To: <4E93A479.5020905@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] interim meeting-- Requirements doc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 02:17:59 -0000 Hello Paul, I agree with you, when we're reaching completion we can be pragmatic but whilst the requirements are still open we should be looking for alignment. Regards, Christian On 11/10/2011 1:05 PM, Paul Kyzivat wrote: > On 10/10/11 8:43 PM, Christian Groves wrote: > >>> In general, not all the functionality in the spec needs to be in the >>> requirements, though any functions in the requirement do need to be in >>> the spec. If there are functions in requirements that are not wanted in >>> the spec, the requirements should be updated. >> [CNG] I don't follow. You say there may be additional functionality in >> the spec that's not in the requirements, then how does it get added if >> we don't agree that there is a requirement for it? Then you say >> functions in the requirements do not need to be in the spec? Then why >> are they in the requirements? I would think the goal would be to have >> the requirements and the spec aligned? > > IMO it is best that the functionality derive from the requirements. > But there probably will come a time when the requirements have been > finalized and we are still working on the mechanism. > > At that point, if we find something else that is needed, we can be > obsessive-compulsive and reopen the the requirements, or we can just > go ahead and add what is needed. Realistically I expect we will do the > latter. > > But while the requirements are still open, it makes sense to establish > requirements for the intended functions. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Mon Oct 10 19:22:37 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E743421F8AB0 for ; Mon, 10 Oct 2011 19:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmYIpBhqtQTa for ; Mon, 10 Oct 2011 19:22:36 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCD821F8CA3 for ; Mon, 10 Oct 2011 19:22:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAIqmk0520RZI/2dsb2JhbAAMN6pzAQEBAwE4GyUBEAshFg8JAwIBAgFFBg0BBwEBF4djugSHTASlWg Received: from ppp118-209-22-72.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.22.72]) by ipmail05.adl6.internode.on.net with ESMTP; 11 Oct 2011 12:52:35 +1030 Message-ID: <4E93A867.9030600@nteczone.com> Date: Tue, 11 Oct 2011 13:22:31 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Stephen Botzko References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C85189@xmb-sjc-221.amer.cisco.com> <4E8E6B36.9000106@nteczone.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C8527D@xmb-sjc-221.amer.cisco.com> <4E923F4C.5090902@nteczone.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42E72@xmb-sjc-221.amer.cisco.com> <4E93914B.4000002@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] interim meeting-- Requirements doc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 02:22:37 -0000 Hello Stephen, Please see my reply below. Regards, Christian ..snip.. [CNG] There's also requirements that discuss dimensional aspects I would propose simply amending these, i.e. > > > REQMT-1b: The solution MUST support a means of allowing > the preservation of order of images in the > scene in three dimensions- horizontal and > vertical and depth. > > [sb] I'm not sure what this even means, I don't think that we should > adopt this language without more thought. How are you thinking this > is rendered? If we can't think up some reasonable way to render it, > why should we require it in the solution? [CNG] I just added "three" and "and depth". Is this what you have the problem with or the wording of the whole requirement? I'm not trying to introduce anything other than allowing the capture to indicate the area x,y,z it is capturing. This would allows preservation of the spatial information of a scene. > > I'm not sure if we need to be explicit as to depth in the audio > requirements? > > [sb] I'm even more confused on rendering audio with depth - as I > mentioned in previous posts, you'd need to be able to place the audio > at the specified apparent depths behind wall-mounted monitors. I > don't think that's possible, certainly not in an interoperable way. I > also don't think its needed. [CNG] Do we need to reflect that in the framework? i.e. depth (z) is not valid for audio captures? From stephen.botzko@gmail.com Tue Oct 11 03:41:46 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBAF521F8C6F for ; Tue, 11 Oct 2011 03:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZRgHxOqdMlY for ; Tue, 11 Oct 2011 03:41:46 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C42B921F8C6E for ; Tue, 11 Oct 2011 03:41:45 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so6657832vcb.31 for ; Tue, 11 Oct 2011 03:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3lmHaqfNSpT1hehkaRVhzINU6KIr0ObhMWAOz1+ZTXI=; b=K2CUzZZ7iKn23RpyjFZ5P65d44f09sBVpVE1P22HElzPVxIDwOdOPCRc/RXwV++Ie6 FJA1/q8Su38PCtgzt1AgQX0d+1Tqz/m0n/tOZcxOo/s1IXt6sINDPySzp0glf47keYR3 Pz/M20vExe4SwDsmozvmh59V1RSHPrqkzzOeY= MIME-Version: 1.0 Received: by 10.52.90.169 with SMTP id bx9mr17474815vdb.49.1318329705263; Tue, 11 Oct 2011 03:41:45 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Tue, 11 Oct 2011 03:41:45 -0700 (PDT) In-Reply-To: <4E93A867.9030600@nteczone.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C85189@xmb-sjc-221.amer.cisco.com> <4E8E6B36.9000106@nteczone.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05C8527D@xmb-sjc-221.amer.cisco.com> <4E923F4C.5090902@nteczone.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42E72@xmb-sjc-221.amer.cisco.com> <4E93914B.4000002@nteczone.com> <4E93A867.9030600@nteczone.com> Date: Tue, 11 Oct 2011 06:41:45 -0400 Message-ID: From: Stephen Botzko To: Christian Groves Content-Type: multipart/alternative; boundary=20cf3071cc14c7728f04af038d48 Cc: clue@ietf.org Subject: Re: [clue] interim meeting-- Requirements doc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 10:41:47 -0000 --20cf3071cc14c7728f04af038d48 Content-Type: text/plain; charset=ISO-8859-1 in-line Stephen On Mon, Oct 10, 2011 at 10:22 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Stephen, > > Please see my reply below. > > Regards, Christian > ..snip.. > > [CNG] There's also requirements that discuss dimensional aspects I would > propose simply amending these, i.e. > >> >> >> REQMT-1b: The solution MUST support a means of allowing >> the preservation of order of images in the >> scene in three dimensions- horizontal and >> vertical and depth. >> >> [sb] I'm not sure what this even means, I don't think that we should adopt >> this language without more thought. How are you thinking this is rendered? >> If we can't think up some reasonable way to render it, why should we >> require it in the solution? >> > > [CNG] I just added "three" and "and depth". Is this what you have the > problem with or the wording of the whole requirement? I'm not trying to > introduce anything other than allowing the capture to indicate the area > x,y,z it is capturing. This would allows preservation of the spatial > information of a scene. > > [sb] The images themselves are 2D representations of the full 3D volume that is in the field of view of the corresponding camera. The image itself has no depth information, and the various pixels in it are reflected from various depths in the room. So I am not sure what "preservation of order of images ... in three dimensions" means. Getting a full description of the camera placement, orientation, and field of view might help receivers make choices on what images they wish to receive, and might also help them rescale those images appropriately for their viewers (and displays). But I think that is different from from your modified 1b. Marshal's "ypoint" is the distance between the camera and objects of interest (e.g., rows of people) - not really the depth of the image itself. That might be useful (or perhaps even essential), but it not really about preservation of order. > > >> I'm not sure if we need to be explicit as to depth in the audio >> requirements? >> >> [sb] I'm even more confused on rendering audio with depth - as I mentioned >> in previous posts, you'd need to be able to place the audio at the specified >> apparent depths behind wall-mounted monitors. I don't think that's >> possible, certainly not in an interoperable way. I also don't think its >> needed. >> > [CNG] Do we need to reflect that in the framework? i.e. depth (z) is not > valid for audio captures? > [sb] depth is actually y in the current framework draft, not sure if that it confusing or not. Generally receivers are more interested in height and width. [sb] Similar to video, a single channel audio capture is a 1D representation of the full 3D volume that is in its microphone pickup pattern (which attenuates, but will pick up some level of sound from the entire room). We need to provide enough information to allow panning of the room audio so the sound matches the receiver's video display choice, and also enough information to match up voice activity detected in that capture with one or more cameras that cover the volume that the microphone picks up. Matching audio pickup to camera pickup might require some depth description. --20cf3071cc14c7728f04af038d48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable in-line
Stephen

On Mon, Oct 10, 2011 a= t 10:22 PM, Christian Groves <Christian.Groves@nteczone.com> wrote= :
Hello Stephen,

Please see my reply below.

Regards, Christian
..snip..

[CNG] There's also requirements that discuss dimensional aspects I woul= d propose simply amending these, i.e.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 REQMT-1b: =A0The solution MUST support a m= eans of allowing
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the preservation of= order of images in the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0scene in three dime= nsions- horizontal and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vertical and depth.=

[sb] I'm not sure what this even means, I don't think that we shoul= d adopt this language without more thought. =A0How are you thinking this is= rendered? =A0If we can't think up some reasonable way to render it, wh= y should we require it in the solution?

[CNG] I just added "three" and "and depth". Is this wha= t you have the problem with or the wording of the whole requirement? I'= m not trying to introduce anything other than allowing the capture to indic= ate the area x,y,z it is capturing. This would allows preservation of the s= patial information of a scene.

[sb] The images themselves are 2D representatio= ns of the full 3D volume that is in the field of view of the corresponding = camera.=A0 The image itself has no depth information, and the various pixel= s in it are reflected from various depths in the room.=A0 So I am not sure = what "preservation of order of images ... in three dimensions" me= ans.=A0 Getting a full description of the camera placement, orientation, an= d field of view might help receivers make choices on what images they wish = to receive, and might also help them rescale those images appropriately for= their viewers (and displays).=A0 But I think that is different from from y= our modified 1b.

Marshal's "ypoint" is the distance between the camera and= objects of interest (e.g., rows of people) - not really the depth of the i= mage itself.=A0 That might be useful (or perhaps even essential), but it no= t really about preservation of order.


=A0 =A0I'm not sure if we need to be explicit as to depth in the audio=
=A0 =A0requirements?

[sb] I'm even more confused on rendering audio with depth - as I mentio= ned in previous posts, you'd need to be able to place the audio at the = specified apparent depths behind wall-mounted monitors. =A0I don't thin= k that's possible, certainly not in an interoperable way. =A0I also don= 't think its needed.
[CNG] Do we need to reflect that in the framework? i.e. depth (z) is not va= lid for audio captures?
[sb] depth is actually y in th= e current framework draft, not sure if that it confusing or not. Generally = receivers are more interested in height and width.
=A0
[sb] Similar to video, a single channel audio capture is = a 1D representation of the full 3D volume that is in its microphone pickup = pattern (which attenuates, but will pick up some level of sound from the en= tire room).=A0 We need to provide enough information to allow panning of th= e room audio so the sound matches the receiver's video display choice, = and also enough information to match up voice activity detected in that cap= ture with one or more cameras that cover the volume that the microphone pic= ks up.=A0 Matching audio pickup to camera pickup might require some depth d= escription.

--20cf3071cc14c7728f04af038d48-- From jonathan@vidyo.com Tue Oct 11 06:47:17 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF8421F8DC1 for ; Tue, 11 Oct 2011 06:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ngr7ffltjfv9 for ; Tue, 11 Oct 2011 06:47:17 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 0060A21F8C1F for ; Tue, 11 Oct 2011 06:47:16 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id D8CBB41735F; Tue, 11 Oct 2011 09:47:15 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id DBB6C4172E6; Tue, 11 Oct 2011 09:46:54 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Tue, 11 Oct 2011 09:46:36 -0400 From: Jonathan Lennox To: Paul Kyzivat Date: Tue, 11 Oct 2011 09:46:52 -0400 Thread-Topic: [clue] interim meeting agenda for framework doc discussion Thread-Index: AcyIHDjEjFiaXTmFRYyW+BHWuxgXag== Message-ID: <642A3846-C456-4AE5-9AA8-EB29429B82EC@vidyo.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D42A75@xmb-sjc-221.amer.cisco.com> <5DCFFFE1-A69B-4FA1-9F83-E5CCA9EE0092@vidyo.com> <4E935A36.1050807@alum.mit.edu> In-Reply-To: <4E935A36.1050807@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] interim meeting agenda for framework doc discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 13:47:17 -0000 On Oct 10, 2011, at 4:48 PM, Paul Kyzivat wrote: >> I think it's important that the protocol support, at least, a mode where >> there's full "transparency" of all the participants in a conference -- >> so that a receiver can say, for instance, "I want to see this scene, >> permanently", it can, and it has enough information to do so meaningfull= y. >=20 > This is starting to smell like a new requirement. Hm, yes, good point. > Can you frame it that way? Sure. Here's a first cut: The solution MUST support a mechanism by which one party in a multi-point c= onference can choose to permanently view ("pin") a view of a selected other= endpoint, a selected specific segment of another endpoint, or a specific p= resentation, independent of a MCU's selection policy. -- Jonathan Lennox jonathan@vidyo.com From jonathan@vidyo.com Tue Oct 11 12:39:53 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E898E1F0C49 for ; Tue, 11 Oct 2011 12:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSD6QVWyVR+6 for ; Tue, 11 Oct 2011 12:39:53 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD5F1F0C47 for ; Tue, 11 Oct 2011 12:39:53 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6F7BD416FC5 for ; Tue, 11 Oct 2011 15:39:52 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A5595416F8E for ; Tue, 11 Oct 2011 15:39:51 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Tue, 11 Oct 2011 15:39:45 -0400 From: Jonathan Lennox To: "clue@ietf.org" Date: Tue, 11 Oct 2011 15:39:50 -0400 Thread-Topic: Audio level RTP header extensions, and encryption Thread-Index: AcyITYcPqozl8D9YRkCPxb+0ojLRJg== Message-ID: <2E3D89F8-C166-409E-BA68-E874D7FF20C4@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [clue] Audio level RTP header extensions, and encryption X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 19:39:54 -0000 Hey all -- As discussed today at the interim, there are two drafts in the AVTExt worki= ng group defining RTP header extensions for audio levels, and a draft in AV= TCore (motivated by these drafts) describing how to encrypt RTP header exte= nsions. These probably aren't sufficient to describe the VAD we need for segment sw= itching (and related issues) in CLUE, but they'll likely be part of it, and= anyway I think they're an important starting point. The drafts are: draft-ietf-avtext-client-to-mixer-audio-level (overall audio level of a str= eam) draft-ietf-avtext-mixer-to-client-audio-level (audio levels of the contribu= ting sources that were mixed into a stream) draft-ietf-avtcore-srtp-encrypted-header-ext (encryption of header extensio= ns). The first two are in (or have completed?) IETF Last Call; the third should = hopefully be going to WGLC as soon as I get an updated version out. -- Jonathan Lennox jonathan@vidyo.com From john@jlc.net Wed Oct 12 03:18:33 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038C021F8C2A for ; Wed, 12 Oct 2011 03:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.392 X-Spam-Level: X-Spam-Status: No, score=-105.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O18ofTjkK359 for ; Wed, 12 Oct 2011 03:18:32 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 826FB21F8BA9 for ; Wed, 12 Oct 2011 03:18:32 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 980BD33C23; Wed, 12 Oct 2011 06:16:42 -0400 (EDT) Date: Wed, 12 Oct 2011 06:16:42 -0400 From: John Leslie To: clue@ietf.org Message-ID: <20111012101642.GC7021@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [clue] Origin and dimensions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 10:18:33 -0000 Listening yesterday, I'm not sure we all have the same understanding of mathematical modeling of cameras and microphones. Inherently, a camera needs six (or more) dimensions: three for where it is, and three for where it's pointed. A microphone needs three for where it is, and two for where it's pointed. (The difference is that the camera has a focus length -- anything closer or farther will be out of focus.) The canonical representation IMHO should be cartesian for position and polar for where it's pointed. Thus X, Y, and Z in millimetres is ideal, while pan and tilt in degrees feels right. YMMV, of course... To me pan-tilt-zoom is so cheap today that I expect it to dominate eventually; also, various calculations such as gap-correction and panorama-stitching make more sense in polar. For microphones, recall that all microphones have sensitivity patterns, and "cardioid" tends to dominate in practice: thus, where the microphone is pointed _does_ matter. I well remember when Apple was starting on MacOS they made a big thing about mathematical modeling of their display. Many folks scoffed at this; but IMHO the decision to be crisp and correct in their model really paid off. I would urge that we _have_ a canonical representation which is crisp and correct, even if it not mandatory. -- John Leslie From stephen.botzko@gmail.com Wed Oct 12 04:33:50 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1920321F8C35 for ; Wed, 12 Oct 2011 04:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXhr2M1gOeKY for ; Wed, 12 Oct 2011 04:33:49 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0BF21F8C34 for ; Wed, 12 Oct 2011 04:33:49 -0700 (PDT) Received: by vws5 with SMTP id 5so544607vws.31 for ; Wed, 12 Oct 2011 04:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Tm8mtOBYBf2juBKvCp9aV80O1SpIUFzbiVYAx879jjk=; b=xhqI/EsEHCVs5FCfwjE27pm+tsn6XTOwb0gikR3S31nQzptXZWNkMPo7FU4g3mrcz/ DM38fllUKnSxYInRarIdpDI3rZN2SKalZOmiarA5XhXj+4dkk1lmbjEO0UIA4lzzqP41 ybXWJNANvUnZ0dU+e2rVio6RSg3oXYVBAkkGc= MIME-Version: 1.0 Received: by 10.52.34.100 with SMTP id y4mr22930134vdi.66.1318419228714; Wed, 12 Oct 2011 04:33:48 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Wed, 12 Oct 2011 04:33:48 -0700 (PDT) In-Reply-To: <20111012101642.GC7021@verdi> References: <20111012101642.GC7021@verdi> Date: Wed, 12 Oct 2011 07:33:48 -0400 Message-ID: From: Stephen Botzko To: John Leslie Content-Type: multipart/alternative; boundary=20cf3079bb06cae8a704af186532 Cc: clue@ietf.org Subject: Re: [clue] Origin and dimensions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 11:33:50 -0000 --20cf3079bb06cae8a704af186532 Content-Type: text/plain; charset=ISO-8859-1 Our systems use microphone arrays, the pickup pattern is not necessarily fixed (though we are generating a proper stereo capture). In the case of audio, we should not presume that an "audio capture" comes from a single cardiod microphone. I don't favor polar for where captures are aimed, because of the origin problem stated yesterday. We need to easily identify adjacency of video captures even if the cameras are not co-located. Polar works for individual cameras, and it also works if all the cameras are in the same position. But it is not easy to tell how two fields of view are related if you use have cameras that are not co-located and you use each camera as the origin for its polar field of view. And polar is *not* natural if the origin is not the camera location. BTW, not sure about the need for focus length in general, but if we do need it we should account for depth of field (a range of distance, not just a single point). Also, we'd need to deal with auto-focus cameras. Regards, Stephen Botzko On Wed, Oct 12, 2011 at 6:16 AM, John Leslie wrote: > Listening yesterday, I'm not sure we all have the same understanding > of mathematical modeling of cameras and microphones. > > Inherently, a camera needs six (or more) dimensions: three for where > it is, and three for where it's pointed. A microphone needs three for > where it is, and two for where it's pointed. (The difference is that > the camera has a focus length -- anything closer or farther will be > out of focus.) > > The canonical representation IMHO should be cartesian for position > and polar for where it's pointed. Thus X, Y, and Z in millimetres is > ideal, while pan and tilt in degrees feels right. > > YMMV, of course... To me pan-tilt-zoom is so cheap today that I > expect it to dominate eventually; also, various calculations such as > gap-correction and panorama-stitching make more sense in polar. > > For microphones, recall that all microphones have sensitivity > patterns, and "cardioid" tends to dominate in practice: thus, where > the microphone is pointed _does_ matter. > > I well remember when Apple was starting on MacOS they made a big > thing about mathematical modeling of their display. Many folks scoffed > at this; but IMHO the decision to be crisp and correct in their model > really paid off. > > I would urge that we _have_ a canonical representation which is > crisp and correct, even if it not mandatory. > > -- > John Leslie > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf3079bb06cae8a704af186532 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Our systems use microphone arrays, the pickup pattern is not necessarily fi= xed (though we are generating a proper stereo capture). In the case of audi= o, we should not presume that an "audio capture" comes from a sin= gle cardiod microphone.

I don't favor polar for where captures are aimed, because of the or= igin problem stated yesterday.=A0 We need to easily identify adjacency of v= ideo captures even if the cameras are not co-located.=A0 Polar works for in= dividual cameras, and it also works if all the cameras are in the same posi= tion.=A0 But it is not easy to tell how two fields of view are related if y= ou use have cameras that are not co-located and you use each camera as the = origin for its polar field of view.=A0 And polar is not natural if t= he origin is not the camera location.

BTW, not sure about the need for focus length in general, but if we do = need it we should account for depth of field (a range of distance, not just= a single point).=A0=A0 Also, we'd need to deal with auto-focus cameras= .

Regards,
Stephen Botzko

On Wed, Oc= t 12, 2011 at 6:16 AM, John Leslie <john@jlc.net> wrote:
=A0 Listening yesterday, I'm not sure we all have the same understandi= ng
of mathematical modeling of cameras and microphones.

=A0 Inherently, a camera needs six (or more) dimensions: three for where it is, and three for where it's pointed. A microphone needs three for where it is, and two for where it's pointed. (The difference is that the camera has a focus length -- anything closer or farther will be
out of focus.)

=A0 The canonical representation IMHO should be cartesian for position
and polar for where it's pointed. Thus X, Y, and Z in millimetres is ideal, while pan and tilt in degrees feels right.

=A0 YMMV, of course... To me pan-tilt-zoom is so cheap today that I
expect it to dominate eventually; also, various calculations such as
gap-correction and panorama-stitching make more sense in polar.

=A0 For microphones, recall that all microphones have sensitivity
patterns, and "cardioid" tends to dominate in practice: thus, whe= re
the microphone is pointed _does_ matter.

=A0 I well remember when Apple was starting on MacOS they made a big
thing about mathematical modeling of their display. Many folks scoffed
at this; but IMHO the decision to be crisp and correct in their model
really paid off.

=A0 I would urge that we _have_ a canonical representation which is
crisp and correct, even if it not mandatory.

--
John Leslie <john@jlc.net>
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf3079bb06cae8a704af186532-- From marshall.eubanks@gmail.com Wed Oct 12 04:39:46 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA34D21F8C98 for ; Wed, 12 Oct 2011 04:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cZR+TjR9dog for ; Wed, 12 Oct 2011 04:39:46 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3C321F8C8E for ; Wed, 12 Oct 2011 04:39:46 -0700 (PDT) Received: by gyh20 with SMTP id 20so730025gyh.31 for ; Wed, 12 Oct 2011 04:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GNYgPbcEGJlHMmmHciV7fM1yUirH/FZazCwnrYO5DAA=; b=E+KvElHPqGw3O7YN/yjBQY2Y0iocejQHuxbrrDkn4LElYWG9ksdGy7rhwuief+9XhJ WFBESzuxRkdkuL2Dy8TfKzkxsuWQaaDK0cx0OwRXKLOy3vFM7uhHRfxJ834mlqL3ZmKP KYL08L6UeP5dVYVr7rMjdfyLZC3ANFHVkUrxw= MIME-Version: 1.0 Received: by 10.151.50.5 with SMTP id c5mr287602ybk.66.1318419585617; Wed, 12 Oct 2011 04:39:45 -0700 (PDT) Received: by 10.151.98.20 with HTTP; Wed, 12 Oct 2011 04:39:45 -0700 (PDT) In-Reply-To: <20111012101642.GC7021@verdi> References: <20111012101642.GC7021@verdi> Date: Wed, 12 Oct 2011 07:39:45 -0400 Message-ID: From: Marshall Eubanks To: John Leslie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: clue@ietf.org Subject: Re: [clue] Origin and dimensions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 11:39:46 -0000 Dear John; A very good and clear description here. On Wed, Oct 12, 2011 at 6:16 AM, John Leslie wrote: > =A0 Listening yesterday, I'm not sure we all have the same understanding > of mathematical modeling of cameras and microphones. > > =A0 Inherently, a camera needs six (or more) dimensions: three for where > it is, and three for where it's pointed. A microphone needs three for > where it is, and two for where it's pointed. (The difference is that > the camera has a focus length -- anything closer or farther will be > out of focus.) Yes, and they both have nominally 2-D fields of view as well, which can change if they zoom, so that is technically 8 and 7, although I think for microphones it is more common to use polar lobe widths (i..e, 1 width parameter can suffice), so 8 and 6. That assumes that people are not using arrays of microphones or 3-D cameras. Arrays of microphones (linear or otherwise) can point in multiple directions at once, so that can be dealt with as separate virtual microphones (as I don't think we want to get into microphone phase analysis, and that might be hardwired in the system and inaccessible otherwise). 3-D cameras are of course doublets, with a fixed separation and orientation, so so can be treated as 8 parameters plus 3 more (the physical separation of the cameras plus the angular orientation of the line separating them). In principle a 3-D camera can also be dealt with as simply 2 cameras (and thus 16 parameters), but treating them as a doublet reduces that to 11 (as you can assume that they are looking in the same location with the same zoom and focus). I strongly suspect that 3-D compression and display will deal with the doublet in a hard-wired fashion. > > =A0 The canonical representation IMHO should be cartesian for position > and polar for where it's pointed. Thus X, Y, and Z in millimetres is > ideal, while pan and tilt in degrees feels right. Exactly. > > =A0 YMMV, of course... To me pan-tilt-zoom is so cheap today that I > expect it to dominate eventually; also, various calculations such as > gap-correction and panorama-stitching make more sense in polar. > If parameters are fixed or irrelevant, you can simply ignore them. > =A0 For microphones, recall that all microphones have sensitivity > patterns, and "cardioid" tends to dominate in practice: thus, where > the microphone is pointed _does_ matter. > > =A0 I well remember when Apple was starting on MacOS they made a big > thing about mathematical modeling of their display. Many folks scoffed > at this; but IMHO the decision to be crisp and correct in their model > really paid off. > > =A0 I would urge that we _have_ a canonical representation which is > crisp and correct, even if it not mandatory. > In my opinion, if we don't, we are not future proofed, and will regret it l= ater. Regards Marshall > -- > John Leslie > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From john@jlc.net Wed Oct 12 09:14:35 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E71821F8C77 for ; Wed, 12 Oct 2011 09:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.297 X-Spam-Level: X-Spam-Status: No, score=-106.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+QdHeNwnk4i for ; Wed, 12 Oct 2011 09:14:34 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 924A621F8C76 for ; Wed, 12 Oct 2011 09:14:34 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 521F933C20; Wed, 12 Oct 2011 12:14:33 -0400 (EDT) Date: Wed, 12 Oct 2011 12:14:33 -0400 From: John Leslie To: Stephen Botzko Message-ID: <20111012161433.GA30384@verdi> References: <20111012101642.GC7021@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: clue@ietf.org Subject: Re: [clue] Origin and dimensions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 16:14:35 -0000 Stephen Botzko wrote: > > Our systems use microphone arrays, the pickup pattern is not necessarily > fixed (though we are generating a proper stereo capture). In the case of > audio, we should not presume that an "audio capture" comes from a single > cardiod microphone. Obviously, not all microphones are cardioid: at a minimum, you'd want to distinguish a "generic cardioid" from a "generic omnidirectional". It may make sense to have a few "generic" sensitivity patterns (which will likely be ignored by most renderers today anyway). And for a microphone array, if you don't want to generate an actual sensitivity pattern (for the array), IMHO it's reasonable to specify none. > I don't favor polar for where captures are aimed, because of the origin > problem stated yesterday. Mea culpa! I didn't intend to talk of a _single_ polar coordinate system at the origin of the cartesian system -- rather a polar system for each camera centered at the XYZ of that camera. (Where the zero pan and tilt points is arbitrary: I didn't mean to advocate anything specific.) > We need to easily identify adjacency of video captures even if the > cameras are not co-located. Actually, this _is_ easy, so long at our definitions are crisp and complete. > Polar works for individual cameras, and it also works if all the cameras > are in the same position. But it is not easy to tell how two fields of > view are related if you use have cameras that are not co-located and > you use each camera as the origin for its polar field of view. Actually, it _is_ simple: transform both to cartesian, then compare. (There are trade-offs here: I can imagine cases where all measurements are done in cartesian, and there is no benefit from any transformation into a polar system.) > And polar is *not* natural if the origin is not the camera location. Agreed. > BTW, not sure about the need for focus length in general, but if we do > need it we should account for depth of field (a range of distance, > not just a single point). Depth-of-field is pretty mushy: IMHO it's different for different renderers. But in principle, you're right. > Also, we'd need to deal with auto-focus cameras. Alas! I haven't thought of a way to deal with a camera which does that unless _it_ reports its focus-length. -- John Leslie From marshall.eubanks@gmail.com Wed Oct 12 09:21:49 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A1D21F8BA8 for ; Wed, 12 Oct 2011 09:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9CzbWas1Dbb for ; Wed, 12 Oct 2011 09:21:49 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C247121F8C58 for ; Wed, 12 Oct 2011 09:21:48 -0700 (PDT) Received: by ywm3 with SMTP id 3so210917ywm.31 for ; Wed, 12 Oct 2011 09:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SU6sYhnbMYlu69NbtvHaQrMfMwvzx3LHgH5+Jzh3uYo=; b=fydydHeZmEv/iuAvro4jI8G7RJe0MAWpxCZz919KZflitHvd+PXxAgXTAGP30wrDUw HxNZ/4tVrx9+rrrO6jT2UwLV06Of7gJY/88Ftkg6+8pr0/qYiZOAS9mU7Ac6xSCoryAg QdSG26duP+G/1Xx46Ouz4cx1bid5MOHkaXC/M= MIME-Version: 1.0 Received: by 10.150.73.39 with SMTP id v39mr1336919yba.96.1318436508251; Wed, 12 Oct 2011 09:21:48 -0700 (PDT) Received: by 10.151.98.20 with HTTP; Wed, 12 Oct 2011 09:21:48 -0700 (PDT) In-Reply-To: <20111012161433.GA30384@verdi> References: <20111012101642.GC7021@verdi> <20111012161433.GA30384@verdi> Date: Wed, 12 Oct 2011 12:21:48 -0400 Message-ID: From: Marshall Eubanks To: John Leslie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: clue@ietf.org Subject: Re: [clue] Origin and dimensions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 16:21:49 -0000 Dear John; On Wed, Oct 12, 2011 at 12:14 PM, John Leslie wrote: > Stephen Botzko wrote: >> >> Our systems use microphone arrays, the pickup pattern is not necessarily >> fixed (though we are generating a proper stereo capture). In the case of >> audio, we should not presume that an "audio capture" comes from a single >> cardiod microphone. > More importantly, it is common to hide microphone array details in firmware= , and even the direction of the maximum sensitivity can be changed automatically. We may only be able to go so far here. > =A0 Obviously, not all microphones are cardioid: at a minimum, you'd want > to distinguish a "generic cardioid" from a "generic omnidirectional". It > may make sense to have a few "generic" sensitivity patterns (which will > likely be ignored by most renderers today anyway). > > =A0 And for a microphone array, if you don't want to generate an actual > sensitivity pattern (for the array), IMHO it's reasonable to specify none= . The default should be omnidirectonal. > >> I don't favor polar for where captures are aimed, because of the origin >> problem stated yesterday. > > =A0 Mea culpa! I didn't intend to talk of a _single_ polar coordinate > system at the origin of the cartesian system -- rather a polar system > for each camera centered at the XYZ of that camera. (Where the zero > pan and tilt points is arbitrary: I didn't mean to advocate anything > specific.) > That is what makes sense and how I interpreted what you said. >> We need to easily identify adjacency of video captures even if the >> cameras are not co-located. > > =A0 Actually, this _is_ easy, so long at our definitions are crisp and > complete. > >> Polar works for individual cameras, and it also works if all the cameras >> are in the same position. But it is not easy to tell how two fields of >> view are related if you use have cameras that are not co-located and >> you use each camera as the origin for its polar field of view. > > =A0 Actually, it _is_ simple: transform both to cartesian, then compare. > (There are trade-offs here: I can imagine cases where all measurements > are done in cartesian, and there is no benefit from any transformation > into a polar system.) > >> And polar is *not* natural if the origin is not the camera location. > > =A0 Agreed. > >> BTW, not sure about the need for focus length in general, but if we do >> need it we should account for depth of field (a range of distance, >> not just a single point). > > =A0 Depth-of-field is pretty mushy: IMHO it's different for different > renderers. But in principle, you're right. > >> Also, we'd need to deal with auto-focus cameras. > > =A0 Alas! I haven't thought of a way to deal with a camera which does tha= t > unless _it_ reports its focus-length. > I am not so sure we would want to communicate constant mm level changes in focus that autofocus tends to produce. A default I think makes more sense here. Marshall > -- > John Leslie > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Thu Oct 13 16:45:04 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DD821F8B84 for ; Thu, 13 Oct 2011 16:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkNAjwG+QCz7 for ; Thu, 13 Oct 2011 16:45:03 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7279321F88A0 for ; Thu, 13 Oct 2011 16:45:03 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so665225vcb.31 for ; Thu, 13 Oct 2011 16:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=1e3TIMYwg1c5peTknYn+dYNCl4MzKIVtHD/YczRTgjI=; b=JsCortuq75ZW2CKb3LT5c95edZgQTWDOhcVHSFQkzwK1Ed/2Es1rAUShHSCvC4nuIc DLnlqy9G98nEBZBwGu/54yeiheqFhx9yEsQ2Eib5yQx4EPdOQ/b9cH6Mx2q3qMXA5HvA i6s21gZ89ylUevALpUudNI98HFup7e1qUqR4U= MIME-Version: 1.0 Received: by 10.52.36.197 with SMTP id s5mr6269912vdj.36.1318549503031; Thu, 13 Oct 2011 16:45:03 -0700 (PDT) Received: by 10.52.75.198 with HTTP; Thu, 13 Oct 2011 16:45:03 -0700 (PDT) In-Reply-To: <20111013220824.67DD821F8B95@ietfa.amsl.com> References: <20111013220824.67DD821F8B95@ietfa.amsl.com> Date: Thu, 13 Oct 2011 19:45:03 -0400 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307f3078bf398a04af36ba7e Subject: [clue] Fwd: IETF 82 - DRAFT Agenda X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 23:45:04 -0000 --20cf307f3078bf398a04af36ba7e Content-Type: text/plain; charset=ISO-8859-1 FYI...CLUE is *tentatively* scheduled for Monday morning. ---------- Forwarded message ---------- From: IETF Agenda Date: Thu, Oct 13, 2011 at 6:08 PM Subject: IETF 82 - DRAFT Agenda To: IETF Announcement list Cc: 82all@ietf.org, irsg@irtf.org The DRAFT agenda is available for viewing on the IETF 82 Meeting web page at: http://www.ietf.org/meeting/82/index.html The final agenda will be published on October 21, 2011. Only 30 days until Taipei, 82nd IETF! Online registration for the IETF meeting is at: http://www.ietf.org/meeting/register.html _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --20cf307f3078bf398a04af36ba7e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI...CLUE is *tentatively* scheduled for Monday morning.

---------- Forwarded message ----------
From: IETF Agenda <agenda@ietf.org>
Date: Thu, Oct 13, 2011 at 6:08 PM
Subject: IETF 82 - DRAFT Agenda
To= : IETF Announcement list <ietf= -announce@ietf.org>
Cc: 82all@i= etf.org, irsg@irtf.org


The DRAFT agenda is available for viewing on the IETF 82 Meeting we= b page at: http://www.ietf.org/meeting/82/index.html

The final agenda will be published on October 21, 2011.

Only 30 days until Taipei, 82nd IETF!
Online registration for the IETF meeting is at:
htt= p://www.ietf.org/meeting/register.html
_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

--20cf307f3078bf398a04af36ba7e-- From allyn@cisco.com Fri Oct 14 11:46:06 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381DE21F84D5 for ; Fri, 14 Oct 2011 11:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXPAAsI+m+Q5 for ; Fri, 14 Oct 2011 11:46:05 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 83C1221F84C9 for ; Fri, 14 Oct 2011 11:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=37202; q=dns/txt; s=iport; t=1318617965; x=1319827565; h=mime-version:subject:date:message-id:from:to; bh=fOHbB2KiJd5BwYqLP+gvGDps1OQ/bfhk2csNWPcD/YY=; b=Lo9Xb9OewvJXYiFPn3ihVuMc1FX6N+Izz2PtFrFJ9dmzfxNrkafA5G1J E8bo1ni9ht6yjQwCCTaviP+u2LcBfoSaxb5DZ2mniM98Gia8ye5nhzuZq Xxs0Wjhz5+rBanYyneYjOeVdyIvG5vtB7MFXKGWYZ24hJB/PpidQOdpVl Q=; X-Files: Interim Oct 2011 Tuesday notes.docx : 24965 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYHAHKCmE6rRDoH/2dsb2JhbABDgk2XNYc9hyiBBYFwAQQSAQkRA1sBDB4GGAcBVgEEGxqfPYEmAZ5FhxhhBIgBkSeMRA X-IronPort-AV: E=Sophos;i="4.69,348,1315180800"; d="xml'?rels'?docx'72,48?scan'72,48,208,217,72,48";a="7934679" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 14 Oct 2011 18:46:04 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9EIk4C3020650 for ; Fri, 14 Oct 2011 18:46:04 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 11:46:04 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC8AA1.86A2FD21" Date: Fri, 14 Oct 2011 11:46:03 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05E6C729@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: notes from Tuesday Oct. 11 Interim Thread-Index: AcyKUQiZGqnd8LqFSVuh2okZDUnMig== From: "Allyn Romanow (allyn)" To: X-OriginalArrivalTime: 14 Oct 2011 18:46:04.0219 (UTC) FILETIME=[86C2E8B0:01CC8AA1] Subject: [clue] notes from Tuesday Oct. 11 Interim X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 18:46:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8AA1.86A2FD21 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC8AA1.86A2FD21" ------_=_NextPart_002_01CC8AA1.86A2FD21 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Folks,=20 These will be included in the Chairs' Proceedings.. but lest you are especially eager, I'm sending them on the list. =20 Best, Allyn ------_=_NextPart_002_01CC8AA1.86A2FD21 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 Folks,

These will be included in the Chairs’ = Proceedings.. but lest you are especially eager, I’m sending them on the = list.

 

Best,

Allyn

------_=_NextPart_002_01CC8AA1.86A2FD21-- ------_=_NextPart_001_01CC8AA1.86A2FD21 Content-Type: application/octet-stream; name="Interim Oct 2011 Tuesday notes.docx" Content-Transfer-Encoding: base64 Content-Description: Interim Oct 2011 Tuesday notes.docx Content-Disposition: attachment; filename="Interim Oct 2011 Tuesday notes.docx" UEsDBBQABgAIAAAAIQAwySgMcgEAAKUFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 VMluwjAQvVfqP0S+Vomhh6qqCBy6HFuk0g8w9gSsepPHbH/fSaBR1UKQClwiJeO3+OXZg9HammwJ EbV3JesXPZaBk15pNyvZx+Qlv2cZJuGUMN5ByTaAbDS8vhpMNgEwI7TDks1TCg+co5yDFVj4AI4m lY9WJHqNMx6E/BQz4Le93h2X3iVwKU81BxsOnqASC5Oy5zV93jqJYJBlj9uFtVbJRAhGS5HIKV86 9Usl3ykUhGzW4FwHvCEbjO9VqCeHBXa4N4omagXZWMT0KizZ4CsfFVdeLiztoeim2ePTV5WW0OJr thC9BETK3JqinVih3bf/gz7cwk4hEvL8RlrqoyYwbQzg+R1sebvkKaxx9AE5leNkfajrp0Dl9D8C xKSh7c/B/BFSovQvsfkdc9f2myomOnTAm2f/5AwamqOSFZ3LiZgaOFnvT/1b6qMmVjB9v1j6P8i7 jLT9kz7+I4zvO6tG72kdby7Z4RcAAAD//wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgC X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2j ILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyM Maui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03 Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1 nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQCzvosdCQEAALYD AAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKyTz0rEMBDG74LvEOZu0666iGy6FxH2qvUB0nb6B5ukJLNq396hsNsuLvXS S2C+kO/7zTDZ7X9MJ77Qh9ZZBUkUg0BbuLK1tYKP7PXuCUQgbUvdOYsKBgywT29vdm/YaeJHoWn7 INjFBgUNUf8sZSgaNDpErkfLN5XzRhOXvpa9Lj51jXITx1vp5x6QXniKQ6nAH8p7ENnQc/L/3q6q 2gJfXHE0aOlKhAxIxJ0F9tS+RlJwUiLmBHkdYbMqAg0dz3ACGOul+GTNeHs0OXqewURwlpYgtmtC EK8HTgBjKcczWWJ4XJOhcpYynXczjrO0BPGwJsQ35u9/VnImnkDkxW9LfwEAAP//AwBQSwMEFAAG AAgAAAAhAOy+kMV3NgAAEjsBABEAAAB3b3JkL2RvY3VtZW50LnhtbOydy3LbSNbn9xMx74DwqjtG lGXJt3J00aGL3eWZungsV3u2EAmJaJMAGwClYq3qHWY2E9Hfdh6snmR+/5OZICGTNOUSRZQ/RVSU bYkEMk+e6/9c8m8vfxkNo8ukKNM8+/bBo929B1GS9fJ+ml18++Dn9687zx9EZRVn/XiYZ8m3D6ZJ +eBl97/+l79dvejnvckoyaqIR2Tli0t+O6iq8YuHD8veIBnF5W4+TjJ+eZ4Xo7jin8XFw1FcfJyM O718NI6r9CwdptX04f7e3tMH/jH5tw8mRfbCP6IzSntFXubnlb7yIj8/T3uJ/yN8o1jnve6bJ37J 9saHRTJkDXlWDtJxGZ42+tKnscVBeMjlqk1cjobhc1fjdd7WL+IrzmM0dMu+yov+uMh7SVny0xP3 y/qJj/ZWvdsTUI+ov7HOEprvDCsZxWlWP0bcce3868Pb5fAeunc/1KNmG4EWXXjpLO9P9ec4unoB L/bffftgb+/x8dNnj549CD96y0Hv7e09ebx/eFD/8CQ5jyfD6tOPv537kT35baE/CvfH2cPu3x76 f/Hn2P9y4auWfO3qRdX9Ma+SMjov8lH0JquSIh3pqZV7tn1vxZd3oveTpOzH0+inXrUbPXrU+K5W pS+vosjam7etV93Dntg9elMlozKSJCb96PDNjV/bwoMIlIybB7ARIlZVkvUTzr2jQy/y/sTIWka/ //a/o9MqGQ/iLPqQZBdJsRP993yQRd8n5TBNdqLoB2genUx6HxGCarATvcuzNHp1GWc7+tU0OoqL LCl3orfwdPQ/dqK/59mvKF49JkO96HO84DKJjvLq14/8/BQN20uK6CS++phmfPMw60+jt8l4nKDd hjvRUZGymqN4iEbn89/F/SJNeHY8HuppR/xsdzcqkyRCzcLBXwMzSCo5gOHwa9jM4QXcFu/YEcFF /aS88a7WUhMoxNXKpoVS/3OZRMdxuSmS1ArcFD1+UT65GERFcpkmV5s5BHtj0wg9PTzYf3JkRnKB 7ZKxuabBsWpLn1B1X0SmdBrL5xt6sTlyL8px3MOSj4ukTIrL5EE3ijqdk7iKo14+HMZneWE+kym7 q0FcRT30Sz+PcpzI6N37t1FaRvnHXfTZ9CyJ4n4/KvNRUg1wVaIqj6rkF/eVCWcXZ1P7yjieDvO4 vxudoof00N9/+79lNIjRYpm+l2Z87PjDq6MI61XGo4QnjdPebmMXm9D1ppQ70Yc8Y0UVMpj1Iy28 J6bTdsaTs2HacxQ5S3qxfnmVRKP0YlBFVzHOMR9qEGHja/Y2w1kjLRj38bwqo5j/orNJ1h+KxkkG I8f96QaX0+TC/SfPnh8+X8XH75J/TdIiUUjRWFVgz25T84Ufx8GXM6/r1n2md6KSThFudqKf9BvL 2wTffZdfIW4jhJCDKlMMfj+H4dIqyhJ8NlvNy+hEP8vy2Q/x6cbRWdz7GOEjFFMndAhPNUiQwuFE 3t+N1+70vldD4UzXMilmUW7udq+j8VBjxtZRPKkGebGQM5aoy50om4zOcI/6SMNwmFTNL9/qcfq4 YnxaTSV1Ly7j4bcPvk/L6m1cxBdFPB48MLvLihyd0uHlMHxur/7dm3742YF+xhL9F7RYT2DT4N0f E4WFciW93oFna6mKCMSjybiPukKpEkLiJFYpPLQbvYdD8P5GaLZxbFG5fo4q51NnQ4L5Ku1FA4i2 Gx2i0uEsfpvxjrnHl7uR+FZcWg7yyRD6smeiPSgttjWF6X6kwCOfNMV8K4RP0Y9XL4bJORHkwVOj eKDpVtZzW4wgMOVTU87R6eRjnV+BYUjRtQJ+dqMf7XxGeYGmScveBGgBU8t/Uh1DGNad7YKj3Y3Q 26MqaugV2LLI8/NXhVyRajrGoSjHOOSnVVxUjq19SProbK0vvsr6819bvD3ThVpwYeaXCKeXGM+n LH+t12x4fQgNDtSkiiQUBUfRWNStMpwn7wd5aGY7+sm4GkSjBG9NFgFZx087j9JRfJGULze3kDtX gT8AB6Ud+ei///Z/ZoqITaOrRjhCKMGrwVTKDXb21jFgmai3YZmHn+LNdczV241M7cXz6s44S4oQ CVAYf5UOh84obY6Yq/z0Q2TXmH+m8IGm2Kx+eBaXKPDzSWZQRSzUVXSItVn9/i/jHJFH0/81ivDQ nVooXzal5vYZdBiX1Tt8VFnjtzDiET7pR7OIVffU2RB500JNFEU0yI8/K99HO0xHo6SfxkT9aJle CkZsHvkuIEAwReGAIyJovgmWUkUxFNPXQYGTYoPBxEIR+DE/JdJCB3iL3rDji/XbexlgW/V+JKVq Ajyq2b1jJwkMhGZPyl6RnmFlPX/XQQsMzu85cp4kdSQGOFCscLJrX5+z5xbZFck5HwVjst8G8tZB EIIxkzc9UEcSRxd5zkvkT4SgCFEbQHdb7RhfSIqIzSM8m5OWm9O9C8OYhx1DwvM0Sw0vRU3OqAxT KazbhzqjpGBLwzyH5ljVypFI4Wl+9s8ETLdVWzvonKAAgB2J07FB2HyOKs16w4k5aPlVK5Z7qzrm 8wxQe9JXL/6g671YZGdKTCBAQHEN3pBhcSgK/OTABAQmzgh/h9NI9gt8JLfjQkOOc9xtPv7vcQoW 8R/tEpvFezewW5h4UD7Rwe4Bgp9Zzi0qr9KqZ7DQJToZlAS9VP8SOkziITGwAPZha3aLN2vZqUZM bKCdi8LOXHTmI09BcwSq4dQb2iCgF4tJF3m+EdMQZMEENREtVgNxK4QKzGtry0KZYt+tX+mcEoOt eAzpuqE0lfPnG8u5Y7HT60SxdV7raL3//NHx87tJ+/lXrTjW1wVKnsj2Y4OG/kgXww5LzvmkDrYa j1qHLpuEYD5PAhPuOpPVWPyX0GEsuDmrHJCKvb3+wKbgfXZ5S6j9Izr1tJqcE/ZIgoBFr79n+aEv eaQyZ5tMy9iC9L+q+4NF50mFFOPYgdNXKSoyzXBhhc8QrLvg0nxhATnVBKo2dnirfOVDTIEKejtr MVTe8qD/ODzZQZvjlOO4TwrcxzIZ4hLxuR1DNvPS+VbS+jNLEA8vXBrV/Yht6vdCQsPnByBMqLKz hCxsUfu5So/Z4+WH8Yzd6CiprhJA7ldvnWFJ+8K9z/JfbkyPhq4PfLhJ4fss/rmYFV2mt7G9PyCJ n5HAz66xSzgaG+nfmueCTB87jmyscCMMSSR7kcE1oCwpaXN4b0pqe2SQKGnufLSD1ICHKPDEqWJp SkQ5f95zC0VH4wEFT5GBSHJLNugdr4rq/9f1g1gXWLPtN2i9DJS7hq11d6lXOCeYAdwVjrYT/UqM Y1I34N870VQFLy6zpVxD4x2bOM9jC7Q8qGf6wP1AqO1u9NrWQuTZG+ZkLLVsuUvuNDe+tg8hkNY7 c+iVZi99zUUZT4Uwma+v36Yj4l5xUlI4/3+QU8sGKzqAzmUYUeT8fuPL/pHMpYml7KDDCuQYjkFn DVTQeiUokNLjJGlBPUlCpQr8cAaCqcjEvkJOjD1ppxtf9RsHR2NUSJ0gxMkvsWiKkwuyeU5ZS1+y bJHTo51ob2dPgMRZXlVsxEHCVNDInFBks3kamwJkPd4QO3AguRAHzHFo+PXG7fQSo5HAsabzUIYG hiVxbyAyigUO/pDyaW5pTe2zeJnRL6gdFNGmWWzx2w1Eh5VMinG35D3q72VCfNoHCmosa9lGP80t mIq+TSoRaJ9TOIZD+NJScQZJs9KpMnH8sr9BnH+VEfNFcR0VGk+1EFZpFSJ1iQQQYx/lDXIYj3dQ SbLNUi84tVP8x4hSkFBnAeTYoPc6JuePxZCrtvZD/BHVXonAMfC5mR/ql3dwQzGa2oIQ5t6EUpqd 6CJRKUwBEo8OKpw7LB0VwHfF9vyT/wSjZkQrfHeS6eRAU3uDLB/mF9NNoSGGu//hctPbecpc2KPk ioO24Q05/ubXS/48Akv9Ynpu+QE5bFasjtqf+1yN1Zqx9SkhwbaGU+9GxxMOA63s3MRS1Uyye1vy +JwfL9wsycRSpSRAfHWRhHQV2L3ZPPJRk6GqTEcUEYtlPB7E8pWWurGYrB3V+NDPClD0LiQWk9xP Iv7fk3QPpy/JpCEB9eolIOQbeoiCXHL+rm2FEqkzCguOcCuQmrljcD7R/KYifBDKV+Wy25N6042f UvfNuS11EAO4UQUnUUYcdTSEnRZZiGXcWnvKKbkwvEg8qCEl0PzeLjW/xKbSDPv4WRBJfsLcgynk vZp74ub3aDkNeMyxHMcplKH29Gq+IpG+aaZabIKPdOwo1V4lWLhMf4VfyNXoTBzhwUOp5SHzlV9l kUACa+5AeNhUY8nrm+fj739+JU99ra9fC6IW7yLqDfCwZedwG8DzEyvBcfU2m2fkxWuy3LW0jTPB LE4Fnd4eW4GnZFSICuIpkqgkSIg9dkq+kJhYyvgsKavoX5wOqeU7UD0BVO9gH1PCD5O74iytChU/ sabR6KXtBL2TEB/cgcNvtjvEJOhEABBqufKCsGQEc1Jsw4E3uWkd3+WmSjl4q/nYo3JiNjtI1kRe hfKvvEA9fxioeguFO40+ZtJBpsh1pi+jcZJbYMVHSlmdirIxlzDUUc/99qpIha/Qn3XFCWBK4xDH Oreofh+1vV5VBsVm+rR+Z20ZhpsXBGV5vRcAd5yj6TraAYXOMkvzgKqd4ojS5v4Olqf0LC+kGtXv 6hPKSnUfthmX9tb3d6J/ThAHmeQ5o9dQJJs4eucqzSWkBdgEoQwo2J3rne7bSYGHCz5yHv1kEIml PaU4xq7K3Dz9uyqJ6nQ2eA4BH3YBx5PnT5/TwLY8qdCd5X9EneM5oFtS2wTGG8sO+UPQundxCnH/ RS+ZBD7EDq4ONEW6keCKyAQZbzxhAwy42MIc5fmQag9XjLQA2E/6u9EbRKvC+7AOCxgDyXlJG5Np IZOtcnJBnVqFhbciRTM9japSQvHLZKpnNe39BrbZNZupcpYZ0Z3P59WZGUTxdk7NrMvBXpCu3Q75 g6U0obOwKaecZywQypesNBJGij7DIdGxxr84GH3NIWiQWV9+GdFFaDCmHYc9Sv68zDCBbZJeOq9X iGLamwxjuRWWkNq1snVnJSBX9tGtI7xSL5y97Yq4BgculDOxFI73tC4cCEFeyHXhE2pPWjPAYAqz EIHg0ZhTCGiD51LltLHoE/303CqbjA7CcxQx+RSFi65mn3ApLC3Mo6FhtazmjRFIkWcA+miugAra hE998bbwhR2ruuPXIpb7oQh1fSMOvrG6TWMp58yKFHTYQPvNcNLthe6hmO3TqgiJo69Yb+rK46f7 z5+8XqUrTerMYvhEcYMKX5LrAl0axf9E3aRlifpsPO929UZzr4d7Tw+PVvbCBEZEnuLGsub0/nsJ pXzMspfAfnCZCyEbn7/dbbhE9LF0ABg62VmrZharz2MzIxAbfMzStRnpt0FATT9QYE5WzVS1wk4L 0UzHz3teVpfKliQ7STyS87XxfTWSOS4/glEOWZ1jjxK5vhO5dj3MGrV0TnlsenWLbavpu6vQbOEL L69rTXP+A9qy8ZreJW2EDTMkzRYCBUvkO52pNY4JM8Uyjuxynxk8AYDi8KJyMh7TOo3lv6DkAUDG 9fKgun/KcHVCd5QCGnuKKU59ri4g4EQdR1r1pgtrA3rjvj57ufHAHQSzptnoJqfMoWDWBtUSrFJ7 kG24Ll2uWi5IlEyezA3yJxROuDloUgbSnvXzYhcFYdXVLqofCazG1giCSH6h+ye1yl7QU1FeL9w0 F3cFGc4b/7nIOERUZ4LZvNO4wfXcVCUfFr1BYzlfYHEIlkGwCnT29SfdcDWLtQG+cT9pdr0He7Hk CwJ+GkvZgL1Y/OrXaUGEvB968Ii9Dy8Ktf8qmRtD65Blo3LfMs64obOgfcbEQ2aQYIluvAkXoT3+ Zu/5s9d3Mk3Ev2pFMHj4xnz0RmOjftLY2xdwHYYqLtLzaZNIPKjJdJ9d4OKDvJ1COrBd8mDopWub xWVfo49scc2lxWlfiOAufuISClCgprT+5j2Un8zPw1eVX5QRGNVBzLUIwmA7gxDkGypoCj6iHJcs dIluHM3vHmoeibSMxXql6vFSbwB8tjok0+c7d5TR+gjCDNIGtEHYU8XDj97bTH0FCvpg5kaoUJoi Lr0EiwlqOf+0BkttQMF1f3CFjhXe+CjA47i/oj/xcsmUrKLc0dYtoqMihSoqsmAYbsgC2s5/FNdY ZYh3T0yRb/x0FrOzeSM6suBN9dUKo5YdlXOGDdnufCoAP2PTNF68VHFXR6CzA2ANdI0n/ZRxFAWF QLQVgNPasYgv+BnYhFUFXiASnId9wc2ZsDCkT2Upp4M3qRyNPtELvrVLIugZ5p3q8Da/627wmkGm ZR1NfiTB4BvmKqoAjiX5rMOOA1RDHXUQNI4MiRd2hmSQM6awa0us1YQ7FZcYhhS7xBKuqve4T+uR IcUksxEgyjxtnt6Lucy75xQ6iylOT96qUA5Jb/D8+nnF929x3tf67qu1up4lqhbiUTtI09+kgk0M XnKxEpzuPCsOf5CTjCL+rhu81QBMpkeqx5eQo7ZQu9ogiR04h5Kd0n7VWPEmtOiPfrSFVze+0tv/ a9aUatbEpOHGK3I+3+tHe8+eHd6Jz+df9QU+X+2zLSPDjTe/dh7x811zOn0P4i3d2orW3sVS5pIf KKkQ2l6Xr1VlWMYUJqeWrZ4lCUJrhNlZU/dS39b1boiZZVw2nDVYn6C3Klbrv3Z1kOiMrOHQeJ3x 9WNZz0OvuiC3+MlKBDbn5yxTnOspPztJmpq/dFWjtE/dyPW+kD+2JofHDVPAFnSux6KEZZIZDvxo +KZyFYyJ8pU+oTnXU8n8DLe9Nsh6K1mT0qwGbZad26e1t6lRdq0vr8mI5ZcuZTOCQSAxYqKjSqaE fxIQEVEpDDGO03QeipGYUQnUyLgHwm+CFcOI5fA6hE6qFHkfJPHl9CqxmSojTRfiSyOqUWngL6nC d9xuny1rt81NkplmMSNg6TdFEugIwxP5kTouedDK81rnDRGeFfpaQpc1myNjsmL872TBWsXoalVN BUixD5zYlIu4+HjQLPLP8Y836N6ur1VbKTFmI+dbUwi/ma33Fk3FJFqqdE7fHe9Ex/Z/BRoUdVLU VQEhNGRlS3vb0muDfTQ0o2PDkpALV58NL19Y82Pfc7sEI0uobxfLW3mcj85awZRhK4t9MHIJJlze BbPsm2XbccukIR4iXg0+WF/hbkbLIfoUfGs4GQYVzca/aRWgrJKxt8QvmN9Z7QAtga4EQeBYYxfb ZqsT7wGYEmXNXjNLV1L/QOGgdCFJHu0u/BK59TrdeKyp5tuwu20T1cJJoTlGMSTSdRafM3LI0VCQ kKxe6YpEjOj87J52VffYUC/1tjO03SaVzUHNta115neDqPf6tjaote5730CjKI9yCNfX4Xwf7ySY M7GDRCFN/Df/QXQU/ohHQuZcj515Nf5n4Q8Hdrx6/HR//8kXgx3jxuTKxswqSH6D8h6/jqVwgWal WBDfyH65PIBXeSg/tH2oA2zDMdRcdxKuwoChmLEW6kJ8g6ArJWFYvDHbpqdFrC8029bQNdWUaDD8 vWdTpCWSiCcTKgMcXI8TJc/jYOzzMILFRS40QFE2IIe1rjhvA4Nsm8LvfM+2HCECLceIsnn8+4fj n8FNyjLvmasUh/yO95EsDx++c0/Lqvu4QQREv5k9Pz44OHx2Ml+/iPdWHQ41isIP/qV4iQicwXzj yg/98xq06lYLS0uWlFI5sTBtmX+MNzjCu7Wq5Ga25/GzZ88f788fzfU5XfX1IWAhRZZ/wZTszaHr VfdnjWxG7QG80L3TYMMtKZgtvfYTofvsyS4Oc3XZSjlQr2mDmN6cL3BrNH6p4RxqmOIwd2NGyxeK yj6ZNmONcehf973eBqv/1xdTv8MleuVU14u4AqwDiorJN+tGmQP21rG9Wm7Gyia5Z+YXXB3wunJK 6UulljtXV0niMBT8qzEPFMQ8crU/lIIQAOg0JMUCrwVUu4eZxGr/0/fymIo3RFTNJhAvvkZ1mqyz Uh0OkY3tcN3IDZ7ekqRu6bWBv7sfrLB8nFvjSS2argXJCOpnB1BpCIycJPdx//ILYD6o62VWanUu mM3VvLt6U5hQlXslVceueBP/pJ9ORu5fjtDCEeR0yrXnerd7ONkm+pG+giAB2HNUe0ljVXRGJdlH h00EBXsv1RXgjieW7lpk/pOGKBgriqlsFJRNa+eGDwJBF4VfuSEB4j1XEwigCg86KzTrF7uwKuIN jse5uY3u/uQspSAFN9cnV4sDG7GMsuuYIExmiLYl7uZGT6DU2sAutTaGzwHnrdSrLjdCYYDruBFo M+ViHQp1ISfTEvqbbNxf/1C2a89uXEuDQnYqmFkOkgWwEd8I0q9195ynph5/Nfi3imlOU3pD4mLI 3C9QnzBiNKRwDMpQSYWsiYm0yhrbsIHtskpVq41QIWrYdfCEij4evTiCdNloQpOFopRjDSUpuSfy nnxLIqPr0U7HXbClrl/zzBnwofmyTKK6JyGDinUlheaH1E62smwunoyM42Z9C4wBriwRVxSqRtlw G8WfReEvYUONPKqL8l0Vr7+ZgiFS4XKHew5cQj28R6aEcr9upTFl1jWmqqNO9L0HcgKG4UMWw8n5 Tp9LCW1yNT6MZvUxQMU4FqbWDxr0Xr8e4jy/XOubr1wN+DpWxbe0ObQzoNMbACbXWcsGXlu7k6cu HeQdm7i+1iic33gw5bajmOFLQHyNebYNim9pG1t6bU29Q+uZmbnczKmzi9IUFgXvqmAsrCa1154B bO8Gttfk9Lr9nqJV127rVhcGUC/VErpZ0sWXTDKt253PEgaSUIhpM0TCBC2NjrJWBpU1CgdQBdM9 SZcocMbIGgEZGoPnr1QvdaWuRZA7eo2ANkyR8JeYQSNeNAyUbvpwNYp3SO69NIHMh0x+yxoTjLgd hmvh5pASo6YwPUAWN+FG6L9N2L5n0iVM6sgqbUBeJEac1a2rKYUgGX42bcg+GSDi6hNtVp/Kkfxg YDd6k3/D5pNSs0bruJ2eLF2ivck5Huu7ybVVOdW1Z5RMWROrgsq+3Z9mXZdK+FBClagET0a7bj+2 WEB2J0ypuOeqqvtdzCxTZtyKhSR56LrmfBLa+DSKlt8J/2AEJxILIEowT7G9ldFY52tp06T1dQ30 1PBgMz32jbo9WtMfJeC6lJSnyq/laX3dxhUP8aLscUyD5WYytQBvdP7r+ly3bRdq1pVrh6B5O6Q/ faWxaFiPnfEOFfOoHaJvk8gkHuU0g/FVuBw+QqeyABmNQZgrQ+QUvyMna+msmD9NP9c1zRxcSS4F l85/hMMD6zN9wV/BjTl0bKSEc0h8PVHvRvP1inI0RapV1endhoo03FvXbbn8XXDvO1xqailpd9HR 3K1nM6/LKqr3671rNM4iAoSL9kSa8Pg26KKgXheXMVDBBdP1AEA1aosB4boPXlm4QQojOcAFSErc BpJufGlNPDpyXZ5C+s4Gdfmx8zWDzMg387Da4TOtpsf3gcNN0c1PkECP7eMOYpx0rzXMHllHmMtQ +tRR47zXj+OVcdoxiq/1AB/Or94Il9vXcQO6mK5uWkzs6gAbbTy7RoBpx1kJ047ugwY82r/n2a/x MJ9VTbjxdL+SGBDz+4hVk481xtFG150D/QwRhuyiGrQr+xc04BwruI5Smf1YBtz656Te61rY2uKH llIpzeiKi9e9p8VXxa8NTt2SMd3Sa4PgdeeYQMG3q822u4NEJLVGimdUIyYSqwmnFfyxbbLZVS5Q 62jXxKx2dOL+P7n5IevhTsZ+vk/JRYtpjxFzTNbGGXEuqpvOIgtkTuo9J5Iu0fXm8vYp/ID3QNrs JnbRrL5DQhWG7n4IwDpcGLzE8yFXlFBdN4ueLDdgHrtVCJjXZ+4+4btrhEL2LSxIokfz5tC7ri4I tUuDTHE0HcXgp94fGdiJYajOK+eY6Ked+dmK2Rgv5CrQ+KUFa3udb76ZtSZgfMp8yKAWP7JS8yfU roY3azT3t4TV84G5L6RUYxL3fbbKTV/slkYfNMKvhkADcqwmqpmxxS+Nwg0F7fAtt6xZF9Oy9gJq XjubpPTuM6OnKiaaJekRZcX4RH5EfI6HYjc2VXaLwFKFd37YhCBnPohR46uoEIpHzfx5SNrSi6rb vRfzJQCfOug7CrPqEL45dss1JHlyWj0aAbob3qVDMnXgQw6ZwXqc/a5hY34EvhA+76LOowFWNi1/ pHE66wcro95krW+uF6Vocw6WJEmq25R3o3dMCyBdaml8LIwfsY6sN157x6KGz3eDTsVHh0+eHD9Z 1S2yqFOxsT/vZC54K8D7YkE3ByDM6RQGhFxee+Z6g3YWv/TORmH6/kyi7Mbq1zlxl7725N9A+nol G6yzwA3mtBczRcAZjTlmkICBWsGzEK4RbjIICA41Xu4zCg65jE0XD8qdRO+jgepRaiFf7rRRUaNk v//2/5q8d6vEcWO8up1N3sNyu1CyY8yj18+ePmlBJ/XTbx4dPVrVzbaYl+Sy2kSShlx+gabqME+w yR48JIirI9Vnl9j9kbstzVGW/ajxiwWjhG+V9dZnC0+XqnvKDIT2dGzXy1J04YsOdak9uK8Xb38H qQsdFqV2GMJGwayF4Q1O2DahT+okU3OUiUVElFwVcUcVvuT73RXKdXDUhl1sm3iaNBQPL7jfTSOy UPMkiUneMdirVYNuYvXdqvYA9J1O1qKf/upAtgvqZarBffk2pLk+C4gilrive9eVumN4r12uZDPU COhUfKyMlmXIHLTmhrLcC8USPxs1w31/JVdRkzbLGU2X6Q4Xqz32F+Qxc2SiYm7pVU9uMeloVtTs 8o0ztO08vVAcrhy6S72B4g3zCWk5IHqmAAhEVqj3yS99aU2secKha9amM8/QIz89kkssubP+Ykqq QvffxmFsAw8V2OKKynyJ3pajLelChVvb1olHauqsU+GzGgZ3CqHSkaOqq8OahofEO0XV17/n2IZv uQ+3Co5zOY2At/2l/Kub9yy8ILBjGBmG3rC0kPQHHGp5DowIN6D5efVWNHJ983N8DWYkCCnoI+gB k5NpljYCseiM0l9ANe/V0BI19D6+cPklN50znJm8YTegHRTJ5th7sYfyqpzSUbpqCBBnpQwEF9fD 392segOYmAJe6S5IYCppFxv4QredbuFUpcCMf5ue/LZl9tQN9MR78To1zBsNvZve0dmN3rpLiClt iKeqflDFgzwgriyU7zOhUFHthWzY/7YNrFi77+8Hhd10STTOhX6asEp14Cwwb9VaTxMyTyoMpcRJ 5FdGiSmyRBwGIZf1zFczQvUoJ5xQalOINfov7cZHVTKG3hV+R6qwmI6ZavIyeg90SKJQ0yF8zVl9 6QKFb8m9EsErrPMAHl+D+tyIIgNn9v84x5HhvtSCH1koqHI/FQpQdNk/i3sfb8xRLpDfP9zfO3i2 /elxfh03nh6na2EIjA2cVs60VdPjtq1sbRSwqzIN9+hJxq9l6P2QZUpNnQmSgYek/HFjntogftpt 12pq4Bai+SmUKrSlGkcii1EOGt9pQdByCxDmffz7iq5lqZKauOLdUBpteHc9OAB6ylU6PC7dBY9L suqGomGX/Mf/cdyxr/lj8BONnDzoCXqkFfz+45gYy49FcUPTBcfp12XC/EFCOY/HveRybplJfoep 17wjuoNIuurAPxW1Hd0WLVSUQtcr5WttU7CQFXHM7loNTrz9xq3I1ba1I2sbvJwVOLROznVGzMJX bqE01zWmVPMfx1an1q79aLasq8YPV1hKoHc1SHEWBlkwCQ9MfWOuixeF06A0NVJWA4eMpVrh14Sz 6v6EWq+xJTsU24SttBWqKKx0MVcJpg96wbXVKB9t4RFzUYqp1G4IpZxucBr4Goetn0k/vFSKvmEC l315vWR6WL0a2iqOgkZCu5wVtpFiGYLmNt62Je9hS68Np989YrB7Rj/VSTp/SYV8PDf/nZtvBewB 4lmpu2lQfnvOjG8FhlWh299VOXt+Y2o6l/jVwcHR/uM7d4m3TPfFUudKYayBFd/aurLdzSEEeMQj 4ls7Dazlm3ocCadRw5euzU3IBnhRdDbV7c+uud7AD57h9KcDta8J65ZIcsevhfNvULziufOGgZKD klQZJgybIP/GsrEB1/6O6azXOUK7AoXFHP82nrjOvLjESXMuWUL5hSvGn1ViOKfRwHpc0DaQM2jQ xfuqy7qD/ymvFSFmj9FZGrdkD61kiSPXcOLnm8URtpuWEru1o4Z1/xPrr/XkqvZ+lCdTqUrHRUBO wg6P95g4e/xI/9v3xVCyLlMXMcjOWLF7gCfb1Ru9WOLmA0P2Z9Cq3U+oSJO5MsnwnAmHVa9d2qN7 hIGA3r6OlYhWY5Rpn/Jzgw+PDxRD+9Q0pp6Q50ydwzqjgzbpwe4rEqcWmXvmwdmwIbrKqMRkE0KT LeG3nUYbFt9KBVjbRCJ4DZNh9A5XL4XGE8sL2pzTUctY+TUnHe5cnN2Je3/MS1KWtYp2kDFQiPN/ dqOf69kWhtoI2SL/YH58g5rLAmTrxdWNCMFH6Zb5JOuX5OibsO6yB6wXYdNFO7hvbLD6q/lOWbTg NBIqxRRQO7PJWFXCuubaTT7LdRV04yC3pIa29NqaK/9EJcu3GI/ddgD6g10hKkBOiuRQU4jawFzh lBd7aye+xp5hUvgJripBW6imYwrFkuqKuxKaYd4yXfWpskPSBFk2iLDs2+tpOru0DSG2qwHkUa/1 7E9Xdvz9z69ueWm///bv8eQMNJNyDRZWTs6YU5GeJb//9h+7kUBoQDoKktyV86I11NkhI8DftJp2 uRCLeeWDG9KCZ1xQJMbteb869zegA+Ih0gFykhsHxQ/9sPe055rI2nNsulIzL4lrWaQClLheaWON 62joTcOoWkMb6g8tvT5r2nHDG5ijhNr7N55NfKZxa2lSwvn+DmXsrCKSMLVHQ5f04UB7PnhjYt+i HWgLXb3vojCz9kEj1bhcUVBeuhxblRp1Sbm7yQ76YKhYtP520VgeDqwM+twGsgb7Q218MiZbDAAi QNZSojNEaWJXQTVtxTpCtwE+qBccAoMOc9pR3VUKbRX1KeSPL6m2tnFUJdMhNHygUd8Oumj9aW5b rmneFUOjavxe25UnfatKbRZXckso7dZ2HFExGWryEtAIPNWK9W6JJ7b02sCKi+2xczg5INd+PR7j qkkvUEl/rcd2S8vf0mtXU83Ml1w0r498RynZaAoPfeZDEl5ywWFM9aG7S5k2rawc5wUgYU5nOwNE bUTJ1KY/SmNbHRnhJfeA8CmVzVARIUfI1EXdCdguP0/ll9NQPCjXjYjZjUbTjWnOIwr7bYMtuWOG gpFWpihXZCO/p6xBh/86XOdKprhBQZ7d7C09OTp4/OR4VXu+Jq42LaTn9AWrXN6PD3btQcEOyAh8 bkfdWNudkzmbjByh0+El081fXMbDbx/sOeSM372hG8j97JF+xvL8F7TQ+dxm962G2D8E9IlF/NAL 04msuuLr2ONiW/B9PJWZFvKATH9sBsZ/3vM8zScFYSVJI39TQaeuhvo6TrN7WDEFka4Wr20Dy4JZ ltFfGPqH/fGlhOpxiYewNv3uClVHST8lT+WuNf6rHb2Ga8h2DVKa84reYOoyPq63ztWx+FrE2Vs7 kSzi10HNxbJxkjgoxkIoqMj126lNGNqhPxJy+SpWS1Litw/jC5sslIR7peVeqeUDy64jwHWgmkd0 5l/bpVvKWq5eaOTptw8OnprCvK4SF5NEIeaFdVGV8hbx+9mP/egv6W6U7O40N7YMtfsUWWPCLyFo gyrLvrwe5DdKNLMwLUfG8+WYGmNWO7uVtrRk8l/duCGHRXC/62yKVGfm5ynsvKLjR+ENo6MYY64t RxTdeVewsew/r9I8Dn1iLtNbj2BXOdo5Ad0ACcBYfCW7fefrzq0QWU1nsoEhdP9K9gjKkTLR2FfX W8d2RyM9v5LtuQshH84J9VeysVN/N9ilYnS7YDp4aKXKSwQaYfdlsZ0xBxHtT3oYpNBQaF3y/fxh 3QBivgDmTFdYb3Vua+2DX734o057fa2aLvsSgLntUb63uDdVbkkhpZl8BvkOaF7+uk0GDy7CHVu4 8NoAz3TfFqnGo0yjy9zy86KTHFtrEbISK1yTHd/tHD35z4w/1jR7dMDF9eQNdxh0Ox5OyuC6WG/I Esjqz8JrLoF29PzxN6+/ufM+hE/wGL+OFRiPgWfv3h9/eHXUuNrixvR2G/cAUECFbjGzgYpeHihs TwuEnbrtHz5+/HjvcBX+9RPq4BOvJ0jG4jjHdO8sVxnMKiBRQuKXwIdgwEyqcvA3PrdbPKKgHNc5 jQa9AhFvcS2QdCXsGV7ZWMcKOWGkhcuxS7mL0ERhVeQEZ5s0v4GZ3/8M7viKyRxUmlntg9KvXG1F 5TBJAeuMJGvL2CUZf43wcOPL1DaJD1d/y+iij3iF0s9tMEpfnn9CnUiZkE8wdtVcEMDNPlAndTrK VOgWHItlvxZqgv9OLA0pMtpuIepDBXf0m9a5FNH3zIYh9TU8Cnnufx0EWKzLjEPqMSTGSRqu0tjy MqzlU6AGNlvrm+uhNDKBurFHt9CQCaNFjhoPOzjAm75l0VzU6hpGyk7j3esovVvVbwvzDZZbMJ0w yzd8Tu5D6PKLnzZF1jC7QNaLCoSJekDI8ZXs9CcA5zApbm53zXzUHR9kMJrBBwglJm52ksmL5ivN 3TQTHIBZG/L2zVDYxbaJF+7n6zgb7dMFLh1cm6naOoVRAYUbjM6Qo1mRH2BsPxluk/EDTWecAZov e9mPdXela+H1mAspgI4J7Gx+tOuhbxdvH+nSUvR9ORlbHYLrxHRtxBqd1ipyn4jMAu4zhjpavdcw zz/OJnozx9vf1+AZys1BS3ut2sX7YwrpVEzzMy6dnFc/ka5Ni1zsK/zIeCw5m3hPhhpvc8W3G04M 47J6hzAn3Eb9Fu/wiIToRz9991iHJSnPm0MQvBZYENUsL5OoCzcapONJN4x+Fp9P9ObTYo471v8r j6VNa1l5et3rhQ8nEwpmqcAaNM7tjvcTzM+WXuspxjhqsI2ekpzcSuSSgQywiJuVAwqpXBTlJo/r zqZjMt580mb+8NdXVk/MX5gItDtX0mQZc40AiqOjPB8mccZ1T4wr0d29DILiC0yu5AtozgHQfh2u 1S9qwxnVxDomI4PWjCdV3mnnCq10USi50ZxaQ7uD25eHpO1yV2yKmOuVLTX+S/Zfqhkz+tIGEOfn THGPAqEZbxraSEjwu0yn89JKKhGFdwjpID8mh6fQlDJKLF3qTJGwjUUFUamnSnOFLuzG19wLeLPV dKiUw01PJcvgR6vu6n46zdMpt5phWKmP+WXT7jw6evzs8Sq0dLHd8Tf8wOODvCivYwc2IGSxlexq 4iR+M8JuXBjGdd5Ygh1o6Jcf9nSrwf2CDbRFH4eyBIOlXTitgkVLeHJ1rzoJ5hk2TI6rJUP33VC2 wjXqlL2EWLbmeQSBxDCItrUkMObbNPOQqg/kgLpka2AXQEM/gp9y7QfTBSkM1WR0rBFoBOMRxdyn rGtm/X3UNz7zWzzecJK11v5OV8arK0O6plUre9NQPmFgF3cjEhH5i6x13tRt+i5lQZmt2sEPWHSG oyqWCLrVM6CrQLRxEprr36pVQ3dNLvQ8jXMCqC4ih4makpcd+wnWgLxppRFrI7YK+WnaodlHfo3d 9KZ735hvii/jctKYILubXFUbigd5bJu2vljn6+o63dggA+pnttrY/MiP22xZS0JoRPItSCJzxqVK ptNkgdByRHmuj1aeqiml6OA5lxEyXnCC08DVkJrTIBxaE72DgHHsKniXE8Kn23BuWw4PFrPLKW1E KkGyaoyCi4m8a2/1dQ2qrZ9sSADcm+7psu9eSzd0cc7k5eHLYX7GOrs0y/JL8xBfRoi6ihqRTzG3 Rkl6YElnbnYx1JL0c+axW8WuJkLo0weP9VxVwerDVuObEyZRwIp9tdsLGpvd0llt6bW1eZWz1/Gx oyskxZdw99u6vrPr1b7bXrDdbZLbmdYRr/SHX3MbznQZ73+apDvEeWuseNlXr4nNYsmWG2iXaRmz k60jsFJcjm13xrLxqi0d5JZeWzO8lYITmFIUHjLuWXJBgVo93HrMnQRcB+/AkVkfxbyb1AZC1jtS pGxuC+cs+MffpOfVo7vtxtSkn/TnpiWbqnX1C2qZaMOO7pg1IODKMpjlFS+Lxe8zsXeIhV2A/PjR 3tOTk1XVUDV7en5krDVwuNzWxll5NliwleXY9zXWbjxvnUNobCHs6xaDwJUns84Cb3Etel2jBdHE TSqVLpR5l9t72xaOzP98jMfRrsD11AJ/JZCcc33j898Aebd9qg3kplQPUQ2P+PvUnM/B+FyLDJsf 2Wql/icc6iaIm73K4USG3sysmMIt1+lm7SZtOPrakGltM6qT0chd+B4sb+3v+XiAz2t0SkQn/n06 SLeTHtr8WV/YoZPXiK/508dB9DKP+iKapuKgFay7ZelfbM/fu6EPjgfrCbczVPdaD+WW99A9Vump CgYPOrQOGOyMlXJ/UcONU1sB822D4G+bYtZILxiEoSqIChiEARHkOVVK9NIuyrG+C5nz0LfUCnnx KnNFrcRilnbRvqpvbRxgGHZqaTw3sbrGQWtF7HK8kZ86zFUHokZI1EE6RiWTdHMD4WaJDItD4T99 OCTw2gFEbpnrFh/MD9zua3BmMXJxqDsNUc9X1O5Gf/djTg8C9M0UQrt2klyRSzjAwfYXLi5MQPms IA5b6QKITz/UBh1QG//3qctCqAh85KDAVq3vQz4ZUjwACMkwXu6gtT/CLZ9Y2XPqlij41+2YbVIR S2YiH3o39sBfBxxyBTsC1qMDjZfbj/7bI3KWno3iqD/N4hG3XYaRZxqoPneBtAea+rrNRvlHJd81 ISntpWMBFKZaU1KTbTjVdXSAC3KPvnn85KgFF0n6dSzHJLonadmbWEW6cEDEqA2ErsU7xFcddzm1 C6YYsM+YrtN3x4IoY67MKapJzPAHF5a2QozW55SnJwfPjzbS16g1eAgigC0N5hRTLJVzSmccrt9g h2U48zxEvfxd3X4ymvyy1gNnwPXyxy02icr6GG8oQZijUxTdyEnjEqbJSPClrUJ/4ZOzcR8u5NW9 hdcWeK3Cxp/Xcolasixb09qPXnIuzutkkO4VNRzXHoZvlZ+/KrRcTWn+9gHI0nC4/GTmNlJ1/5ln BMOW975pQq55QPNPXUIJK09rhZQGNbN4oeN4Oszj/k50jKrZrWeHGO1rZrrxIZjUfZEkrJDXwPSt SF+vpmqTbdfRkxuADcMSZf2YMUBaF10Qxprb9FlVhwTDwu0MTBtrBW03R6//LwAAAAD//+RXW27b OBTdyoW+HTd2k6Y1ag2STKfNRwojziyAkq4lwjIpkJRV9at76Fc30IV1JXNIWa6DGh1ggMIqBjBk kRQved/nUDPbinIevdfLSqRS5dGz+PWzZlYtTPy6mYWHixfasXJSlJRxatrKSa1IWluzJanIFUz3 t3/7fS7sxjYvw0uocIKxMnuYR+fnF7cvriZXUT/1J69EXbofVxYHU0FId5tq6dqSf3rlEx27t9Q7 sWWSmbfWSnJGVm+YUq2sM0IqZ8djso10aQFTk1AZ1jaVtjJYVDFnlpymhGmtdKOGYFGo1vtrYbxf bl5dXN5cRd4vLn6PK/sb++uSNjKXClFidW1SHlEmrZMqDcol7BpmRVtpXI1vvPKG9x8/UXVvzjHd s7UCUjtrPTwuSG6qUqbCC7XjJ9tO5PwTHbs30t2KWl13LvCpKNJg4N4JPqr2LmoK4UjiZ+nbp89k tHVsqISfMP5KjWipYUqkyv4Ygml7HenDppxZVCieR5Vhy2bLUfxoZLpuvW5QmaBYIfOCbAWFkWfD v/9vcMWlQ6KlVEmlkINnIWsRYgmjbqH4l7rOGLEDm4s1mxECSDnvkJwdhb6QCSdIq7LFI+Ux0Z3K 5FZmvgRsaoeZIfkpXkItrZj2pbgx0nFXxh1/cIMoOH1WxI8F8tj/FLLYNVIh0wntpaCQ58IwOVGu Q/VMdO1opQ28s9HG6GYIdj9x6TxeVgBlQhyHVhwam1zt+jTsCwv2fW5MvQME3WhdslDDCOcTmzW+ rp0+63BOb5hQOcTBfAjTSqOVt2PysEl9+/TF1w5ELKoFgCZgVEYw/eGunZl90Ou1aP+HMYzk79Bw 0iH1MPIO3yH2p2Bt+mby6uZNAGtHtnkEtyiFsoMrDH2JO56hd5560OT5iKzMATh7eAiQrWyljRtR Amy5Hg2quRzX5RoXpVRUrjZ8Rg8c4I1vop4i7OmV9agX1EcgWa5zw4x26j+xqEGBL4gEy2i8tcUf OrQVIB5wbV6L/L802Q7r78Knj6lfQNh6R6Pzes5AlksOhOHfU/v25XRy+dcxNrlbQYI0Mwtxiz2F 8QTm6b4l1g9mA93Mlx+hcjOPJtPpxbk/ocD75Uu8B5lVfi+8SKcrzF90n4D8FJDUDxPt0Gm/j0te HawWLDIGnbqaBvErDYb9fZjXLgx3x6W6tDhth3/9lnCLTKdvjcywggTghWeV8+j5i7CKgtApHph4 orM2vGBLvQE5jf8BAAD//wMAUEsDBBQABgAIAAAAIQCWta3ilgYAAFAbAAAVAAAAd29yZC90aGVt ZS90aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQokDSSX0b2uOA AcO6YYcV2G2HYVuBFtil+zTZOmwd0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+pq9fuxwwdEiEpT9pe /XLNQyTxeUCTsO3dHvYvrXlIKpwEmPGEtL0pkd61jfffu4rXVURigmB9Itdx24uUSteXlqQPw1he 5ilJYG7MRYwVvIpwKRD4COjGbGm5VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9Bq+JknrAZ2KgSRNn hcEGB3WNkFPZZQIdYtb2gE/Aj4bkvvIQw1LBRNurmZ+3tHF1Ca9ni5hasLa0rm9+2bpsQXCwbHiK cFQwrfcbrStbBX0DYGoe1+v1ur16Qc8AsO+DplaWMs1Gf63eyWmWQPZxnna31qw1XHyJ/sqczK1O p9NsZbJYogZkHxtz+LXaamNz2cEbkMU35/CNzma3u+rgDcjiV+fw/Sut1YaLN6CI0eRgDq0d2u9n 1AvImLPtSvgawNdqGXyGgmgookuzGPNELYq1GN/jog8ADWRY0QSpaUrG2Ico7uJ4JCjWDPA6waUZ O+TLuSHNC0lf0FS1vQ9TDBkxo/fq+fevnj9Fxw+eHT/46fjhw+MHP1pCzqptnITlVS+//ezPxx+j P55+8/LRF9V4Wcb/+sMnv/z8eTUQ0mcmzosvn/z27MmLrz79/btHFfBNgUdl+JDGRKKb5Ajt8xgU M1ZxJScjcb4VwwjT8orNJJQ4wZpLBf2eihz0zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJiaIVnHei 2AHucs46XFRaYUfzKpl5OEnCauZiUsbtY3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcYThQOSUIU0nP8 gJAK7e5S6th1l/qCSz5W6C5FHUwrTTKkIyeaZou2aQx+mVbpDP52bLN7B3U4q9J6ixy6SMgKzCqE HxLmmPE6nigcV5Ec4piVDX4Dq6hKyMFU+GVcTyrwdEgYR72ASFm15pYAfUtO38FQsSrdvsumsYsU ih5U0byBOS8jt/hBN8JxWoUd0CQqYz+QBxCiGO1xVQXf5W6G6HfwA04WuvsOJY67T68Gt2noiDQL ED0zEdqXUKqdChzT5O/KMaNQj20MXFw5hgL44uvHFZH1thbiTdiTqjJh+0T5XYQ7WXS7XAT07a+5 W3iS7BEI8/mN513JfVdyvf98yV2Uz2cttLPaCmVX9w22KTYtcrywQx5TxgZqysgNaZpkCftE0IdB vc6cDklxYkojeMzquoMLBTZrkODqI6qiQYRTaLDrniYSyox0KFHKJRzszHAlbY2HJl3ZY2FTHxhs PZBY7fLADq/o4fxcUJAxu01oDp85oxVN4KzMVq5kREHt12FW10KdmVvdiGZKncOtUBl8OK8aDBbW hAYEQdsCVl6F87lmDQcTzEig7W733twtxgsX6SIZ4YBkPtJ6z/uobpyUx4q5CYDYqfCRPuSdYrUS t5Ym+wbczuKkMrvGAna5997ES3kEz7yk8/ZEOrKknJwsQUdtr9VcbnrIx2nbG8OZFh7jFLwudc+H WQgXQ74SNuxPTWaT5TNvtnLF3CSowzWFtfucwk4dSIVUW1hGNjTMVBYCLNGcrPzLTTDrRSlgI/01 pFhZg2D416QAO7quJeMx8VXZ2aURbTv7mpVSPlFEDKLgCI3YROxjcL8OVdAnoBKuJkxF0C9wj6at babc4pwlXfn2yuDsOGZphLNyq1M0z2QLN3lcyGDeSuKBbpWyG+XOr4pJ+QtSpRzG/zNV9H4CNwUr gfaAD9e4AiOdr22PCxVxqEJpRP2+gMbB1A6IFriLhWkIKrhMNv8FOdT/bc5ZGiat4cCn9mmIBIX9 SEWCkD0oSyb6TiFWz/YuS5JlhExElcSVqRV7RA4JG+oauKr3dg9FEOqmmmRlwOBOxp/7nmXQKNRN TjnfnBpS7L02B/7pzscmMyjl1mHT0OT2L0Ss2FXterM833vLiuiJWZvVyLMCmJW2glaW9q8pwjm3 Wlux5jRebubCgRfnNYbBoiFK4b4H6T+w/1HhM/tlQm+oQ74PtRXBhwZNDMIGovqSbTyQLpB2cASN kx20waRJWdNmrZO2Wr5ZX3CnW/A9YWwt2Vn8fU5jF82Zy87JxYs0dmZhx9Z2bKGpwbMnUxSGxvlB xjjGfNIqf3Xio3vg6C24358wJU0wwTclgaH1HJg8gOS3HM3Sjb8AAAD//wMAUEsDBBQABgAIAAAA IQAwMkJc8wIAANQGAAARAAAAd29yZC9zZXR0aW5ncy54bWycVdlu2zAQfC/QfxD0XEeHbcUV4gSJ HfdA0hZV8gGURFlEeIGkrLhf36UkRjEqBEGfTM7Mjsjd5fri6plR74CVJoKv/egs9D3MC1ESvl/7 jw+72cr3tEG8RFRwvPaPWPtXlx8/XLSpxsaATHtgwXUq1n6jeKqLGjOkZ4wUSmhRmVkhWCqqihR4 +PGHCLX2a2NkGgRD0JmQmINbJRRDRp8JtQ/6yK0oGoa5CeIwTAKFKTJwYF0TqZ0b+183+FTtTA5v XeLAqNO1UfiWcrhuK1T5EvGe49kAqUSBtYbMMtpflyHCnY2m7/Hp83lHcoXU8ZXJJZTtjxDMa1OJ VQEJhZpHoR9YAj4sqswgg4HWElPaNUFBMeK9osQVaqh5QHlmhATVAcFxzuPBoKiRQoXBKpOogNiN 4EYJ6nSl+CHMRjCp4Hq9IbSGRKb7OnRgqe0x7OK3EMaFheFik5xH532EZd/DrG7mn+fbqZjVNomS aIrZrOJouZtkdovt/HqK2cbhbRJPMbfLxTy+nWJ219EyuplkNvEq7NyCPhGQEZbaBv2l3GoHWfVY n/oNYrkiyLu3LQxpZGmunm4Id3yO4Snh10zW5I6czXpCM0TpDirnCOjenimJlltcdcb0Hqn96NyV nKVqEoU++f7iZrsMqy9KNLJ3bRWS33gJsPtgtFgMfoSbO8Icrps8c1EcOvkV1fDy50FZw2BMUJsa GD7YZugO8b3rE8xnj5mVtmlBVWYHFL5HUkKLgiTfR2ufkn1tIh+2BnYlUk/dJt/HAxd3HOws121Q YW8G6mFhBf0SVMNixOYOm4/YwmGLEVs6bDliicMSi9VHeLrwNJ9gELilxStBqWhx+dWBa/8fqE+C rpHEUFf7lqHBRNoBw+PW3iHFzzAXcEkMzH5JSoaeYUyEcWLDBzVFR9GYE63lrFieoF6JDILwrlQn wVA6mDOnZ2nTEhcEGjI7snwcHWf9wSnRJsMSpowRCq7cjZ9PnfP4d3T5FwAA//8DAFBLAwQUAAYA CAAAACEAStiKkrsAAAAEAQAAFAAAAHdvcmQvd2ViU2V0dGluZ3MueG1sjM7BasMwDMbxe2HvEHRf nfUwSkhSKKMv0PUBXEdpDLFkJG3e9vQ1bJfdehSf+PHvD19pbT5RNDIN8LJtoUEKPEW6DXB5Pz3v oVHzNPmVCQf4RoXD+LTpS1fwekaz+qlNVUg7GWAxy51zGhZMXreckeo2syRv9ZSb43mOAd84fCQk c7u2fXWCq7daoEvMCn9aeUQrLFMWDqhaQ9L66yUfCcbayNliij94YjkKF0VxY+/+tY93AAAA//8D AFBLAwQUAAYACAAAACEAJY6ySHoHAADKOwAADwAAAHdvcmQvc3R5bGVzLnhtbLRbUXPTSAx+v5n7 Dx6/Q5qkJEeHwJQCR2cKFNLOPW/sTbOD483ZG9rerz+tbG8dO7al2jyB17v6pJX0yW2lN+8etpH3 Syap0vHCH7888T0ZBzpU8d3Cv7359OIv30uNiEMR6Vgu/EeZ+u/e/vnHm/uz1DxGMvVAQJyeJQt/ Y8zubDRKg43civSl3skY3q11shUGHpO7kV6vVSA/6GC/lbEZTU5OZqNERsIAeLpRu9TPpd1TpN3r JNwlOpBpCtpuo0zeVqjYfwvqhTr4INdiH5nUPibXSf6YP+E/n3RsUu/+TKSBUjegOJi4VbFOPp/H qfLhjRSpOU+VOPpyY3cdfROkpiTtvQqVP7KI6X8g85eIFv5kUqxcWA0O1iIR3xVrMn5xuyxrsvDd 0grkLnyRvFieW2EjNLP4t2Tu7sB4eEJVdiKAiwMcsTYSHAj+sDiRso6ezGfFw499BAtib3QOggIA rCwWHis3Dn4FLy+zKIG3cn2lg58yXBp4sfARCxZvL68TpRNlHhf+69cWExaXcqs+qzCUNijztdt4 o0L5z0bGt6kMn9a/f8IQyyUGeh8bUH82xyiI0vDjQyB3NsRAdCysh7/aA5EVm5ZwUKG9etImW6ig 4uK/BeQ48+FRlI0UNo081L8VCK3e9waaWIvKBqBclq7T/iJO+4t41V8EBm+/u5j31wLIs69Hstgo RSXdqUYHWfCV72H6uiVk7YlaFHWeqAVN54lajHSeqIVE54laBHSeqDm880TNv50nau5sPREIJK5q FE3xNkiJfaNMJO35VgIa96S6vNR41yIRd4nYbTxbWKtqt5Hlcr8yNFWRTp9PlkuT6Piu80agOtvU fTYnf9zuNiJV8EXTcfWTnld/I1aR9P5OVNgJ9SoLvppN+GFytIRdRyKQGx2FMvFu5EPmUcb5r9pb Zl8Zncr1dOuVutsYb7nBktsJNmu49OabyORfqRTvoDWZZg2mdAkn+XDWEJfNwr/IUO23xdUQvkZm GZ8z3FyBQBXbr+jUuqieXZ1WWAdQTMjKBd8ElE/QPysufPnWxxT9s1L0TPkE/bPC9Uz5GB/t/mUz zQeR/PRI6TVn5+6FjnSy3kdFDnTSw5ydwQ6CZgI7iZ18EknM2Rl8QJ/eeRDAT26UOGX74olHGShs d2QomGx0W9hOqdDemGER20EVrAkDqx/XMoDYpPtD/lL2F0/cYoAs7b41O9N52nADUIJI39Df99p0 f0NPGjiPinIZw69LUunR0KYNmUdFy+Mpq3cMH/crfAygfhWQAdSvFDKAGuKj+ZvH1UQ6SP/iyMBi 07KrYhh2ZGaes5nZAfFKwEB1k/D91ZC9zbFQr5sEFLaD6nWTgML2TqWWubpJwBqsbhKwGqpGs4/K nMoxil03y0DuS4Bg0TDkTQAahrwJQMOQNwGoP3l3gwxH3gQsNjc4Ti2TNwEIt3B+1HdAZfImALG5 IWO7/HdGRd1DKe0/3A5A3gQUtoPq5E1AYXunibwJWLiFEwkVLEd1BKxhyJsANAx5E4CGIW8C0DDk TQAahrwJQP3JuxtkOPImYLG5wXFqmbwJQGx6cEBl8iYA4RYONxwlb8z6307eBBS2g+rkTUBhe6dC qO4jlYDFdlAFy5E3AQu3cIIhx8Lg5hg1DHkTLBqGvAlAw5A3AWgY8iYA9SfvbpDhyJuAxeYGx6ll 8iYAsenBAZXJmwDE5oaj5I3J+NvJm4DCdlCdvAkobO9UCNXxHAGL7aAKliNvAhbGS2/yJgDhlucC cSwahrwJFg1D3gSgYcibANSfvLtBhiNvAhabGxynlsmbAMSmBwdUJm8CEJsbjpI35shvJ28CCttB dfImoLC9UyFUR94ELLaDKliO6ghYw5A3AQgDszd5E4BwyzOAMIs4bhqGvAkWDUPeBKD+5N0NMhx5 E7DY3OA4tUzeBCA2PTigMnkTgNjcYPtsoV+U3J46bggCap9B0dVABpw0OIkKmBv4Q65lApNMsrs7 pCdgYSEDsSE8qCa+1/qnR2vsnjYECBlKrSKlsaX7Ebt0SoMI03nLJMHNtwvvczYAUzuHIXXYeQPT Q+VxIRxPsoNDoKd53MHIzq7oLLfSYEDIznXlI0A4h3YJA0H5WI89bOd8YCMOVeXL+HfbHBX/DzNv YbHn5OT0YjYfo0WgC4qsKxFsQIsAZqValMhb4V13EjbCV1Vq6JdHtZ6GNQrl8r75p6+rbN9B9yYs NettbI94i87YQ956ex5uyfxdVxDGtlClLg1dvxXuNqsoG0SD/1zG1hUw9od/W8tcHj6ITCy8v5BR 9EXg2JrRu+atkVyb7O34BOtkRdRKG6O3zecTbCNHTY4JgCsuK5M9WiOa7z7eb1cygTmwlvv/qm19 wXm1w8DNOmIzd7vMA+0xrqm33qzbQVKV0qjo2a+Gbamdv0GnPFQpaYbjg5hj1TlEjIF8CvHUPTRO ITYk63Hj7EW73KzdOJb5p9do5ErAtOE3OzxYY5N6JkCrIR5iXYDC4Lehu/DnMA+CEgIYoIGJi72I cm/AKniyGL3MjS58m779HwAA//8DAFBLAwQUAAYACAAAACEA7MTConABAADhAgAAEQAIAWRvY1By b3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFLBTsMwDL0j 8Q9V7l3SDSGo2k4CtBOTkBgCcQuJt4WlSZRk6/r3pO3arYITt9jv+dl+TjY/ljI6gHVCqxwlE4Ii UExzoTY5elst4jsUOU8Vp1IryFENDs2L66uMmZRpCy9WG7BegIuCknIpMznaem9SjB3bQkndJDBU ANfaltSH0G6woWxHN4CnhNziEjzl1FPcCMZmUEQnSc4GSbO3shXgDIOEEpR3OJkk+Mz1YEv3Z0GL XDBL4WsTdjqNe6nNWQcO7KMTA7Gqqkk1a8cI8yf4Y/n82q4aC9V4xQAVGWepF15CkeHzM7zc/usb mO/SQxAAZoF6bQsqZa3aoj7TeL2DutKWu1A3ikIhB8esMD5csFMdJQJbUueX4aRrAfyh7hv8Bpo+ Fg6i+QvFtG00hGGf1r5uTOBRMCTt7OuR99nj02qBiilJkjghcXKzIvcpuUsJ+Wz2GdU3BnWJ8jTZ vxV7gc6a8acsfgAAAP//AwBQSwMEFAAGAAgAAAAhAOGPx+RiBAAAmSAAABIAAAB3b3JkL251bWJl cmluZy54bWzsWs2Oo0YQvkfKO1hIOc7wj7G1zMrjsaWNNqsomShnDO2hFZpGDbbX132ZfYQ81r5C qmlgMTAMMOOVI/kyHld3VfdXfFVdXfjd+88knOwRSzCNHEm9VaQJijzq4+jJkf56XN/Y0iRJ3ch3 QxohRzqiRHp/9/NP7w7zaEc2iMHECdiIkvkehoM0jeeynHgBIm5yS2MUweCWMuKm8JU9ycRl/+zi G4+S2E3xBoc4PcqaolhSboY60o5F89zEDcEeowndplxlTrdb7KH8o9BgfdYVmg/U2xEUpdmKMkMh 7IFGSYDjpLBGxloDiEFhZN8FYk/CYt4h7rOaz9wD+JmEYtsHyvyYUQ8lCUgfxGBpUVW61s4dyE2U Gn22cLpmsRPi4qg0w+lRe/7lw7uFhyeLtWVu6jsQ8MUdkMndJClzvfTTjkxOvn3wHUnJpkQJ9mFs 74aOZOoLxbJXtiRzZbILU/wR7VH4eIxRMSc4bhj2f+NjIR8Tc1MSh8UM01iulvcrS4yEez6A4YOv CP+mceg50tpWl6vFYpXtAUKBpYW6KvQgDtakFPrIw8TNFwNbj+hzOfaLelsu9atXmAnRNhXi+HfG 4eCI4+RiR5pq2VYCN3rKQlK3FD5XPszzyUzosDWN0gTUAhyBmo+2LgDPp2ZzQAW2w+1XgarfgSqG MlMURc8kECMQGjyk1Z7AN7swRDmQGm46FLVqGANhu4mHsSMt6Y5hxCaf0IHDCBZAmobUSxqigV7T Gl4z395r3758Heo3TQV6cNy96ZL77W8gF8/5kAVLr53KhtFKkCiLn5xWgmhvSqtvX/4d7CDbHueg P49kQyFtl96pCIa5xsiYUnXNJUQc5JVxjvlBESfiq+q1y4g4Qx+aoM8UcVA/FSfWRUWcCbvJwmZo SqoEmMjiFcGwiJs2XHMJEWdOR+bqHxRxUPjXCHUZEWcZI1P46XkmOHUqe4lWUEJV6tQXy1ZROVXL 1qlyPzWXq6yEe0XZqqztma0Z5eEHD6pRtpZJgG/z5bK1o3obccwOrlrzpFgJ8VfGfFtd+2pPXOtY fvdqvfZ08udaxzpSp4Oudexb3RyvdSxE6Iib47WOdaTORsy1juXHZ0uH6lrHjou4/08dqzXar9OF fq9Yq6moQMe2X5W1aiwflqs+dey6ZxfyjduvvN3Kez7PXF579lTVWXaXGt78CukBsY8oTRErnXTS UNYGN5RVpfv61A6p0fBU718D6Q9K3Kgdkd6GiOGn4PkeuWrXelcg4MYBSpav2iE1W5TrkZA6OWe0 4ek8aTSzu6XUDqfRVjwf6czBkHStuwnUDqnR8zsb6aw2RN2k02e11NCLdM0u3VlIN23D00k6wxqT FhqdtfORzh4MyTRqaaH27qyddI2219lIN2tD1E06S62lhmdIB9BqjSp4SQnnGPzl71NFY6oy4wN/ 4Zi9WC0SJ8zk9d6JmqgDWtWyngCs2qamZ0d3q5qWp+lMTaiLnxTc/QcAAP//AwBQSwMEFAAGAAgA AAAhAMSpNJQLAgAARQcAABIAAAB3b3JkL2ZvbnRUYWJsZS54bWzMlFFvmzAQx98n7Tsgv68YSkoa lVRdtzz2Yeu0ZwdMsIRt5HNC8+13tqFpGyqVh2kjCgl/nw/75//dze2TbKMDNyC0KkhyQUnEVakr oXYF+fW4+bIkEVimKtZqxQty5EBu158/3fSrWisLEc5XsDIFaaztVnEMZcMlgwvdcYVjtTaSWXw0 u1jXtSj5N13uJVc2Tim9ig1vmcV3QyM6IEO2/iPZem2qzuiSA+BiZRvySSYUWQ+ri/qVYhJX/Sgk h+iB99EPLVkI6JjSwBOMObC2IDTFzxW9pAua4TfFfxmJXaayYQa4fQ6kQa6ZFO1xVI3P6+M7Yctm 1A/MCLZteZgDYocDe9jSguD2aXq3zElQkoIsUXHXoKS4qHDhGfhZl8+Kjyl9Hh+SbDYuBhXMM8zy 64zDOZ0Rudd7I7hxTDyucxo5Erj2VByNbBYNqStuVNjzKxy1eOLV/8biN/rHGR48CdbaBzQN0vS+ OA2Gw33jmsUI+/QbtvfWNWmQX7uG7a2eoPS+aca3nEyTDNKZaUYbTZrmpdU+bpqfR7nV7aRfFlgz CfokoTlWUYpP+QwO86vn34K4Z63YGjFJIqUb3z9cP8mwhvA+TWKyj0AvAGZZ4s6hSL/7+sfOgvWf OYHmX+dZIhC9nttHmEQQ7B0SrpOGjuo66zwS8z0xTYLS7O+QGForrP8AAAD//wMAUEsDBBQABgAI AAAAIQDdsUmbhQEAANkCAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAJxSy07DMBC8I/EPUe7USVsBqrZGqAhx4CU1lLNlbxILx7ZsU7V/z4bQ NogbOe3ObMazY8PNrjPZFkPUzi7zclLkGVrplLbNMn+r7i+u8ywmYZUwzuIy32PMb/j5GbwG5zEk jTEjCRuXeZuSXzAWZYudiBOiLTG1C51I1IaGubrWEu+c/OzQJjYtikuGu4RWobrwR8F8UFxs039F lZO9v7ip9p4Mc6iw80Yk5M+9HTNRLnXAjihULglT6Q55SfCxgVfRYOQlgUMF7y6oyGfF7BrYUMOq FUHIRBny8mpWEjFC4NZ7o6VIlC9/0jK46OqUvXwnkfUKwMYjQOmsUX4Gnfa8ADZu4VHb3s18Dmwo yV8QTRC+jXxO06MW1lIYXFEKvBYmIrATACvXeWH3fKWjdOT3p+0P+IhvvnJ3fVY///0GR+u+69Su vZDkaVrMysvx4iMO1hQQKtrkoHgC4IEuKJj+WArNNqgOM3+JPsrN8FJ5OZ0U9H1nd8Bo/eMT4l8A AAD//wMAUEsBAi0AFAAGAAgAAAAhADDJKAxyAQAApQUAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250 ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAHpEat/MAAABOAgAACwAAAAAAAAAAAAAAAACr AwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAs76LHQkBAAC2AwAAHAAAAAAAAAAAAAAAAADP BgAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQItABQABgAIAAAAIQDsvpDFdzYAABI7 AQARAAAAAAAAAAAAAAAAABoJAAB3b3JkL2RvY3VtZW50LnhtbFBLAQItABQABgAIAAAAIQCWta3i lgYAAFAbAAAVAAAAAAAAAAAAAAAAAMA/AAB3b3JkL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYA CAAAACEAMDJCXPMCAADUBgAAEQAAAAAAAAAAAAAAAACJRgAAd29yZC9zZXR0aW5ncy54bWxQSwEC LQAUAAYACAAAACEAStiKkrsAAAAEAQAAFAAAAAAAAAAAAAAAAACrSQAAd29yZC93ZWJTZXR0aW5n cy54bWxQSwECLQAUAAYACAAAACEAJY6ySHoHAADKOwAADwAAAAAAAAAAAAAAAACYSgAAd29yZC9z dHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAOzEwqJwAQAA4QIAABEAAAAAAAAAAAAAAAAAP1IAAGRv Y1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhAOGPx+RiBAAAmSAAABIAAAAAAAAAAAAAAAAA 5lQAAHdvcmQvbnVtYmVyaW5nLnhtbFBLAQItABQABgAIAAAAIQDEqTSUCwIAAEUHAAASAAAAAAAA AAAAAAAAAHhZAAB3b3JkL2ZvbnRUYWJsZS54bWxQSwECLQAUAAYACAAAACEA3bFJm4UBAADZAgAA EAAAAAAAAAAAAAAAAACzWwAAZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAADAAMAAEDAABuXgAAAAA= ------_=_NextPart_001_01CC8AA1.86A2FD21-- From stewe@stewe.org Fri Oct 14 20:03:05 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B48121F8BD3 for ; Fri, 14 Oct 2011 20:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLdk2mVWrBKb for ; Fri, 14 Oct 2011 20:03:04 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id EBA9421F8B37 for ; Fri, 14 Oct 2011 20:03:03 -0700 (PDT) Received: from [172.19.131.174] (unverified [12.130.122.12]) by stewe.org (SurgeMail 3.9e) with ESMTP id 49759-1743317 for ; Sat, 15 Oct 2011 05:03:02 +0200 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Fri, 14 Oct 2011 23:02:53 -0400 From: Stephan Wenger To: "clue@ietf.org" Message-ID: Thread-Topic: Kick-Off Item 5: description of composed pictures Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3401478182_1845738" X-Originating-IP: 12.130.122.12 X-Authenticated-User: stewe@stewe.org Subject: [clue] Kick-Off Item 5: description of composed pictures X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 03:03:05 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3401478182_1845738 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi, Here is the kickoff message as agreed in our F2F. We are in the process of defining a mechanism that allows us to tag in room "coordinates" of captures to RTP streams. In its most trivial incarnation, that would allow us to assign the decoded RTP streams to devices such as individual monitors. RTP comes from system 1, camera coordinates x, y, z, upper right x, y, z, lower left x, y, z RTP comes from system 1, camera coordinates (something else) Note that we probably need a third and even a fourth point for faithfully specifying a capture in 3D space, but that's not the subject of this email, so don't beat me up on it right now. As for the capabilities of a renderer (not defined in the framework yet), it should be clear that a monitor can trivially display more than one decoded RTP stream. Insofar, the mapping should be per part of a virtual display wall (or however you want to call it), and not per physical screen. I would hope that this is uncontroversial. Things become more tricky when there is a video mixing MCU in the picture, or when an endpoint creates a single RTP stream that contains information from multiple camera devices (through tiling, picture-in-picture). Here, we cannot meaningfully tag the a single geographic information to a single RTP stream simply because the multiple video sequences were mixed at the sample level, and the encoder didn't have a clue that it is actually encoding data stemming from more than one camera. However, the endpoint system (or the MCU) know the geographic metadata associated with the composed picture. So what I'm proposing is that we allow a single RTP stream to have more than one geometric information about the capture involved. For video, one would probably have to associate regions of the reconstructed video stream (in the spatial dimension) with capture geographic information as currently proposed in the framework. Example: a sending endpoint creating ONE RTP stream which includes TWO captures, tiled horizontally RTP { bitstream coordinates x=0 to 959, y=0, to 1080 , comes from system 1, camera coordinates x, y, z, x, y,z x, y, z bitstream coordinates x=960 to 1919, y=0 to 1080, comes from system 1, camera coordinates (something else) } Architecturally, this system would best need to be recursive, as it ought to be possible to throw an already composed image from MCU1 at the input of MCU2, which scales it down and composes it with other images to other ports. Clear enough? Thanks, Stephan --B_3401478182_1845738 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi,

Here is the kickoff message as agreed in our F2F.

= We are in the process of defining a mechanism that allows us to tag in room = "coordinates" of captures to RTP streams.  In its most trivial incarnat= ion, that would allow us to assign the decoded RTP streams to devices such a= s individual monitors.

RTP <id#1> comes from = system 1, camera coordinates x, y, z, upper right x, y, z, lower left x, y, = z 
RTP <id#2> comes from system 1, camera coordinates (= something else)

Note that we probably need a third = and even a fourth point for faithfully specifying a capture in 3D space, but= that's not the subject of this email, so don't beat me up on it right now.&= nbsp;

As for the capabilities of a renderer (not de= fined in the framework yet), it should be clear that a monitor can trivially= display more than one decoded RTP stream.  Insofar, the mapping should= be per part of a virtual display wall (or however you want to call it), and= not per physical screen.  I would hope that this is uncontroversial.

Things become more tricky when there is a video mixi= ng MCU in the picture, or when an endpoint creates a single RTP stream that = contains information from multiple camera devices (through tiling, picture-i= n-picture).  Here, we cannot meaningfully tag the a single geographic i= nformation to a single RTP stream simply because the multiple video sequence= s were mixed at the sample level, and the encoder didn't have a clue that it= is actually encoding data stemming from more than one camera.  However= , the endpoint system (or the MCU) know the geographic metadata associated w= ith the composed picture.  So what I'm proposing is that we allow a sin= gle RTP stream to have more than one geometric information about the capture= involved.  For video, one would probably have to associate regions of = the reconstructed video stream (in the spatial dimension) with capture geogr= aphic information as currently proposed in the framework.

Example: a sending endpoint creating ONE RTP stream which includes TW= O captures, tiled horizontally

RTP <id#2> {
    bitstream coordinates x=3D0 to 959, y=3D0, to 1080 , come= s from system 1, camera coordinates x, y, z, x, y,z x, y, z
 =   bitstream coordinates x=3D960 to 1919, y=3D0 to 1080, comes from system = 1, camera coordinates (something else) 
}

Architecturally, this system would best need to be recursive, as it ou= ght to be possible to throw an already composed image from MCU1 at the input= of MCU2, which scales it down and composes it with other images to other po= rts.

Clear enough?

Thanks,=
Stephan

--B_3401478182_1845738-- From mphmmr@gmail.com Sat Oct 15 10:03:09 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC0E21F8B20 for ; Sat, 15 Oct 2011 10:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS0-jYdq1ZTv for ; Sat, 15 Oct 2011 10:03:08 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A27121F8B1F for ; Sat, 15 Oct 2011 10:03:08 -0700 (PDT) Received: by wyg24 with SMTP id 24so4437801wyg.31 for ; Sat, 15 Oct 2011 10:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8ujKioc8c+U0iCJh+nw/w5t8VwnTwKU0IB3Iubjd8XA=; b=A9StLcfE+389XDjykeMMq6Qp6XRrOnuu+gi5V4deuWWvYkLfTvboDPhChGqoaz8HE4 CQcDl58z6LHEL5ldWrgGLQrZKxDJEAqIYctVYBbH1cQp5cbz49rexGWmhj0mq9LUyMmx UUiX5X/q1RhwWZAWCJPv8/H/RikWDxVYFGbo0= MIME-Version: 1.0 Received: by 10.216.190.69 with SMTP id d47mr4452590wen.51.1318698187384; Sat, 15 Oct 2011 10:03:07 -0700 (PDT) Received: by 10.216.39.69 with HTTP; Sat, 15 Oct 2011 10:03:07 -0700 (PDT) In-Reply-To: References: Date: Sat, 15 Oct 2011 13:03:07 -0400 Message-ID: From: Michael Hammer To: Stephan Wenger Content-Type: multipart/alternative; boundary=0016364181d30667f204af59595a Cc: "clue@ietf.org" Subject: Re: [clue] Kick-Off Item 5: description of composed pictures X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 17:03:09 -0000 --0016364181d30667f204af59595a Content-Type: text/plain; charset=ISO-8859-1 Stephan, You use monitor as both input and output device. I hope that is not embedded in the scheme. The rest of this email seems to focus only on input definitions as it probably should. Don't understand the comment about 3-D followed by coordinates in 3-D. It seems like 3-D is fundamental. Do I understand correctly that the camera coordinates define the location of the lense, while the bitstream is abstraction of the pixel layout for some abstraction (via ray-tracing?) of a window? Or is the camera coordinates defining some virtual window in space that through some changes in focal length could be a closeup and those farther from the camera and narrower field of view versus wider angel and closer to the lense with greater field of view? When talking about spatial things, perhaps a picture would help save a thousand words. Also, I would think that what a renderer or MCU would do could be a second discussion once the capture scheme is better understood. (Understand that the impacts of those might drive some iterations on the basic scheme.) Mike On Fri, Oct 14, 2011 at 11:02 PM, Stephan Wenger wrote: > Hi, > > Here is the kickoff message as agreed in our F2F. > > We are in the process of defining a mechanism that allows us to tag in room > "coordinates" of captures to RTP streams. In its most trivial incarnation, > that would allow us to assign the decoded RTP streams to devices such as > individual monitors. > > RTP comes from system 1, camera coordinates x, y, z, upper right x, > y, z, lower left x, y, z > RTP comes from system 1, camera coordinates (something else) > > Note that we probably need a third and even a fourth point for faithfully > specifying a capture in 3D space, but that's not the subject of this email, > so don't beat me up on it right now. > > As for the capabilities of a renderer (not defined in the framework yet), > it should be clear that a monitor can trivially display more than one > decoded RTP stream. Insofar, the mapping should be per part of a virtual > display wall (or however you want to call it), and not per physical screen. > I would hope that this is uncontroversial. > > Things become more tricky when there is a video mixing MCU in the picture, > or when an endpoint creates a single RTP stream that contains information > from multiple camera devices (through tiling, picture-in-picture). Here, we > cannot meaningfully tag the a single geographic information to a single RTP > stream simply because the multiple video sequences were mixed at the sample > level, and the encoder didn't have a clue that it is actually encoding data > stemming from more than one camera. However, the endpoint system (or the > MCU) know the geographic metadata associated with the composed picture. So > what I'm proposing is that we allow a single RTP stream to have more than > one geometric information about the capture involved. For video, one would > probably have to associate regions of the reconstructed video stream (in the > spatial dimension) with capture geographic information as currently proposed > in the framework. > > Example: a sending endpoint creating ONE RTP stream which includes TWO > captures, tiled horizontally > > RTP { > bitstream coordinates x=0 to 959, y=0, to 1080 , comes from system 1, > camera coordinates x, y, z, x, y,z x, y, z > bitstream coordinates x=960 to 1919, y=0 to 1080, comes from system 1, > camera coordinates (something else) > } > > Architecturally, this system would best need to be recursive, as it ought > to be possible to throw an already composed image from MCU1 at the input of > MCU2, which scales it down and composes it with other images to other ports. > > Clear enough? > > Thanks, > Stephan > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --0016364181d30667f204af59595a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Stephan,
=A0
You use monitor as both input and out= put device.=A0 I hope that is not embedded in the scheme.
The res= t of this email seems to focus only on input definitions as it probably sho= uld.
=A0
Don't understand the comment about 3-D followed by c= oordinates in 3-D.=A0 It seems like 3-D is fundamental.
=A0
=
Do I understand correctly that the camera coordinates define the locat= ion of the lense, while the bitstream is abstraction of the pixel layout fo= r some abstraction (via ray-tracing?) of a window?
=A0
Or is the camera coordinates defining some virtual windo= w in space that through some changes in focal length could be a closeup and= those farther from the camera and narrower field of view versus wider ange= l and closer to the lense with greater field of view?
=A0
When talking about spatial things, perhaps a picture wou= ld help save a thousand words.
=A0
Also, I would think = that what=A0a renderer or MCU would do=A0could be a second discussion once = the capture scheme is better understood.=A0 (Understand that the impacts of= those might drive some iterations on the basic scheme.)
=A0
Mike

On Fri, Oct= 14, 2011 at 11:02 PM, Stephan Wenger <stewe@stewe.org> wrote:
Hi,

Here i= s the kickoff message as agreed in our F2F.

We are= in the process of defining a mechanism that allows us to tag in room "= ;coordinates" of captures to RTP streams. =A0In its most trivial incar= nation, that would allow us to assign the decoded RTP streams to devices su= ch as individual monitors.

RTP <id#1> comes from system 1, camera coordinate= s x, y, z, upper right x, y, z, lower left x, y, z=A0
RTP <id#= 2> comes from system 1, camera coordinates (something else)

Note that we probably need a third and even a fourth point f= or faithfully specifying a capture in 3D space, but that's not the subj= ect of this email, so don't beat me up on it right now.=A0

As for the capabilities of a renderer (not defined in the fr= amework yet), it should be clear that a monitor can trivially display more = than one decoded RTP stream. =A0Insofar, the mapping should be per part of = a virtual display wall (or however you want to call it), and not per physic= al screen. =A0I would hope that this is uncontroversial.

Things become more tricky when there is a video mixing = MCU in the picture, or when an endpoint creates a single RTP stream that co= ntains information from multiple camera devices (through tiling, picture-in= -picture). =A0Here, we cannot meaningfully tag the a single geographic info= rmation to a single RTP stream simply because the multiple video sequences = were mixed at the sample level, and the encoder didn't have a clue that= it is actually encoding data stemming from more than one camera. =A0Howeve= r, the endpoint system (or the MCU) know the geographic metadata associated= with the composed picture. =A0So what I'm proposing is that we allow a= single RTP stream to have more than one geometric information about the ca= pture involved. =A0For video, one would probably have to associate regions = of the reconstructed video stream (in the spatial dimension) with capture g= eographic information as currently proposed in the framework.

Example: a sending endpoint creating ONE RTP stream whi= ch includes TWO captures, tiled horizontally

RTP &= lt;id#2> {
=A0 =A0 bitstream coordinates x=3D0 to 959, y=3D0, = to 1080 , comes from system 1, camera coordinates x, y, z, x, y,z x, y, z
=A0 =A0 bitstream coordinates x=3D960 to 1919, y=3D0 to 1080, comes fr= om system 1, camera coordinates (something else)=A0
}
<= br>
Architecturally, this system would best need to be recursive,= as it ought to be possible to throw an already composed image from MCU1 at= the input of MCU2, which scales it down and composes it with other images = to other ports.

Clear enough?

Thanks,
Stephan


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


--0016364181d30667f204af59595a-- From Even.roni@huawei.com Sun Oct 16 12:34:10 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F69321F8AF7 for ; Sun, 16 Oct 2011 12:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.735 X-Spam-Level: X-Spam-Status: No, score=-102.735 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjmAcsJaWESQ for ; Sun, 16 Oct 2011 12:34:09 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7A90421F8AF6 for ; Sun, 16 Oct 2011 12:34:09 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT6002O0BOPF5@szxga03-in.huawei.com> for clue@ietf.org; Mon, 17 Oct 2011 03:34:01 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT6000C7BOPUT@szxga03-in.huawei.com> for clue@ietf.org; Mon, 17 Oct 2011 03:34:01 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-199-250.red.bezeqint.net [79.183.199.250]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LT600HW4BOHR6@szxml12-in.huawei.com> for clue@ietf.org; Mon, 17 Oct 2011 03:34:01 +0800 (CST) Date: Sun, 16 Oct 2011 21:31:43 +0200 From: Roni Even To: clue@ietf.org Message-id: <00d601cc8c3a$421e5e20$c65b1a60$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Uxp88rr8AXVVklfDM/lxFg)" Content-language: en-us Thread-index: AcyMOjp9eFtxm2B8TseqXd8lNrjNHg== Subject: [clue] Area Scale Millimeters X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 19:34:10 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Uxp88rr8AXVVklfDM/lxFg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, The default for Area Scale Millimeters is no physical scale. During the Interim meeting my understanding was the even though there is no physical scale there is some scale since the numbers reported can be used to find the relation in the x direction between the different areas and between an area and a gap. For example an area of (0,25) is half the size of an area (25,75). This also imply that x(0,50) is twice the size of y(0,25) for two dimension. If this is the understanding also of the authors of the draft than I am not sure why it is easier to use no physical scale since you need some scale to have the correct proportions between axis Regards Roni Even --Boundary_(ID_Uxp88rr8AXVVklfDM/lxFg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

The default for Area Scale Millimeters is no physical scale. During the Interim meeting my understanding was the even though there is no physical scale there is some scale since the numbers reported can be used to find the relation in the x direction between the different areas and between an area and a gap. For example an area of (0,25) is half the size of an area (25,75).

This also imply that x(0,50) is twice the size of y(0,25) for two dimension. If this is the understanding also of the authors of the draft than I am not sure why it is easier to use no physical scale since you need some scale to have the correct proportions between axis

Regards

Roni Even

 

X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435B621F858D for ; Mon, 17 Oct 2011 10:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ybmdkubb5MSd for ; Mon, 17 Oct 2011 10:05:55 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3808621F8586 for ; Mon, 17 Oct 2011 10:05:55 -0700 (PDT) Received: by vws5 with SMTP id 5so3328116vws.31 for ; Mon, 17 Oct 2011 10:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=te8+Hs8zVQynPsoVU+SmN8kJZPjlJDct1flf9r5rKdM=; b=mtzj9M3CxnZB9+jhshtkXDMsX0tbIpKOJ1j/tmCNQEOaxXs9yAia0v5GMh5JdFwkg6 sB9GB7g16VCVbgz5Eec8PiDdINciXKWgqAZrmQLuHWupZRE/HCMZZOd+C2kULmkEiwCv U6XS58RzmS/zU186qX3NiqM0roX/Tvh2jx0hA= MIME-Version: 1.0 Received: by 10.52.21.67 with SMTP id t3mr20699653vde.104.1318871154505; Mon, 17 Oct 2011 10:05:54 -0700 (PDT) Received: by 10.52.75.198 with HTTP; Mon, 17 Oct 2011 10:05:54 -0700 (PDT) Date: Mon, 17 Oct 2011 12:05:54 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307d00caab367c04af819e29 Subject: [clue] Raw notes, recordings and some conclusions from CLUE WG Interim meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 17:05:56 -0000 --20cf307d00caab367c04af819e29 Content-Type: text/plain; charset=ISO-8859-1 Hi all, While the chairs are busy (well, Paul really) pulling together the official minutes, I have uploaded the raw notes to the wiki and included the links to the recordings: http://trac.tools.ietf.org/wg/clue/trac/wiki/WikiStart We stuck fairly close to the agenda that is on the wiki, except for the last couple hours on Tuesday. We ended up discussing the way forward for issues (that Allyn identified in her presentation + others identified by the group) before the RTCWEB discussion which was very short. We ended up with time to discuss one of the top 5 issues on Tuesday (item 1 - Point of View/Areas of Capture). The top 5 issues (based on feedback from those at the meeting) are summarized here: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/WikiStart/9-Framework-Major-Issues-to-discuss-top.ppt We were able to discussing the other four issues on Wednesday as identified in the agenda. The summary of all the key issues identified at the meeting (as discussed at the end of the meeting on Wednesay) along with the individual that was assigned the action item for the issue is available here: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/WikiStart/Final-Framework%20Major%20Issues.ppt As far as the actual framework document, there was strong consensus amongst the attendees (and one individual that survived the meeting via webex) to accept draft-romanow-clue-framework as the basis for the WG deliverable. Mark Duckworth will be the assigned editor for the document. He will be submitting the WG -00 by the deadline. This update will include some of the basic changes agreed - primarily editorial. Any conclusions from other issues over the next two weeks may be reflected in a -01 before the meeting. Otherwise, the remaining open issues will the focus for discussion at IETF-82. Anyone that was not at the meeting that has any concerns with using draft-romanow-clue-framework as the starting point for the WG deliverable, please respond on the mailing list detailing your concerns. Thanks, Mary and Paul --20cf307d00caab367c04af819e29 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

While the chairs are busy (well, Paul really) pu= lling together the official minutes, I have uploaded the raw notes to the w= iki and included the links to the recordings:

We stuck fairly close to the agenda that is on the wiki= , except for the last couple hours on Tuesday. =A0We ended up discussing th= e way forward for issues (that Allyn identified in her presentation + other= s identified by the group) before the RTCWEB discussion which was very shor= t. We ended up with time to discuss one of the top 5 issues on Tuesday (ite= m 1 - Point of View/Areas of Capture). =A0The top 5 issues (based on feedba= ck from those at the meeting) are summarized here:

We were able to discussing the other four issues on Wed= nesday as identified in the agenda.

The summary of= all the key issues identified at the meeting (as discussed at the end of t= he meeting on Wednesay) along with the individual that was assigned the act= ion item for the issue is available here: =A0http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/WikiStart= /Final-Framework%20Major%20Issues.ppt
=A0
As far as the actual framework document, there was stron= g consensus amongst the attendees (and one individual that survived the mee= ting via webex) to accept draft-romanow-clue-framework as the basis for the= WG deliverable. =A0Mark Duckworth will be the assigned editor for the docu= ment. He will be submitting the WG -00 by the deadline. =A0This update will= include some of the basic changes agreed - primarily editorial. =A0Any con= clusions from other issues over the next two weeks may be reflected in a -0= 1 before the meeting. Otherwise, the remaining open issues will the focus f= or discussion at IETF-82. =A0

Anyone that was not at the meeting that has any concern= s with using draft-romanow-clue-framework as the starting point for the WG = deliverable, please respond on the mailing list detailing your concerns.

Thanks,
Mary and Paul
--20cf307d00caab367c04af819e29-- From bbaldino@cisco.com Mon Oct 17 10:17:04 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177D821F8C32 for ; Mon, 17 Oct 2011 10:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G38HSGwnyBjT for ; Mon, 17 Oct 2011 10:17:02 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id DB88A21F8C12 for ; Mon, 17 Oct 2011 10:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bbaldino@cisco.com; l=9166; q=dns/txt; s=iport; t=1318871823; x=1320081423; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=l1XrH0ZzMri9Sc6rA8Pv6uQIYX0Sn7TBYY6KVLLo9pc=; b=cWvFMWYZvzW3uu5n5UauH6iPbrn9+8pN2Rg0Z9t2xuXNvis3W9HRU2mF m80rKedoNvN2VesSvXrcdgG7v2JY5K0H+L5L/7BueAeCU1lDI9xLd3oCH LdJH7jxjhcdYyF07y3OfWx/hjaEXDrUdnKJnbheEj02gmaXIO++zFzKAw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBAANinE6rRDoG/2dsb2JhbABEgk2WbY8jgQWBbgEBAQQSAQkRA0IXAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqgCgGeYocnYQSIApEqjEQ X-IronPort-AV: E=Sophos;i="4.69,360,1315180800"; d="scan'208,217";a="8357588" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 17 Oct 2011 17:17:02 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9HHH2vw004206; Mon, 17 Oct 2011 17:17:02 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 10:17:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8CF0.95C0C168" Date: Mon, 17 Oct 2011 10:17:01 -0700 Message-ID: In-Reply-To: <00d601cc8c3a$421e5e20$c65b1a60$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Area Scale Millimeters Thread-Index: AcyMOjp9eFtxm2B8TseqXd8lNrjNHgAte/4w References: <00d601cc8c3a$421e5e20$c65b1a60$%roni@huawei.com> From: "Brian Baldino (bbaldino)" To: "Roni Even" , X-OriginalArrivalTime: 17 Oct 2011 17:17:02.0304 (UTC) FILETIME=[95F89E00:01CC8CF0] Subject: Re: [clue] Area Scale Millimeters X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 17:17:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8CF0.95C0C168 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey Roni, Not sure I understand how you're saying that a relative scale requires as much detail as an absolute scale (millimeters). If I don't care (or don't know) the dimensions of my room in millimeters, but I know it's divided up into thirds, it's easy for me to describe the 3 areas of capture as {(0,32),(33,65),(66,99)} or even {(0,1),(1,2),(2,3)}. Both of those areas of capture tell the renderer spatial ordering which may be all that is required for some devices. =20 -Brian =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Sunday, October 16, 2011 12:32 PM To: clue@ietf.org Subject: [clue] Area Scale Millimeters =20 Hi, The default for Area Scale Millimeters is no physical scale. During the Interim meeting my understanding was the even though there is no physical scale there is some scale since the numbers reported can be used to find the relation in the x direction between the different areas and between an area and a gap. For example an area of (0,25) is half the size of an area (25,75).=20 This also imply that x(0,50) is twice the size of y(0,25) for two dimension. If this is the understanding also of the authors of the draft than I am not sure why it is easier to use no physical scale since you need some scale to have the correct proportions between axis Regards Roni Even =20 ------_=_NextPart_001_01CC8CF0.95C0C168 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey Roni,

Not sure I understand how you’re saying that a = relative scale requires as much detail as an absolute scale (millimeters).  If I = don’t care (or don’t know) the dimensions of my room in millimeters, but = I know it’s divided up into thirds, it’s easy for me to describe = the 3 areas of capture as {(0,32),(33,65),(66,99)} or even = {(0,1),(1,2),(2,3)}.  Both of those areas of capture tell the renderer spatial ordering which = may be all that is required for some devices.

 

-Brian

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Sunday, October 16, 2011 12:32 PM
To: clue@ietf.org
Subject: [clue] Area Scale Millimeters

 

Hi,

The default for Area Scale Millimeters is no = physical scale. During the Interim meeting my understanding was the even though there is = no physical scale there is some scale since the numbers reported can be = used to find the relation in the x direction between the different areas and = between an area and a gap. For example an area of (0,25) is half the size of an = area (25,75).

This also imply that x(0,50) is twice the size of = y(0,25) for two dimension. If this is the understanding also of the authors of = the draft than I am not sure why it is easier to use no physical scale since you = need some scale to have the correct proportions between axis

Regards

Roni Even

 

------_=_NextPart_001_01CC8CF0.95C0C168-- From stephen.botzko@gmail.com Mon Oct 17 10:30:45 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2319B21F8469 for ; Mon, 17 Oct 2011 10:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yg8q3xIC5iTh for ; Mon, 17 Oct 2011 10:30:44 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 17F6621F8468 for ; Mon, 17 Oct 2011 10:30:44 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3340817vcb.31 for ; Mon, 17 Oct 2011 10:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VP8JPURByu4FiuOQPy465CUC0Dyfb4oZQu45eKWdq/E=; b=DZ1VgJL9nNDsoGIZQszQJ7KQ0Ainy+r/qCNNW2NDqIhWVC7iFcKM/u1eMyM4AR5rpj 06Te05DNM8dseuCiv8bVQvsSwjlq1H5jR2ywvMz4yyBwEXd/9eEEIYH+gtgvVuHq69DN G6u5m2bjxoES0EO7+9ncJjj0tv9wiacq1jjoU= MIME-Version: 1.0 Received: by 10.52.21.232 with SMTP id y8mr20966720vde.83.1318872643518; Mon, 17 Oct 2011 10:30:43 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Mon, 17 Oct 2011 10:30:43 -0700 (PDT) In-Reply-To: References: <00d601cc8c3a$421e5e20$c65b1a60$%roni@huawei.com> Date: Mon, 17 Oct 2011 13:30:43 -0400 Message-ID: From: Stephen Botzko To: "Brian Baldino (bbaldino)" Content-Type: multipart/alternative; boundary=20cf3079baba6bc09804af81f727 Cc: clue@ietf.org Subject: Re: [clue] Area Scale Millimeters X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 17:30:45 -0000 --20cf3079baba6bc09804af81f727 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree. For instance, if you aren't particularly interested in actual siz= e display or gaps between captures, you could simply use capture pixels as your relative scale. So it is possible to get some utility (e.g. adjacency at least) without any measurements at all. I expect we would use physical MM scale in our signaling. I'd rather know if a far-end is using a true physical scale, or not - since in the latter case I would defeat any re-scaling/cropping to get true size. Steve B. On Mon, Oct 17, 2011 at 1:17 PM, Brian Baldino (bbaldino) < bbaldino@cisco.com> wrote: > Hey Roni,**** > > Not sure I understand how you=92re saying that a relative scale requires = as > much detail as an absolute scale (millimeters). If I don=92t care (or do= n=92t > know) the dimensions of my room in millimeters, but I know it=92s divided= up > into thirds, it=92s easy for me to describe the 3 areas of capture as > {(0,32),(33,65),(66,99)} or even {(0,1),(1,2),(2,3)}. Both of those area= s > of capture tell the renderer spatial ordering which may be all that is > required for some devices.**** > > ** ** > > -Brian**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf O= f > *Roni Even > *Sent:* Sunday, October 16, 2011 12:32 PM > *To:* clue@ietf.org > *Subject:* [clue] Area Scale Millimeters**** > > ** ** > > Hi,**** > > The default for Area Scale Millimeters is no physical scale. During the > Interim meeting my understanding was the even though there is no physical > scale there is some scale since the numbers reported can be used to find = the > relation in the x direction between the different areas and between an ar= ea > and a gap. For example an area of (0,25) is half the size of an area > (25,75). **** > > This also imply that x(0,50) is twice the size of y(0,25) for two > dimension. If this is the understanding also of the authors of the draft > than I am not sure why it is easier to use no physical scale since you ne= ed > some scale to have the correct proportions between axis**** > > Regards**** > > Roni Even**** > > ** ** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --20cf3079baba6bc09804af81f727 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree.=A0 For instance, if you aren't particularly interested in actu= al size display or gaps between captures, you could simply use capture pixe= ls as your relative scale.=A0 So it is possible to get some utility (e.g. a= djacency at least) without any measurements at all.=A0

I expect we would use physical MM scale in our signaling.=A0 I'd ra= ther know if a far-end is using a true physical scale, or not - since in th= e latter case I would defeat any re-scaling/cropping to get true size.

Steve B.


On Mon, Oct 17, 2011 at = 1:17 PM, Brian Baldino (bbaldino) <bbaldino@cisco.com> wrote:

Hey Roni,

Not sure I understand how you=92re saying that = a relative scale requires as much detail as an absolute scale (millimeters).=A0 If I don=92t care (or don=92t know) the dimensions of my room in millimeters, but I know it=92s divided up into thirds, it=92s easy for me to describe the 3 areas of capture as {(0,32),(33,65),(66,99)} or even {(0,1),(1,2),(2,3)}.= =A0 Both of those areas of capture tell the renderer spatial ordering which may= be all that is required for some devices.

=A0

-Brian

=A0

From:= clue-bounces@iet= f.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: Sunday, October 16, 2011 12:32 PM
To: clue@ietf.org=
Subject: [clue] Area Scale Millimeters

=A0

Hi,

The default for Area Scale Millimeters is no physica= l scale. During the Interim meeting my understanding was the even though there is no physical scale there is some scale since the numbers reported can be used t= o find the relation in the x direction between the different areas and betwee= n an area and a gap. For example an area of (0,25) is half the size of an area (25,75).

This also imply that x(0,50) is twice the size of y(= 0,25) for two dimension. If this is the understanding also of the authors of the = draft than I am not sure why it is easier to use no physical scale since you need some scale to have the correct proportions between axis

Regards

Roni Even

=A0


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


--20cf3079baba6bc09804af81f727-- From Mark.Duckworth@polycom.com Mon Oct 17 11:10:45 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9C121F8AEA for ; Mon, 17 Oct 2011 11:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0qyII9ugwiZ for ; Mon, 17 Oct 2011 11:10:43 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 50A1E21F8B67 for ; Mon, 17 Oct 2011 11:10:40 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Mon, 17 Oct 2011 11:10:36 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 17 Oct 2011 11:11:24 -0700 Thread-Topic: [clue] Area Scale Millimeters Thread-Index: AcyM8oPu+i51pdwfRamEr30nVqZkrwABNy+Q Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61CE24CCCA@CRPMBOXPRD01.polycom.com> References: <00d601cc8c3a$421e5e20$c65b1a60$%roni@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A61CE24CCCACRPMBOXPRD01pol_" MIME-Version: 1.0 Subject: Re: [clue] Area Scale Millimeters X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 18:10:45 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A61CE24CCCACRPMBOXPRD01pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree too. To further clarify a point Roni brought up in the meeting las= t week, the intent is for the scale to be the same linear scale in all dime= nsions (x,y, z), even if you don't know it is millimeters. So the range 0 = to 32 has the same length as the range 33 to 65. The physical scale would = be either millimeters or undefined, not some other unit of measurement. Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ste= phen Botzko Sent: Monday, October 17, 2011 1:31 PM To: Brian Baldino (bbaldino) Cc: clue@ietf.org Subject: Re: [clue] Area Scale Millimeters I agree. For instance, if you aren't particularly interested in actual siz= e display or gaps between captures, you could simply use capture pixels as = your relative scale. So it is possible to get some utility (e.g. adjacency= at least) without any measurements at all. I expect we would use physical MM scale in our signaling. I'd rather know = if a far-end is using a true physical scale, or not - since in the latter c= ase I would defeat any re-scaling/cropping to get true size. Steve B. On Mon, Oct 17, 2011 at 1:17 PM, Brian Baldino (bbaldino) > wrote: Hey Roni, Not sure I understand how you're saying that a relative scale requires as m= uch detail as an absolute scale (millimeters). If I don't care (or don't k= now) the dimensions of my room in millimeters, but I know it's divided up i= nto thirds, it's easy for me to describe the 3 areas of capture as {(0,32),= (33,65),(66,99)} or even {(0,1),(1,2),(2,3)}. Both of those areas of captu= re tell the renderer spatial ordering which may be all that is required for= some devices. -Brian From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Roni Even Sent: Sunday, October 16, 2011 12:32 PM To: clue@ietf.org Subject: [clue] Area Scale Millimeters Hi, The default for Area Scale Millimeters is no physical scale. During the Int= erim meeting my understanding was the even though there is no physical scal= e there is some scale since the numbers reported can be used to find the re= lation in the x direction between the different areas and between an area a= nd a gap. For example an area of (0,25) is half the size of an area (25,75)= . This also imply that x(0,50) is twice the size of y(0,25) for two dimension= . If this is the understanding also of the authors of the draft than I am n= ot sure why it is easier to use no physical scale since you need some scale= to have the correct proportions between axis Regards Roni Even _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_44C6B6B2D0CF424AA90B6055548D7A61CE24CCCACRPMBOXPRD01pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree t= oo.  To further clarify a point Roni brought up in the meeting last we= ek, the intent is for the scale to be the same linear scale in all dimensio= ns (x,y, z), even if you don’t know it is millimeters.  So the r= ange 0 to 32 has the same length as the range 33 to 65.  The physical = scale would be either millimeters or undefined, not some other unit of meas= urement.

 =

Mark

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Stephen Botzko
Sent: Monday, October 17, 2011 1:= 31 PM
To: Brian Baldino (bbaldino)
Cc: clue@ietf.orgSubject: Re: [clue] Area Scale Millimeters

 

I agree.  For instance, if you aren't part= icularly interested in actual size display or gaps between captures, you co= uld simply use capture pixels as your relative scale.  So it is possib= le to get some utility (e.g. adjacency at least) without any measurements a= t all. 

I expect we would use physical MM scale in our signali= ng.  I'd rather know if a far-end is using a true physical scale, or n= ot - since in the latter case I would defeat any re-scaling/cropping to get= true size.

Steve B.

On Mon, Oct 17, 2011 at 1:17 PM, Brian Baldino (bbaldino) <bbaldino@cisco.com> wrote:

=

Hey Roni,

Not sure I understand how you&= #8217;re saying that a relative scale requires as much detail as an absolut= e scale (millimeters).  If I don’t care (or don’t know) th= e dimensions of my room in millimeters, but I know it’s divided up in= to thirds, it’s easy for me to describe the 3 areas of capture as {(0= ,32),(33,65),(66,99)} or even {(0,1),(1,2),(2,3)}.  Both of those area= s of capture tell the renderer spatial ordering which may be all that is re= quired for some devices.

 

-Brian

 

=

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Eve= n
Sent: Sunday, October 16, 2011 12:32 PM
To: clue@ietf.org
Subject= : [clue] Area Scale Millimeters

<= div>

 

Hi,

The default= for Area Scale Millimeters is no physical scale. During the Interim meetin= g my understanding was the even though there is no physical scale there is = some scale since the numbers reported can be used to find the relation in t= he x direction between the different areas and between an area and a gap. F= or example an area of (0,25) is half the size of an area (25,75).

This also imply that x(0,50) is twice the size of y(0,25) for = two dimension. If this is the understanding also of the authors of the draf= t than I am not sure why it is easier to use no physical scale since you ne= ed some scale to have the correct proportions between axis

Regards

Roni Even

 


_______________________________________________
clue mai= ling list
clue@ietf.org
https://w= ww.ietf.org/mailman/listinfo/clue

 

= --_000_44C6B6B2D0CF424AA90B6055548D7A61CE24CCCACRPMBOXPRD01pol_-- From marshall.eubanks@gmail.com Mon Oct 17 12:03:31 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A91221F8C63 for ; Mon, 17 Oct 2011 12:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.426 X-Spam-Level: X-Spam-Status: No, score=-103.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJlAcPhh2LzV for ; Mon, 17 Oct 2011 12:03:30 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C2FF521F8C64 for ; Mon, 17 Oct 2011 12:03:30 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3440624vcb.31 for ; Mon, 17 Oct 2011 12:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XoIpYEhUVIGAAiWNtTJ3Px8Uj558tBGpnLHJ6oLdPsE=; b=FwlmrQQ5jLA8eFbpw3hIrQ5mj/hEHJJ2cXCTKsz4vTfrdWwQfvHcKBbg0yUUuOqmXG iL30YUfewbZgtahOXcVh4UEoBCEBSQQwPDcdr40dfCIGCkgvAIzkFK/Z8U3yNI+mvlL+ 5m5a1vQMQWROJYsVZaZuoNaoOPtRTPynIJbdM= MIME-Version: 1.0 Received: by 10.182.131.34 with SMTP id oj2mr11879966obb.71.1318878210047; Mon, 17 Oct 2011 12:03:30 -0700 (PDT) Received: by 10.182.111.7 with HTTP; Mon, 17 Oct 2011 12:03:30 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 Oct 2011 15:03:30 -0400 Message-ID: From: Marshall Eubanks To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] Raw notes, recordings and some conclusions from CLUE WG Interim meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 19:03:31 -0000 Dear Mary; On Mon, Oct 17, 2011 at 1:05 PM, Mary Barnes w= rote: > Hi all, > While the chairs are busy (well, Paul really) pulling together the offici= al > minutes, I have uploaded the raw notes to the wiki and included the links= to > the recordings: > http://trac.tools.ietf.org/wg/clue/trac/wiki/WikiStart > We stuck fairly close to the agenda that is on the wiki, except for the l= ast > couple hours on Tuesday. =A0We ended up discussing the way forward for is= sues > (that Allyn identified in her presentation + others identified by the gro= up) > before the RTCWEB discussion which was very short. We ended up with time = to > discuss one of the top 5 issues on Tuesday (item 1 - Point of View/Areas = of > Capture). =A0The top 5 issues (based on feedback from those at the meetin= g) > are summarized here: > http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/WikiStart/9-Frame= work-Major-Issues-to-discuss-top.ppt > We were able to discussing the other four issues on Wednesday as identifi= ed > in the agenda. > The summary of all the key issues identified at the meeting (as discussed= at > the end of the meeting on Wednesay) along with the individual that was > assigned the action item for the issue is available here: > =A0http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/WikiStart/Fina= l-Framework%20Major%20Issues.ppt > I don't think that these wiki's like PPT files - I am getting HTML preview not available, since no preview renderer could handle it. Try downloading the file instead. You might want to put PDFs there instead. Marshall > As far as the actual framework document, there was strong consensus among= st > the attendees (and one individual that survived the meeting via webex) to > accept draft-romanow-clue-framework as the basis for the WG deliverable. > =A0Mark Duckworth will be the assigned editor for the document. He will b= e > submitting the WG -00 by the deadline. =A0This update will include some o= f the > basic changes agreed - primarily editorial. =A0Any conclusions from other > issues over the next two weeks may be reflected in a -01 before the meeti= ng. > Otherwise, the remaining open issues will the focus for discussion at > IETF-82. > Anyone that was not at the meeting that has any concerns with using > draft-romanow-clue-framework as the starting point for the WG deliverable= , > please respond on the mailing list detailing your concerns. > Thanks, > Mary and Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From Mark.Duckworth@polycom.com Mon Oct 17 12:29:12 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7EF21F8AEE for ; Mon, 17 Oct 2011 12:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQUmXl6RUNeu for ; Mon, 17 Oct 2011 12:29:12 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 67DF121F8A6C for ; Mon, 17 Oct 2011 12:29:10 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 17 Oct 2011 12:29:09 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 17 Oct 2011 12:29:16 -0700 Thread-Topic: [clue] Raw notes, recordings and some conclusions from CLUE WG Interim meeting Thread-Index: AcyM/3kEQunRIja5SqKkQ84skTzXSAAA0LiA Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61CE24CD59@CRPMBOXPRD01.polycom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Raw notes, recordings and some conclusions from CLUE WG Interim meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 19:29:12 -0000 Marshall, I get the same thing. But then I can immediately click on the download lin= k it gives me, and I can download the PPT file and view it with the powerpo= int application or viewer on my PC. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Marshall Eubanks > Sent: Monday, October 17, 2011 3:04 PM > To: Mary Barnes > Cc: CLUE ...snip...=20 > I don't think that these wiki's like PPT files - I am getting >=20 > HTML preview not available, since no preview renderer could handle it. > Try downloading the file instead. >=20 > You might want to put PDFs there instead. >=20 > Marshall From mary.ietf.barnes@gmail.com Mon Oct 17 15:05:53 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E4D21F8AAC for ; Mon, 17 Oct 2011 15:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFvLaKfju820 for ; Mon, 17 Oct 2011 15:05:53 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA24121F8593 for ; Mon, 17 Oct 2011 15:05:52 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3600823vcb.31 for ; Mon, 17 Oct 2011 15:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E81BLWLZXemOGgJSRHYrcDlO8RRf1N0s7kXDGPQnflo=; b=J3x2c9QVYP+qAS3876UcLk/C8R7uQ+9ujz1O7SGSiU6Jhz0cTWr+J57bIQDVHMDRig +2ZaiwhxMp5qq1zL+r2aa7I+EhcUf9a/BaUdmty0ndU5vqYkuF3zw/JWhkIKfCOaPSK9 copG1pbgOKmG0iZrx+fa0x1ft7xJ5V7u4/IYc= MIME-Version: 1.0 Received: by 10.52.21.67 with SMTP id t3mr21864482vde.104.1318889151296; Mon, 17 Oct 2011 15:05:51 -0700 (PDT) Received: by 10.52.75.198 with HTTP; Mon, 17 Oct 2011 15:05:51 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 Oct 2011 17:05:51 -0500 Message-ID: From: Mary Barnes To: Marshall Eubanks Content-Type: multipart/alternative; boundary=20cf307d00ca5c739404af85cff4 Cc: CLUE Subject: Re: [clue] Raw notes, recordings and some conclusions from CLUE WG Interim meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 22:05:54 -0000 --20cf307d00ca5c739404af85cff4 Content-Type: text/plain; charset=ISO-8859-1 The wiki doesn't like .pdf any better than .ppt. The only files it seems to like are .txt, which makes sense actually. So, as Mark suggests you can download the files. I have also started uploading the files to the Interim meeting materials webpage http://www.ietf.org/proceedings/interim/2011/10/11/clue/proceedings.html Depending on your browser setup, you might be able to open without downloading. Thanks, Mary. On Mon, Oct 17, 2011 at 2:03 PM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > Dear Mary; > > On Mon, Oct 17, 2011 at 1:05 PM, Mary Barnes > wrote: > > Hi all, > > While the chairs are busy (well, Paul really) pulling together the > official > > minutes, I have uploaded the raw notes to the wiki and included the links > to > > the recordings: > > http://trac.tools.ietf.org/wg/clue/trac/wiki/WikiStart > > We stuck fairly close to the agenda that is on the wiki, except for the > last > > couple hours on Tuesday. We ended up discussing the way forward for > issues > > (that Allyn identified in her presentation + others identified by the > group) > > before the RTCWEB discussion which was very short. We ended up with time > to > > discuss one of the top 5 issues on Tuesday (item 1 - Point of View/Areas > of > > Capture). The top 5 issues (based on feedback from those at the meeting) > > are summarized here: > > > http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/WikiStart/9-Framework-Major-Issues-to-discuss-top.ppt > > We were able to discussing the other four issues on Wednesday as > identified > > in the agenda. > > The summary of all the key issues identified at the meeting (as discussed > at > > the end of the meeting on Wednesay) along with the individual that was > > assigned the action item for the issue is available here: > > > http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/WikiStart/Final-Framework%20Major%20Issues.ppt > > > > I don't think that these wiki's like PPT files - I am getting > > HTML preview not available, since no preview renderer could handle it. > Try downloading the file instead. > > You might want to put PDFs there instead. > > Marshall > > > > As far as the actual framework document, there was strong consensus > amongst > > the attendees (and one individual that survived the meeting via webex) to > > accept draft-romanow-clue-framework as the basis for the WG deliverable. > > Mark Duckworth will be the assigned editor for the document. He will be > > submitting the WG -00 by the deadline. This update will include some of > the > > basic changes agreed - primarily editorial. Any conclusions from other > > issues over the next two weeks may be reflected in a -01 before the > meeting. > > Otherwise, the remaining open issues will the focus for discussion at > > IETF-82. > > Anyone that was not at the meeting that has any concerns with using > > draft-romanow-clue-framework as the starting point for the WG > deliverable, > > please respond on the mailing list detailing your concerns. > > Thanks, > > Mary and Paul > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > > --20cf307d00ca5c739404af85cff4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The wiki doesn't like .pdf any better than .ppt. =A0The only files it s= eems to like are .txt, which makes sense actually. So, as Mark suggests you= can download the files. =A0

=A0I have also started uplo= ading the files to the Interim meeting materials webpage
Depending on your browser setup, you might b= e able to open without downloading.=A0

Thanks,
Mary.=A0

On Mon, Oct 17, 2011 at 2:03 PM, Marshall Eubanks <marshall.eubanks@gm= ail.com> wrote:
Dear Mary;

On Mon, Oct 17, 2011 at 1:05 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
> Hi all,
> While the chairs are busy (well, Paul really) pulling together the off= icial
> minutes, I have uploaded the raw notes to the wiki and included the li= nks to
> the recordings:
> http://trac.tools.ietf.org/wg/clue/trac/wiki/WikiStart > We stuck fairly close to the agenda that is on the wiki, except for th= e last
> couple hours on Tuesday. =A0We ended up discussing the way forward for= issues
> (that Allyn identified in her presentation + others identified by the = group)
> before the RTCWEB discussion which was very short. We ended up with ti= me to
> discuss one of the top 5 issues on Tuesday (item 1 - Point of View/Are= as of
> Capture). =A0The top 5 issues (based on feedback from those at the mee= ting)
> are summarized here:
> http:= //trac.tools.ietf.org/wg/clue/trac/attachment/wiki/WikiStart/9-Framework-Ma= jor-Issues-to-discuss-top.ppt
> We were able to discussing the other four issues on Wednesday as ident= ified
> in the agenda.
> The summary of all the key issues identified at the meeting (as discus= sed at
> the end of the meeting on Wednesay) along with the individual that was=
> assigned the action item for the issue is available here:
> =A0http://tr= ac.tools.ietf.org/wg/clue/trac/attachment/wiki/WikiStart/Final-Framework%20= Major%20Issues.ppt
>

I don't think that these wiki's like PPT files - I am getting=

HTML preview not available, since no preview renderer could handle it.
Try downloading the file instead.

You might want to put PDFs there instead.

Marshall


> As far as the actual framework document, there was strong consensus am= ongst
> the attendees (and one individual that survived the meeting via webex)= to
> accept draft-romanow-clue-framework as the basis for the WG deliverabl= e.
> =A0Mark Duckworth will be the assigned editor for the document. He wil= l be
> submitting the WG -00 by the deadline. =A0This update will include som= e of the
> basic changes agreed - primarily editorial. =A0Any conclusions from ot= her
> issues over the next two weeks may be reflected in a -01 before the me= eting.
> Otherwise, the remaining open issues will the focus for discussion at<= br> > IETF-82.
> Anyone that was not at the meeting that has any concerns with using > draft-romanow-clue-framework as the starting point for the WG delivera= ble,
> please respond on the mailing list detailing your concerns.
> Thanks,
> Mary and Paul
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>
>

--20cf307d00ca5c739404af85cff4-- From Christian.Groves@nteczone.com Mon Oct 17 15:51:06 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6460611E8095 for ; Mon, 17 Oct 2011 15:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BT416wlXtz01 for ; Mon, 17 Oct 2011 15:51:05 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 350A011E8096 for ; Mon, 17 Oct 2011 15:51:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIAAOKtnE520Y3R/2dsb2JhbAAMN5kykhgBAQEEAQEBLwEFGxsEBhELEQQBAQEJFggHCQMCAQIBFR8REwYCAQGIA7ciBIgIBKVi Received: from ppp118-209-141-209.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.141.209]) by ipmail06.adl6.internode.on.net with ESMTP; 18 Oct 2011 09:21:02 +1030 Message-ID: <4E9CB153.5070406@nteczone.com> Date: Tue, 18 Oct 2011 09:50:59 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <00d601cc8c3a$421e5e20$c65b1a60$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61CE24CCCA@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61CE24CCCA@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Area Scale Millimeters X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 22:51:06 -0000 Is the issue that even though we say the scale is "relative" it does in fact relate to something physical? i.e. in Brian's examples even though the scale is relative the areas are physically 1/3rd of the room. Roni, is your concern that we need to specify that the scale must be linear and consistent between all axis? Regards, Christian On 18/10/2011 5:11 AM, Duckworth, Mark wrote: > > I agree too. To further clarify a point Roni brought up in the meeting > last week, the intent is for the scale to be the same linear scale in > all dimensions (x,y, z), even if you don’t know it is millimeters. So > the range 0 to 32 has the same length as the range 33 to 65. The > physical scale would be either millimeters or undefined, not some > other unit of measurement. > > Mark > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Stephen Botzko > *Sent:* Monday, October 17, 2011 1:31 PM > *To:* Brian Baldino (bbaldino) > *Cc:* clue@ietf.org > *Subject:* Re: [clue] Area Scale Millimeters > > I agree. For instance, if you aren't particularly interested in actual > size display or gaps between captures, you could simply use capture > pixels as your relative scale. So it is possible to get some utility > (e.g. adjacency at least) without any measurements at all. > > I expect we would use physical MM scale in our signaling. I'd rather > know if a far-end is using a true physical scale, or not - since in > the latter case I would defeat any re-scaling/cropping to get true size. > > Steve B. > > On Mon, Oct 17, 2011 at 1:17 PM, Brian Baldino (bbaldino) > > wrote: > > Hey Roni, > > Not sure I understand how you’re saying that a relative scale requires > as much detail as an absolute scale (millimeters). If I don’t care (or > don’t know) the dimensions of my room in millimeters, but I know it’s > divided up into thirds, it’s easy for me to describe the 3 areas of > capture as {(0,32),(33,65),(66,99)} or even {(0,1),(1,2),(2,3)}. Both > of those areas of capture tell the renderer spatial ordering which may > be all that is required for some devices. > > -Brian > > *From:*clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org ] *On > Behalf Of *Roni Even > *Sent:* Sunday, October 16, 2011 12:32 PM > *To:* clue@ietf.org > *Subject:* [clue] Area Scale Millimeters > > Hi, > > The default for Area Scale Millimeters is no physical scale. During > the Interim meeting my understanding was the even though there is no > physical scale there is some scale since the numbers reported can be > used to find the relation in the x direction between the different > areas and between an area and a gap. For example an area of (0,25) is > half the size of an area (25,75). > > This also imply that x(0,50) is twice the size of y(0,25) for two > dimension. If this is the understanding also of the authors of the > draft than I am not sure why it is easier to use no physical scale > since you need some scale to have the correct proportions between axis > > Regards > > Roni Even > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Mon Oct 17 15:59:12 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53431F0C43 for ; Mon, 17 Oct 2011 15:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.954 X-Spam-Level: X-Spam-Status: No, score=-105.954 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrkpFi9bQ1xl for ; Mon, 17 Oct 2011 15:59:11 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id DF3D31F0C42 for ; Mon, 17 Oct 2011 15:59:10 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT800F1OFULJ9@szxga04-in.huawei.com> for clue@ietf.org; Tue, 18 Oct 2011 06:59:09 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT800DWGFULJ7@szxga04-in.huawei.com> for clue@ietf.org; Tue, 18 Oct 2011 06:59:09 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-199-250.red.bezeqint.net [79.183.199.250]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LT8008YPFUBMS@szxml12-in.huawei.com>; Tue, 18 Oct 2011 06:59:09 +0800 (CST) Date: Tue, 18 Oct 2011 00:56:38 +0200 From: Roni Even In-reply-to: To: "'Brian Baldino (bbaldino)'" , clue@ietf.org Message-id: <01cc01cc8d20$0c8cdd90$25a698b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_t2diY1CHclO4i4nInPoYeQ)" Content-language: en-us Thread-index: AcyMOjp9eFtxm2B8TseqXd8lNrjNHgAte/4wAAu95oA= References: <00d601cc8c3a$421e5e20$c65b1a60$%roni@huawei.com> Subject: Re: [clue] Area Scale Millimeters X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 22:59:12 -0000 This is a multi-part message in MIME format. --Boundary_(ID_t2diY1CHclO4i4nInPoYeQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Brian, This is very easy if you use only one dimension. If you use two dimensions it will mean that 0 to 32 in X direction is the same size as 0 to 32 in the Y direction. I think this will require some unit to do the actual measurement otherwise how does the sender of the information know that they are the same size. A third of the room in X direction is not the same size of third of the room in Y direction. I can agree that relative scale is easier if you are using just X coordinates and want to convey only the spatial order in the X direction. My question was if this is enough as a default information from the sender, my view is that it is not. Having some absolute values will be more helpful for scaling or cropping. Roni From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] Sent: Monday, October 17, 2011 7:17 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Area Scale Millimeters Hey Roni, Not sure I understand how you're saying that a relative scale requires as much detail as an absolute scale (millimeters). If I don't care (or don't know) the dimensions of my room in millimeters, but I know it's divided up into thirds, it's easy for me to describe the 3 areas of capture as {(0,32),(33,65),(66,99)} or even {(0,1),(1,2),(2,3)}. Both of those areas of capture tell the renderer spatial ordering which may be all that is required for some devices. -Brian From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Sunday, October 16, 2011 12:32 PM To: clue@ietf.org Subject: [clue] Area Scale Millimeters Hi, The default for Area Scale Millimeters is no physical scale. During the Interim meeting my understanding was the even though there is no physical scale there is some scale since the numbers reported can be used to find the relation in the x direction between the different areas and between an area and a gap. For example an area of (0,25) is half the size of an area (25,75). This also imply that x(0,50) is twice the size of y(0,25) for two dimension. If this is the understanding also of the authors of the draft than I am not sure why it is easier to use no physical scale since you need some scale to have the correct proportions between axis Regards Roni Even --Boundary_(ID_t2diY1CHclO4i4nInPoYeQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Brian,

This is very easy if you = use only one dimension. If you use two dimensions it will mean that 0 to = 32 in X direction is the same size as 0 to 32 in the Y direction. I = think this will require some unit to do the actual measurement otherwise = how does the sender of the information know that they are the same size. = A third of the room in X direction is not the same size of third of the = room in Y direction.

I can agree that relative scale is easier if you = are using just X coordinates and want to convey only the spatial order = in the X direction.   My question was if this is enough as a = default information from the sender, my view is that it is not. Having = some absolute values will be more helpful for scaling or = cropping.

Roni

 

 

From:= = Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com]
Sent: = Monday, October 17, 2011 7:17 PM
To: Roni Even; = clue@ietf.org
Subject: RE: [clue] Area Scale = Millimeters

 

Hey = Roni,

Not sure = I understand how you’re saying that a relative scale requires as = much detail as an absolute scale (millimeters).  If I don’t = care (or don’t know) the dimensions of my room in millimeters, but = I know it’s divided up into thirds, it’s easy for me to = describe the 3 areas of capture as {(0,32),(33,65),(66,99)} or even = {(0,1),(1,2),(2,3)}.  Both of those areas of capture tell the = renderer spatial ordering which may be all that is required for some = devices.

 

-Brian

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Sunday, October 16, 2011 12:32 = PM
To: clue@ietf.org
Subject: [clue] Area Scale = Millimeters

 

Hi,

The default for = Area Scale Millimeters is no physical scale. During the Interim meeting = my understanding was the even though there is no physical scale there is = some scale since the numbers reported can be used to find the relation = in the x direction between the different areas and between an area and a = gap. For example an area of (0,25) is half the size of an area (25,75). =

This also imply that x(0,50) is = twice the size of y(0,25) for two dimension. If this is the = understanding also of the authors of the draft than I am not sure why it = is easier to use no physical scale since you need some scale to have the = correct proportions between axis

Regards

Roni = Even

 

= --Boundary_(ID_t2diY1CHclO4i4nInPoYeQ)-- From Even.roni@huawei.com Mon Oct 17 16:03:07 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7DE11E80AF for ; Mon, 17 Oct 2011 16:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.116 X-Spam-Level: X-Spam-Status: No, score=-106.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWUV1jaZ8oOT for ; Mon, 17 Oct 2011 16:03:07 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id CA2D211E80A5 for ; Mon, 17 Oct 2011 16:03:06 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT800FF3G15J9@szxga04-in.huawei.com> for clue@ietf.org; Tue, 18 Oct 2011 07:03:06 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT800AZCG156D@szxga04-in.huawei.com> for clue@ietf.org; Tue, 18 Oct 2011 07:03:05 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-199-250.red.bezeqint.net [79.183.199.250]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LT8007A3G1158@szxml12-in.huawei.com>; Tue, 18 Oct 2011 07:03:05 +0800 (CST) Date: Tue, 18 Oct 2011 01:00:40 +0200 From: Roni Even In-reply-to: <4E9CB153.5070406@nteczone.com> To: 'Christian Groves' , clue@ietf.org Message-id: <01d101cc8d20$9a320120$ce960360$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcyNH0SFmWdCUzCGQvi1G25ytaqmfAAAMp4w References: <00d601cc8c3a$421e5e20$c65b1a60$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61CE24CCCA@CRPMBOXPRD01.polycom.com> <4E9CB153.5070406@nteczone.com> Subject: Re: [clue] Area Scale Millimeters X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 23:03:07 -0000 Ho Christian, Yes, so I believe that in order to support a scale that is linear and consistent between all axis we define some absolute measurement even if we do not call it mm. If we go this way, having a real value like mm will help the receiver to scale and crop since it knows what are the real sizes of the reported areas. The discussion is also about what is the minimum default that should be supported. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Tuesday, October 18, 2011 12:51 AM > To: clue@ietf.org > Subject: Re: [clue] Area Scale Millimeters > > Is the issue that even though we say the scale is "relative" it does in > fact relate to something physical? i.e. in Brian's examples even though > the scale is relative the areas are physically 1/3rd of the room. > > Roni, is your concern that we need to specify that the scale must be > linear and consistent between all axis? > > Regards, Christian > > On 18/10/2011 5:11 AM, Duckworth, Mark wrote: > > > > I agree too. To further clarify a point Roni brought up in the > meeting > > last week, the intent is for the scale to be the same linear scale in > > all dimensions (x,y, z), even if you don't know it is millimeters. So > > the range 0 to 32 has the same length as the range 33 to 65. The > > physical scale would be either millimeters or undefined, not some > > other unit of measurement. > > > > Mark > > > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > Behalf > > Of *Stephen Botzko > > *Sent:* Monday, October 17, 2011 1:31 PM > > *To:* Brian Baldino (bbaldino) > > *Cc:* clue@ietf.org > > *Subject:* Re: [clue] Area Scale Millimeters > > > > I agree. For instance, if you aren't particularly interested in > actual > > size display or gaps between captures, you could simply use capture > > pixels as your relative scale. So it is possible to get some utility > > (e.g. adjacency at least) without any measurements at all. > > > > I expect we would use physical MM scale in our signaling. I'd rather > > know if a far-end is using a true physical scale, or not - since in > > the latter case I would defeat any re-scaling/cropping to get true > size. > > > > Steve B. > > > > On Mon, Oct 17, 2011 at 1:17 PM, Brian Baldino (bbaldino) > > > wrote: > > > > Hey Roni, > > > > Not sure I understand how you're saying that a relative scale > requires > > as much detail as an absolute scale (millimeters). If I don't care > (or > > don't know) the dimensions of my room in millimeters, but I know it's > > divided up into thirds, it's easy for me to describe the 3 areas of > > capture as {(0,32),(33,65),(66,99)} or even {(0,1),(1,2),(2,3)}. Both > > of those areas of capture tell the renderer spatial ordering which > may > > be all that is required for some devices. > > > > -Brian > > > > *From:*clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org ] *On > > Behalf Of *Roni Even > > *Sent:* Sunday, October 16, 2011 12:32 PM > > *To:* clue@ietf.org > > *Subject:* [clue] Area Scale Millimeters > > > > Hi, > > > > The default for Area Scale Millimeters is no physical scale. During > > the Interim meeting my understanding was the even though there is no > > physical scale there is some scale since the numbers reported can be > > used to find the relation in the x direction between the different > > areas and between an area and a gap. For example an area of (0,25) is > > half the size of an area (25,75). > > > > This also imply that x(0,50) is twice the size of y(0,25) for two > > dimension. If this is the understanding also of the authors of the > > draft than I am not sure why it is easier to use no physical scale > > since you need some scale to have the correct proportions between > axis > > > > Regards > > > > Roni Even > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From bbaldino@cisco.com Mon Oct 17 16:10:57 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235BA21F8515 for ; Mon, 17 Oct 2011 16:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Z8y+oBDFsLE for ; Mon, 17 Oct 2011 16:10:54 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E2A1C21F8509 for ; Mon, 17 Oct 2011 16:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bbaldino@cisco.com; l=14789; q=dns/txt; s=iport; t=1318893055; x=1320102655; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=VpTB9x+kRdag2OSSCJJ2BvzdrUXcoNjw37VsV+jYR/k=; b=JflWobNK+ZrcYPrpWExnvxTi11lSR4jOpnzl/e6CFRf3jRq2W5+W+L3r W1Lh+DJbKgtL77KsibsHkwskFH58GA00LvnTjdwTsZ0Qf7wBazQ+KE+TQ 5LI+7wFlzgoiT7UE+gjpwtbHgt5Fv54htBQSYxonqnVE9+krBz9/OPiUY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEAAG21nE6rRDoJ/2dsb2JhbABDgk2WZY8lgQWBbgEBAQQSAQkRA0IXAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqgAwGecYcnYQSIApEpjEM X-IronPort-AV: E=Sophos;i="4.69,362,1315180800"; d="scan'208,217";a="8452700" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 17 Oct 2011 23:10:54 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9HNAsPQ020688; Mon, 17 Oct 2011 23:10:54 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 16:10:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8D22.04E958B6" Date: Mon, 17 Oct 2011 16:10:53 -0700 Message-ID: In-Reply-To: <01cc01cc8d20$0c8cdd90$25a698b0$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Area Scale Millimeters Thread-Index: AcyMOjp9eFtxm2B8TseqXd8lNrjNHgAte/4wAAu95oAAAI23wA== References: <00d601cc8c3a$421e5e20$c65b1a60$%roni@huawei.com> <01cc01cc8d20$0c8cdd90$25a698b0$%roni@huawei.com> From: "Brian Baldino (bbaldino)" To: "Roni Even" , X-OriginalArrivalTime: 17 Oct 2011 23:10:54.0282 (UTC) FILETIME=[05375AA0:01CC8D22] Subject: Re: [clue] Area Scale Millimeters X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 23:10:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8D22.04E958B6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Christian had a good point and I think I mis-spoke a bit. I did not mean to associate them with thirds of the "room", only to imply that they were of equal size. =20 I still see your point though, Roni (about multiple dimensions). But certainly not all endpoints/devices will want to describe themselves in multiple dimensions either, right? I think that forcing implementers to always describe their devices in accurate millimeters will be a burden (and sometimes impossible). =20 =20 -Brian =20 From: Roni Even [mailto:Even.roni@huawei.com]=20 Sent: Monday, October 17, 2011 3:57 PM To: Brian Baldino (bbaldino); clue@ietf.org Subject: RE: [clue] Area Scale Millimeters =20 Brian, This is very easy if you use only one dimension. If you use two dimensions it will mean that 0 to 32 in X direction is the same size as 0 to 32 in the Y direction. I think this will require some unit to do the actual measurement otherwise how does the sender of the information know that they are the same size. A third of the room in X direction is not the same size of third of the room in Y direction. I can agree that relative scale is easier if you are using just X coordinates and want to convey only the spatial order in the X direction. My question was if this is enough as a default information from the sender, my view is that it is not. Having some absolute values will be more helpful for scaling or cropping. Roni =20 =20 From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com]=20 Sent: Monday, October 17, 2011 7:17 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Area Scale Millimeters =20 Hey Roni, Not sure I understand how you're saying that a relative scale requires as much detail as an absolute scale (millimeters). If I don't care (or don't know) the dimensions of my room in millimeters, but I know it's divided up into thirds, it's easy for me to describe the 3 areas of capture as {(0,32),(33,65),(66,99)} or even {(0,1),(1,2),(2,3)}. Both of those areas of capture tell the renderer spatial ordering which may be all that is required for some devices. =20 -Brian =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Sunday, October 16, 2011 12:32 PM To: clue@ietf.org Subject: [clue] Area Scale Millimeters =20 Hi, The default for Area Scale Millimeters is no physical scale. During the Interim meeting my understanding was the even though there is no physical scale there is some scale since the numbers reported can be used to find the relation in the x direction between the different areas and between an area and a gap. For example an area of (0,25) is half the size of an area (25,75).=20 This also imply that x(0,50) is twice the size of y(0,25) for two dimension. If this is the understanding also of the authors of the draft than I am not sure why it is easier to use no physical scale since you need some scale to have the correct proportions between axis Regards Roni Even =20 ------_=_NextPart_001_01CC8D22.04E958B6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Christian had a good point and I think I = mis-spoke a bit.  I did not mean to associate them with thirds of the “room”, = only to imply that they were of equal size.

 

I still see your point though, Roni (about = multiple dimensions).  But certainly not all endpoints/devices will want to = describe themselves in multiple dimensions either, right?  I think that = forcing implementers to always describe their devices in accurate millimeters will be a = burden (and sometimes impossible). 

 

-Brian

 

From:= Roni Even [mailto:Even.roni@huawei.com]
Sent: Monday, October 17, 2011 3:57 PM
To: Brian Baldino (bbaldino); clue@ietf.org
Subject: RE: [clue] Area Scale Millimeters

 

Brian,

This is very easy if = you use only one dimension. If you use two dimensions it will mean that 0 to 32 = in X direction is the same size as 0 to 32 in the Y direction. I think this = will require some unit to do the actual measurement otherwise how does the = sender of the information know that they are the same size. A third of the room in = X direction is not the same size of third of the room in Y = direction.

I can agree that = relative scale is easier if you are using just X coordinates and want to convey only = the spatial order in the X direction.   My question was if this is = enough as a default information from the sender, my view is that it is not. = Having some absolute values will be more helpful for scaling or = cropping.

Roni

 

 

From:= Brian = Baldino (bbaldino) [mailto:bbaldino@cisco.com]
Sent: Monday, October 17, 2011 7:17 PM
To: Roni Even; clue@ietf.org
Subject: RE: [clue] Area Scale Millimeters

 

Hey Roni,

Not sure I understand how you’re saying that a = relative scale requires as much detail as an absolute scale (millimeters).  If I don’t care (or don’t know) the dimensions of my room in millimeters, but I know it’s divided up into thirds, it’s = easy for me to describe the 3 areas of capture as {(0,32),(33,65),(66,99)} or = even {(0,1),(1,2),(2,3)}.  Both of those areas of capture tell the = renderer spatial ordering which may be all that is required for some = devices.

 

-Brian

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Sunday, October 16, 2011 12:32 PM
To: clue@ietf.org
Subject: [clue] Area Scale Millimeters

 

Hi,

The default for Area Scale Millimeters is no = physical scale. During the Interim meeting my understanding was the even though there is = no physical scale there is some scale since the numbers reported can be = used to find the relation in the x direction between the different areas and = between an area and a gap. For example an area of (0,25) is half the size of an = area (25,75).

This also imply that x(0,50) is twice the size of = y(0,25) for two dimension. If this is the understanding also of the authors of = the draft than I am not sure why it is easier to use no physical scale since you = need some scale to have the correct proportions between axis

Regards

Roni Even

 

------_=_NextPart_001_01CC8D22.04E958B6-- From Christian.Groves@nteczone.com Mon Oct 17 21:25:24 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0D111E80CA for ; Mon, 17 Oct 2011 21:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcEwYj06JWg9 for ; Mon, 17 Oct 2011 21:25:24 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id C6A0311E80C8 for ; Mon, 17 Oct 2011 21:25:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAG/9nE520Y3R/2dsb2JhbAAMN6tOAQEBAQMBAQE1GxsKARALGAkWDwkDAgECARUwBg0BBQIBAYgDtxCICASlZg Received: from ppp118-209-141-209.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.141.209]) by ipmail05.adl6.internode.on.net with ESMTP; 18 Oct 2011 14:55:22 +1030 Message-ID: <4E9CFFAF.2090707@nteczone.com> Date: Tue, 18 Oct 2011 15:25:19 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] Raw notes, recordings and some conclusions from CLUE WG Interim meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 04:25:24 -0000 Hello Mary, I'd agree that we should accept the framework document as a WG deliverable. Regards, Christian On 18/10/2011 4:05 AM, Mary Barnes wrote: > Hi all, > > While the chairs are busy (well, Paul really) pulling together the > official minutes, I have uploaded the raw notes to the wiki and > included the links to the recordings: > http://trac.tools.ietf.org/wg/clue/trac/wiki/WikiStart > > We stuck fairly close to the agenda that is on the wiki, except for > the last couple hours on Tuesday. We ended up discussing the way > forward for issues (that Allyn identified in her presentation + others > identified by the group) before the RTCWEB discussion which was very > short. We ended up with time to discuss one of the top 5 issues on > Tuesday (item 1 - Point of View/Areas of Capture). The top 5 issues > (based on feedback from those at the meeting) are summarized here: > http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/WikiStart/9-Framework-Major-Issues-to-discuss-top.ppt > > We were able to discussing the other four issues on Wednesday as > identified in the agenda. > > The summary of all the key issues identified at the meeting (as > discussed at the end of the meeting on Wednesay) along with the > individual that was assigned the action item for the issue is > available here: > http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/WikiStart/Final-Framework%20Major%20Issues.ppt > As far as the actual framework document, there was strong consensus > amongst the attendees (and one individual that survived the meeting > via webex) to accept draft-romanow-clue-framework as the basis for the > WG deliverable. Mark Duckworth will be the assigned editor for the > document. He will be submitting the WG -00 by the deadline. This > update will include some of the basic changes agreed - primarily > editorial. Any conclusions from other issues over the next two weeks > may be reflected in a -01 before the meeting. Otherwise, the remaining > open issues will the focus for discussion at IETF-82. > > Anyone that was not at the meeting that has any concerns with using > draft-romanow-clue-framework as the starting point for the WG > deliverable, please respond on the mailing list detailing your concerns. > > Thanks, > Mary and Paul > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Wed Oct 19 02:06:28 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2D121F8A55 for ; Wed, 19 Oct 2011 02:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.384 X-Spam-Level: X-Spam-Status: No, score=-106.384 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5eVUzCKRbtG for ; Wed, 19 Oct 2011 02:06:27 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8A93D21F89BA for ; Wed, 19 Oct 2011 02:06:27 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTB00A512MP6F@szxga04-in.huawei.com> for clue@ietf.org; Wed, 19 Oct 2011 17:06:25 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTB009ZC2MPU6@szxga04-in.huawei.com> for clue@ietf.org; Wed, 19 Oct 2011 17:06:25 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-199-250.red.bezeqint.net [79.183.199.250]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LTB00LNK2MFPN@szxml11-in.huawei.com>; Wed, 19 Oct 2011 17:06:25 +0800 (CST) Date: Wed, 19 Oct 2011 11:03:50 +0200 From: Roni Even To: clue@ietf.org Message-id: <032b01cc8e3e$0a4bad30$1ee30790$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_T0QWQT0YQmMt35CZrUDyIg)" Content-language: en-us Thread-index: AcyOPgPZguLAE3IhRUG0RGdm6jAYJA== Cc: "'Botzko, Stephen'" Subject: [clue] Definitions for the two multi-view usages X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 09:06:29 -0000 This is a multi-part message in MIME format. --Boundary_(ID_T0QWQT0YQmMt35CZrUDyIg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, The use case draft has a multi-view use case. The term multi-view is not clear since there are two main cases that use the term. I will try to use two different terms that will enable us to differentiate the cases and have the right requirements. My proposal is to use "Multipoint Multiview" and "Stereoscopic Multiview" using the following definitions 1. Multiview as specified in section 3.7 of the use case draft. The definition will be "The multipoint multi-view conference extends the point to point case by having each participant have his own "seat" in a virtual meeting room. This means that each participant will see a different view with a different participant to his left and right side. The participant expect to see a picture that reflects the relative position of the person." 2. Multiview as discussed in Multi View Coding(MVC) which is an amendment to H.264 or in the boarder sense a stereoscopic view. The definition will be "Stereoscopic Multi-view provides two media captures of the same object for creating or enhancing the illusion of depth in an image by presenting two offset images separately to the left and right eye of the viewer." Roni Even --Boundary_(ID_T0QWQT0YQmMt35CZrUDyIg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

The use case draft has a multi-view use case. The term multi-view is not clear since there are two main cases that use the term.

I will try to use two different terms that will enable us to differentiate the cases and have the right requirements. My proposal is to use “Multipoint Multiview” and “Stereoscopic Multiview” using the following definitions

 

1.       Multiview  as specified in section 3.7 of the use case draft.   The definition will be “ conference extends the point to point case by having each participant have his own “seat” in a virtual meeting room. This means that each participant will see a different view with a different participant to his left and right side. The participant expect to see a picture that reflects the relative position of the person.”

2.       Multiview as discussed in Multi View Coding(MVC) which is an amendment to H.264 or in the boarder sense a stereoscopic view.  The definition will be “Stereoscopic Multi-view provides two media captures of the same object for creating or enhancing the illusion of depth in an image by presenting two offset images separately to the left and righ t eye of >

 

Roni Even

--Boundary_(ID_T0QWQT0YQmMt35CZrUDyIg)-- From stephen.botzko@gmail.com Wed Oct 19 04:10:29 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6EE21F8BBA for ; Wed, 19 Oct 2011 04:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEdv3boUsLjY for ; Wed, 19 Oct 2011 04:10:28 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 525EE21F8BB7 for ; Wed, 19 Oct 2011 04:10:28 -0700 (PDT) Received: by vws5 with SMTP id 5so1297935vws.31 for ; Wed, 19 Oct 2011 04:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pyHUBOzFqRso8p9SiX5A235+JU8nIbFr4GjpDkia/II=; b=wzuMR9mup+CxnpbhP3SiqG/SmgXeUte7kDvxziIgM95xw8j9YPaLlI5pq0EJB9H1h3 VGY+YQW03wv/rwle1QfwTkv4nODsjaFLAbjIORZA/oHESWg5BIHwCnUDL9yhNQeGTgzE WDsy+fX3jRKVEwdF59Fbyuv76vGXIHULWmINQ= MIME-Version: 1.0 Received: by 10.52.36.237 with SMTP id t13mr6281365vdj.45.1319022622151; Wed, 19 Oct 2011 04:10:22 -0700 (PDT) Received: by 10.52.187.195 with HTTP; Wed, 19 Oct 2011 04:10:22 -0700 (PDT) In-Reply-To: <032b01cc8e3e$0a4bad30$1ee30790$%roni@huawei.com> References: <032b01cc8e3e$0a4bad30$1ee30790$%roni@huawei.com> Date: Wed, 19 Oct 2011 07:10:22 -0400 Message-ID: From: Stephen Botzko To: Roni Even Content-Type: multipart/alternative; boundary=20cf30780d00d8151904afa4e24b Cc: "Botzko, Stephen" , clue@ietf.org Subject: Re: [clue] Definitions for the two multi-view usages X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 11:10:29 -0000 --20cf30780d00d8151904afa4e24b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I suggest describing the MVC case as "stereoscopic 3D". There are several ways of encoding 3D out there, including side by side and top/bottom mergin= g of images, 2D+depth, and H.264 MVC. At this point we have no need to distinguish them, though of course we will need to ensure that they can be distinguished in the signaling. That might not be CLUE's job anyway. There is at least one other usage of multiview. There are some "multiview displays" that are capable of showing completely different images to the multiple viewers in the room. Some are also 3D, but not they do not have t= o be. This idea was used in the EU telepresence demonstration technology to improve eye contact. In that project, it was combined with both of Roni's Multiviews (though it used 2D+depth, and not H.264 MVC). I think we need a new name for multiview per the use case draft, so we can keep these three usages distinct. Not sure what it should be, though perhaps it should use "camera" or even "capture", since it is really about capturing the same field of view from multiple camera angles. Regards Stephen Botzko On Wed, Oct 19, 2011 at 5:03 AM, Roni Even wrote: > Hi,**** > > The use case draft has a multi-view use case. The term multi-view is not > clear since there are two main cases that use the term.**** > > I will try to use two different terms that will enable us to differentiat= e > the cases and have the right requirements. My proposal is to use =93Multi= point > Multiview=94 and =93Stereoscopic Multiview=94 using the following definit= ions*** > * > > ** ** > > **1. **Multiview as specified in section 3.7 of the use case > draft. The definition will be =93 conference extends the point to point= case > by having each participant have his own =93seat=94 in a virtual meeting r= oom. > This means that each participant will see a different view with a differe= nt > participant to his left and right side. The participant expect to see a > picture that reflects the relative position of the person.=94**** > > **2. **Multiview as discussed in Multi View Coding(MVC) which is an > amendment to H.264 or in the boarder sense a stereoscopic view. The > definition will be =93Stereoscopic Multi-view provides two media captures= of > the same object for creating or enhancing the illusion of depth in an > image by presenting two offset images separately to the left and righ t e= ye > of >**** > > ** ** > > Roni Even**** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --20cf30780d00d8151904afa4e24b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I suggest describing the MVC case as "stereoscopic 3D".=A0 There = are several ways of encoding 3D out there, including side by side and top/b= ottom merging of images, 2D+depth, and H.264 MVC.=A0 At this point we have = no need to distinguish them, though of course we will need to ensure that t= hey can be distinguished in the signaling.=A0 That might not be CLUE's = job anyway.

There is at least one other usage of multiview.=A0 There are some "= ;multiview displays" that are capable of showing completely different = images to the multiple viewers in the room.=A0 Some are also 3D, but not th= ey do not have to be.=A0 This idea was used in the EU telepresence demonstr= ation technology to improve eye contact.=A0 In that project, it was combine= d with both of Roni's Multiviews (though it used 2D+depth, and not H.26= 4 MVC).

I think we need a new name for multiview per the use case draft, so we = can keep these three usages distinct.=A0 Not sure what it should be, though= perhaps it should use "camera" or even "capture", sinc= e it is really about capturing the same field of view from multiple camera = angles.

Regards
Stephen Botzko


On Wed,= Oct 19, 2011 at 5:03 AM, Roni Even <Even.roni@huawei.com> wrote:

Hi,

The use case draft has a mu= lti-view use case. The term multi-view is not clear since there are two mai= n cases that use the term.

I will try to use two different terms that will enab= le us to differentiate the cases and have the right requirements. My propos= al is to use =93Multipoint Multiview=94 and =93Stereoscopic Multiview=94 us= ing the following definitions

=A0

1.=A0=A0=A0=A0=A0=A0 Multiview=A0 as specified in section 3.7 = of the use case draft.=A0=A0 The definition will be =93 conference extends the point to point case by having each participant have= his own =93seat=94 in a virtual meeting room. This means that each partici= pant will see a different view with a different participant to his left and= right side. The participant expect to see a picture that reflects the rela= tive position of the person.=94

2.= =A0=A0=A0=A0=A0=A0 Multiview = as discussed in Multi View Coding(MVC) which is an amendment to H.264 or in= the boarder sense a stereoscopic view.=A0 The definition will be =93Stereo= scopic Multi-view provides two media captures of the same object for creating or enhancing the illusion of depth in an image by pres= enting two offset images separately to the left and righ t eye of >

=A0

Roni Even


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


--20cf30780d00d8151904afa4e24b-- From stewe@stewe.org Wed Oct 19 13:35:59 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F99921F8997 for ; Wed, 19 Oct 2011 13:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIEiqZ594pi5 for ; Wed, 19 Oct 2011 13:35:59 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 920EE21F84E1 for ; Wed, 19 Oct 2011 13:35:53 -0700 (PDT) Received: from [192.168.1.64] (unverified [71.202.147.60]) by stewe.org (SurgeMail 3.9e) with ESMTP id 51451-1743317 for ; Wed, 19 Oct 2011 22:35:50 +0200 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Wed, 19 Oct 2011 13:35:20 -0700 From: Stephan Wenger To: "clue@ietf.org" Message-ID: Thread-Topic: [clue] Kick-Off Item 5: description of composed pictures In-Reply-To: Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3401876150_7780812" X-Originating-IP: 71.202.147.60 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.147.60) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [clue] Kick-Off Item 5: description of composed pictures X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 20:35:59 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3401876150_7780812 Content-type: multipart/alternative; boundary="B_3401876150_7768730" --B_3401876150_7768730 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Mike, Not sure this is going through to the list, due to the size of the attachment. But let's try. Attached is a little hand-drawing that hopefully helps understanding what I am shooting for. Consider a three way conference. The two "capturing" rooms, depicted on the left side, have two cameras each, capturing scenes one and two (for the first room), and four and five (for the second room), respectively. The captured content is encoded by encoders marked "E" to create RTP streams 1, 2, 4, and 5. RTP streams 1 and 2 (from the first room) terminate an an MCU, which composes them into a composed picture 3, encoded into RTP stream 3. The composed picture contains 1 and 2 side-by-side, plus grey bars on top and bottom. The monitors of the receiving third endpoint are shown on the right side. Streams 4 and 5 go straight to the two decoders of the main projection wall. Stream 3 (created by the MCU) goes through a side decoder to a third monitor (could be the monitors that many telepresence rooms have for each participant, a monitor normally dedicated for shared content, what not). This monitor shows the composed image. The CLUE architecture allows perfectly well to describe the capture properties of streams 4 and 5. However, at present, the MCU hides the capture properties of streams 1 and 2. Similarly, the MCU hides the render properties of the decoder/display of stream 3. Accordingly, the geographic parameters of captures 1 and 2 are not known at decoder 3, and, if that decoder would want to do something a bit more sophisticated than just decoding and displaying on the screen, it couldn't because it lacks info. One of this "more sophisticated" things could, for example be as follows. Suppose the endpoint capturing 4 and 5 drops out of the call. The video wall of the rendering endpoint goes blank. It would be desirable if the info from 1 and 2 would be rendered on the video wall instead of the side screen. One sensible way to do that would be that the stream 3 is feed into both decoders responsible for the video wall, but "cut out" and upscale the content from the composed picture created by the MCU, before rendering. (There may be technical reasons for the presence of the MCU beyond the fact that there are only three decoders at the receiving side). However, that's not possible as the nature of stream 3 (being composed form 1 and 2) is not visible at the rendering endpoint. My proposal is to add information related to the captures inside a composed stream (beyond that one flag that says the stream is composed). Clearer? Stephan From: Michael Hammer Date: Sat, 15 Oct 2011 13:03:07 -0400 To: Stephan Wenger Cc: "clue@ietf.org" Subject: Re: [clue] Kick-Off Item 5: description of composed pictures Stephan, You use monitor as both input and output device. I hope that is not embedded in the scheme. The rest of this email seems to focus only on input definitions as it probably should. Don't understand the comment about 3-D followed by coordinates in 3-D. It seems like 3-D is fundamental. Do I understand correctly that the camera coordinates define the location of the lense, while the bitstream is abstraction of the pixel layout for some abstraction (via ray-tracing?) of a window? Or is the camera coordinates defining some virtual window in space that through some changes in focal length could be a closeup and those farther from the camera and narrower field of view versus wider angel and closer to the lense with greater field of view? When talking about spatial things, perhaps a picture would help save a thousand words. Also, I would think that what a renderer or MCU would do could be a second discussion once the capture scheme is better understood. (Understand that the impacts of those might drive some iterations on the basic scheme.) Mike On Fri, Oct 14, 2011 at 11:02 PM, Stephan Wenger wrote: > Hi, > > Here is the kickoff message as agreed in our F2F. > > We are in the process of defining a mechanism that allows us to tag in room > "coordinates" of captures to RTP streams. In its most trivial incarnation, > that would allow us to assign the decoded RTP streams to devices such as > individual monitors. > > RTP comes from system 1, camera coordinates x, y, z, upper right x, y, > z, lower left x, y, z > RTP comes from system 1, camera coordinates (something else) > > Note that we probably need a third and even a fourth point for faithfully > specifying a capture in 3D space, but that's not the subject of this email, so > don't beat me up on it right now. > > As for the capabilities of a renderer (not defined in the framework yet), it > should be clear that a monitor can trivially display more than one decoded RTP > stream. Insofar, the mapping should be per part of a virtual display wall (or > however you want to call it), and not per physical screen. I would hope that > this is uncontroversial. > > Things become more tricky when there is a video mixing MCU in the picture, or > when an endpoint creates a single RTP stream that contains information from > multiple camera devices (through tiling, picture-in-picture). Here, we cannot > meaningfully tag the a single geographic information to a single RTP stream > simply because the multiple video sequences were mixed at the sample level, > and the encoder didn't have a clue that it is actually encoding data stemming > from more than one camera. However, the endpoint system (or the MCU) know the > geographic metadata associated with the composed picture. So what I'm > proposing is that we allow a single RTP stream to have more than one geometric > information about the capture involved. For video, one would probably have to > associate regions of the reconstructed video stream (in the spatial dimension) > with capture geographic information as currently proposed in the framework. > > Example: a sending endpoint creating ONE RTP stream which includes TWO > captures, tiled horizontally > > RTP { > bitstream coordinates x=0 to 959, y=0, to 1080 , comes from system 1, > camera coordinates x, y, z, x, y,z x, y, z > bitstream coordinates x=960 to 1919, y=0 to 1080, comes from system 1, > camera coordinates (something else) > } > > Architecturally, this system would best need to be recursive, as it ought to > be possible to throw an already composed image from MCU1 at the input of MCU2, > which scales it down and composes it with other images to other ports. > > Clear enough? > > Thanks, > Stephan > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --B_3401876150_7768730 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Mike,

Not sure this is going through to the list, due to the size of the attach= ment.  But let's try.

Attached is a little han= d-drawing that hopefully helps understanding what I am shooting for.
Consider a three way conference.  The two "capturing" rooms, depicte= d on the left side, have two cameras each, capturing scenes one and two (for= the first room), and four and five (for the second room), respectively. &nb= sp;The captured content is encoded by encoders marked "E" to create RTP stre= ams 1, 2, 4, and 5.
RTP streams 1 and 2 (from the first room) term= inate an an MCU, which composes them into a composed picture 3, encoded into= RTP stream 3.  The composed picture contains 1 and 2 side-by-side, plu= s grey bars on top and bottom.  
The monitors of the receivin= g third endpoint are shown on the right side.  Streams 4 and 5 go strai= ght to the two decoders of the main projection wall.  Stream 3 (created= by the MCU) goes through a side decoder to a third monitor (could be the mo= nitors that many telepresence rooms have for each participant, a monitor nor= mally dedicated for shared content, what not).  This monitor shows the = composed image.

The CLUE architecture allows perfec= tly well to describe the capture properties of streams 4 and 5.  Howeve= r, at present, the MCU hides the capture properties of streams 1 and 2. &nbs= p;Similarly, the MCU hides the render properties of the decoder/display of s= tream 3.  Accordingly, the geographic parameters of captures 1 and 2 ar= e not known at decoder 3, and, if that decoder would want to do something a = bit more sophisticated than just decoding and displaying on the screen, it c= ouldn't because it lacks info.

One of this "more so= phisticated" things could, for example be as follows.  Suppose the endp= oint capturing 4 and 5 drops out of the call.  The video wall of the re= ndering endpoint goes blank.  It would be desirable if the info from 1 = and 2 would be rendered on the video wall instead of the side screen.  = One sensible way to do that would be that the stream 3 is feed into both dec= oders responsible for the video wall, but "cut out" and upscale the content = from the composed picture created by the MCU, before rendering.  (There= may be technical reasons for the presence of the MCU beyond the fact that t= here are only three decoders at the receiving side).  However, that's n= ot possible as the nature of stream 3 (being composed form 1 and 2) is not v= isible at the rendering endpoint.

My proposal is to= add information related to the captures inside a composed stream (beyond th= at one flag that says the stream is composed).

Clea= rer?

Stephan    





From: Michael Hammer <m= phmmr@gmail.com>
Date: Sat,= 15 Oct 2011 13:03:07 -0400
To: St= ephan Wenger <stewe@stewe.org>Cc: "= clue@ietf.org" <clue@ietf.org><= br>Subject: Re: [clue] Kick-Off Item = 5: description of composed pictures

Stephan,
 
You use monitor as both input and output device.&nb= sp; I hope that is not embedded in the scheme.
The rest of this em= ail seems to focus only on input definitions as it probably should.
 
Don't understand the comment about 3-D followed by coordi= nates in 3-D.  It seems like 3-D is fundamental.
 
=
Do I understand correctly that the camera coordinates define the locati= on of the lense, while the bitstream is abstraction of the pixel layout for = some abstraction (via ray-tracing?) of a window?
 
= Or is the camera coordinates defining some virtual window in space that thro= ugh some changes in focal length could be a closeup and those farther from t= he camera and narrower field of view versus wider angel and closer to the le= nse with greater field of view?
 
When talking abou= t spatial things, perhaps a picture would help save a thousand words.
<= div> 
Also, I would think that what a renderer or MCU wo= uld do could be a second discussion once the capture scheme is better u= nderstood.  (Understand that the impacts of those might drive some iter= ations on the basic scheme.)
 
Mike

On Fri, Oct 14, 2011 at 11:02 PM, Stephan Wenger <stewe@stewe.org> wrote:
Hi= ,

Here is the kickoff message as agreed in our F2F.=

We are in the process of defining a mechanism that= allows us to tag in room "coordinates" of captures to RTP streams.  In= its most trivial incarnation, that would allow us to assign the decoded RTP= streams to devices such as individual monitors.

RT= P <id#1> comes from system 1, camera coordinates x, y, z, upper right = x, y, z, lower left x, y, z 
RTP <id#2> comes from syst= em 1, camera coordinates (something else)

Note that= we probably need a third and even a fourth point for faithfully specifying = a capture in 3D space, but that's not the subject of this email, so don't be= at me up on it right now. 

As for the capabili= ties of a renderer (not defined in the framework yet), it should be clear th= at a monitor can trivially display more than one decoded RTP stream.  I= nsofar, the mapping should be per part of a virtual display wall (or however= you want to call it), and not per physical screen.  I would hope that = this is uncontroversial.

Things become more tricky = when there is a video mixing MCU in the picture, or when an endpoint creates= a single RTP stream that contains information from multiple camera devices = (through tiling, picture-in-picture).  Here, we cannot meaningfully tag= the a single geographic information to a single RTP stream simply because t= he multiple video sequences were mixed at the sample level, and the encoder = didn't have a clue that it is actually encoding data stemming from more than= one camera.  However, the endpoint system (or the MCU) know the geogra= phic metadata associated with the composed picture.  So what I'm propos= ing is that we allow a single RTP stream to have more than one geometric inf= ormation about the capture involved.  For video, one would probably hav= e to associate regions of the reconstructed video stream (in the spatial dim= ension) with capture geographic information as currently proposed in the fra= mework.

Example: a sending endpoint creating ONE RT= P stream which includes TWO captures, tiled horizontally

RTP <id#2> {
    bitstream coordinates x=3D0 t= o 959, y=3D0, to 1080 , comes from system 1, camera coordinates x, y, z, x, y,= z x, y, z
    bitstream coordinates x=3D960 to 1919, y=3D0 t= o 1080, comes from system 1, camera coordinates (something else) 
=
}

Architecturally, this system would best need= to be recursive, as it ought to be possible to throw an already composed im= age from MCU1 at the input of MCU2, which scales it down and composes it wit= h other images to other ports.

Clear enough?
<= div>
Thanks,
Stephan


_= ______________________________________________
clue mailing list
clue@ietf.org
https://w= ww.ietf.org/mailman/listinfo/clue


<= /body> --B_3401876150_7768730-- --B_3401876150_7780812 Content-type: image/jpeg; name="clue-stephan.jpg" Content-disposition: attachment; filename="clue-stephan.jpg" Content-transfer-encoding: base64 /9j/4AAQSkZJRgABAQEBLAEsAAD/4QCMRXhpZgAATU0AKgAAAAgABgEGAAMAAAABAAIAAAES AAMAAAABAAEAAAEaAAUAAAABAAAAVgEbAAUAAAABAAAAXgEoAAMAAAABAAIAAIdpAAQAAAAB AAAAZgAAAAAAAAEsAAAAAQAAASwAAAABAAKgAgAEAAAAAQAACbCgAwAEAAAAAQAADJwAAAAA /9sAQwAgFhgcGBQgHBocJCIgJjBQNDAsLDBiRko6UHRmenhyZnBugJC4nICIropucKDaoq6+ xM7Qznya4vLgyPC4ys7G/9sAQwEiJCQwKjBeNDRexoRwhMbGxsbGxsbGxsbGxsbGxsbGxsbG xsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbG/8AAEQgMnAmwAwEiAAIRAQMRAf/EAB8A AAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAE EQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNE RUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeo qaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8B AAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMR BAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpD REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwD AQACEQMRAD8A36WiigBhUFuadgelJj56WgQYHpRgelFFAwwPSjA9KKKADA9KMD0oooAMD0pG AIpaRulAgwMdKXA9KB0ooGGB6UbR6UUtACbR6Um0elOpKAE2j0o2j0paWgBu0elIqqR0px6U 2PpQIXaPSjaPSlooGJtHpRtX0paKBWE2j0o2j0paKAsJtHpRtHpS0UDsNKgsKXaPSjHzUtMV hNo9KNo9KWikAm0elG0elLS0BYbtHpRtHpTqSgLCbR6UjKNvSnU2T7tMGKFGOlG0elC9KWkF hNo9KNo9KWigLCbR6UbF9KWigLCbF9KNq+lLRzQAm0elIqjJ4p3NNXOTTAXaPSjaPSlopBYT aPSjYvpS0UBYTYvpRsX0paKAsJsX0o2L6UtFAWGMgLCnbF9KQ/eFOp3CyE2L6UbF9KWikFhN o9KNi+lLRQFhNi+lGxfSlooCwmxfSkKDBwKdSN0phZDVjGOaXYvpSr90UtFwshNi+lGxfSlo pBYTYvpRsHpS0UBYTYvpRsX0paKAshNi+lNVBuNPpi53mmDSHbF9KNi+lLRSCwmxfSjYvpS0 UBYbsX0o2Cn0lFwshvlr6UuwUtFFwshjIDjFO2ChuopadwshvlrS7BTqKVwshmwUbBT6KLhZ DPLFHlinUtFwshmwUbBin0h6U7hZDVQY55o2ClXpS0XCyG7BR5Yp1FFwshuwUbBTqKVwshuw UbBTqWi4WQ3YKbs+brUlN530wshNgo2CnUUrhZDdgo2D3p1FFwshuweppdvuaWigLIbs9zRs 9zTqWi4WRE6dME04IMd6V+1LTuFlcbsFGwe9OopXCyG7B70bB706ii4WQ3YPU0bPc06ii4WQ 3yx6mjYPU06g9KdwshipxySaXYPU0q9KWi4WQ3YPU0bB6mnUUrhZDdg9TRs9zTqKdwshuwep o2D1NOopXCyG7Pc0mz5upxT6T+KncLITZ7mjZ7mnUUgshuz3NHl+5p1FO4WQ3Z7mjZ7mnUUg sN2f7Ro2e5p1LQFiNlI6Gl2+5pW6UophYbsPqaNh/vGnUUgsN2e5o2+5p1LQFhmz/aNGw/3j TqKAsN2H+8aNvuadRQFiNVY5yadsP940qd6dTBIZsPqaNnuafSUgsN2n+9RsP96nUtAWGbT/ AHqNh/vGnUUwsN2H1NIVbPDVJTT96gLCbT60bT/eNPopBYZtPrRtP940+igLDNp9aAp/vU6i mFhu0/3qNp/vU6ikFhjKccGlCtj71K3SlphYbtP940bT/ep1FILDdp/vUbT606imFhu0+tG0 /wB6nUUgsN2n+9QVOPvU6igLEYVj1NO2n+8aUHrS0wsN2n+9RtP96nUUBYbtb+9RtP8Aep1L SCwzaf71G1v71PpKAsN2n+9TWD7hg1JTW+8KYmg2t/eo2n+9TqKB2G7W/vUbW/vU6ikFhu1v 71G1v71OooCw3a396gK396nUUBYYQ2OGoAbHLU5jxSjpTCw3a396jDetOopBYbhvWja396nU tAWI9rf3qXa396nUUwsN2t/eo2n1p1FILDAHz14pdp/vUoPJpaYWG7W/vUbW/vU6lpBYZtb+ 9Rtb+9T6KAsM2t/eo2t/ep1FAWG7W/vUjBgRg5p9IeophYTa3rSbW/vU+igLDdrf3qMN606l pBYZtb+9RhvWnUUBYbtb1ow396nUUBYYQwHWkUORyakPQ0in5RTCwm1v71GG/vU6ikFhuG9a MN606igLDcN60Yb1p1LQFhmG/vUbW/vU6igLEfz7sA07Df3qUHk0tMLDcN60Yb1p9FILDNrf 3qMN60+koCw3DetGG9adS0BYZhvWkYOOhp9IT0phYTDetGG9adRSCw3a3rRtb1p1FAWG4b1o w3rTqKAsNw3rRhvWnUtAWGYb1pBv9RTzQvSmFhuG9aMN60+kpBYbh/UUYb1p9FAWGYf1FGG9 afRQFhmG9RRhvWn0lAWI/n3YyKdhvWlz89LTBIbhvWjDetOpaQWGYf1FJh/UU+igLDcN6ijD +op1FAWGgN3NIdwHXNPpG6UBYQbyOcUYf1FOooCw3Deoow3qKfSUBYb83qKMP6inUUBYbh/U UYb1p1FAWG4b1FNG8+1SUimmFhMN60mHz1FPpaQWGYfHUUYf1p1FAWG4b1FGH9RT6KAsMw/q KMN60+igLEZ3A4pcN60pPzClphYaQ/qKPm9qdRSCw3Deoow1OooCw3DetHz+op1LQFhmG9RS NuAzmn02T7tNA0OHIpaav3RTqQwooooAKKKKACiiigAooooAb/FTqb/FTqACiiigAooooAKK KKACmt0p1NbpQAvalpB0paACiiigAooooAKKKKAEpqdKdSJ0oEOooooGFFFFABRRRQAUUUUA NP3qdTf4qdQAUUUUAFFFFABRRRQAUx/u0+mSfdoQmOXoKWkHSloGFFFFABRRRQAUUUUAFNXq adTV6mgB1FFFABRRRQAUUlLQAUUUUANP3hTqafvCnUCCiiigYUUUUAFFFFABSHpS0h6UAC9K KRfuinUAFFFFABRRRQAUUUUAJTV++1Opq/eNAmPooooGFFFFABRRRQAUUUUANbqKdTW6inUA FFFFABRRRQAUUUUAFIelLSHpQAi9KdTV6U6gAooooAKKKKACiiigApo+9TqaPvGgB1FFFABR RRQAUUUUAFFFFADW7U6mP2p9AgooooGFFFFABRRRQAUhpaTtQAi9KdTV6U6gAooooAKKKKAC iiigApv8VOpv8VADqKKKACiiigAooooAKKKKAGt0paRulLQAtFFFABRRRQAUUUUAFJS0hoAa nen0xOhp9AkFFFFAwooooAKKKKACmn71Opp+9QA6iiigAooooAKKKKACiiigBG6UChulAoAW iiigAooooAKKKKACiiigBB3paaO9OoAKKSloAKKKKACiiigBKQ/eFLTW+8KBD6KKKBhRRRQA UUUUAFFFFACHpQOlDdKB0oAWiiigAooooASloooAKKKKAGjqadTR1NOoAKKKKACiiigAoooo AKaeop1NPUUAOooooAKKKKACiiigAooooAQ9KB0obpSL90UAOooooAKKKKACiiigAooooAaO pp1NH3jTqACiiigAooooAKKKKACmt2p1Ie1AC0UUUAFJS0UAFFFFABRRRQAlA6UGhelAC0lL SUALRRRQAUUUUAFFFFADf46dTf46dQJBRRRQMKKKKACiiigBKRulOprdKAF7UtJS0AFFFFAB SUtFABRRRQAlC0UCgBaKKKACiiigAooooAKKKKAGn7wp1NP3qdQIKKKKBhRRRQAUUUUAFMf7 tPpj/doQnsOHSlpB0FLQMKKKKACiiigAooooAKKKKAG/xU6m/wAVOoAKKKKACiiigAooooAK a3SnU1ulAC9qWkpaACiiigAooooAKKKKAEpE6UtInQ0CHUUUUDCiiigAooooAKKKKAG/xU6m /wAVOoAKKKKACiiigAooooAKa/3adTX+7QDFHSlpB0paACiiigAooooAKKKKACmr1NOpq9TQ A6iiigAooooAKKKKACiiigBp6inU09RTqACiiigAopKWgAooooAKRulLSN0NACL90UtC9BRQ AtFFFABRRRQAUUUUAFMX7xp9MX75oEPooooGFFFFABRRRQAUUUUANbqKdTG6in0CCiiigYUU UUAFFFFABSHpS0h6UAIvSnU1fu06gAooooAKKKKACiiigApo++adTf4qAHUUUUAFFFFABRRR QAUUUUAMftT6a/anUCCiiigYUUUUAFFFFABSGlpDQAi9KdTV6U6gAooooAKKKKACiiigApv8 dOpv8VADqKKKACiiigAooooAKKKKAGt0paRulLQAtFFFABRRRQAUUUUAFJS0lADU70+mJ3p9 AkFFFFAwooooAKKKSgBaafvU6mn7woAdRRRQAUUUUAFFFFABRRRQAjdKBQ3SigBaKKKACiii gAooooAKKKKAGr3p1NXvTqAEpaKKACiiigAooooASmt94U+mN94UCY+iiigYUUUUAFFFFABR RRQAjdKB0obpQOlAC0UUUAFFFFACUtFFABRRRQA0dTTqaOpp1ABRRRQAUUUUAFFFFABTT1FO pp6igB1FFFABRRRQAUUUUAFFFFACN0pF+6KVulIv3RQIdRRRQMKKKKACiiigAooooAaOpp1N H3jTqACiiigAooooAKKKKACmt2p1NbtQA6iiigAooooAKKKKACiiigBDQvSg0L0oAWiiigAo oooAKKKKACiiigBn8dPpv8dOoEgooooGFFFFABRRRQAU1ulLSN0oAWlpKWgAooooAKKKKACi iigBKBRSL3oAdRRRQAUUUUAFFFFABRRRQA0/eFOpp+8KdQIKKKKBhRRRQAUUUUAFMf7tPpr/ AHaBMUdKWkHSloGFFFFABRRRQAUUUUAFFFFADf46dTf4qdQAUUUUAFFFFABRRRQAU1ulOpG6 UAFLSUtABRRRQAUUUlAC0UUUAJSL0paRelADqKKKACiiigAooooAKKKKAG/xU6m/xU6gAooo oAKKKKACiiigApr/AHadTW6UCYo6UtIOlLQMKKKKACiiigAooooAKavU06mr1NAh1FFFAwoo ooAQ0tFFABRRRQA0/eFOprfeFOoEFFFFAxKWiigAooooAKQ9KWkPSgAXpS0i9KWgAooooAKK KKACiiigApi/fNPpg++aBMfRRRQMKKKKACiiigAooooAa3UU6mt1FOoAKKKKACiiigAooooA KQ9KWkPSgBF6U6mr0p1ABRRRQAUUUUAFFFFABTf46dTR940AOooooAKKKKACiiigAooooAY/ an0x+1PoEFFFFAwooooAKKKKACk7UtJQAi9KdSL0paACiiigAooooAKKKKACm/xU6m/xUAOo oooAKKKKACiiigAooooAa3SlpH6UooAWiiigAooooAKKKKACkpaKAGJ3p9MTvT6BIKKKKBhR RRQAUUUUAFNP3hTqafvCgB1FFFABRRRQAUUUUAFFFFACN0oFDdKKAFooooASloooAKKKKACi iigBq96dTR1NOoAKKSloAKKKKACiiigBKa33hTqQ/eFAmOooooGFFFFABRRRQAUUUUAI3Sgd KG6UDpQAtFFFABRRRQAUUUUAFFFFADR1NOpq9TTqACiiigAooooAKKKKACmnqKdTT1FADqSl ooAKKKKACiiigAooooARulIv3RSt0pF6CgQ6iiigYUUUUAFFFFABRRRQAg+8aWmjqadQAUUU UAFFFFABRRRQAU1u1OprdqAHUUUUAFFFFABRRRQAUUUUAIaF6UHpQvSgBaKKKACiiigAoooo AKKKKAGfx06k/jpaBIWiiigYUUUUAFFFFABTW6U6mt0oAWlpB0paACiiigApKWkoAWiiigBK Re9LSL3oAdRRRQAUUUUAFFFFABRRRQA0/eFOpp+8KdQAUUUUAFFFFABRRRQAU1/u06mP92gT HDpS0g6UtAwooooAKKKKACiiigAooooAYSA/NOyPWmMgZuaXy1pi1HZHrRmm+WKNg96A1HZo yKbsFGwUg1HZozTfLFGwUw1HZpGOBSbBQVGKA1FBBHWlpvlil2CgNRaKbsHvRsHvSDUdmjNN 2Cjyx70w1HZozTdg96Ng96Qajqap4o2DHekVB6mmGo+im7B6mjYPU0g1HUU3YPU0bB6mmGo6 jNN2D1NGweppBqOzRTdg9TQEA7mgNQLDdinZqNo8sOad5Y9TT0Emx1FN8v3NGz3NA9R1FN2e 5o2e5pBqOopuz3NGz3NAajs01zhaNnuaR0yOppoHceDxRTAnHU0uz3NAajqKbs9zRs9zQGo6 im7P9o0bPc0BqOopuz3NHl+5oDUdSKRk0m33NN8vLE5oFdklFN2H+8aNnuaB6jqKbs9zRsPq aAux1FNKe5o2H+8aAux1FN2H+8aNh/vGgLik/MKWo2Q5HNO2H+8aAux1FN2H+8aNhz940Bcd RTAhz940uw5+8aAux1GabsP940bD/eoC7HUHpTdh/vUhU7etAXHLjHFLUaxkDrS7D/eNArsf RTdh/vUbD/eNAx1FN2n1o2t/eoAdRTSh/vUbT/eoAdTV+8aNp/vU0K24/NQJskopuxv71G1v 71Ax1FN2n+9Rtb+9SAfSU3a396ja396gLjqWo9rf3qXa396mFxW6ilqN1bjBpQr/AN6iwrj6 Kbtb+9QVb+9QO46im7W/vUbW/vUBcdS1Htb+9ShW/vUBcdQelN2t/eoIbHWgLir0paiVX7HF O2t/eoEmSUlN2t60bW/vUDuPopm1v71G1vWkFx9FM2t/eo2t60BcdSD7xpMN603a2/g0wbJa SmbX/vUbX9aQXH0Uza+eopcN6imFx1FNw/qKTa/rQFx9FNw3rRhvUUguK3alqOQNilCv607C vqPopuH9RQQ/Yigdx1FNw3qKMP6igLjqKZh/UUuG9RQFx1FMAf1FLhsc4oC44dKKjUP26U75 /agLjqKb83tS/NSC4tFNw3tR8/tQFx1FN+f2o+f2oC46k/ipPn9qYd+/inYTZNSUz5/al+f2 pDuOopvz+1Hz+1AXHUU35/aj5/agLjqKb8/tR8/tQFxW6UtRvv20o34p2FfUfS1H+89qX5/a kO46im/N7UfNQFx1FN+f2o+f2oC46im/P7UfP6CgLir3paiXfk4FP+f0FOwkx1FN+f2o+f0F Idx9FM+b0FHzelAXH0Uz5/QUfP6CgLjqT+IUnz+1MO/cMCnYGyaimZf0FJ8/oKQXJKKZ8/oK Pn9BQFx9JTcv6UmX9KAuSUUzL+goy3pQFxx6UVG5bHSlUvjpTsFySimZb0oy3pSC4+imZb0o +b0oC4+imfN6CjL+goC4+imAv6UZb0oC4o706oVL7jxTsv6U7CTH0tMBf0oy3pSHcfRTMt6U Zb0oC4+imZb0oy3pQFx9NP3hSZb0pjswI4ppCbJqKjBf+7S5b0pDuPopmW9KMt6UBcfRTMt6 UZb0oC4+kpuW9KQFv7tMLjz0oHSmOW2nihWbb92iwX1JKKjy/wDdpct6UguPoqPc/pS5f+7Q Fx9FRkv/AHaMv6UwuSUUzLelGW9KQXFHU06oQz78Yp25v7tOwrklFMy392jc392gdx1LUe5v 7tKC392gLj6KZub+7RlvSkFx9NPUUm5v7tNctxxTBslpKZub+7RufP3aLBckopmW/u0Zb+7Q Fx9FM3N/do3N/doC4+imZb+7Rub+7QFxx6GkX7oprMcdKRXbH3aLCvqS0VGGb+7S7m/u0DuP opm5v7tJub+7QFySimbm/u0m5v7tAXH0Uzc392l3N/doC4o60tRbiHPH4U7e392iwrofRTNz f3aXc392gdx1FN3N/do3N/doC46imbm9KXcf7tAXHUhpNzf3aa7NxxRYGySimb2/uml3N/do sFx9JTNzf3aNzZ+7RYLj6Kbub+7RuP8AdoC46im7m/u0bj/dNAXHUDpTdx9DTVc4+6aLBcko pm9v7po3H+6aLBcfRTN7f3TS7z/dNKwXHUU3ef7po3n+6aYXH0Uzef7po3n+6aQXF/jpahZy Hzin7z/dNOwkySkpm8/3TS7z/dNIdx2aWmbz/dNG8/3TQF0Popm8+hpC5/umgLklNbpTd5/u mhmO3oadguPoqMSEj7ppd5/umiwXRJRUe8/3TSlz6UrBcdRTd5/umk3n+6aYXH0U3cf7po3n +6aAuh9NWk3H0poYjPBosFyWimbj6GjcfQ0rBcdRTdx/umkDn+6aYXJKKZvP900bj6UguPop m8/3TRuPoaAuKfvCnVCzkMOKdvP9007CuiSio95/uml3n+6aVh3H0UzefQ0bj/dNFguPopm4 /wB00bz/AHTQFx9Nf7tJvP8AdNNdzjpTsJskHSlpF6UtIoKKKKACiiigAooooAKKKKAG/wAV Opv8VOoAKKKKACiiigAooooAKa3SlpG6UAL2paTtS0AFFFFABRRRQAUUUUAJSL0paRelADqK KKAEpaSloAKKKKACiiigBv8AFTqb/FTqACiiigAooooAKKKKACmv92nU1/u0CYo6UtIOlLQM KKKKACiiigAooooAKavU06mr1NADqKKKACiiigBKWkpaACiiigBp6inU0/eFOoAKKKKAEpaS loAKKKKACkPSlpD0oAB0paRelFAC0UUUAFFFFABRRRQAUxfvGn0xfvGgQ+iiigYUUUUAFFFF ABRRRQA09RTqa3UU6gAooooAKKKKACiiigApD0paQ9KABelLTV6U6gAooooAKKKKACiiigAp o+8adTR940AOooooAKKKKACiiigAooooAa3anU1u1OoEFFFFAwooooAKKKKACkNLSdqAEXpT qavSnUAFFFFABRRRQAUUUUAFN/ip1N/ioAdRRRQAUUUUAFFFFABRRRQA1ulLSP0pRQAtFFFA BRRRQAUUUUAFFFJQAi9DTqavenUAgooooAKKKKACiiigApO9LTT94UAOooooAKKKKACiiigA ooooARulFDdKKAFooooAKKKKACiiigAooooAQd6WmjvTqACiiigAooooAKKKKACmnqKdTT94 UAx1FFFABRRRQAUUUUAFFFFACHpQOlDdKB0oAWiiigAooooAKKKKACiiigBo6mnU0dTTqACi iigAooooAKKKKACmnqKdTT1FADqSlooAKKKKACiiigAooooAQ9KRegpW6Ui/dFAuo6iiigYU UUUAFFFFABRRRQA0feNOpo6mnUAFFFFABRRRQAlLRRQAU1u1OprdqAHUUUUAFFFJQAtFFFAB RRRQAlA6UUL0oAWiiigAooooAKKKKACiiigBnG+n03+OnUCQUUUUDCiiigAooooASkbpTqa3 SgBR0paSloAKKKKACkpaSgBaKKKACmr3p1NXvQA6iiigAooooAKKKKACiiigBp+8KdTT94U6 gQUUUUDCiiigAooooAKY/wB2n01/u0CYo6UtIOlLQMKKKKACiiigAooooAKKKKAG/wAdOpn8 dPoEgooooGFFFFABRRRQAU1ulOprdKAFpaSloAKKKKACiiigAooooASkXpSmkTpQA6iiigAo pKWgAooooAKKKKAG/wAVOpv8VOoAKKKKACiiigAooooAKa/3adTH+7QJjh0paQdKWgYUUUUA FFFFABRRRQAU1epp1MTqaBD6KKKBhRRRQAUUUUAFFFFADW+8KdTT94U6gQUUUUDCiiigAooo oAKQ9KWkPSgAXpRQOlLQAUUUUAFFFFABRRRQAlNX7xp1NX7xoEPooooGFFFFABRRRQAUUlLQ A1uop1NbqKdQAUUUUAFFFFABRRRQAUh6UtIelACL0p1NXpTqACiiigAooooAKKKKACmj7xp1 NH3zQA6iiigAooooAKKKKACiiigBj9vrT6a/anUCCiiigYUUUUAFFFFABSHpS0h6UAIvSnU1 elOoAKKKKACiikoAWiiigApv8VOpP4qAFooooAKKKKACiiigAooooAa3SlpG6UtAC0UUUAFF FFABRRRQAUlLSUANTvT6Ynf60+gSCiiigYUUUUAFFFFABTf4qdTf4qAHUUUUAFFFFABRRRQA UUUUAI3SihulFAC0UUUAFFFFABRRRQAUUUUANHenUg70tABRRRQAUUUUAFFFFACUh+8KWkb7 woEx1FFFAwooooAKKKKACiiigBG6UDpSN0pR0oAWiiigAooooAKKKKACiiigBq9TTqaOpp1A BRRRQAUUUUAFFFFABTT1FOprdRQA6iiigAooooAKKKKACiiigBG6UifdFKelC/dFAuotFFFA wooooAKKKKACiiigBo+8adTR9406gAooooAKKKKACiiigAprdqdTW7UAx1FFFABRRRQAUUUU AFFFFACGhelB6UL0oAWiiigAooooAKKKKACiiigBv8dLTf46dQJC0UUUDCiiigAooooAKa3S nU1ulAC0tJS0AFFFFABRRSUALRRRQAlIveloFAC0UUUAFFFFABRRRQAUUUUAN/ip1NP3qdQA UUUUAFFFFABRRRQAUx/u0+mP92hCY4dKWkHSloGFFFFABRRRQAUUUUAFFFFADf4qdTf46dQI KKKKBhRRRQAUUUUAFNbpTqa/SgGLS0g6UtABRRRQAUlLRQAUUUUAIelInSlNInSgB1FFFACU tIaWgAooooAKKKKAG/xU6m/x06gAooooAKKKKACiiigApr/dp1Mf7tAmOHSlpB0paBhRRRQA UUUUAFFFFABTV6mnU1epoAdRRRQAUUUUAJS0UUAFFFFADT94U6mn7wp1AgooooGFFFFABRRR QAUh6UtI3SgAXpS0i9BS0AFFFFABRRRQAUUUUAJTV+8afTF+8aBMfRRRQMKKKKACiiigBKWi igBrdRTqa3UU6gAooooAKKKKACiiigApD0paQ9KAEXpTqavSnUAFFFFABRRRQAUUUUAFNH3j TqaPvUAOooooAKKKKACiiigAooooAa/anUx+1PoEFFFFAwooooAKKKKACkPSlpD0oARelOpq 9KdQAUUUUAFJjnNLRQAUUUUAFN/ip1N/ioAdRRRQAUUUUAFFFFABRRRQA1ulLSN0paAFoooo AKKKKACiiigApKWkoAROhp1NToadQJBRRRQMKKKKACiiigApp+8KdTf4qAHUUUUAFFFFABRR RQAUUUUAI3SihulFAC0UUUAFFFFABRRRQAUUUUAIO9LTV706gAooooAKKKKACiiigBKQ/eFL SH7woEOooooGFFFFABRRRQAUUUUAI3SgdKRvu0o6UALRRRQAUUUUAFFFFABRRRQA1epp1NXq adQAUUUUAFFFFABRRRQAU1uop1NPUUAOpKWkoAWiiigAooooAKKKKAEbpSL90UrdKRfuigQ6 iiigYUUUUAFFFFABRRRQA0feNOpo+8adQAUUUUAFFFFABRRRQAU1u1OprdqAHUUUUAFFFFAB RRRQAUUUUAIelC9KD0oHSgBaKKKACiiigAooooAKKKKAGf8ALSnU3/lpTqBIWiiigYUUUUAF FFFABTW6U6mt0oAWlpKWgAooooAKKKKACiiigBKRe9Opq96AHUUUUAFFFFABRRRQAUUUUANP 3hTqafvCnUAFFFFABRRRQAUUUUAFNf7tOpr9KBMUdKWkHSloGFFFFABRRRQAUUUUAFFFFADc fPS0g+9TqACkpaKAEopaKAEopaKAEpHGRTqQ0AFLRRQAUlLRQAUlLRQAUlLRQAh6U1Pu06kX pQAtFLRQAhopaKAEopaKAEopaKAGfxU6j+KloASilooASilooASilooAKa/3adTW6UCYo6Ut IOlLQMSilooAKSlooASilooASmr1NPpq9TQIWilooGFFFFACUtFFABRRRQAxs7hTqQ/eFOoE FFFFAxKWiigApKWigBKRulOpD0oARfuiloHSloASloooASilooASjmlooASmLncakpq/eNAh 1JS0UDCkpaKAEopaKAEOaKWigBjZyKdSHqKdQIKSlooGFFFFACUUtFACUHpS0h6UAImdtLQv SloBCUGlooASloooAKSlooASmjO80+mj7xoEOpKWigYlLRRQAlFLRQAlFLRQAx+1OpG7U6gQ lFLRQMSilooASilooASg9KWkNACLnFOpq9KdQCEopaKAEopaKAEopaKAEpvO+n03+KgBaKWi gBKM0tFACUUtFACUUtFADHPFOFI3SnUCEopaKBiUUtFACUUtFACUGlpKAGp0NOpF6GnUCQlL RRQMKKKKAEpaKKAEpM/PTqb/ABUALS0UUAJRS0UAJRS0UAJS0UUANbpSjpQ3SigAopaKAEop aKAEpaKKACkpaKAGr3p1NXvTqAEopaKAEpaKKAEopaKAEzTWPzCn009RQJi0tFFAwooooAKS looASjNLSUAI5+WlHSkbpSjpQIKWiigYUUUUAJS0UUAFJS0UAMU8mnUg6mnUAFFFFACUUtFA CUtFFACUjHkU6mnqKAFopaKAEopaKAEopaKAEozS0UANb7poQ/KKU9DSL90UC6i5opaKBhRR RQAlLRRQAlFFLQAwH5jTqQdTTqAQlLRRQAUlLRQAlFFLQAlNY9KfTW7UCFpaKKBhSUtJQAUU tFABSUtFACE8UinIpT0pF6UALRS0lABS0UUAFFFFABRRRQAzPz06m/x06gSFooooGFFFFACU tFFACUjnApaRulAmKDxS0lLQMSilooASilpKACilooASkQ9aWkUYzQIdRRRQMKKKKACiiigA ooooAaT84p1NI+anUCEpaKKBhSUtFACUUtFABTJPu0+mP92hCY4dKWkHSloGFFFFABRRRQAU UUUAFFFFAEZ3bvlpfn9qX+KlpisN+f2o+b2p1FILDfn9qPm9qdRQFhvze1Hze1OooCw35/ah t2OOtOoPSgLDRvx2o+f2p1FAWE+b2o+b2paKAsJ83tSZb0FOooCwnze1J83tT6KAG/NjtTV3 Y7U+kXpTAT5vaj5vQU+ikAzL+go+f0FOpaAsMy/oKMt6CnUUBYblvQUuW9KdRQBEzNuGBTsv 6Uv8VLTCw0F/SjLelOopBYblvSjLelOooCwmW9KTLelPooCwzLelI5bb0qSmv92mDQ1S+ORS 5bHSnDpRSCw3LelLlvSlooATLelJlvSnUUBYblv7tG5s/dp9FAWGZb0poL7jxUlIvU0wsJub +7RlvSnUUgG7m/u0uT6UtFADSzf3aMt6U6igLDdzf3aXcf7tLRQAx2YEYFKGb+7SnqKWmFhu 4/3aXcfSlopANDH+7RuP92nUtADNx/u0bj/dp9FADNx/u0hY4+7T6D0pgMVjjpS7z/dNOHSi gLDdx/umjcf7tPopAM3H+7RuP900+igBm45+7RuP900+igBm4/3TTQ53Hg1JSL940wYm4/3T RuP9006ikAm4+ho3H0NOooAbu9jSbz/dNPooAYXPZTQGP9006loAjdyCODSh8/wmlYZIpaYW Y3f/ALJo3H+6afRSAbuP900bjjpTqKAGbj/dNG4/3TTqWgBm8/3TQW46Gn0h6UARrJx0NO3/ AOyaVRgUtMEmN3/7JoL89DT6SkAm72NJv9jT6KAGb/Y0u72NOooAZv8AY0m/5uhp9IPvUw1E 3+xo3/7Jp1FINRN/saTf7Gn0UAN3+xpN49DT6KAGbx70bx706igBjPjFL5g9DQ4BxmnYphqN Dj0NLv8AY0tFINRN49DSb/Y0+igBu8Um8ehp1FADd496XcMUtFAajFkB7Uu8e9KoAFLTBXG7 x70u8e9LRSATeKQuKdRQGom8e9G8e9LRQAm8U0yANT6TA3Uw1E8we9G8e9OxRSDUTeKTePen UUBqJuFG4UtFACbxSbxTqKA1GM4xS+YvrSsBilAHpTDUb5i0bxTsCikGom8Um8U6igNRN4o3 ilxRigBN4pN64607FGKA1I1kHQ07etCgYNOwKYK4m8UbxS0YpBqJuFG9fWlwKMUBqJvFJ5i+ tOwKMD0oDUTePWkLrmnYpMDdTDUN6+tJvX1p2BRgUg1G719aXevrS4FGBQGo3evrRvWnYHpR gelAaibx60bx60uBRigNRrOAKBIvrSsARQFA7U9A1E3r60u9fWlwPSjA9KQajd6+tLvX1pcC jA9KA1E3r60bxS4HpRgelAaibx60bh60uB6UYoDUYJF5zTt6+tIqjJ4p2B6UwVxu9fWl3r60 YHpS4HpSDUTePWjevrS4HpRgUBqJvFG9fWlwPSjA9KA1E3D1prOART8D0prKCRTB3F3r60b1 9aXA9KMD0pBqJuHrRvHrS4HpRgelAaibh60bh60uB6UYHpQGom9fWjevrS4HpSbR6UBqIzAC gOuOtKVBHSgIo7Uw1DcPWjcPWlwPSjaPSkGom9fWjcvrS4HpRgelAaib19aNw9aNo9KXA9KA 1E3D1FG4etLgelGB6UBqNDjJpd6+tIFGSaXaPSmGobl9aN6+tLtHpSbR6Ug1DevrRuHrRtHo KXaPSgNRNw9aNw9aXaPSjaPSgNRNw9aazgEU/aPSmsoyOKYO4u9fWjevrRtHpRtHpQGobh60 bh60bR6UbR6Ug1DcPWjcvrS7R6Um0elAahuHrRuHrS4HpRtHpQGohYY60iuuOtKVGOlIqjHS mGou4etG4etG0elG0elINQ3D1o3D1o2j0pdo9KA1E3D1FG4etLtHpRtHpQGom5fWjcPWjaPS jaPSgNRAy5PNLuHrSbBuPFLtHpTDUNw9aNw9aNo9KNo9KQahuHrRuHrRtHpRtHpQGobl9aNy +tG0elG0elAahuHrSMw45pdo9KRlHFMHcXcPWjcPWjaPSjaPSkGobh6ijcPUUbV9KNi+lAah uHrRuHrRtHpRtX0oDUNw9aNw9aNo9KNo9KA1DI9aRWBHWl2j0pFQAdKYai7h6ijcPUUbF9KA ijtSDUNw9RRuHrRtHpRsX0oDUXcPWk3D1o2r6UbF9KA1F3D1oyPWk2L6UbF9KA1E3Df1p2R6 0zYN/SnbF9KYlcXI9aMj1pNg9KNi+lIeouR60m4etGxfSjYvpQGou4etJuHrRsX0o2L6UBqG 4etIzDFKEX0pGQYphqLuHrRuHrSBFx0pdi+lAai5HrRuHrSbF9KNi+lINRdw9aNw9aTYvpRs X0oDUXI9aMj1pNi+lGxfSgNRcj1pqsPWl2j0pAg54phqOyPWjI9aTYvpRsX0pBqLketGR60m xfSjYvpQGouR60ZHrSbV9KNq+lAai5HrRketJtHpRtHpQGohYBhzTsj1phQFhTti+lMNRcj1 oyPWm+WvpS7R6Ug1FyPWjI9aTaPSjYPSgNRcj1oyPWk2j0o2L6UBqLketNcjb1pdg9KayjHS mgdx46UtIOlLSGFFFFABRRRQAUUUUAFFFFADR96nUz+On0CQUUUUDCiiigAooooAKa3SnU1u lAC0tJS0AFFFFABRRRQAUUUUAIaROlKaRelADqKKKACiiigAooooAKKKKAGn79Opv8VOoASl pKWgAooooAKKKKACmv8Adp1Nf7tAmKOlLSDpS0DCiiigAooooAKKKKACmr1NOpq9TQA6iiig AooooAKKKKACiiigBjfeFPpp+8KdQIKKKKBiUtJS0AFFFFABSN0paRulAAvQUtIvQUtABRRR QAUUUUAFFFFABTF+8afTE+8aYmPooopDCiiigAooooAKKKKAGt1FOprdRTqACiiigAooooAK KKKACkPSlpD0oARelOpq9KdQAUUUUAFFFFABRRRQAU0feNOpo++aBDqSlpBQMWiiigAooooA KKKKAGP2p9NftTqBBRRRQMKKKKACiiigApO1LSdqAAdKWmr0p1ABRRRQAUUUUAFFFFABTf4q dTf4qAHUUUUAFFFFABRRRQAUUUUANbpTqa3SnUAFFFFABRRRQAUUUUAFJS0lACL0NOpq9DTq AQUUUUAFFFFABRRRQAU3+KnU3+KgB1FFFABRRRQAUUUUAFFFFADW6U6mt0paAFooooAKKKKA CiiigAooooAavenUgpaACiiigAooooAKKKKACmn7wp1NP3hQIdRRRQMKKKKACiiigAooooAQ 9KB0oPSgUALRRRQAUUUUAFFFFABRRRQA0dTTqaOpp1ABRRRQAUUUUAFFFFABTT1FOpp6igB1 FFFABRRRQAUUUUAFFFFACN0pF+6KVulC9BQIWiiigYUUUUAFFFFABRRRQA0dTTqaPvGnUAFF FFABRRRQAUUUUAFNbtTqa3agB1FFFABRRSUALRRRQAUUUUAIaF6UHpQvSgBaKKKACiiigAoo ooAKKKKAGfx06k/jpaBIWiiigYUUUUAFFFFABTW6U6mt0oAWlpKWgAooooAKKKKACiiigApq 96dTV70AOooooAKKKKACiiigAooooAb/ABU6mn7wp1AgooooGFFFFABRRRQAU1/u06mv92gT FHSlpB0paBhRRRQAUUUUAFFFFABRRRQA3+KnU3+KloELRRRQMKKKKACiikoAWmt0paR+lAC0 tJS0AFFFFABRRRQAUUUlABSL0pT0pEORQIdRSUtAwopKWgAooooAKKKKAG/x06mZ+en0CQUU UUDCikpaACiiigApr/dp1Mf7tCExw6UtIOgpaBhRRRQAUUlFAC0UlFAC01eppaavU0CH0UUU DCiiigBKWkozQAtFJS0ANP3hTqYfvCn0CCiikoGFLSUtABRRRQAUjdKWmseKAFXoKWmr90Ut AC0UlLQAUUUUAFFFJQAU1fvGnUxfvmmIkopKWkMKKKKACiiigBKWkooARuop1NY8iloELRRR QMKKKKACikpaACkPSlpD0oARelOpq9KdQAUUUlAC0UlLQAUUUUAFNH3jTqaD8xoAdSUtJQAt FFFABRRRQAUUUUANftTqY/an0CCiiigYUUUUAFFFFABSdqKD0oARelOpq9KdQAUUUUAFFFFA BRRRQAUn8VLTf4qAHUUUUAFFFFABRRRQAUUUUANbpTqa3SnUCCiiigYUUUUAFFFFABSGlpDQ A1Ohp9MToafQJBRRRQMKKKKACiiigApv8VOpv8dADqKKKACiiigAooooAKKKKAEbpS0jdKKA FooooAKKKKACiiigAooooAavenU1adQAUUUUAFFFFABRRRQAU0/eFOppPzCgQ6iiigYUUUUA FFFFABRRRQAjdKB0obpQOlAC0UUUAFFFFABRSUtABRRRQA0dTS0g6mnUAFFFFABRRRQAUUUU AFNPUU6mnqKAHUUUUAFFFFABRRRQAUUUUAI3Q0i/dFDfdoX7ooF1HUUUUDCiiigAooooAKKK KAGjqadTR9406gAooooAKKKKACiiigAprdqdTW7UAOooooAKKKKACiiigAooooAQ0L0oNC9K AFooooAKKKKACiiigAooooAZ/HT6Z/HT6BIKKKKBhRRRQAUUUUAFNbpTqa3SgBaWkpaACiii gAooooAKKKKACmr3p1NXvQA6iiigAooooAKKKKACiiigBp+9Tqb/ABU6gAooooAKKKKACiii gApr/dp1Mf7tCExw6UtIOlLQMKKKKACiiigAooooAKKKKAG/xU6mj71OoAKKKKACiiigAooo oAKa3SnU1ulAC0tJS0AFFFFABRRRQAUUUUAJSL0pTSL0oAdRRRQAUUUUAFFFFABRRRQA3+Kn U3+KnUAFFFFABRRRQAUUUUAFNf7tOpr/AHaBMUdKWkHSloGFFFFABRRRQAUUUUAFNXqadTV6 mgB1FFFABRRRQAlLRRQAUUUUANP3hTqafvCnUCCiiigYlLSUtABRRRQAUjdKWkPSgAXpS0g6 UtABRRRQAUUUUAFFFFABTFHzE0+mL940CY+iiigYUUUUAFFFFACUUtFADGHIp1I3UU6gQUUU UDCiiigBKWiigApD0paQ9KAEUYFOpF6UtABSUtFABRRRQAUlLRQAlNH3zT6aPvmgQ6kxS0UD CiiigAooooAKKKKAGOM4+tOpr9qfQIKKKKBhRRRQAlFLRQAlB6UtIaAET7tLQvSloAKKKKAC kpaKAEpaKKAEpMfPTqb/ABUAOooooAKSlooAKKKKACiiigBr9KWkbpS0CCilooGFFFFABSUt FACUGlpKAGp0NOpqdDT6BISloooGJS0UUAFJS0UAJSY+anU3+KgBaKWigAooooAKSlooAKSl ooAaw4paRulLQAtFFFACUtFFABRRRQAUlLRQA1R1p1IO9LQAlFLRQAUUUUAFFFFACU0j5hT6 afvCgTFopaKBiUUtFACUUtFACUUtFADW6Uo6UjfdpR0oELSUtFAxKKWigBKKKWgBKKWigBqj k0tIOpp1ACUtFFACUUtFABRRRQAU0j5hTqaeooAdSUtFABRRRQAUUUUAFFFFADW6GhegpT0o XoKBBRS0UDEopaKAEopaKAEopaKAGj7xpaQfeNOoAKKKKACkpaKAEpaKKACmMOlPprdqBMWl oooGFJS0UAJS0UUAFFFFACHpQvSg0L0oAKKWigApKWigAooooAKKKKAGfx06m/x06gSFpKWi gYlFLRQAUlLRQAlI3SnU1ulAmKKKO1LQMKKKKACkpaKAEpaKKAEpFp1NXvQAtFLRQAlFLRQA UlLRQAUUUUAMP36dSH7wp1AhKWiigYUlLRQAUUUUAJTZPu0+mSfdoQnsOHSlpB0paBhRRRQA UUUUAFFFFABRRRQA3+KnVGW2vz0pd4oFcfRTQ4NG8ZxQFx1FN3CjeKAuOopu8UbxQFx1IelI HBpGYYoC46lpgcYpd4oC46im7xRvFAXHUU3eKTetAXH0U3eKNwoAWkXpRuFIrDFAD6KbuFG8 UDFpabvFG8etArjqKbvHrRvFAXHUU3cPWjcPWgdw/ip1RlwGp29fWgV0LS03evrRvX1oC46i m7x60bh60DHUU3cPWjcPWgB1NfpRuX1pHYbaBMcOlLTQ4x1o3L60BcdRTdw9aNw9aBjqKbuH rRuHrQA6im7h60bl9aAHU0dTRuHrSBhkigVx9FN3D1o3D1oGOopu4etG4etAC0tNLL60bh60 AOopu4etLuHrQAh6inUwsARzS7h60CuOopNw9aNw9aBhS03cPWl3D1oAWik3D1o3D1oAWkPS jI9aQkY60AKOlLTFYEdaXcPWgQ6ik3D1oyPWgYtFJketG4etAC0UmR60bh60AFNX7xp2RTVY bjTEx9FJkUZHrSGLRSZFGRQAtFJketGR60AFLSZFGR60AIeop1MZgMU7I9aBC0UmR60ZHrQM WikyPWjIoAWikyPWjIoAWkPSjIoJGKABelLTVYEdaXI9aAFopMijIoAWikzRmgBaKTNGaAFp o+8aWkBG7rQIdRSZozQMWikzRmgBaKSjIoAWikozQAjdqdTGIGKdmgQtFJmigYtFJRQAtFJR QAtIaKO1AAvSlpqkYpaAFopKKAFopKKAFooooAKb/FTqb/FQA6ikpaACiikoAWiiigAooooA a3SnU1ulLQAUtFFABRRRQAUUUUAFJS0lACL0NOpqninUCQUUUUDCiiigAoopKAFpv8VOpv8A FQA6iiigAooooAKKKKACiiigBG6UUHpRQAtFFFABRRRQAUUUUAFFFFADV706mjvTqACiiigA ooooAKKKKACmn7wp1NPUUAx1FFFABRRRQAUUUUAFFFJQAN0oHShulA6UALRRRQAUUUUAJS0U UAFFFFADR1NOpB1NLQAUUUUAFFFFABRRRQAU09RTqaeooAdRRRQAUUUUAFFFFABRRRQAh6UL 0FB6UL0FAC0UUUAFFFFABRRRQAUUUUANHU06mjqadQAUUUUAFFFFABRRRQAU1u1OprdqAHUU UUAFFFFABRRRQAUUUUAIaRelKaF6UALRRRQAUUUUAFFFFABRRRQA3+OnU3+OnUCQUUUUDCii igAooooAKa3SnU1ulAC0tJS0AFFFFABRRRQAUUUUAFNXvTqavegB1FFFABRRRQAUUUUAFFFF ADT94U6mn71OoAKKKKACiiigAooooAKZJ92n01/u0ITFHSlpB0paBhRRRQAUUUUAFFFFABRR RQA3ALUuKT+KnUCExRS0UDEopaKAExRgUtFACYpGAxTqa/SgBcCiiloASjFLRQAmKMUtFACU UtFACEUi9KWkTpQIXAoxS0UDEwKMD0paKAEwPSjA9KWigBMCjA9KWigBhUFulO2j0pP4qdQK w3aPSlwPSlooGJgelGB6UtFACYHpRgelLRQAmB6U1gMdKfTX6UCYAD0pdo9KB0paBiYHpRge lLRQAm0elGB6UtFACbR6Um0elOooATA9KaFGTxT6avU0CDaPSjaPSnUUDsN2j0o2j0p1FAWG lR6UbR6UtLQKw3aPSjaPSnUUDsMKgkUu1fSg/eFOoFYbtHpRtHpTqKB2G7F9KNo9KdRQKw3a PSjaPSnUUBYbtHpQVGOlOpD0oCw1UAHSl2L6Uq9KWgLIbtHpRtHpTqKBjdo9KNo9KdRQKw3a PSjYvpTqKAG7R6U0KNxNSUxfvGmFhdo9KNg9KdRSHYbtFG0elOooFYbsX0o2j0p1FAWG7BRs X0p1FAWI2QHFKEX0pWPIp1O4WQzYvpS7RTqKQWG7BRsFOooCwzYtGxadRQFkN2LQVGKfSHpQ FhioMc0uxfSnDpS07hZDNgo2Cn0UrhYZsFLsFOoouFhuwYxSbBT6KAsN2Cm7AWqSmj7xphYT YKAgFPopXCw3YKTYKfRRcLDNg96Ngp9FFwsM2Cl2CnUUXCxE6cUojGOppzdqWncVlcaYwaNg 96fRSuOwzYKNgp9FFwsN2ik2D1p9FAWGCMe9GwY70+kouFkMWP3pdnuacvSlp3CyGbB6mjYP U0+ilcLDNg9TSGPPc1JRRcLIZs9zRs9zT6KAsM2D1ppjJPWpaT+KncLIb5fuaNnuafRSuFkM 2D1NAT3NPoouFhmz3NGz3NPooCwzZ7mjafWn0UBYjZOOtAjwOppzdKWncLIZ5fP3jS7Pc0+i lcLIZs9zRs9zT6KAsM2H1NGz3NPooCwzZ7mjZ7mn0UBYhSM5J3GnhP8AaNKvQ06m2JIZs/2j S7fc06ikOwzb7mjYf7xp9FAWGbD/AHjRs/2jT6KAsM2n1NIVO4c1JTf4qYWE2H+8aNp/vGn0 UgsM2+5o2e5p9FAWGbD/AHjRsP8AeNPooCwzaf7xoKk/xU+igLEbqdvWhUOOtPbpRTuFhuxv 71G0/wB406ikFhuw/wB40bD/AHjTqKYWGhT60bT/AHqdRSCw3af71G0+tOooCxGqHceadtP9 6lFLTuFhmw/3jS7T/eNOooCw3af71G0/3qdRSCw3afWjaf7xp1FAWG7T/eproSRzUlIeop3B obsP940u1v71OopXCw3af71G0/3qdRQFhpU9mo2t/ep1FAWG7Tj71AVsctTqKYWGsDt65pAr Y6089KBQFhu1v71G1v71PooCwza396ja396nUUgsN2tn71G1v71PophYZtb+9RtP96nUUgsR hW3HmnbW/vUo6mnU7hYZtb+9Rtb+9TqKQWGhW/vUbT/ep1FAWG7W/vUYb1p1FAWG4b1prqxx zUtNPUUwsN2t60bWz96pKKQWGYb+9Rtb+9TqKAsN2t/eo2t/ep1FAWG7W/vUYPrT6KAsRsGw eaRFfHWnt900L90UxW1Ew396jB9adS0h2GYb+9RhvWn0UBYZhv71GG9afRQFhm1v71Lg4606 igLEWG3cGnYb1pR1NOphYZhvWjDetPopBYZtb1ow2OtPooCwwBvWjDetPooCwzDetIwapKa3 amDQmHx1FGH/AL1PopBYZhvWk2vn71SUUBYZhvWjDetPooCwzD+oow3rT6KAsMIbHUU1Q+Ot SUL0p3CwwiT1FGH9akpKLhYbh/UUYb1FOopBYb83rRh/UU+igLDMP6ijDeop9FAWIiH38GnY f1FH8dOpiSG/P7UfP6inUUh2G/P7UfN7U6igLDfn9RQd/tTqKAsNAf1FI+7FPpG6UwsNG/HU Uvz+op1LSCwzD+oow/qKfRQFhmG9aMP606igLDcP7UfN6inUUBYbhvUU0B8mpKRe9MLCYf1o +fPan0UgsM+b1FGH9afSUBYbhvUUYf1FPpKAsN+f2pfmpaKAsRsG3DFO+f1FKfvClp3CwzD+ opfn9RTqKQWG4fPUUYb1FOooCw35/UUYf1FOooCw35vUU1w23tUlNk+7TQNaDh0paRegpaQw ooooAKKKKACiiigAooooAb/FTqZj56fQJBRRRQMKKKKACiiigAprdKWkYZFAC0tJRQAtFFFA BSUtJQAtFJRQAUi9KU9KRBgUCHUUUUDCikooAWiiigAooooAb/FTqYfvinUCFopKWgYUUUlA C0UUUAFNf7tOpkgytCExw6UtIOlFAxaKSigBaKSigBaKSigBaavU0tNUcmgQ+iikoGLRRSUA FLSUUALRSUUAIeop1MP3hTqBC0UUUDEpaSigBaKSigBaQ9KKRulACr0paav3RS0ALRSUUALR Sc0c0ALRSc0c0ALTF+8adTVzuNAh9FJRQMWikooAWiiigAopDRQAjdRTqY2cinUCFooooGFF JS0AFFJRQAtIelFB6UAIvSnU1c4paAFopKKAFopKWgAoopKACmj75p1NH+sNAmPopKKBi0Ul LQAUUUlAC0UlFACN2p1MftTqBC0UUUDCiiigAooooAKQ9KKD0oARelOpqfdp1AIKKKKACiii gAopKWgApv8AFS03+OgQ+iiigYUUUlAC0UlLQAUUlFACN0paa+cU4UCFopDRQMWikooAWikp aACkooNACJ0NOpiHrTqBIWikooGLRSUtABRRSUALTT94UtNP3xQIfRRSUDFopKWgAoopKAFo pKKAEbpS0j9KUdKAFopKKAClpKKAFooooAKKSigBFPWnU1e9LQCFopKKAFopKKAFooooAKaf vCnUxvvCgTH0UlLQMKKSloAKKSloAKSijNAAelA6UjHC0KcigQ6iikoGLRRSUALRSUZoAWii koAQdTTqavU0tAC0UlLQAUUlFAC0UUUAFNPUUtNY8igB9FJRQAtFFFABRRRQAUUUUAIelC/d FDdKRfuigQ6iiigYUUUlAC0UlLQAUUlFACD7xp1MH3jT6BIKKKKBhRRRQAUUUUAFNbtS01+1 AmPopKWgYUUUlAC0UUUAFFFJQAdqRelKelIp4oAdRRSUALRSUUALRRRQAUUmaKAG/wAdOpv8 dOoEhaKKSgYtFFFABRSUUALTW6UtIx4oAWlpBS0AFFJS0AFFFFABRSUtABTV70tIp60CHUUU UDCikooAWiiigAooooAafvCnUw/fFOoELRSUtAwooooAKKSloASmyfdp1Nk+7QJ7Dh0paQdK WgYUUUUAFFFFABRRRQAUUUUAN/jp1N/ip1AkFFFFAwooooAKKKKACmt0p1I3SgBaKKKACiii gAooooAKKKKAENIvSlNIvSgB1FFFABRRRQAUUUUAFFFFADf4qdTf4qdQAUUUUAFFFFABRRRQ AU1/u06mt0oBijpS0g6UtABRRRQAUUUUAFFFFABTV6mnU1epoAdRRRQAUUUUAJS0UUAFFFFA DT94U6mn7wp1ABRRRQAUUlLQAUUUUAFIelLSHpQAL90UtIOlLQAUUUUAFFFFABRRRQAUxfvG n0xfvGgQ+iiigYUUUUAFFFFABRRRQA1uop1NbqKdQAUUUUAFFFFABRRRQAUh6UtIelAAvSlp F6UtABRRRQAUUUUAFFFFABTB980+mD75oEx9FFFAwooooAKKKKACiiigBrdqdTW7U6gQUUUU DCiiigAooooAKQ9KWkPSgBF6U6mr0p1ABRRRQAUUUUAFFFFABTf4qdTf4qAHUUUUAFFFFABR RRQAUUUUANfpS0jdKWgQtFJS0DCiiigAooooAKSlpDQA1O9PpidDT6BIKKKKBhRRRQAUUUUA FN/ip1N/ioAdRRRQAUUUUAFFFFABRTWYKMsQB71RudVghyFO9vagC83SjIA5Irn5tWnkyFwo 9qpvcTSElnY596AOna6gUkGVRj3pv262/wCeq/nXLAMetLhsdDRZhodR9vtf+ey1ItxE/wB2 RT+NckQR1BoBI6EigDsQQehpa5SK8nh+5Iw+tXItamUAOqt70Ab9FZ0OsW7j5yUPvVqO7gkH yyKfxoAlXvTqjR1OcEU7cv8AeFADqKQEHpS0AFFFFABRRRQAU0/eFOpp+8KBDqKKKBhRRRQA UUUUAFFFFACN0oHShulA6UALRRRQAUUUUAJS0lLQAUUUUANHU06kHU0tABRRRQAUUUUAFFFF ABTT1FOpp6igB1FFFABRRRQAUUUUAFFFFACN0pF+6KVulIv3RQLqOooooGFFFFABRRRQAUUU UANH3jTqaPvGnUAFFFFABRRRQAUUUUAFNbtTqa3agTHUUUUDCiiigAooooAKKKKAEPSkUYFK elIvSgB1JS0UAFFFFABRRRQAUUUUAN/jp1M/jp9AkFFFFAwooooAKKKKAEpG6U6mt0oAWlpK WgAooooAKSlooAKKKKAEpF706mr3oAdRRRQAUUUUAFFFFABRRRQA0/eFOpp+8KdQIKKKKBhR RRQAUUUUAFMf7tPpj/doQmOHSlpB0paBhRRRQAUUUUAFFFFABRRRQA0ffp1NH3qdQAUUUUAF FFFABRRRQAU1ulOprdKAHUUlLQAUUUUAFFFFABRRRQAhpF6UppF6UAOooooAKKKKACiiigAo oooAb/FTqb/FTqACiiigAooooAKKKKACmv8Adp1Nf7tAmKOlLSDoKWgYUUUUAFFFFABSUtFA BTV6mnU1epoAdRRRQAUUUUAFFFFABRRRQA09RTqafvCnUAFFFFABRSUtABRRRQAUh6UtI3Sg AHSlpF6CloAKKKKACiiigAooooAKYv3jT6Yv3jQIfRRRQMKKKKACiiigAopKWgBp6inU09RT qACiiigAooooAKKKKACkPSlpD0oAB0paQdKWgAooooAKKKKACiiigApg++afTR940CHUUUUD CiiigAooooAKKKKAGP2p9MftT6BBRRRQMKKKKACiiigApD0paQ9KAEXpTqavSnUAFFFFABSU tFABRRRQAU3+KnU3+KgB1FFFABRRSUALRRRQAUUUUAI3SikbpS0AFLSUtABRRRQAUUUUAFJS 0lACJ0p1MTvT6BIKKKKBjWYKMk4FZd3rCRkrCA59e1R6zekHyE/E1i5oA2LfWnLhZUBBPUVt IwZQR0NchAN0q4x1rrYseWuMdKAJKbn56dTf4qAHUUUUAFFFRTXEUAzI4FAEtUbzUYrYFc7n 7AVn3ervJlYRtX171nKrzSYUFmNAEtzeT3J+djt9BUUUEsrYRSx9q1rXRuA07f8AARWrFDHC uI1AFPRCMWDRpODMwA9BWhDpdtGOU3H3q43SlouFiJbaFekaj8Kf5Uf9xfyp9FK4ELWsLDBj X8qgk0u1f+DH0q5S07sLGJPoZ5MUnHoaoS6dcxHmMkeo5rqaKLgcaVIJB4NAJBrq3s7eQktE pJ61A+k2rdFI+ho0DU54SyKeHYfjSGR+7Nn61uf2LCSfmYChtDhwcO1FguZUGozwfdckehrS h1tSP3qEH2qlcaTPESVG9fUVCLG4HJiIHvSsO50ltdRXK5jbOOoqeuZsbz7EzZTcTVuLW2Mv zoNntQBt0U1HDoGHQ06gAprfeFOpp+8KBDqKKKBhRRRQAUUUUAFJS0lACN900o6UN0oHSgBa KKKACiiigBKWkpaACiiigBB1NLSDqaWgAooooAKKKKACiiigApD1FLSHqKAFooooAKKKKACi iigAooooARulIv3RSnpSL90UCHUUUUDCiiigAooooAKKKKAGjqadTR9406gAooooAKKKKACi iigAprdqdTW7UAOooooAKKKSgBaKKKACiiigBDQvSg9KF6UALRRRQAUUUUAFFFFABRRRQAz+ On0z+On0CQUUUUDCiiigAooooAKa3SlpG6UALS0lLQAUUUUAFFFJQAtFFFABTVp1NXvQA6ii igAooooAKKKKACiiigBp++KdTT94U6gQUUUUDCiiigAooooAKa/3adTX+7QJijpS0g6UtAwo oooAKKKKACiiigAooooAaPvU6o2Xc3pS7Pc0xXH0UwKfU0bfc0gH0UzZ/tGjZ7mgB9FM2+5o 2e5oAdSN0pNp9TSOhI4NMB9FM2HH3jS7T6mgLj6KbtPqaTb7mkA+kpNp9TSbD/eNAD6KbtPq aTaf7xoAdQOlN2nHWkVTjqRTC5JRTdp9aTaf71IB1FNKn+8aNp/vUBcdRSbT60m0+tADqKbt b+9Rtb+9QFxf4qdUTKSwwadtb+9TC46lpm1v71G1v71AXH0Uza396ja396kFx1FN2t60bW/v UBcdSP8AdpNrf3qRw23rTBseOlFMVXx96lw396gLj6KZhvWjDetILj6KZhvWja396gLjqWmY b1pMPnrTC4+kHekw3rTFV8nBxQFyaimYf1ow/qKQXHUU3DetGG9aAuPoqPD+tLhvWgLjqKbh vWjDeooC4p6ilqJi24Y607D+op2C5JRTMP6ijDetILjqKb8/qKMN60BcdRTcP6ijD+ooC46g 9Kb8+OoobdtNMLjh0oqNN+O1Kd/qKLBcfRTRv9qBv74pBcdRTfn9RR8/qKAuOopvze1Hz+1A XHU1fvGj5qaN+40wuSUU35/aj5/akFx1FN+f2oG/2oC46im/P7UfP7UBcdRTPn9qX5/agLin qKWo338Uo3+1OwXH0U35/aj5/akFx1FN+f2o+f2oC46im/P7UfN6CgLj6Sm/N7UHdigLjh0p aiXfjinfP6CnYLj6KZ83oKMv6UguPopmW9KPn9qAuPopmW9KMt6UBcfTR940fN6Cm5fd0oC5 JRTMv6CjLegoC4+imZb0oy3pQFx9FMy3pRlvSgLj6KZlvSjLZ6UBcVuopajdmA6YpQz4+7Ts K5JRTMv/AHaMt6Uh3H0UzLf3aMt/doC4+imZb0oy392gLj6TtTct/doy2Pu0wuKvSnVErt2G adub+7RYEx9FM3N/doLN/dpBcfRTNzf3aNzf3aYXH0Uzc392jc392kFx1Hem5b+7TSzbulML klFN3N/do3N6UguPopmW/u0Bm/u0BcdRTdzf3aNx/u0BcdRTdx/u0bjj7tAXHHpRTHZsdKA7 Y+7TsFx9FM3Nn7tLuP8AdoC46im7j/do3H+7SC4+imbj/do3H+7QFx9JTdx/u0bj/dNAXFTo adUSOeeKdvP9007CTHUjHCk0m4/3TVe9mMds5244oHc568k825dj61XJp7YJqS2tnuJNqUrB cgBIII4rVtNW8mMI6Zx3BqF9JuFPA3VC1pPHy0bAfSnZhdG5DqtvIPmbYfQ1Mt1A7ZWVSPrX MEEHkUmcdM0WGdU93BH96VR+NRPqVqgz5gP0rms5pVRmbCgk+1KwXNSfWnYYhTb7ms6aeSds yMWNTRafcyH7hA960bTS0iYNIN59O1VYXMUbPTpLnkjavqa27WzitlGxefU1KDtGAuBS7z/d NIV0Popm8/3TRvP900h3HHpRTGY7ehFCyEj7pp2C6JKKj8w/3TS7z/dNKwXQ+imbz/dNG8/3 TRYLj6KZuP8AdNG4+hoC4+imb/8AZNLu46GgLiilqMPjNLv4+6adguOpGUMpHrTd5/uml3n+ 6aAujmL6Dybl1zxnNVhV7VSDeMapooLAZ70AdPp+fsceTnirVVrUhIEUDoKm3/7JosF0Ppp+ 8KTf7Gms+COKLA2iWio/M9jS7/8AZNKwXQ+imb/Y0b/Y0BcfRTN/saN/saAuPopm/wBjQHz2 NFguOPSims3HQ0ivkdDTsFySimb/AGNLu9jSC46im7vY0b/Y0BcWlpm/noaN/saLBcfRTd/s aN3saAuKOppajD8ng0u8ehp2C6H0Uwv7Gjf7GkFx1LTN/saXd7GgLjqKZv8AY0b/AGNAXH0h 6ik3j0NNZ8EYFMLokopgceho3j0NKwXQ+imb/Y0bx6GiwXH0Uzf7Gjf7GiwXH0Uzf7GjePQ0 BccelC9BTWfg8GkV8r0p2C6uSUUzePQ0bx6GlYLj6KZv9jRvHoaAuPopm8eho3j0NFguh9FM 8we9G8ehosFxR1NOqMP81O3j3oC6HUUzePQ0eYPQ0WC6H0UzePejzB70WC6H0UzePQ0bx70W C4+mt2pN496RnHFOwNklFM8wUbxSsF0OopvmCjzB70WC6H0UzeKN4osFx9FN3ik3iiwXHUL0 pu8YpFkGKdguh9FN8xfWjzBSC6H0UzeKN4osFx9FM3ijeKLBcfRTN4pd4oC4fx0tRmQB6dvW nYE0Oopu9fWjetILjqKb5i0u8UBdC0U3etG9aAuh9NbpSBwaRnGKdguh9FNEi4o3ikF0OopN 4pN60BdDqKbvWjzFoC6HUU3eKN60BdD6avejeKarjkUwuPopu9fWl3ikF0LRTd60eYtAXQ+i mbxS7xRYLjqKbvFG8UBcD94U6o2cAg0u8U7BdDqKb5i0u8UguhaKTeKTetAXH0UzeKN4osFx 9Nf7tG8U12G3imDY8dKWkHSlpDCiiigAooooAKKKKACiiigBo+9S0g+9TqACiiigAooooAKS looASkbpTqaxxQAtLRRQAUUUUAFJS0lABS0UUAIelIn3aU9KRPu0CHUUUUDENFFLQAUUUUAF FFFADf46Wk/ip1ACUtJS0AFFFFABRRRQAU1z8tOpr/doExR0paQdKWgYUUUUAFFFFABSUtJQ AUi9TS01epoEPooooGFFFFACUUUtABSUUUAIfvClpD94UtAC0UUlABS0lFAC0UUUAFI3SlpG 6GgAXpQaF6CigBaSlooAKKKKACikpaAEpqn5jTqao+Y0xMfRSUtIYUUUUAFFJS0AJRRRQAh6 ilpCORS0ALRSYooAWiiigAopKKAFpDS0h6UAA6UtIo4paACiikoAWiiigAooooAKaPvGlpo+ +aBMfSUtFAwopKKAFooooAKKKKAGt2p1MftT6BBRRRQMKKSloAKKKKAEoPSig9KABelLTV6U 6gAooooAKKKSgBaKKKACm/xUtJ/FQA6ikooAWkpaSgBaKKKACiiigBrdKWkbpS0CClpKWgYU UUUAFFJRQAtJRQaAETpTqYnSnUCQtZ+sOFtCM8k1frI1w8otAzGNbGgpxI+Pasg8Vv6MpW1z jqaYjRpCM0tJSGRvbwv96NT+FQNp9sWx5Qq3SH71NMViuLC2GP3S8VMkMUf3UUfQU+ii47C0 UUUgCiikoAWiiigBrdKUUjdKWgBaKSigApaSloAKKSloAKKSigBFAyadTV706gApD0opsrbI mY9hQBzOotuu5PrUEI/er9aJX8yVmPc1NYRmS7QA96Yjp48eWv0p9IBgYopDCkYDcKWmt94U CY+ikpaBhRRRQAUUlLQAUlFFAAelA6UjfdpR0oAWikooAWikooAKWkooAWikooAQDk06mjOT S0ALSUUUAFLSUUALRSUUALTT1FOpp6igBaKWkoAWiiigAoopKAFpKWkoAG6Ui4xQ3Q0L90UC FpaKKBhRSUUAFFLRQAlFFLQA0dTS0g+8aWgAopaKAEopaKAEooooAKRgDilpGzxQJi4FFFLQ MSjFLSUAGB6UYopaAEooooAO1IoAHSlPSkXOKBC4HpRgUtJQMMUYpaKAEwKMUUtACYFGKWko Abgb+lOwKb/HTqBIMCjApaKBiYFGKKWgBMCjApaKAEwPSkYAilpHzigTFwPSjFFFAwxRgUUt ACYFGBS0lABijFFLQAmKRQOaWkXvQIXA9KMClooGJijA9KWkoAMUYFLRQAmBRgUtFADSBu6U uBTT98U+gQmB6UYpaKBiYFGBS0UAJgUYpaKAExTXAx0p9Mk+7QJjh0paQdKWgYUUUUAFFFFA BRRRQAUUUUANH3qdTR96nUCCiiigYUUUUAFFFFABTX7U6mtQAtLRRQAUUUUAFJS0UAFFFFAC GkT7tKaRelADqKKKACikpaACiiigAooooAb/AB06m/x06gAooooAKKKKACiiigApj9KfTH+7 QhMcOlLSDpS0DCiiigAooooAKKKKACmr3p1NXvQA6iiigAooooASlpKWgAooooAafvCnU0/e FOoEFFFFAxKWiigAooooAKRuhpaRuhoAF6ClpF6CloAKKKKACiiigAooooAKYv3jT6Yv3jQI fRRRQMKKKKACiiigAooooAaeopaQ9RTqACiiigAooooAKKKKACkPSlpD0oAB0paRelLQAUUU UAFFFFABRRRQAUxR85p9NH3jQIdRRRQMKKKKACiiigAooooAY/an01+1OoEFFFFAwooooAKK KKACkNLSHpQAL0paRelLQAUUUUAFFFFABRRRQAU3+OnU3+KgB1FFFABRRRQAUUUUAFFFFADW paRqWgBaKKKACiiigAooooAKQ0tIaAEToadTV6U6gEFYWttm4UDqBW7XN6o268f2poCp1rpt PXbZxj2rmU5YfWurgGIUHtQBJRRRSAKb/FTqb/FQA6iiigAooooAKKKKACiiigBD0paRulLQ AUUUUAFFFFABRRRQAUUUUANXvTqap6/WnUAFZ+sT+Va7R1fitCuf1qUyXOzslAGaTzWpokG+ UykcCssCul0qHyrRcjBPNMRdooopDCmnqKdTT94UAOooooAKKKKACiiigAooooARulAobpQO lAC0UUUAFFFFABRRRQAUUUUAIO9LSDqaWgAooooAKKKKACiiigApD1FLTT1FADqKKKACiiig AooooAKKKKAEbpSL90Up6UL0FAhaKQnA5oDA9KBi0UUUAFFFFABRRRQA0dTTqaOpp1ABRRRQ AUUUUAFFFFABTT2p1NPagB1FFFABRRRQAUUUUAFFFFACHpQvSg9KF6UALRRRQAUUUUAFFFFA BRRRQA3+OnU3+OnUCQUUUUDCiiigAooooAKa3SnU1ulAC0tJS0AFFFFABRRRQAUUUUAJSL0p aRelADqKKKACiiigAooooAKKKKAGn7wp1NP3hTqBBRRRQMKKKKACiiigApkn3afTH+7QJjh0 paQdKWgYUUUUAFFFFABRRRQAUUUUANH3qdTR96nUCQUUUUDCiiigAooooAKa1OprdKAHUUUU AFFFFABRRSUALRRRQAh6UifdpT0pE6UCHUUUUDEpaKKACiiigAooooAYfv0+m/xU6gQUUUUD CiiigAooooAKa/SnU1+lAmKOlLSDpS0DCiiigAooooAKKKKACmr1NOpq9TQA6iiigAooooAS loooAKKKKAGn7wp1NP3hTqACiiigAooooAKKKKACmt9006mt900AC/dFLSJ90U6gAooooAKK KKACiiigApi/eNPpi/eNAh9FFFAwooooAKKKKACiiigBp6inUh6iloAKKKKACiiigAooooAK Q9KWkPSgAHSlpB0paACiiigAooooAKKKKACmj7xp1NH3jQIdRRRQMKKKKACiiigAooooAY/U U+mP1FPoEFFFFAwooooAKKKKACkPSlpD0oARelOpF6UtABRRRQAUUUUAFFFFABTf4qdTf4qA HUUUUAFFFFABRRRQAUUUUANbpS0jUtAC0UUUAFFFFABRRRQAUlLSdqAEToadTU6U6gSEPAzX L3jl7mRveunkOI2PtXJzHdIxPc00Mdbr5k6L6muqQYUD0Fc1py7ryMe9dMKGAtFFFIApv8VO pn/LQUCY+iiigYUUUUAFFFFABRRRQAjdKWkbpS0AFFFFABRRRQAUUUUAFFFFADV706mr3p1A CMcKTXK3knmXMjep4rprj/UP9K5RuWP1pgLCu6ZF9TXWxjaigdhXM6cge8QH1zXT0ALRRRSA KafvCnU0/eFAh1FFFAwooooAKKKKACiiigBrdKUdKG6UDpQAtFFFABRRRQAUUUUAFFFFADR1 NOpo6mnUAFFFFABRRRQAUUUUAFNJ+YU6mnqKAHUUUUAFFFFABRRRQAUUUUANb7poX7oob7po X7ooF1FIyMUxUKng1JRQMKKKKACiiigAooooAaOpp1NH3jTqACiiigAooooAKKKKACmt2p1N PagB1FFFABRRRQAUUUUAFFFFACGhelB6UL0oAWiiigAooooAKKKKACiiigBn8dPpn8dPoEgo oooGFFFFABRRRQAU1ulOprdKAFpaSloAKKKKACiiigAooooASkWlpFoAdRRRQAUUUUAFFFFA BRRRQA0/ep1N/ip1ABRRRQAUUUUAFFFFABTX+7Tqa/3aBMUdKWkHSloGFFFFABRRRQAUUUUA FFFFADR96nU0fep1ABRRRQAUUUUAFFFFABTWp1IaAFooooAKKKKACkpaSgBaKKKAENIn3aU9 KRelADqKKKAEpaKKACiiigAooooAb/HTqb/FTqAEpaSloAKKKKACiiigApr9KdTX+7QJijpS 0g6UtAwooooAKKKKACiiigApq96dTV6mgB1FFFABRRRQAlLSUtABRRRQA0/eFOpp+8KdQAUU UUAJS0lLQAUUUUAFIelLSHpQADpS0g6UUALRRRQAUUUUAFFFFACU1fvGn0xR8xoEx9FFFAwo oooAKKKKACiiigBrdRTqaeop1ABRRRQAUUUUAFFFFABSHpS0h6UAA6UtIOlLQAUUUUAFFFFA BRRRQAUwffNPpg+8aBMfRRRQMKKKKACiiigAooooAY/UU+mt1FOoEFFFFAwooooAKKKKACkP SijtQAi9KdSL0paACiiigAooooAKKKKACm/xU6m/xUAOooooAKKKKACiiigAooooAa1LSNS0 ALRRRQAUUUUAFFFFABSUtJ2oAROhp1NTpTqBEN0+y3dj6Vyrckmul1Nttk/vXMnHrTQzQ0YZ u/oK6GsLQ0JnZuwFbtDAKKKKQBTf4qdTT9+gB1FFJQAtFJS0AFFFFABRRRQAjdKKG6UCgBaK KKACiiigAooooAKKKKAGr3p1NXvTqAIbo4tpD7VyjHmuovyBaSZ9K5c9aYi1pYJvUrp657RU DXZJ7CuhpDCiiigApp+8KdTT94UAOooooAKKKKACiiigAooooARulA6UN0oFAC0UUUAFFFFA CUtFFABRRRQAg6mlpB1NLQAUUUUAFFFFABRRRQAUh6ilpD1FAC0UUUAFFFFABRRRQAUUUUAI elC/dFDdKF+6KAFooooAKKKKACiiigAooooAaPvGnU0feNOoAKKKKACiiigAooooAKae1Opr dqAHUUUUAFFFFABRRRQAUUUUAIaB0oPSgdKAFooooAKKKKACiiigAooooAb/AB06mfx06gSF ooooGFFFFABRRRQAlI3SnU1ulAMWlpKWgAooooAKKKKACiiigBKRe9Opq96AHUUUUAFFFFAB RRRQAUUUUAN/ip1NP3qdQAUUUUAFFFFABRRRQAUyT7tPpj/doQmOHSlpB0paBhRRRQAUUUUA FFFFABRRRQBEzMH4GaXc/wDdpw+8aWncmwzc392l3N/dp1FA7Ddzf3aNzf3adRQFhu5v7tIW b+7T6KAsMBb+7QxbHSn0h6UBYaHbH3aXcf7tOooCw3c392jcfQ06igBu5v7tIGPoafRQFhu5 v7tG4/3adRQA3ccdKarEDpUlC9KAsN3H+6aNx/umn0UBYjLn+6aN7f3TT6KAsxu4/wB00m8/ 3TUlFAWI95/uml3n+6afSUBZkJch+lP8w/3TTv4qWi4kmMDn+6aN5/umn0UDsxm8/wB00bz/ AHTUlFAWZHvP900bz/dNSUUBZke/2NI7/L0NSUj9KAsxgkOB8ppd59DTx0ooCzGb/Y0b/wDZ NPooCzGbz/dNLv8AY0+koDUZv9jR5nsafRQFmND57GmB8E5FS01QMmgTTE8z2NL5nsadRQOz G+Z7Gk8wehp9FAajDJ7GjzOOhp9FAWY3zPY0eYPQ06igNSNnwRxSiQehpxAyKXFGgrMb5g96 N/sadiigeozzB70vmD0NOooDUZ5g9KPMHoafiigNRvmD3pC/FPoPSgNRgkGOaPMHvTlUAcCl wKNA1G7xR5g96diigNRvmCjzBTqKA1G+YKPMFOxRigNRu8UwSYc56GpcUxQNxoE7i+YKPMFO xRigeo3eKPMFOwKMD0oDUb5go8wU7AowPSgNRnmCl3il2jOaXAo0DUjaQAil8wU5gDxS7Rjp RoLUb5i0eYKdgelGBQPUbvFG8U7A9KMD0oDUb5i+tG8etOwPSjA9KA1G71o3jFOwPSggelAa jFkGOaXevrSqoA6UuB6UaArjd6+tG8etOwPSjA9KA1G7x60bxTsD0owPSgNRN49aN6+tLgel GB6Ug1E3j1pocbjT8D0poA3HimGou8etJ5i+tOwPSjA9KQajd60u8etLgelJtHpQGobxRvHr RtHpS7R6UBqN8xfWl3r60bR6UYHpTDUY8gGOacJFx1pHUHFO2LjoKNBa3E3r60u9fWjaPSja PSgeobx60b19aNo9KNo9KQahvX1o3j1o2j0o2j0phqJvX1pSwx1o2L6UbRjpQGo1XHQ07evr SKgx0pdi+lGglcN6+tG9fWjavpRtX0oHqG9fWk3r60u0elGxfSloGobx60b19aNo9KNq+lMN Q3D1pu8butO2j0pCgLUaA7i719RRuHrRsX0o2L6UBqG4etG9fWjaPQUbR6UBqG5fWjcPWjYv pRsX0pBqG4etG4etGxfSjYvpTDURmGKXeuOtIyDHAo8tfSjQWou9fWjePWjYvpRsX0o0HqG4 etG4etGxfSjYvpQGobh60bh60bB6UbF9KA1DePWjcMdaNi+lGxfSgNRiOvrT96+opixrySKd sX0odhK5Q1iQfZtoPU1g1sa2AqoB3rHx60DNnRBiN2PGTWruHrVDSYgLQEjqavbF9KHYNRdw 9aNw9aNi+lJ5a+lGgai719ao3epxQNhfnYdhUeq3Qt02R43n9KwlDSvgZZiaAL8+r3EhOw7B 7VB9uuevnNV220ZnXMzFfYVZ/sWDH3mosguZQ1C6H/LU1IurXQxlgR7irraGv8Mp/EVWm0ed OU2uPaiyHcfHrUob50Uj2q9BqtvKQGOw+9YEkMkTYdSD70ylYLnXLIjDIYGl3D1rl4LuaD7p yPQ1r2moQzYVxsb3pi1NBmAFKGBHWmsoK8UojGKNBa3F3D1o3D1pPLX0o8tfSjQeou4etG4e tJ5a+lGxfSjQNRdw9aNw9aTYvpR5a+lAai7h60ZHrSbF9KXYKQaiK4yRml3D1pojBJpfLXFP QWpR1eULaMOu7iue6mtHV7gNJ5SHIXrWcvJoGauhofNZ92MDGK29w9az9It9lvudcFqv+Wvp QGo7cPWk3D1pPLWjYvpRoGo7I9aYzAEUuxaRkBIoE7jtw9aXcPWm+WvpRsX0pD1HZHrRkU3Y PSjYvpQGo7cPWjI9absX0o2LQGo7IoyPWm7BQI1FMNRWIAoDAjrSFABxSLGMc0aC1uPyPWjI pvlijYKQ9R2RRkU3YKNgphqOyKMj1ppjFHlrigNR2R60ZpvlijYKA1AMMnmnZHrTAnJpdgo0 DUdkUZpuwUbBQGo7I9aMim+WtGwUBqOzRmk2CjYKQai5pGIBFJsFIyAkUwdx+RRkU3YKPLFA ajsijIpuwe9GwUBqOyKKbsFHlj3oDUdRTdg96PLHqaA1FY8UKQVpCoxSLGMUC1uPzRmm7BR5 Y96B6jqKbsHvRsFINR1FN2D3o8sUw1HZopvlj3o2D3oDUARuIp2aj8vLdTTtgo0Erjs0Zpvl ijyxQPUdRmm7B70eWPegNR2aKb5Y96NgoDUdTWIGKNg96Rk44oB3H5FFN8sepo8sepoDUdRm m+WPU0hjHqaA1H5FFN8sepo8sepoDUdRTfLHqaPLHqaA1HE8UikEUhT3NNWP3o0FdklGab5Y 9TR5Y9TQPUdRmm7Pc0eWM9TQGo6jNN2e5o8v3NAajqKbs9zRs9zSDUM/PTs1GY8v1NL5fuae gk2Popuz3NGz3NA9R2aKb5fuaNnuaA1HUU3y/wDaNATHc0BqOpGPFJs9zSMnHU0A7j+1FNCc dTRs9zQGo6jNN2e5o8sepoDUdRTdnuaPL9zQGo6im+X7mjZ7mgNR1Ivejb7mmqnXmgB9FN2e 5o2e5pBqOozTdnuaTy+OpphqPopuz3NGz3NAajqKbs9zRs9zSDUCRup1RmPkc07y/c0xXY7N Gab5fuaNnuaB6jqWmbPc0bfc0g1HUU3Z7mjZ70BqPpj/AHaNnuaa6cdaaBkg6UtIOlLSGFFF FABRRRQAUUUUAFFFFADR9+nU3+KnUCCiiigYUUUUAFFFFABTW6U6mt0oAdRSUtABRRRQAUUU UAFFFFACHpSJ0pT0pE+7QIdRRRQMSloooAKKKKACiiigBv8AFTqb/FTqACiiigAooooAKKKK ACmv92nUx/u0CY4dKWkHSloGFFFFABRRRQAUUUUAFNXqadTV6mgB1FFFABRRRQAUUUUAFFFF ADT94U6mn7wp1AgooooGFFFFABRRRQAUh6UtIelAAvQUtIOnFLQAUUUUAFFFFABRRRQAlNX7 5p1NX7zUCY+iiigYUUUUAFFFFABRRRQA09RTqa3UU6gAooooAKKKKACiiigApD0paQ9KABel LSL0paACiiigAooooAKKKKACmj7xp1NH3jQIdRRRQMKKKKACiiigAooooAa3anU1uop1Agoo ooGFFFFABRRRQAUh6UtIelAAvSlpq9KdQAUUUUAFFFFABRRRQAUnelpv8VADqKKKACiiigAo oooAKKKKAGtS0jdKWgBaKKKACiiigAooooAKQ9KWkPSgBqdKfTI+hp9AkYetsfOUegrLHWr+ rnddnHYVRTJcADmmB01iu21Qe1WajgBEKA9cVJSGFNdtqFj2p1Vr9/LtHYdcUAc5eTGe4dz6 8Vc0WINOXI6Vmk5Nbuipthz6mmhM1aKKKQwooooAZJEkgw6gj3FZd3pAILW/B/umteincVjk pIXibbIpB96ZnBrqbm1iuU2yL9DWBeafJbMTglOxFG4E1nqbxYSU7k7HuK3Y3WRAynINciBz Whp9+bYhH5Q/pSGdDRTUdXUMpyDTqACiiigAooooAKKKKAGr3qlq119nt8KcM3Aq6veue1ib zbor2XigDPJLHOcmrmnWpnnHGVHJqmoycCuo06AQWy8ckZNMRaUBVAHaloopDCiiigApp+8K dTW+8KBDqKKKBhRRRQAUUUUAFFFFACN0oHShulA6UALRRRQAUUUUAFFFFABRRRQA0dTTqaDy adQAUUUUAFFFFABRRRQAUh6ilpp6igB1FFFABRRRQAUUUUAFFFFACHpQvQUHpQv3RQAtFFFA BRRRQAUUUUAFFFFADR1NOpo+8adQAUUUUAFFFFABRRRQAU1u1OprdqAHUUUUAFFFJQAtFFFA BRRRQAlA6UGhelAC0UUUAFFFFABRRRQAUUUUAM/jp9M/jp9AgooooGFFFFABRRRQAU1ulOpr dKAHUUlLQAUUUUAFFFFABRRRQAU1adTV70AOooooAKKKKACiiigAooooAb/FTqafvCnUAFFF FABRRRQAUUUUAFNf7tOpkn3aBMcOlLSDpS0DCiiigAooooAKKKKACiiigBo+/S00ffNPoEgo oooGFFFFABRRRQAU1ulOprdKAHUUUUAFFFFABRRRQAUUUUAIelIvSlPSkX7tADqKKKAEpaKK ACiiigAooooAb/HTqb/FTqACiiigAooooAKKKKACmv8Adp1Nf7tAmKOlLSDpS0DCiiigAooo oAKKKKACmr1NOpq9TQA6iiigAooooAKKKKACiiigBp+8KdTT94U6gQUUUUDCiiigAooooAKR ulLSN0oAF6ClpB0FLQAUUUUAFFFFABRRRQAlNX7xp1NX75piY+iiikMKKKKACiiigAopKWgB rdRTqa3UU6gAooooAKKKKACiiigApD0paQ9KAAdKWkHSloAKKKSgBaKKKACiiigApo+8adTR 940AOooooAKKKKACiiigAooooAY/an01u1OoEFFFFAwooooAKKKKACkPSig9KAEX7tOpq/dp 1AIKKKKACiiigAooooAKb/HTqb/FQA6iiigAooooAKKKKACiiigBrUtI3SloAKWiigAooooA KKKKACk7UtIelADY+hpx6U2PoaJDiNj7UxI5q+ObmQ5zzUdsCbhB70kp3SMfep9NXdeJkZFA HSr90UtJS0hhVTU13WUn0ouNQgt22s2W9BT5CtzakoeGHFCA5YjB9639Hx9nWsN02uVPUVsa K2YyPQ1RLNaiiipKCiiigAooooAKZIgkQqwyDT6KAOe1HTjb/PHlk/lWfXXSqGQg8g1z+o2L Wz715jP6VW4h+mXzQSCNzlD69q3wQwyOlcfnmt3SL3zE8qQ/MOlSM06WkpaACiiigAooooAj yFVie1crcN5k7v6muluW220hzjiuXJyaYh9vGXnQdya6xBhAPaud0hd94M9ua6OgYtFFFIAo oooAKa33hTqa33hQIdRRRQMKKKKACiiigAooooARulA6UN0oHSgBaKKKACiiigAooooAKKKK AGjqadTR1NOoAKKKKACiiigAooooAKaeop1NbqKAHUUUUAFFFFABRRRQAUUUUAI3Q0i/dFK3 ShfuigQtFFFAwooooAKKKKACiiigBo+8adTR9406gAooooAKKKKACiiigAprdqdTW7UAOooo oAKSlpKAFooooAKKKKAENC9KDSL0oAdRRRQAUUUUAFFFFABRRRQAz/lpT6Z/HT6BIKKKKBhR RRQAUUUUAFNbpTqa3SgGLS0lLQAUUUUAFFFFABRRRQAU1e9Opq96AHUUUUAFFFFABRRRQAUU UUANP3hTqb/FTqAEpaSloAKKKKACiiigApr/AHadTX+7QJijpS0g6UtAwooooAKKKKACiiig AooooAYPvmn0z+OnUCQtFFFAwooooAKKKKACmt0paRulAMWlpKWgAooooAKKKSgBaKKKAEPS kTpSnpSJ0oEOooooGJS0lGaAFooooAKKKKAG/wAVLSfx06gAooooAKKKKACiiigApr/dp1Mk +7QJjhS0g6UtAwooooAKKKKACiikoAWmr1NOpq9TQIdRRRQMKKKKACikooAWiiigBp+8KdTS fmFOoEFFFFAwopKWgAooooAKRulLTW6UAKvQUtNXpS0ALRRRQAUUUUAFFFFACU1PvGnU1fvm mIfRRRSGFFFFABRRRQAUUlLQA1uop1MbqKfQIKKKKBhRRRQAUUlLQAUhpaQ9KAAdKWmr0p1A BRRRQAUUUUAFFFFABTR9406mj7xoAdRRRQAUUUUAFFFFABRRRQA1u1Opj9qfQIKKKKBhRRRQ AUUUUAFIelFB6UAIvSnU1Pu06gEFFFFABRRRQAUUUUAFN/jp1N/joAdRRRQAUUUlAC0UUUAF FFFADWpaRulLQIWikpaBhRRRQAUUUUAFIelLSHpQA1OhqO8fy7Z29qkToaqaq4Wzb3piRzrH rV/RE3XRJ7CqBrY0JPldz9KANiqepXRtrcso5PAq2a53WLhpLnZ/CtIZSZ2kcsxyT1rpNO3f Y03DHFc7brvmUeprq4wFQAdhTAybzS5JJWePBBq1p9obVfmPzHrV6mn74ouJoVmCgknAqOO6 hlOEkUn0rP1q6KKIUPJ61mWJxdx/WkM6mikHSloAKKKKACiiigBrdKZNEs0RRhwRT36UvagD lbqBreZkYdOlRwymKRXXqK3tVtRLCZF+8o/OuexTEdZazCeBXHcVNWFo90Vk8ljwelblIYtF FFABSUtJQBR1JttnJ78VzjEDoK3tXbFqRnqa59gc5psSJrW7ktn3pity21aGUAPlG965sUoN SM7NHV1DKcg06uXtNRmthtBBX0NbNpqcM6DcwRvQ0wL9FNDBhkHIp1ABTG+8KdTWPzCgTH0U lLQMKKKKACiiigApKWkoARvu0o6UjdKUdKAFooooAKKKKACiiigAoopKAEXqadTAcE5pwIPQ 0AhaKKKACikpaACikooAWmnqKXNNb7woAfRSUtABRRRQAUUUUAFFFFACHpQv3RQ3SkX7ooEO ooooGFFFFABRRRQAUUUUANH3jTqaPvGnUAFFFFABRRRQAUUUUAFNbtTqa3agB1FFFABRRSUA LRRRQAUUUUAIaRelKaF6UALRRRQAUUUUAFFFFABRRRQAz+On0z+On0CQUUUUDCiiigAooooA Ka3SnU1ulAC0tJS0AFFFFABRRRQAUUUUAFNXvS0i96AHUUUUAFFFJQAtFFFABRRRQA0/eFOp v8VOoEJS0lLQMKKKKACiiigApj/dp9Mf7tAmOHSlpB0paBhRRRQAUUUUAFFFFABRRRQA3HzU 6mbgG5pdw9aBDqKTcPWjI9aBi0UmR60ZHrQAtFJketGR60ALTW6UuR60jMAKAFpabuHrS5Hr QAtFJketGRQAtJRketGR60ALRSZHrRketAAelIn3aXIpFIxQIdRSZHrRmgYUtJkUZFAC0Uma M0ALRSZooAT+KnU3I3UuRQIWikzRQMWikooAWikpaACmuPlpaRulAmKOlLSA8UUDFoopKAFo opKAFopKKACkXqaWkUjJFAh1FJS0DCiiigBKWkpaAEpaKKAGkfMKdTScEUtAhaKKKBiUtJS0 AFFFFABTWHFOpD0oAB0ooHSigApaKKACiiigAooooASmr9806mr940xD6KKKQwooooAKSloo ASilooAaw5FLSNwRTqBBRRRQMKKKKAEpaKKAEoPSlpD0oARRgU6mqcinUAFJS0UAJS0UUAFF FFACUgHzGnU0feNAh1JS0UDCiiigAooooAKKKKAGOM4p1I3anUCCiiigYUlLRQAUUUUAJQel LSGgBFGBS0L0paACiiigApKWigBKWiigApuPmp1N/ioAWilooASilooASilooASilooAa44F LSNS0CCilooGJRS0UAJRS0UAJQelLSdqAGIOtZmtvgItaidDWFrMm662j+EUxLYzyK6DR022 gPqa58DJArqbRNluin0oAkc7VJNcpdP5lxI3qa6W/bZaSH2rlT1pDL+kRq90N3bkV0eKwdEA +0E4ycda3qACmN97OakqC5kEcbMegFNCZzl/IZLuQk55xT9MTdeJ3xzVWRtzk+pzWjoihrkn 0FAG+BxRS0UhiUhIUZJ4pWIUZJwK5/UtReSRo4nwg4OO9AF671aKHiP52/Sq0OtsWxIgx7Vj k80lAHXq4ljDqeDUo6VgaVdlWETkkdvat8dKBCMMgg9DXNajB9nuWUfdPIrp6ytbh3RLKB93 rTQzFhkMUquvUGuqt5PNhV/UVyXWt/RZt9v5fdaQGliilooASilooAyNZ/1IHqaxSK2NaPCj 3rH5NMSL9ppi3VrvDYfPFVbmymtj868eord0cD7GKuSRrIpVwCDQBxxpAcVtXeincWgII9DW e9jcRn5om/KiwXCG+nhwEkOPQ1aXWpxjKqazWQg8jFJSGbaa4v8AHEfwNW4b6C4YbXx7GuZp wJHfFAbnYAgjg5pa5aK/niUBZDgetXodbYH96nHtQBt0VVt7+CdchwD6GrQII4NABRS0UAJR S0UANcfLQvSlbpQOlAgopaKBiUUtFACUUUtACUHpRWZqOpLEpSM5bpQBU1K+cSskbEDoaqQ6 jcRAgOT9arM5Zix6mm0MEblvrSkASrj3FXor+3lICyDPoa5YdKUZ655oA6/zFx94U17iJfvS KPxrlC7f3m/OkLE9STQB0Fzq0MQxGd59qoSazcE/IFUVm89KXy3borflRYLlv+1bon/WfpSr ql0D98H6iqfkSZ+435U4QS/3G/KizC6NOLWnHEiA+4q9FqlvJjLbT71zhRlPzAikP1oA69ZU YZDgg+9P61xyyMpGGP51uaZqJkIik+960AatLRRQAlFLRQA1ulCfdFKelC9KBdQpaKKBiUtF FACUtFFACUUtFADB9406kHU06gSCiiigYlFLRQAlLRRQAlNbPFPprdqAFpaKKACkpaSgAopa KAEpaKKAEPSkXOKU9KB0oAKKWigBKKWigBKKWigBKKWigCPnzKfSfx0tAkFLRRQMKSlooAKS looASkfOKdTW6UAKOlLRRQAlFLRQAUlLRQAUUUUAIaanen01aBC0UtFAxKKWigBKKWigBKKW igBh++KdSH71OoEJS0UUDCiiigBKWiigBKa/3afTX+7QJijpS0g6UtAwooooAKKKKACiiigA ooooAjK7m5pfLWlH3qdTFZDdi+lG0U6ikFhuwUbF9KdRQFhuwUmxafRRcLDdi+lIyDFPprdK AsII1Hal2L6UtFAWQmwelGwU6igLDdgpNi+lPpKAsJsFGwelOooCw3aMUioMU6kXpQFg2CjY KdRQFhmwUbBTqWi4WGbBRsFPoouFhmwUbB70+ii4WIig3U7yxS/xU6ncLIYIxnqaNgp1LSuF kM2D1NGwe9PoouFhmwepo2D1NPoouFkM2D3pHX5akpr/AHadwaQ0RjHJNLsHqacOlLRcLIZs 46mjYPU0+ilcLDNg9TRs46mn0UBYZsHqaBGB3NPoouFkM2e5poTLHmpKRe9O4WQmznrRs9zT 6KVwsM2e5o2e5p9FFwsM2e5o2e5p9FFwshmz3NG33NPooCxEyZI5pRH/ALRpx+8KdTuFkMCf 7Ro2f7Rp9FK4WQwJ/tGjZ7mnUtFwsM2e5o2e5p9FAWGbPc0MvHU0+kbpRcLDFQ460eWf7xp4 6UU7hYbs/wBo0bD/AHjT6KQWGbD6mjZ7mn0UBYZs/wBo0bT60+igLDNp/vGmhDuPJqWmr940 7g0JsP8AeNG0/wB40+ikFhm0/wB40bT60+igLDNp9aNp/vGn0UBYZtP96jYf71OophYjdScc 0uw4+8aceopaLhZDdh/vUbT/AHqdRSCw3af71G0/3qdRQFhoU4+9RtP96nUUBYbtP96gqcda dQaAsRqh65xSlW/vU8dKKdwSQ0K2OWo2n+9TqKQWE2nHWjaf71OooCwzaf71G0/3qdRQFhMH +9TcHceafSD7xphYTDf3qNrf3qfRSCwza396jDf3qfRQFhuG9aTDetOooCw3Df3qMN/ep9FA WI3BIHNAD45NObqKdTFbUZhvWjDetPopDsMw3rRhv71PpKAsNw3rRhvWn0UBYYA3rRhsHmnU HpQFiNVf1xTsP6inL0op3Cw3DetGG9afRSCwzDetJh/71SUUBYZh/WjD+tPooCwzDeoppDbq ko707hYbh/UUYf1FPopBYZhvUUYf1FPooCwzDeoow/qKfRQFhmG9aMN6inUUBYY4Y96Ub/al bpS0wsNO/wBqPn9qdRSCw35/aj5/anUUBYb8/tR8/tTqKAsN+f1FHz9yKdQelAWIV3jJFc7e PuuZCfWujdgkLt6CuWc5kYnuc1QkrDoFLzIoHJNdOgcIBxWBpab71MjpzXSUh2MvWZXS32kD DVg5rY18nKL2rGpAbeiRnYzr3rV/ee1UNEQra7ieprSp3Cw35/as/VpClsQcc8VpVia6x3KO cUBYyCRWxoaHa7L16VjVq6NMId5c4Xuc0IZt/vPaj5/aqLazbiTbyR61cFxG0XmBhtxmlcVj N1e8ZF8kEAnrWGOTU17MLi6Zx0zxRaRebcovbNAy3Z6W08e9jgdqrXlsbaYoenY11KKFQAVl a7H8iP6GncVjHhYpIpHrXUwNI0SkgdK5VchhXUWLtJbIWGDigLE2Xx0FV7yN5bZ1OOlWqRxl CPai4WOPPDY7itTRJMSMo71n3A2zuPQ1b0f/AI/B9KAOg+f2o+f2p1FILDfn9BR8/tTqKAsY es5Dr61l961daI8xRWVVCR0OlB1tFxjBq78/tVbS1C2SY71bpDsN+f2pPn9BT6KQWK8lqkpy 8an8KhbTYG/5ZAfSr1LT5mLlMiTRUblCVqrNpEyfcIauhph+8KLhaxyctvLEcOjD8KYRiuwZ FYfMoP1qlPpVvLkgbD7UaDObzjpV211GaDgncvoakuNHnjBKYce3WqDxtGSGBBosBuwavHIQ rfKfer6SbxlSpHsa5DnNWLe7mgPyOQPSkFjqcv6CjLegrLttYViFmXb71ppKkgBRgQfSi4WB i23pSKXx0p7dKUdKYWG5f0FGX9BT6KQWGZb0FGX9BTqKAsMJfPQUuW9BTqr3twttAXPXtQFi rqGoeQDGMFj6dq5923sSx5NOmlM0rO3U1PY2L3T8cKOpo3HsRQW8kzAIpIrUh0cggyHI9K0r S2S3TagqxT2FuZbaPCeikfjTDoq54c1sUlPmFymQNFXuxNPXR4gPm3H8a1KKOYOUpx2MUf3Y V/GpwhAwEXFS0UrjsR4P9wUjAgjCipaQ9RRcTRC8QkHzRqfrWVf6YFDSINo9BW5TJUDoVPQ0 XCxx569atac5W5XHrTb6DyLll/EUlmQLlN3rSGdSC+Ogpct6Uq8qKWmFhuW9KMv6U6ikFhrF tp4pqM2Pu09uhoXoKYraibm/u0Zb0p9FIdhmW/u0Zb+7TqKAsNy392jL+lOJAqKS5hj+/Io/ Gi4WFDvn7tP3N/dqi+rWyNjcT7gVC+uRA/KjEUXCzNHc27gU7c392sn+20ByIjn60n9uj/nk c/Wi4JGvub+7TTJt6jFYsuuSN/q0C/WqM17NMTvc49BRcdjqRIW6DNLub+7XO6dfNBKFYkqf U10akMoI6GgVhAzf3aNzf3afRQFhm5v7tIxPpT6Ru1MLCbm/u0bm/u06ikFhu5v7tG5v7tPp KAG7j/do3H+7TqKAG7j/AHaNzf3afRQFhmW9KQM393NPoHSmFhu5v7tAZv7tOopBYbuP92jc f7tPooAZuP8Ado3H+7TqWgBu446UgY/3afRQBEWIfpTtx/u0v8dLTEkJuPpSbj/dp1FIY3cf 7tG4/wB2nUUAJuPpSFj/AHadRQA3cf7tDE46U6g9KYWGhjj7tG5v7tOopBYbuP8Ado3N/dp1 FAWE3H+7Sbm/u06igBMn+7RuP92looATJ9KaGIzgU+kXvTCwm4/3aNx/umnUUgG7m/u0Bm/u 06igBu4/3aNx/u0+igBu4/3aNx9KdRQBEzHdwKduP900v8VLTCw3ef7po3H0p1LSCwzcf7po 3H+6afRQAzcf7po3HP3adRQAm4+lNdjjpUlNf7tNA9hR0paQdKWkMKKKKACiiigAooooAKKK KAGj7xp1NH3qdQJBRRRQMKKKKACiiigAprdKdTW6UAx1FFFABRRRQAUlLRQAUUUUAIaRelKa RelADqKKKAEpaKKACiiigAooooAb/HTqb/FTqACiiigAooooAKKKKACmv92nU1/u0CYo6UtI OlLQMKKKKACiiigAooooAKavU06mr1NAh1FFFAwooooAKKKKACiiigBp+8KdTT94U6gQUUUU DEpaKKACiiigApD0paRuhoAB0paRegpaACiiigAooooAKKKKACmr9406mr1NAh1FFFAwoooo AKKKKAEpaKKAGnqKdTT1FOoAKKKKACiiigAooooAKQ9KWkPSgAXpS01elOoAKKKKACiiigAo oooAKaPvGnU0feNAh1JS0UDCiiigAooooAKKKKAGt1FOprdRTqBBRRRQMKKKKACiiigBKD0o oPSgAXpS01elOoAKKKKACiikoAWiiigApP4qWm/x0AOooooAKSlooAKKKKACiiigBrdKWkfp S0AFLRRQAUUUUAFFFFABSHpS0h6UAU72QJZyflXOd62tXkAt9ueSaxKolGtocQLPJ6cVt1na Km203eprRpMoxde6x8Vj45rd11Mwo2OhrB70COm0rH2NcVcrH0KbKtET05ArYpDFrM1Wze52 mPkjtWnTD98UITMK30aV2zKQoHamaoVgIgiUKB1966Os7UtON3ho8Bh60wOaJxUizOilVbCn qKkubSW2bEiY9+1QY5pWHcAK1NEjJuC23IA61RgtpJnCopJNdJp9r9lgCnG7vTEW6y9ajZ4l KgnB7VqUhAPWkM5yxsmmfcwIUH0rokXaoA7UhUAcDFOpsSFpD0NLTWOFJpDOWvRi6kHvVnRl zdg7c4H5VVum3XDnqc1d0QE3JIzjHNMRv0UUUhhRRRQBg60f3yisytHWf+PgfSs6qEjp9O/4 84/pVqqunf8AHnH9KtVIwooooAKKKKAEprfeFOprffFAmPooooGFQTWsMwPmID71PRQBi3Gi ZyYX/A1mTWs0DEOhHv2rraayK4wwBHvTuKxx3apI5XiIZXII963p9JglyV+Q+1ZVxpdxDnau 9fUUWAmg1eQHEw3L6itSDULeXADgH0NcxtKnkEH3o6dKQzsQwIyDmlrlYL2eDG1zj0NX4NbI 4mTPuKANyiq0F9bzgbJBn0PFWAwPQigANYGtTl5hEDwtbzHiuVvm3XchPrQBHBEZZQg7109n bLbQhV69zWFpQBvF9q6UdKYhF6mnUxepp9IYUlNeRYxliAPesm71kKxWFc470Aa+aNw9RXLS 39xKfmkOPaoTNJ/z0b86AOwBormbbU7iAgFt6+hrds71LpcrwR1FAFqmt1FLTW6igGPpKWo5 ZFiUsxAFAGLrsQWRZB34rLhP7xSexq/q17HchVTPB61mKcUAdjAwaJSOmKlrm7bWJIUCFQwF TjXW3f6sEfWgDdorEGu9P3X607+3U2n90c/WgDXb7poT7orFOuZGPK5+tVpNYuSfkwooA6Ms B1IqJ7uCMkNIoP1rl5bmeU5eRj+NRZJ6nJpAdHLrFsgO0lj7CqMuuSE/u0C/WsoZqaO0uJfu RMR9KdmFySXULmUYMhA9uKrMzMeTk1ow6PO/38JV+LRoFHzksadhXOfpQjnoprqEsbZcYiXi pxGijhQPwo0DU5IwyY/1bflR9mlP/LNvyrrVUbjwKdgelGganGMjp1Ug+9Jz3ro9ZRfsZOOR XO0hixLvcAHBrq7JWW2UO24461zliqtcoGAwTXUoAqgDpQA6iiigAprdqdTW6igB1FFFABRR RQAUUUUAFFFFACHpQvSg9KB0oAWiiigAooooAKKKKACiiigBn8dOpv8AHT6BIKKKKBhRRRQA UUUUAFNbpTqa3SgBaWkpaACiiigAoopKAFooooAShaKRelADqKKKACiikoAWiiigAooooAb/ ABU6m/xU6gBKWkpaACiiigAooooAKa/3adTX+7QJijpS0g6UtAwooooAKKKKACiiigAooooA aPvU6mfxU6gQtFJRQMWiikoAWikooAWmt0paa44oEx9FIKKBi0UlLQAUUlFAC0UlLQAh6Ui9 KU9KRPu0CHUUlLQMKKSigBaKKSgBaKSigBP46dTP46dQJC0UlFAxaKKSgBaKSigBaa/Slpsg ytCE9hw6UtIOlFAxaKSloAKKKKACiikoAWmr1NLTV6mgQ+ikooGLRSUUALRSUUALRSUUAIfv CnUw/eFOoELRSUUDFopKKAFoopKAFpG6UUjZ2mgBV6Clpq5wKWgBaKSigBaKSigBaKSigBaY vU06mJ940xMkopKKQxaKSigBaKSigApaSigBG6inUxvvCnUCFopKKBi0UlLQAUUlFAC0h6UU h6GgBV6ClpqZ20tAC0UlFAC0UlFAC0UlFAC00feNLTV+8aBD6KSigYtFJRQAtFJRQAtFJRQA 1+op9Rv1FPzxTELRSZrOvdUjgyi8vSGaOaMiuVl1C4kJ/eEZ7Cki1C5i6SE/WkM6yisS31sY xMnPqK0Yr6CUZWRfxOKYizQelRLPGTgOp/GnNIuOooAcn3adUaOMU7dQJDqKTNGaBi0lGaM0 ALRSZozQAtNH3jS5pgPzmgRJRSUZoGLRSUZoAWikooAWikooARulOpjngU6gQUtJRQMWikoo AWiiigApD0ooPQ0AYGrOGl255FZw69atag267f2qCIbpVHqaolHTWKbLSMe1WKZGNsaj0FOq SiC+h8+1dB1xxXLMu0kHqK7CsHVrMxS+agO1uvtTEUbWc28yuOx5rqIJ0njDocg1yJqxa3kt q+UPy9xSGdXTT98VTs9SiuQATtf0NWt3zjFAmSUUlGaBjZYklQq6hgfWqn9lWu7ITHtV2ii4 rDI4Y4vuIBUlJRQMWikooARulLTXPFOB4oAWq97IIrZ29qnJwKwdYvBKwijPA60AZpOSTW3o cW2NnPc1jQo0sioOpOK6i1iEECoOcUxE9FJRSGLRSUUAc/rBzcj6Vngc1f1c/wClfhVAU2JH UWH/AB6R/SrNVrA/6JH9KsUhi0UmaKAFopKKACmn74p1NY/OKYmPopKKQxaKKKACikozQAtJ RRmgCC4tYZkO9Bn1rKudGbGYDn2NbbHApR0p3FY5GW2lhOJEK1Cc12TorghgCPes260eOTLQ nY3p2o0AwMkVNDeTwtuRz+NOubKaDO9Dj1FVelKw0zYTWnwA6D61mTyeZMz8YJqLrS4NAF/S CBeL9K6XtXL6a+y7Qn6V04ORQAidTRJIsaFmOAKRT1rF1i8LN5K9B1oYkV9Rv2uWKrwg/WqP LHApVUuwVRya39O04QqHkwXP6UJDZkx6bdSYIjIHqaSXT7mLOYyR6iupGAMUtPQRxhVk4Iwf epIppIW3RttPtXRX+nx3KEgYk7GudmheGQo4wRSHc6DTL77Qm1yPMH61dP3hXJQSmGVXHY10 trdJcorL+IoQMt1ja6ZNi4zs71sVDcwpPEUcZBoA5BqaM896nuYxHMyDsafZQfaJgnQd6AK4 BI6Uu046cV1cdlAsQQxqQPUU8WsAGPKXH0p2QtTkQp9DS7T6V1wt4R0jT8qPs8JOTGmfpRoG pyawueiE/hUqWNxIcLG35V1LIoXhR+VKmNoo0DUwYtFmYAuwWr0WjQLgvlzWlRRcCGO0gjGF iUfhUwAA4GKKKQxaKSigApaSigBB9406mKfmNOoEilq3Nk+a5k8Gul1fH2NsmubIoGWdO/4+ 0x611I6VzGmD/TEPvXT0ALRSUUALTW6inUxuooEx9FJS0DCiikzQAtFJRQAtFJmigANC9KD0 pFORQA6iikoAWiiigAooooAKKKKAGfx06m5/eU6gSFoopKBi0UUlAC0UUlAC01ulLmkY8UAL S0lFAC0UUlAC0UUlAC0UUUAJSL0paRT1oEOooooGFFFJQAtFFFABRSUUAJ/FTqaT8wpaAFop KWgAooooAKKSloAKY/3afTX6UCYo6UtIOlLQMKKKKACiiigAooooAKKKKAGj71Opo+8adQAU UUUAFFFFABRRRQAU1ulOprdKAHUUUUAFFFFABRRRQAUUUUAIaRelKaRelADqKKKACiiigAoo ooAKKKKAG/xU6m/xU6gAooooAKKKKACiiigApr9KdTX+7QJijpS0g6UtAwooooAKKKKACiii gApq96dTV70AOooooAKKKKACikpaACiiigBp+8KdTT94U6gAooooAKKSloAKKKKACkPSlpG6 UAA6UtIOlFAC0UUUAFFFFABRRRQAUxfvGn0xepoEPooooGFFFFABRRRQAUUhOKWgBrdRTqae op1ABRRRQAUUUUAFFJS0AFIelLSHpQAL0paRelLQAUUUUAFFFFABRRRQAU0feNOpo+8aBDqK KKBhRRRQAUUUUAFFFFADH6inU1+opXOFJpiM3VNQ8geXHyx6+1YDsXfcxyTU15IZLlyxzzUH ekMaQc0vbirkWmzSxiRcYNTW+lTNIPMBC+op2Fcze2aC3FdBqFpHHZ/Ki8d6wGGODSYxA5H3 WINSCWTg72/Oo0Us2B3rXg0bfFukcqx9KEgbM43MveRvzp63dwvSVvzrS/sRWXiU/iKVtD+X 5ZefcU7CuUBqN0P+Wpp66tdADLA/hUzaJN2dTTG0W5XoVP40WC44a1OP4VNKNcm7xoahOkXQ GQoP41G2n3S9YjRYLl1NcfPzRD8DU6a3Cfvoy/rWQbK4GP3T/lUbQyr1Rh9RRZhc6Eatakfe I/CnC/tjlhIprmiGHY01yQKWw9zbfXAHwseR9auWeox3XAG1vQ1y1PRmBypI+lIZ17zRoMs4 H1NUJ9YgjbCAv9KwC7n7xJ+tN57UxG8mtxMcMjL71oW9xHcLujbNcjVvT7l4J1APyk8igDqa KapyoNOoAa/SnU1ulOoEFFFFAwooooAKKKKACmyHCE+gp1Q3TbLd29qAOYnbdM7Hual09PMv EB6ZzVdzkn3rQ0Rd10WI6CmI3xwKWiikMKZJGsqFXGQafRQBz19pjwktGNyfyrOxziuxIyOa o3elwzksvyN7U9xHOAkHg4NXLbUpoCMnePQ0lxps8GSV3D1FVCpBwRiiwHQQaxDKwVgUJ9el Xlljbo6n8a5ClV3U5DEUhnY0tctHqFzGeJCR71bTW5Rw8amgDepKyE1xf44j+BqT+2oNudjZ 9KANSiswa1b45V8/SmtrcWfljY0Aab9KGZVXLEAe9Yk2tSNkJGAPeqM97NcH943HoKANPUNV UKY4Dk9zWLksckkmhVZzgAk1tabpeAJZxz2U0xDtL0/Ztnk+92FatAAAwKWlcYUUUUAFJS0U Ac5q3/H2QapAZNXNVObxs1Uh/wBaoPrTEdPZgi2QH0qxTIv9Wv0p9IYUUUUAFFFFABTGHzin 00/eFAmOooooGFFFFABRRRQAUlLRQAjdKB0obpQOlAC0UUUAMdFdSrAEH1rKvdIUgtBwfSti ii4HNwaTNIfm+Ue9VbmHyZ2jznFdaa5jVOLySmIhtcC4TnHNdYn3B9K5K3/1yHGea61OUH0p DGdmrlrpt1w5966k8q4rlJ8iZwfWmxIm04Kb2PdXUjpXH28xgmVwM49a14daywEiYHtSGbNF RxTpKoKsDUmaAFrO1WyE8JdfvrV8sAMk4qOWaJUO9wB9aAOROQav6TMY7kA5weKq3ar9obYQ RnIxSWwJmUDrntQB146VBeSeVbu/oKljBEag9cVm65NthEY6tQBhOxeQseSTWzolsApmPU9K x4lLOoHUmuqtIRDAqj05piJqWiikMKKKKAGt900KPlFK33TQv3aBBS0UUDCiiigAooooASlo ooAaPvGlpB9406gEZmtsBbhSOSa5881r67LukSP05rIoA0dGhD3OT/CM10OKydCjwjuR1rXp sBKWiikAU1uop1NbtQAtLRRQAUlLRQAUUUUAFFFFACHpQvSg9KF6UALRRRQAUUUUAFFFFABR RRQAz+OnU3+OnUCQtFFFAxKWiigAooooATFIw4p1NbpQDFApaKKACiiigApKWigAooooASkU cUtIvSgB1FFFABSYpaKAEopaKAEoxS0UANON1Opp+9TqBCYopaKBiUtFFABRRRQAlNf7tPpr 9KBMUdKWkHSloGFFFFABRRRQAUUUUAFFFFADR940tRtnfxS4f1FOwrj6Kbh/UUYb1pBcdRTc P6ijDetAXHUU3DetBDeooC46g03DeopGDY60wuPpajw+OopcP6ikFx1FNw/qKMN6igLj6KZh /UUYf1FAXH0UzD+oow/qKAuOpF6UnzeopF3Y7UwuPopPm9qT5/UUguOpaj+f1FL8/tQFx1FN +f2o+b2oC46im/P6ij5/agLi/wAVLUZ37uKX957U7CuPopg8z2pfn9qQ7jqKb8/tR8/tQFx9 FM+f2o+egLjqa/3aPn9BTX3Y5xTQN6Eg6UtRqXx0pcv6CgLj6KZlsdKMv6CkFx9FMy/oKMv6 CgLj6KZl/QUZf0FAXH01e9JlvSmgvk4FMLktFMy/92jLelILj6KZlvSjLelAXHUtR5b0pdzf 3aAuPopmW9KMt/doC4p6inVExbI4pdz/AN2nYLklFMy3pRl/SkFx1LUe5/7tLub+7QFx9FM3 N/do3N/dphcdQelNy3pQScHigLjh0oqNGOOmaUs392iwXH0U3c392jc392kFx1FNy392jLf3 aAuOopu5v7tG5v7tAXH0xfvGly3pTFY7jgUwbJaKZub+7Rlv7tILjqKbuP8Ado3N/doC46im 7j/do3N/doC46imlm/u0bm/u0wuKetLUbMRjil3t/dosFx9FN3N/do3H+7SC46im7j/dNG4/ 3TQFx1FNDH+7RuP92gLj6Q9KbuP92gscdKAuOHSlqNXOOmaXcf7tOwXH0Uzcf7tG4/3TSC4+ imbj/dNG4/3aAuPopm4/3TS7j6GgLjqaPvGjcfQ00Mdx4phckpKbuP8AdNG8+hpWC4+imbj/ AHTRvP8AdNAXH0Uzef7po3H+6aAuPopm72NG/wBjRYLg/b60Sf6tvpTZG6cVHPNtt3JBHFOw rq5zEx/et9TSQrukUeppHOWNS2ZUXKFuRmgZ1FugjhVQMcVJTFf5R8ppd/saAujN1yRlt1VT 1PNYBNa2uSFpEXoBWVSAsadD5tyo9DmupAwgFY2ixBQZMZzxWwX46GmFxV6U6okk45FO3+xo sCaH0Uzf7Gjf7GlYLj6Sm7/Y0hk9jTsF0PpCqnqAaTf7GjzPY0BdDWhiI5jX8q5rUdv2pwgG 0cYFdHNOEiZiDwK5eZt7s3qaAIgK3bPSoXgVpMliKybSEzTKo9a6iNgqABTxQFyoNItQOQT+ NRXNvYWy5dB+dX5pdkTNg8CuWmkMkjMecmi7BWLbWKXHzWbAj+6eop1tpU5mHmLtUHk03SGY XeR0xzXQCQehoAcqhVAHanUzePQ0bx6GlYLit0paY78dKUSDHQ07BdDqWmeYPQ0bx70rBcfR TN49DRvHoaLBcfRTN496N496LBcfVHVn2WbY78Vb8we9ZmtSAxIoPOadguYpPNa+hIf3jn6V kGt7SPkteV6nNAGlRTN49DS7x6GlYLjqKZvFLvHvRYLjqKZvHvRvHvRYLjqrTWUEzfPGMnuK sbx700uAwpq4NozpdFib/VuV9jzVOXR7hPu7XHtW9vHvS7xQGhyz2k6HDRMPwqFkYcYI/Cuu 3LTWWNvvID9RQByWKQ8dq6k21qScwrz7VGbCzP8AyyxTFc5qjBzxXTCxsx/yyFPW0tVPEK/l RoFzmVjduFUn6VdttJnlILjYvvW7iNR8qgfQU8OMUBcr22nwW4GF3N6mrVN3ijeKQ9B1LTN4 pd4pBcdRTd4pN4osFx9JTd4oLjFFguc3qJzdyZ9agjHzr25qa/8AmupCD3qGBcyqPeqA6qHI iXPpUlRRuNgFO3ilYLjqKbvWjeKQXQ6ik3ik3rQFx9NP3hRvFNZwCKdgbRJRTN60u8UguOop u8UbxQFx1FN3ijeKAuOopu9aQOD3oC45ulAprOMcUBwRTC4+im7xRvFILi0Um8UnmL60BdBI 21Ca5W9lMty7H1xWzqt6Y02JjJrAOWJJPNAyxYLvu0GM811SjCgVz+jQ5n8xug6Vvb19adhX QYyGrlb5Nly46c11AcZOaydVszK/mR80WFdGJiip/ss3ZCaX7FcH/lk1HKx3RGk0ifdYr9DU 639yo4mNRtazL96Nh+FMMbD+E/lSsx3JJL2eRdryMRUTSO2NzE0eW/8AdP5UeU5/hNFguJ1r S0q1LzBznC81FaWDySLvUha34ljgUKvSqSsS2T9q57WZC10VPQCt4yqB1rmb+QS3bsPWkO47 TkV7yMH1zXTjpWBowX7QWbsOK3d6+tADqKbvX1pd6+tILodRTd6+tG9fWgLit0NC9BTWYAda RXXHWmF9SSim719aN6+tILjqKbvX1o3r60BcdRTd6+tG9fWgLjqKbvX1o3r60BcB1NLTA43H mo7mcRwOwPIFOwXRganJ5l4/scVVAzTnYsxZuSTmnW0ZkuEX3oA6PTo/LtEGOSM1aqNCqqAD 0p29fWgLjqKbvHrRuX1pBcdTW7Ubl9aRnHFAXH0U3cPWjevrQFx1FN3r60b19aAuOopu8etG 4etAx1FN3D1o3L60AKelA6Um4etIHX1oFcfSUm9fWjevqKAuOopu4etG5fUUDHUU3cPUUbl9 aAHUU3cPWjcPWgA/jpaZuG+nbl9RTEmOopu4etG4etIY6im7h60bh60AOopNw9aTcPWgB1Nb pRuHrSMwx1oFcdS00OuOtG5fUUDuOopu4eoo3L60AOpKTcPWjevqKBXHUU3cPWjcPWgYtIve jcPWkDD1oEPopNw9aNw9aBi0U3cPWjcPWgB1FJuHrRuHrQAtFJuHrRuHrQAh+9TqYWG7rS7h 6igVx1FN3D1o3D1oHcdRSbh60bh60ALRSbh60ZHrQAtNfpS7h6012AHWgTY4dKWkHSloGFFF FABRRRQAUUUUAFFFFADR9406mj7xp1AkFFFFAwooooAKKKKACmtwKdTX6UAOopKWgAooooAK KKKACiiigBD0pF6UvakXpQA6iiigAooooAKKKKACiiigBv8AFTqb/FTqAEpaSloAKKKKACii igApr/dp1Mf7tCExw6UtIv3RS0DCiiigAooooAKSlooAKavenU1epoAdRRRQAUUUUAJS0UUA FFFFADT1FOpp+8KdQAUUUUAJS0lLQAUUUUAFI3SlprfdNACr04opF+6KdQAUUUUAFFFFABRR RQAUxfvGn0xfvGgTH0UUUDCiiigAooooASloooAa3UU6mt1FOoAKKKKACiiigBKWiigApD0p aQ9KAEUYFOpB0paACiiigAooooAKKKKACmj7xp1NH3jQIdRRRQMKKKKACiiigAooooAY+DjN Zmsz7IQink1pv2rM1m03x+avUdaYjAzzU1q6pcIzdAahIGaB7UhnZRsGQFemKdWfo03mWgU9 V4rQoA5/Wzm6A9BWbV/Wf+Pw5PaqGaAOh0X/AI9OnetE9KztFObQfWtE9KYDUGBTqRfu06kJ CUUtFAxKa8iIMuwH1pzHAJrmdTujcXBwTtXjFAHSJIkgyrAj2p1c5pE5juQmeG4rox0oAoax LstCB/FxXNk1ta833Fz+FYpoAtadcLb3Ad84xXQ215Dc8Rtz6VyQqWGZ4JA6HBFAHSarJ5dm +DgniuZ6nitK+1Bbq0C9HB5FZlAGvoSjzWatysjQkHls/fpWxQAUUUUANbpS01+1OoEFFLRQ MKKKKACiiigBKwtbYG4Vc9BW9XOaq2bxqaAogZNdTYpttIxjtXMICzgZ711cI2wqPahiH0tF FIYlFLRQAlFLRQAlJj5qdTf4qAFopaKAEopaKAEopaKAEopaKAGsMilAAFI3SnUCExRS0UDE opaKAEwKMUtFACUHoaWmtwp+lAHL3fNzIR60WYzdRjGeabcHMz49TUlgM3ceR3piOmAGBS4o HSlpDEoxS0UAJijFLRQAlNYAsOKdTT98UCY7A9KMClooGJijFLRQAmKMClooATAoxS0UANYc UoAxQ3SigAwKMUtFACYFGBS0UAYOs28pmDqpKn0qhHaTSMFVDmusIB60m1Qc4FPQRXsbUW8A UjnvVnArF1PUnSUxQtjHU1WttVmi4b5196VxnQgDJp20elULXVIJeGOxj2NXwwYZByKAsJtX 0FLtHpS0UAN2j0FJ5af3R+VOpaAGeWn90flTWgibqin8KlooFYaFA6CkZQSKfTW4IpgMmUeS 2OOK5N/9Y2eua6S/ukjgYBxk8da5luWJpAauhkeawI7Vu4HpWNoUbAu5GB9K2qBiYHpRgelL RQAmB6UYHpS0UANYAikVQFpW+6aF+6KYhcD0owPSlopDEwPSjA9KWigBMD0owPSlooATaPSj A9KKWgCMKNxNUNacJa7e7GtEfeNYmty7pljH8IzTFYyj7Vp6LAWuGcjgCsw4roNFjKWu49zQ Bo7R6UbR6UtFIYm0elGB6UUtACYHpSFRxxTqa3agQuB6UbR6UtFAxMD0o2j0paSgAwPSjaPS looATA9KMD0paKAG4GOlIFHpTj0oXpQKwm0ego2j0p1FAWG7R6UbR6U6igY3aPSjaPSnUUCs N2j0o2j0p1FAyMqC9O2j0o/jp1Akhu0elG0elOooCw3aPSjaPSnUUDsN2j0o2j0p1FADdo9K RlGOlPprdKBWAKMdKNi+gpaWgLDdo9KNo9KdRQA3aPSjaPSnUUBYTA9KTaPSnUUDEwPSmqo9 KdSLQIXaPSjaPSlooGN2j0o2j0p1FArCbR6UbR6UtFAxu0elG0elOooFYYUBbpS7R6Cj+KnU BYbtHpRtHpS0tA7CbR6Um0elOooAbtHpRtHpTqKAG7R6U2RRt4FSUx/u00JocOlLSDpS0hhR RRQAUUUUAFFFFABRRRQAwffp1J/FTqBIKKKKBhRRRQAlFLRQAlIx4paRhxQAtFFLQAlFLRQA lGaWkoAWkpaKAEJ4pFPFKelInSgQtFFFAwzRmiigAzRRS0AJRmiigBufnp1Nx89PoEhKWkpa BhRRSUAFFFFAC0yT7tPprdKBMF+6KdSDpS0DCiikoAWikooAWkoooAKah606moOTQIfRSUtA wpKWkoAKKKKAFopKKAGn74p9MI+YU6gSCloooGJS0mKWgAooooAKa3Q0tIw+U0AKvQUUi9BS 0AFLSUUALRRSUALRRRQAlNX7xp1NUfMaYh9FJRSGLRRSUALRSUtACUtJRQAjfeFOpjDkU6gQ tFFJQMWiiigBKWkooAWkPSig9KAEXpTqav3aWgBaKSigBaKSigBaKSloAKYPvmnU0D5jQJj6 SiigYtFJRQAtFJRigBaKSjFADJDjFUdYkdbU7cYPWr0g6Vm644WBV9TTF1MA9amtLdrmbYDi ojxU1nctbShl6dxSGdLZWwtYQgOfU1YPSq9pcJcxB1P1FSTMI4mb0FMDndVOb1uc1SzUlxIZ ZmdupNRikB0ejAizGe9X2PFUtJIazXHaotVvDAvlp1amBPLqEEHys3zegqAa1BuwQ2PWsB2L Eljkmm5pAdfBcRzoGQ5FS1yVtdSW7hkbA7iuot5RLCrgjkUAMvphFbOxOOOK5ViScmtjXJcB YwevJrG70AX9JiD3QJHA5rpB0rK0SLEJc961COKYjB1tgblR6Css1d1U5vG9qp4zSGXl0xnt FmQ5OM4qiylWwRg102mr/oaZ9KjvdMS4yyna9MRzZNKCKlubZ7d9sikVBxmlsPc6DQj+4YZH WtauStLqS2bMbcHtXR2Nz9qhDkYPegC1RSUYoAR+lLTXGcU6gQUtJiigYtFJRQAtFJRQAHpX MXxzcyHjrXTP9w/SuUmOZW+tNALajdcIp9a6tRhQK5jTl3XiYHeunHShgLRSUUgFopKKAFop KKAFpv8AFS00j5xQA+ikooAWikooAWiikoAWikooARulLSOMiloELRSUUDClpMUUALRSUtAB TJRmNs+lOpsvETH2oA5SU/vGxxzVjTObxBVeT75+tWdM5u04piOkFLSCikMWikooAWikooAK afvCnU1vvigTH0UlFAxaKSigBaKSigBaKSjFACN0pR0pGB20o6UCFopKKBi0UlFAC0yRN6Fc kZHUU6igDmr3Tprdi3Lp61Sx+ddkQCMHkVTn0y3mydu1vUU9BHMgmp47ueH7khH41YuNLmiJ 2DevqKptG6/eUj6iiwJl9NZuFxkK1WF1z+9F+RrF20uKVh3Ohi1e3c4bK/WrIvbc/wDLVfzr le9LQB1YuYSMiRfzpRcRH/lov51yWaCT6mgDq3u4E+9Kv51SutUg8s+W2T7VgH60cmgBXdnY knrU1kiSXCo67gahVCxAAJNbulWHlDzZB83YHtTSEaMMSxRhUGAKkpKKQxaKSloAKKSigBG6 GhPuihvumhPuigXUdRSUUDFoopKAFopKWgAopKKAGj7xrnNRYveSbTntXQSNsV29BXLTP5kj Me5piGgEnFdRYR+XaIp64rmrdC86KO5rrEG1APagB1FJRSGFLSc0c0ALTW7UtNbPFAh9FJRQ MWikoNAC0UlFAC0UUlAAelC9KD0pEztoAdRSUUALRRRQAUUlLQAUUlFADf46dTP+WlPoEhaK SloGFFJRQAtFJzRQAtNbpS0184oEx1LSDpS0DCiikoAWiikoAWiiigApq96WmrnmgQ+ikooG LRSUUALRRRQAUUUUAN/ip1MOd4p1AC0UlFAC0UlLQAUUUUAFNfpTqY+cUITHDpS0g6UtAwoo ooAKKKKACiiigAooooAaPv06mj7xp1AkFFFFAwooooAKKKKACmt0p1NbpQA6iiigAooooAKK KSgBaKKKAENIvSlPSkXpQA6iiigAooooAKKKKACiiigBv8VOpv8AFTqACiiigAooooAKKKKA Cmt92nU1/u0AxR0paQdKWgAooooAKKKKACiiigApq9TTqavU0AOooooAKKKKAEpaKKACiiig Bp+8KdTT94U6gQUUUUDCiiigAooooAKRuhpaRuhoAF6ClpF6UtABRRRQAUUUUAFFFFABTF6m n0xfvGgQ+iiigYUUUUAFFFFABRRRQA1uop1NbqKdQAUUUUAFFFFABRRRQAUh6UtIelAAvSlp F6UtABRRRQAUUUUAFFFFABTR9406mj7xoEOooooGFFFFABRRRQAUUUUAMftWPrrAlF79a2H6 isPW2BuFHcCmIym60CnYoeNo8Bhg0hmho9z5UxRjhWrcuGXyGLDK4rkQ2CMcVptqIksDESQ+ MfWgDNlI8xiOmaQUhNKvNAHSaQCtmuR1rK1hybsg9hW3p6gWiAHPFY+tR7LoNjgimBmmgqQM 44o4BqbeGgKHqORSAgGcVds9Re1XaOV9KpHp1oz70AS3Nw1xKZG79qagLsFHU0wcitXSbPzJ RK6/KOlCBmxZReTbIvfFTMcA5pQMCmykCNifSgDmL+QSXUjDpmoEGWA9TRKcyMR3NPt0MkyK O5piOptl2wIPapaZGNqAegp9IZT1KNXtHyBkCuXIrrbwZtpBnHFcoetAFiwtRcz7ScCuktrd LeMIg4rD0b/j75x0roaYC0UUUgGt0p1NbpTqBBRSUtAwooooAKKKKAGTHETH2rlZR8xIPeul vW22sh9q5hjnrTQF7R13XYPoK6GsHQxm4c56Ct6hgFFFFIAooooAKKKKACmn7wp1NP3xQA6i iigAooooAKKKKACiiigBG6UUjdKUUALRRRQAUUUUAFFFFABUc5xA/wBKkqK5/wCPd/pQByr8 sfrVzR1zeD2FU34atDRRm5J9BTEbwpaSlpDCiiigAooooASmt94U6mt94UCY+iiigYUUUUAF FFFABRRRQAjdKBSN0pR0oAWiiigAooooAKKKKACiiigBq9TSPEjjDKD9RSjqadQIrNY2zDmF aifSbVuiFfoavUU7hYzDosBPDMKjbQ0/hlP4itaii4WMc6H/ANNv0pv9ht/z2H5Vt0lFwsZC 6Gv8Up/AVKmjwKRuLNWnTT1FFwsQw2cEH3Ixn1qelopDCiiigAooooAKKKKAEbpQv3RQ3SkX 7ooEOooooGFFFFABRRRQAUUUUAU799ltIc4OK5omtzWXxFtB6msMjNMRe0iLzLwHsvNdHWNo QH7w962aGMKKKKQBRRRQAU09qdTW7UAOooooAKKKKACiiigAooooAQ9KF6UHpQvSgBaKKKAC iiigAooooAKKKKAGfx0+m/x06gSCiiigYUUUUAFFFFABTW6U6mt0oAWlpKWgAooooAKKKKAC iiigBKFopFoAdRRRQAUUUUAFFFFABRRRQA3+KnU3+KnUAFFFFABRRRQAUUUUAFNfpTqa/SgT FHSlpB0paBhRRRQAUUUUAFFFFABRRRQAwffNPpo+8adQJBRRRQMKKKKACiiigAprdKdSN0oA WiiigAooooAKSlpKAFooooATtSL0paRelADqKKKACiiigAooooAKKKKAG/xU6m/xU6gAoooo AKKKKACiiigAprdKdTW6UAKOlLSDpS0AFFFFABRRRQAUUUUAFNXvTqavegB1FFFABRRRQAUU lLQAUUUUANP3hTqafvCnUCCiiigYUUUUAFFFFABSHpS0h6UAA6UtIOlLQAUUUUAFFFFABRRR QAUxfvGn0xT8xoEx9FFFAwooooAKKKKACiiigBp6inU09RTqACiiigAooooAKKKKACkPSlpD 0oARelOpF6UtABRRRQAUUUUAFFFFABTR9406mj7xoAdRRRQAUUUUAFFFFABRRRQBHJ2rn9Vb N43sK6CXgZrmLtt9xIw6Zpi6kUYJkUD1rfurAXFsuAPMA4NYloN1zGvvXVL90UAcjNC8LlXB BFR9q6y4s4bj/WLk+tZ1xoictG+B6GjcDDwaco5FOdAjFc5waROWH1pDOqsk22yD2qlriA24 bHINX7YAQJjpiluIVmiKMODTEcgR3oXk1qS6NKDmNgRTrfRpN4MhAFFguQnTHmiWSFeo6Ui6 RcnOVAxXRogRAoHApaLgZVpoyR4aY7j6VqKioAFAAp1JSuMWq96dtrIT6VYqrqJxZyfSgDmC MmrelDN4vTFUzWjo0Ye5yc8CmI6AdKWkpaQyveuI7Z2PpXKk8niui1iXZaEd24rm6ANHRhm8 z6CujrE0KP5nfHtW3QAUUUUANbpTqa3SnUAJS0lLQAUUUUAFFFFAFTU2C2b571zTHJrotW/4 8zXOsaYjW0MfPIcfjWzXP6fepaROW5Y9KbLq8zP8hAFJjOjormxq9yB1H5VOuuScZjX86AN2 isYa4P4ov1qVdahJ+ZGFAGpRVBdVtifvEfUVMt9bOARKtAFmmn71ME8TdJFP407cCwwRQA+i kpaACiiigApKWigAooooAa3SlHSkbpSigBaKKKAEpaSloAKKKY8iopJOAKAH1XvSFtZCfSql zq0cWQnzNVCfV2mjZCo5/SgCk3WtHRM/aG6dKzM5Naeij/SG9cUxG6KWiikMKKKKACiiigBK afvCnUh+8KBDqKKKBhRRRQAUUUUAFFFFADW6Uo6UN0oHSgBaKKKACiiigAooooAKKKKAGr1N Opo6mnUAFFFFABRRRQAUUUUAFNbqKdTT1FADqKKKACiiigAooooAKKKKAEbpSL90UrdKRfui gQ6iiigYUUUUAFFFFABRRRQBh60/7xVH1rKJzV/VHLXbe1Ue9MR0Gjx7LQHuTWhVXT1K2iAj BxVqkxhRRRQAlLRRQAU1u1OprdqAHUUUUAFFFFABRRRQAUUUUAIelC9KD0oXpQAtFFFABRRR QAUUUUAFFFFADP46fTf46dQJBRRRQMKKKKACiiigApG6UtNbpQAtLSUtABRRRQAUlLSUALRR RQAlIvSlpFoAdRRRQAUUUUAFFFFABRRRQA3+KnU0/eFOoAKKKKACiiigAooooAKa/wB2nU1/ u0CYo6UtIOlLQMKKKKACiiigAooooAKKKKAIy216XzB6GjALU7FMWo0OPejePenUUg1E3Cje KXFFAaibx70m8U6jFAajd4oZxinUjAEUw1EEgNG8U4CjFAaibhRvFLRSDUbvFAcGnUYFAaib xQHBpaKA1E3jFIrjFOpF6Uw1DeKTetOowKQajd4o3j1p2B6UYHpQGom9fWk3r607A9KMD0oD UTevrRuHrS4HpRgelAajC4DU7eKQqC3Sl2j0p6BqG9fWjcPWjaPSjaPSgNQ3D1o3j1o2j0o2 j0pBqG9fWjcPWjaPSjaPSgNQ3D1pHcAdaXaPSkdRt6UwdwV1I60u9fWgKMdKNo9KA1DcPWjc PWjaPSjaPSkGobh60bh60u0elG0elAaibh60bh60bR6UbR6UBqG4etIrjJp20elMVRk8Uw1H bh60bh60bR6UbR6Ug1DcPWjcPWjaPSjaPSgNQ3r60bh60bR6UbR6UBqG5fWjcPWjaPSjaPSg NRrOARTt6+tIyAkcUuwelPQNQ3D1o3D1o2L6UbR6Ug1DcPWjcPWjaPSjaPSgNQ3D1o3D1o2j 0o2j0oDUXcPWkJGOtG0elBUY6UBqIrjHWl3D1pAgxzzS7B6Uw1DcPWjcPWjaPSjaPSkGouR6 0ZHrSbR6UbR6UBqLuHrRketJtHpRtHpQGouR601WG480u0elNVRuPFMNR+4etGR60m0elG0e lINQ3D1pcj1pNi+lGwelAai5HrRketJsHpRsFAai5HrRketJsHpRsHpQGoMQMZNLketMZAcU uxfSmGo7I9aMj1pNg9KNg9KQai5HrRketJsWjaKA1FyPWjI9absFLsX0oDUXIoJ4pNg9KQoM UBqCsCKdketMWMYpdi09AVx2RRkU3YvpRsWkGo7IoyKTYKNg9KA1FzRkUmwUbBQGouRSAjca Ngpu0FjTB3H5oyKbsHpR5a0g1HZozSbBRsFAai5ozSbBSeWKA1HZozTdgo2CgNSO7fZCzDnA rlpG3MW9TXQ6qwjtGx1PFc2aYCrIyPuUkEeladjqkolWOUhlPGTWTSqxVgaQzsgQRmkcjYaq afKk9upzyOtWXjGw0xanLXA/fPjpupi/eHbmnXH+uf61GpORQM6y0ObdOc8VMelV7RAbdCRj ipigx3oFqKpGKWo1jHqaXyx6mgFcfRTfLFHlj3oDUdRmm7B6mkMYPc0BqPqlqzYsnq35Y9TW drOEtuvJNAamDV7TblLZndyelUDzR0oA6Oz1OO4fYw2t296v5rkrVys6Nx1rqFUFAc9qAMrX ZslIx9axxzVvU5C14wyMDiq0YLSKo7mkB0WkxeXagn+Lmr1QwwhYlGT0qTYPU0w1HUU3Z7mj Z7mkGorHApc0xl4pQnuaYajqKYY/c0uz3NAajqKbs9zRs9zSDUdRTdnuaNnuaA1KWsHFrx61 zzVuawpWBcEnmsRznHFMBhzQM+lbOlWsc0BLqDWglhAoxtH40WQrs5pbeaQfLGx+goNtMBzE 35V1QhVRgcUvlCjQNTlGhlXqjD8KaUcfwn8q60xA03yE9B+VPQNTk8HuKOa6prSFuqL+VRPp ls/VMfSloGpzQZgepBqRbiVejsPxrbk0aBvullNVX0Vw2FkBosO5Vj1S6Tnfke4qdNbmU/Mq tUUml3SHhN30qB7OdTgxMPwosO5pjXBt5i5+tL/bq/8API/nWOYZc/6tvypNjnop/KlZhc2G 1wY+WI59zTP7ck/55D86y/Kk/uH8qUQTHny2I+lOwXNJtck4xGtKNckzzEuPrWb9lnPSJvyp Dbzg8xsPwosFzWOtg8GI/gacuuR/xRsKxWjdThkIP0pvIPIpWC5vjWoM/dbFPGsWxPVvyrnc n0oBNFgOk/ta1/vH8qa+sW4GV3H8K50k0ZbFAGrNrMjE+WoA96oT3084IdyR6CodpPQGporO eU/LGfrRYLkHJ60nSp3tJ0JBjbj0FRFWHUUWYXFU1raIuZXb0FZIFbOiKSj9uetNCZsUUwIf 7xpdh/vGgLsfRTNh/vGjafWkA+imbD/eNGw/3jQFx9Mb7wo2n+8aY6nI5pibJqKZsPqaNh/v Ggdx9FMCn1NGw/3jSAfRTNp/vGjaf7xoAfRTNp/vGgKf7xoC45ulFNZTt60gQ4+8aYXH0U3a f7xo2n+9SC46im7D/eNG0/3qAuOHTmim7T60bD/eNMB9FM2n+9RtPrSAUHk06ogp3HBp20/3 qYJjqKbtP96gqf71ILjqKbtP96gqf71AXHUU3af7xo2n+9QFx1IeopNp/vU1lPHNMGySimBG /vUu1v71AXHUU3a396jaf71ILjqKbtP96jaf71AXHUU3af71G0/3qAHHpSL0FIwO0/NSKrYH zUwvqPopu1v71G1v71ILjqKbtb+9Rtb+9TC4+imbW/vUbW/vUguPpGOFJpu1v71RXLGOB2LY wKYXOdvJPMuHb1NRwrvlUeppGJLE96s6bH5l2vtzQB0cY2xqPQU+owrf3qXa396kFx1FN2t/ eo2t60BcdRTQrf3qNrf3qYXHUjdqTDf3qRg2OtAXJKKZtb+9Rtb+9SC4+imbW9aTa/rQFySi mbW9aNr/AN6gLj6KZtb+9RhvWgLjqB0ppDY601Q+OtMLklFNw396kw/rSC5JRTMN60Yb1oC4 6im4b1ow3rQFx9FMw/rRhvWgLi/xUtREPv607D+op2EmSUUzDetGG9aQ7j6KZh/UUYf1FAXH UU3D+tGH9aAuOpG6UgD+opGDY60wuPpaYA2OtGH9aQXHUU3DetGG9aAuPpKbhvWjD+tAXH0U zDf3qMN60BcdSCkw3rSAN2NMLj6KbhvWjDetILjqKbh/WjD+ooC4+imYf1FGG9aAuOopuH9R RhvUUBcX+KlqNg2RzzSgP6inYVx9LUeH7EUuGx1pDuOopuG9aMP60BcdRTcN60Yb1FAXHUj/ AHaT5/UUj7tvamDY8dKWkHSlpDCiiigAooooAKKKKACiiigBg+/TqQfeNOoEgpKWigYUUUUA JRS0UAJTXzin01ulAhRRS0UDCkpaKAEopaKAEopaKAEPSmp0p1IvSgQtLRRQMSilooASiloo ASilooAZzup1J/FTqAEoopaAEopaKAEpaKKAEpH+7Tqa/wB2gTFHSigdKWgYlFLRQAlFLRQA lFLRQAlNXvT6avegQtFLRQMSilooASilooASilooAYfvCnUh+8KdQISloooGJ3oopaAEopaK AEpG6U6kPSgBF6UtA6UtACUUtFACUUtFACUUtFACUxfvGpKYv3jTEx1FLRSGJRS0UAFJS0UA JRS0UANOcilpD1FOoASloooAKSlooASilooASkJ4p1IelACKeKWhelLQAlFLRQAUlLRQAUlL RQAlNB+c0+mj7xoExaKWigYlLRRQAlFLRQAlFLRQBka6/wAiL3zWJWjrMm66wOwrPUEkAdTT ETPaMlqs/UHr7VWzXVxW6m0WNwMYrHvtJeEGSL5l7j0oApWl5JavuTp6GtH+2yycpg1jlcHp R2pDHuxd2b1NA5IpmaemNw+tAHVWfFumM9KnJ4qK2wIE+lSnpTARTxS0idKdSBCZooozQAUG jIoyPWgAzWPrznZGvvWxkVia64LooPIoAyCKQ5xTqsfZWa281efWna4r2Ko4IxXR6beJLb7O jKOa53GBUkMzwNuU44xSGLdMHuZD6mnWaF7pAPWoCcksTzT4ZmilDp1FAHXLwAKWorWXzoFf 1FTUAJmjNLRQAxzgU6kbpS0CCjNLRQMSilooASilooAy9bP7lee9YTVua3/q0+tYh60xG7oi Yti3qa0qo6Rj7GMVfoYxKKWikAmaKWigApKWkoAKaT81Ppv8VAC0UtFADcD0pPLT+6v5U+ig Bu1f7ooCgdhTqKAE4owPSlooAjkRDglQfwppt4ScmNc/SpG6UtO4iFrWBhgxLj6Uz7BbYx5K 1ZpaLsLFT+zrX/nkKDp1qf8Alko+lW6KLhYhS2hj+7Go/CpQAOgpaKQxOKztVhjFqzBAD64r RqlqxxZt700Bzp61saEflkHvWOTzWxoX3ZKBGvRRS0hiUtFFABRRRQAU0n5hTqafvCgTFpaK KBhRRRQAlLRRQAUlLRQAjdKB0obpQOlAC0UUUAFFFFACUtJS0AJS0UUANU8mnU0dTTqACkpa KAEpaKKACiiigBKQnkU6mnqKAY6kpaKAEopaKACiiigBKWiigBrfdNC/dFK3SkX7ooF1HUUU UDCkpaKAEoopaAEqhq8gW129yav1i63J+9VB25oAyj1rW0OL5mkPTpWSa6HSIyloC3fmmIv0 UUUhhRRRQAlLRRQAU1j0p1NbtQDFpaSloAKSlpKAFooooAKKKKAENC9KD0oXpQAtFFJQAtFF FABRRRQAUUUUAM/jp1N/jp1AkLRRRQMKKKKACiiigBKRulLSMOKAFpaSloAKKKSgBaSiigBa KSloASkXvS0ijrQIdRRSUDFpKWkoAWiiigAooooAaT8wp1NI+YUtAgpaSloGFFFFABRRRQAU xz8tOpr/AHaBMcOlLSDpS0DCiiigAooooAKKKKACiiigBo+8adTR9406gSCiiigYUUUUAFFF FABTW6U6mt0oAdRRRQAUUUUAFFFFABRRRQAhpF6UppE6UAOooooAKKKKACiiigAooooAb/FT qb/FTqACiiigAooooAKKKKACmv8Adp1Nf7tAmKOlLSDpS0DCiiigAooooAKKKKACmr3p1NXv QA6iiigAooooAKKKKACiiigBp+8KdTT94U6gQUUUUDEpaSloAKKKKACkbpS0jdKAAdBS0i9B S0AFFFFABRRRQAUUUUAFMXqafTF+8aBD6KKKBhRRRQAUUUUAFFFFADW6inU1uop1ABRRRQAU UUUAFFFFABSHpS0h6UAIvSnUi9KWgAooooAKKKKACiiigApo++adTB980CY+iiigYUUUUAFF FFABSMcAmlqK4bZC7HsKAOZvJPMuXb3pbFPMuo1981A5yxPqa0dEj3XJb0FMRvgYAFBAIwel LRSGUrjTYJh93afUVUbREAJ8w/lWxTZDhGPtTuKxyEi7HZR0BxTQ2OafM2ZWPuajpDLv9pzD aFbAFSDWbgdQprN70uDnpSA1BrUwGNi0n9tTnHCis8RueiH8BSGN+mw5+lOzC5ek1e5c/KQo 9hUR1K5IP7yoRbTHGIm/KpF0+6bGIm59aLBcDf3P/PVqQXtwoIErc+9SrpV038GPrUg0a5K/ wg+maLBcrfbLjtK351C8ryNl2JPqavHSLkfwj86qXFu9u+x+tFguRgc10WloDaqCOCK50da6 fThi3T6U0JmbqOmMjGSAEqeo9KymGOD1rsqz7/T4JEaTG1gM8Ubgc2acgLEAdTQV5rQ0eNXu vmXOBSGbdjGYrVFPXFWKQcUtABRRRQA1ulLSN0paAFooooAKKKKACiiigDK1v7kf1rEbrzit zWyfKQY71hmmI6LSP+PJavVn6P8A8eY+taFJjCiiigAooooAKKKKACk/ipab/FQA6iiigAoo ooAKKKKACiiigBrdKWkbpS0ALRRRQAUUUUAFFFFABVHVv+PNqvVR1YZs2x60Ac8eua19C6SV kHitfQuklMRsUUUUhhRRRQAUUUUAFNP3hTqafvCgQ6iiigYUUUUAFFFFABRRRQAh6UChulA6 UALRRRQAUUUUAFFFFABRRRQA0dTTqavU06gAooooAKKKKACiiigApp6inU09RQA6iiigAooo oAKKKKACiiigBG6UifdFK3SkX7ooEOooooGFFFFABRRRQAhOBXM38nm3bk9M4roLuTyrd29q 5huTnr9aYBGpkkVB3OK6qBPLhVPQVg6VEXu1OOF5roqGAUUUUgCiiigAooooAKa3anU09qAH UUUUAFFFFABRRRQAUUUUAIelA6UGhelAC0UUUAFFFFABRRRQAUUUUAM/jp9M/jp9AkFFFFAw ooooAKKKKACmt0paRulAC9qWkpaACiiigAooooAKKKKAEoWihelAC0UUUAFFFFABRRRQAUUU UANP3qdTT94U6gAooooAKKKKACiiigApr9KdTX6UCYo6UtIOlLQMKKKKACiiigAooooAKKKK AGD75p9MH3jT6BIKKKKBhRRRQAUUUUAFNbpTqa3SgGOopKWgAooooAKKKKACiiigBD0pE+7S 9qRelADqKKKACiiigAooooAKKKKAG/x06m/x06gQUUUUDCiiigAooooAKY/3afTH+7QhMcOl LSDpS0DCiiigAooooAKKKKACmr3p1NXvQA6iiigAooooAKKKKACiiigBp+8KdTT94U6gAooo oASloooAKKKKACkPSlpG6UAA6UtIvQUtABRRRQAUUUUAFFFFABTF+8afTFHzGgQ+iiigYUUU UAFFFFABRRRQA1uop1NPUU6gAooooAKKKKACiiigApD0paQ9KAAdKWkXpS0AFFFFABRRRQAU UUUAFMX75p9MH3jQJj6SlooGFFFFABRRRQAVS1WTZZt78VdrJ1xyI0UdCaAMQ1paTNDAHeRw DWYelMzxQB1sF5DcHEbgn0qxXHRStG4ZSQfauqtJfNt1f1FAE9Rzf6ls+lSVFcECByemKAOT k++fTNPtoRNMqeppjnLE+9W9LAN4uaYjQ/sWI4wxFW4rCCJeEBPvVodKD0ouFhiIgXhR+VL5 aE52j8qVelOpAJgelFLRQMKSlooASsLXFAnU9yK23ZUUsxAArmdRuftFyWByo4FAFdQCRXUW QxCg9q5ZTgiups23RKevFMRZqC8GbaTntU9Vr9ttpIfakM5cjmtLRf8Aj5PPaszOTWroakzM 3GMUxG7RRRSGFFFFADW6U6mt0p1AgooooGFFFFABRRRQBnayAbYEnoawGxXQaxj7Lz61z5pg buif8ex+tadZWhH9y4x3rVpAFFFFABRRRQAUUUUAFJ/FS03+KgB1FFFABRRRQAUUUUAFFFFA DW6UopG6UtAC0UUUAFFFFABRRRQAVT1T/jyerlUtW/482oA50+9a2hD/AFlZBrY0If6w0xGx RRRSGFFFFABRRRQAlNP3hTqafvigTH0UUUDCiiigAooooAKKKKAEPSgdKG6UDpQAtFFFABRR RQAUUUUAFFFFADR1NOpq9TTqACiiigAooooAKKKKACmnqKdTT1FADqKKKACiiigAooooAKKK KAEPQ0i/dFDfdNCfdFAuo6iiigYUUUUAFFFITgZoAytbmARYweTyaxe/FWb+bzrl2HQHFV0X e4UdTTEbeiw7Y2kPU1qVWsovJhVPQVZoYIKKKKQwooooAKKKKACmt2p1NbtQA6iiigAooooA KKKKACiiigBDQvSg0L0oAWiiigAooooAKKKKACiiigBn8dPpn8dPoEgooooGFFFFABRRRQAU 1ulOprdKAFpaSloAKKKKACiiigAooooAKRelLSLQAtFFFABRRRQAUUUUAFFFFADT94U6mn71 OoAKKKKACiiigAooooAKY/3afTX+7QhMUdKWkHSloGFFFFABRRRQAUUUUAFFFFADB940+mA4 c07NAkLRSZozQMWikzRmgBaKTNGaAFprdKWmuQBzQJj6KQHiigYtFJRQAtFJS0AFFFJQAHpS L0pT0pE6UCHUUlFAxaKSloAKKKKACikooAT+KnU3I3UtAhaKSloGFFFFABRRRQAU1/u06mv9 2gBR0paQdKWgAooooAKKKKACiiigApq96WmqetAh9FFFAwoopKAFopKKAFooooAafvCnU0kb hTqACiiigBKWkpaACiiigApG6UtIelAAOlLSDpS0AFFFFABRRRQAUUUUAFMXqafTF+8aBD6K KKBhRRRQAUUUUAFFJS0ANPUU6mnqKdQAUUUUAFFFFABRRRQAUh6UtIelAAOlLSDpS0AFFFFA BRRRQAUUUUAFMH3jT6aPvGgQ6iiigYUUUUAFFFFABWHrkmZEQdq2657WH3XePQUAZ55qWe1e JFcr8rDrUajLAV0xt1msxG/pTEct0NbWjXiBfJc4PYmsu5t2gmaNh06GolyGBU4IpDudlVXU WxZyc44qrYamrIEnIVh0PrSaxcIbbarAkmgDDPWtDRh/pWfas4GtjQ48l37dKYjaFB6UCg9K QxF6U6mr0p1ABRRRQAUlLSUAV76IzWzovXFcq6lGKsOQa7I8iuV1BQt3IB60AVga3dHuQ6+W xAI6CsKpIpGicMpIIoA7CqOrHFk1FjfpcIFJw47Go9afFpgdzQBgGtjQhzIax62tCUiNz2Jp iNeiiikMKKKKAGt0paRqWgBaKKKACiiigAooooAztZP+ij61gGt/Wv8Aj1/GufpiNvQx8jnP etasrQv9Q31rVpDCiiigAooooAKKKKACm/xU6m/xUAOooooAKKKKACiikoAWiiigBrdKdTW6 U6gAooooAKKKKACiiigAqpqf/Hm9W6qakM2Un0oA5sjvWtoXBkrJrV0P/WP9KYG1RRRSAKKK KACiiigApp+8KdTT94UAOooooAKKKKACiiigAooooARulA6UN0oFAC0UUUAFFFFABRRRQAUU UUANHU06kHeloAKKKKACiiigAooooAKaeop1NPUUAOooooAKKKKACiiigAooooARulIv3RSn pQvQUCFooooGFFFFABVXUJvJtWOeTwKtVh61PvlEYP3etAGWxLHmr2lW5luQ38Kc1R710Gk2 /lW+89X5piLy9TTqaPvGnUhoKKKKACiiigAooooAKa3anU1u1ADqKKKACiiigAooooAKKKKA EPShelB6UL0oAWiiigAooooAKKKKACiiigBn8dPpv8dOoEgooooGFFFFABRRRQAU1ulOprdK AHUUUUAFFFFABRRRQAUUUUAJSLS0i0AOooooAKKKKACiiigAooooAafvU6mn71OoAKKKKACi iigAooooAKY/3afTX+7QJijpS0g6UtAwooooAKKKKACiiigAooooAjK7no8seppR940+ncmy I/L9zS7Pen0UXHZDPLHqaPLHqafRSuFkM8v3NJ5fuakop3CyGBPc0jJx1qSmt0ouFkNEfuaX Z7mn0UXCyGbPc0bPc0+ilcLDNnuaNnuafRRcLIZs9zRs/wBo0+ii4WQwpx1NIqcdcU89KReV p3CyE2f7Ro2e5p9FK4WRH5fuaNh/vGn0tO4WQzYf7xpNh/vGn0UXCw3YfU0bD/eNPopXCxEU y3Wl8s/3jTv4qdTuKyIwh/vGjYf7xp9FFx2Q3Yf7xo2H+9TqKAsN2H+8aNrf3qdRQFhuw/3q a6nb1qSkfpQDWgxUbA+anbD/AHqcOlFFwshmw/3qNh/vU+ii4WGbW9aXa396nUUBYZsP96gK 2fvVJRRcLDNp9aaqHJ5qSkXvRcLDdjf3qNrf3qkopXCxHtb+9Rtb+9UlFO4WI9rf3qNrf3qf S0XCxHtb1pdretPooCxC6sSPWl2v/ep5+8KdRcViPa396ja396pKKVx2I9r+tG1vWn0tFwsM 2t/eo2t60+igLDNretIytjk1JSHpTCxEivjg07D+op46UUXEkM2t60bX9akopDsR7W9aNrf3 qkophYZhvWjD+op9FILDMN60wK244qamL1NO4mgw3rRhvWn0Uh2GYb1oAb1FPooCwzD+oow3 rT6KAsR4b1pfm9qdRQFiNw3FLh/WnN1FLTuKwzD+opfn9qfRSuOxHh/Wl+b2p9FFwsR4f1FL hvWn0UXCwz5vaghqdQelAWI134p3z+1OHSincLDfn9qQh/UU+ikFhvz+1HzU6igLDfn9qPm9 qdRQFho3e1NG7eakpB9407iaEO/tik+f2p9FIdhnz+1L89OooCwzL+lHz+gqSigLEZ346Cuc 1Ik3b54NdN2rmNSO68kye+KYFeLmRfrXUx7/ACxgdq5i2GZ0HvXWJwg+lAWKN9ZG6UdAwrBn geCQrIpBrrar3dol1Htbr2NF7haxymeeKUsSOTWpcaM6JmNtx71mSxmNijdRSsFxowe9dBo6 MltnHU1z4HPFdTpwC2afSmgJgXz0oJfHIqC4v4YCVLfN6VWXWoSPmVgaLhYvIX6Dmnbn/u1R /ti3VeNxP0qFtcXb8sZzRcSXmamX9BTHnCD5iB9TWHNq88oIUhB7VSeV3PzsT9aVx28zplvE d9iupPtU+5/SuWtPMNwnl5zmurTO0Z64phYjdnCniuYuWMk7sepNdVKcRsT6VychzIx7ZoCw 0Lzx1oIxVzSkV7td3I960LzS1mYmL5T6dqAuYSuUbcpINST3UswAkckCpp9Onh6pkeoqrIjo cMpH1osFxFxurodJVltsjkGueVecmun0xdtklAMsZf0pdzelOooCwzL+lLlvSn0UBYicnHSl DNjpTm6UtFxWGFn9KNz+lPooHYbub+7Rub0p1FAWGbm/u0bm9KfRQFjL1hmMABGOaxDW5rZx Ao96wzQBs6MSIDgZ5rSDN/dqnoygWmfU1oUBYZub0qCe9jt/vkZ9Kr6lqPkDZEQXP6VhSSNK 5ZiSxoCxrS63ziNOPU0w61KeiKKzo7eWU4WNifpU5065H/LI/hRYLloa3ID80YxT/wC2zu/1 fy/WqJ027xnyjTHtJ0HzRMPwosFzVj1qM/fQipF1SB2zvx9awCMdRRQG51Ed2kn3GU/jUodj /DXJKWU5BIq7BqlxDjLbx6GgLHQbm/u0bm7rVG31eGTAk+Q9z2q+jrIuVYEe1K4WE3N/do3t /dNPophYbub0o3H+7TqKAI3Y7emKA7Y+7T26UtArO4zc392jc392n0UDsMLN/dNLub+7TqKA sN3H+7Rub+7TqKAG7m/u1XvctauNvarVR3IzbyD2oCxyjdcVoaQ7LcEKuQRzVA8E1d0dv9MA 9qAN4O3900u5v7tOooCzGb2/u0u4+hp1FADd5/umjcfSnUUAN3H+7THYhhxU1NP3hQJpjd5/ u0u8/wB006igdmN3H+7RuP8Adp1FADdx/umjef7pp1FADdx/umjcf7pp9FILEbMSvAoVjjkU 89KKYWG7j6Ubj/dp9FILDNx/umjef7pp9FAWI95/uml3H+6afRTCzGbj/dNG4/3TT6SkBEHY E8U8OT/DSgcmlpisxu8/3TRvP900+igdmRhyexpd5/umnUtAWI95/uml3H0NPooCzGbj/dNN dyMcVJSHqKAsxu//AGTRvP8AdNPooCzG7z/dNG8+hp9FAWYzef7po3/7Jp9FADN/saN/safR SAjZ/lOAaRJDj7pqRuhpF6CmKzuJvP8AdNG/2NOooHqN3+xo8z2NOooDUhnnEUTMQeBXMyv5 sjOx5JzWxrU+2MRDq3WsOgCa2iM0yqK6aM7UVcdBWZolvw0rDnoK16AIt5DHg07zPY04AbjS 0CSY3f8A7Jo3+xp1FA9Rpf2NG/2NPpKQajQ+e1G/2NOophqN3+xprP04NSUjY4oBpib/AGNG /wBjTqKA1G7/AGNHmexp1FAajd/tR5nsadRQGo3zPY0b/Y06igNRpfjoaasnHINSUgAx0oFZ ieYPQ0eYPQ06igeo3ePQ0eYPQ06igNRu8eho3j0NOopBqN3j0NLvHvS0UBqRl8PTt/saMDfn FOpiSY3ePQ0b/Y06igeo3zB6GjzB6GnUUBqN3j0NHmD0NOooDUaJAexpGfI6U/FIw4oDUQSD Hejf7U7FFAajPMHoaXzPY06igNRvmexoMg9DTqKA1G+Z7Gjf7GnUUBqN38dDTVk9RUlIooFZ ieYPQ0eYPQ06igeo3ePejzBTqMUBqN3j3o8we9OooDUb5go3j3p1FINSMuAwp28e9BALCnYp i1G7xR5gp2BRQPUbvHvRvHvTqKQajd496N496dRQGo3eKR3GOlPwKa4+Wmgdxw6UtIOlLSGF FFFABRRRQAUUUUAFFFFADB980+mD75p9AkFFFFAwooooAKKKKACmt0p1NbpQA6iiigAooooA KSlpKAFooooAQ9KRPu0p6UifdFAuo6iiigYUUUUAFFFFABRRRQA3+KnU3+OnUAFFFFABRRRQ AUUUUAFNf7tOpj/doQmOHSlpB0paBhRRRQAUUUUAFFFFABTV6mnU1O9Ah1FFFAwooooAKKKK ACiiigBp+8KdTT94U6gAooooAKKSloAKKKKACkPSlpD0oAB0paQdKWgAooooAKKKKACiiigB KYn3mp9NXqaYh9FFFIYUUUUAFFFFABRRRQA1uop1NPUU6gAooooAKKKKACiiigApD0paQ9KA BelLSDpS0AFFFFABRRRQAUUUUAJTR9806mr980CY+iiigYUUUUAFFFFADWYKpLEAe9ctesDd SEEEZ7Vr65IVtgBnk1zxNAFm0/4+Y/rXVr90Vydiw+0xnHeusXoKAFooooAa5whJ9K5K5ffM 7eprodVlEdowzgniuaNAD4l3yKvqa6OcNFY/JnIHasXS4DNcj0Xk10u0FcHpTA4+SRncljk0 3vXRT6RBIxZflJqE6IoOfM49MUWFcw+KOvSuii0i3GCwJNWo7KCMfLEv5UWQXOWEMjdEbH0q 5baXNNhiu1feujCqBgAUuMUaAVbSxitR8oy3qatUtJSGV79tlpIQccVy5NbWt3JRBEP4utYW frQBp6MjNdBgOAOa3x96snQkHlu/4Vqj79MQ7Ga5/WiDdgDsK6CuY1J915J7HFIZXUciuqtQ BboB6VzFsN1xGvvXVoMKKbEOooopDCiiigBrdqdTW6CnUCCikpaBhRRRQAUUUUAZGukbYxWL Wrrh/eoPQVldxTEdFpC7bNfepNQuRbW5bPzHgUaaMWiZ4rM1ucPKsYP3etDBGYzl2LE5JNa2 l6eki+bKv0FULGHz7lVxxnJrqEUIoUDAFAChQowAAKKWikMKQilpKAI3t4n+9Gp/Cqkul2zn AXb7itCm/wAVO4jDudIlQ5iw4/Ws6SN422upU+4rrqZJDHKMOgP1FFwORqWC5lgYFHI9q1br RwFLQHn0NZMkTxMVdSposBu2eqRzALIdr/oa0AQRxXHjI6Vo6fqLQHZKSyfypDOgoqOGZJk3 IcipKAGt0paRulLQAtFFFABRRRQAUUUUAFMmGYmHtT6ZIcRt9KAOUcYY/WrWlZN6v0qrK2Xb 61a0nIvFxxTEdJRSDpS0hhRRRQAUUUUAFNP3hTqafvCgB1FFFABRRRQAUUUUAFFFFACN0oHS hulA6UALRRRQAUUUUAFFFFABRRRQA1epp1NHU06gAooooAKKKKACiiigApp6inU09RQA6iii gAooooAKKKKACiiigBG6UL0FI33aF+6KBDqKKKBhTWYKpY9BTqpapP5NqwB5bgUAYl7MZ7hn zx0FQRpvcKOpOKaTzWlo8AlnLsOE6UxGzbRCGFUAxgVNSUtIY0dTTqaPvGnUAFFFFABRRRQA UUUUAFNbqKdSHtQAtFFFABRRRQAUUUUAFFFFACHpQOlB6UL0oAWiiigAooooAKKKKACiiigB n8dPpn8dPoEgooooGFFFFABRRRQAU1ulOprdKAFpaKKACiiigAooooAKKKKAEoWikWgB1FFF ABRRRQAUUUUAFFFFADT96nU0/ep1ABRRRQAUUUUAFFFFABTX+7TqZJ92hCY4dKWkHSloGFFF FABRRRQAUUUUAFFFFADAfnNPpo+8adQJBRRRQMKKKKACiiigAprdKdTW6UAOooooAKKKKACk paSgBaKKKAEPSkT7tKelIv3aAHUUUUAIaWiigAooooAKKKKAG/x06m/x06gBKWiigAooooAK KKKACmv0p1NfpQJijpS0g6UtAwooooAKKKKACiiigApq96dTU70CHUUUUDCiiigAooooAKKK KAGn7wp1NP3hTqBBRRRQMSlpKWgAooooAKRulLSN0oAF6UtNXoKdQAUUUUAFFFFABRRRQAlM Q5Y0+mJ95qYmSUUUUhhRRRQAUUUUAFFFFADT1FOprfeFOoAKKKKACiiigAooooAKQ9KWkPSg AXpS0g6UtABRRRQAUUUUAFFFFABTFHzGnUg+8aBDqKKKBhRRRQAUUUUAU9StjcWxC/eHIrl3 UhsHqK7GU4jY+1clNzIx96AC1kEU6ORkA11kMiyxqynINccOtael33kOEflCfyoA6KkoBDAE dKD0oAxNdkzIiZ96yKt6m/mXj+3FVAMnFAG5oUe2Jmx1Na9VdPjEdqgAxxVqhgJQelFB6UAI n3adTU+7TqACiiigAoopD0oAwddI89PXFZRNXdSk8y7c9QOKpEZoA1dFuAkpiP8AF0rcH3zX Ixs0bgqcEV0enXX2hOfvDrTEXHO1CfauSnbfM7Hua6e9kEdq7H0rljyc0hlnTkLXkePXNdOO lYehxBpGkP8ADwK3KbAWiiikAUUUUAMfpTqRulOoEFFFFAwooooAKKKSgDA1ls3WPQVng9Bi rmpndePVWNSZFA9aYjpbPi1X6Vz16267kPvXSQDEIHtXOXsbJdSA+tALYs6Jt+1HPXHFdBXK WkpguFcHvzXUowdAwOQaQx1FJS0AFJS0UAFN/ip1N/joAdRRRQAVDcW0dwhV1B96mooA5y90 6S3O5RuT1qjyK7BgGGCMg1i6jpm0+ZAuR3FPcWxRtbt7aQFSdvcV0dtcJcxh0P1rlDwasWV3 JayjBO0nkUhnTt0paijmSaMMjAj2qWgBaKKKAEpaKKACiiigAqOYZhfHpUlRXH+of6UAcs4+ c1c0dQbsZ7CqT9TV7RgDd59BTA6AUtJS0gCiiigAooooAKafvCnU0/eFAmOooooGFFFFABRR RQAUUUUAIelAobpQOlAC0UUUAFFFFABRRRQAUUUUANHU06mjqadQAUUUUAFFFFABRRRQAU09 RTqafvCgB1FFFABRRRQAUUUUAFFFFACN0pF+6KVuhpF+6KBDqKKKBiGue1W4864Kg/KnFbd5 MIbd2PpXKuSWzQAAEniul02DyLVQRhjyaxdMt/Oulz0HJrpQMDFMQUtFFIY0feNOpo+8adQA UUUUAFFFFABRRRQAU1u1OprdRQA6iiigApKWigAooooAKKKKAEPSgdKD0oXpQAtFFFABRRRQ AUUUUAFFFFADP46fTP46dQJC0UUUDCiiigAooooAKa3SnU1ulADqKKKACiiigAooooAKKKKA EpFpaRaAHUUUUAFFFFABRRRQAUUUUAN/ip1NP3hTqACiiigAooooAKKKKACmv92nUx/u0ITH DpS0g6UtAwooooAKKKKACiiigAooooAZ/HT6Z/HT6BIKKSloGFFJS0AFFFFABTW6U6mtQDFp aSloAKKKKACiikoAWiikoADSJ92lPSkXpQIdRSUtAwopKKAFooooAKKSloAb/HTqZ/HTqBC0 UlLQMKKKKACikooAWmv0p1Mk+7QhMcOlLSDpRQMWiikoAWikooAWiikoAWmr3paanegQ+iko oGLRSUUALRSUUALRSUUAIfvCnUw53CnUCFopKKBi0UnNFAC0UUlAC0jdKKRulACr0FLTV6Cl oAWikooAWikooAWikpaAEpqfeNOpifeamIkopKKQxaKKKACikooAWikooARuop1MbO4cU6gQ tFJRQMWiiigAopKKAFpD0paRulAAvSlpq/dFLQAtFJRQAtFJS0AFFFJQAU1eGNOpqn5zTEx9 FJRSGLRSUZoAWikzRmgCK5OLdz7Vyb/eNdVfHFrJ9K5VqYDRSirWnxLNMUYZBFF3YyWzdCV7 GiwrlvTdS8rEUx+XsfStf7RGyFlcHj1rkulODsOhIpDJLl98zt6mkgXdKo96iPBq1pyb7uPH HPehAdPGMRge1PpBwKM0AFB6UZpCeDQAL92nUxPu06gELRSUtABUF5KIbd3PYVNWTrk2I1jB PJ5oAxWYsST3p9vbPcEiNckVH1rc0SDZCZD/ABUxGKyshKsMEU+Cd7eTehwa2dTsBKDLEvz9 wO9YUilSQQQaANG/1BLi1VRwx6iswdaaRSg4IpDOk0eMJaggcmr9VdOlSS2Xy+gGKtUALRRR QAUUlFADX6U6myHinCgXUWiikoGLRRSUALSHpRTZDhGPtQBzF6d1zIfektBm5Qe9NlbMjfWp LB1S4Dt0FMR0aMqRkscCsPVLiGWT91ye5qK9vmnYqhIT09aZaWcly3yg47mgFsQAmtnR7vI8 lzz2qzDpdukYDLuPrU0dlBFL5iJhqNALNFJRSGLRSUUALTP46dmsbUtReObZCcEdTQBtUVzt tq88bjzTvXvW3BdRTrlGBPpQBPRSBgelGaAFpCMjmijNAGJqmniPM0Q47isroa69gGUq3INc 5qdp9nmyoOw0xDtOu/Ik2MfkNdCrBlBByK4/vW5o11ujMTHkdKQzWopM0UALRSZooAWikzRQ AtQXn/Hs/wBKmzVXUn22b/SgDmm5JrR0RM3DN6Cs0kmtjQuknrTEbFLSZopDFooooAKKSigA pp+8KdTT94UCY+ikooGLRRSUALRSUtABRSUUAI3SlHSkY8Uo6UALRRRQAUUUUAFFJS0AFFFF ADR1NOpqnk06gAopKKAFopKKAFooooAKafvCnU1uooEOoopKBi0UlLQAUUUUAFFFFADW6Ghf uihvumhfuigXUdSGikY7VJNAzI1ubIWMdB1rH+lWL2YzXLtnjPFQxKZJVUDOTimI3NFg2QeY Ry1adRwqEiVQMYFSUhhRSUtADR1NOpo+8adQAUUUUAFFFFABRSUUALTW7UtIx5FADqKKKACi ikoAWiiigAooooAQ9KF6UHpSL92gB1FFJQAtFFFABRRRQAUUUUAM/jp9Mz89OoEhaKKKBhRR RQAUUUUAFNbpS0jdKAFpaQdKWgAooooAKKKKACiiigBKRe9LSLQA6iiigAoopKAFooooAKKK KAG/xU6mn7wp1ABRRRQAUUUUAFFFFABTH+7T6ZJ92gTHDpS0g6UtAwooooAKKKKACiiigAoo ooAaOtOqNiQ3AzS7m/u0xXHUU3c392jcf7tILjqKbuP92jcf7tAXHUU3cfSjcf7tAXH0hpu4 /wB2hmOOhoC46imqxI6Ubj/doC46im7j/do3H+7QFx9FN3H0pNx9KAuPopu4/wB2jcfSgLin pSL0o3HHSmqxx0phckopu4/3TRuP900guOophc/3TS7j6GiwXHUUzcf7po3H+6aAuPopu72N G72NAXD+KnVEzkN0p2//AGTTsF0Popgf/ZNG/wBjSsFx9FM3+xo3+xoC4+imb/Y0u72NAXHU 1ulG72NNZuOlMLj+1LUYfjoaXf7GlYLofRTd3saTf7GgLj6Kbv8AY0bvY0BcdRTN/saN/saA uPpq96N49DTQ+CeDTC6JKKbvHoaTePQ0guPopm8eho3j0NFguOpaYXHoaN496LBdD6KZvHoa XePeiwXA/eFOqNmwaXzB6GnYLofRTN4o3j3pWC4+imbx70u8UWC46im7xRuFAXHUh6Um8UhY YoC44dKKaJBijeKYXQ+im7xRvFILjqKbvFG4UBcdRTd4o3igLjqYvU0pYCmK43GmDZLRTd4o 3ikFx1FN3ijeKAuOopu8UbxQFxaKbvWl3rQF0B6inVGzgEU7eKdguh1FN3ijeKQXHUU3eKN4 oC46imbxS7xRYLjqQ9KTeKQuMUBccOlFMWQHg9aXevrRYE0Popu8Ubx60BcdRTdwo3Cgdx1F N3D1o3igVx1NH3jRuHrTQw3GgLklJSbx60m9fWgLj6Sm719aXePWgLjqKbvX1o3r60Bcgvzi 0kPtXLtg10uouv2OQZ7VzRpgX9GGbn8K6BkV12sARXPaQ22549K6AOp70C0uZ9zpEUgJiG1v 0rLudMmtxuYZUdxXSb19aparKos2APJ4oGc5jmrmlcXqVSPWr2klRdAmkgOlpaYHU96XevrQ FxaD0podfWlLDHWgLir0pajWRSOtO3r60BcdRTd6+tG4etA7jq5vV5TJdlc8LXQPIqoTnoK5 a4k8yd3Pc0xEagswFdTZRCK2RfauZt18yVV9TXVRlVjVc9BQA+s3UNPSfc4+VgOvrWjuX1qr fTCO3cj0oQM5hkwSDT4IWmkCIMk01uTWpoq/vmY9AOtAGrY2/wBmgCd+9WabvX1FG5fWkA6i k3D1o3D1oGLRSbh60bh60AI1LTWIx1pdw9aBDqKbuHrRuHrQMdRTdw9aXcPWgAqO5O23c+1P 3D1qrqLgWcmCM4oA5xuppm7HANObgVGDk02BZsbf7RcKnbvXTxRrEgVRgCsvQ41VWkPU9DWt uHrQIdRTdw9aNw9aQx1FN3D1pdw9aAFpKNw9aTcPWgBSMjFcxqMDxXLbuhOQa6fcPWq9zDFO NsoBFNCbOUI96VJXjOUYg+1XtQ082x3odyH9KoY55pNDRch1O5h43bh71di1shf3seT6isbH NHNILm+NbhI5RhTG1uP+GNiaw6MUwL51S4M+8HC/3a2CFv7LkYyKxbC08+YbvuDrXRxqkaBV wAKdrCucpNE0UhRhgg0+2l8mdXHY1p61b9J1x6GsegDrYZFljDqcg1JWVos+6Jo2P3elam4e tIYUtN3D1pcj1oAWikyPWjI9aAFrP1hsWhHqcVfyPWsnXJAVRB1zmgDG71uaIgEDN6msMda6 PTFVLRcHrzTEXKWkyPWjI9aQxaKTI9aMj1oAWikyPWjI9aAFppHzClzTSQGFAmPopMj1oyKB i0UmRRkUALRSZFGR60ALSUZoyKAEbpSikY8UoIxQAtFJkUZFAC0UmRRketABS0mRRmgBaKSi gBB1NOpoIyaWgBaKTIoyKAClpM0ZoAWikzRmgBaaeopc0hIyKAHUUmaMigBaKSjNAC0UmaKA FopKKAEboaFHyihuhoUgigXUWquozCG1Y9zwKtZrE1ubdIsYPC8mgZmHvmtDR7fzJ/MI+Vf5 1mjryK6LSYvKtBkYJ5piL1LSUUhi0UmaKAEH3jTqaCMmloEhaKSigYtFJRQAUUZpaAEpGHSl pGIyKBMWlpKKBi0lFFABS0UUAFFJS0AIelC9KKRTxQAtFFLQAUUUUAFFFFABSUtFADMfPT6b kbqWgSFooooGFFFFABRRRQAlIwyKWkbpQAuKWkpaAEpaKKACkpaKACiiigBKRRS0i0AOoooo AKSlpKAFooooATFFLRQA3HzUtIfvU6gBKWkpaACiiigAooooASmyD5afTH+7QJjh0paQdKWg YUUUUAFFFFABRRRQAUUUUANH3qdTB940+gSCiiigYUUUUAFFFFABSGlprdKAHUUUUAFFFFAB RRRQAUUUUAJ2pF6Up6Ui9KAHUUUUAJS0UUAFFFFABRRRQA3HzU6m5+anUCEpaKKBhRRRQAUU UUAFNfpTqa/SgTFA4paQUtAwooooAKKKKACkpaKAEpB3p1NXvQA6iiigApKWigBMUYpaKAEo paKAGkAkZpcCkP3hTqBCUUtFAxKMUUtACYowKWigBMUEcUtIelACKAB0pcUDpS0AJijFLRQA lFLRQAlGKWigBKaoGTTqanU0CHYFFLRQMTFGKWigBMUYpaKAEwKMUUtADGAOBTsD0pD1FOoE JgelGBS0UDExRgelLRQAmBRgelFLQAmBQQMUtIelADVUY6U7A9KF6UtAhMD0owKWigYmBRge lLRQAmBRgUtFACYFNCjcafTR1NAhdo9KNo9KWkoGGB6UYHpS0UAJtHpRgelLRQBS1TAs37cV zJPNdJq4zaHFc0aALWnTLFcqX6HiunQKyggDBrj4/vjnvXU29xD5ar5i5x0zRcLFjaPQVj65 IoVUB59K1y67cgg1zOqT+ddH0HFFwsUzzV/Siv2pdxxVDmprY4mXrnPahAdaFXHSjaPSki+4 M+lDuqKSxwBQAu1fQUFRjpVB9WgRsZJ+lOOq220fP1ouFi2qLjpTto9KoDVrYcFj+VTRX9vJ 0cD60XBIs7R6CjaPSgOpHBpc0BYiuFUQOcDpXKPjcfrXV3QzbuB6VybnDGmIsadzdpjnmunC jHSuUtZRFOjnsa6qGQSRhh0NIdh20elZWtNtiCjgE1r1ha4+ZFX0poTRlZ5rd0SIeSzHuawh 1rpNJXbZr70AXNq+lG0elOopBYbtHpRtHpTqKB2G7R6UbR6U6igViNlGOlOCDHShjgCnUBYb tX0o2j0p1FAWG7R6UbB6U6igLDdi+lUNXCraHjkmtGsfXXwI0/GmFkYr9KatObpxTR0pDOi0 eNfsu71q/sX0rK0KUbXjJ5HNbFO4rIbsX0o2L6U6ikFhuxfSjYvpTqKAsN2r6UmxfSn0lAWE 2D0prIC1PJx1poYM/BBouFkU9ThDWb7RyK5uuvnQSQsp6EVyUqFJGU8YNMCxYQxy3ASToa1j otuTkMw9qw4HMcquDjBrq4XEkSsO4ouFjLOhJniU4+lSwaPDG25yX9jWnRRcLESQRxjCqAKf sX0paKQWRXvIFlgZcdRXMOu1ip6g11sn3a5vUozFdNxweeKfQOo7Sn23YB6NxXRbBXK2rlLh Gz0NdWhyoNAWE2L6UuxfSlopBZCbF9KNg9KdRQFhmxfSsHWGH2nYOwroCcAmuWvpDJdyMfXF MLECjLDFdTbRBYEBGOK56yQyXcYwOua6gcAUBYaI19KNi+lOopBZDdi+lGxadRQFkJsX0pNi +lOooCyE2CmMgJFS00/eFO4NITYKXYKdRSCw3YKNi+lOooCw3YvpSbF9KfRQFhuwUnlin0lA WGsgxQEGKVulL2p3Cw3YKXYKdRSCw3YKTYKfRQFhmwUuwU6igLDNgpdop1FAWIwgLE0vlrSj qadTuFkM2CgoDT6KQWGBAKNgp1LRcLDNgo2Cn0UXCw3YKayDIxUlIeoouFkN8se9Hlin0U7h ZDNgo2Cn0UrhYZ5Yo2D3p9FFwsM2CjYKfRRcLDGQY701YwB1NSN0NIv3RTuFlcY6qqFiTxXM 3L+ZMzeprf1OYRWjercVzbNk0BZEkEZllRR3NdPHEFQKOwrG0SLdOzkcAVvUXCwzYKNgp9FK 4WGbBS7B6mlpaLhZEYTLGl2D1NKOpp1O4WQzyx6mjYPen0UrhZDNg96Ng9TT6KLhYZsFGwep p9FFwshmwe9I0Y45qSmt1FO4NITyx6mjYPU0+ilcLIZsHqaTyxnqakpKLhZDdg9TRsHqafRR cLDNg9TRs9zT6KLhYZs9zSBOOtPoXpTuFkN8v3NHl+5p9FK4WQzZ7mjZ7mn0UXCwzZ7mjZ7m n0UBYZs9zRs9zT6KLhYiMeX607Z7ml/ip1O4kkM2cdTRs9zT6KQ7DNnuaNnuafRRcLDNnuaN n+0afRRcLDAmO5pGTjrUlNbpTuFkIE46mjYPU06lpXCyGbPc0uz3NOooCwzZ7mjZ7mn0UBYZ s9zRs9zT6KLhYZs9zSKnvUlNXvTuFhNnuaNnuafRSCwzZ7mgJ7mn0UXCwzZ7ml2e5p1FAWGb Pc0u33NOooCxGUyw5NLs9zSn71Op3CyGbPc0u33NOopBYbt9zRs9zTqKAsM2e5o2e5p9FAWG 7fc01146mpKa/wB2mgaFHSlpB0paQwooooAKKKKACiiigAooooAaPvGnU0feNOoEgooooGFF FFABRRRQAU1ulOprUAOooooAKKKKACiiigAooooAQ9KRelKelInSgB1FFFABRRRQAUUUUAFF FFADf4qdTf4qdQAUUUUAFFFFABRRRQAU1+lOprdKAFHSlpB0paACiiigAooooAKKKKAEpF70 6mr3oEOooooGFFFFABRRRQAUUUUANP3qdTT94U6gQUUUUDCiiigAooooAKRulLSHpQADpS0g 6UtABRRRQAUUUUAFFFFACU1PvGnU1OppiH0UUUhhRRRQAUUUUAFFFFADT1FOprfeFOoAKKKK ACiiigAooooAKQ9KWkPSgBF+6KdSDpS0AFFFJQAtFFFABRRRQAU0feNOpo+8aAHUUUUAFFFF ABRRRQBR1ZZGtGEYJPtXNmGQfwN+VdjSbR6CgDjdpHbmjJFdVPZwSkbo1z9Kgk0e2YfLuU+x p2QrnPrNIvR2A+tRsWLZP51tyaH/AM85fzFV30a5HTafxosO5lnOeKlt5PKcMR0qeXT54hl0 OKqsCKQbm9FrUBUBtwNZ1/qD3LEKSE9PWs/PGCaCcdaQxc80EkkU3vmnc0AKTRn3pOaX+dAi VbmZBgSMB7GrEWqXMa4D5HvVL8aQ9aBmr/bTtGVeMHI7VmMQzEimnp0pMdKYh1b+k3Ua2213 AI9TXP4x70A8c0AdNcarDDwvzH2rEvbo3Mm8jFVuaDQAqnJrqrBdtpGPauVTgiuttTm3Q+1A E1FFFABRRRQAUUUUANboKdTW6U6gAooooAKKKKACsDWn3XIXPQVvVzWpPvvHPYcUAVOTxTSu O1TW6Fp0X1NWdTtmhl3AfK1OwiPTJvJulLdDxXTg5Ga44Eg8V0el3Pn24DH5l4NIZfooooAK KKKACmuwVST0FOqK4QyQOq9SKAMDUdQknkZEbCA9u9V7W+mt5NwJI7gnrUU0LxSEOpBHrUdF gN9NbhIAYEGse7lEtwzr0NVzS9aQDgeeK6jTGZrNC3pXLouWAHU11djEYrZFPXFMCxRRRQAU UUUANfpWHrajz1IPJFbj9KxNcIEqfSmIy0B3j611ltn7OmeuK5WHBkUE8ZrrIgBGoHTFAx1L SUtIAooooAgu5BFbux9K5diXJJrb1uTbAE7k1hUwNPRYt07OR90VvVm6NHttyx/iNaNDAM46 1XmvYIR80i5qnq955Uflo3zHrWASWPJJNIDo/wC17bIwT+VOTVbd2xux7muZyBRn3pDOwinj m+44NSVx8U8kRyjFTVyLV7iPqQw96BHSVFLKkbDcwH1NYLavOxOMCqctxLK252JNMLHVR3MU n3HBqXNcaszxtlWIq7Fqs6KATmgZ01FUrG9W4jG5hv8AQVdoEFFFFABRRRQA1ulKOlI/3aUd KAFooooAKKKKACikpaACiiigBo6mnU1epp1ABRRRQAUUUUAFFFFABTT1FOpp+8KAHUUUUAFF FFABRRRQAUUUUANb7poX7oob7ppM4TPtQLqY+tTbnEXHHNZWOasXkhkuHb3qGEGSVVxnJpjO g0qAR2qtjDNyavUyNdsaqOwp9IAooooASloooAaOpp1NHU06gAooooAKKKKACiiigAprdqdT W6igB1FFFABRRSUALRRRQAUUUUAIelC9KD0oXpQAtFFFABRRRQAUUUUAFFFFADP46fTP46fQ JBRRRQMKKKKACiiigAprdKdTW6UALS0lLQAUUUUAFFFFABRRRQAlIvelpFoAdRRRQAUUUUAF FFFABRRRQA0/ep1N/ip1ABRRRQAUUUUAFFFFABTJPu0+mSdKEJ7Dh0paQdKWgYUUUUAFFFFA BRRRQAUUUUAMB+YinU0ffNOoEhaKKSgYtFJS0AFJS0lABSNS4pGHSgBaWkooAWikpaACkpaT FAC0UlFAAelIvSlPSkUfLQA6iiigBKWkpaACiiigAooooAb/AB06m4+anUCQlLSUUDFooooA KKSigBaa/Slpr9KBMcOlLSDpRQMWikoxQAtFJRQAtFFJigApF70uKRR1oEOopKKBi0UlFABS 0lGKAFopKMUANP3hT6YR8wp1AhaKKSgYtFJRQAtFJS0AFI3SikbpQAo6UtIOgooAWikooAWi kooAWikpaACmJ1NOpqfeNMTH0UUUhhRRSUALRRRQAUUUlACH7wp1NP3hS0CFopKWgYUUUlAB S0mKKAFpG6UUjdKAFXoKWmr0paAFopMUUALRSUUALRSUUALTR940tIB8xoEOoopKBi0UlFAC 0UlFAC0UlFADX6in1G45FPA96YhapX98tqBxkmrh6VzOqSM92wPQelIZHdX0lw/UgegqoWOO +aU0HpQAnWgjNAqRo2VQWXAPSgCEfSpFUnoMmhBk81uaPbjyWcgc9KEDZhkEdRijntXVizgb lolJPtTG021Y58oU9BanLY9qULnpzXUf2Za4P7sU9LG3jOVjUUWQanOW9lLcH5VrWj0aIoPM yG9jWoqKowoApaLgZD6Gh+7IR9RVY6JMGIDDHrXQUUXCxzMtg0CkysB6c9apN7VsazBM0oZQ zJ7DpWaLWZh8sbH8KNwEtV3zop5Ga6yMbUAFY+mabIriWUbcdq2qAFoopKQxaKKSgBaKKKAG v0FOpj9BTqBdRaKSloGFFFFADXOEJ9q5SckyufeumvHKWrsPSuXbk00BZ0yMyXieg5rZ1ODz rVsdV5FZ2iITOzY4A61uEZFAjkGBHBqayuGt7hWB4zyKs6lZsjmVB8p9Kz8YoaBM6+KRZUDK cg0+ub06+Nu4VzlD+ldCjB1DKcg0hj6KSigBaKSigCOW3imGJEDfUVkXej/P+4PB7Gtumn79 NMTOebRrkDgKfxpg0q67pXTUUXAy7TSEQBpuW9K1AABgUUUhi0UlFAC0UUlADXOBXP6w++6w OwrduGCRFicYrl55DJMzE5yafQXUfZJvuo1IzzXVKMACsHRrYvN5p6LW9QMWikopALSUUjHC kntQBgazLvutv90Vnr94VNdP5tw7eppbOPzLlFxkZpiOhsl2wKBxxVgnAqOEYXHaqupXf2eL jqeBQwWxi6nL5t22MYHFU8c8U5juYk9TVnT4POuFBxjrSGPttMedd2cZp/8AY0/bH41vqFjQ AYAFV7rUIrbGTuJ7CnoIwpNOuYzzESPaoXglX7yMPwrYGtx55jYCr8E8NyuUKn2o0Hqcrsf0 P5UjRuOx/KuuNvEeqL+VRXFpHL8uMfSiyFdnKfWjOOtaF9p5hY4PHas9uKTQyzZytFOrKe9d TFIJEBBFcaGIHStXTtRMZCSHINAHQ0VWN7AAMyLTG1K2UZMo/CgC5SVmNrUHO1WNV31xv4Ih +JoA2n+7SjpWAdZmPBRad/bcoX7i0Ab1JWEdckwMRrmom1i4bnAFIDos0tc1/a05XGali1mV XG9crQB0FFUbbUYpl5YBvSraurdCDTAfRSUUAIvU06mL1NOoEhaKKKBhRSUtABRRSUALTT94 UtIc7hQA6koooAWikooAWikpaACiiigBr/dNV72XyrN29sVO/wB01k6xNiNIx35pi6mQ3P1q /o8PmXW4jIXms881vaLCUgLn+KgDTooopDCiiigAopKKAEHU06mLncadQJC0UlFAxaKSigBa KSloAKa3UUtI3UUAx1FJRQAtFJRQAtFJRQAtFJRQAHpQvSg9KRelADqKSigBaKSloAKKKSgB aKSloAZ/HTqb/HTqBIWiiigYUUUUAFFFJQAtNbpS0j9KBMWlpBRQMWiiigAoopKAFopKWgAp q96WkTpQIdRRRQMKKKSgBaKSloAKKSigBD94U6mn71LQAtFJRQAtFJRQAtFJS0AFMf7tOpsn ShCew4dKWkHSloGFFFFABRRRQAUUUUAFFFFADR9406mj7xp1AkFFFFAwooooAKKKKACmt2p1 NagB1FFFABRRRQAUlLSUALRRRQAhpF6Up6Ui9KAHUUUUAFFFFABRRRQAUUUUAN/ip1N/ip1A BRRRQAUUUUAFFFFABTX6U6mt0oBijpS0gpaACiiigAooooAKKKKACmr3p1NXvQA6iiigAooo oAKKSloAKKKKAGn71Opp+8KdQIKKKKBhRRRQAUUUUAFI3SlpD0oAB0paQdKWgAooooAKKKKA CiiigApq9TTqavU0CHUUUUDCiiigAooooAKKKKAGnqKdTT1FOoAKKKKACiiigAooooAKQ9KW kPSgAXoKWkHSloAKKKKACiiigAooooAKaPvGnU0feNAh1FFFAwooooAKKKKACiiigBj9RT6a 3UU6gQlUbnS4Z2Lcqx64q8SAMms6+1RIQVjIZqBmTfwQwPsjclh1qnj1p80rTSF26nrToIHn cKgyTRuGw61tjO/UBRySadfSB5Aq/dUYFbcWniKzKDG8jrXPyoyOysMEGmxEaV1GmgCyTHpX MDrwK6XTPM+xrv8AwoGXF6U6mr0p1IAooooAKKKKACiiigBCM00ABuAKfTR940AOooooAKKK KACiiigAooooAa3anU1ugp1AgooooGFFFFAFDV32WhGeW4rnSea2tckG1Exz1rGFMDa0SMiN nPetU9Kp6VGUs1z35q4elDAjMayRsjDg1z1/ZNbSHuh6GukTpTJ4UnjKOMg0COSIxV2x1GS2 IVjuT09KS+sJLYlsbk9apdqAR10E6ToGRgalrkoLmS3bKOR7Vs2erxy4WXCN69qQzUopqurD KkEUtAC03+KnU3+OgB1FFFABRRRQAUUhIHU1BNeQQjLyD6A0AWKjllSJSzsABWVcaznIgT8T WXcXUtw2ZGzQBd1DUzODHFwvr61QijaVwqjJNEUTyuFVcmt/T9PW2G9uXP6UxE9jbC2gC9+9 WaKKQwooooAKrX8vlWrsOuKs1ma1KFgCd2NAGETyTV/SGjjdpJG29qzzTNxpgdI2p28ak78+ wrEvrv7TNuGcehqqTSCkAua3NHMa25c4yO9YQFTJNJGhRWwp6igC/qGpPNmOP5VB6+tZhYk8 nJpyKzttUEk9hWtaaNuAa4JHsKLBcxiSKlgmeFw6Ng1o6hpfkr5kWSB1rKIoaC50+n3n2mP5 sBh2qy33xXMWVx5Fwr9u9dIkiy7WUgg00JmRrMjbwO1Y56c1vazD8hftWCetJjQmfl4pR7Ub eOlTQWskzbUUmiwXIix9aXrWsmhMVBMgB7irEGixo2ZG3e1OwXMJQx4ANTrZXDrkRNj6V0sV pBFjZGAfWpsUaC1OWXT7kjPlkfWmvY3CdY2NdU/3aUAY6UaBqcf5EmcbGz9KTynBwVNdhsXO dozTWhjbqgzRoGpx5QjqDTe9db9ht/8AnmKqzaNbvnZlD7UWQ7s53Jzwaniu54fuSGrE+lXE ZO1dwHeqLKVOGGDSsFzXstXlMgSbBB71uKQygiuMBIrb0i+3DyXJJHQ0Aa69TTqavenUAFFF FABRSUtABRRRQAU0/eFOpp+8KAHUUUUAFFFFABRRRQAUUUUANf7prm9Qm824PPA4Fb95J5Vs 7e1cuxJJJ70xAq73Cjqa6m1i8m3RPQVgaVD510pIyF5NdJQwFooopDCiiigAooooAavU06mj qadQAUUUUAFFFFABRRRQAU1uop1NbqKAHUUUUAFFFFABRRRQAUUUUAIelC9KD0oHSgBaKKKA CiiigAooooAKKKKAG/x06mfx0+gSCiiigYUUUUAFFFFABTW6U6mt0oAdRRRQAUUUUAFFFJQA tFFFACUi0tIvSgB1FFFABRRRQAUUUUAFFFFADf4qdTf4qdQIKKKKBhRRRQAUUUUAFNf7tOpr 9KBMUdKWkHSloGFFFFABRRRQAUUUUAFFFFADNwDYNLuHqKaVDPzS7F9KYtRdw9aXcPWk2L6U bF9KQai5HrRketJtX0o2L6UBqLketGR60mxfSjYKA1FyPWkYgDrRsHpSMgIxTDUUMD3pcj1p oRQOlLsX0pBqLketGR60mxfSjYvpQGouR60m4etBRT2pNi56UBqOyPWjI9aTYvpRtHpQGopI pFIxRtGOlIqDGaYajsj1oyKTYvpRsX0pBqLketGR603YvpRsX0oDUdketGR603YvpRsHpQGo 7I9aM03YvpS7B6UBqJkButOyPWmFAWpfLWnoGo7I9aMj1pvlijYKA1HZFGRTdgo2CkGo7NFN 8sUuwUBqLmkf7tGwU10GKYO9h4IxRmmCMY70vlj3oDUdRTdgo2CkGo6jNN2D3o2D3oDUdkUZ pvlijyx70w1HUinrzSbB701YxkmgNSSim+WPejYPU0BqOopuwepo2D1NINR1FN8sepo8sepp hqOopuwepo2D1NINRScEUtRtHkjml8seppiux9FN8sepo2e5oHqOopnl89TS7Pc0BqPopmz3 NGz3NINR9IelN2e5oZeOpoAcDkUUwJx1NBj9zTC7JKKZs46mjZ7mkA+im7Pc0mz3NAD6KZs9 zS7fc0AOpqnk0m33NNCfMeaYNslopmz3NGz3NIB9FM2e5o2f7RoAfRTNvuaNv+0aAHUtM2H1 NGw/3jQApOCKdUTKTjmnBD/eNMLsfRTNp/vUbT/eNILj6KZtPrRsP940BcdRTdh/vGjafU0B cfSHpTdp9aCpx1oAcOlFRqhx9407Yc/eNMLsfRTNp/vGjaf7xpBcfRTNpx940bD/AHjQFx9F M2n1o2n+8aAHUg+8aTaf71N2kt1phckopu0/3jSBW/vUAPopu0/3jQVb+9SC46io2+UZZ8Cm iVScCUH8aAJqKjHPR6U5HV6YCucYpss8cKFnYACoLieNF+aQZrAu7l5XOTkfpQC3Ll/qrSgp Dwp71lE5NNpf5VIyzaWsly4CDjua6O0tI7aMBR83c1zkF7LbqVjwAavW2rsSBKePUVVxG7Va 4sILjllw3qKdDMsyhkkBFS7W/vUAVF0u2XB2nI96uBQq4AwBSBW/vUENjrQA4dKKjUMR1xTg G/vUWC46im4b+9Rhv71ILj6KZhv71G1v71AXHUU3DetGG9aAuOpO9JhvWmkNu4NMLktFMw/9 6jDetILj6KZhvWjDetAXHUU3DetLhvWgLi0U3DetADeooC4rUtMfdigB8dRTsK5JRUeH9aXD etA7j6KZh/UUYf1FILmJrTZuFX0FZyjLDirmqsftZ5yQKqRZ81enWmB1FqoW3QAY4qWo4w2x eR0pxDY60BcVelLUSB+cHin4f1FDQk9AdFkUqwBBrGvtJZMvByP7tbOHx1FJh/UUDOSZCCQR g03HNdNcafHOcsAG9RWXc6VNHyg3j2p2FcqwXc9ufkc49D0q/HrTj/WID9DWY8bocMpB96bi lYq5vprMDD5gymnf2rbbs7j+Vc7+FFIDojq9t6n8qY+swAfKGJrAzR9aLBc2G1s5O2IY9zUE usXDjChV+lUFViflXNSLbTOfljY/hTsFxXu7iQnfI351ASSc9a0IdIuJMFgEHvVyPRkX77bq dhNmKsbMflBJ9qv22kyyEGT5V/WtmK3WEYRFH4VLh/UUtBEMNrFboAij61Ypj7sUDzMdRQFx 9FN+f1FHz+1Idx1FMO/2pfn9qAuPrA1t91yq+grbbeBniuZvZDLcux9aYXINu7gd6nOm3IAI jyPaktFL3Ma+9dMocLjigLnNnTpRC0jjaB61UIHauivywtZOOK51vpQ0CdxAMU5QSQB1ptaO k23my7yMhaSQNmlpdgIIxI4+c/pWjTAHA7Uvz+1MLisoZSCMg1zep2n2ackD5W5FdF+89qzt YiLW29sZWgLmB3rY0aQlyhPArHPNaOnyfZ4mkIoQMn1ubJWIHjqax8c4qW4nM8rOe9Tadb+f cAHGBzSGaml2KC3DyKCzetaKRIn3VA+lIiuqgDGBTvn9qYh1FN+f2o+f2pBcdRTfn9qBv9qA uK3SlpjbtvNA346CmFx9FN+f2o+f2pBcdRTfn9qPn9qAuONY2rWBJM0Y+ta539gKRgxGCAaY XOQIAPNOikaGQOp6Ve1SzMD+YFwrelZxNJgjqbC4FxDu71brlLW8kt2ARiFrobW4a4iDgfnQ GxZopvz+go+f2oC46lpmX9BR83tQFx1FN+f0FHz+goC4+mnqKT5vQU1i2Rgc07Bclopnz+gp Pn9BSC5JRTMv6CjLegoC4+imZf0FGX9BQFx9FMy3oKMvjoKAuZ+sy7YQgPLVhHFXNSmMt02e g4qmo3MAO9MZuaJDtiMpHLdK1KrWiNHbouBwKmy3oKGK4+imZf0FGW9BSC4+imZb0FGW9BQF x1LTMv6CjLelAXFHU06ogX3HinZb0FMLj6KZ83oKMt6UguPopmW9KMt6CgLjqWmZb0FGW9KA uPpp6iky3pSMW44phckopmW/u0Zb0pBcfRTMt6CjLZ6UBcfRTMt6CjLelAXHUUmW9KMt2FAX FPSgdKblsdKarNj7tMLktJTdzelG5v7tILj6KZk+lGW/u0BcfRTMt/doy392gLjqKblvSly3 pQFw/ipajLNv6U7c392mFx9FMy392jLf3aQXHUU3c392ly3pQFxaKblv7tG5v7tAXHUhpAzf 3aRycdMUwuSUVGGYj7tLlv7tILj6KZlv7tGW/u0BcfSU3LelG5v7tAXHUU3Lf3aMt6UBcdSL 0NJlv7tIrN6UwuSUUzLf3aNzf3aQXH0lNy392gFv7tAXHUU3c392jLelAXHUU3Lf3aXJ9KAu H8VLTCzBhgUuW/u0wuOpaYWbP3aMt/dpBcdRTdzf3aNzf3aAuOopMt6UmW/u0BcdTX6Ubm/u 02RjjpTQm9CQdKWkHSlpFBRRRQAUUUUAFFFFABRRRQA0feNOpo+8adQJBRRRQMKKKKACiiig AprU6mtQA6iiigAooooAKSlpKAFooooAQ9KRelKelIv3aAHUUUUAFFFFABRRRQAUUUUAN/ip 1N/jp1ABRSUtABRRRQAUUUUAFNfpTqa/SgTFHSlpB0paBhRRRQAUUUUAFFFFACUi96dTV70A OooooAKKKKACiiigAooooAafvCnU0/eFOoAKKKKAEpaKKACiiigApG6UtNbpQAo6UtIOlLQA UUUUAFFFFABRRRQAUxepp9MTqaBD6KKKBhRRRQAUUUUAFFFFADT1FOpp6inUAFFFFABRRRQA UUUUAFIelLSHpQADpS0i9KWgAooooAKKKKACiiigApo+8adTR940AOpKWkoAWmu2xSx7U6or gEwsF64oAwL/AFCSZyg+VQe1UBIytkMQaJARIwPXNMxSAsLdzpyshpHuZmJzIxz71EqEngE1 PFZzSnCxmnYLkJY45OabmtaPRnwPMYDPpU66Gn8Uh/AU7CuYPelHFdAuiQAjLManGl2oH3KL IdzmDSHgV0l1pkTQMI1AbtXPOmxip4IosBNZ3DwzKysQM811Ubh4ww71yEQYyKo55rrYF2wq PakBLSHpS0h6UAC9KWmr0p1ABRRRQAUUUUAFFFFABSfxUtN/ioAdRRRQAUUUUAFFFFABRRRQ A1qdTW7U6gBKWiigApD0paRvumgDmL5g925JzzTbNQ11GCMjPSm3HMz/AFNT6Wu69TPQc0xH SAYAopaTtSGIvSnU1OlOoEgooooGFFFFADHjRxhlBHuKrSaZbSHOzb9KuUUXAzW0a3PQsPxp jaNCTgOwrVpv8VO4rGcmi26/eZmqZdMtVORHn61doouwsRJBFH9yNR9BUmAOgpaKQwooooAK KKKAEalprdKdQAUUUUAFFFFAEVw2yB29BXKOSWJ9TXS6k2yyc+1cyTzTAuaUm68X25rpO1Ym hx5kdz24rboYFDVGC2T+9c0a6HVs/ZW9M1zxpMSEq7Z6g9qu0YI9Kp+lBPPFAzdTXEx8yHNS jWrf/a/Kuc5zSjNIDck1xR9yPJ96p3WqPcxlGQAGqGD6UYOcY5pgW7JIJJcSsRSXsqs+2LhB xilhtZChkZSFA71UbOaYhDWvogxIfl/GscAk8V0mjwFIN7Dk0kM0qKKKACiiigAooooARulA pG6Uo6UALRRRQAUUUUAJS0UUAUdWVWtG3VzJrc1ybCrGD161h4oAcg3EAda6fTozHaqGGDWf pOnqwE0mcjoK2hwKYhaKKKQwooooAKKKKACmnqKdTT94UAOooooAKKKKACiiigAqOdxHCzHs KkrN1mbZb7B1agDDkYtIzepqzpcIlu1yOBzVQ+1bmiwbYjKw5bpTEaY4paKKQwooooAKKKKA CiiigBo6mnU0dTTqACiiigAooooAKKKKACmnqKdTW6igB1FFFABRRRQAUUUUAFFFFACHpQOl B6UDpQAtFFFABRRRQAUUUUAFFFFADf4qdTR96nUAFFFFABRRRQAUUUUAFNbpTqa3SgB1FFFA BRRRQAUlLRQAUUUUAJSL0paRelADqKKKACiiigAooooAKKKKAG/xU6m/xU6gBKWiigAooooA KKKKACmP92n01+lCExR0paQdKWgYUUUUAFFFFABRRRQAUUUUAMH3zTqaPvmn0CQlFLRQMKSl ooASilooASmvnin01qBMWilooGFJS0UAJRzS0lAC0lLRQAh6UifdFKelC9KBBS0UUDEopaKA CkpaKAEopaKAGc76dSfx06gSEoopaBic0UtFACUUtFACU2T7tPpr9KEJijpRRS0DEopaKAEo paKAEopaKAEpq96fTV70CFopaKBiUUtFACUUtFACUUtFADCfnHFOpD94U6gQUlLRQMSiiloA SilooASkf7tOprdKAYL90UtA6UtACUUtFACUUtFACUUtFACUxPvNT6avU0xMdRS0UhiUUtFA CUUtFACUUtFADGPzCnUh6inUCEpaKKBhSUtFACUtFFACUN0paQ9KAEU/KKdSL0FLQAUUUUAJ S0UUAJRS0UAJTVPzGn01fvGgQtANLRQMTNI/3TTqa3CmgDkrrP2mTPrUSDc4HvU10d1xIevJ pbRN9zGO2aAOgtLSFI1OzJx3q18qDoAKTIRMngAVhajqTyuY4mwg7jvTbCxfu9ThiOFO9h2F Vl1w5+aL8jWPkn60nIzmkB01vqlvNgZKn0NXAwIyOlcaCc1r6fqhQrFLyvQGgDYuG2QuwHQV yUjbnJPc11Ny6taOwORjtXKt1oAsaeN11Hj1rqh0Fc5o6k3YIFdJQAmaGPFFB6UAIh+WlpF+ 7TqAQUlLRQAlBNLSUAGaM0tFACU0H5zT6aPvUCFopaKBiUZpaSgAopaKAEzRmlooAY5xinUj 9qWgQZozRS0DEpkpxEx9qkqK5/493+lAHKyMTIx96u6Mc3n4VRb7xrR0Q/6UfpTEb1B6UtIe lIY1DxTqanSn0CWwUUUUDCiiigApKWigBKbn56dSfxUCHUUUUDCiiigApKWigAooooAax4pa RulLQAUUtFACUUUtAGdrTYtcZ6mufNbmuH9yo96wsc0xG7oYxCzeprUJqho64sxnuav0hmbq ozaN169q54ium1ED7FJXNmmxIu6XZrcyEv0XtWuNLtR/yzBqloTDc6962qLhYpjS7UZ/d9ac un2qjAiWrdJRcLEP2WHGPLXH0qL+z7YPv2AGn3F7Dbj52GfSse51iWTKxAKvrSux2Lmp3SQR eWgUk8Vz5OTzTnZnbcxyafDBJMwCKSaNwEgj8yRUAzk9q6y2jEUKoOwqnYackADty9aFMQtF FFIYUUUUAFFFFADXPFKOlI3SlHSgQtJS0UDCkpaKAEoJwKKjuHEcDt6CgDnNSmMt23oOKggT zZVQDqaSQ7nLHua0NGtxJKZGH3elMRtWyBIwo7VNTEGM0+hggooopDEpaKKACiiigBKQn5hT qaR8woBjqSlpKAClpKWgAooooAQkAZNc5qdx59wcdF4rav5vJtmPc8CuZJyTTAEUu4Uck11N qvl26L6CsPSrfzJy56LXQoMKKHsLqOooopDCiiigAooooASiiigBFPJp1NUcmloBC0UUUAFF FFACUtJS0AFNY8inU1uooEOoopKBi0lLSUALRRRQAUUlLQAh6Ui9KUjihelAC0lFGKAFoooo AKKKKACiiigBg++afTAPnNOoEhaKKKBhRRRQAUUUUAJSN2paRhnFAmLS0lLQMKKSigBaKKSg BaKSloASkXpS0i9KAHUUlFAC0lLSUALRRRQAUUlLQA3Pz06m4+aloELRSUtAwopKWgAooooA KZJ0p1NkGRQhPYcOlLSDpS0DCiiigAooooAKKKKACiiigBo+8adTR9406gSCiiigYUUUUAFF FFABTW7U6mt2oAdRRRQAUUUUAFFFFABRRRQAh6Ui/dpT0oXpQAtFFFABRRRQAUUUUAFFFFAD f4qdTf46dQAUUUUAFFFFABRRRQAU1+lOpr9KAFHSlpB0paACiiigAooooAKKKKACmr3paRe9 ADqKKKACiiigAooooAKKKKAGn7wp1NP3hTqBBRRRQMSloooAKKKKACmt0p1Nf7tAMUdKWkHQ UtABRRRQAUUUUAFFFFABTF6mn0xepoEPooooGFFFFABRRRQAUUUUANPUU6mn7wp1AgooooGF FFFABRRRQAUh6UtIelAAvSlpF6UtABRRRQAUUUUAFFFFABTV+8adTR940CHUlLSUDFqC7kEd u7E44qeszWpgkGzH3qAMBySxNXdIj33YPpVE+1a+loILZ5249KYEur3qqhhU/MetYfU8U+eQ yys5JOTU+n2/2i4UHgDk0gL2nWACB5VB3djVy60yGdPlGxuxFWiAu0DtUlU2Skcnc2z20pR/ wPrUH410GtqpgByNwNc8eTUsovW980dtJCxJyOKpnqKcgO1jSZoEaehoTOzdgK36xtBHEhrZ oGFIelLSHpQAi/dp1NXpTqACiiigAooooAKKKKACmj71Opo+9QA6iiigAooooAKKKKACiiig BrUtI3aloAWikpaACq98220kPtViqmpf8eb/AEoA5ojmtLQ8/aG+lZnOa1tDU73btTEbdJ2p aQ9KQxE6U6mp0p1AkFFFFAwooooAKKKKACm/xU6m/wAVADqKKKACiiigAooooAKKKKAEalpG 6UtABRRRQAUUUUAZGun5YxjvWLzmtnXCMpWP3piOi0k5slq7VPSsfYlxVztSGZuqSqto67hu PQVzxJrQ1Z83BU9qz6GJGlosoS4II6966HIrj4pXibchwanOo3BAG8jFAzo5bqGJSXdRj3rH utZdwViGB61mPK0jEsck0ioznCqSfagBZJGkOWJJpoGTjFaFtpE83LjYPetS00uK35b529xT sK5mWelSzEM42p7962oLWO3IVBVgAAYFNP3hRcGh9FFFIYUUUUAFFFFABRRRQA1/u0o6UjdK UdKAFooooAKKKKACszWp9luEHVq0icCub1SczXR/urwKAKR5NdHpMHlWoJ6tzWFaQme4VBXU xoEjCjoBTEKvU06mr1NOpDCiiigAooooAKKKKACmnqKdTT94UAOooooAKKKKACiioriUQws5 7CgDI1m4DyCJW+7yaywOeOafK/mSs57nNTafCZrtQBkA5NMRs6dB5NoMjDHk1dX7opDwvFKv 3aAFooopDCiiigAooooAKKKKAGr1NOpo6mnUAFFFFABRRRQAUUUUAFNbqKdTT2oAdRRRQAUU UUAFFFFABRRRQAh6UL0oPSgdKAFooooAKKKKACiiigAooooAb/EadTR9406gSCiiigYUUUUA FFFFABTWp1NbpQA6iiigAooooAKKKKACiiigApq9KdSL0oAWiiigAooooAKKKKACiiigBv8A FTqb/FTqACiiigAooooAKKKKACmP0FPpr9KEJiilpBS0DCiiigAooooAKKKKACiiigBo+8ad TR9406gAooooAKKKKACiiigAprU6kNAC0UUUAFFFFABRRRQAUUUUAIaB0oPShelAC0UUUAFF FFABRRRQAUUUUAN/ip1N/ip1ACUtFFABRRRQAUUUUAFNfpTqa/SgTFHSlpO1LQMKKKKACiii gAooooASkXvS0i0AOooooAKKKKACiiigAooooAafvCnU0/eFOoEFFFFAwooooAKKKKACmt90 06kPSgAHSlpB0paACiiigAooooAKKKKACmL1NPpi9TQIfRRRQMKKKKACiiigAooooAaeop1I eopaACiiigAooooAKKKKACkPSlpD0oAB0paQdKWgAooooAKKKKACiiigApo+8adTR940AOoo prMFBJ6UAKTgVzurXPnXBVT8q8VLqGqM7GOE4XoTWVkk0ASQRmSQKoySa1dTT7PZJGp4707R 7LaPOkBz2q3qNo11DtU4I5FMRy/SpI5niOY3Kn2rQ/sWcqSWXPpVKW0micq0Z49qLBceL64H /LZqX+0rr/nqaq7COooCH0pWHclluJJf9YxNQ8Zp4jcnhSaPKcE5QjFFmFxN5CleMUDpTTUt tC00qxr1NCA3dEj225f1NadRW8fkwqg7CpaGAUh6UtIelAAvSlpB0paACiiigAooooAKKKKA Cm/xU6k/ioAWiiigAooooAKKKKACiiigBrUtI1LQAtFFFABVHVnKWZx34q9WTrkmIlT1NAGI eDW1oSfI7Z79Kxe9dDo0YW0DYGWNMRoUh6UtJ2pDGp0p9NTpTqBIKKKKBhRRRQAUUUUAFN/i p1J/FQAtFFFABRRRQAUUUUAFFFFACN0paQ9KWgAooooAKKKKAMjXB8sZ4rF71ta591OtYvem I6PSDmzHtV6s/Rjmzx6GtCkMydR09p23xjn0rGntpYX2yKRXWr3oaNH+8oP1FMSOOCnOOtTR Wc8hwsZrpvskG7d5S5+lTAAdBRoGpg2+iyNhpW2j0rWtrGG2HyKM+pqzRRcLBRRRSGFNP3hT qafvCgB1FFFABRRRQAUUUUAFFFFADW6Uo6UjdKUdKAFooooAKKKKAKt/P5FszdzwK5ljuJJP JrS1i68yXyl+6vWs+GIyzKi8kmmBr6JbBVMzDk9K16it4lhhVF7CpaTAavU06mr3p1ABRRRQ AUUUUAFFFFABTT1FOpD1FAC0UUUAFFFFABWJrF1uk8lTwOtad7cC3t2fv0Fcy5MjF2PJoASt 7SLXyYfMb7z1lafbG4uAMfKOTXSKAoAHQUxA33TSr90UN0oXpSAWiiigYUUUUAFFFFABRRRQ A0dTTqaOpp1ABRRRQAUUUUAFFFFABTW6inU09RQA6iiigAooooAKKKKACiiigBD0oHSg9KB0 oAWiiigAooooAKKKKACiiigBn8dPpv8AHTqBIKKKKBhRRRQAUUUUAFNbpTqa1ADqKKKACiii gAooooAKKKKAEpF6U6mr0oAdRRRQAUUUUAFFFFABRRRQA3+KnU3+KnUAFFFFABRRRQAUUUUA FNfpTqa/TigTFFLSdqWgYUUUUAFFFFABRRRQAUUUUAREEtxS7X/vU4fepaYrDcN3NGG9afRS CwzDetGG9adS0BYZhv71GG9afSUBYbhvWkbdin0jHFMLDQHx1pcN606lpBYZhv71GG/vU6lo CwzDetGH9afSUBYbhvUUYb1p9FAWG4bHWmqG7GnnpSIcrTCwmG9aMN60+ikFhmH9RRh/WnUU BYbh/UUfN7U6igLDfn9RR8/qKdRQFiM7t3XmnfPjqKX+Klp3BIaN/tR8/qKdRSCw35/UUfP7 U6igLDfn9RS/N7UtFAWG/P7Uj7ttSUxzgUwaEXfjtS/P7U4dKKAsN+f2o+f2p1FILDfn9qPn 9qdRQFhvz+1Hz+1OooCwnze1MXfk4qSkXvTBobl/QUuX9BT6SkFhuX9BRl/QU6loCxGS/oKX L9gKdRQFhuX9KMt6CnUUBYjctkcUuZPQU4/eFOp3FYZl/SjL+lOpaB2IwX9BS5b0p1FAWG5b 0oy/oKfSUgsNy3pQS2OlPprdDTCwxS+OlLl/SnjpRQFhuW9KMt6U+igLDMv6UZf0p1FILDct 6UZb0p9FAWG5b0pgLbjgVJSKeTTBoTc392jLelPopBYblvSky3pT6KAsMy3pRub+7TqKAG7m 9KXJ9KWloCxE7NxxilDNj7tOPUU6mFhm5v7tG4/3adRSAbub+7Rub+7T6KAsM3N/do3N/dp1 LQFhm4/3aCxx92nUHpTAjVz6Zp25v7tKvSloBJjdzf3aNzf3adRQA3c392jc392nUUgsJuPp Sbj/AHafRQAwMf7tN3kN0qSmj75pg0G84+7WJqt8XfykyAOvNbtUrnTILiTecqT1x3oDU5rr WnpliWYSupIHQVoR6Tbo+SCw9DV5EVFCqMAUbBuNDEDhaN5/u1T1K/8Asq7UwXNY/wDa1yWG X6dqVwsdJvP900E56rVCy1WOYBZMI1aIYMMg5p3CzIJI4zj90v5ULHGBxCv5VK/UU8U7itqQ hUHSID8KoauHaMCNDg9cCtWggHqKVx2OVjspnbAjYfUVrabYm2O91JatTFFFwsxu8/3TRvPo afRSAZv9jRv46GnUHpQGpGsnHIp28/3TSqOKWmCTG7j/AHTRv9jT6KQDN3saN/8Asmn0lADd /saN/wDsmn0UAN3exphkw2MVJSYG6mDuJv8AY0b/AGNOopBqN3+xo3/7Jp9JQGo3f7Gjf7Gn 0UAM3+xo3+xp1FAajHbA6UCTI6GnMMilxTCzuMMmOxpd/sadRQGo3f7GsPWZA86j0HStyRgk ZY9hXK3cxmnZz3NAEY69K6WxxHaovJ4rnIE8ydFHOTXWRqFQADGBQAb/AGNG/joadQelAaka SdjTvM56GhAMdKdQJXG7/Y0bx6GnUUh6jd49DS7x6GlooDUbvHoaN49DTqKYajd49DSM+GHF PpD96gNRN49DRvHoadRSDUTePQ0m8ehp1FAajd49DR5g96dRTDUbvHoaXeKWikA1nAFIJBjo acwyKUAUw1G7x6GjeKdRSDUbvHvRvGO9OooDUydaO6NCAeDWKOtb2t4+zqe+awDTA3tGO2Bs +taO8VnaGQbdhjkGtOgNSMScnIp3mD0NKoHNLQCuN8we9HmD0NOxRQGo3ePejePenUUBqN8w e9HmCnUUBqJvFMaQbqkprAFhQgdw8wUbx706igNRC4FG8UtFINRN496TeKdRQGo3eKPMFOox QGo1nGKBICKVhkUoAxTDUb5i0bxTqKQajTIB61DdXKwwMxPOOKscVgavdebN5Sn5VphqZ7sW Yk8knNa2j26j9+3XsKzIIjNMqDua6iCIRRKgA4FADt4pd4pcCjFINSMSDJp28UKoyTinYFPQ FcbvFG8U7FGBSDUaHBo3inYFGKYaibxRvFLijFINRu8UFxkU7FIwGRTDUTePWjetOwKMD0pB qN3iguB1p2BVLU7kQQEDG5uBTDUy9Uu/PmKqcotUQCSB3NBOWya0NJtfOmErfdTp70AaWmwr bwDP3m5NXNwpcD0oxQGo1mG04pFcYpzAYoUDFAtbhvX1o3j1pcD0owPSkPUTevrRvFLgelGB 6UBqJvX1o3r60uB6UYFAaib19aNw9aXA9KMD0oDUYHG4il3r60ADceKdgelMNRN6+tG9fWlw PSjApBqJvX1o3r60uB6UYHpQGom9fWjePWlwPSjA9KA1E3r60jMOKdgelNYZxTB3F3r60b19 aXA9KMD0pBqJvHrSeYvrTsD0pMD0oDUN6+tG9fWlwPSjA9KA1E3r60b19aXA9KMD0oDUTcMd aRXBpxApAox0phqG9fWjevrRtHpS7R6Ug1E3D1o3r60uB6UYHpQGom5fWjcPWlwPSjA9KA1E 3D1o3D1pcD0owPSgNRhdQ3Jp29fWk2gtyBS7R6CmCuG5fWjcvrRtHpRtHpSDUNy+oo3D1o2j 0pdo9KA1E3r60bh60bR6Uu0elAaibl9aRmAHWl2j0FIygjpTDUA6460u9fWjaPQUbR6UBqG9 fWjevrS7R6UYHpSDUTcPWjcvrS4HpRtHpQGom5fWjcPWlwPSjA9KA1E3DHWkVxjrTsD0pqgY 6Uw1F3L60bh60bR6UbR6Ug1DcPWjevrS4HpSbR6UBqG4etG4etLgelGB6UBqJuHrRuHrS7R6 UYHpQGo0uA3Wl3D1pNo3Uu0elMNQ3r60bh60bR6Uu0elINRNw9aNw9aXA9KMD0oDUTcPWjcP WlwPSjaPSgNRNw9aa7DGM0/A9Ka6jHSmgdxw6UtIOlLSGFFFFABRRRQAUUUUAFFFFADAPnNO pB940tAkLRRRQMKKKKACiiigBKRhxTqa3SgBaWiigAooooAKSlooASloooAQ9Kan3acelIv3 aBdR1FFFAwooooAKSlooASilooAZ/HTqT+KnUCQlLRRQMKKKKACiiigApr/dp1Nf7tAmKOlF A6UtAwpKWigBMUUtFABSYpaKAExSKOtLSL3oELiilooGJijFLRQAlFLRQAlLRRQAwj5hTqQ/ eFOoEJS0UUDExRS0UAFJS0UAJSN9006kboaAEX7opaF6CloATFFLRQAlFLRQAlLRRQAlNUcm n01epoELS0UUDEopaKAEpaKKAEopaKAGsORS4pD1FOoASilooASilooASilooASgjilpD0oA RR8tLQvSloASgilooASilooASilooAKYB85p9NH3jQIWjFLRQMSjFLRQBzmsQSrclyCVPQ1m la7NlDDBAIqhdaTDMSy/IfanoxHNip47yeEYSVgPSmTx+VKydcd6jpDL0eqXCsCzBh6GtKLW oWX51ZTXPDpTxQB0yalbOcCTH1qZbmFgMSLz71ymaNxB6mgDrw6nowP40w3EQfYZFDema5Xz XHR2/Oml2PJYk0AdiOelFZWiTSyIyu2VHTNa1ACUEcUUHpQAiD5aWkXpTqAQlFLRQAlFLRQA lFLRQAlIPv06mj71Ah1JS0UDEopaKAEopaKAEopaKAGt0paRqWgAopaa7bVJNAGTrF4Yx5SN yetYZNT3srS3LMfXFVz9KAJrWf7PMrgAkdq24dZhfAcFK59ValxQB10c0cgBVwc+9P7cVyCu y/dYircOp3MSgbtwHY0AdHHnBp1Y0GtAcSRn6ir8WoW0gBEgHsaARaopFdWGVYEe1OoASilo oASg0tFACU0/eFPpv8VAhaKWigYlFLRQAlHNLRQAlFLRQA1ulKKRulLQAUUtFACGilooAzda B+zD61gEV0Os/wDHp+Nc6etMRuaF/qn+tatZehZ8l8+tatIY1c80tIvenUAhKKWigBKKWigB KKWigBKa2d4p1NP3hQJjqKWigYUlLRQAlFLRQAlFLRQA1s4pR0pG6Uo6UAFFLSUAV76fyLZm 79BXMMS7FjWjrFyZJvLHRao20LTzKg7mgDU0W1wDMw69K2KZBEIolQdhUlDASilooAYucmnU i9TTqAEpaKKAEopaKAEopaKAEpDnIp1NbqKAFopaSgBGbYpY9BXM31ybicn+EcCtXWLry4vK U/M3WsGgCSGJppAijJNdNaQC3gVB261naLbHmdh7CtimISloopDGuMqaF4UUrfdNC/dFAuoU UtFAxKKWigBKKWigBKKWigBi53GnUg6mnUCQlFLRQMKSlooASilooASkbORTqa3UUCYtLRRQ MSilooASilooASilooAQ9KF6UGgdKACilooASilooAKSlooASilooAZ/HTqT+OnUCQlLRRQM SloooAKSlooASmvnFPprdKBMWiiloGFJS0UAFJS0UAJRS0UAIelNTOKfTV6UCFopaKBiUUtF ACUtFFABSUtFADf46Wk/ip1ACUUtFACUUtFACUUtFACU2TOOKfTH6UCY4dKWkHSloGFFFFAB RRRQAUUUUAFFFFADR96nU0ffNOoEgooooGFFFFABRRRQAU1ulOprUAOooooAKKKKACiikoAW iiigBD0pF6Up6UifdoEOooooGFFFFABRRRQAUUUUAN/ip1N/ip1ABRRRQAUUUUAFFFFABTH+ 7T6Y/wB2hCew4dKWkHSloGFFFFABRRRQAUUUlAC01e9Opq96AHUUUUAFFFFABRRRQAUUUUAN P3hTqafvCnUCCiiigYUUlLQAUUUUAFNb7pp1I3SgAXoKWkHSloAKKKKACiiigAooooAKavU0 6mr1NAh1FFFAwooooAKKKKACiiigBp6inU1uop1ABRRRQAUUUUAFFFFABSHpS0h6UAA6UtIv SloAKKKKACiiigAooooAKaPvGnU0feNAh1FFFAwooooAKinkWKFnboBUtZetz7LcRg8tQBiX EhllZz3NRAZYAU7rV7SrYTXIY/dXmgRNZaWSMzrgHpWl/ZlqQP3Yqy3GKdTuFjOfR7djlSy1 A+h9dsv5itmii4WME6HNn761JDomDmV/wFbVFFwsRQQR26bY1AFS0UUhhSHpS0hoARelOpq9 KdQAUUUUAFFFFABRRRQAU3+KnU3+KgB1FFFABRRSUALRRRQAUUUUANanU1qdQAUyRBIhU96d S0AYF3pEqtuiO8GmQaPM7DzPlFdFRTuKxXgs4YYwoQH3NMm062m6xgH1HFW6KLhYyZdEjI/d OQfeqM2l3EY4XcPaukpD0ouFjkXjeM4ZSDTa6sRI4O9Q31FVZdJtnyVUqfY09BK5hJcSxfcc r+NW4tWuUADEOPeppdFfP7twR71VfTbqP/lmT9OaVh3L6a2vAeMj1xVyLUbaTAEgB9DXNyRu hwylT7imDIPNKw7nYK6t91gfoaWuRWZ0PyuQfY1YTVLpQBvz9RQB09NJ+esFNanA+ZFNSDW2 yCYh+dAG5RWMNdH8UJ/A04a5GesR/OgDWorK/tuL/nm1O/tuDH3GzQBqUVl/23Bn7jYpy6zb Ec7h+FAGlRWf/bFt6t+VPXVbQ/8ALTH1FAFtulLVQ6jasOJRUy3MLLkSLj60ATUVGJYz0dT+ NPBB6GgBaKSigDM1tsW4XPJNYPNautzqzqisDjrWVzTEbuhhvIYk8ZrVqlpUfl2a+p5q7SGN XvTqavenUAFFFFABRRRQAUUUUAJTT94U6kP3hQJjqKKKBhRRRQAUUUUAFFFFACN0oHSkbpSj pQAtQXkvk2zv3AqesTWrjLiFTwOTQBlOxZiT1Na+iW/WY/QVlRIZJAoGcmupt4xFCqKMYFMR LRRRSGFFFFADV6mnU0dTTqACiiigAooooAKKKKACmnqKdTT1FADqZLII42c9AKfWRrF1x5KE e9AGXdTGednPc0lrC08yoo6mou9b2j2vlQ+a33n6UxGhFGI41QdhT6KKQwooooARulC9BQ3Q 0L0FAhaKKKBhRRRQAUUUUAFFFFADR1NOpo+8adQAUUUUAFFFFABRRRQAU1uop1NbqKAHUUUU AFFFFABRRRQAUUUUAIelC9KD0oXpQAtFFFABRRRQAUUUUAFFFFADf46dTP46fQJBRRRQMKKK KACiiigAprdKdTW6UAOooooAKKKKACiiigAooooAKavQ0tIvSgB1FFFABRRRQAUUUUAFFFFA Df4qdTf4qdQAUUUUAFFFFABRRRQAU1+lOpr9KBMUdKWkHSloGFFFFABRRRQAUUUUAFFFFADR 9406mj7xp1ABRRRQAUUUUAFFFFABTW6U6mt0oAdRRRQAUUUUAFFFFABRRRQAh6Ui/dpT0pF+ 7QA6iiigAooooAKKKKACiiigBv8AFTqb/FTqACiiigAooooAKKKKACmv92nUx/u0CY4dKWkH SloGFFFFABRRRQAUlLRQAU1e9Opq96AHUUUUAFFFFABRRRQAUUUUANP3hTqafvCnUCCiiigY UUlLQAUUUUAFNbpTqa33TQAq9BS0i9BS0AFFFFABRRRQAUUUUAFNX7xp1NXqaAHUUUUAFFFF ABRRRQAUUUUANPUU6mnqKdQAUUUUAFFFFABRRRQAUh6UtIelAAvSlpF6UtABRRRQAUUUUAFF FFABTR9406mD7xoEPooooGFFFFACMdqkntXMalc/aLkkdBwK3dSn8m1YjqeBXLNkknvQAtdD osOy3Lnq1YMMZklVRkknpXWQII4lUdhTAV+1Ppj9qfSEFFFFAwooooAKKKKACkPSlpD0oARe lOpq9KdQAUUUUAFFFFABRRRQAU3+KnU3+KgB1FFFABRRRQAUUUUAFFFFADW7U6mtTqACiiig AooooAKKKKACkPSlpKAGx9DT6YnQ0+hiQUUUUDGPEkg+dQfqKrS6bbS5ym0+oq5RRcLGTJoi H/VyEfUVWfRZh91lat6incVjmm0y6X/lnn6VE1ncL1ib8q6umkfNRcDkmglU8o35U3ynxnY3 5V2BUHqBSbRjoKNA1OP8s9waMEdq68xRnqi/lTTBETzGv5UaBqclikwa61raBhzEv5Un2S3x jykx9KNA1OT5orqvsFtnPkrSHT7U/wDLFaNA1OX5oya6OTS7Y4IXH0pp0e2PPzD8aNAOfDEA 4Jp6TypysjD8a2ZNEiP3JGWojoZx8sv5iiwXZnjULpTnzW/Gg6ldH/lqaS8s3tGAZgc9MVVp WHcczM5LMck1YsIGuJ1QDjqarqpZgFBJPaul0y1EFuCygOetAFxFCIFHQU6iigBq96dTV706 gAooooAKKKKACiiigApp+8KdTD94UCH0UUUDCiiigAooooAKKKKAGt0pR0obpR2oAbK4jjZj 0ArlbiUyzu57mt3V5dlqVB5biue5zQBp6JBvnMjD7tb1UtKh8q0Unq3NXabAKKSlpAFFFFAD V6mnU1epp1ABRRRQAUUUUAFFFFABTT1FOpp6igBlxKIYWduwrl5pDNKznqa0tZudziFDwOtZ X40wLFjbfaLlVwSBya6ZFCKFAwBVDSbXyYN7D5mrRoYgooopDCiiigBG6UL0obpSL90UCHUU UUDCiiigAooooAKKKKAGjqadTR1NOoAKKKKACiiigAooooAKa3UU6mt1FADqKKKACiiigAoo ooAKKKKAEPShelB6UL0oAWiiigAooooAKKKKACiiigBg++afTP46fQJBRRRQMKKKKACiiigA prdKdTW6UAOooooAKKKKACiiigAooooAKavSlpE6UAOooooAKKKKACiiigAooooAb/FTqafv CnUAFFFFABRRRQAUUUUAFNfpTqY/3aBMcOlLSDpS0DCiiigAooooAKKKKACiiigBo606omba /Sl8z2NOwrokopnmexo3j0NKwXQ+imb/AGNG8ehosF0Popm8UeYPQ0WC6H01ulJ5g9DSO4xT sF0PpajEgxS7x6GiwXQ+imbx6GjeKVguPopm8UeYPeiwXQ+imeYPejePQ0WC449KReBSFxim rIMYNOwXRLRTN4o3ilYLofRTN4o8wUWC6H0UzzBR5gosF0Popm8UbxRYLoX+KnVEXw/tTvMF OwXQ6im+YtHmCiwXQ+imeYB1o8wUrBdDqKb5i0eYKAuh9Nf7tJvFNdwVppA2iQdKWo1kBWl8 xfWiwXQ6im+YvrR5gpBdDqKbvFHmLQF0Oopu9aN6+tAXQ+mr3o3imLIMkGnYLokopu9aN6+t ILofRTN4pd4osFx1FM3j1o3iiwXQ+imb19aN6+tFguhT94U6o2cAil8xfWnYLodRTfMX1pd6 +tILodRTN49aXevrRYLjqKbvFJvX1osFx9I3Sk3j1pGYYoC44dBS0xXGKXePWgLodRTd6+tG 4etAXHUU3cPUUbh60BcdRTdw9aNw9aB3HU0dTRuHrTFcBjk0xXJaKbvHrRuHrSC46im7h60u 4etAxaKTcPWk3D1oAdRTdw9aNw9aAuB6inVGzgEU7cPWmK46im7h60bh60guOopu4etG4etA 7jqKbuHrRuHrQFx1IelG4etISMUAKOlLTFcY60u4etArjqKTcPWkLD1oGOopu4etLuHrQAtF JuHrRketABSD7xpcimhhuNAh9JSbh60bh60DHUh4FG4etVb+5Fvbsw+8eBQBkavdGafy1Pyr /Os6nOxZiT1NPt4vNmVB3NFgNHRLbc5mYcDgVu1DBGkMQRcACpcimxCN2p1MdsAGl3DGaQDq KTIoyKBi0UmRRkUALRSZFGRQAtIelGRQSMUAC9KWmqwIpcigBaKTI9aM0ALRSZHrRkUALRSZ FGRQAtN/ipc03cN2KBD6KTIozQMWikzRkUALRSZozQAtFJmigBG6U6mOcCnAjFAhaKTNGaBi 0UmaM0ALRSZoyKAFpKKCeKAETpTqYhFOyKBIWikzRmgYtFJmjNAC0UlGaAFpP4qKaSAwoAfR SZozQAtFJRQAtFJRQAtFFFADW6UtIxwKWgQtFJmigZn6np7XWHQ/MO1Y5024BA8s9a6jNHFM RlafpZhcSS9R0Fa1JRSGLRSUUAIvenU1TnNOoAKKSigBaKSigBaKTNFAC00/eFLSE/MKBMdR SUtAwooooAKKSigBaKSigBG6Uo6UjHApGYBC2egoEYmtSbpwgPCiqFunmTqvqaddS+bcO+ep q3o0O+4LnotMDejUIgUDAAp1JS0hhRSZooAWikooARepp1NUjJp1ABRRSUALRSUtABRRRQAV Xu5hBCXPap81haxdF5fKU/KvWgDOlkZ3Z26k1Z0+2+1XAHRRyTVQAk8c10Ok2/k24Y9W5piL 6gKoA6ClpKWkMKKKSgBaKKKAEbpSL90UN0oX7ooF1HUUUUDCiiigAooooAKKSloAav3jTqaP vGnUCQUUUUDCiiigAopKWgAprdqdTWPIoBjqKKKACiikoAWiiigAooooAQ9KF6UHpQvSgBaK KSgBaKKKACiiigAooooAb/HTqb/FTqBIKKKKBhRRRQAUUUUAFNbpTqa3SgB1FJS0AFFFFABR RRQAUUUUAFNXoaWkXpQIdRRRQMKKKKACiiigAooooAafvU6m/wAVOoAKKKKACiiigAooooAK a/SnUx/u0CY4dKWkHSloGFFFFABRRRQAUUUUAFFFFADcDdS0g+8adQISilooGJRS0UAJRS0U AJSMARzTqa1AC4HpRS0UAJRS0UAJRilooASjFLRQAmKRQMUvakXpQAuKMClooATAowPSlooA TA9KMClooATAowPSlooAbgFqXA9KP4qWgBMD0owPSlooATA9KMD0paKAEwPSjA9KWigBMD0p GHHSnU1ulAmAUY6UbR6Uo6UtACYHpRgelLRQMTA9KMD0paKAEwPSjaPSlooATA9KaqjJOKdS LQKwu0elGB6UtFAxNo9KTaPSnUUAN2j0o2j0p1FAWG7R6UbR6U6igBjKCRS7R6UHrTqBWG7R 6UbR6U6igLDdi+lG0elOooCw3aPSjavpTqKAsN2j0oKjHSnUjdKAsNWNQKXYvpSjpRTCyE2L 6UbR6U6ikFhu1fSjaPSnUUBYbtHpRtHpTqKAsN2j0poQFjkVJTV6mmDSDYvpRsX0p1FILDdi +lG0elOooCw3YPSjYvpTqKAsN2L6UbF9KdRQFiNkHFLsX0pT1FOp3CyG7F9KNi+lLRSCyE2D 0o2j0p1FAWG7F9KNi+lOooCw3YB2oKDHSnUh6UBZDBGuORS+WvpTh0ophZDdi+lLsX0paKQW QmxfSjYPSnUUBYbsX0o2L6U6igLDdg9KbtUseKkpo+8aAsGxfSk2L6U6igLIbsX0rC1ebdP5 anha2buYQW7OTzjiuWdmdyzHk80wsN5zWzo9oCpmcfSsqCMySqvqcV1UEYiiVB0AoAXYtLsF OopXCxGyDAFKIxjFK3anU7hZDNi0uxaWikFkN2Cl2CnUUBYZsFGxfSnUUBZDfLFBQYp9J2ou FkMWMYpdi04dKWncLIZsFGwU+ilcLDNi+lHlrT6SgLIb5Yo2Cn0UXCyGhB700oC1SU3+KncL ITyxR5Yp9FK4WQzYKPLFPoouFkM2CjYPen0UXCwzYPU0bB6mn0UXCyI2QYpfLHqacaWncLIZ 5Y9TRsHqafRSuFkM2D3o2D1NPoouFhmwepo8se9PoouFkM2D1NGwepp9JRcLEax5OSad5Y9T Sp0p1O4kkM2D1NGwU+ilcdhmwetGwepp9FFwsM2D1NHlj1NPoouFkM2D1NNaPJ61LSd6dwsh vl+5oCAdzT6KVwshmwepo2D1NPoouFhmwepo2e5p9FFwsM2e5o2e5p9FFwsRsmR1NAj46mnm incLIbs9zRs9zT6KVwshmz3NGwepp9FFwshmz3NLt9zTqKAsM2e5o2e5p9FAWIgnPU07Z7mn Clp3CyGbPc0bPc0+ilcLIZs9zRs/2jT6KLhZDNnuaNnuafRRcLIZs9zTWTJHJqWmn7wp3BpC bP8AaNGz3NPopXCyGbPc0u33NOooCwzZ/tGjZ7mn0UXCyGbPc0bP9o0+ii4WI2Tjqaq37eTa Mc8kYxV1ulZOtzAIkYPPU07hZGN1Nb2k2+22D5wWrCRd7gAdTXVW6COBFAxgUXAd5f8AtGjZ /tGn0UrhZEfln+8aXZ7mn0UXCyGbPc0bD/eNPoouFiIJ8x5NO2H+8aVepp1O4kkM2H+8aNh/ vGn0UrjshgQ/3jRsP940+igLDNh9TRsP940+igLFS9k8i3Z9x9q5p3LsSTya1NZud8ghB4Xr WV3phYu6Xb+fcDP3Rya3xFtGA2BVbSoFitQcfM3Jq7RcLDdh/vGjYf7xp1FAWQ3Yf7xo2H+8 adRQFhuw/wB40bD/AHjTqKAsNKnaeaaqHH3jUh6UDpRcLajdp/vUbT/ep1FILDQp/vUbD/eN OooCw3Yf7xo2H+8adRQFhuw/3jRtP9406imFiMIdx+anbD/eNKOppaLhZDdh/vGjYf7xp1FI LDdh9aTYf7xp9FMLDNh/vUpQn+KnUUrhYbtP96mupOOakpD2phYbsb+9S7D/AHjTqKVwsN2H +8aTYf71PoouFhu1v71G1v71OophYbtP96ja396n0UgsM2nHWmqjAfeqTtQOlO4WGbW/vUbW /vVJRSuFiPa2fvUpVv71PophYZtb+9RtPrTqKQWGhW/vUu0+tLRQFiPa2/rTtrf3qX+OnUxJ DNrf3qNrf3qfRSHYZtb+9Rtb+9T6KYWGbW/vUbW/vU+ikFhm1v71IykjrT6RulMLDQrAfepd rf3qdS0BYZtb+9RtPrTqKQWG7W/vUbW/vU+imFhm1v71G1v71PooCwwq396mqp5wakpF6UBY Ta396ja396n0UgsM2t/eo2t/ep9FAWGbW/vUbW/vU+igLDNrf3qNrf3qdRQFiMoxYfNTtrf3 qX+Klp3Cw3a396ja396n0UgsM2t/eo2t/ep1FAWG7T/eo2t/ep1FAWG7W/vUjKccmn0j9KYN CjpS0g6UtIYUUUUAFFFFABRRRQAUUUUAMH3zT6aPvGnUCQUUUUDCiiigAooooAKa3SnU1qAH UUUUAFFFFABRRRQAUUUUAJ2pF6Up6Ui9KAHUUUUAFFFFABRRRQAUUUUAN/ip1N/jp1ACUtJS 0AFFFFABRRRQAU1+lOpr9KBMUdKWkHSloGFFFFABRRRQAUUUlAC01adTV70AOooooAKKKKAC iiigAooooAafvCnU0/eFOoEFFFFAwooooAKKKKACmt9006kbpQADpS0g6UtABRRRQAUUUUAF FFFABTV6mnU1epoEOooooGFFFFABRRRQAUUUUANPUU6mnqKdQAUUUUAFFFFABRRRQAUh6UtI elAAvSlpB0paACiiigAooooAKKKKACmj7xp1NH3jQA6kpar3lwtvCWPXtQBk6zdb5REp4XrW XT5HMjlm5JOadbQmeVUXvTEamjWn/LdvwrZqOCMRRKg7CpKTGFFFFADW6inU1uop1AgooooG FFFFABRRRQAUh6UtIelAAvSlpF6UtABRRRQAUUUUAFFFFABSfxUtN/ioAdRRRQAUUUUAFFFF ABRRRQA1qWkbtS0ALRRRQAUUUUAFFFFABSUtJ2oAanSn0xOhp9DEgooooGFFFFABRRRQAU3+ KnU3+KgB1FFFABRRRQAUUUUAFFFFACN0paRqWgAooooAKKKKACiiigAooooAatOpBS0AFFFF ABRRRQAUUUUAFNP3hTqafvCgQ6iiigYUUUUAFFFFABRRRQA1zhTXOanL5t0fQcVv3LiOBmPY Vy0jb3LZzk0xFrTIvMu14yBzXSVk6Eg2u+3npmtehjCiiikAUUUUAFFFFADV6mnU1epp1ABR RRQAUUUUAFRzyCKJnPYVJWRrU+AIVPuaAMiZzI7MeSTU1hB51yqkcdTVc1t6RbeWgkYctVCZ qKAqgDoKWiipGFFFFABRRRQAUUUUAI33TSL90UrdDSL90UC6jqKKKBhRRRQAUUUUAFFFFADV 6mnU1fvGnUAFFFFABRRRQAUUUUAFNbqKdTW6igGOooooAKKKKACiiigAooooAQ9KF6UHpQvS gBaKKKACiiigAooooAKKKKAG/wAdOpo+/TqBIKKKKBhRRRQAUUUUAFNbpTqa3SgB1FJS0AFF FFABRRRQAUUUUAFNXpS0i9KAHUUUUAFFFFABRRRQAUUUUAN/ip1N/ip1ACUtFFABRRRQAUUU UAFNfpTqa/SgTFFLSDpS0DCiiigAooooAKKKKACiiigBo+8adTR9406gSCiiigYUUUUAFFFF ABTTTqa3agB1FFFABRRRQAUUUUAFFFFACGhelB6UL0oAWiiigAooooAKKKKACiiigBv8VOpv 8VOoAKKKKACiiigAooooAKZJ92n01xkUCYo6UtIOlLQMKKKKACiiigAooooAKavenU1e9ADq KKKACiiigAooooAKKKKAGn74p1NP3qdQAUUUUAFFFFABRRRQAU1ulOprfdNACjpS0g6UtABR RRQAUUUUAFFFFABTF+8afTF6mgQ+iiigYUUUUAFFFFABRRRQA09RTqaeop1ABRRRQAUUUUAF FJS0AFIelLSHpQAL0paRelLQAUUUUAFFFFABRRRQAUwfeNPpg+8aBDu1YGrXfnS+Wn3V6/Wt TUboW8BwfnPAFc2SSSTyTQMStvRrXCee3U9BWVawGeZUHc811ESCONUXoBTEPooopDCiiigB rdqdTH6in0CCiiigYUUUUAFFFFABSHpS0h6UAC9KWkXpS0AFFFFABRRRQAUUUUAFN/ip1NH3 qAHUUUUAFFFFABRRRQAUUUUANanU1qWgBaKKKACiiigAooooAKTtS0nagBqdDT6anSnUCQUU UUDCiiigAooooAKb/FTqb/FQA6iiigAooooAKKKKACiiigBG6UtI3SloAKKKKACiiigAoooo AKKKKAGrTqatOoAKKKKACiiigAooooASmn7wp1NP3xQJj6KKKBhRRRQAUUUUAFFFJQBn6zNs ttg6tXP9TV/VpxNcYB4XioLGETXSKemcmmI39Oi8q0QdyM1apqgKoA6CnUhhRRRQAUUUUAFF FFADV6mnU1epp1ABRRRQAUUUUANkYIhY9AK5i7naaZn7HpWxq8/lwbB/F1rBpoCS1iM9wqe9 dOihAqjsKzNEgG1piOegrVP3hQIdRRRSGFFFFABRRRQAUUUUAI3ShegobpSL90UC6jqKKKBh RRRQAUUUUAFFFFADR1NOpi/eNPoEgooooGFFFFABRRRQAU1uop1NbtQA6iiigAooooAKKKKA CiiigBD0oHSg9KF6UALRRRQAUUUUAFFFFABRRRQAz+On0z+On0CQUUUUDCiiigAooooAKa3S nU1ulADqKKKACiiigAooooAKKKKAENIvSlpF6GgB1FFFABRRRQAUUUUAFFFFADf4qdTf4qdQ AUUUUAFFFFABRRRQAU1+lOpr9KBMUUtIKWgYUUUUAFFFFABRRRQAUUUUAMH3zT6aB8xpaBIW iiigYUUUUAFFFFABTW7UtIwoAdRRRQAUUUUAFFFJQAtFJRQAHpSL0pT0pFHy0CHUUmKWgYlL SUUALRRRQAUUlFACfx06m4G6loEFLSUUDFopKWgAooooAKa/3adTX6UCYo6UtIOlLQMKKSig BaKKSgBaKSigApF70tNUdaBD6KSloGFFJRQAtFJRQAtFJRQA0/fFPphHzg0+gSCikooGLRSU UALRSUUALTW+6aWkbpQAo6ClpAOKKAFopKKAFoopKAFopKMUAFNX7xp1MUYY0xElFJRSGLRS UUALRRSYoAKWkxRQAjfeFOpjD5hTqBC0UUlAxaKSigApaSigBaQ9KKD0oAF6UtNXpS0ALRSU UALRSUUALRSUUAFMzgtT6zdUufIjKKfmfimhMy9QuDcXLHsOBVUdcUZq1p1sbi4AP3RyaANb SbXyoA7D5mrRpqqFUAdBS0hi0UUlAC0UUUANbqKdTGzkU6gQtFJRQMWikpaACiiigApD0ooP SgAHSlpq9KWgBaKKKACiikoAWikooAWmj7xpaQfeNADqKSloAKKSigBaKKSgBaKSigBG7U6m t2paBC0UlLQMKKKKACikooAWk7UtIaAGx9DT6YnQ0+hiWwUUlFAxaKSloAKKSigBab/FS0n8 dADqKSloAKKSloAKKKKACiiigBrdKWkbpxS0ALRRRQAUUlFAC0UUUAFFFJQAi96dTV70tAC0 UlLQAUUUUAFFFFABTD98U6mNneKBMkopKWgYUUUlAC0UnNFAC1BeS+TbO+eQKmrG1qfpEG9z QBksxdyT35rZ0W2wpmYcnpWRDGZZVQdSa6m3jEUKoOwpiJaKSikMWiko5oAWikOaOaAFopOa OaAEXqadTVzk0tAkLRRRQMKSioL2bybdm79BQBiapMZbkjPC8CqiKXcKOSTQ5yST1q7pEBlu N5X5V70xG3awiCBUHYVIfvClpDncKQDqKSigYtFJS0AFFFFABRRRQA1vumhfuihuhoX7ooF1 HUUUUDCikpaACiiigAopKKAEX7xp1MX7xp1AkLRRRQMKKKKACikpaACmt2p1NbqKAY6ikpaA CikooAWikpaACiikoAD0pF6Up6Ui9KAHUUlGaAFopKKAFopKKAFoopKAE/ip1Mz89OoEhaKK KBhRRSUALRSUtABTW6UtI3SgB1FIKKAFopKKAFoopKAFopKWgBKRelLSL0oAdRRSUALRRSUA LRSUUALRRSUAJ/FTqb/HS0CFopKKBi0UlFAC0UUUAFNfpTqY/SgTHClpB0paBhRRRQAUUUUA FFFFABRRRQAzOHp1MZdze1L5Y9TTFqOopvlj1NGweppBqOopuwepo2DPU0BqOopuwe9Hlj1N MNR1IxpNnuaRo8jqaAdx+aKb5Yx1NGwepoDUdRTdg9TRsHrSDUdRTdg9TQEwetAajqWm7Pej b7mgBaRelIV46mkVOOtMCSim7Pc0mz3NIB1FN2e5o2e5phqPopmz3NGz3NIB9FMKe5o2e5oA X+KlqNkJbrS7Dj7xphdj6KZ5Z/vGl2H+8aAux9FM2e5o2+9IB9FM2n1o2n1oAfTW6Um0+tI6 kr1pgx4opixkD71LtPqaAux9FM2H+8aNp9aQXH0UzYf71G0/3qAuPopm0+tG0+tAXHUi96Np 9aYFYsTmmFyWimbT/eo2n1pBcfRTNp/vUbT60BcdS0wqfWjafWmFx9FM2nPWjafWkFxT94U6 onUkjml2n1piuSUUza3rRtPrSHcdS0za396jafWgLjqKbtb+9Rtb1oC46g9Kbtb1pGDbTzTC 48dKWo1VsdaXa396gLj6Sm4b1ow3rSC46im4b1ow3rQFx1FJg+tJhvWgLjqRepow3rTArbjg 0wbJaSm4b1ow3rSC46im4b1ow3rQFx9FMw3rRhvWgB9FMIb1oAb1oC4p6ilqNt2RTgH9RTFc fRTMP60Yb1pDuOopuG9aMP6igLj6KZh89RR83qKAuPpD0puG9RQd2KAHDpS1EoftjFOw/qKY XHUU35vUUfP6ikFx1FNw3qKXDetAXFoppDetHz+ooC4rEKpJ6CuZ1Ccz3DN1A4Fa2q3LQwFM 8vxxWATzTAVQScV0WmWv2eDLfebk1kabbmecccLzXQgOOOKAH0U3D+oo+f1FILjqKb83tS/N 7UBcWik+aj5vagLg3UUtMfdxSjfTC46im/N7Uvze1ILi0Unze1Hze1AXFopvze1L83tQFxaK blvQUHdjtQFxw6UVGu/FO+b0pgmOopPm9qPm9qQC0tN+b2pDv9qAuPopnze1L83tQFxaO9J8 3pTTu3cUBckopmX9BRl/QUBcfRTMt6CjL+goC46iky3pRlvSgLi0UmW9KMt6UADU6o3LY6Uo L46UwuPopmX/ALooy3oKQXHUUmW9KMt6UBcWim/N6Cly3pQFxaKTLelBLY6UBcF6U6oULDPG aflvSmJMfRTMt/doy392kO4+imZb0oy392gLj6KblvSky392gLjqO9Jk/wB2mEtu6UwuS0Uz Lf3aMt6UguPopmW9KMt6UBcdRSZb0pMt6UBcdRSZb0oy3pQFxTRTWJx0pAzf3aYXH0U3Lf3a XLelILjqKZlv7tLk+lAXFopuW9KMt/doC4+im5PpRk+lAXFFLUYY56UuW/u0BcdRTdzf3aXJ 9KAuLRTct6UuT6UBcWikyf7tG4+lAXHU0/eFGT6Ux2IYcUwbJKKbub+7Rub+7SC4+im7j6UZ PpQFxaKTJ9KTc392gLiSyCKNnY4Arl7mQzTM57mtPWLr5RD0PU1lwRmaQIvJNMLmjpFtnMzD jtW2OlQQRmG3WMDoKlVmxytDEmOopu4/3aXcf7tIdx1FNyfSjcf7tAC0U3cf7tG4/wB2gLj6 KZuP92lyfSgLgO9OqMMcninbj/dNOwXFopu4/wB00bj/AHTSC4+sXWZ9ziMc7eTWpJKURmI6 CuZnkMkrOT1NOwXI+/vXR6Zb+TbAnq3NYVnCZp1UDI710ykqoAXpQBJTT1FJuP8AdNIzEEcU guPopu4/3aNx/u0BcfRTdx/umk3H0oC4+im7j/dNG4+hoC46im7j/dNG4+hoAU9KB0prNx0N IrkjpTC+pJRTNx/uml3H0NILjqKbuP8AdNG4/wB00BcdRTd3saNx9DQFx1FM3H+6aXd7GgLg Opp1R7sE8U7d7GgLjqKbu9jRu9jQFx1FN3exo3exoC46imb/AGNG4+hoC4+mntRu9jTWfHY0 wbJKKYHyPumjd7GkFx9FN3expN/+yaAuPopu72NG72NAXHUU3d7Gjd7GgLimgdKQtx0NNV+2 DQFySimb/Y0b/Y0BcfRTd3saTf7GgLj6Kbu9jRu9jQFx1FN3+xo3exoC4fxU6oi+H6U7f7Gn YE0Popm/2NLu9jSC46im7vY0b/Y0BcdRTd3saTf7GgLj6a3Sk3j0NDNx0phcfRTA/HQ0b/Y0 rBcfRTN/saXd7GgLjqKbu9jSb/Y0BcfRTd3saN3saAuOpq9KN3saardsUBckopu72NG72NAX HUU3d7Gjd7GgLjqKbu9jRu9jQFx1FN3exo3DPegLh/FTqjL4bpxS7x6GiwXQ+imF8djS7vY0 BcdRTd3saN3saAuOopu/2NG72NAXHU1+lG/2NNduKYNjx0paQdKWkMKKKKACiiigAooooAKK KKAGj7xp1NH3qdQAUUUUAFFFFABRRRQAU1qdTW7UAOooooAKKKKACkpaKACiiigBD0pF6Up6 Ui9KAHUUUUAFFFFABRRRQAUUUUAN/ip1N/ip1ABRRRQAUUUUAFFFFABTW6U6mv0oBi9qWkHS loAKKKKACiiigAooooAKavenU1e9ADqKKKACiiigBKWiigAooooAafvCnU0/eFOoAKKKKACi iigAooooAKQ9KWkbpQADpS0g6UtABRRRQAUUUUAFFFFABTV6mnUxepoEPooooGFFFFABRRRQ AUUUUANPUU6mnqKdQAUUUUAFFFFABRRRQAUh6UtIelAAOlLSDpS0AFFFFABRRRQAU1mCqWPQ U6svWLvy08pD8zdaAMvULr7TcE/wjgVWHOMcmkPWrunWhuJQeiryTTQjY0uDybUZGGbk1dpF GAB6UtIYUUUUAFFFFABRRRQA1u1OprdqdQAUUUUAFFFFABRRRQAUhpaQ9KAAdKWkXpS0AFFF FABRRRQAUUUUAFN/ip1NH3jQA6iiigApKWigAooooAKKKKAEaihqWgBKWkpaACiiigAooooA KSlpKAEXpTqanSnUCQUUUUDCiiigAooooAKb/FTqb/FQA6iiigAooooAKKKKACiiigBD0paR ulLQAUUUUAFFFFABRRRQAUUUUANWnU1adQAUUUUAFFFFABRRRQAU0/eFOph++KBD6KKKBhRR RQAUyaQRRM56AU+sbWbs58hTx3oAy7mUzTs57mtTRbbrO30FZUERnlWNepNdRbQiCFUHYUxE p6UChulApDFooooAKKKKAEpaSloAKKKKAEFLTV6mnUAFFFJ2oAz9XnEdvsBwWrA47Vc1KYy3 TAn5V4FVY13uqjucUxGxolvtVpj34Fa1Q2sQhgVB2FTUmMKaeop1NPUUAOooooAKKKKACiii gAooooARulC9KG6GkX7ooEOooooGFFFFABRRRQAUUUUANHU06mj7xp1ABRRRQAUUUUAFFFFA BTT1FOprdqAHUUUUAFJS0lAC0UUUAFFFFACHpQOlB6UL0oAWkpaKACiiigAooooAKKKKAG/x U6mfx0+gSCiiigYUUUUAFFFFACUjdKdTW6UALS0lLQAUUUUAFJS0UAFFFFACUi9KWkXvQIdR RRQMKSlooAKKKKACiiigBuBupaT+KnUCEpaKKBhRRRQAUUUUAFNfpTqa/SgTFHSlpB0paBhR RRQAUUUUAFFFFABRRRQAwH5yKfTR9406gSCiiigYUUUUAFFFFABTW6U6mv2oBjqKKKACiiig AooooAKKKKAE7Ui9KU0i9KAHUUUUAFFFFABRRRQAUUUUAN/ip1N/ip1ABRRRQAUUUUAFFFFA BTX6U6mv92gTF7UtIOlLQMKKKKACiiigAooooAKavenU1e9ADqKKKACiiigAooooAKKKKAGn 7wp1NP3hTqBBRRRQMSlpKWgAooooAKRulLTW6UAKOlLSL0FLQAUUUUAFFFFABRRRQAUxPvNT 6Yv3jTEx9FFFIYUUUUAFFFFABRRRQA09RTqafvCnUCCiiigYUUUUAFFFFABSHpS0h6UAIv3R TqavQU6gAooooAKKKZI4RCzHAFAEN5dLbRFm69q5qaVppWdzyalv7prqYnPyjoKrAZNADkQy OFUZJrpbCAQRBcc45qppFj5a+dIPmPQVpr940xD6KKKQwooooAKKKKACiiigBj9RT6a3anUC CiiigYUUUUAFFFFABSHpS0h6UAIvSnU1elOoAKKKKACiiigAooooAKaPvU6m/wAVADqKKKAC iiigAooooAKKKKAGtTqa3aloAWiiigAooooAKKKKACk7UtJ2oAanQ0+mp0p1AkFFFFAwoooo AKKKKACmn7wp1N/ioAdRRRQAUUUUAFFFFABRRRQA1ulLSN0paAFooooAKKKKACiiigAooooA atOpFpaACiiigAooooAKKKKAEpp++KdTT94UCY+iiigYUUUUARXEohhZ2OMCuWldpZC7dSc1 pa1dEuIV6DrWbDG00qoo5Jpga2i2wCmY4z0Fa9R28QhhVAOgqWkwEbpQKG6UCgBaKKKACiii gBKWiigAooooAavU06mr3p1ABUF5J5Vs7Drip6ytamIRY1PXk0AYzEs5J71d0mHzboMR8q1Q yc+tdBpEPl224jluaYjQooopDCmt1FOpp+8KAHUUUUAFFFFABRRRQAUUUUAI3SkX7oob7tKv QUCFooooGFFFFABRRRQAUUUUANHU06mj7xp1ABRRRQAUUUUAFFFFABTT2p1NPagB1FFFABRR RQAUUUUAFFFFACGhelB6UL0oAWiiigAooooAKKKKACiiigBn8dPpn8Zp9AkFFFFAwooooAKK KKACmt0p1NbpQA6ikpaACiiigAooooAKKKKAEpF6UtIvSgB1FFFABRRRQAUUUUAFFFFADf4q dTf4qdQAUUUUAFFFFABRRRQAU1+lOpr9KBMUdKWkFLQMKKKKACiiigAooooAKKKKAGD79OpB 96nUCQUlLRQMKKKKACkpaKAEpG7U6mt0oAWloooAKKKKACkpaKACiiigBD0pE+7SmkXpQAtL RRQAlFLRQAlLRRQAUlLRQAz+OnUn8VOoEJmiiloGJRS0UAFFFFABTH+7T6a3SgTFHSijtS0D EopaKACiiigBKKWigBKRT1p1NXvQIWilooGFFFFACUtFFABRRRQAwn5hTqQ/eFOoASilooAS iiloASilooASkbpTqQ9KABegooHSloATNFLRQAUUUUAFJS0UAJTU+8afTF+8aYmPooopDCii igAooooASloooAax+YU6mnqKdQIKKKKBhRRRQAlLSUtACUHpS0jdDQAL0paan3adQCCkpaKA EJAGTWBqt950nlxsdg6+9W9VvvLXyYz8x6n0rD6mgBM5NaelWXmyebIPlXpnvVexs2uZgMHa OprpI0WNAqjAFPYQ4DAwKQH5jTqaPvGkA6kpaKBhRRRQAUUUUAFFFFADHPSnU1uo+tOoELRR RQMKKKKACiiigBKD0ooPSgBFOVp1NXpTqACiiigApKWigBM0tFFACUgPzmnU3+KgBaWiigAp KWigAooooAKKKKAGuelLSNS0CCilooGFFFFABRRRQAUh6UtJQAiHg06mp0p1AkFJS0UDCiii gApKWigBKbn56dTSPnBoEx9FFFAwooooAKSlooAKKKKAGv0paRulLQAtFFFACUtFFABRRRQA UlLSUAIvenU1e9OoASlpKWgAooooAKKKKACmMfnFPphHzCgTH0UlLQMKjnlWKJnY8AVJWTrV wAghB5PJoAyLiXz5mkPc1paJb5ZpmHHQVlohkdVUZJNdTbRCGBUHYUxE1JS0lIYjdKUdKR+n FKOnNAhaKKKBhRRRQAlLSUUALSUUUAIp606mqOTTqBIQnArmr+XzbpzngHFbl/L5NqzDGcVz TEHJPWmMdAhkmVB3NdVCgjiVQMACsTRYd8zSMOF6Vu0MQtFFFIYU0/eFOppHIoEx1FFFAwop KKAFopKWgAooooAa33TQv3RQ33TQv3RQLqOopKWgYUUUUAFFFFABRRRQA1fvGnU1R8xp1AkF FFFAwooooAKKSloAKa3anU1hyKAHUUUUAFFFFABRSUtABRSUtACHpSL0pT0pF6UAOopKKAFo oooAKKKKACiikoAaPv0+mAfOadQJC0UlLQMKKKKACikooAKRulLSMMigTFpaSigYtFJRQAtJ S0lAC0UlFAAaROlLTUHBoEPoopKBi0UUlAC0UUUAFFFJQAn8VOpuPmpaAFopKWgAooooAKKS igBaY/Sn0xxxQhMcOlLSDpS0DCiiigAooooAKKKKACiiigBo+9TqaOpp1ABRRRQAUUUUAFFF FABTW7U6kNAC0UUUAFFFFABRRSUALRRRQAnakXpS0i9KAHUUUUAFFFFABRRRQAUUUUAN/ip1 J/FS0AFFFFABRRRQAUUUUAFNbpTqa3SgBe1LSUtABRRRQAUUUUAFFFFABTV706mjvQA6iiig AooooAKKKKACiiigBp+8KdSd6WgAooooAKKKKACiiigApD0paQ9KAAdKWkHSloAKKKKACiii gAooooAKYv3jT6avU0CHUUUUDCiiigAooooAKKKKAGnqKdTT1FOoAKKKKACiiigAooooAKQ9 KWkPSgAXpS0i9KWgAqrqFyLe3JzhjwKskhQSegrm9TuvtE52nKDgUAVHYuxYnJNS20DXEwRR UQBJwOvpXRaZaC3hDEfO3WmIsW1ulvEEQfWpqKKQwpo++adTR96gQ6iiigYUUUUAFFFFABRR RQA1u1OprdqdQAUUUUAFFFFABRRRQAUh6UtIaABelLSDpS0AFFFFABRRRQAUUUUAFJ/FS03+ KgB1FFFABRRRQAUUUUAFFFFADWpaRqWgBaKKKACiiigAooooAKSlpKAEXpTqavSnUAFFFFAB RRRQAUUUUAFN/ip1J/FQAtFFFABRRRQAUUUUAFFFFACN0paQ9KWgAooooAKKKKACiiigAooo oAavenU1adQAUUUUAFFFFABRRRQAU0/eFOpp+8KBDqKKKBjJHCIWPQCuXupTNcM+eprY1m5M UIjXq1YQBYjHemBpaLAHmMhHC9K3qqadb/Z7ZQR8x5NW6TAKKKKAEbpQKG6UCgBaKKKACiii gAooooAKKKKAGr1NOpo70MwVSx6CgDI1ubJWMHpyayMVNdymWd26jNFpH51yi9s0xG7pcXl2 i5HJ5q7TVG1QB2p1IYUUUUAFNPUU6kPUUALRRRQAUUUUAFFFFABRRRQA1vumhfuihvumhfui gXUdRRRQMKKKKACiiigAooooAaOpp1NHU06gAooooAKKKKACiiigApD2paa3agB1FFFABRRR QAUUUUAFFFFACHpQvSg9KB0oAWiiigAooooAKKKKACiiigBn8dPpn8dPoEgooooGFFFFABRR RQAU1ulOprdKAHUUUUAFFFFABRRRQAUUUUAFNXvTqavegB1FFFABRRRQAUUUUAFFFFADf4qd Tf4qdQAUUUUAFFFFABRRRQAU1+lOpr9KBMUdKWkHSloGFFFFABRRRQAUUUUAFFFFAETkhsqM ml3P/dpw+8aWncVhoL+lGW9KdRSCw3LelGW9KdRQFhuW7CjLf3adRQFhoZvSkYnHSn0jUwsI Gb+7RlvSnUUBYblvSly3pS0UgsNy3pSBmz92n0UBYblvSjLelOooCwmT6U0E46U/tQvSmFhu 4/3aNzf3adRSCw3c392jc392nUUwsN3H0o3H+7TqKQDdzf3aNx/u06igLEZYhulO3H+7S/xU 6mFiPef7ppdx/u06igLDdx/u0bj/AHTT6KQWGbj6Ubj/AHTT6KAG7j/dNNdiB0NSU1ulMGNV yR900u4/3TTqWkFmM3n+6aNx9DT6KAG7j6Gk3H0NPooAZvP900b/AGNPooAZu9jTVc5IxUlI o60wsxN/saN/safRSAZu9jRv56Gn0lADd/saN/8AsmnUtAajd3saN/sadRQBEz4IOKdv9jSn kilphZjd/saN/sadRSDUbv8AY0b/AGNOpaAGb/Y0u/2NLRQAm72NIW46Gn0h6UAMWTjkGl8z 2NOHSimFmN3j0NG/2NOopBqN3+xpd/saWigNRu8eho3j0NPooAbvFMV/mPFSUgHJpg7ibx6G jePQ06ikGom8Ubx6GnUlACbxSbxTqKAG7xQHB9adRQGoxnxggUvmDGcGlYAkUtMNRokHvS7x 70tFINRN4o3ilooATePejeKXFFAaibxSFxinUHpQGoxZARS7xSqABTZnWKNnboBTBXKGrXey Ly0OGbrWEakuZzPOznuaYiGSQIvJJxQBe0mAST72HyrW/uFQ2dutvAqgDOOanoYCbxRvFLRi kAm4Um4bjTqQAbjxTDUN4o3iloxSDUTeKNwpcCjAoDUTcKNwpcUYoATeKNwpcUYFADHcDFO3 rjrSOoOKdgelMWtxN6+tG8etLgelGB6Uh6ibhRvX1pcD0owPSgNRN49aN49aXA9KMD0oDUTe vrRuFLgUEDFAajFcdDxTt6+tIqADpTsD0pgribh60bh60uB6UYHpSDUTcPWguo70uB6UYHpQ Gom9fWjcvrS4HpRgelAaibh60hcBqdgelN2jd0phqLvX1o3D1pdo9KMD0pBqJuHrRvX1pcD0 pNo9KA1DcPWjcvrS4HpRtHpQGom4etG4etLgelG0elAajWYYpQ4PekZQRShQB0phrcNw9aNw 9aNo9KXaPSkGom4etLuHrRtHpRtHpQGobh60m4etLtHpRtHpQGobh60m4etLtHpSbR6UBqIr A55pdw9aRUHPFLtHpTBXDcPWl3D1o2j0o2j0pBqJuHrRuHrS7R6UbR6UBqGR60m4etG0elGx fSgNRdw9aaWANLtHpSFQWphqLuHrRuHrRtHpRtHpSDUXcPWjcPWjaPSjaPSgNRNw9aXcPWk2 j0o2j0oDUXI9aMj1pNo9KNo9KA1BmAHWgMMdaRlGPSl2DHSmGou4etGR60m0elG0elINQ3D1 pcj1pNo9KNo9KA1FyPWjI9aTaPSjaPSgNRcijI9aTaKXaPSgNRoYZIzTsj1pqoMk0uxfSmCu G4etLuHrSbF9KNo9KQai5HrRketJtHpRtHpQGou4etG4etJsHpRsX0oDUXI9aazgMOaXaPSm soJApoHcduHqKCwA60bF9Kq6hIsFszY56CgNTE1KbzrpiM4HApdOg865G7oOTVRjk5PU1vaP bbIN7dWoA0RgDANLketJsX0o2L6Ug1FyPWkyPWjYvpQEUdqA1BiMdaARjrSMgx0oCDFMNR2R 60ZHrSbF9KNg9KQai5HrRketJsX0o2L6UBqGR60uR603YvpS7F9KA1FyPWjNJsX0o2D0oDUQ MMnmqmpziO1YAjLcVaEY5zWHq0wafYvRaYK5nnrzWrokS7mkPUcCsvG4iulsoFjtkGOcUwLA I9aXI9aaEWl2L6VIai5HrRketJtHpRtHpQGouRTWYAil2D0pGUHA7Uw1HZHrRketNEajtRsX 0paBqOyPWjIpNi+lGwelAai5ozSbB6UbRQAuaMik2j0o2D0oDUCeKFIIpCowaFQYphrcdRmm 7B6UuwUg1FopNgo2D0oDUWim7BS7BQGouaKbsWl2jFAaiAjJp2aZsBNO2CmGouRRTdgo2CkG o7NGabsFGwUw1HZozTdgpdgpBqLmkYjik2CkZBTB3H5opojGO9GwUg1HZozTdgoMYNMNR1FN 2Cl2CkGouaKTYKNgoDUU0gIIpNgxSLGOtMNR9FN2Cjyx70BqOopuwe9GwUg1HUU3YKXYKA1F opuwUuwUAJkb6dUZQF6dsHvTErjqKbsHqaNg9TSHqOopuwe9Gz3NAajqKbsHqaNg9TQGo6kb pSeWPU0jIMUw1H0U0IB60bB6mkGo6immMH1o2CgNR1FN2D3o2CmGo6im7BijYPekGo6kXFGw e9NVBimGo+ik2D1NJsHvSDUdRTdgo2CgNR1FN2D3o2D3oDUdRTdg96XYPegAz89LTCmWFLsH vTDUdRTdgo2D3oDUdRSbBSbBSAdRSbB70mwe9ADqa5wKXYPemSLgcU0DvYkHSlpB0paQwooo oAKKKKACiiigAooooAaPvGnUwH5zT6BIKKKKBhRRRQAUUUlAC01u1OpjnigTH0UlLQMKKKKA CkpaSgBaKKKAENIv3aU9KRfu0AOooooASlpKKAFooooAKKKKAG/xU6m/xU6gAopKWgAooooA KKKKACmt0p1Nf7tAMUdKWkHSloAKKKKACiiigAoopKAFpq96WkXvQA6iiigAooooAKKKKACi iigBp+8KdTT94U6gQUUUUDEpaKKACiiigApD0paRulAAOlLSDpS0AFFFFABRRRQAUUUUAFNX qadTF+8aBD6KKKBhRRRQAUUUUAFFFFADT1FOpp6inUAFFFFABRRRQAUUlLQAUh6UtIelAAOl Y2tXeT5CkeprSuZ1gt2dj24rl5XaR2Zjkk0ANzWro1sWkMx+6OlZkMRllCL1NdTaQiCBUHbr TET0UUUhhRRRQAU0feNOpq/eNAh1FFFAwooooAKKKKACiiigBrdqdTW7U6gAooooAKKKKACi iigApO1LSHpQADpS0i9KWgAooooAKKKKACiiigApv8VOpo+8aAHUUUUAFFFFABRRRQAUUUUA I1LSNS0AFFJS0AFFFFABRRRQAUlLSUAIvSnU1elOoBBRRRQAUUUUAFFFFABTf4qdTf4qAHUU UUAFFFFABRRRQAUUUUANbpTqa3SloAWiiigAooooAKKKKACiiigBq96dTV706gAooooAKKKK ACiiigApp+8KdTT94UAx1YmuTZdYgeOprZY7VJ9K5e8lMtw7nHWgCOBDJMiDua6uNQkaqOwr A0eDzbjeeiV0VMQUUUUhhRRRQAjdKB0obpQOlAC0UUUAFFFFABRRRQAUUUUAQyuI43Y9hXMT MZJWfuTW1q02yEpnlqwj3piLWnQefdqD0HJrpQMDArK0OHEbSHqeBWtQxhRRRSAKKKKACmn7 wp1NP3hQJjqKKKBhRRRQAUUUUAFFFFACN0oXoKG6Ui/dFAh1FFFAwooooAKKKKACiiigBo6m nU0feNOoAKKKKACiiigAooooAKa3anU1uooAdRRRQAUUUUAFFFFABRRRQAh6UDpQelC9KAFo oooAKKKKACiiigAooooAb/HTqZ/HT6BIKKKKBhRRRQAUUUUAFNbpTqa3SgBaWkpaACiiigAo oooAKKKKACmr0paRelADqKKKACiiigAooooAKKKKAG/xU6m/xU6gAooooAKKKTPHWgBaKKKA CmP92n01+lAmKOlLSCloGFFFFABRRRQAUUUUAFFFFADR940tNH3zT6BISilooGJRS0UAFJS0 UAJSMM4p1NboKBC0UtFAxKWiigApMUtFABRRRQAh6UijC0tIvSgQuKMUtFAxMUYpaKAEopaK AEpaKKAG4+alpP4qdQAmKKWigBKKWigAooooASmuPlp9NfpQJijpRRS0DCkpaKAEopaKAEox S0UAJTUHWnUi96AFopaKACkpaKAENFFLQAlLRRQAwj5hT6afvU6gQlFLRQMTFFLRQAUlLRQA lI3SnUjdKAEUcCloHSloASilooASloooASloooASmqPmNPpq9TQIWilooGFFFFACUUtFACUU tFADT94UtIeop1AhKKWigYlFLRQAlFLRQAlI33TTqq304gt2bIz2oAytWuvMIhU8L1rMpXcs xJPJqS2haeZUHc0xGnotp1nf8K2cUyJBHGqDoBUlIYlFLRQAUlLRQAlNGdxp9NHU0CFopaKB iUtFFABRRRQAUlLRQAx+op1I3UU6gQlFLRQMKKKKACkpaKAEoPSlpD0oARc4paF6UtACUtFF ACUUtFACUUtFACUnO6nU3+KgBaKWigBKOaWigBKKWigBOaKWigBrZ4paQ06gBKOaWigApKWi gAooooAKQ0tIaAGp0p1IvSnUCQlLRRQMKSlooASilooASm876fTf4qBC0tFFAwpKWigBKKWi gAooooAa3SlpG6UtAC0UUUAJRS0UAJRS0UAJRS0UANXvTqavenUAJRS0UAJRS0UAFFFFACU1 vvinU0/eFAmVtSmMVoxHU8VzR5NauuSlpFjB4HJrPt4/MnRAeppjNzSITHbBj1bmr9IihECj sKdSASilooASilooAa3SlHSkbpSjpQIKWiigYUUUUAJRS0UAJQelLUNzKIoGc9hQBg6jKZLl uuBwKqoNxCgcmlkYu5J7mrekwebdBuy80xG3aReTbomBnFTUtFIYlFLRQAlLRRQAUw/eFPpp +8KBMWilooGJS0UUAJRS0UAFFFFADW+6aF+6KVuhoXpQIWkpaKBiUUtFABSUtFACUUtFADV6 mnU0dTTqAEopaKAEopaKAEopaKAEprHkcU+mnqKAFpaKKAEopaKACiiigAooooAQ9KRelKel A6UAFFLRQAlFLRQAlLRRQAUUUUAMH3zTqQfepaBIWiiigYlFLRQAlLRRQAmaRzxS0jdKBMUU UUtAwooooASilooASilooASmoeKdSL0oELS0UUDEopaKAEpaKKAEopaKAGH79OpP4qdQJCUU tFAxKMUtFACUtFFACU2Q8dKfTH6UIT2HDpS0g6UtAwooooAKKKKACiiigAooooAaPvmnU0fe NOoAKKKKACiiigAooooAKa1OprUAOooooAKKKKACiiigAooooAQ0L0oNC9KAFooooAKKKKAC iiigAooooAb/ABU6m/xU6gAooooAKKKKACiiigApr9KdTX6UCYvalpB0paBhRRRQAUUUUAFF FFABTV70tIvegB1FFFABRRRQAUUUUAFFFFADT94U6mn7wp1ABRRRQAUUUUAFFFFABSN0paRu lAAOlLSDpS0AFFFFABRRRQAUUUUAFMXqafTF6mgQ+iiigYUUUUAFFFFABRRRQA09RTqaeop1 ABRRRQAUUUUAFFJS0AJWDrM/mTCNc4XrWveTiCBnJ57VzEjtI5ZjyeaAGHrW5otsFQzHqeKy bW3a4mVFH1rqIYlhiVFHAFMRJRRRSGFFFFABRRRQAU0feNOpo+8aBDqKKKBhRRRQAUUUUAFF FFADW7U6mt1FOoEFFFFAwooooAKKKKACkPSlpD0oAF6UtIvSloAKKKKACiiigAooooAKb/FT qb/FQA6iiigAooooAKKKKACiiigBrUtI3aloAWiiigAooooAKKKKACkpaQ0AIvSnU1elOoBB RRRQAUUUUAFFFFABTf4qdTf4qAHUUUUAFFFFABRRRQAUUUUAI3SlpG6UtABRRRQAUUUUAFFF FABRRRQA1e9Opq96dQAUUUUAFFFFABRRRQAVHIdvPpUlUtSl8q3JBwTxTQmYV5L51w7dBmrW jQ+Zc7zyFrPPPWuh0iDyrUMRgtzQBfooopDCiiigAooooAa3SlHSkbpSjpQAtFFFABRRRQAU UUUAFZWtTYjWMHrya1GO1ST2rmL2YzXDt2zxQBAeTW9o8Pl228gAtWLBEZpVRepNdREnlxqv oKYh9FFFIYUUUUAFFFFABTT94U6mn7woAdRRRQAUUUUAFFFFABRRRQAjdKB0oboaF6UCFooo oGFFFFABRRRQAUUUUANHU06mjqadQAUUUUAFFFFABRRRQAU09RTqaeooAdRRRQAUUUUAFFFF ABRRRQAh6UDpQelA6UALRRRQAUUUUAFFFFABRRRQA0fep1NH36dQIKKKKBhRRRQAUUUUAFNb pTqa3SgB1FFFABRRRQAUUUUAFFFFACUi9KWkXpQA6iiigAooooAKKKKACiiigBv8VOpv8VOo AKKKKACiiigAooooAKY/Sn0x/u0ITHDpS0g6UtAwooooAKKKKACiiigAooooAaPvGlphba/N O3r60xXHUU3evrRuHrSC46im7h60bh60DuOopu5fWjcPWgLjqaaNw9aRmAFArj6KaHUjrRuX 1oHcdRTdw9aXcPWgBaKbuHrRuHrQFx1FN3D1pdw9aAA0L0pCRjrQpGOtAh1FJuHrRuHrQMWi m7h60u4etAC0Um4etG4etAC0Um4etGR60AJ/FTqZuG7rS7h60CuOopNw9aMj1oGLRSZHrRke tAC0UmR60ZHrQAtNbkUuR60jHAoExaWkBGKMj1oGLRSZFGRQAtFJketGRQAtFJkUZHrQAtNX vS5pqsOeaBD6KTI9aMigYtFJkUZFAC0UmR60ZFAC0UmaKAEPWnUwsARTsigQtFJmjNAxaKTN FAC0UlFAC0jdKKGPFAAOlFAII4NGaAFopKWgAopKKAFopKWgApi9TTqapGTQIfRRRQMKKKKA CiiigAopKWgBp6inU0kZGadQIKKKKBhRRRQAVWvbpbWEsSM9hVhjgE1zeqXTTzlc/KvSgCC5 vJrg/O3y+lVwctSc06JS0ir60AbuiW+1GlYdela1Q2qCOBFXsKloYkLRRSUDFooooAKKKKAC mj7xp1NH3jQIdRRRQMKKKKACiiigAooooAa3UU6mscEU6gQUUUUDCiiigAooooAKQ9KWkPSg AHSlpB0paACiiigAooooAKKKKACm/wAVOpO9AC0UUUAFFFFABRRRQAUUUUANbtS0GigBaKKK ACiiigAooooAKSlpKAEXpTqavSnUAFFFFABRRRQAUUUUAFN/ip1J/FQAtFFFABRRRQAUUUUA FFFFACHpRQelFAC0UUUAFFFFABRRRQAUUUUANWnU1adQAUUUUAFFFFABRRRQAVia3Nl1iHbm tpjhST2rl72Tzbl2zxnigBlunmzogxya6qNdqBR2FYWi24eYyMOF6Vv02IKKKKQwooooAKKK SgAbpQOlDdKKAFooooAKKKKACikooAp6pceTbEA/M3Fc6Tzk1e1W4864KqflXiqSIZHCDqaY GrokGS0p+grZqvZQ+RAqdxVihiQUUUUhhRRRQAUUUUAFNP3hTqQ9RQAtFFFABRRRQAUUUUAF FFFACN0NC9BQelA6UALRRRQAUUUUAFFFFABRRRQA0dTTqavU06gAooooAKKKKACiiigAprdq dTT1FADqKKKAEpaKKACiiigAooooAQ9KF6UHpQOlAC0UUUAFFFFABRRRQAUUUUAM/jp9N/ip 1AkFFFFAwooooAKKKKACmt0p1NbpQA6iiigAooooAKKKKACiiigApq9KdTV6UAOooooAKKKK ACiiigAooooAb/FTqb/FTqACiiigAooooAKKKKACmv0p1NbpQJiilpB0paBhRRRQAUUUUAFF FFABRRRQBHtDNzTti+lIPvmnUxWE2D0o2j0paWkFhNo9KTaPSnUlAxNo9KNo9KWigVg2j0pr KCKdSN2oANi46UbR6UtLQFhu0elG0elOpKBibR6UbR6UtFACbR6UbR6UtLQA0qMdKFUY6Up6 Ui9KBBtHpRtHpTqSgLCFAe1G0elLRQFhNo9KNg9KWigLCbB6UbRS0UAMKAtS7F9KATup1O4W QmxfSjaPSlopBYTYPSjYPSlooCwmwUbB6UtFAWE2L6UjqCKdTX+7TBoNgpdg9KUdKKQWE2D0 o2D0paKAsJsHpRsHpS0UBYTYPSk2CnZooCwmwUxYwSTUlIvencLITYtGxadRSCyG7F9KNi+l OooCyGmNaPLFOooCw3YKNgp1FAWGMgJApfLHvQT8wp1O4WQ3yxRsFOopBYaIx70bB706ii4W Q3yx70uwe9LRQFhuwe9DKNtOpGPFMLDVQY5pfLHvTh0oouFkN2D3o2D3p1FILCbBSbB706ig LCbB6mjYPU0tFAWE2j1NMVPmNSU1T8xpg0LsHqaTYPU06ikFhNnuaTYPU06loCwzYPU0bB6m n0lFwsN2e5o2e5p1FAWI3Tkc04R+5pSeRS07ishvl+5o2e5p9JSuOw3Z7mjZ7mn01mCqSego CxVvnEFuz7ue1cw7lmJPU1f1W7+0TbVPyL0rP2ljQNaCCrFkpa4X1pFsrggYjbmtXTdOaEiW Tr6U0hNmnHH8oJJFP2e5pVPFLRcEkNCe5oKf7Rp1FILDdnuaNnuadRQFhuz3NLt9zS0tAWG7 fc00J83U0+mg/MaYNBt9zRs9zT6SkFhuz3NG0/3jTqKAsJtPqaTafU06loCwzaf71G0/3jTq KAsRyITjmnbDj7xoY4Ip1O4rajdp/vGjaf7xp9JSHYbtPqaNp/vGnUtAWG7T6mjafU0tFAWG 7T/eo2nHWnZpCcCmFhFU+tG0/wB6lU5FLQFhu0/3jRtPrTqKQWG7T/eo2n+8adRQFhu0/wB6 ja396nUUBYbtP96k2kt1p9ID8xphYTa396jaf71OopBYbtP96gKf71OooCw3a396jDetOooC w3DetGG9adRQFhjBsdaUK2PvUrHGKWmFhu1v71GD606ikFhu1v71Lhv71LRQFhuG/vUbW/vU 6igLCYb1pMN60+kPSgLEaq2TzinYb1pUPFOpiSGYb+9Rhv71OpaQ7DMN/eow3rT6KAsMw3rR tb+9T6KAsMw396msrZHNS03+KmFhMN/eow3rT6KQWGYbHWjDf3qdRQA3DetGG/vU+koCwmG/ vUmG9adRQAxg2OtAD46049KWncLDcP6ijDetOpaQWGEP6ijDetOpaAsMw3rRhvWn0UBYZhvW jDetOooCxGA2Tg07D+tKppadwsMAf1pcN6inUtILDMP6ijDetPooCwz5/UUYf1FPpKAsUdTm aG2bkZPFc7nJrS1mffMEB4XrVO0hM1yijHWmBtaXbtFbA5ALc1ew/qKVAFQAdqdRcLDMP6ij Deop1FILDcP6ijD+op9FAWGYb1FA3+op1FAWGNvx1FKA+OopXOFpR0phYb8/qKPn9RTqKQWG /N6ij5/UU6igLDDv9RUN5K0NuzEjpVkmsXWLoMwiU5A60wsZjMWYk9TV3SoTLcbuMJVDknjr XSadbiC2Xj5jyaAJlD560/5/UUqnrS0NgkMw/qKX5/anUUgsNG/2o+b2p1FAWG/P6ij5/anU UBYT5vamsGyOlPpCeRTCwnz+1Hz+1OopBYb8/bFL83tS0UBYb83tS/N7UtFAWG/N7Uvze1LR QFhp3YPSkXfjtTm+6aF6CmFtRBv74o+f2p1FILDfn9qPn9qdRQFhvz+1Hz+1OooCw35/al+b 2paKAsRjduOKd83tSjqaWmCQ35/aj5/anUUgsN+f2o+f2p1FAWG/P7UfP7U6igLDct6CkbdT 6Q9RTCwg3+1GX9BT6KQWGfP7UHf7U6igLDfn9qPn9qdRQFhuX9BR8/tTqKAsNJbHQUil8dKe elA6UwsNy/oKTL+gqSkpBYbl/SjL+gp9FAWGZf0FGX9BT6KAsM+f2oy3oKdRQFiPLbulOy/o KUfeNLTCw3Legoy/oKdRSCw3L+goy/oKfRQFhmX9BRlvQU+igLDAX9BTXLY6VJSN0pg0NBfH Sly/oKdS0gsMy/oKMv6Cn0UBYZlvQUZf0FPpKAsNy/oKPm9qdRQFhvzY6U1S/PFSUi0wsJl/ QUZf0FPopBYZl/QUAv6Cn0lAWG5b0oy3pTqKAsNy3pS5b0paKAsMJbd0pcv6Cl/ipaAsNJf0 FLlvQUtFAWEy3oKTLegp9FAWG5b0pMt6U6igLCZb0prlsdKkpknSmgew4dKWkHSlpDCiiigA ooooAKKKKACiiigBo+9TqaPvGnUAFFFFABRRRQAUUUUAFNanU1u1ADqKKKACiiigAooooAKK KKAENIvSlPSkXpQA6iiigAooooAKKKKACiiigBv8dOpn8dPoAKKSloAKKKKACiiigApr9KdT JOlCExw6UtN3ADk0K6sMgg0DHUUmaMigBaKTNLQAUlLSUALTV70tNTvQA+ikozQAtFFFACUt FFABRRRQA0/eFOpp+9TqBBRRRQMSloooAKKKKACkbpS0jdKAAdKKB0paACiiigAooooAKKKK ACmL1NPpq9TQIdRRRQMKKKKACiiigAooooAaeop1NPUU6gAooooAKzdYuRFBsB+Zq0T0rmdT l827c54HFAFM81Yso99wg7ZquBk4Heui0yxEEYkcZcj8qYi+qgKOKU9KWkPSkMRelOpF6UtA BRRRQAUUUUAFFFFABTR9406mj7xoEOooooGFFFFABRRRQAUUUUANbqKdTW6inUCCiiigYUUU UAFJS0UAJigjilpD0oARelOpF6UtABRRRQAUlLRQAUUUUAFNH3qdTe5oAdRRRQAUUUUAFFFF ABRRRQA1qdTWp1AgooooGFFFFABRRRQAUhpaSgBE6GnU1OlOoEgooooGFFFFABRRRQAU3+Kn U3+KgB1FFFABRRRQAUlLRQAUUUUAI3Sig9KKAFooooASloooAKKKKACkpaKAGr3p1NXvTqAQ lLRRQAUUUUAFRXEghhZ2OMCpaxtauAcQqTkcmgDKmk8yVnPc1qaNbkHzW79KzII2mlVFHJNd PFGIlRAOgqhMlpaKKkYUUUUAFFFFACUClpKAEcfLSjpSP0pR0oF1FpKWigYUUUUAQ3EixQs7 cACuYlcySM7dzWtrVxhREv1NYx57UwLenQG4uRxlV5NdIAAMVQ0i38q23EcvzWhQwGqOtOpq 96dSAKSlooATFLRRQAlLRRQAU09RTqaeooAWilooASloooAKKKKACkpaKAGt900L0FK3Q0L0 FAhaSlooGFJS0UAFFFFACUtFFADR1NOpo6mnUAJS0UUAJRS0UAJS0UUAJSMORTqa3UUALS0U UAFJS0UAJS0UUAJS0UUAIRxQvSg9KB0oAKKWigBKWiigApKWigBKWiigBoHzUtNB+Y0+gSCi iigYUlLRQAlFLRQAlI44p1NbpQDFpaKKACiiigApKWigBKWiigBKRRgUtIvSgB1FFFACUYpa KACiiigBKKWigBuPnpaT+KnUCEoopaBhSUtFACUtFFABTJB8tPpr9KEJijpS0gpaBhRRRQAU UUUAFFFFABRRRQA0ffNOpo+8adQAUUUUAFFFFABRRRQAU1u1Opr9BQA6iiigAooooAKSgkDq aarq3RgaAH0UlLQAh6Ui/dpSeKga7hiX55FGO2aALFFZrazbhsAMR64p0Or28hwxKH3pXAv0 tV2vIFXcZFx9aVLqFwdsinHvTuBPRVd72BcZkX86jbUrZRnzB+FAFulrKfWow2FQketV31uQ n5IwPrQBtfx07Nc4+q3J6ED8Khe/uXHMrUAdOXUdSBUL3tvH96VfzrmGmkb7zsfxpoJ70gOi fVrZRwxb6Co/7ag/ut+VYPWk57UAbv8AbcWf9W2KX+2ov+ebVg80ozTsFzcOtx44jaq0+svI uETafXNZZBowfSiwEst1NKcu5ohu5ofuOcelRrE7/dUmmYIJyMUWC5of2tc4+8PyqB7+4c5M rCq2aMUhl6DVbiLjIYe9W01whfniyfY1kiNuyHFIVYdQadhXNg64e0X60064/aIZ+tZODngU hBHUGgDWOuSf881/OnJrZVvnjBHtWMM96U+1IDcl1pPLzGp3H1rOfUrlnz5hFU8GjFAze07U 2mYRSLlvWtauV0/H2pNzFRnrXUr90UxDqKSloAKKKKAGn7wp1NP3hTqACiiigBKWkpaACiii gAprdKdSN0oAB0paQdKWgAooooAKKKKACiiigApi/eNPpifeNAh9FFFAwooooAKKKKACiiig Bp6inU09RTqACiiigCC7lENu7k9q5ZzucsepNbOuTYRYh1PNYmeaYFrTofPu1B6Dk104GBis fQ4uXkI9q2aGAUh6UtIelIAXpS0g6UtABRRRQAUUUUAFFFFABTR9406mjqaBDqKKKBhRRRQA UUUUAFFFFADW6inU1uop1AgooooGFFFFABRRRQAUh6UtIelAAvSlpF6UtABRRRQAUUUUAFFF FABTR96nU0feoAdRRRQAUUUUAFFFFABRRRQA1u1OprU6gAooooAKKKKACiiigApDS0nagBE6 U6mp0p1AkFFFFAwooooAKKKKACm/xU6m/wAVADqKKKACiiigAooooAKKKKAEbpS0jdKWgAoo ooAKKKKACiiigAooooAavenU1e9OoAKKKKACiiigCOeQRRM57CuWnlMsrOe5rV1m6P8AqF47 k1l20JnnWMd6aA09FtjuM56dBWsfvCkgiWGJUXoBSn74oEPooopDCiiigAooooAKSlooAa3S lHSkbpSjpQAtFFFABTZGCIWPQCnVmaxcmOMRKeW60AZF1M08zOe5pbOEz3CLjjPNQHmtzRrX y4vNbq3SmI0kUIoUdBTqKKQxB3paQd6WgAooooAKKKKACiiigApD1FLTT1FADqKKKACiiigA ooooAKKKKAEboaF6ChulA6CgBaKKKACiiigAooooAKKKKAGjqadTR1NOoAKKKKACiiigAooo oAKa3UU6mnqKAHUUUUAFFFFABRRRQAUUUUAIelA6UHpQvSgBaKKKACiiigAooooAKKKKAGj7 xp1NH3qdQJBRRRQMKKKKACiiigAprU6mt0oAdRRRQAUUUUAFFFFABRRRQAU1elOpq9KAHUUU UAFFFFABRRRQAUUUUAN/ip1N/ip1ACUtFFABRRRQAUUUUAFNfpTqY/IoExw6UtIOlLQMKKKK ACiiigAooooAKKKKAGj7xp1NH3jTqACiiigAooooAKKKKACmt2p1NbpQA6iiigAprHapPpTq r3ys1s4TrigDCv72SSRgrkL04NVY7iWM5VyPxpjgqSG4NMpDNNdYuAoHynFI2rXLDhgPoKz1 Uk9CanSznkPyxNTSFcc19cN96ZuarsxZsk5PvV9NHuWGWAX6mrUGioVzK5z6CnYVzG5pDkV0 y6ZbBcbM+9VrnRomG6NimOvelYDBJPrRuI6GpJUCSMoOQDip7Gy+1yMpbbiiwypuNLW4uhRj GZD+VSx6Nbo2Wy3saLAc+AT0qRLeZxlYmx9K6eO0gi+5EoP0qYAAYAxT0FqczHpty/8Ayzx9 asLokx+86gVu/wAVOoAx10NcfNKfwFTR6Nbr97c341o0tFwsUhpdqP8Alnn8aeun2qniFfxq 1RRcLEH2S3/55J+VH2O3/wCeS/lU1FF2FiH7JB/zyT8qY9pEvKxoPXirVNf7tCbBoakMajhF H4VVvNPinQkKA3bFXc8UtFwschPbSW7YdcGogOea29eQbEf3xWIKQzp9OiQWicA8VZaCJvvR qfwqrpWPsa85q9TAiFvCDkRrn6VmavYs6+ZCvTqBWxSYzRcVjiyMHBFKfpW7qemBwZYB83cV hspBwRg0rDExxkUc0dvSk5oAfEG8wYHOa6233eSu7riuc0xd12oxkd66cDAoAWiiigAooooA afvCnU0/eFOoAKKKKAEpaKKACiiigApG6UtIelAAOlLSDpRQAtFFFABRRRQAUUUUAFMX7xp9 MX7xoEPooooGFFFFABRRRQAUUUUANPUU6mnqKdQAU12CIWY4Ap1Y+sXeF8hDyetAGZfT+fcs +cr2qFBuYADJNNPJrS0m1MswkPRaaA2LCEw2yqQAe9WaQcUtIApD0paQ9KABelLSDpS0AFFF FABRRRQAUUUUAFNH3jTqaPvGgB1FFFABRRRQAUUUUAFFFFADW6inU1uop1AgooooGFFFFABR RRQAUh6UtIelAAvSlpF6UtABRRRQAUUUUAFFFFABTf4qdTf4qAHUUUUAFFFFABRRRQAUUUUA NalpGp1ABRRRQAUUUUAFFFFABSGlpO1ADU6Gn01OlOoEgooooGFFFFABRRRQAU3+KnU3+KgB 1FFFABRRRQAUUUUAFFFFACGlpG6UtABRRRQAUUUUAFFFFABRRRQA1e9Opq96dQAUUUUAFRzy rDEzscACpKwtZui8nkq3yjrQBn3EpmmZ26k1q6LbcGdvoKy7SBp7hUHQnmupiQRxhVGABTEP pp+8KdTT94UgY6iiigYUUUUAFFFFABRRRQA1ulKOlI3SlHSgBaKKKAGswVSxOAK5q+n864Zu 2eK1tWuRFBsH3mrAPJpgS20JnnVAM5PNdRGoRAo6AVmaLbbUMzdT0rWoYgooopDGr1NOpo6m nUAFFFFABRRRQAUUUUAFNP3hTqafvCgB1FFFABRRRQAUUUUAFFFFACN0oXoKG6UDoKAFoooo AKKKKACiiigAooooAaOpp1NHU06gAooooAKKKKACiiigAprdRTqae1ADqKKKACiiigAooooA KKKKAEPShelB6UL0oAWiiigAooooAKKKKACiiigBo+8adTR96nUAFFFFABRRRQAUUUUAFNbp Tqa3SgB1FFFABRRRQAUUUUAFFFFABTV6U6mr0oAdRRRQAUUUUAFFFFABRRRQA3+KnU3+KnUA FFFFABRRRQAUUUUAFMf7tPpj9KEJjh0paQdKWgYUUUUAFFFFABRRRQAUUUUAMyNxFOqNlLNx +dLtf+9TJuPpajCv/epdrf3qB3HUU3a3rRtb1pBcfRTNrf3qNretAXHUjUmG9aaynHWmFyWi owrY+9S7W/vUBcdQeRzTdr+tJtf1oC5z+rxhLnIAANZ561payMTjPPFZ30pMaBWKHKkg1s6X qO4iKYj2JrGPHUEUqnBz3pAdhkEZFCfdrHsdSLARyHnsa1I9xXIYYqhX1JajuH2Qs3oKXa/r VTUmKWjlj7UWC5zzndIzHua1dDTLO/4VkZrf0mBltw4PLUIGaVLUeH9aUh/UUguPopmG9aTD +ophcdn5qWomVy3WnYf1FFhXH0UzD+oow/qKVh3JKKZhvWkw/qKYXJKSm4f1FJh/UUguPpHO BTcP6ikkDbeTTBvQfgHGadUKiTHUU7D+1FguVNYiMtmcDJXmuarrZo3kjZcjkVy0yeXKyN1B oC5raPdYQxEdOahutVmMpEZCqDVO0fbMADjPFRyoUmYEd6Q7m7pmoPcExyfeHetKuSt5mhlD r1FdFaXJuYwy49xTsK5bPIrMu9LS4YshCtWh8/tTVD5OKaE2c/caXcQjO3cPUVSxgkEV1c5k WFjxwK5Z+WJ7k0mNF3SAPtY56D0ro6wNFjJnZwOgrc+f2oC4+imHf6Cgb/alYLklFR/vPal+ f0FAXFP3hTqhctkU4b/QU7CuSUVH8/pR8/oKVh3H0tR/P6Cj5/QUBckoqPL+lL8/oKAuPpD0 pvzelI27HSiwXHjpRUaF8dM0pL+gp2C5JRUfz+lL8/oKQXH0UzL+lGX9KAuPopmW9KMt6UBc dSL1NJlvSmAuHPFOwmyaimZf0oy3pSHcfRTMt/doy3pQFx9FMy3pRl/7tAXH0VHl/Sly3pQF xT1FOqJy2RxSlm/u07CuMu5xbwM57dK5eaVppC7dSa0NXu/MfyRjC9azKBj4ImmlVF5JrqbW EQQKgHQc1m6Ta7V84rlj0rVy392gLjqWo9zf3aXLf3aAuOoNN3N/doJbHSgLjh0paiVmx0zT tzZ+7QFx9FMy392jLf3aAuPopm5v7tG5v7tILj6KZub+7Rub+7QFx1IPvGkyf7tN3NuPFMLk tFM3H+7Sbmz92gLj6Kbub+7RuP8AdpBcdRTdx/u0bm/u0BcdRTdx/u0bm/u0BcVuopajdiAO KUO2Pu07Cuh9FN3N/do3N/dosO46im7j/do3H+6aQXHUU3cf7po3H+6aYXH0h6UwOc/dNLuJ H3TSsFxw6UVGrnuM07ef7pp2C4+imbj/AHTRuP8AdNKwXH0UwOf7poL+xosFx9FRhyf4TS7z /dNFguPpO9N3n0NNLkN0NOwXJaKZvP8AdNIHP900rBdElFM3n+6aA5/umgLj6KYX/wBk0b/Y 0BdD6KZv9jRv/wBk0WC440tRuxxwKA+R0NOwXRJRUZf2NKHz2NKwXQ+imb/Y0b/Y0BcfRTN/ tRv9jQFx9JTd/wDsmjf7GiwXFQYFOqJZOvBp2/2p2Emh9FM3+xo3+xpWHdD6KZv9jQX9jRYL ofRTN/tR5nsaLBdD6b/FSb/Y00v8w44p2C6JaKZ5nsaN49DSsF0Popm/2NG/2NFguh9FM8z2 NHmexosF0Popnmexo3+xosF0OPSimM/HANAk46GnYLokoqPzPY0u/wBjSsF0Popnmexo8z2N Fguh9FM3+xo8z2NFguh9FM8z2NG8e9Fguhy0tRCTBOead5g9DTsF0PoqPzB70GUAUrBdEV7c rbQMxPPauZZi8hY9Sat6ndm4nIX7q8Uywt/PnGRlRyaaQNmrpFp5MXmsPmatKo1cAYAPFL5g 96Auh9NP3hSbx6U1pMMOKLCbRLRUfmj0NL5g9DRYd0PopnmD0NHmD0NKwXQ+imeYPejePQ0W C6H0UzzB70eYKdguhW6UtMZxt4o80ccGiwXRJTWYKpJ6Cm+YPeqOqXflwFF+81FgujKvp/Pu Gbt0FRQRNNMqLySaj5xmtXRoQGMzdeg4oQNmvEgjjVR2FSVH5g9DQJAexoswuiSimeYKN49D SsF0KO9OqJZBk5pfMFOwXRJRTPMHvR5gpWC6HUU3zBR5gp2C6HUU3zBR5gosF0PpD1FN8we9 I0gBFFguh9FM80UvmLRYLodRTfMWjzFoC6HUU3etG8Uguh1FN8xaPMX1oC6HHpQOlNLjFIsg xTsF0SUUzeKN4pWC46im719aN6+tAXQ6im+YtG9fWgLodRTfMWjetAXQo6mnVF5gDHNO3rTs F0Oopu8UeYtILofRTPMWl3iiwXQtFN8xfWjeKAuh9Ieopu9fWkdwMGiwXQ+im+YuM5o3r60B dDqKbvX1o3r60BdDqKbvX1o8xfWgLodRTd6+tHmL60BdDjQOlNLjHWkWRSKYXQ+im719aPMX 1pBdDqKbvX1o3r60BdDqKbvX1o3r60BdDqKbvX1o3r60BdC/x06ovMG/2p28U7Amh1FN3rQX WkF0Oopu9fWl3r60BdC0U3evrS719aAuh1NbpSb19aRnGODTsF0PopokX1o3r60guh1FN8xf WjevrQF0OopN4pPMX1oC6HUU3etG9fWgLodSL0o3r601ZBTsF0Popu9fWjevrSC6HUUm9fWk 8xfWgLodRTd6+tLvHrQF0Oopm9fWl3D1oC4fxU6oy4DUu9fWnYLodRTfMX1o3r60guh1FN3r 60u9fWgLoWim719aXevrQF0Opj/do3r60juCOKaBseOlLSDpS0hhRRRQAUUUUAFFFFABRRRQ A0feNOpo+8adQAUUUUAFFFFABRRRQAUhpaa3SgB1FFFABSGlpGOAaAOb1d2e6Kk9KqRANKqk 4yakvm33Uh7ZplsoadATwTQBvzadDPbqoADAcEVh3NrJbOVcEDsa6mMAIAOmKbPAk8ZSQZFM VjkgxB4q/Z6pJBhX+Zf5U+80l4svF8yenes4jBOaVh3OrguI50DIwOazNcn+VYh9TWTFK8Lh kYg1Jd3LXLKWxkDFAECLuYD1NdZbJ5cCL6CubsED3cYPrXUjgUALRRRQAUUUhIUZJwKAE/ip 1Z1xqkMLfKd59BVN9albhEVfrQBuUtYH9sT8cLUi61IPvRqfpQBt0Vlxa1E2N6lTVqO/t5CA sgyfWgC1RSAg9DS0AFNfpTqa/SgBR0paQdKWgBK5rVohHdsRzu5rpqwteQCRHA5PFAGUn3h9 a2L2zE1qsyD5wOfesiP76/WusiUGFR2xTQjkTwantbuS2fch47itPUNKLt5kAHutY7xtGxVl II9aLAdBZ6pFcYVvkf3q8hzmuQBIINX7bVJoMK3zr70hm1fPstXI9K5Un5q2bnUY7mycA7W9 DWNigDb0LO2T61sVlaEuIGPqa1aACiiigAooooAafvCnU0/eFOoAKKKKAEpaSloAKKKKACkP SlpD0oAB0paQdKWgAooooAKKKKACiiigApq9TTqYvU0CH0UUUDCiiigAooooAKKKKAGnqKju ZRDAznsKkbqKxdbudziJTwOTQBmSOZHZmOSTmpLO3NxMqD8agBrd0W2CRmZhy3SmI0okEcYR egFPoopDCiiigApD0paQ9KAAdKWkHSloAKKKKACiiigAooooAKaPvGnUxfvGgQ+iiigYUUUU AFFFFABRRRQA1u1OprdqdQAUUUUAFFFFABRRRQAUh6UtIelAAvSlpF6UtABRRRQAUlLRQAUU UUAFNx81OpO9AC0UUUAFFFFABRRRQAUUUUANYZFLQaWgAooooAKKKKAEpaKKACkpaSgBFHFL SJ0p1AkFFFFAwooooAKSlooAKbj5qdTf4qAFpaKKACiiigBKWiigAooooAaw4pcUHpS0AJRS 0UAJRS0UAJS0UUAFJS0UANAHPFLikWnUCExVDVbsQQlF++1XZHEaFmOAK5m9uDcTs5PHQUDK 4BZvUmul061FtAB/E3JrN0a03yGVhwvSt6mITFGKWikMSmsAWFPpp+8KBC4FGKWigYlFLRQA lGKWigBKMUtFADW6UoHFI3SlHSgBGwASe1c3f3BnuG9BwK2NTuPJtyB95uK50nJNMB8MZllW Ne5rp7aBYIVQdqzNFtwSZm7cCtmhgJijA9KWikAmBRilooAaAMk4pcD0pB1NOoEJgUYFLRQM TA9KMClooATA9KMClooATFIQCeRTqaeooAXaPSjApaKAEwKMD0paKAEwPSjA9KWigBMD0owK WigBpAxQqgDgUrdDQvQUCDA9KMD0paKBiYHpRgelLRQAmB6UYFLRQAmB6UYHpS0UAMAG48U7 A9KQfeNOoEJgelGB6UtFAxMD0owPSlooATaPSjA9KWigBMD0prKDjNPpp7UCDaPSlwPSlooG JtHpRtHpS0UAJtHpRtHpS0UAJgelG0elLRQA0gelCqMdKU9KB0oFYTaPSjaPSnUUBYbtHpRt HpTqKAG7R6UbR6U6igBNo9KMD0paKBkewFulO2j0o/jp1ArDdo9KXA9KWigYm0elJtHpTqKB Ddo9KNo9KdRQFhu0elIyjHSn01ulAWAIo7UbV9KdRQFhu0elG0elOooCwm0elJtHpTqKAEwP Sk2j0p1FAxMD0pqqOeKdSL0oEG0elG0elOooCw3aPSjaPSnUUBYTaPSjaPSlooGN2j0pdo9K WigBhUFulLtHpR/FTqBWG7F9BRtHpS0tAWG7R6Uu0elLRQA3aPSjaPSnUUDG7R6UjDjin01+ lAmKOlLSDpS0DCiiigAooooAKKKKACiiigBo+9TqaPvGnUCQUUUUDCiiigAooooAKa1Oprdq AHUUUUAFNcZQinU1zhSTQByd0u2d19DTIm2SK3oafeMGuHZRgZqHNJgdBa6tG7bJPk9Ca0lY MMg5Fcbmuh0e682Ly2PK0AaTcg1Qn0yG4G77reoq+elIvSqFYwZNHnD4XaV9aoXEJgmZCc4r rj0rl9QOb2TjvQA/SVzeLjtXSjpXN6ScXi10lIYtFFFACEgDJ6VhapqHmMYom+UdSO9aGq3I t7cgfebgVzaKXcDuaAHxo8rbUUk+gq2ul3RH3APqa1rC0S3UcfMRyau09hbnOHS7oD/V5/Go HtZ0HzxMPwrqqCAeoouBx5BBpOc9a6qazgmBDRj6isy50Yg5hOR6GiwFO11Ga34zuX0Nbdrq ENwo+ba3oa52WGSFiroVPvTVYqcjg0rDudfTZPu1lafqfSKc89jWo7ArkcihCew8dKWkHSlo GFYuvZzHxxW1WPr/ANyP1zQBjp98fWuot5E8tV3gnHrXJk4pyuwOdx/OgDsevSq13YxXQ+YY b1FV9Ju1lhCE/MPWtGgDnLrTZoGJVS6+oqiwIPPWuxIyKpS6dBPklcHPUU9xHNGgda1bzSPK jZ43yBzg1lDr0pWGb+iMDAwx0NalY+hMNrrnnNbFACGloooAKKKKAGn7wp1NP3hTqBBRRRQM SloooAKKKKACkPSlpG6UAA6UtIOlLQAUUUUAFFFFABRRRQAUxepp9MXqaBD6KKKBhRRRQAUU UUAFFFIeKAILuYQRFz2rmJpDLKzt1JzWhq955snlJ91eprN60xEltC08yoveuphQRxKg7Cs/ R7QRx+cw+ZuntWpQwCiiikMSloooAKQ9KWkPSgAXpS0i9BS0AFFFFABRRRQAUUUUAFMH3zT6 YPvmgTH0UUUDCiiigAooooAKKKKAGt1FOpj9RT6BBRRRQMKKKKACiiigApD0paQ9KAAdKWkX pS0AFFFFABRRRQAUUUUAFJ/FS0n8VAC0UUUAFFFFABRRRQAUUUUANbpS0jUtAC0UUUAFFFFA BRRRQAUnalpKAETpTqanSnUCQUUUUDCiiigAooooAKb/ABU6m/xUAOooooAKKKKACiiigAoo ooAa3SlpG6UtAC0UUUAFFFFABRRRQAUUUUANXvTqaveklcRxs7HAAoAzNaudkfkr1brWNEjS yqi8kmpLuc3E7Ofwq/olvuczMBgcCmI1raFYIVRRj1qaiikMKKKKACmn7wp1MP3hQJj6KKKB hRRRQAUUUUAFFFFADW6UucDJpG6VV1G4EFsefmbgUAY+pXHnTnnIHAqtFG0siooyTTCQTWpo tvukaU/w8CmI17eIQwqgGMCpaKKQwooooAKKKKAGjqadTV6mnUAFFFFABRRRQAUUUUAFIetL TT1FADqKKKACiiigAooooAKKKKAEbpSL90UrdKF6UCFooooGFFFFABRRRQAUUlLQA0dTTqaO pp1ABRRRQAUUUUAFFFFABTT2p1NbqKAHUUUUAFFFFABRRRQAUUUUAIelA6UHpQOlAC0UUUAF FFFABRRRQAUUUUAM/jp9M/jp9AkFFFFAwooooAKKKKACmt0p1NbpQA6iiigAooooAKKKKACi iigApq9KdTV6UAOooooAKKKKACiiigAooooAT+KlpP4qWgAooooAKKKKACiiigApr9KdTX6U CYo6UtIOlLQMKKKKACiiigAooooAKKKKAGj71Opo+8adQAUUUUAFFFFABRRRQAU1qdTWoAdR RRQAVFcNshZvQVLVe+BNrJj0oA5WQ73ZiepqS3tXuSQhGQM4qIitPRDiZgB1oQGa6MjFWBBH anQSvBIHQ4Irc1LTvOBkiGHHX3rBZSrFWyDQ0B0tlepcwjJAcdRVtDlRXIxytG2VJBrdsdUj kURyHaw7nvQBpGub1Uf6a30rohIpGQRXO6vn7afpQA3TCv2xM10wrlbEkXUZz3rql6CgBaSl pDQBga3JvuQnZRTdHhEl1lhkKKj1Rl+2vjNWNDbEzj1FMDbHD0+mD79PpMSEpaSloGFFFNZg oyTgUARXNtHcptcfj6VgXthJanJ+ZOxro0lR/usD9DRJGsqFXAINNMLHIj171p2N/sHlSHjs ah1CyNtJlQSh6H0qn0PBoEdchDKCOlOrK0m88xPKdvmHStSkMWsnXVzCrehrWrP1lSbM4HSg DnDzSDHSlqdLVpIDKgzt6igQlrP9nmVx26109vMs8YdDkGuS5Bq7p98bWTB5Q9RQM6WkXvSI 4kQMvQihO9AEd5/x7P8ASuUPBNdVfMqWrlumK5Q9aANTQ3AuGB6kVv1gaGMzsT6Vv0AJS0lL QAUUUUANP3hTqafvCnUCCiiigYUUlLQAUUUUAFNbpTqRulAAOgpaQdKWgAooooAKKKKACiii gApi9TT6YvU0CH0UUUDCiiigAooooAKqajci3tmP8R4FWicDNc3qdz59yQPurwKAKbNk5PWr Wn2xuZwv8I5NVlXcQAOa6TTrUW0Az95uTTEWkUIoUdBTqKKQwooooAKKKKACkPSlpD0oAF6U tIvSloAKKKKACiiigAooooAKYPvmn0wffNAmPooooGFFFFABRRRQAUUUUANbqKdTW6inUCCi iigYUUUUAFFFFABSHpS0h6UAC9KWkXpS0AFFFFABRRRQAUUUUAFN/ip1N/ioAdRRRQAUUUUA FFFFABRRRQA1qWkbtS0ALRRRQAUUUUAFFFFABSdqWkPSgBF6U6mJ0p9AkFFFFAwooooAKKKK ACm/xU6m/wAVADqKKKACiiigAooooAKKKKAGt0p1NbpS0ALRRRQAUUUUAFFFFABRRRQA1ay9 ZudqCJTyetae4KpJPArmL2cz3DN1GeKYEMaGRwqjJNdRZwiC3VMYOOaydGtt8xmI4XpW7QIW iiikMKKKKACmn7wp1NP3hQJjqKKKBhRRRQAUUUUAFFFFADX4Wue1S486faD8qVtX0vlWzMOt cyx3MSetMQiKXYKOprqLKDyLZU745rG0i2MtwHI+VK6GhgFFFFIYUUUUAFFFFADV706mr1NO oAKKKKAEpaKKACiiigApp+8KdTT1FADqKKKACiiigAooooAKKKKAEbpQvShulC9BQIWiiigY UUUUAFFFFABRRRQA0feNOpo6mnUAFFFFABRRRQAUUUUAFNbqKdTW6igB1FFFABRRRQAUUUUA FFFFACHpQvSg9KF6UALRRRQAUUUUAFFFFABRRRQAz+On0z+On0CQUUUUDCiiigAooooAKa1O prdKAHUUUUAFFFFABRRRQAUUUUAFNXpTqavSgB1FFFABRRRQAUUUUAFFFFADf4qdTf4qdQAl LRRQAUUUUAFFFFABTX6U6mv0oExRS0g6UtAwooooAKKKKACiiigAooooAZ/FTqQfeNOoEJRS 0UDEopaKAEopaKAEpG9qdSGgAopaKAEqO4XfC69Mipaa33TQByEgwxHoav6McXf4VUudvnvj pmpLByt0hB70AdRVC/01LgFkAWT19avg5FLQByM9vJbuVkUj3qHOM4rrriBJ4yrrmsG40yaN iY1LL2p2uLYprNIvR2H4015GkOXOT608202cGMg/So8EHHelYdy1pq7rxB71046VhaJEWmZ8 cDvW9QAVBeXAt4Gc4yOlT1ha3cB5BEOg60AZsshllLt1Y1paHETM0mDgcVlqMkAc102nQ+Vb L8uCeTQhFgffp9N/jqK5u4rZC0jc+lAInzRWL/bhLcRfL9auW+qW8xAJ2t70XGXqydamKqEU kE+laoYEZByKwNcYG5UegoAp2szwyhlJHPNdTE++MN6iuST7w+tdXbY8hMelACzRLNGUcZBr mry3NtMUPTsa6qqWpW6zwHj5hyKaEznY3MbhlJyDXTWd0txCCDz3rlyu0kHtV/SbjyrjaThW oGdDmqeqf8eb/SrnaszW5FFuEzyTSAwK6DR4x9lJK9TWCq7mAHUmupsojFbIp5IFMRlapp2z MsQ47j0rJIwa7FlDAgjINYWpaa0bGSFSVPUDtRuBVs7+W2IAJKehrftbmOZMqwye1cuBg81I kjxOGRiCKBm/qozZtwTXNmtOTUjPaNHJ97HUVmd6QG1oQ4c1sVmaGB9nbHXNalNgITRS0UgE zRS0UAMJ+cU6kP3qdQISilooGJRS0UAJRS0UAJSN0p1IelAAOlFA6UtACUUtFABSUtFABSUt FACU1Opp9MXqaBDqKWigYUlLRQAUlLTWIVST0FAFDVrsww7E+81c/wBTVi9mM9wzE8ZwKhjQ vIFHJJpgXNJt/MuAzDha6Kq1pbLbxKoAz3q1QxISloopDCiiigBKKWigApD0paQ9KAEXpTqQ dKWgAooooAKKKKACiiigApgI3Gn00feNAh1JS0UDCiiigAooooAKSlooAY/UU6kYciloELRR RQMKKKKACiiigBKCeKKD0oARTxTqRRxS0AFJS0UAFJS0lAC0UUUAFNB+anU3HzUAOooooAKS looAKKKKACiiigBrHilpG6U6gAooooAKKKKACiiigApD0paQ0ANTpT6ag4p1AkFFFFAwoooo AKKKKACm/wAVOpuPmoAdRRRQAUUUUAFFFFABRRRQA1ulLSMMiloAWiikoAKWkooAWiiigApK WkPSgDO1SfyrYqD8zcVgjsB1NW9Tl825KjovFO0q3E10C3ReaYjZ0+AQWyjHJ5NWqQDApaQw ooooAKKKKAEprHDinU0j5hQJj6KKSgYtFFJQAtFFFABSUtRXEgihZycYFAGRrFzvkESn5V61 lgFnAHWnyt5jljzk1Y02HzrteOF5NMRt6fAILZVxgnk1apAMCikMWiiigBKWkpaACiikoARe pp1NUcmloEhaKKKBhRRRQAUUUUAFNP3hTqaR8woAdRSUUALRRRQAUUUUAFFFFACN0pF+6KVu lIo4oF1HUUUUDCiiigAooooAKKSigBB1NOpoHzGnUAFFFFABRRRQAlLSUtABTW6inU1hkigB 1FJS0AFFFJQAtFJS0AFFFFACHpQvSg9KF6UALRRSUALRSUtABRRRQAUUlFADf46fTMfPTqBI WiiigYUUUUAFFFFABTW6UtIwoBi0tJS0AFFFFABSUUUALRSUUABpF6UtIo4oAdRSUtABRSUU ALRSUtABRSUtADf4qdTcfNTqACikooAWikooAWiikoAWmP0p1NcZFCExw6UtIOlLQMKKKKAC iiigAooooAKKKKAIy2Gpd/saUfepaYhu/wBjRv8AY0+ikA3f7Gk3+xp9FADd/saQv7Gn0UAM 3+xoZsDpT6a1ACb+Oho3+xp1LQAzf7GmvJhTwelS1HL/AKtselAHKXJ3TOc9TTYpPLkDDsaJ wRK2fWozgUhnSWuqQzYU/K3vV0SA9jXHhiCCMg1pWWqyRuFlOU/lTuFjfL8dDTVfjoaI5Ulj 3IQQaevSmLUp6g6raucYOOtc3361v622LXA7mufUZYCkwN/SB5dtk960fMHoajtUVLdAvTFT Uw1IpJlRSzZAFcvdSCW5dx0J4rp7td1s49q5IjDEUmNF3TIBLcAtyB6V0auAAMGue0qcRXID EANxXRjBFO4iJ5Qpz2rnNQmM9wx3EgdK6G7GYn9cVyrj5qGCEHFKDinwRrJIELhc9zUtxYyw DJG5f7wpJDJLbUJoOA+V9DUF1M1xKXPBNRAEGlVS7AAZNAE9jH5lwoxnmunR1CgAcVQ0qyES eY4+Y1pYFMWo3zBTZGBWpMU2T7tCB3sc3qEPl3BI6NzVeI7ZFI9a1dcUBYyKyE+8KbBHVxzA xKT6VgarcCa6IHReK24jts19lrmJm3SsT1zSAt6dD5lwCeg5NdEJFArm7K9Foj4XLnpV601c vIEmUAHvRcLM194pC605SGAIwRS4oDUzL3T4p8vH8r/oaxp7aSFsMK6zAqMwxuCHUGndC1OW WF2XcB8o6mo8c11UsEa27qigDFcs3DEe9IZtaI4WJgfWtTetYGiyEXRXsRXQ4FAajfMWjeKd gUYFAaibxQGBpcCjApBqMLjIp28etIQCwp2B6Uw1E3ijeKXA9KMCkGo3euetLvFLgelGB6UB qJvX1o3r60uB6UYHpQGom8etIWGODTsD0pGAIoAQOMUb19aVVAHSjaPSmGob19aN6+tLgelG B6Ug1E3D1o3L60uB6UYHpQGom4etG4etLgelGB6UBqJuX1pocZPNPwPSmqoyTimGou9fWjev rRtHpS4HpSDUTcPWjcPWlwPSjA9KA1E3r61Q1W5CW5RT8zcVf2j0rndWmEl0VUcLxTDUpEc1 p6NEDKXcdOlZgHNdNp8IjtUHUkZoAnZwCKdvX1pGUEjil2j0o0DUN6+tG4etG0elGB6Ug1Dc PWjcPWjaPSlwPSgNRNw9aNw9aNo9KNo9KA1DcPWgsMdaXaPSkKjHSgNRA4x6Uu4etIEHpS7R 6U9A1DcPWjcPWjaPSjaPSkGobh60bh60bR6Uu0elAahketJuHrS7R6Um0elAai7h603cMnml 2j0pu0FjxTDUduHrRuHrRtHpRtHpSDUXcPWjI9aTaPSjaPSgNRcj1oyPWk2j0o2j0oDUNw9a XI9aTaPSjaPSgNRGYDFLuHqKa6ZxilEajtT0FrcdketGR60mxfSjYvpSHqLketG4etJtHpRs HpQGouR60ZHrSbR6UbF9KA1FyPWgmkCL6UFR6UBqAYY60uR600IMdKXYPSmGouRRketJtFG0 elINRcj1oyPWk2ijYPSgNRcj1oyPWk2L6UbB6UBqLmk3DdRtHpTfLBb2phqPyPWjI9absX0p dg9KQai5HrRketJsX0o2LQGouRRkUm0UbRQGotGRSbRRsFAagxApcimsoIoCAUw1HZopuwUb BSDUdmik2CjaKA1FzRmk2CjYKA1FzRmk2CjYMUBqCkEUuRTFQYpdgpgrjs0ZpNgo2CkGotFJ sFGwUBqLRmk2CkKA0BqOpCQDQEAppTJ9qYO4+im+WPejYKQajqKTYKNg96A1FzRSbBSbB70B qOopuwe9LtFAainpRTWXjrQEGOpphqOopNg96TYKQajqKb5Y96NgoDUdRTdgo2D3oDUdUN1M IYGYnHHFSbB6msjWJQGEQz6mmGplOdzEk8k1vaPCI7bcRy1Y1rB59wqD15rpUhVECjoKAJKK aIx70bB6mgNR1FN2D3o2D1NINR1FN2D1NHlj3oDUdSEjcKTYPU01kyRimDuSUU3yx6mjYPU0 BqOopuz3NGweppBqOopuwepo2D1NAajqyNauOkKn3NabqFQsScCuaupfNmdu2eKYEXWt/Sbf yrfeR8zViWsRmnVcV00cQVAuTxQFySim+WPU0bPc0g1HUU3YPU0bB6mgNR1FN2e5o2e5oDUf RTdnuaTZ7mgBQaWmBOTzSlM9zTC7H0UzZ7mjZ7mkA6im7Pc0uz3NAajqKZs9zRs9zQA6kJGR SbPc0jJkjmmDuPopoj9zRs9zQGo6im7Pc0bPc0g1H0UzZ7mjZ7mgB9FM2e5o2e5oAcelA6U1 l+XqaRU46mmGpJRTNnuaNnuaQD6KZs9zS7fc0AOopu33NJs9zQA+kpuz/aNG33NACjqaWmbP mzk0uz/aNME2Popmz3NGz3NIB9FM2e5o2+5oAdS0wJ7ml2+5oAWkPUUbfc01kzgZpgSUUzb7 mjafU0gH0UzafU0FD/eNAXH0UzYf7xo2n+8aAH0UzafU0bT/AHjQA49KB0pu0460gQ4+9TC4 +im7D/eNAU/3qQXHUU3Yf7xo2H+8aAH0Uzaf71G0/wB40BcfRTNp/vGjaf71AC/x0tRFCX60 /af7xpiTHUU3af7xo2n+8aQx1FN2n+9RtP8AeoAdRTdh/vGjaf71AXH0h6U0Kf7xpGU460wu PopoU4+9RtP940BcdRTdp/vUbT/eNILjqKbtPrSFG/vUwuSUUzaf71G0+tILjqQdKTafWkVT 60wuPopu0/3qNp/vUgH0lN2n+9RtPrQFx9FM2n+8aNp/vGgB9FN2n1NG0+tAB/FTqiKnd1p2 0/3qYXHUtM2H+8aNp9TSAfRTQp9aNp9aAHUU3afWk2n+9QA+mv0o2n1prA45NMGPHSlpB0pa QwooooAKKKKACiiigAooooAaPvGnU0feNOoAKKKKACiiigAooooAKa1OprdqAHUUUUAFI3Km lpDQByl8pS6kB9agRS7BR1NXtWTZeN781UhP75M+ooAJreSA4dSBUYrrHt454grrxisPUNNa 2O5Msn8qGgI9Pu3t5QCx2HqK6SJg0YI6GuQ6Vr6ZqO3EMuMdjQBPrpPkL0xmsOP/AFi/WtnX CGgQj1rGj++v1oA62H/VL9KfTIf9Uv0p9ACMMqRXLahAYLlhzg8iuqrO1i2EtvvA+ZaAOfRt jhh25rpdPvFuo+mGHUVzJ4NWbK6NtMGxkdCKAOlZQ5IPQiub1G1a2nI/hPIroIJ0mwyMCKW4 tIrkDzVzimI5eGNndVXrmupgixbqj88YNJBZwQf6tAD61PQMovpNs5JwR9DUkGnwQ8qmT6mr dFFxWEAx0paSikMWmS/dp9QXUgihLntQhMyNbk3SImegzWdCheVVXqTTriZriUyE9a0NGtNz +cw4HSmBrKhW2CnqFrlZR+9b6117D5SK5O6XFzIPQ0DITxQDV3T4FuZGRhnjg+lQXMD28pRh 9DRYDU0e958iQ5PatmuORijBlOCK6HTL/wC0LscgOP1pAaFIvel7U1O9AhXGUI9q5O5XZO6+ hrrT0rl9RQreOPfNAybRzi7x6iuirmdNfbeJziumHSgBaKKKACiiigBp+8KdTT94U6gAoooo AKKSloAKKKKACkbpS0jdKAAdKWkHSloAKKKKACiiigAooooAKYvU0+mL1NAh9FFFAwooooAr 3k4gt2c9ccVy7uWck9Sc1q65P86xA8dSKyOtMC1YQma5QYyAcmunAwABWbo9t5UPmHq9adDE hp6inU0/eFOpDCiiigAooooAKKKKACkPSlpD0oAB0paRelLQAUUUUAFFFFABRRRQAU0feNOp i/eNAh9FFFAwooooAKKKKACiiigBrdRTqa3UU6gQUUUUDCiiigAooooAKQ9KWkPSgAHSlpB0 paACiiigAooooAKKKKACk70tJ3NAC0UUUAFFFFABRRRQAUUUUAIaWkaloAKKKKACiiigAooo oAKSlpO1ACL0p1NTpTqAQUUUUAFFFFABRRRQAUnelpP4qAFooooAKKKKACiiigAooooARulL SN0paACiiigAooooAKKKKAGuwRSx7Vy93MZ7hnPrxW3q03lWpAOC3Fc8BuYDqc0Aa2iW+WaY 9uBW1VXT4hDbKuMHvVqmxIKKKKQwooooAKKKKACmn7wp1NP3hQJjqKKKBhRRRQAUUUUAUNWm 8q2Kjq3Fc8frWhq0/m3BUH5V4qjEheQL6nFMDW0e3+QzMOvArXFQwxCG3VB2FTUMSFooopDC iiigAooooAKKKKAEHelpq96dQAUUUUAFFFFABRRRQAUh6ilpD1FAC0UUUAFFFFABRRRQAUUU UAI3SgdKG6GhegoAWiiigAooooAKKKKACiiigBo6mnU0dTTqACiiigAooooAKKKKACmnqKdT W6igB1FFFABSUtJQAtFFFABRRRQAh6UDpQelA6UALRRRQAUUUUAFFFFABRRRQA0feNOpgHzm n0CQUUUUDCiiigAooooAKa3SnU1qAHUUUUAFFFFABRRRQAUUUUAFNXpS0i9KAHUUUUAFFFFA BRRRQAUUUUAJ/FS03+KnUAFFFFABRRRQAUUUUAFNfpTqa/SgTFHSlpBS0DCiiigAooooAKKK KACiiigBo+8adTR9406gSCiiigYUUUUAFFFFABTWp1NagB1FJS0AFFFJQBz2tD/SufSqMPEq n3FXdZcNdYA6CqMTYkUk8A0AddGcxr9KV1DqVYZBqvBeQSBVWQE46VZBoA5zU7I277kH7s/p WfnBrrriJZoWRhnNc3cWUsUmNpIzwRTtcV7ETXEkiBGYkds0wcMKnexnjhMrrtX3qv8AWlaw 7nV2jB7ZG9qnqpprB7OPHpVugBaQjIwaKWgDC1aw2EzRD5T1HpWTiuxZQ6kMMg1iX+lMHLwL lfSnuIzoLmS3cMjYrZtdXjcYm+Q1huhQ4YYI9aYaQzroriKUZRwfxqXIrjQ7L90kH2qeO9uI xgSt+JpAdXRXNpqtyq43g+5FOXWLgddp/CmB0VBIFc42r3L8BgPoKikv55BtMpxQBvXV9Fbo SXBbsBWFeX0t0cE4X0FVjljzVu0sJJiCQQnrTSE2MsbVrqUL27mulhiWGMIowBTbeCOCMKig CpaGAHpXLaiCt7Jn1rqa5zWRi8JI7UhiaS+y8HPXitm9skuo/Rh0NYOnkC8jJ6ZrqB0pgclP bvBKUcYIpqSNG4ZThh3rpb+zS5iPA3joa5ueF4XKuMEUCNmy1ZX+SfAPrWnEwZcg5FceOKu2 2oy24wuGX0NIZ01czqoxfPWrDq9u6jeSrehrL1Qq92WU5BFAEdiyrdxluma6kdK5S0G65jHv XVL90UAOopKWgAooooAb/HTqafvinUCCiiigYlLSUtABRRRQAUjdKWmt92gBR0paRegpaACi iigAooooAKKKKACmr1NOpi9TQIdS0UUDCoriUQws57CpaydbuAIxCp5PWgDHnlaaVnbkmnWk JmnRMcE81AetbOhwj5pCDnoKaEa6IEQKOgFPpKWkMaeop1NP3hTqACiiigAooooASloooAKR uhpaQ9KABegpaQdKWgAooooAKKKKACiiigApo+8adTB980CH0UUUDCiiigAooooAKKKKAGt1 FOprdRTqBBRRRQMKKKKACiiigApD0paQ9KABelLSL0paACiiigAooooAKKKKACmg/MadTR94 0AOooooAKKKKACiiigAooooAa3anU1u1OoAKKKKACiiigAooooAKTtS0h6UAInSnU1OlOoEg ooooGFFFFABRRRQAU3+KnU3+KgB1FFFABRRRQAUUUUAFFFFADW6U6mt0p1ABRRRQAUUUUAFJ S1BeTCG2dz6UAYmq3HnXJUfdXik0q38643H7q81TLZcn1rodKg8q1BIwW5piLaDAp9NWnUho KKKKACiiigAooooAKafvCnU0/eFAh1FFFAwooooAKhu5fJt3f0FTVka3PgLED15NAGTIdzFm PJ5q9osPmXBkYcL0rOOT2ro9Lg8m1Gerc0xFtulL2pG6Uo6Uhi0UUUAFFFFABRRRQAUUUUAN XvTqavenUAFFFFABRRRQAUUUUAFNP3hTqaeooAdRRRQAUUUUAFFFFABRRRQAjdDQOlDdKB0o AWiiigAooooAKKKKACiiigBo6mnU0dTTqACiiigAooooAKKKKACkPUUtNPUUAOooooAKKKKA CiiigAooooAQ9KF6UHpQOlAC0UUUAFFFFABRRRQAUUUUAMH3zT6YPvmn0CQUUUUDCiiigAoo ooAKa3SnU1qAHUUUUAFFFFABRRRQAUUUUAJQvSlpq9KAHUUUUAFFFFABRRRQAUUUUAN/ip1N /ip1ABRRRQAUUUUAFFFFABTX6U6mv0oExaWkFLQMKKKKACiiigAooooAKKKKAGgfNTqaPvU6 gAooooASilooASilooASkYdKdSNQAUUtFABTW4BNOpkn3Dj0oA5nUH8y6c8YzVQ1LcHMzk+t NjjMjbVzk0ANBKkEEgit3Sb7zh5ch+YdM96xJEaNir8EU2J2jcOpwRSA7E9KRFG2qen3ouYf mI3DqKup92mLqVNTGbN65o11Go/8ecn0rmPSgZ0Wkj/Qkq9iqelf8eSVdoASilooASjFLRQB Tnsobh/nXn1FZ8+iNkmJxj0NbQ+9TqdxWOZfS7pf+Wefoai+wXI6wtke1dVRijQDkvs8g6o3 5UeRIeiN+VdbtHoKTaPSjQDlBaTN0iY/hViLSriTqu0e9dJiijQDOtNKjh+aTDNV11AXAqSm ydKLg9hQOKWgdKKQwrndZ/4+/wAK6Imuc1h912cdqAIbBd13Hj1rqAOK5rSlL3i+3NdMKYBU Fzax3KFXH41YpKQHPXOkzRcp86+1Z7qVOCCDXYnpVCXTYbhy7ZB9qejFsc6oJqSVdrgNnpXQ Q6XbxNkLuPvWRq4AvDt9KAIrIhbuM9s11A6Vy1ihkukAODmuqXgCgYUUtFIBKKWigBhHzinU h+8KdQISilooGJRRS0AFFFFACUjD5adTW6UAC9BS0DpS0AJRS0UAJRS0UAJRS0UAJTEByakp q9TTELRS0UhjWO1ST2rl72Xzrl27ZxW5qs/k2xUH5m4Fc4c5oAEUu4UDk8V1VpCIbdUAxgVi 6Ta+bcbnBwvNdAOKYgopaKQxjA7hTqQ/eFOoEFJS0UDCiiigBKKWigBKRulOpD0oARegpaF6 UtABRRRQAlLRRQAUUUUAFMX7xp9NHU0CHUlLRQMKKKKACiiigAooooAY3UU6kbqKdQIKKKKB iUtFFACUtFFACUHpS0h6UAIvSnUg6UtABRRRQAUlLRQAlLRRQAUwZ3Gn00dTQAtLRRQAUUUU AFFFFABSUtFADW7UtI1OoASloooAKKKKACiiigApD0paQ9KAGp0p1IvSnUCQUlLRQMSloooA SilooASk/ip1N/ioAdRRRQAUUUUAFJS0UAFJS0UAMfpThSNS0CFpKWigYlFLRQAlY2tXAYrC vbrWtNIIomdugFcrNK0szOT1NAElnCZrhUxkZ5rqFUKgUdAKy9FgIBmbvwK1qbAaveloWlpA JS0UUAFFFFABRRRQAlNOd4p9MP3xQJjqKWigYUlLRQA1jtUk9q5u+m8+4Zx0HArb1GXyrVsH BPFc0SSetNAWLGEz3Kr26mumVQqhR0FZGiQ8tKfoK2aGIa/IpR0pG6UtIYtFFFABRRRQAlLR RQAUUUUANXqaWkXvTqAQlLRRQAlLRRQAUlLRQAU053CnU09RQA6iiigApKWigBKWiigApKWi gBrfdNC9KVulC9BQIKKWigYlLRRQAUlLRQAUUUUANXqadTR1NOoAKKKKAEopaKAEopaKAEpG 6inU09RQAtFLRQAUlLRQAlFLRQAUUUUAIelIvSlPSgdKAFpKWigBKWiigAooooAKKKKAGD75 p1NH3zT6BISilooGFJS0UAFFFFACUjU6mt0oAWloooAKKKKACiiigBKWiigBKRelLSLQA6ii igApKWigBKWiigAooooAb/FTqb/FTqAEpaKKACiiigAooooASmyHgfWn0x+lAmOpaQUtAwoo ooAKKKKACiiigAooooAaPvGnUwEbiKdQAtFJRQAtFJRmgBaKSjIoAWmtS0hNADqKTNFAC0yQ 4RvpTqjuW2wOR6UAcrMcysfetDRYg8rMR0rOY5J+tbWhriNz6mmAmrWG9fNiX5u9YZX1/Kuy OCMGs2/0yOVS8Xyv6etG4GFFK8ThkbBrcstVjdQkh2t69qwpI2jcqwIIph4NIDp7+RWsnKkE YrmqeLiURFN52ntUW4n6UXA6bSyRZJmrtcxb6lPAgQEFRWlDrUTDEilaLga1FUF1e1Y43Ee5 FTpe279JV/OgCxRUfnRf89F/Ojz4v+ei/nQA7+KnVVa8gVsmRcfWon1a1XPzk/QUAXqWsw6z AOisfwqM65H2iagDWorGfWzgbI8H3NQvrUx6IooA380hYAZJrm31W5f+MD6CoJLuaXO+Rvzp AdK93Ch+aRR+NRvewEcSLXM5z3pM0wOnOo26jmQVWfWoRnaCawCfrSZFAGlNrEzt8gCiqEkr SuWY8mmGikMvaWQk5kbhUGav/wBtr5m0RnHrmslBKIGZVO09SKjFMR18cgkQMOhp1c3Y37Wz gMS0fp6V0EMyTIHQ5BoAkpqd6dSKetAC1zmrD/S2Ga6Ouc1Zf9Nb6UwI7A7buPHrXTjpXL2J 23cf1rqB0FAAaWkpaQBRRRQA3+KnU0n5hTqBBRRRQMSlpKWgAooooAKRulLSN0oAB0paQdKW gAooooAKKKKACiiigApq9TTqavU0CHUUVV1CfyLZmHXoKBmPq05luSoPC8VRUZIA6mgncSSe TVvTbbz7kE9F5NMRtadb/Z7ZR3PJq3SAYGKWkMKKKKAGnqKdTT1FOoAKKKKACiiigAooooAK Q9KWkPSgAHSlpB0paACiiigAooooAKKKKACmjqadTR1NADqKKKACiiigAooooAKKKKAGt1FO prdRTqACiiigAooooAKKKKACkPSlpD0oAB0paQdKWgAooooAKKKKACiiigApv8Rp1N7mgB1F FFABRRRQAUUUUAFFFFACGlpDS0AFFFFABRRRQAUUUUAFJS0lACL0p1NXpTqACiiigAooooAK KKSgBaT+KlpO9AC0UUUAFFFFABRRRQAUUUUANbpTqQ0tABRRRQAUUUyVxHGzt0AoAy9ZusL5 Knr1rMtIfOnVB1JpLiXzpmc9zWpo1thTMw6/dpiNSJBHGFAAwKfRRSGItLSCloAKKSloAKKK KACiiigApp+8KdTT98UCY6iiigYUUUyVxHEznsKAMfWLjdIIlPA61l4JIHrUlxIZJmYnqam0 6Dz7lePlXk0wNywhEFqq9zyas0gGBgUtIBG6UUN0ooAWiiigAooooAKKKKACiiigBq96dSDv S0AFFFFABRRRQAUUUUAFNPUU6mnqKAHUUUUAFFFFABRRRQAUUUUAI3Q0L0FB6UDoKAFooooA KKKKACiiigAooooAaOpp1NHU06gAooooAKKKKACiiigApp7U6kPagBaKKKACiiigAooooAKK KKAEPSgdKD0oHSgBaKKKACiiigAooooAKKKKAGj71Opo+9TqACiiigAooooAKKKKACmt0p1I 1AC0UUUAFFFFABRRRQAUUUUAFIvSlpB0oAWiiigAooooAKKKKACiiigBP4qWk70tABRRRQAU UUUAFFFFABTW6U6mv0oBiilpB0paACiiigAooooAKKKKACiiigCMoGbntS+WPelH3jTqdxWG eWKNgp9FK4WQ3YPejYKdRQFhmwe9GwU+ii4WGbB6mhlyOKfTWoCwnljHejYPen0UXCw3YKhu UxbvgnpVio5gDE2emKdwsckc5NbeipmBiT3rFfh29M1f07UI7VWVweT2pXCxvbBRsFVotRtp cASAE9jVsHI4ouFipc2MMysSvzEdawZ7KeEk7CV9a6k9KaoBXkCmBx5DehppNdHqsMa2jMqh T7CuexSsMb2yKUk1rW2lJPAriTk1N/YS4/1p/KnYLmHubHSjce4rZbQzj5ZR+IqI6JP2daVg uZfmGlDnPU1of2Nc56L+dJ/ZFz/dX86LBcoZoz7Vpro8xOGZRU66GMjdLx7CnYVzFycUgJro U0eAdSxpw0a2H9786LBc5zLUHNdL/ZNr/cP508abagf6oUrIDlhnvU8VtNKfkjJ/CukGn2w/ 5ZLU6IqABQABT0Hqc1/Z11tyYjij+zbnbkx8Gunpr9KNBHODS7ojOyoWsbhTgxN+VdWOlGKN AOQe3lQZZCv1qMDmug1tgttj1NYK8kAUhm/ptsPsY3dG7VS1LT/I/eRLlO49K2bMFbZARg4q V0V1KsMg07isccTjpU0F3LARsYgelaV/pPV7cfVayHRkJVlII9aLAdDZ38dwAC2G9DVtVJOQ a5NSQcg8itK11aSIBZF3D170XCxuFDj71YGrrtusdeK17fUIJ1yGCn0NZetbTOpznIouFipZ nF1H9a6dUOB81cpbnE6H3rrU5UUBYaUP940bD/eNPoouFhuw/wB40bT60+ikFiJlJIGaXY39 407+Klp3FYbsb+9RtP8AeNOooHYZsP8Aepdp/vU6igLDdp/vUbT/AHqdRSCw3afWkKnHWpKQ 9KAsRqrY60uxv71PHSincLDQrd2o2n+9TqKQWE2n1pNp/vU6igLDdp9aNrf3qdRQFhNp9ajC tuPNS0i9TTBoTa396sHV7gvN5YOQtbF7cC3t2Y9e1cy7mRyx6nrQFhBXQaZbmO3DdC3JrL02 1M9wMj5Rya6MAKMDgCjYNxuG9aMN/ep1FILDSrf3qMN/ep9FAWInVsjml2t/epx6inU7isM2 t60Yb1p9FIdhmG9aMN/ep9FAWGYb1ow3rT6KAsMw3rQQcdafSHpQFiNQ2ODTsP604dKWncLD MP60Yb1p9FILDMN60Yb1p9FAWGYb1ow3rT6KAsM+b1puH3cGpaaPvGgLCYb1ow/rT6KAsMw3 rRhvWn0UBYZhvWjDeop1FAWG4f1FGG9RTqKAsRvu4pQH9RTm6inU7isMw/qKMP60+ikOwz5/ UUHf7U6igLDfm9aPn9qdRQFho3+1B3Yp1HagLEa76d8/tTh0ophYb8/tS/NS0UgsN+b2oO/2 p1FAWG/P7Uvze1LRQFhPm9qYd+7ipKO9MLDRv74o+f2p1FILCfNSfP7U6igLDfm9qPn9qdRQ Fhvz+1L83tS0UBYYxbFKC+KcaKdwsNJf0FHze1OopBYb83tS/N7UtFAWEy3pR83tS0UBYT5q TLegp1FAWI1L/hTsv6ClXpTqYJDMt6UfN7U6ikFhuW9BRl/QU+igLDMt6UEtjpzT6SgLDct6 CkYtmpKTvTCw3L+goy3pT6KQWG5b0pMt6U6igLDctRlvSnUUBYblvSjLelOooCwxywHSgF8d KeaKYWG5b0oy3pT6KQWGEt6Vj6xdscQqceuK0b+4Ftblv4jwBXMsxkcsxJYmmBNawNcTBFH1 rpIkMcYQAYAqppNp5EO9h8zVo0BYZl/QUZb0p1FILEal+eKdlvSnClphYZlvSjLelOopBYbl vSjLelPooCwzLelGW9KfRQFhmW9KaxbcMCpaafvCmDQm5vSjc3pT6KQWGZb0qhq0xW32dC1a NYGqz+bcEAjavFMLGe3JzWxosbLG0gB5NZMa+ZIqjOScV1NvEIYVQdhQA7c/92jc3pT6KQWI 2ZtvSlDNj7tOPSimFhuW/u0Fj6U+kpANy3pRlvSnUUBYbub+7Rub+7T6KAsNyfSjJ9KdRQBE rNuPFO3N6U4d6WncLDNzelG5v7tOopBYbub+7S5PpS0UAN3N6Ubm/u06igBu5v7tIzEHoafS HqKYWE3N/do3N/dp1FAWG7m/u0bm9KdRSCw3c392jc392n0UBYZuPpS5PpTqKAGMTg8Uiscd KeelA6UwsN3H+7RuP92n0UgGbj/do3H+7TqKAGlj6Ubj/dp1FADdzf3aXcfSlooAjDnceKdu P92lHU06mFhm8/3TRuPpTqKQWG7j/do3H+7TqKAsNDn+6aNx9KdS0BYZuP8AdNIzHjipKaeo pg0JvP8AdNG4+hp9FILDNx/umjcf7tPpKAsN3H+6aNx9DT6KAGbj/dNG72NPooAYW46GkVzj oaeelA6Uwsxu8/3TQHPoadRQGo3ef7po3exp9FIBm4+ho3+xp9FADN5/uml3H0NOooAiLkN0 p24/3TS/xUtMSTG7/wDZNG72NPopDGb/AGNG72NPooAZv9jRu9jT6KAGB/8AZNI74HQ0+kbp TCzED8dDRuP92nUUg1G7vY0bz6Gn0UAM3H0NG4/3afSUAN3n+6aXd7GlpaAG7vY0gb2p1A6U wG7/AGNLu9jTqKQDN3saN/safRQA3d7Gjd7GnUUAN3exo3exp1FAEZb5ulO3exo/ipaYajd/ saXd7GlpaQDd3saN3sadRQA3d7Gjd7GnUUAM3expHbIHapKa/SmDFHSlpB0paQwooooAKKKK ACiiigAooooAaPvU6mDO806gSFooooGFFJRQAtFJRQAtNalprnpQJj6KSigYtMkGY2+lOpG+ 6aAOSm4kce5qMVLcD9++fU1ZsLNLsOGJBHQigRRBIPHatrTNSyfKmPPY1m3do9rJtbkdjUA+ XkGgaOxzkUifdrCsdUdNscvK+tbcThkBHIoAq6sM2TVzddPqI3Wbj2rmO+RQB0ulgfY0xV2s 7R33WgHpWhmgBaKSjNAC0UlFADf46fTM/PTqBIKWkooGLRSUtABRSUUALTH6U6myfdoQmOHS lpAeKKBmRrx/dIPesaLmRceorY10ZCVkRD5wR1BpgdbFxGv0p9Z0+oLbW6MQSxHAqC21nzJA sibc980gNiqd5YR3Qyflf1FWg4YZHSjNMDl7qxmt2O4ZHqKrEYrsHUMCGGRWfcaZFMCUGxva jRi2OfHsaVnd8bmJxWiNGnyRlcdjUV5YG0jVmbJPpRYLlSI4kU+hrrYTuiU+orkBwa6qxYta oSMcUhlmikozQAtFJRQAh+8KdTCfnFOoELRSUtAwopKWgAooooAKRulFI33aAFHSlpAeKKAF opKKAFoopKAFooooASmr1NOqjf3PkQOR948CmJmbq10Zptin5VqgiliAOtBJJJPU1d0q38+4 3MMqtAGxp9v9ntwCPmPJq3SDgUUhi0UUUAFFFFADT1FOpjfeFPoEFFFFAwooooAKKKKACkPS lpD0oAF6UtIp4paACiiigAooooAKKKKACmj7xp1MX7xoEPoopKBi0UUUAFFFFABRRRQA1uop 1NbqKWgQtFFFAwooooAKKKKACkPSlpD0oAB0paavSnUAFFFFABRRSUALRRRQAU0feNOpgPzG gB9FJS0AFFFJQAtFFFABRRRQA1ugpaRqWgBaKKKACiiigAooooAKSlpD0oAROlOpidDT6GJB RRRQMKKKKACiiigApv8AFTqb/FQA6iiigAooooAKKKSgBaKKKAGtS0jdKWgBaQkAZPSlrP1a 58mDYp+ZuKAMrU7rz7ghW+ReBT9JtDPMJGHyoapIpkcKOpNdPZWy20AQdepNMRP0paKKQwoo pKAEWnU1adQAUUlLQAUUUUAFFFFABTT94U6o2++KBMkooooGRXEgihZj2Fcu7F3Y+pra1mcp CIx/F1rCJpgXtIhEl1uPRea6Ks7R4Qltv7tWjQwCiiikAjdKB0pG6Uo6UALRRRQAUUUUAFFF FABRRRQA0d6dTV706gAooooAKKKKACiiigApp6inU09RQA6iiigAooooAKKKKACiiigBG6UL 0obpQvSgBaKKKACiiigAooooAKKKKAGjqadTR1NOoAKKKKACiiigAooooAKae1OprdqAHUUU UAFFFJQAtFFFABRRRQAh6UDpQelC9KAFooooAKKKKACiiigAooooAYP9YafTB980+gSCiiig YUUUUAFFFFABTW6U6mt0oBi0tJS0AFFFFABRRRQAUUUUAFNXpTqavSgB1FFFABRRRQAUUUUA FFFFADf4qdTf4qdQAUUUUAFFFFABRRRQAU1ulOpr9KBMUdKWkHSloGFFFFABRRRQAUUUUAFF FFADR9406mD79PoEgooooGFFFFABRRRQAU1u1OprUAOooooAKa/3T9KdTX4RvpQByk/+vfPr Wnof335/CsuUkzOT61q6Gv3zj8aYGjdWqXMe1/wNc9d2cls5BBK9jiuppjxrIu11BHoaQjkA Oat2uoS2xAB3L6Grl9pRXMkHI7rWQ6kHBGDQ0NHRG6ivLRwHAOOQa54gBqQEqc5xSZzQBvaI +YWXPQ1q1h6E37x19q3KACiiigBO9LRRQA3+OnU3+KnUAJS0UUAFFFFABRRRQAUx+lPpr9KE JijpRR2paBmTriZhVvQ1icA10erJvsm9ua5we9MRZvVkKRyElkI49qqA+ldDZwrc6cqOBgis m9sJLVvVOxFAE1lqckJVHwU9T2reilWVQyEEVyBqxa3ktsfkbjuKQzqqRe9UrLUUuhg/K3oa uJ0NADqytd/1Kj3rWrI11vkRe+aAMUda6mxz9lTd1xXKjrXWWnFsn0piJqKKKQwooooAafvC lpD94U6gAooooAKKKKACiiigApG6UtI3SgAHSlpB0paACiiigAooooAKKKKAEPSud1SbzLgq D8q1t3swhtmYnBxxXLuSzZPU00AnU10mmW/kWwyBubk1j6bbma4Ax8o5NdIBgYFAhaKKKQwo oooAKKKKAGnqKdTT1FOoAKKKKACiiigAooooAKQ9KWkPSgBF+6KdSL0paACiiigAooooAKKK KACmj7xp1NHU0AOooooAKKKKACiiigAooooAa3UU6mt1FOoEFFFFAwooooAKKKKAEoPSlpDQ AL0paQdKWgAooooAKKKKACiiigApoA3GnU3+KgBaWiigApMUtFABRRRQAUUUUANalpDTqACi iigAooooAKSlooAKQ9KWk7UANTpT6anSnUCQUUUUDCiiigBKKWigApuPmp1N/ioAdRRRQAUU UUAFJS0UAFFFFADWHFLSNS0ANkdY0LscAVzN5cm4uGY9Owq9rF5lvIQ8DrVKytzczqo6dTQB f0ezz+/cf7orYpEQIgUdBTqGAUlLRQAlFLRQA1R1p1ItLQAlLRRQAUUUUAJRS0UAJTWHzinU h+8KBMWg0tQ3Ugit3YnHFAzC1OcS3LZ6LwKrQxmSVUHOTTXO5iTySav6NCXuC/ZaYjbhjEca qOwp9LRSGFJS0UAI3SgdKG6UCgAopaKAEpaKKACkpaKAEopaKAGqOtOpq9TTqACiiigBKWii gAooooAKaR8wp1NPUUALRS0UAJRS0UAFFFFABSUtFADW6GlXpQ3SgdBQIKWiigYUUUUAJRS0 UAJRS0UANXqadTR1NOoAKKKKAEopaKAEopaKAEpGHIp1NPUUALS0UUAJRS0UAJS0UUAJS0UU AIelIvSlPShelAC0lLRQAUlLRQAUUUUAFFFFADB9806kH3jS0CQUtFFAwpKWigBKKWigBKa4 yKfTW6UCFoopaBiUUtFACUUtFACUtFFACUi9KWkWgB1JS0UAJRS0UAJRS0UAJRS0UAMx89Op P4qdQAlFLRQAUUUUAFFFFACU1xkU+mv0oExR0paQdKWgYUUUUAFFFFABRRRQAUUUUANH3jTq aPvU6gAooooAKKKKACiiigAprU6mt2oAdRRRQAVFctsgdvapaq6i22zk+lAHMuTuJ9TV/TL6 O2BVwefSs00c0AddDMkyBkbIqWuUtLuS2kDKeO4retNRhuOM7W9DQBcPSs6702OdC6DEn860 c8Ui9KYjlJraWKTYynNRshRsMMV15VT1ANc7q6gXhxgcUaAO0hyt2AOhFdDXM6YSL1MV0wpD FooooAKKKKAG/wAVKTjrUFzcJbKXfpWNeaq842R5RT+dAI2pbuGEHfIo9s1Sl1qJR+7Usffi sZIpZSNqs34VMNOuscRGnZhcvDW8/wDLH9acutp/FER+NZxsLpesLYqu0bocFSDSsFzoodUt 5cDdtPvVxWDDKnIrkOlXLO/lt+AdydwaAOlpr9KitrlLmMMh+o9KkfpQgY7tS0g6UtAFa/AN pJn0rlu9dTqH/HpJ9K5cimB0OjkmzGTnmrskSyoVcZBqnpIxZr71ezQBiXmjlSXhOR/dNZLo VJBBBHrXY1TvNPiuh/db1FG4jmlcqQVJB9q07PVGiIWblfWq11p01s3I3L/eFVDRYDropkmT cjAisfXGHmIB1qhbXUluwKNgdxUl/cC4lV+nFIZBCMyKPU11kQxGoHpXLWaiS6Qe9dUowBTE OooopDCiiigBp+9TqafvCnUAFFFFACUtJS0AFFFFABSN0paRulAAOlLSDpRQAtFFFABRRRQA UUVHNII4mdugFAGNrU5eURL0XrWXUk0hllZ8dTTrWAzzqgHfmmBt6RB5VtuI+Zua0KZEgjjC L0Ap9IAooooAKKKKACiiigBp6inU09RTqACiiigAooooAKKKKACkPSlpD0oAF6ClpB0paACi iigAooooAKKKKACmjqadTR940AOooooAKKKKACiiigAooooAa3UU6mt2p1ABRRRQAUUUUAFF FFABSHpS0h6UAA6UtIOlLQAUUUUAFFFFABRRRQAU0fep1N/ioAdRRRQAUUUUAFFFFABRRRQA jUtI1LQAUUUUAFFFFABRRRQAUnalpKAEXpTqYnQ0+gSCiiigYUUUUAFFFFABSfxUtJ/FQAtF FFABRRRQAUUUUAFFFFADW6VXv7kW9uT/ABHgVPIdqEntXO6jdG5mx/CvAoAqkl3J6kmug0y0 +zw7mHzt+lZulWZnm8xx8i/rXQdBTELRRRSGFFFFABRRRQAi0tNWnUAFFFFABRRRQAUUUUAF NP3hTqYfvCgQ+srWptqLGD15IrUPFc5qUvnXLHIwvAoGUzzXQ6RF5dqGxy3NYES75VQdzXVQ p5cSoOwpiJKKKKQwooooARulFDdKB0oAWiiigAooooAKKKKACiiigBq96dSDvS0AFFFFABRR RQAUUUUAFNPUU6mn7woAdRRRQAUUUUAFFFFABRRRQAjdKB0obpQvQUALRRRQAUUUUAFFFFAB RRRQA0dTTqaOpp1ABRRRQAUUUUAFFFFABTW7U6mt1FADqKKKACiiigAooooAKKKKAEPSgdKD 0oXpQAtFFFABRRRQAUUUUAFFFFADP46fTf4zTqBIKKKKBhRRRQAUUUUAFI3SlprdKAHUUlLQ AUUUUAFFFFABRRRQAlIvSlpF6UAOooooAKKKKACiiigAooooAb/FTqb/ABU6gAooooAKKKKA CiiigApr9KdTX6UCYo6UtIKWgYUUUUAFFFFABRRRQAUUUUANHWlqMkh+Kdl/QUxXH0Uz5/QU fP6CkFx1FNy3oKMt6CgLj6Sm/N6CjL+goC46kNIN/oKR923pzTC5JRUYL46Cly/oKVguPrP1 hgLMj1q7l/QVl6058pUbuaYGJjnmtD+yXaASI3JGdpqigBcAAnmuogDCJQBxjvQgZyrIyMVY YPvQrFTkHBrpLuyW5X5lAbsRWLdWMtuTlcr60WBMmtdVljwsnzLW5bzJLGGUiuTqSG4kgkBR iMUhnW1z2s4+2de1W7XVjIwR1AJ71Q1Rt92SeeKBCab/AMfqZrph0rmtNH+lqcZNdEGbHSnY Lj6KZl/7tLlvSgLj6iuJ1t4i79BSl29Kw9Wu2kkMWRtXrSsFyveXT3cnt2FXrDS8hZJuR/dq tpdv5kwcjIWt8FgPu09hXFSNUACqAB6U6mBn/u0u5v7tA7jqjkgilGHQGnbm/u0bm/u0BczL vSFILW/B9KyJI2ico4wRXVbm/u1Rv7T7SmQoDjvTFcyLS6a2l3L07iuginSeEOprmHUo5VuC KtWFw0MoXPynrSH0OkHSio1clQcZFKXb+7RYLlfVG22b/SuZNbWtSP5IU8A1jLywHrQBL9qm CBFcqo7CtHTdTbIjnOR2Y1QvLUwbT2YVXBwaVhpnYBgRkUtYFjqhhGyX5l7GteG6WZdyDIoE 2TsoYEEZFZdxpEcuWjbafStLef7tNVzuOBkVSuJtGHHpFwWw2FA75qpcx+VMyE5xXUFzj7tc 1e/8fUmfWkND9Lj8y8X25rph0rndIOLrgZ4rfDt/doC4+imFz/doDn+6aLBckopm4/3aNx9K VguKfvU6omY7hgc0u8/3TTsFySimbz/do3n+6aQXHUtR7z6Uu8/3TTsFx9FM3n0o3n+6aVgu PpD0pu/2NBY46GiwXHDpRTFc45FG/wD2TTsF0SUUzf7Ub/Y0rBcfRTN/saXcfQ0BcdWXrVxs hEQ6tWgXwPumuc1Gfz7lmPQcCnYLlQ1uaLD8jSkcngVjIm9wo710dmPJiVMdBTsJuxcopgf2 NG//AGTU2HcfRTN/saN/saLBcfRTN/saN49DRYLj6KYXx2NG/wBjRYLoceopajZ+R1o8z2NO wXRJRTN/saN49DSsFx9FM3+xo3+xoC4+imb/AGNG/wBjRYLofSHpTfMHoaC3HQ0WC6HDpS1E snYineYPQ07BdD6KZvHoaN49DSsF0Popm8eho3j0NAXH0UzePQ0bx6GiwXQ+mj7xpN4pN4DG nYLokopm8e9G8ehpWC6H0UzzBRvFFguPopm8UbxRYLjqKbvWl3igLoG7U6o3fpilEgNOwXQ+ imlwOtG8UguOopm8Uu8UBcdRTd4pN4oC4+kPSm71pd4xQFxR0opgkWl3rTC6H0U3eKN6+tIL jqKbvFG8UBcdRTN4pd4osFx1N/io3D1pN4DUBdDqKbvX1o8xfWgLofRTd49aTeKAuPopu9fW jePWgLjqKbvFG8etAXFNLTGcUB1PeiwXQ+imb19aXevrQFx1FN3j1o3D1oGOopu8etG8etAr jqSk3D1o3D1oC4J0p1RrIuKdvHrTBNDqKbuHrRuHrSGOopu9fWjcPWgB1FN3D1o3r60CuOpv 8VG4etIXAIoC4+im719aN6+tAXHUU3evrRuHrQMdRTdw9aN6+tAXHUU3cPWori4SGFnPOKBF HWLsInkr1PWsaKMzSBF6k0s8zzSs7HOa09Ht1GZn69qaBmpawLbwKg7VNTdy+tG4etIB1FN3 D1o3D1oGOopu4etG4etAXHUlJuHrRuHrQAopaYrjml3D1oFcdRTd6+tG4etA7jqKbuHrRuHr QA6im7h60bh60BcdTD98U7cPWmM4DDmgTGXcvk27v7VzDNuYmtjWZ/3axqQc8msUnmmBoaPB 5txvI4WugrN0ePyrbLYBbmtDcvrQwHUUm4etG4etIYtJRuHrSbh60AK3SikLDHWjcPWgQ6im 7h60bh60DHUU3cPWjcPWgB1FN3D1pdw9aAFopNw9aMj1oAB3paYHGSKXcPWgVx1FJuHrRuHr QMWim7h60u4etAC0UmR60ZHrQAtNPUUuR600sARQIfRTdw9aNw9aBjqKTcPWjI9aAFopMj1o yPWgBaKTcPWjI9aABuhoXpSMeKFYEdaBdR1FJketGR60DFopMijI9aAFopMijIoAWikyPWjI oAQdTTqYGGSM07I9aBC0UmRRkUDFopMj1oyPWgBaKTI9aMigBaaeopcikYgYoAdRSZHrRkUA LRSZFGR60ALRSZFGRQAtFJkUZFABQOlBIxSAjFADqKTIozQAtFJmjNAC0UmaM0ALRSZooAT+ KnUzI306gSFopM0ZoGLRSZozQAtFJmjIoAWmt0pc0jEAUAOopMijNAC0UmRRkUALRSZFGaAF opMijNAC0g6UZpqsPWgQ+ikyKMigYtFJkUZoAWikyKMigBaKTNGaAE/ip1MJw1OzQIWikzRm gYtFJmjNAC0UmaM0ALTH6U6myHihCY4dKWkHSloGFFFFABRRRQAUUUUAFFFFADQfmNOpg++a dQJC0UUUDCiikoAWikooAWmselLTXHSgTHUtJRQMKxNcb94gzW3iue1k/wCl4z2oAq2ih7mN W6ZrqkGABXOaWoe7UHtzXRgUwFpCoIwQDS0UgM680uOUFovkb26GsGaJonKsMEV1xHFVp7KK 5jw459aYjl8+lDOWPJJNX5tKnjchRuX1qiyFGKkcilYdy7pGTeLXSCuf0Qf6Q2ewroKAFopK gurlLaMs5/CgBL2fyLdn744rl2cySEtySauX+oG6UKFwKrWyb51UngmgDoNOiEUK8ckZNXai iXbgD0qWmxIKWkopDFpKKKAFpKKKAMfWLQY85APescHFdbLGJIyrdCK5a5iMM7IexpiNzSrr zodpHKcZrQrndJm8u429mroR060hmNrrH5F4xWVCN0yD3q/rbE3IHYCqtgu+7jHvTA6C4s0u YAj9ccGueu7R7VyG6djXVAcUyWFJUKuoINAjkD1FSxTyQtuRiDWrc6LxmBufQ1lzWs0LESIR 79qLBcvw604wJUBHqK1La7hlGVcZPauWIp2SDxSGdczDBrlrw5uZD6mnQ3s8R4ckeh5qKZ/M lZz3oAvaIB9rOfSuhrm9Iz9sH0rpAKACiiigBaKSigBD94U6mEfMOafQIKKSigYUtJRQAtFF JQAtNbpS0jdKAFHSigdBRQAUtJS0AFFJRQBBeSeVbOw9K5dzlie5rZ1ubCLGD16isXFMRd0m PzLsZGQvNdCgwTWfo9v5dvvI5atBOpoAfRSUUhi0UUUAJS0lLQAlFFLQA0gEilpD94UtAhaK KSgYUUtFACUtJS0AJQelLSHpQAAcUUL0paAEopaSgAooooAKKWigBKaMbjTqQfeNAhaMUUUD DFGKKWgBMUYFFFABgUYFFFADXAOKdgelNbqKdQIMD0owPSiloGJgUYFLSUAGBRgUtFACYFBA xRQelACKoA6UuB6Ui9KWgQYHpRgelLSUDDAowPSlpKADA9KMCiigAwPSm7QW6U+mj7xoExcD 0owPSiloGJgelGB6UUd6ADaPSjaPSiigAwPSjA9KKKAGsBilCgdqGzxS0CDaPSjaPSiigYYH pRtHpRRQAbR6UbR6UUUAGB6UYHpRRQAxFHJp+0elIucUtMSQbR6UbR6UUUhhtHpRtHpRRQAb R6Um0elOpKADaPSmlQWp1J/HQJhtHpRtHpTqSgYm0elG0elLRQAm0elG0elLRQKwm0elYus3 ILiFO3WtS8uBbwM569q5eRzLKWY8k0DJbSAzzhB+NdPHEiIFCjgVn6Xa+VAJD95q06bEhNo9 BRtHpS0UgsJtX0o2j0paKBibR6UbR6UtFACbR6UbR6UtBoAaFFLtX0oU0tArCbR6Uu0elFFA CbV9KNo9KWigYm0elG0elLRQAm1fSmuq5FPqveSeVEze1NCdjE1OQPdMAeBwKqRpvlVfU0rk sxJq7pEHmXO4jIWgDchiVIlUAcCn7R6UtFILCbR6UbR6UtFAWE2j0o2j0paKAsIVGOlAUY6U MeKUdKAE2j0o2j0paWgdhu0elGwelLRQKwmxfSjYvpS0UBYTYvpRtHpTqKAsMCLk8UuxfShe 9LTCyE2L6UbB6U6kpBYTYvpRtHpS0tAWG7F9KNg9KdRQFhu0elIUBI4p1IT8woBpBsX0o2L6 U6koCwmxfSjYvpS0UBYTYvpRtHpS0UAJtHpRsHpS0UANZBjpQEXHSlb7tC9KYWVw2L6UbF9K dRSAbtHpRsX0paKAsJsHpRsFOooCw3YvpRtHpTqSgLDBGpJ4pfLX0pV6mlphZCbF9KNg9KdR SCw3YPSjaPSlooCwmwelG0UtFAWE2L6UhReKdSN1FMLINi+lGxfSlopBZCbF9KTYtOooCyE2 CjYKWigLCbBRsFLRQFhCoxSKgxTj0oXpQFkN2LRsX0p1FAWQmwUbBTqKAsN2LSbFp1FAWG7F pdgpaKAsM2DdTtgpB9806mCSE2CjYKdRSCw3YtGxaWigLITYKTYKfRRcLDNgoZRinU1zxTCy ARgCjYKdRQFkJsFGxadSUgsJsWk2LTqKAshuwUuwUtLQFhuwYpoQU+kU8UwsJsFLsFLRSCw3 YKNgp1GaAsN2Cl2ClooCwmwUbBS0UAMKAml2Clz81LTuFkN2Cl2ClzRmkFhuxaXYKXNFAWE2 CjYKdRQFhuwU11GOKfTX6U0DQ4dKWkHSlpDCiiigAooooAKKKKACiiigBo+8adTR9406gAoo ooAKKKKACiiigAprdqdTW7UAOooooAQ1zOptuvX/ACrpj0rl9QObyT60AWNFH+lHjtW+CM1y cNw8GTGcE8Zp8V7Mkofex9cmi4HV0VVs7tLmMFTz3FWqAEPSkT7tKelIn3RQIST7hrlJ/wDX vnrmurk+4fpXJyj9831NAzT0MZd2rbrH0McOea2KAGyNtQk9q5a+uDNOzZJHbNdJeEi2cjri uTbljk0AHap7IhbmMt0zUSoX6DpU9vbyySDap69aEhHTIfmGPSpKybjUha4QDc+MGqx1ubB+ RfrQ2NG/RXPf2zOR91c0o1qfGNq0gOgozXPjWLjnhajOr3X95fyp3A6TNGa5c6jcuxJkP4U6 DUZ43BZyw9DQB01c/rSFbkMRwRW7C/mRK/TIrH10fvEpgUbDm7j7c11A6VzWmxebdKMkAc8V 0hGFoA5vVTm9fnNS6MoN1k9hVa+YG6kI6ZplvdPbPujxk8c0gOtBorCt9YdeJVDD1FbEM6TK GRgaAJaayK4wwBHvTqKAM660mGY7k+Q+1Zs2lTpkphwPSujpqd6dxHMwWM0sgBRgCeuKjuo/ KnZMYxXVkcVzOo/8fsn1oAm0b/j7x7V0Nc5pB/0wY9K6MUhi0UUUAFFFFADT96nU0/eFOoAK KKKACikpaACiiigApG6UtI3SgAHSlpB0paACiiigApCcAk9BS1XvpBHauT6UAc/fzeddOwOR 0FRQRmWVUHc0w9au6TGXu1OOnNMRvxII4lUdhSr1NPpi9TQA+iiikMKKKKACiiigAooooAae op1NPUU6gAooooAKKKKACiiigApD0paQ9KAAdKWkHSloAKKKKACiiigAooooAKaOpp1NHU0A OooooAKKKKACiiigAooooAa3UU6mt1FOoAKKKKACiiigAooooAKQ9KWkPSgAXpS0i9KWgAoo ooAKKKKACiiigApo+9TqaPvGgB1FFFABSUtFABRRRQAUUUUAI1FBpaACiiigAooooAKKKKAC kNLSGgBF6U6mr0p1AIKKKKACiiigAooooAKb/FTqb/FQA6iiigAooooAKSlqtfXAt7ZmzzjA oAx9XuvNm2KeFqPTLb7RcjcPlXk1UJLv7muj0y2+z2wyPmbk0xFraFUADgU+kbpRSGLRRRQA UUUUAFFFFABRRRQA1adTVp1ABRRRQAUUUUAFFFFABWVrUwCrH3Nah4Fc3qM5muW9AcCmgKld BpEPl2+89WrDhjaWVUHc11MSeXEqDsKBD6KKKQwooooAKKKKAEbpRQelFAC0UUUAFFFFABRR RQAUUUUANXvTqavenUAFFFFABRRRQAUUUUAFNPWnU0/eFADqKKKACiiigAooooAKKKKAGt0N KvShulA6UCFooooGFFFFABRRRQAUUUUANHU06kHU0tABRRRQAUUUUAFFFFABSHqKWkPUUALR RRQAUUUUAFFFFABRRRQAh6UDpQelA6UALRRRQAUUUUAFFFFABRRRQA0ffp1M/jp9AkFFFFAw ooooAKKKKACmt0p1NagB1FFFABRRRQAUUUUAFFFFACUi9KdSL0oAWiiigAooooAKKKKACiii gBv8VOpv8VOoASloooAKKKKACiiigApr9KdTX6UCYo6UtIOlLQMKKKKACiiigAooooAKKKKA Gj7xp1NH3jTqBIKKKKBhRRRQAUUUUAFNbtTqa/agB1FFFACHoa5a8P8ApUnpmupPQ1y15j7V IB60ARJE0gJUZxTCK1tEQF3J9Ks3+mJKC8QAf09adhGLbXD28gZD+FdDZ30dyoGQH7iubkja NtrKVPoadHI0bBlOCPSlYZ1p6UifdFZFtrAICyj/AIFWrE4eMFTkGgBZP9W30rk5eJGHvXWt 901yl0MXLjpzQBp6E3Dj3rZrC0QgTMPat0UAQ3aF7dwDziuTZcMR6V2LDKkVy19EYrl1xwTk UAO059tyowCD61v3LeVbMyJk46CuWVipBHGK6HTbwXEex/vAd+9CAwJNzOS3UmmYrppNPgmk JZBn2pw022AA2dKdkK5zAowa6v7JBjHlLj6UptIDjMS8e1GgHKY+tJtJ7V1X2K3z/qlqRbeJ ekaj8KNAOTEMhPCH8qv2WmyTMGcbV963xGg/hH5U7AHSjQBiKI4wo6AVz+qzCW6ODwvFa2o3 a28JAPznpXO5Lvz1JoGaehxkys3YCttuFNVtPtxBbjj5jyassMqaAOTuuZpPqahxgVNdDFw4 HTNXNJhjnLpIuRigRm5zU0FzJbtujbHtWldaMQSYOR6GsuSF4n2upBFFh3Ni21gMQsy4J7it VHV1BUgg1x3Oas219LbsNrHb6UgOqPSmp0NU7TUorhfmIRvQmrcbZB5oEPPSuX1Hm9k+tdQT xXMX/wDx+SfWmMl0f/j7GPSuirn9GP8ApfHpXQUMApaSlpAFFFFADf4qdTf4qdQIKKKKBiUt JS0AFFFFABSN0paa3SgBR0paQdKWgAooooAKx9bnwFiB9zWs7BFLHoK5e9mM9wznpnigCDJN b+jQCO38wjlqw4omkdVXkk11MEYihVB2FMRLTF6mn0xeppAPooooGFFFFABRRRQAUUUUANPU U6mnqKdQAUUUUAFFFFABRRRQAUh6UtIelAAOlLSDpS0AFFFFABRRRQAUUUUAFNHU06mjqaAH UUUUAFFFFABRRRQAUUUUANbqKdTW6inUAFFFFABRRRQAUUUUAFIelLSHpQAL0paRelLQAUUU UAFFFFABRRRQAU0feNOpo+8aBDqKKKBhRRRQAUUUUAFFFFACGlpG7UtABRRRQAUUUUAFFFFA BSUtIaAEXpTqanSnUAgooooAKKKKACiiigApv8VOpv8AHQA6iiigAooooAKwdan3TCMHhe1b U8ohhZz0ArlpZGmlZz/EaALGl2/2i5BP3V5NdIBgYFUtLt/ItgSPmbk1epsBrdKdTW6U6kAU UUUAFFJS0AFFFFABRRRQAi0tNWnUAFFFFABRRRQAUUUUAV72XybZ2744rmHJLc1r61PysQPu ayM5pgaOiwb5zIei1vVS0y38m1B7tyau0MAooopAFFFFABRRRQA1ulKOlI3SloAWiiigAooo oAKKKKACiiigBq96dTV706gAooooAKKKKACiiigApp+8KdTT94UAOooooAKKKKACiiigAooo oARuhoHShulC9KBC0UUUDCiiigAooooAKKKKAGjqadTR1NOoAKKKKACiiigAooooAKQ9RS00 9RQA6iiigAooooAKKKKACiiigBD0oHSg9KB0oAWiiigAooooAKKKKACiiigBo+8adTR96nUC CiiigYUUUUAFFFFABTWp1NagB1FFFABRRRQAUUUUAFFFFABSL0ooXpQAtFFFABRRRQAUUUUA FFFFADf4qdTf4qdQAUUlLQAUUUUAFFFFABTX6U6mP0oExwpaQUtAwooooAKKKKACiiigAooo oAaPvGnU0dTTqACiiigAooooAKKKKACmt2p1NbtQA6iiigBD0NcreD/SpMetdU33TXK3QH2m THrQBoaEQHcd62qxNEbEzL7Vt0AVrqxiuQdy4b1rCu7GW3Y5XKeorp6ayh1IYZBp3EciBUsV 3PFwkhA9K1rzSVcFoDtPoayJbaWIkOhHvRYLmhDrTAASpn3FZt1KstwzrnB55qMimkUhmlo5 /wBKH0roa5vSOLtea6SgBaytYtDKokQcrWrSMoYYPSgDjWBzz1p0UjxtuU4IrU1LTnUmWIZX 0FZWCD0osK50WnXqzoAxG/0q/XHo7IwZTgj0rVtNXKDbPlh6igZt0tV4buGZQUcc9qnBB70A LRSZpCwA5IFADqr3dyltEXb8qjuNQghU/OGb0FYF5dPdSEtkDsKAG3M73MpdifarGm2/mzBm XKiobW3eeUKoOPWuhgtkt4gqD61SEywowoxSt0oHSg9KkZyt8MXcn1q7oZ/fuD6VU1Hi8k47 1Pop/wBL/CmI6GoZ7aKcYkQGphS0hmDe6Q0YLwfMPSsphg4Iwa7Kqd3p8NyCSNr+op7iOYBx VqK/nhGEc4qW40qeE5Vd6+oqkyMGwQQaLBc2LPVS/wAkoyT3FZl2265kOe9WLOylYebjCrzz 3qpISZGPvRYC/oo/0o/SugrD0MZlc+1btDGFFJS0gCiiigBv8VOpv8VOoEFFFFAxKWkpaACi iigApG6UtIelAAOlLSDpS0AFFFNkYIhYnAFAGdrF15cflKeW61gE+tWLuczTu+SeeKZDE00q ovU0xGjocO5zKRwOBW5UNtCIIVQdhU1JjCmr1NOpq9TQIdRRRQMKKKKACiiigAooooAafvCn U09RTqACiiigAooooAKKKKACkPSlpD0oAB0paQdKWgAooooAKKKKACiiigApo6mnU0D5jQA6 iiigAooooAKKKKACiiigBrdRTqa3UU6gQUUUUDCiiigAooooAKQ9KWkPSgAHSlpB0paACiii gAooooAKKKKACmj7xp1N/ioAdRRRQAUUUUAFFFFABRRRQAjUtNanUAFFFFABRRRQAUUUUAFI aWk7UAIvSnU1elOoBBRRRQAUUUUAFFFFABTf4qdTf4qAHUUUUAFFFIxCqSegoAzNZuFWIQ9z zWXp8JnuVGMgHJovZvOuXbPGeK09Ft9sbSnq3ApiNQDAAFLRRSGIelFB6UUALRRRQAUUUUAF FFFABRRSUAItOpq9KdQAUUlLQAUUUUAFITgE0tVNRnENq3qeBQBhXshluXbPektI/MuUTqCa iJyTmtPRYPnMpHsKYmbSjaoA7UtFFIYUUUUAFFFFABRRRQAjdKBQ3SigBaKKKACiiigAoooo AKKKKAGr3p1NHenUAFFFFABRRRQAUUUUAFNP3hTqaetADqKKKACiiigAooooAKKKKAGt0NKv QUN0oXpQIWiiigYUUUUAFFFFABRRRQA0dTTqaOpp1ABRRRQAUUUUAFFFFABTT1FOpp6igB1F FFABRRRQAUUUUAFFFFACHpQOlB6UDpQAtFFFABRRRQAUUUUAFFFFADR96nU0feNOoEFFFFAw ooooAKKKKACmtTqa1ADqKKKACiiigAooooAKKKKACkXpS0i9KAFooooAKKKKACiiigAooooA b/FTqb/FTqACiiigAooooAKKKKACmP0FPpr9KEJiilpB0paBhRRRQAUUUUAFFFFABRRRQBGX Cvg0vmL60bQWyaXaPSmTqG9fWjevrS7R6Um0egpD1DevrRuHrRtHoKXaPSgNRN49aN6+tLge lJtHoKA1E3r60jOMcU7aPSkZR6U9A1DevrS7x60bR6UbR6UBqNaRQp5rmLtt1w5HrXUOq7Tw OlcpcEee+OmaA1H2909sxaPGT61p2erNJIEkUDPesSjJB4NIZ2AkU96XevrWDp+pCIbJssvY +lbkbJIoZcEGjQWopdcdaaNjrhgD9aeVGOlIqjHSmLUpzWFrKc7dp9qw72Bbe4KI2R611BVc dBXM6gxa7fjHOKGxok0ni7BPSuiEi+tYOjR7pyT2Fb+xfSgNQ3r60b19aNoz0o2L6UBqIWUj kisu/wBOWVi8JAbuPWtXYvpRsX0oDU5KWB4mw6kGmEcV1clvHK2HUEVSn0aJzlGKe1GgK5hB iuMZFSJdTp92Rh+NXJNHuEPy7WFQNp9yn/LJvwosFwGoXOMea1RSXU8gIeRiPTNONncd4n/K pYtMuX/gx/vUuUdynzVm1spLluOF9TWrbaQi4aY7m9B0rQWFFACrgCnohO5DaQR26BVIz3NT O4Ap2xfSmsgx0oFqKHUjrS7x6ikEagdKPLX0o0Hqc5qwH2xiO9RWU4t5xIy5AqXVsC8bAqka GCN2PWo2cBkKj1rSjmSRQysCK5DtVyyv3tyFb5kpDOl3r6ik3r6iooJIpkDJgg1J5a56U9Ba jiwNQeTA5O5FJ9xU2xfSmqinNCE7kF7IsNo5XA4wMVzJJJOa3NawluNvc1hZ5oGbuiIohZz1 JrU3D1qjpcIFouep5q75a0Owai7h60bh60mwUeWvpRoGo7cPWjI9absFGxfSjQNRC4DU7cPW mMgLDFO8sUaC1Hbh60ZHrTfLFHlrRoPUXcPWl3D1pvlrR5a0aBqOyPWjI9ab5Yo2CjQNR2R6 0jEY60mwUhQYo0DUcrAjg0uRTFjAFL5a0aBqLuHrWXrF3tjEKHlutX5QkUbMegFczcSmWVmY 9TxQGpGfWtfRrYZMzfQVl28ZmmVF7munht0jjVQOgoAmyPWjIpvlijyxQGo7NNVhk80eWKaI wSaNBakmR60ZHrTfLWjy1o0HqOzRmm+WPejyx70BqOzRmm+WPejYKA1HUU3yx6mjYPU0BqKS ARS5FRtH0xSiIDuaNBXY/NGab5Y96PLHqaB6js0Zpvlj1NHlj1NAajs0ZFN8sepo8sUBqOoJ 4pvlj1NBTjrQGooIIpc1GsfHJNL5Y9TRoK7H0U3YPU0eWPU0D1HUU0Rj1NGwepoDUdRTdg9T Rt96QajqQEbjzSbPc03ZljzTE2ySim7Pc0eX7mgeo6im+X7mjy/c0BqPopmz3NGz3NINR9FM 2e5o2f7RoDUVjyKWo3QkAAmlEeB940xXdx9FN2f7Ro2f7RoHqPpKbs9zRsP940guOopuz3NG w/3jQF2OoPSmeX/tGlKcdTTC7HA8UVGqHHU07Yf7xoC7HUU0If7xo2n+8aAHUU3Yf7xoKE/x GgLsdRTdnuaNh/vGkF2OpO9IFI/iNNKEt1NMG2S0VHsP940bD/eNAXY+im7D/eNGw/3jQF2O opoUj+I0bT/epBcdRTdh/vGjaf71AXFY0tMdTjrQEOPvGmF2PoppQ/3jRsP940BdjqKbsP8A eo2n+9SC46im7D/eNG0/3qAuOopu0/3qNpx1phcVelLUSo3PzcU/Yf7xoEmx1FN2n+9RtP8A epDuOopu0/3qNp9aAH0Uzaf71G1v71AXHUn8VJtb+9TSjbhg0wbJaKZtb+9Rtb+9QFx1UdWn 8q1IB5birm1v71YGrTb59u7IX0oC5UhTzZlQdzXUQRiKJUHYVi6PbGWTzc4C9K29rf3qAJKK Ztb+9Rtb+9SC4ppaYwOOtAVsfephckoqPa396l2t/eoC4+imbW/vUbW/vUguOopu1v71G1v7 1MLj6Q9Kbtb+9RtPrSC4qdKWo1RuecU7a/8AepiTHUtR7G/vUu1v71Idx9FM2t/eo2t/eoC4 6sTWpi0wQHha1pSY42ctwBXMzO0srMx6mmBGAWYAc5rprOLyYUX2rD06AzXSgdBzXQFGyOaY mTUVHtf+9S7W/vUh3H0Uza/96ja396kFx9FM2t/eow3rQFx9FM2t/eoCv/eoC45ulFMZWI60 APjrTC5JRTNrf3qNrf3qQXH0Uza/96ja396gLjqKbhvWjD+tAXH0UzDetGG9aAuOHelqIK2T g07D+ophcfRTMP60bX9aQXH0lNw/qKMN60BcfRTNretGG9aAuPpp6ikw/qKaytkc0wuS0UzD +opMP6ikFySimYb1pNr/AN6mFySimYb1ow/qKQXH0UzD+oow3rQFxx6UDpTGDbTzSIHx1FOw r6ktFMw/qKMP6ikO4+imYf1FBD+ooC46im4b1FGH9RQFx9FMw/qKMN6igLijqaWowrbjg07D +ophcdRTcP6ijD+opBcdRTcP6ijD+ooC46im4f1FGH9RQFx1IeopMP6imuGOOadgbJKKZh/U UYf1FILklJTcN60Yf1FAXH0UwB+5FGH9RQFx1FN+f2ow/qKAuOPSgdKad2Oaau8CmFySim/P 7Ug3+1ILj6Kb8/tR8/tQFx1FN+f2o+f2oC46im/P7UfP7UBcUfeNLUR37+Kd+89qdhJj6Kb8 /tR8/tSHcdRTfn9qPn9qAuPopnz+1Hz+1AXHUjU35/akbfjnFMGySlqMb8dqP3ntSC4+im/P 7UfP7UBcdRTfn9qPn9qAuOopvz+1Hz+1AXHUi9KQ7sdqaoamFySim/P7UfP7UguOopvz+1Hz +1AXHUU35/aj5/agLjqKb8/tS/N7UBcP4qWozv3cU75/amFx1FNO/tij5/akFx1FN+f2o+f2 oC46im/P7UfP7UBcdSN0pPn9qa+7HOKYNkg6UtIOlLSGFFFFABRRRQAUUUUAFFFFADR9406m j7xp1ABRRRQAUUUUAFFFFABTWp1NftQA6iiigBkv+rbHpXJS/wCsYn1rq7g4gf6Vyb/eP1oA u6ZbR3LMr+nFMvdPktmJHKetXNCAJdsc1sOiyAqwBBpiOPPFWba+mtj8jcehrQvtIzl7cf8A AayXjaNtrqVYUrDubdtq6SDbL8h9a0YmDICDkGuQ5qRLmaPhJGA9M0gOrmfZEzegrk5GLyM2 epq4NUla3aN+SRjNUD1pgbmhxYjaT1Na1UdJVVs1weT1q9QAtFFFABRRRQA3+KnU3+OnUAJR RS0AJiilooAKKKKACmv0p1MfpQJjh0oNA6UHpQM5nVX3Xj+3FR2May3Coy5Bpb9w15IR0zUu j5+2A+1MQl7p0luxZRmOqWMV2JUMMEZFZN/pW4l4Bg9xRuBkQ3Mtu2Y2INakGtcASpz6isiR GRiGBBpp+tIZ1kFzFcJmNgakTvXJwzvC+5GINdFp90s8XJ+YdaAKuusNiL3zWNGpaRQPWtPX HzMi+1UrJA91GD0JpgdPAu2JR7VJTVGAKdSASlpDS0AFFFFADf4qdTT96nUAFFFFABRRRQAU UUUAFI3SlprdKAFHSihegpsriONmboBQBl61dbUEKnk9axOM1NcymadnPc0W0JnmVAOppiNP RbXAM7D6Vs0yKMRxqijAAp9JjCiiigApq9TTqavU0CHUUUUDCiiigAooooAKKKKAEPUUtNPU U6gAooooAKKKKACiiigApD0paQ9KAAdKWkHSloAKKKKACiiigAooooAKaPvGnU0dTQA6iiig AooooAKKKKACiiigBp6inU1uop1ABRRRQAUUUUAFFFFABSHpS0h6UAA6UtIOlLQAUUUUAFFF FABRRRQAU3+I06k70ALRRRQAUUUUAFFFFABRRRQAhpaRqWgAooooAKKKKACiiigApKWkoAF6 UtNXpTqACiiigAooooAKKKKACk70tN/ioAdRRRQBDdP5du7egrlnO9j6mtrW5tsaxA9eTWXZ xebdIvUZzTQG7psHkWig9TyauUgGABS0gCiiigBDS0h6UtABRRRQAUUUUAFFFFABRRRQA1ad TVp1ABRRRQAUUUUAZ2sT+Xb7B1eufzV7VZvNuyOy8VViQySqo6k4pgbOiwlYjIf4ulaR+8Kb BGIoVQdhTj94UCHUUUUhhRRRQAUUUUAFFFFACHpS0jdKKAFooooAKKKKACiiigAooooAQd6W mjvTqACiiigAooooAKKKKACkPUUtIeooAWiiigAooooAKKKKACiiigBD0oHSg9KF6CgBaKKK ACiiigAooooAKKKKAGjqadSDqaWgAooooAKKKKACiiigApp6inU09RQA6iiigAooooAKKKKA CiiigBD0oHSg9KB0oAWiiigAooooAKKKKACiiigBo+8adTR9406gAooooAKKKKACiiigAprd qdTW6UAx1FFFABRRRQAUUUUAFFFFACUi9KdTV6UAOooooAKKKKACiiigAooooAb/ABU6m/xU 6gAooooAKKKKACiiigApr9KdTJPu0ITHClpB0paBhRRRQAUUUUAFFFFABRRRQAwffNPpo+8a dQJBRRRQMKKKKACiiigApr9qdTW7UAOooooAgu222znrxXJseT711l4M2z/SuSbqaANbRLiO MsjkAnpWyZox1dR+NcfuK9DzTvMJ6kn8aQzqXv7ZOsq1BPLY3I2s6knvXOFs0uad2IvXNiqt +6lVh6Zqk8bI3IpOaCT60AIcjmkzSmm85pAbGlXixgRucfWttXVhkMDXGAmrEN3LA3yMcHtR cZ1tFYkWuHjfF+RqdNahP3kYfrRcRqUtUk1O1Yf6wD61KLy3bpKv50wJf46fUKyoz5DA/jTw 6nowoBDqWmCRP7wo8xP7w/OgB1FMeVEXJYYrHudZdJSsaDA70AbdFc2dXuSSQQPwqxBrTjAl TPuKVwNymydKqRapbSD7+0+hpZb+3AP71T9KaYMuDpUVy4SFmzjArOfWogMKjE1QudTkuI2Q jAoApyMWcn1NXtFYC55OOKzjT4pWjcOvY0AdiKKyrbV43IVxtNaSyBgCDkGgCteWCXK9gR3r HudLmhJKruX2ro803zEJIyM07isceQQcEc09HeNgyMQa6G7sIJ/mGFf1FYslpKrkFCQO4osF yOeZpn3OcnpVjShm9WqR6mr+kf8AH4v0oGdGKWkFLSAQ0tFFABRRRQA0/ep1NP3hTqACiiig AooooAKKKKACmt92nU1ulACr0rK1q52RiJTyetabMEjLE4wK5e7mM87OT1PFAEGcmt3RbfbG ZWHLdKxreIzTKg7murhQRxqg7CmIfRRRSGFFFFACU1fvGnU1ByaBD6KKKBhRRRQAUUUUAFFF FADT1FOpp6inUAFFFFABRRRQAUUUUAFIelLSHpQADpS0g6UtABRRRQAUUUUAFFFFABTF+8af TR940CHUUUUDCiiigAooooAKKKKAGt1FOprdRTqBBRRRQMKKKKACiiigApD0paQ9KAAdKWkH SloAKKKKACiiigAooooAKb/EadTf4jQA6iiigApKWigAooooAKKKKAGtS0jU6gAooooAKKKK ACiiigApKWkoARelOpq9KdQCCiiigAooooAKKKKACm/xU6k/ioAWkPAparX04gtmYnk8CgDC 1CczXbHsOKu6HFkvKfpWUMySADqTXTWcAt7dUHXvTEWKKKKQwooooARqWkbpS0AFFFFABRRR QAUUUUAFFFFADVp1NXvTqACiiigAqC7lENuzE44qesjW58BYgfc0AZDtucknmr+jQeZOZD0W s3PPHeuj0qDybYEjluaYi9TT94U6mn7wpDHUUUUAFFFFABRRRQAUUUUAI3SgUN0paACiiigA ooooAKKKKACiiigBq96dSDvS0AFFFFABRRRQAUUUUAFNPWnUh60ALRRRQAUUUUAFFFFABRRR QAh6UDpQelC9KAFooooAKKKKACiiigAooooAaOpp1NHU06gAooooAKKKKACiiigApp6inU09 RQA6iiigAooooAKKKKACiiigBD0oXpQelA6UALSUtFABRRRQAUUUUAFFFFADf4jTqb/FTqBI KKKKBhRRRQAUUUUAFNanU1qAHUUUUAFFFFABRRRQAUUUUAFIvSikXpQA6iiigAooooAKKKKA CiiigBv8VOpv8dOoAKKKKACiiigAooooAKZJ0H1p9NfpQhMUdKWkHSloGFFFFABRRRQAUUUU AFFFFADR9406mj7xp1AkFFFFAwooooAKKKKACmt2p1NagB1FFFAEc67oWX1FclKm12X0NdgR kVhX+mytcFolyDQBkhfzrSttHkmQOzhAe1TWOkNvDzHAB6VtgADAp7C3MYaFzzLx9KeNDjzz ITWvRRcLGQ2iJjIlbP0qIaGW580D8K2z0pE+7RcLGOuhc8y/pRJoYCkrIc+mK2aKLhY4+WJo 3KMpyDTPLY9jXXvBG5yyAn6UCCIZxGvPtRoPU5ALS9uldY1rA5y0Sn8KjbTbVv8AlkPwo0Fq cvSg4roW0e2Y5AYfjUDaGm75ZSB7ilYDGDt2JH40eY46MfzrXOiDOBL+lI2ht2lH5U7BcyBI 46O350okb+8fzrTGhyf89FpRocmeZVx9KVh3MsySEcscemaZx3rY/sN+8o/KopNEmXlHVqLB cyz7UDNaaaNMQSSBU0WiE/6x8fSiwXMfBoPWt5dEiH3nY0j6LEOQ7U7CuYJ69aD+Fbh0NMcS n8qyrqBoJShz9TRYdyvSUpHNGBSAXpU6Xs6LtErAVCFyOKckTP8AdUn6CiwXJ/t9xjHmtioT M5OS5yfejyZCcBGz9Kd9ml/55t+VFguNEzg5Dt+dOe5lZdpc4NSLYXDYAjPNMnt5IfvrinYV yKrWnPsu05wKq1LaAm4TA70hnWryKWmp90U6gAopKWgAooooAafvCnU0/eFOoAKKKKACiiig AooooAKa3SnU1zhSaAM7V7jy7fywfmasE81b1GbzblucgcVUUZYAdTTEa+iWuSZ27cCtqoLS IQ26IPSp6TGFFFFABRRRQAUxfvGn01epoEOooooGFFFFABRRRQAUUUUANPUU6mnqKdQAUUUU AFFFFABRSUtABSHpS0h6UAA6UtIOlLQAUUUUAFFFFABRRRQAU0feNOpo+8aBDqKKKBhRRRQA UUUUAFFFFADW6inU1uop1AgooooGFFFFABRRRQAUh6UtIelAAvSlpB0paACiiigAooooAKKK KACmj71Opo+8aAHUUUUAFFFFABRRRQAUUUUANalpG7UtAC0UUUAFFFFABRRRQAUhpaQ0AIvS nU1elOoBBRRRQAUUUUAFFFFABTf4qdTf4qAHVja5NlkiB9zWu7bVJPauXu5WmuGc+tCAfpsP nXajsOTXTDgVl6JBtjaU9+K1abEgooopDCiiigBGpaRqWgAooooAKKKKACiiigAooooAaven U1e9OoAKKKKAEY7VJPauXvpvPuWft0rc1SfybUgH5m4rnDyeaAJrKHzrlExxnmuoUBVAHQVk aJb/AHpj9BWzTYgpp+8KdTT94UhjqKKKACiiigAooooAKKKKAGt0paG6UUALRRRQAUUUUAFF FFABRRRQA1e9Opq96dQAUUUUAFFFFABRRRQAU09RTqaeooAdRRRQAUUUUAFFFFABRRRQAjfd NC/dFB6UDpQAtFFFABRRRQAUUUUAFFFFADR1NOpq9TTqACiiigAooooAKKKKACmnqKdTW6ig B1FFFABRRRQAUUUUAFFFFACHpQOlB6UL0oAWiiigAooooAKKKKACiiigBo+9TqaPvU6gSCii igYUUUUAFFFFABTW6U6mt0oAdRRRQAUUUUAFFFFABRRRQAlIvSlpF6UAOooooAKKKKACiiig AooooAb/ABU6m/xU6gAooooAKKKKACiiigApr9BTqa/QUCYopaQUtAwooooAKKKKACiiigAo oooAbj5qWkHU06gBKKWigBKKWigApKWigBKRh0p1IaACloooAKSlooAKSlooASloooAQ9KRP u0ppF4FAhaKWigYlFLRQAlLRRQAlFLRQAzHz06k/ip1ACUYpaKAEopaKAEopaKAEpH6U6mt0 oBi44qrd2MdyMsPmHerVLRcDMi0eBM7/AJqc2kWzMCFI9hWjRTuKxVjsLeMYEYPuamSFEGFU D6CpKKV2Fhmweg/Kqt1ewWxw/J9BVw9K5bUc/a3HOM96YzZg1OGaQIMgnpU0tpHcIQ4z6VzC FkYFTgiun09y9spY5NCYmZraK5c4YAVftNNityG6sO9XaWi4WEopaKQxKKWigBKWiigBp+9S 0h606gBKWiigBKWiigAooooASquoTeTbM2eccVarD1q4LSCJc4HWgDKZiTk96u6Xb+fcgkZV eapV0Gj2xit97dW5piNEdKKWikMKSlooAKKKKAEpq/eNPpq9TQIWloooGFFFFABRRRQAhopa KAGnqKWg9RS0AFFFFABRRRQAlFLRQAlB6UtIelAAM4ooHSloASilooASloooAKKKKACmDO40 +mjqaBDqTvS0UDCiiigAooooAKKKKAGN1FOpD1FOoEJzRS0UDCiiigAooooASg9KWkNACLnF LQOlLQAUUUUAFJS0UAJS0UUAFNGdxp1J3oAWkpaKACiiigBKKWigApKWigBjZwKdSN2p1ACU UtFACUUtFACUUtFACUGlpKAEXOKWkXpTqAQlFLRQAlFLRQAlFLRQAlJ/FTqT+KgClqs/lWpA 6twK55FLOABya0dZnDziMHhaj0mISXYJ5C800I3LWMR26KBjAqaiikMKSlooASilooAa3Slo NLQAUlLRQAlLRRQAlFLRQAlFLRQA1O9LQKWgBKKWo7iQRQs57CgDD1ibzLnYDwlUEQu4A6k0 srmR2YnknNXdHt/Nud56JzTEbVpCILdUA6CpqWikMSmn74p9NP3hQJi0UtFAwpKWigBKWiig BKKWigBjnC04dKRulLQIWiiigYUUUUAJS0UUAFJS0UANXvTqavenUAFFFFACUtFFACUtFFAC Uh+8KdSHrQAUUtFACUUtFABRRRQAlLRRQA1jxQvQUrdKF6CgQUtFFAxKWiigAooooASilooA avU06kHU0tACUUtFABSUtFACUtFFABTW6inU09RQAtLRRQAUlLRQAUUUUAFFFFACHpSL0pT0 oHSgAopaKACiiigBKWiigAooooAYPvmnUg+8adQJBRRRQMKSlooASloooASkbpTqa1AC0tJS 0AFFFFACUUtFABRRRQAlIpyKWkXpQIdRRRQMKSlpKAFooooAKKKKAGZ+en03+KnUCEoopaBh RRRQAUUUUAFMfpT6a/ShCYo6UtIKWgYUUUUAFFFFABRRRQAUUUUARkEvwcUpDetKPvGlpisN w3rRhvWn0UgsMw396jDetPooCwzDetBDetPooCwzDetI4bHBqSkNMLDAHx96lw3rT6KQWGYb 1ow3rTqKAsNw3rQA396n0lAWG4b1ow3rT6KAsMw2OtIobHWn0DpTCw3DetGG9afRSCwzD+tG H9RT6KAsMw3rR83tT6KAsM+b2o+b1FOooCxGd2/infP7Uv8AFS0wsMw/qKX5/UU+ikFhnzUf N7U6igLDfm9qPn9qdRQFhvze1I+7bUlNbpTBoau/Hal+f2p1FILDfn9qPmp1FAWE+b2pPm9q fRQAw7/asnVLGSQ+ai7j6CtiincLHMQWE0smCjD1JFb1tE0MYRecd6s4pFouFhPnz2oy+e1O opBYb83tRlvSnUUBYb8/oKPn9BTqWgLDMv6CgFvSnUUBYjYtuHFOy/oKX+KlphYblvSjLelO opBYbl/QUZb0p1FMLDct6UZb0p9FILFe4mMMLOwwAK5iWUySl2OSTWxrk5VFiHfk1hnrQBPa R+dcKnqa6ZNyIFC9Ky9Dtx80xHPQVs0wGhm/u0Zb0p9FILDMt6UZb0p1FAWG5b0oy3pTqKAs Ny3pTQzbjxUtNXqaYNCbm/u0uW9KWikAmW9KTLelOpaAG5PpSZb0p9FADMt/dpQT6UtFAWGO zDGBShm/u0p6inUwsMDN3WlyfSlpaQDMt6UuT6U6igBm5vSl3HPSlooATJ9KQk46U+kPSgBi s2OlLuP92nDpRTCwm4+lJuPpT6KQDdx9KNx9KdRQA3J9KNxz0p1FADcn0poY7ulSU0dTTAMn 0pNx9KfRSAbuPpRuPpTqKAG7j/dNJuP900+igBu4+lG72NOooAjkYjGBShzj7ppWHIpaYWdx u4/3TRuPoafRSAbuPoaNx9DTqKAG7j6Gjd7GnUUAM3n+6aXPHSloPSgBgc/3aXf7GnDpS0ws xu72NG72NOopAN3expCx9KfRQA3d7Gk3f7Jp9FADc+1NL4PSpKbgbqAYbuOho3exp1FADd3s aTf7Gn0UAN3+xo3exp1FADd3saN3tTqKAI2fA6UofI6GlNLTDUbv9jS7/Y0tFINRN/saN/sa dRQA3d7UbvY06igBu72NG72NOpKAGLIORS7/AGNKoGKWmCuN3j0NLv8AY06ikA3d7Gjd7GnU UAM3+xo3j0NOooDUbvHoaimnEalj0AqesnWptqrGDyetNA7mTLIZZWc9Sa2tJhEMO4j5mrHt IjPcKnvXUooVQo7UAJvHoaXcKdRSAbuFJvHvTqKA1E3j3o3D3paKA1Gs4xRvGKVhkUuKYajd 496N4p1FINRpcD1o3j3p1FAaibxRvHvS0UAN3j3pdwpaKAGCQc5pfMWlUDmlxTDUbvFZusXG IhGp5PWtQ4Arm9Qm867YjoOBQGpU71vaRGIrfcerc1iwR+bMqeprqYkEcaqBwBQAbx70u8e9 LRSDUQOD601nAIp9NIBYUwdxd4xRvFLRSDUTePejeKWigNRN4o3ilooATeKN4paMUBqNLjFG 8UpHFLgUw1E3ijeKWikGom8UbxS0UANLgUbxTqKA1E3ijcKWigBocZNLvFAHWlxTDUTeKN4p cUYpBqN3il3ilxRigNRN4o3ilxRigNRu8etIzgEU/FIQCRkUw1DeKTeKdgUYHpSDUTeKN4pc CjAoDUTeKN60uB6UYHpQGom9aNwpcCjFAajWYYpFkGOacwGKFUAUw1uG8Ub19aXAowPSkGom 4UbxS4HpRigNRN49aN49aXA9KMCgNRN4o3r60uB6UYoDUaHGTS7xSBRk8U7AphqJvHrRuFLg elGBSDUTePWjePWlwPSjFAaib19aNw9aXA9KMD0oDUTcPWkZhxTsD0pCBxxTDUN4o3r60uB6 UYHpSDUTevrRvX1pcD0owPSgNRN6+tG8etLgelGB6UBqJuFG9fWlwPSjA9KA1ELDHWkVwR1p SBjpSKgA6Uw1DevrS719aNo9KNo9KA1DcPWjcPWlwPSjA9KQaibh60bh60uB6UbR6UBqJuHr RuHrS4HpRtHpQGozeA3Wnbh603aC3SnbR6U9BK4b19aNw9aXA9KTaPSkPUNw9aNw9aXA9KTa PSgNQ3D1o3r60uB6UYHpQGogdfWkZgBS7R6UjKCKYagHUjrS719aAoHal2j0pBqJuFG5R3pd o9KMD0oDUTcPWjevrS4HpSbR6UBqG8etG4etLgelGB6UBqJuFIrCnYFNVQM8Uw1F3D1o3D1p cD0owPSkGom9fWjevrS4HpSbR6UBqG4etG4etLgelG0elAaibh60bh60u0elGB6UBqNLgNS7 h60hUFqXaPSmGob19aNw9aNo9KXA9KQaibh60bh60u0elGB6UBqJuX1o3D1pdo9KMD0oDUTc PWmuwwBT8D0prqMDtTQO44UtIKWkMKKKKACiiigAooooAKKKKAGj7xp1NH3jTqBIKKKKBhRR RQAUUUUAFNanU1u1ADqKKKACiiigAooooAKKKKAEPShelB6UL0oAWiiigAooooAKKKKACiii gBv8VOpv8VOoAKKKKACiiigAooooAKa/SnU1+lAmL2paTtS0DCiiigAooooAKKKKAE7Vmzat FBKUKlsdxWkwypFctqETRXDA9CeKAOgs72O6TI+U+hqzXIwSvDIGU8iuksLr7VDuxgigC3RR RQAlLRRQAUUUUANP3hTqafvCnUAFFFMklSMZdgB70AOpazZdXgjbC5b6VD/ba5/1Rx9aANik Y4BNUYdVt5TgttPvVmaQCBnU54oA53UJjNcsSeBwKrRqXkVR1JodtzE+pqfT13XicdKaEzo7 SEQ26oPSpqRfuinUhhRRRQAUUUUAFFFFABTV6mnU1epoEOooooGFFFFABRRRQAUUUUANPUU6 mn7wp1ABRRRQAUUUUAFFFFABSGlpD0oAB0paQdKWgAooooAKKKKACiiigApo+8adTR1NADqK KKACiiigAooooAKKKKAGt1FOprdRTqACiiigAooooAKKKKACkPSlpD0oAB0paRelLQAUUUUA FFFFABRRRQAUnelpv8RoAdRRRQAUUUUAFFFFABRRRQA1u1OprdqdQAUUUUAFFFFABRRRQAUl LSUAIvSnU1elOoBBRRRQAUUUUAFFFFACE4BJrmb+YzXTHqAcCtrVJjDaHHU8VzqKZJAB1Jpg a2iW33pmHsK2ahtohDAiDsKmpMAooooAKKKKACiiigBDS0h6UtABRRRQAUUUUAFFFFABRRRQ A1adTVp1AFa+m8i2du+OK5ljliT1rW1uflYgfc1kDmmBqaJBulaUjgcCtyqmmxeVaIO55q3S YBRRRQAU0/ep1NP3hQA6iiigAooooAKKKKACiiigBrdKWkbpS0ALRRRQAUUUUAFFFFABRRRQ A1e9Opq96dQAUUUUAFFFFABRRRQAUh60tIeooAWiiigAooooAKKKKACiiigBD0oHShulA6UA LRRRQAUUUUAFFFFABRRRQA1epp1NHU06gAooooAKKKKACiiigApp6inU09RQA6iiigAooooA KKKKACiiigBD0oHSg9KB0oAWiiigAooooAKKKKACiiigBv8AFTqaPvU6gAooooAKKKKACiii gApDS01qAHUUUUAFFFFABSUtJQAtFFFABTV6UtC9KAFooooAKKKKACiiigAooooAb/FTqb/F TqACiiigAooooAKKKKACmv0p1NfoKBMUUtIKWgYUUUUAFFFFABRRRQAUUUUANH3jTqYD85p1 AhaKKKBhRRRQAUUUlAC01u1LSN2oEx1FFFAwooooAKKKKACiiigBD0oHSg9KRfuigB1FFFAB RSUtABRRRQAUUUUAN/ip1N/ip1ABRSUtABRRRQAUUUUAFNfpTqY5+WgTHdqWkB4paBhRRSZo AWikpaACiikoADWJrMTNhgpIFbdR7FcEMARTQmcrDBJK4RFJJrpbC3NvbhG61OqIv3VA/CnU ALRRRSGFFJRQAtFFJQAh+8KWmk/OKZczrbxF27UARX14ltHyfmPQVzs9w87Zdifai4ne4lLH JJPAq9ZaSZQrzHavp3p2C5mHrRggc11KWNun3Yl/GnPaQSDDRL+VGgjk881Mt3MkRQOdp7Vq 3WjLgtAefQ1kTQvC+2RSDRYLkWa0NHTdclvQVQxzV/SriOGUq4wW70kDOiX7opaRGBUEUtAx aKSloAKKKKACiiigApq9TS01TyaBD6KSloGFFFFABRRRQAUUUUANPUU6mn7wp1AgooooGFFF FABRSUtABSHpS0jdKABegpaRegpaACiiigAopKWgAooooAKaOppaQfeNADqKKKACiiigAooo oAKKKKAGt1FOprdRTqBBRRRQMKKKKACiiigApD0paQ9KAAdKWmr0p1ABRRRQAUUUUAFFFFAB TR1NOpo+8aAHUUUUAFFFFABRRRQAUUUUANbtTqa3aloAWikpaACiiigAooooAKQ0tJ2oARel OpqdKdQCCiiigAooooAKQ9KWq95MIbdmJwccUAYuq3JluCoYlF4xS6RbCafew+Vaokl3z3Jr otOgEEIH8RGTTEy5S0UUhhRRRQAUUUUAFFFFADWp1NbpTqACiiigAooooAKKKKACiikoARe9 KxCqSe1IvSq2ozeVat6nigDBvJfOuXftnils4TNcqqjjvUJ5rV0OE7mlPToKYjYUbVAHaloo pDCiiigApp+8KdTT94UAOooooAKKKKACiiigAooooAa3SlpG6UtAC0UUUAFFFFACUtFFABRR RQA0d6dTR3p1ABRRRQAUUUUAFFFFABSHqKWkPUUALRRRQAUUUUAFFFFABRRRQAjdKB0oboaF 6UALRRRQAUUUUAFFFFABRRRQA0dTTqavU06gAooooAKKKKACiiigAprdRTqaeooAdRRRQAUU UUAFFFFABRRRQAh6UDpQelA6UALRRRQAUUUUAFFFFABRRRQA0feNOpo+9TqACiiigAooooAK KaSewp1ABTW6U6mt2oAdRRRQAUUUUAFFFFABRRRQAlIvSlpF6UAOooooAKKKKACiiigAoooo Ab/FTqb/ABU6gAooooAKKKKACiiigApj9KfTX6UCYo6UtIKWgYUUUUAFFFFABRRRQAUUUUAM A+Y0+mj7xp1AkFFFFAwooooAKKKKACmmnU1qAHUUUUAFFFFABRRRQAUUUUAIelC9KD0oXpQA tFFFABRRRQAUUUUAFFFFADf4qdTf4qdQAUUUUAFFFFABRRRQAU1+lOprdKBMUdKWkpaBhRRR QAUUUUAFJS0UAJSL3paRaAHUlLTWyVOOtAFC81RLZ9gXc31p9nqUd0duCrehrBvAwuXDnnNR wF1kBjJ3Z4oA6+lqK3LtCpcYbHNS0AFFFFADD96sPV7oyS+UOFXr71tSnbk+grl7hvMnZuuT TEW9IthNNvZSVWuhAAFVdOhEVqg7kZq3QxiUtFFIBKhurWO5Ta4+hqeigDmL2xktm5BKdiKq DrXYOiupVhkGsG/01oCZI/mT+VPcQ/TtSMeIpeV6A+lbgIIyOlchjFaem6gUKwyHIPQ0hm7R SA5GRS0AFFFFABRRRQAlNUcmn01epoEOooooGFFFFABRRRQAUUUUANPUU6mnqKdQAUUUUAFF FFACUUtFABSHpS0h6UAC9KWkXpS0AFFFFABRRRQAUUUUAJSAfMadTF+8aBD6SlooGFFFFABR RRQAUUUUAMbqKdSN1FOoEFFFFAwooooAKKKKACkPSlpD0oARRxTqQdKWgBKWiigAooooAKKK KACmj7xp1N7mgB1FFFABRRRQAUUUUAFFFFADW7UtI3anUCEopaKBiUtFFABRRRQAUh6UtJ2o ARBxS0i9KdQJBRRRQMKKKKAErG1ufJWEH3Na8jiONnPQCuWuZvOnZ27nigCbTofOulHYcmuj VQGrP0a38uEyEct0rR/ipiFpaKKQxKWiigBKKWigApKWigBrDNLQaWgAooooASilooASiloo ASg0tFADEGAayNamy6xDoOTWxnCkmuavZPNuncHjNMRX4JxXS6fF5VogxgkZrBsYvOu0XHGc munAwAB2oYC0UUUhhRRRQAlNI+YU+mn7woELS0UUDEpaKKAEpaKKACiiigBrdKUdKRulLQAU UtFACUUtFACUUtFACUUtFADVHWlpB3p1ABRRRQAlLRRQAlFLRQAlIR8wp1NPWgBaKWigBKKW igApKWigApKWigBrdKUdKG6UDpQIWiiigYlFLRQAlLRRQAUlLRQA1epp1NHU06gAooooAKKK KACiiigBKRhyKdTW6igQtLRRQMKKKKACiiigBKWiigBD0pF6Up6UDpQAUUtFABRRRQAUUUUA JRS0UAMA+Y0+mj71OoEgooooGFFFFACUtFFACUjdKdTWoAWloooAKKKKACiiigAooooASkXp S0i9KAHUlLRQAUlLRQAUlLRQAUUUUANx81Opv8VOoASilooAKSlooAKKKKACmt0p1NfpQJij pS0gpaBhRRRQAUUUUAFFFFABRRRQA0dTS0wttf60u/8A2TTFcfRTN/saN/saQXH0Uzf/ALJp d3saAuOopu72NJv9jQFx9IaTd7GkZ8DoaAuPopgfj7poD+xoC4+im7vY0bvY0BcdRTd3saTf z0NAXH0U3d7Gjd7GgLinpQOlN3exoD8dDTC6H0U3d7Gjf7GkFx1FM3+xo3+xoC4+imb/AGNG /wBjQFx9FM3j0NLvFAXD+KlqMvhqd5g9DTsF0PopgkGeho3ilYLofRTN4o3iiwXH0UzePel3 igLjqa3Sk3ikdwBTsDY+lpgkGOho3j0NKwXQ+imbxRvHvRYLj6KZvFLvFAXHUUzeKXeKLBcW kXpRvFND4zmnYLklJTfMFAcGkFzM1DSzPJ5kXU9c0WWk+U4eYgkdAK1N4pN4pgOA4paYXAo3 jFKwXH0VSvNQS2XplvSq1rq/nSBHULn3oGWNTfZbsQcHFc/F/rVye9bWrsGtuKw432SBvQ5x TEjrYv8AVrj0p9c6+sTk/IFAq/p+peflZOG9aQzSpaZ5i0eYtFhXQ+imeYtV7m+jgU5OT6UW C5apsgDIQehrDOszbyVA2+lXrTUkuF2kYegbM7UbEwfvE5Q9vSqAOCPWupk2SxFHGQa5u5j8 qZl7A8VTJTN/TLoXFuB/EvBq7XOaTcGK525+Vu1dB5i+tKxQ+im7xRvFIVx1FN3CjevrQFx1 NXqaNw9aarAMaYXJKKbuHrRvX1pDHUU3cPWjcPWgLjqKbuX1o3D1oAdRTdw9aNw9aAA9RTqY zAEUu9fWgV0Oopu4etG4etA7jqKbuHrRuHrQFx1FN3D1o3D1oAdSHpSbh60FhjrQAo6UtMVw R1pdw9aBXHUU3cPWjcPWgY6ik3D1o3D1oAWik3D1oyPWgBaaOpo3D1pAwyeaBXH0Um4etJuH rQMdRSbh60bh60ALRSbh60ZHrQAtFJketGR60AIeop1MZgCMml3D1oFcdRSZHrRketAxaKTI 9aMj1oAWikyPWjI9aAFpD0oyPWgkYoAB0opFYEdaXI9aAFopMj1oyPWgBaKTI9aMj1oAWiky PWjI9aAFpB1NGRTdw3YoEPopMj1oyPWgYtFJketGR60ALRSZFGRQAtFJmjNACHtTqaxApcig BaKTIozQAtFJRmgBaKSjNAC0lFBPFACL0p1MQjHWnZoEhaKTNGRQMWikzQWAGSaAM3WZykIj U8t1rFgjMsyoO5qxqE/n3Tc8DgVa0aBTI0p5x0poRsRIEjVR0Apf4qWkyA1IY6ikzRQAtFJR QAtFJRQAtFJRQAGlprEAUuaAFopKKAFopKKAFopKKAFopKKAKl/N5Nq57ngVzh5yTWrrMpJW MEY61lDnimI1dDhy7SntwK2qp6bEIrRPU8mrdDGLRSUUgFoopKAFpp+8KWkJG7rQJjqKSigY tFFFABRSUtABRRSUAI3SlpG6UtAC0UUUAFFFFACUtJS0AFFJS0AIKWmg9adQAUUUUAFFJS0A FFFFABSHrS00nmgB1FFJQAtFFFABRRRQAUUUUAI3Q0DpQ3SgdKAFooooAKKKKACiiigAoooo AQdTS00dTTqACiiigAooooAKKKKACmnqKdTT1FADqKKKACiiigAooooAKKKKAEPSgdKD0oHS gBaKKKACiiigAooooAKKKKAGj7xp1N/iNOoEgooooGFFFFABRRRQAU1qdTWoAdRRRQAUUUUA FFFFABRRRQAU1elLQvSgBaKKKACiiigAooooAKKKKAE/ipab/FTqACiiigAooooAKKKKACmv 0p1NfpQJijpS0gpaBhRRRQAUUUUAFFFFABRRRQA0feNOpi/eNPoEgooooGFFFFABRRRQAUh7 UtNagB1FFFABRRRQAUlLRQAUUUUAIelIvSlPShelAC0UUUAFFFFABRRRQAUUUUAMwN3SnUn8 VOoEJRS0UDEopaKAEopaKAEpHHFOpr9KBMUAYoopaBiUtFFACUUtFACYopaKAEpqjrT6aveg QtGBS0UDEwKMClooATApCBilooA5rVyftZySRVFWIII61u6tp8k7CSIA4HIqhZ6dLLJlkICn nNOwhbudpLZFPHHSs+r2pjbPtHQVQA5pMaFGSK0dIiL3QOOAKu6PDFJbZZQTnuK00jSMYRQP oKYhcAVTudQt4CVJyw7CmX+oLbjavLH9K5+RzI5Ynk0hmodY+cnZx6Vn3VwbiQsePaoCaOpo AM1PaSFLhSDjJqIoduTSLw45oA7CIDYKx9bgVWWQDrwcVqWZzbpnrioNWTdaMe4piOfhbbMh PY11keGRSB2rkR1rqLE5tIz7UDLGB6UYHpS0UgE2j0owPSlooATA9KaqjJ4p9MXqaBDsCjA9 KWigYmB6UYHpS0UAJgelGB6UtFACYHpRgDtS0UAMZQSKXaPSlPWloFYTA9KMD0paKBiYHpRg elLRQAm0elG0elFLQAmB6UhAx0p1IelADQg9KXaPSlHSloFYTaPSk2j0p1FAxNo9KMD0paKA E2j0owPSlooATA9KbtBY0+mj7xoEG0elG0elOooAbtHpRtHpTqKBjdo9KNo9KdRQFhu0elG0 elOooAYyAkcUu0elDdRTqYrDdo9KNo9KdRSAbtHpRtHpTqKAG7R6UbR6U6igdhuxfSgqMdKd SHpQKw1UGKXaPSlHSloCw3aPSjaPSnUUDsN2D0o2j0p1FAhuwelG0elOooCw3aPSk2DdT6aO poCyDYPSjaPSnUUBYbsX0o2D0p1FAWG7RRsHpTqKBjdoo2inUUBYYyil2ig9qdQKw3YvpRsF LRQFkJsFG0U6igLDdgo2inUUBYbsFBUYp1IelAWGKgp2wUL0p1O4JDdgo2L6U6ikFhuwelU9 SkWG2JH3jwKvVha1OHmEa9F60wsZqgu2O5NdLZ2ywwKvfvWLpUBnuQT91eTXRgYFAWE2imlA WqSm/wAVILINgxRsFOooCw3YKNgp1FAWG7BRsFOooCw3YKNgp1FAWGFRijYKcaWgLDdgo2Cn UUBYZsFLsFOooCw3YKNg96dRQFhuwUhUYJp9QXknlWzt7UBY5+9l33DkdM0y1TzZ0XsTUbHc xNaGjRbpyxGQopgbSRBVAGaXYKdS0rhYbsFGwU6igLDNg9TRsFPoouFhmwe9NaMFhUtN/ip3 CyE2CjYPen0UrhYZsHvS7BTqKAsN2CjaKdRQFhuwe9JsHvT6KLhYYyAijYPenHpRTuFhNgo2 D3p1FILDdgo2D1NOooCwzyx6ml2D1NOoouFhuwUbR706igLEYTk80uwe9KvenU7hZDNg9TRs HqafRSuFhmweppdo96dRRcLDdo9TRtHvTqKAsNC/WmsmSKkpO9AWG7B6mjYPU0+ii4WG7B6m jYPU06igLDdg9TRt9zTqKAsN2j1NG33NOooHYYy8dTSKnHU089KB0pisJt9zRt9zTqKQWG7P c0bfc06igLDdvuaNvuadRQFhmz3NLt9zTqKAsRBMseTTtnuaUdTTqdwSQzZ7ml2+5p1FILDd nuaTZ7mn0UBYYE9zRs9zTqWgLDdvuaayZxyakpp6igLCbPc0uz3NOooCwzb7mjZ7mn0UBYZs 9zS7Pc06igLDdvuaTZ7mn0UBYYV46mkVD3Jp56UDpTCw3Z/tGjZ7mn0UrhYZs9zRs9zT6KAs MK57mjZ7mn0UBYbt9zRt9zTqKAsQ+Wd+c0/Z/tGlH3jTqdxJDdvuaTZ7mn0Uh2GbPc0bPc0+ igLDNvuaNh/vGn0UBYYEPqaRlOOtSU1qdwsIE/2jRt9zT6KQWGbfc0u33NOooCwzZ7mjZ7mn 0UBYbt9zRt9zTqKAsN2+5pqr7mn0i9KYWE2+5pdvuadRSCwzafU0bD6mn0UBYbtP940bfenU UBYbtPqaNvuadRQFiNkJYcml2n1NL/FTqYWGbfc0u33NOopBYbtP940bT606igLDdp9aTafU 0+igLDdvuaa69Oakpr8imDQo6UtIKWkMKKKKACiiigAooooAKKKKAGD75p9MH3zTqBIWikoo GLRRRQAUUUlAC01u1LSMOlADqKSloAKKKKACiiigAooooAQ9KRelKelIv3RQA6iiigAoopKA FooooAKKSloAb/HTqYPv0+gSCikpaBhRRSUALRSUUALTX6UtNfpQJju1LSDpRQMWikooAWik ooAWikpaAEpEPWlpqDANAh9FJRQMWiiigAopKKACkI4NLQaAOW1AkXUm71qoK0dXTZdN781n gUMDT0SbZMUP8XSt5uFJrk4GKSoynBBrqlO6EE9xTA5i+l825Y9gar4zU94ALl8etQKMnA60 gLMdhNLHvRcirNvpEzYL4A9K1NMtzDbDJyTzV3FPYRgarbiFEVVwvc1lj7wrp9QszdRgBsEV mxaNKsm52XAo3DY0NKDC2G4n2zU96AbWTcMjFSRIEjAHamXS5t3Ge1HUDlD1rptMYtZpn0rm m4Y10umAizjye1AFyikopDFopKWgApi9TTqamcmgQ+iiigYUUUlAC0UlLQAlLSUUAIeop1MP 3hTqAFooooAKKKKAEpaSloAKRulLTW6UAKOlLTV+7S0ALRRSUALRSUtABRRSUALTR940tNH3 jQIfRRSUDFopKKAFopKKAFopKWgBrdRTqa3UUtAhaKKKBhRSUtABRRSUALSHpRSN0oAVegpa av3RS0ALRRRQAUUUlAC0UlLQAU0feNOpo+8aAHUUUlAC0UUlAC0UUUAFFFFADW7U6mt2paBC 0UUUDCiiigAoopKAFpDS0h6UAInSnU1OlLQJC0UUUDGSsEjZj2FcrO/mzM57mtzV5zHbbV6t xWHAhkmVB3NNAbmjweVbbj1bmtGmRqEjVR0Ap1IBab/FTqb/AB0AOooooAKKKSgBaKKSgBaK SigANLTW7UtAC0UlLQAUUlFAC0UlFAC1l61LtiVAeSa0zXParMZbogfw8UAUfyroNIh8u2Dd 25rBjUvIFA5JxXVQJshVfQUxElFJRSGLRRSUALRSUUALTT94UtNP3qAH0UUUAFFFJQAtFJS0 AFFFJQAjdKWkbpS0ALRRSUALRRRQAUUUUAFFFFADV706mr3p1ABRRRQAUUlLQAUUUUAFJ3op D1oAdRSUtABRRRQAUUUUAFFFJQAN0NA6UjfdpV6CgQtFFFAwooooAKKKKACikooARepp1MXq afQJBRRSUDFoopKAFopKKAFpp6inU1jyKAHUUlLQAUUUlAC0UlFAC0UlLQAh6UDpQelIp4oA dRSUZoAWikpaACiikoAWiikoAQfeNOpgPzGnUCQtFFFAwooooAKKKKACmt2paRj0oEx1FJS0 DCiiigAoopKAFopKKACkXpS0i9KAHUUlLQAUUUlAC0UUlAC0UlFACfxU6m/xUtAC0UlFAC0U lLQAUUUUAFNfoKdTHPAoEx1LSDpS0DCiiigAooooAKKKKACiiigBo+8adTR9406gAooooAKK KKACiiigAprdqdTWoAdRRRQAUUUUAFFFFABRRRQAh6UL0oPShelAC0UUUAFFFFABRRRQAUUU UAN/ip1N/ip1ABRRRQAUUUUAFFFFABTX6U6mv0oEL2paTtS0DCiiigAooooAKKKKACmr3paR e9Ah1FFFAwooooAKKKKACiiigDF1yPlXx7VkJgOuema6PUojNAygc4zXNkYODTEjoLfTrVlW RVJzz1rRCgDA6VlaJPuiMTHkdK1qGxmLqOmyy3BeJRg02z0mQOGmwAO1bdLRcQijaABS0UUh hTW+6adTW6UACfdFU9VcpaNtOCeKuLwtYms3QkcRIcgdcUwRlqCzgA8k11VpH5VuinrisHTI DNdKcfKvJrpBQIWiiikMKKKKACmr1NOpq9TQIdRRRQMKKKKACiiigAooooAaeop1NPUU6gAo oooAKKKKACiiigApG6UtIelAAvSlpB0paACiiigAooooAKKKKACmj7xp1NHU0CHUUUUDCiii gAooooAKKKKAGt1FOprdRTqACiiigAooooAKKKKACkPSlpD0oAB0paQdKWgAooooAKKKKACi iigApo+8adTR96gB1FFFABRRRQAUUUUAFFFFADW7U6mt2p1ABRRRQAUUUUAFFFFABSHpS0h6 UAIvSnU1elOoBBRRTJGCRsx7DNAGFrEu+529lp2jQ77guRwoqjPIZJmc9zW7pEXl2gJ6tzTA v0UUUgCm/wAdOpv8VADqKKKACiiigAooooAKKKKAENLSGloAKKKKACiiigAooooAZK+yJmPY Vysrl5GYnqc1v6tL5dqQOrcVzx69KYFzSohLdjOfl5roqy9Eh2xtIR1rVoYBRRRSAKKKKACi iigApp+9TqafvCgB1FFFABRRRQAUUUUAFFFFADW6UtI3SloAWiiigAooooAKKKKACiiigBq9 6dTV706gAooooAKKKKACiiigApp606k70ALRRRQAUUUUAFFFFABRRRQAjdKB0obpQOlAC0UU UAFFFFABRRRQAUUUUANXqadTV6mnUAFFFFABRRRQAUUUUAFNPUU6kPUUALRRRQAUUUUAFFFF ABRRRQAh6UDpQelA6UALRRRQAUUUUAFFFFABRRRQAwffNPpo+8adQJBRRRQMKKKKACiiigAp rdqdTW7UAOooooAKKKKACiiigAooooASkXpS0i9KAHUUUUAFFFFABRRRQAUUUUAN/ip1N/ip 1ABRRRQAUUUUAFFFFABTX6CnU1ulAmKOlLSDpS0DCiiigAooooAKKKKACiiigBo+8adTR940 6gAooooAKKKKACiiigApDS0hoAWiiigAooooAKKKKACiiigBD0oXoKD0oHSgBaKKKACiiigA ooooAKKKKAGj71OpB96loAKKKKACiiigAooooAKa/SnU1hkUALS0lLQAUUUUAFFFFABRRRQA lIvSlpFoAdRRRQAUUUUAFFFFABRRRQAwgFsGud1OAw3JOPlbkV0X/LQVS1e28633DqnNMRiW U5t7hXzx3rqI3EiBlOQa488VsaZqKIghmOMdDSGbdFMR1cZUgin0AFFFFABSN0pGZVGSQKzL 7VVTMcPzN69qAJL+/WCIovLkflWASXbuSaV3aRyWOSa1NJsd376QcdqYi5pVq1vCS/VucVfp OlLSGFFFFABRRRQAU1epp1NXqaBDqKKKBhRRRQAUUUUAFFFFADT1FOpp6inUAFFFFABRRRQA UUUUAFIelLSHpQADpS0g6UtABRRRQAUUUUAFFFFABTR9406mjqaAHUUUUAFFFFABRRRQAUUU UANbqKdTW6inUAFFFFABRRRQAUUUUAFIelLSHpQADpS0g6UtABRRRQAUUUUAFFFFABTR9406 kHU0ALRRRQAUUUUAFFFFABRRRQA1u1OprdqdQAUUUUAFFFFABRRRQAUh6UtJ2oARelOpq9Kd QCCqepyiO1YZwW4FXKxNcky6R+nNAGbGhllCLySa6mFPLhVPQVhaPFvu9xGQoroabAKKKKQB Tf4qdSd6AFooooAKKKKACiiigAooooARqWkbpS0AFFFFABRRRQAUUUhOATQBia1NmcRjoorL GSeKnvH8y5kY9zSWkZkuUUHHNMTOhsU8u1RT1xVmmRjCgU+hghKWkFLSGFFFFABRSUtABTf4 qdTT94UAOooooAKKKKACiiigAooooAa3SlobpRQAtFFFABRRRQAUUUUAFFFFADV706mr3p1A BRRRQAUUUUAFFFFABSHrS0negBaKKKACiiigAooooAKKKKAEbpQOlDdKB0oAWiiigAooooAK KKKACiiigBo6mnUg6mloAKKKKACiiigAopKWgApp6inU09RQA6iiigAooooAKKKKACiiigBD 0oHSg9KB0oAWiiigAooooAKKKKACiiigBo+8adTR9406gSCiiigYUUUUAFFFFABTWp1NagB1 FFFABRRRQAUUUUAFFFFACUi9KWkXpQA6iiigApKWigAooooAKKKKAG/xU6k/ipaACiiigAoo ooAKKKKACmt0p1NbpQDFHSlpBS0AFFFFABRRRQAUUUUAFFFFADcgNzS5HrTCoZuaXy19KYtR 2RRkUmwUbBSDUXNGRSbBRsFAai5ozSbBRsFAai5pCcUbBSMgIphqOyKM03y1pdgpBqLRSbBR tFAC5opNgo2CgNRc0UmwUbBQGop6UinikKCgIMUBqOzRSbBRsFAai0U0oKPLHvQGo6ik2D3o 2CgNRaKbsFGwe9Aai/xUtRmPLdTTvLHqaYXY6im7B6mjYPU0BqPopu0eppNnuaQDqKbsHqaN nuaA1H01+lJsHqaR0yvGaYO48dKKYseB1NLs9zQGo+im7fc0mz3NIB9FM2e5o2e5oAfRTdnu aTZ7mgB1Ivejb7mmqnJOTTAkopuz3NG33NIB1FN2+5o2e5oAWlphTPc0bPc0APopmz3NLt9z QAfxUMAykHoaYyHcMGnbPc0wuzntSsjbSFlyUb9Ko11ktukqlX5FZtxowOTC+D6GgDMgvZ4O I3IHoavJrco+9GD71TlsbiI8xMR6iq5DL1GKLDua39un/nj+tMfW5WGEQKfWsnmnIGY4AJPt UoCea6mmOXcn2qEAkjFXIdMuZSMoVHqa1YNNigGT8zepq7CbKOn6Y0jCSUYX09a3FUIoVRgC mJGQOuKdsP8AepMSuPopmw/3jRtPrSHcfRTdp9aNp9TQA6im7T60m0+tADqRepo2n1pgUljy aYNktJTdp/vGjaf7xpAPopu0+tG0+tADqKZtPrRtP96gB1FN2n+9RtP96gBT1FLUbqcjBp21 v71MLj6KZtP96jaf71ILjqKbtP8Aepdp9aAFopu1v71G0/3qAuOoPSm7T/eoIOOtADh0opiq 2OG4pdrf3qYXHUU3Df3qCG9aQXHUtMw396lw3rQA6im4b1owf71AC0g6mjB9aaFbceaYXJKK ZhvWja396kFx1FNw396lw3rQA6im4b1pMN60BcdRTcN60uG9aAuB6inVFIG4pQHx1p2FcfRT cN60Yb1pDuOopuG9aXDetAXFopuG9aMP6igLj6Q9KbhvWht2DzQFxw6UVGgfHtTsP6imFx1F Nw3rS/N6ikFxaKT5vUUhDdjQFx1FJhvWkw3qKAuOoHWk+b1FMO/dxTC5JRTfn9qMN60guOop uG9RR8/qKAuOopvze1Hze1AXHUU35/aj5/agLintS0x9wFKN+O1OwXHUU35/agbu+KQXHUU3 5/al+agLi0U35vaj5vagLjqKT5vak+b2oC4q9KWo0344xTvn9qYJjj0rmL+Qy3bknvit+6la KB3JxgVzJ+diT1JoC5s6HHhHfHXjNatVLCNo7VBgDirPz+1DC46im/P7UHf7UguPpO9N+b2p pL7uKdguSUU35/aj5/akFx1FN+f2oO/2oC46im/N7UZf0FAXH0Uwb/al+b2oC4ppajfdtoBf HQU7BcfRTQX9BR83tSC46im5b0oy3pQFx1QXsgitnJ7jFS5f0FZeszMFWPjnmmFzIY/MeOa0 NGhDzNIf4elZ3Oa3tKhaO33EctzTAvr0p1RqX56UuX9BSC4+ioxv9BS/P6CkFx9FM+f2oy3o KAuPopmW9BRlvQUBcfTT94UgLelNcsGGBTSBslopmX9BR8/tSsFx9FMy/oKMv6CgLj6KZlvQ UZf0oC4+imZf0oy/pQFxzdKKYxbHSgF8dBTsFySimZb0oy/pSC4+imZb0oy3pQFx9FMy/oKM t6UBcdRTct6UuW9KAuA706olLbj6U7LelOwXH0UzL+lGW9KQXH0UzLelGW9KAuPopmW9KMt6 UBcfSd6blvSkYtkYFAXJKKZlvSjLelAXH0UzLelGW9KAuOopuW9KMt6UBcfRTMt6UZb+7QFx zdKB0pjFtvShWYj7tMV9SSimZb+7Rlv7tIdx1FNy392jc392gLjqKbub+7Rlv7tAXHUU3c39 2jLelAXFHU06ogzbj8tOy3pTC46im5b+7Rub+7SC4+imbm/u0bm/u0BcdS1GGb+7S7m/u0Bc dSHqKTc392kYtxgUwuSUUzc392jc392kFx9FM3N/do3N/doC46im7m9KNzf3aAuOopu4/wB2 jc392gLjjQOlN3EjpSKzY6UwuPopu4+lG4/3aQXHUU3c392jcf7tAXHUU3cf7tG4/wB2gLjq KbuP92jcfSgLij7xpaiLsH+7T9zf3adhJodRTdzf3aNx9KQ7jqKbub+7RuP92gLjqKbuP92j cf7tAXHUhpN5/umkZjjpTC6H0UwO2Puml3N/dosFx1FN3H+7RuPpSC46im7j/do3N/doC46i m7j/AHaNx/u0wuOpF6Um4/3aarN6UBckopu4/wB2jcf7tILj6Sm7j/dNAY/3aLBcfRTNx/u0 bj/dNAXH0Uzcf7tLuPpQFxe9FRlzu4Wnbj/dphcdRTd7f3aNx/u0guOopu4/3aNx/u0BcdRT dx/u0bj/AHaAuPpr9KTcf7tI7HHTFMGx4paQdKWkMKKKKACiiigAooooAKKKKAGj71LSD7xp 1ABRRRQAUUUUAFFFFACUjdqdTW7UAOooooAKKKKACiiigAooooAQ9KRTlaU0DpQAtFFFABRR RQAUUUUAFFFFADQfmp1N/ip1ABRRRQAUUUUAFFFFABTXOBTqa/SgTFHSlpKWgYUUUUAFJS0U AFJS0UAJSJ3paROlAh1FFFAwooooASloooAKKKKAG5+anU3+KnUAFJS0UAJUNxBHJE2UGcdc VNSMMqaAOQdcOwPY1r6Eq/OcAms27jMdy4I5zV3RHIuCo6EUxG9SN9006mt900hgv3RS0i/d FOoAKKKKACiiigAooooASmr9406mp940xMfRRRSGFFFFABRRRQAlLRRQA0nkU6mnqKdQAUUU UAFFFFABRSUtABSHpS0h6UAA6UtIOlLQAUlLSUALRSUtABRRRQAlIDyadTQPmNADqSlpKAFo pKWgAooooAKKKKAGt1FOprdRS0CFooooGFFFFABRRRQAlB6UUHpQADpS0i9KWgAooooAKKKK ACiiigApo+8adTQPmNADqKKKACiiigAooooAKKKKAGtTqawpaAClpKKAFoopKAFopKKAFpDR QelACL0p1MTpT6ARnazLstdmeWrFs4/NuUX3q5rUm64Cj+EUzR033YPoKaEdCowoFLSUUhi0 UUUAFN/ip1Nx81ADqKKKACiiigAoopKAFopKKAENOprCloAWiiigBKWkpaAErnNTmMt22Og4 reupPKt3bPQVyzsWYknk0wHRIZJVQdzXVRrsjVfQVg6RbmW43kcLXQY4oYhF6U6mrS0hhS0l LQAUUlFAC0UUlAC00/epaafvigB9FFJQAtFFFABRRRQAUUUlACN0paRhxS0ALRSUtABRRRQA UUlLQAUUUlACL3p1NXvTqAQUUUUAFFJS0AFFFFABTT1FOppHIoAdRSUtABRSUUALRRSUALRS UUADdKB0pG+6aVegoELRSUUDFopKKAFopKKAFopKKAEHU06mr1NLQCFooooAKKSigApaSigB aaeopaRhyKAHUUlLQAUUUlAC0UlFAC0UlFAAaB0oPSkXoKAHUUlFAC0UlFAC0UUUAFFFJQA0 feNPpg+8adQJC0UUlAxaKSigBaKKKAEpGpaRqAHUUlLQAUUUUAFFFFABRSUUAFIvSl7UiDig Q6ikooGLRSUUALRSUtABRSUUAJ/FTqZ/HTqAClpKKAFopKKAFopKWgApj9KfTH6UCY4UtIOl LQMKKKKACiiigAooooAKKKKAEHWlpo+8adQAUUUUAFFFFABRRRQAU1u1OprdqAHUUUUAFFFF ABRRRQAUUUUAIelA6UHpQvQUALRRRQAUUUUAFFFFABRRRQA3+KnU3+KnUAFFFFABRRRQAUUU UAFNfpTqY/TigTHUtJ2paBhRRRQAUUUUAFFFFACUi0tIvSgB1FFFABRRRQAUUUUAFFFFADf4 qdTf4qdQAUUUUAJS0UUAc5rC4vSfUUmkcXi84pdZfdeEY6Cm6SM3q96YHS0h6UtIelIAHSlp B0paACiiigAooooAKKKKACmr1NOpq9TQIdRRRQMKKKKACiiigAooooAaeop1NP3hTqACiiig AooooAKKKKACkPSlpD0oAB0paQdKWgAooooAKKKKACiiigApo6mnU0dTQA6iiigAooooAKKK KACiiigBp6inU1uop1ABRRRQAUUUUAFFFFABSHpS0h6UAA6UtIOlLQAUUUUAFFFFABRRRQAU 3+KnU0dTQA6iiigAooooAKKKKACiiigBrdqdTW7U6gAooooAKKKKACiiigApD0paQ9KAETpS scKSe1InSorx9ls59qBI5y8k8y5dxyCa1NDiwjSY68CsY8n8a6awjEVoi+2aYyzRRRSAKKKK ACm/xU6m/wAVADqKKKACiiigAooooAKKKKAGt0paGpaACiiigAoopDwKAMzWptsSxg8nrWH1 q3qU3m3Teg4FQQRtLMqDuaYjc0eLZaZI5Y5rQpkaeXGqjsKfSGNWnU1elOoAKKSloAKKKKAC iiigApp+8KdTT96gB1FFFABRRRQAUUUUAFFFFACN0oobpRQAtFFFABRRRQAUUUUAFFFFADR3 p1NXvTqACiiigAooooAKKKKACkPWlpp6igB1FFFABRRRQAUUUUAFFFFACN0oHSkb7ppR0oAW iiigAooooAKKKKACiiigBo6mnU0dTTqACiiigAooooAKKKKACmnqKdTT1FADqKKKACiiigAo oooAKKKKAEPSgdKD0oHSgBaKKKACiiigAooooAKKKKAGj7xp1NH3jTqBIKKKKBhRRRQAUUUU AFNanU1qAHUUUUAFFFFABRRRQAUUUUAJQvSikXpQA6iiigAooooAKKKKACiiigBv8VOpv8VO oAKKKKACiiigAooooAKa3SnU1+lAMUUtIKWgAooooAKKKKACiiigAooooAaPvGnU0feNOoAK KKKACiiigAooooAKa3anU1u1ADqKKKACiiigAooooAKKKKAEPSgdKD0oXpQAtFFFABRRRQAU UUUAFFFFADR96nU3+KnUAFFFFABRRRQAUUUUAFMk+7T6ZIMihCew4dKWkHSloGFFFFABRRRQ AUUUUAFNXpS0idOKAHUUUUAFFFFABRRRQAUUUUAN/ip1J/FS0AFFFFABRRSN900Aczqp3Xr8 9KsaGp+0se2KpXjFrmTJPWtTQsbX9aYjYpG6UtI3SkMB0paQdKWgAooooAKKKKACiiigApid TT6YnU0CH0UUUDCiiigAooooAKKKKAGn7wp1NP3hTqBBRRRQMKKKKACiiigApD0paQ9KAAdK WkHSloAKKKKACiiigAooooAKavU06mjqaBDqKKKBhRRRQAUUUUAFFFFADW6inU1uop1ABRRR QAUUUUAFFFFABSHpS0h6UAA6UtIOlLQAUUUUAFFFFABRRRQAU0feNOpo+8aAHUUUUAFFFFAB RRRQAUUUUANbtTqa3anUAFFJS0AFFFFABRRRQAUh6UtIelACJ0rP1qQrbqg/iNaCdKw9Zl33 AQH7opiRRgTdcIvUE11SjCgDsK57SYfNugxHC810dDGFFFFIAooooAKT+Klpv8VADqKKKACi iigAooooAKKKKAGt2paRqdQAUUUUAFQXkvk27v3xxU9Y+uTcLED7mgDIdyzEnvWho0Ra43no orOyD9a6LSYvLtAe7c0xF6iiikMavSnUi0tACUtFFABRRRQAUUUUAFNP3hTqafvUAOooooAK KKKACiiigAooooARulLSN0ooAWiiigAooooAKKKKACiiigBBS01e9OoAKKKKACiiigAooooA KQ9aWmnqKAHUUlLQAUUUUAFFFFABRRRQA1vumlHShulA6UALRRRQAUUUUAFFFFABRRRQAg6m lpB1NLQAUUUUAFFFFABRRRQAU09RTqaeooAdRRRQAUUUUAFFFFABRRRQAh6UDpQelA6UALRR RQAUUUUAFFFFABRRRQA0feNOpo+8adQJBRRRQMKKKKACiiigAprdqdSNQAtFFFABRRRQAUUU lAC0UUUAJQvSlpB0oAWiiigAooooAKKKKACiiigBv8VOpv8AHTqACiiigAooooAKKKKACmt0 p1NboKAYopaQUtABRRRQAUUUUAFFFFABRRRQA0feNOpo+8adQAUUUUAFFFFABRRRQAU09qdS GgBaKKKACiiigAooooAKKKKAEPSgdKD0oXpQAtFFFABRRRQAUUUUAFFFFADR96nU0fep1ABR RRQAUUUUAFFFFABTH6U+mv0oExR0paSloGFFFFABRRRQAUUUUAFNXpTqavSgQ6iiigYUUUUA FFFFABRRRQA3+KnU3+KnUAFFFFABTW+6adSHpQBylzzcOeRzWnoX/LSs+/4vJPrV7Qm/eOvt TEbdI3SlpG6UhgOlLSDpS0AFFFFABRRRQAUUUUAFNXqadTV6mgQ6iiigYUUUUAFFFFABRRRQ A09RTqaeop1ABRRRQAUUUUAFFFFABSHpS0h6UAA6UtIOlLQAUUUUAFFFFABRRRQAU0dTTqaO poAdRRRQAUUUUAFFFFABRRRQA1uop1NPUU6gAooooAKKKKACiiigApD0paQ9KAAdKWkHSloA KKKKACiiigAooooAKaOpp1J3oAWiiigAooooAKKKKACiiigBrdqdTWp1ABRRRQAUUUUAFFFF ABSHpS0h6UANU4U1zV+4ku3PXmugnk8u2dvQVzBJZyT1JpiNnRIsRtJ68VrVV06LyrRB3PNW qTGFFFFABRRRQAUn8VLSd6AFooooAKKKKACiiigAooooAQ0tIaWgAooooAQnAJrmL+Xzrlmz nBxW9qEwhtWOeTwK5nJJyaYEttF5twiDJya6mNAiBR0ArF0WAtIZT0HArcoYgooopDGr0p1I vSloAKKKKACiiigAooooAKafvCnU3+KgB1FFFABRRRQAUUUUAFFFFACN0oFDdKWgAooooAKK KKACiiigAooooAatOpq96dQAUUUUAFFFFABRRRQAU09RTqafvCgB1FFFABRRRQAUUUUAFFFF ACN0oHShulA6UALRRRQAUUUUAFFFFABRRRQA1epp1NHU06gAooooAKKKKACiiigApp6inU09 RQA6iiigAooooAKKKKACiiigBD0oHSg9KB0oAWiiigAooooAKKKKACiiigBo+8adTR9406gA ooooAKKKKACiiigAprdqdTW7UAOooooAKKKKACiiigAooooAShelFA6UALRRRQAUUUUAFFFF ABRRRQA3+KnU3+KnUAFFFFABRRRQAUUUUAFMfoKfTX6UCYopaQUtAwooooAKKKKACiiigAoo ooAiYMX+WlxJ6inDqaWncmwz957UuH9RT6KQ7DPn9qMP6inUUBYb8/tSYf1FPooCwzD+opGD YHNS0hp3Cw35/UUfP7U6ikFhvz+1Hz+1OooCw35/ajD+1OooCw35/aj5/anUUBYad2O1Iu/F PPSgdKYWG/P7UfP7U6ikFhn7z2pfn9qdRQFhvz+1B306loCxH8/oKX5/an0lAWIjv3cU7Mno Kd/FS07isMBfuBS5f0FOpaQ7DMv6UZf0p9FAWGZf0FGX9BT6KAsMy2OlNctjpUtNbpTuDQxS +ORS5f0FPpaAsMy3pSZf0qSikFhmX/u0Zb0p9FAWGZb0oy3pT6KAsMJbHSmqW6YqSkWmFhMt 6UZb0p9FILDNzf3aNzelPooCwws2OlJub+7T6KYWG7m/u0bm/u06igLERZtwOKdub+7Tj96n UXFYZub+7Sbm/u0+igdhm9v7poLNj7tPooCzOY1AEXT565qxozEXDY9OlRasMXrVJohxd49R QBvbm/u0jM2OlPoPSgLEauxH3aXc392njpRRcLMbuP8Ado3H+7T6KAsM3H+7Rub+7TqKAG7j /do3N/dNOooAbuP92mBmDHipaRepoE0Jub+7RuOfu06igdhpc/3TRvP9006igBu4/wB00Fz/ AHTTqKAG7zj7poDH+6adRQBGzkEcUoc/3TTiORS0Csxu8/3TRuP92nUUDG7z/dNG8/3TT6KQ WZHvOfuml3n+6afRTCzGbz/dNBY46GnUHpQFmRq5x0pd5/umnKMCloFZjd5/umjef7pp9JSH Zjd5/umjef7pp1FAWY3d7Gjef7pp9FAajN/sabvIPSpKQDk0wsxN/wDsmkEn+yafRQGo3f7G jf7GnUUBqN3+xo3+xp1FINRu/wD2TRv9jT6KA1InfGMClEmR0NOYZIpaegrMbv8AY0b/AGNO ooHqN3+xo3+xp1FINRu8eho3j0NOophqN8wehpC/HANPxQRxQGoxZOOlL5g9DSgAClx7UBqN 3+xo8wehp1FAajd49DR5g96dRQGozzB6Gl3j0NOooDUbvHoaTfyeOKfSbRuzQGonmD0NG8eh p1FAajd496N49DTqKQajd4pd4paMe1Aajd4o3inYFGKA1GM/HFL5gxSsAaXA9KegtRu8UCQU 7FGKB6jfMHvR5gp2KMCgNRu8UeYKdgUYHpQGo3zB70FxinYFBAxQGpmancbbUoByeKxoBmZQ eeav6xINyoOvWodKi828XPReaYlexvo6hQMdqd5i07A9KMD0paD1G+YKN4p2B6UYFAajfMWj zBTsD0owPSjQNRu8UhcA57U/AppUE0aBqHmLR5i07A9KMD0paBqN3j3o8we9OxRgUw1G7xR5 gzTsD0owPSgNRu9aN6+tOwPSjA9KQajGcAUvmKaVlBpdo9KegtRvmLR5i+tOwPSmuQqMxHQU aD1MbWp97rEOg5NZYqSeTzZ3b1NSafD5t0inoOaANvTkENqoPU81a3rShQBjFLgelGgaibxS bxTsD0owPSgNSNZAad5i0Ko9KdtHpRoJXG+YtG9fWlwPSlwPSkPUbvFHmL607A9KMD0p6BqN 3rRvX1p2B6UYHpSDUTeKY0gDCpMD0pjKCw4pqwncUSKaXevrRtHpS4HpQPUTevrRvFLgelGB 6Ug1G719aXeKXA9KMD0oDUTevrSeYvrS7R6UbR6CgNRC4xR5i460rKCOlG0elPQNRPMX1pd6 +tLtHpRgelAaib19aTevrTsD0owPSkGo3evrR5i0u0ego2j0phqJ5i+tLvX1o2j0o2j0oDUa JBk5pfMX1oCDJ4pdo9KNBK4b19aN6+tG0ego2j0oHqJ5i+tLvX1o2j0FG0egoDUN6+tG9fWj aPSjaPQUg1DevrTS4DCn7R6U0qCelPQNRd6+tBdfWjavoKNo9KA1E3rRvX1pdo9KNo9KA1De vrRvX1o2j0o2j0pBqG9fWjevrRtHpRtHpQGojOAOtCyKR1oZQR0pQoA6U9Ba3DcvrRuX1o2j 0o2r6Uh6hvX1o3r60bR6UbV9KA1DevrRvX1pdo9KTaPSgNQ3D1o3D1o2r6UbR6UBqNEignJp 29fWmhFJPFO2D0p6C1DevrRvX1o2L6UbR6Uh6hvX1o3r60bR6UbR6Uw1DevrRvX1o2L6UbF9 KNA1DevrTWcAinbF9KayLkUaC1Hb19aN6+tGxfSjavpRoPUN6+tG9fWjaPSjYvpSDUN6+tG5 fWjYPSjYvpTDUNy+tG4etGxfSjYvpQGoFhjrSB1x1oKLjpQI1x0o0DUXcPUUbh60bF9KTYvp RoGou5fWjcPWjYvpRsHpQGobh60bl9aNi+lGxfSgNQDqe9LuHrSbF9KNg9KQajd67zzTty+t N2KWpdi+lPQSuLuHqKNw9aNi+lBRT2oHqG4etG4eoo2L6UbF9KA1DcPWjcPWjYvpRsX0oDUN w9aRmGKUIPSkZB6UBqKHUjrRuHrSBFx0pdi+lLQNQ3D1o3L60mxfSl2L6U9A1DcPWjcvqKNi +lGxfSgNQ3D1o3D1o2L6UbF9KQahuHrSK4x1pdi+lIEXrimGou4etG4etGxR2o2L6Ug1DcPW jcPWjYvpSbF9KYai7h60bh60bF9KNi+lAahuHrRuHrRsX0o2L6Ug1E3jdilyPWmlATjtS7Fp 6C1F3D1o3D1o2L6UbF9KQ9Q3D1o3D1o2L6UbF9KA1DcPWjcPWjYvpRsX0oDUNw9aa7DA+tO2 L6U1kHBxTE7jxS0gpaRQUUUUAFFFFABRRRQAUUUUANH3jTqaPvGnUAFFFFABRRRQAUUUUAFI aWmt2oAdRRRQAUUUUAFFFJQAtFFFACHpSL0pT0oX7ooAWiiigAooooAKKKKACiiigBP4qWmj 71OoASlpKWgAooooAKKKKACmv0p1NfpQJi0tJS0DCiiigAooooAKKKKACmr0p1NXpQA6iiig AooooAKKKKACiiigBv8AFTqb/FTqACiiigAoopD0NAHOawc3rYPan6L/AMffHpVS9z9qk3HJ zVnRj/pYxxxTEdHTW6U6mt0pDFHSlpB0paACiiigAooooAKKKKACmr1NOpq9TQIdRRRQMKKK KACiiigAooooAaeop1NP3hTqACiiigAooooAKKKKACkPSlpD0oAB0paQdKWgAooooAKKKKAC iiigApo6mnU0dTQA6iiigAooooAKKKKACiiigBp6inU1uop1ABRRRQAUUUUAFFFFABSHpS0h 6UAA6UtIOlLQAUUUUAFFFFABRRRQAUnc0tNH3jQA6iiigAooooAKKKKACiiigBDS0hpaACii igAooooAKKKKACkPQ0tRzv5cLt6CgDnL+QvdP3xxV7Q4+Xf8KypG3OWPc10GkxeXZqT1bmmI vUUUUhhRRRQAUUUUAFJ3paT+KgBaKKKACiiigAooooAKKKKAENLTW7U6gAqhq0/lWpUH5n4q 9XPatOZbkrnheKAKGa2tEt8IZmHXgVjou9gAOa6i0j8q2RcYIFMRPRRRSGFFFFACLS01elOo AKKKKACiiigAooooAKb/ABU6m/xUAOooooAKKKKACiiigAooooAa3SlpG6UtAC0UUUAFFFFA BRRRQAUUUUAIO9LSDvS0AFFFFABRRRQAUUUUAFNPWnU0/eFADqKKKACiiigAooooAKKKKAEb pQOlDdKB0oAWiiigAooooAKKKKACiiigBo6mnU0dTTqACiiigAooooAKKKKACmnqKdTT1FAD qKKKACiiigAooooAKKKKAEPSgdKD0oHSgBaKKKACiiigAooooAKKKKAGj7xp1NH3jTqACiii gAooooAKKKKACmtTqa3agB1FFFABRRRQAUUUUAFFFFABSDpS0g6UALRRRQAUUUUAFFFFABRR RQA3+KnU3+KnUAFFFFABRRRQAUUUUAFNfpTqa/SgTFHSlpBS0DCiiigAooooAKKKKACiiigB g+8adTV++adQJC0UUUDCiiigAooooAKa3anU1u1ADqKKKACiiigApKWigAooooAQ9KF+6KD0 oXoKAFooooAKKKKACiiigAooooAaPvU6mj71OoASloooAKKKKACiiigApknQU+mP0oQmOpaS loGFFFFABRRRQAUUUUAFNXpTqavQ0AOooooAKKKKACiiigAooooAb/FTqb/FTqACiiigApD0 NFI5wpJoA5W+H+lyY9an0Yj7aMjtVa8cPcyFc4JpbObyblH7Z5oA6ykfpQjBkBHQ0N0oEKOl LSDpRQMWiiigAooooAKKKKACmJ1NPpq9TQIdRRRQMKKKKACiiigAooooAafvCnU0/eFOoEFF FFAwooooAKKKKACkPSlpD0oAB0paQdKWgAooooAKKKKACiiigApo6mnU0dTQA6iiigAooooA KKKKACiiigBrdRTqa3UU6gQUUUUDCiiigAooooAKQ9KWkPSgAHSlpF6UtABRRRQAUUUUAFFF FABTR1NOpo6mgB1FFFABRRRQAUUUUAFFFFADW7U6mt2p1ABRRRQAUUUUAFFFFABVLVXCWT57 8VdrG1yY5WL8aAMlFLyBRyScV1cCbIUX0Fc5psfmXqe3NdNTYC0UUUgCiiigAooooAKT+Klp v8VADqKKKACiiigAooooAKKKKAGtS0jUtAEdzIIoHcnoK5VyWcknrzWzrc2I1iHU8msTtzTA v6TB5tzuPRK6Gs/R4fLt956tWjQwCiiikAUUUUAIKWmr0p1ABRRRQAUUUUAFFFFABTT96nU0 /eFAmOooooGFFFFABRRRQAUUUUANbpS0jdKWgBaKKKACiiigAooooAKKKKAEFLSCloAKKKKA CiiigAooooAKaeop1NP3hQA6iiigAooooAKKKKACiiigBrfdpR0pG6Uo6UALRRRQAUUUUAFF FFABRRRQAg6mlpo6mnUAFFFFABRRRQAUUUUAFNPUU6mnqKAHUUUUAFFFFABRRRQAUUUUAIel A6UHpQOlAC0UUUAFFFFABRRRQAUUUUANH3jTqaPvGnUCQUUUUDCiiigAooooAKa1OprUAOoo ooAKKKKACkpaSgBaKKKAEoXpRQvSgBaKKKACiiigAooooAKKKKAG/wAVOpv8dOoAKKKKACii igAooooAKa/QU6mv0FAmLS0lLQMKKKKACiiigAooooAKKKKAGj7xp1MH3jT6BIKKSloGFFFF ABRRSUALTW7UuaRj0oAdRSUtABRRRQAUUUUAFFFFACHpSL92lPSkX7ooAdRRRQAUUlFAC0Ul FAC0UlLQA0fep1NH3qdQAUUlLQAUUUUAFFFFABTX6U6mOcCgTHUtIDxS0DCikpaACiiigAoo pKACkXpSmkU8UAOopKWgAopKWgAopM01pEQZZgB70APoqpJqNsi58wH2FUpNcUHEcRP1NAGq fvinVgvrEx5VVWoJNUun/wCWmPpQB0uR60xpo0+86j6muWNxO/3pGP41GWZurEn3oA6dr62X rKtRtqVsykCQVzfNGDRYBbgqZmIIIPpRAoaZQWCjPU01lzRtoA6uGaIRqvmKSB2NSswK8GuR GR0JqSO6mjOFlbHpmgDrF6Utc4mr3KnJII9MVYh1s/8ALVM/SgDboqlDqdvL/HtPvVpJUf7r A/Q0APopKWgAooooAKanelpqHk0CH0UlLQMKKKKACiiigAooooAafvCnU0n5hTqBBRRRQMKK KKACikpaACkPSlpG6UAC9KWkXpS0AFFFFABRRRQAUUUUAFNHU06mjqaAHUUUUAFFFFABRRRQ AUUUUANbqKdTW6inUCCiiigYUUUUAFFFFABSHpS0h6UAA6UtIvSloAKKKKACiiigAooooAKa PvGnU0feNADqKKKACiiigAooooAKKKKAGt2p1NbtS0ALRRRQAUUUUAFFFFABXN6rJvvGx24r opG2oxPYVyk7+ZM7eppgaOhxgyu57dK3Ky9Ej2wMxHU1qUMAooopAFFFFABRRRQAUnelpv8A FQA6iiigAooooAKKKKACiiigBrdqXtSNUN7L5Nq7ZwccUAYOpSma6dh0HFQ28fnTInqajJJJ JrU0OHc7SnoOBTEbMSCONUHQCn0UUhhRRRQAUUUUANXpTqavSnUAFFFFABRRRQAUUUUAFNP3 qdTT94UAOooooAKKKKACiiigAooooAa3SlpH6UooAWiiigAooooAKKKKACiiigBB3paRe9LQ AUUUUAFFFFABRRRQAU0/ep1NP3hQA6iiigAooooAKKKKACiiigBG6UDpQ3SgdKAFooooAKKK KACiiigAooooAaOpp1NHU06gAooooAKKKKACiiigApp6inU09RQA6iiigAooooAKKKKACiii gBD0oXoKD0oXoKAFooooAKKKKACiiigAooooAaPvGnU0feNOoEgooooGFFFFABRRRQAU1u1O prdqAY6iiigAooooAKKKKACiiigBKF6UUL0oAWiiigAooooAKKKKACiiigBv8VOpv8VOoAKK KKACiiigAooooAKa/anU1+goExRS0gpaBhRRRQAUUUUAFFFFABRRRQA0feNOqMttbnvTt4pi uh1FN3j1o3CkFx1FN3D1o3r60BcdRTdw9aNw9aB3HU09qN49aRnAoFcfRTd6+tG4etAXHUU3 cPWjcKB3HUU3cPWjePWgQ6im7h60bh60DuKelA6UhYY60gcY60CuPopu4etG5fWgdxaWm719 aNw9aBXHUU3cvrRuHrQO46im7h60bh60AH8VOphcBqXevrQK6HUU3cPWjcPWgdx1FN3D1pdw 9aAFopu4etLuHrQAtNYZFLuHrTWIx1oEx1LTQwx1o3D1oGOopNw9aTcPWgB1FJketGR60ALS UZHrSbh60ALSKKXcPWmq455oEPpKr3F7Dbj5259BWRd6tJL8sXyL+tAzaluYYRmRwKoz6xEg /dKXP5VikvIeck1NBYzTHhcD3ppMLpEs2q3EowCEHtVRpZH+8zH6mtWLRkAHmS/gKvQWVtCM KgJ9TzRZCuc4sUjn5UY/QVYj026fBEZx78V0ahF+6APpTsj1oAwl0eUkbmUVMuhrn5pTj2Fa pYbhS5HrRcCguj2y9dx+pqVdNtV/5ZA/WreR60ZHrRdhoQi0gHSJfyp3kRf880/Kn5HrS5Hr RqGhCbSA9Yk/KmNp1q3WIfhVnI9aMj1ouw0M59Ht2+6WWqsuiuOUkB+tbeRSMRii4HOPpdyo zs3fQ1WeF4zhkZT7iusDAjrSMEYYYA/WgDke9PjlkjOUcj6GuiksLWTP7sAnuKz59GIyYXBH oaLBcjt9Xlj4kXeP1rWtr6G4HythvQ1zs1vJC2HUj3qMMVIIJB9qLDudfS1hWerOmEmG4etb McqSKGVgQaQD6ag5NOyKapGTzTEPpKMijIpDFopM0ZoAWikzRmgApaTIooAQj5hS0hYAilyK BC0UmaKBi0lFGaAClpM0ZoAWkPSignigAHSlpAQR1ooAWikooAWikooAWkpaSgApB1NLSAjJ 5oEOpKKKBi0UUUAFFFFACUUtFADWHIpaQkZFLQIWiiigYUUUUAJS0UUAJQelLSHpQADpS0gI I4paACiiigAooooAKKKKACmgcmnU0Hk0ALRS0UAJRS0UAFJS0UAFJS0UANYdKWkNLQIWiiig YUlLRQAUlLRQBU1GTy7Rz6jFc0BlsetbmuSYhVfU1jwDdMoHrTQjorCPy7VFPXFWaZF/qwKk oYLYSilopDCkpaKAEopaKAExSY+anUn8VABRS0UAJRS0UAJRilooASilooAawrH1qflYgfc1 ryHC5PauZvJfOuXfPHQUxFfrXSaXD5VmuRyeawrSLzrhF7E811CqFUAdBQAtFFLSGJRS0UAJ RS0UANXpTqatOoASloooAKKKKACiiigAppHzU6m/xUALS0UUAFFFFABSUtFACUUtFADWHFL2 oPSloASilooAKSlooASilooAKSlooAavenUgpaACiiigBKWiigBKKWigApp+8KdSHrQAUtFF ABSUtFACUtFFABRRRQA1uhpR0obpQOlAC0UUUAJRS0UAJRS0UAJRS0UANUcmlpB1NOoASloo oAKKKKAEpaKKACmnqKdSHqKAFooooASilooASloooAKKKKAEPSkXpSnpQOlABRS0UAFFFFAB RRRQAUlLRQAwffNOpB96nUCQUlLRQMSloooASilooASkYZxTqQ0AFFLRQAlLRRQAUlLRQAlF LRQAlIvSnUg6UAFLRRQAUlLRQAUlLRQAlFLRQA3+Klo/ipaAENFLRQAUUUUAFJS0UAJTXB4p 9NfoKBMUUtIKWgYUUUUAFFFFABRRRQAUUUUAMABY5p2B6Ug+8adQITA9KMClooGJgelGB6Ut FACYHpRgelLRQAmB6UjAelOpD2oAMD0owPSlooATA9KMClooATA9KMD0paKAE2j0owPSlooA QgY6UgUY6Up6Ui9KBC4HpRtHpS0UDG7R6Uu0elFLQAm0elG0elLRQA3aPSl2j0paKAGbQWpd i+lH8VLQKyE2j0o2j0p1FA7CbR6UbR6UtFADdo9KNo9KdRQFhu0elIygin01ulArAEAHSjaP SlFLQFhu0elG0elOooHYbtHpRtHpTqKAsN2j0o2j0p1ISAMngUCsIQoGTise91FYyyRcn19K bqepb8xQnjuaz7e2lun2xjPqT2pq4NIYXeR+csTV210qaYhnGxPfrWnY6clsuWw0nrV6gCtB YQQfdTJ9TU/lr6U+ildhZDNi+lGxfSn0UXCyG7B6UbB6U6igLEZQZpfLWl/ip1O4WQ3YKNgp 1FILDNi5pdg9KWigLITYKTYKfRQFhuwUjKMU+kbpQFhojGOaPLWnDpS07hZDNgo2LT6KVwsi J4I5FKsuRWXeaR1e3P8AwE1sUtO4WOQdGRyrAgj1qW2unt3BU5HcVv3lhFdDJGH7EVgXdpJb PtYcdj60Ab9pcQ3KZQ4PcVMqAsTmuWhmeCQMjEGt2w1BJjtbhzQFkXtgo2CnUtK4WG7BSbBT 6KLhYZsFGwU+ii4WGbBRsFPoouFiNowSBR5Y96cfvCnU7hZDNgo2Cn0UrhYZsHvS7BTqKLhY ZsFGwU+ii4WQzYPegqMU+kPSgLDFj45NLsHrTh0padwshmwYo2D3p9FK4WGBAKXYKdRQFhu0 eppNg9TT6KAsN2+5puzLGpKaOpphZCbB6mjZ7mn0UrhZDNnuaNnuafRQFhmz3NGz3NPooCwz Z7ml2e5p1FAWInTOMGnBPc0rdRTqdwshmz3NGz3NPopBYbs9zRs9zTqKAsM2e5o2e5p9FAWG bP8AaNBXjrT6Q9KAsMEfvS7Pc04dKWncLIZt9zRt9zT6KQWGbD6mjZ7mn0UBYZsPqaNp9afR QFhu33phQlutS0g6mncGhuw+po2nP3jT6KQWGlfc0mw/3jT6KAsN2n1pNp/vGn0UBYZtPqaX afWnUUBYjZTjrQEP94089qWncLDCh/vGjaf71OopBYQKfWjafWnUUBYbtPrSbT/ep1B4FAWO f1eTdc7c5Cik0qIyXGRjC81Xvn33Uh960tCXEbmqA0o0b1xT9rf3qVOlLSbEloN2n+9RtPrT qKQ7Ddp/vUbT/ep1FAWE2n+9SbT606igLDdp9aQqS3Wn0nemFhNp/vUbT/ep1FILDdp/vUbW /vU6igLDdp/vUbW/vU6igLDdp/vUbW/vU6igLFPUnMVqzZ9q5wk5ya19cm+7ED7kVjj6UwNT RYS7tJ0xxW0FI/iqrpcHk2qk9W5q7Q2FhhVv71G1v71OopBYbtb+9RtP96nUUBYbtP8AepcH 1paKAsRqrc807a396nClphYZtb+9Rhv71PopBYZtb+9Rtb+9T6KAsM2t/eo2t/ep1FAWG4P9 6murEjBqSkP3qdwaE2t/eow3rT6KQWG4b1ow3rS0UBYbhv71GG/vU+igLDMN/eoAb+9T6KAs MYHHWgBvWnHpRTCw3Df3qMN60+ikFhmG9aMN606igLDcN60Yb1p9FAWGYb1pcN60tFAWIwrb jg07Df3qcO9LTCwzDetGG9afRSCwzDetGG9adS0BYZhvWjDf3qfRQFhuG9aawbIwakpp6imF hMN60EN60+ikFhmG9aMN606igLDcN60Yb1p1FAWEw3rRhvWlooAawYjg0KGxyRTj0oHSmFtR uG9aXDetOopBYZhvUUYb1FPooCwzDetGG9RTqKAsNw/qKXDetLS0BYiCtuODTsN60o6mnUws M+b1FGG9adRSCwmG9aMN6inUUBYZhvWj5vUU6loCwwBvUUjBsjmn0h6igLCAP3Io+b1FPooC wz5vagh/UU6igLDcN60Yb1FOooCwnzeoo+b2p1FAWGHdikAfHWnmgdKAsN+f1FHze1OooCwn ze1Hze1LRQFhPm9qT5vanUtAWG/N7UfN7U6igLEWG38U75/alH3jS0wSGjf3xR8/tTqKQWG/ N7UfP7U6igLDfn9qPn9qdRQFho3d8UjhiKfSGmFhBv8Aaj5/UU6ikFhvze1Hze1OooCw35vU UfN7U6igLDfm9qBup1FAWE+bFMUPUlIvSmFhPn9RR83tTqKQWG/N7UDf7U6igLDfm9qX5val ooCwnze1Hze1OooCxGQ26l+f2p38VFAWG/P7UfN7U6igLDfm9qX5valooCwnzUnze1PooCw3 5vamtux2p9NfpTBocOlLSClpDCiiigAooooAKKKKACiiigBo+8adTR9406gAooooAKKKKACi iigAprdqdTW7UAOooooAKKKKACiiigAooooAQ9KRfuilPShelAC0UUUAFFFFABRRRQAUUUUA NH3qdTR96nUAFFFFABRRRQAUUUUAFNfpTqa/SgBaWkFLQAUUUUAFFFFACE4GTWHqt+XYxRHC jqR3q1q12I4vKRvmPXHasWCF7mYIgJJ70ALbW8l1KFUfU10lnAIItoAz3pLS1S2iCqBnHJ9a nXpTEOooopDCiiigAooooAKKKKAG/wAVOpv8VOoAKKKKAEpaSloAKKKKACkbpS01ulACjpS0 g6UtABRRRQAUUUUAFRTwJOhVxmpaKAOavrB7V8j5k7GqgJUgg4Ndcyh1KsAQawNRsWjYvGMp 6elVuLYuabqQlHlTEBh0PrWoDnpXH5IrX0vUekMx+hNSM2qKQHIyKWgAooooAKKKKAGnqKdT T94U6gAooooAKKKKACiiigApD0paQ9KAAdKWkHSloAKKKKACiiigAooooAKQdTS00dTQA6ii igAooooAKKKKACiiigBrdqdTW6inUAFFFFABRRRQAUUUUAFIelLSHpQADpS0i9KWgAooooAK KKKACiiigApB1NLTR940AOooooAKKKKACiiigAooooAQ9qWkbtS0AFFFFABRRRQAVHcNsgdv QVJVLVZAlm3qeKAOdf5mJPU10WlxiOyX1PNc6i7nAz1NdVAgjgVR2FMQ9OlOpqdKdSBBRRRQ MKKKKACiiigApv8AFTqT+KgBaKKKACiiigAooooAKQnAzS1XvZfKtXb2oA5/UJvOu3PvgVHb xmWdUHc1ESSST1rR0aItc7uyimI3o12Iq+gp1FFIYUUUUAFFFFABRRRQAgpaatOoAKKKKACi iigAooooAKafvCnU0/eFADqKKKACiiigAooooAKKKKAGt0paRulLQAtFFFABRRRQAUUUUAFF FFADR3p1NXvTqACiiigAooooAKKKKACmnqKdTT94UAOooooAKKKKACiiigAooooARulA6Ujf dNKOgoAWiiigAooooAKKKKACiiigBo6mnUg6mloAKKKKACiiigAooooAKQ9RS009RQA6iiig AooooAKKKKACiiigBD0oHSg9KB0oAWiiigAooooAKKKKACiiigBo+8adTR9406gAooooAKKK KACiiigAprU6mtQA6iiigAooooAKKKKACiiigBKRelLQvSgBaKKKACiiigAooooAKKKKAG/x U6m/xU6gAooooAKKKKACiiigApj9BT6Y/QUCY4UtIKWgYUUUUAFFFFABRRRQAUUUUANH3jTq aPvGnUAFFFJQAtFFJQAtFJRQAtNbtS01+1AmPopKWgYUUUlAC0UUlAC0UUUAIelC9BQelIv3 RQA6ikpaACikooAWikpaACiikoAQfep1MGd9OoEhaKSloGFFFJQAtFFFABTW6UtNfpQJjqWk HSigYtFFJQAtRTyCKFnJ6CpKytauCqiIHr1oAyJ5GnmLHkk1uaVZ/Z4t7D52rM0uAzXQP8K8 10YGKYgpFpTTUzzSAfRSUtAwoopKAFopKKAFopKKAE/ip1MOd9OoELRSUGgYd6WoXnRD87qP qajN/bD/AJar+dAFqiqh1G2H/LVaT+07X/nqKALlNb7tVRqVqR/rRUouIpF+R1P40AyYdBS0 1egpaAFopKWgAoopKAFopKWgBKjUBtwIyKkqOPO5qaE9zH1LTvLJliGV7j0rLHBrryNwII4r C1SwMLebGPkPX2o3As6XqCsoilOGHAJ71q1x/KnINb2l3wkQRSN846Z70hmnRSUUALRSUUAI fvCnUw/eFOoELRSUUDFopKKAFopKKAFpD0opG6GgBR0paavQUtAC0UlFAC0UlFAC0UUlAC00 dTTqaOpoAdRSUUALRSUUALRRSUALRSUtADW6inUxjyKdQIWiiigYUUUlAC0UlFAC0h6UUh6U AKOlLTVPFOoAKKKKACiikoAWikooAWmj7xpaQH5jQA6ikpaACiikoAWiiigAooooAQ9qWmt2 paAFopKKAFoopKAFrJ1x8Ronqa1awtbYm4UdgKAKVqu+5jX3rqQMKBXPaQga8XIzjmuiJ4pi ETpTqavSlpAhaKKKBhRSUtABRRSUALTf4qWkz81ADqKKKACiikoAWiikoAWsnXJcRpGD1PNa ua5zVZfNu254XigCkQM9a39Fi2WxY/xGsGNdzgAck11dsgjgRR2FMRLRSUtIYUUlFAC0UUUA FFFJQAL0paatOoAKKKSgBaKKKACiiigApp+8KdTD98UCY+ikpaBhRRRQAUUUUAFFFJmgAbpR SMeKWgBaKKKACiiigAooooAKKKSgBF706mr3p1ABRRRQAUUlLQAUUUUAFNP3hS0hPzCgB1FF JQAtFFFABRRRQAUUUUAI33TQOlI33TQvQUCHUUUUDCiikoAWiikoAWiikoAB3paap5NOoAKK KKACiiigAopKWgApp6inU1jyKAHUUlLQAUUUUAFFFFABRRRQAh6UL0oPSgdKAFooooAKKKKA CiiigAooooAaPvGnUwffNPoEgooooGFFFFABRRRQAU1qWkagB1FJS0AFFFFABRRSUALRRRQA lC9KDSL0oAdRRRQAUUUUAFFFFABRRRQA3+KnU3+KloAWikpaACiikoAWiiigApj9BTqa54FA mOpaQUtAwooooAKKKKACiiigAooooAaPvGnU0dTTqACiiigAooooAKKKKACmt2p1NbtQA6ii igAooooAKKKSgBaKKKAEPShegoPSgdKAFooooAKKKKACiiigAooooAT+KlpB96loAKKKKACi iigAooooAKa3SnU1ulAC0tJS0AFFFFACHgVzWpS+bdsR24robhisLkdQK5bmSYDuxpgbmiwh Lbfjlq0qigTy4VX0FS0gCmrS0i0AOooooAKKKKACikpaACiiigBp+9Tqb/FTqACs7VrowRYV sMa0ayNbgkkCsikgdaAMV5Gc5ZifrTR0qaC0kuHCov1NacWhjHzy/kKdhXMait4aHAOrsaeN Gt+5Y0WA5/NKrlTlTW42iRc4kYVTn0iaMZQq30osFxttqk0RG47l9DW1bXsNyvyNz6GuYkRo 2w4INCSMhBUkEUrDudhRWfpV4biLa5+df1rQoAKKKKACiiigBKZH95qfTU6mmJ7j6a6B1KsM g06ikM5zULFreQlQSh6VTVmjcMpII5rq54lmiKN0Nc3fWrWsu08qehp7iNvT71bqPB4cdRV2 uTt53t5Q6Hkdq6W0uUuYg69e4pDJ6KKKAGn7wp1NP3hTqBBRRRQMKKKKACiiigApD0paQ9KA AdKWkHSloAKKKKACiiigAooooAKaOpp1NHU0AOooooAKKKKACiiigAooooAa3UU6mnqKdQAU UUUAFFFFABRRRQAUh6UtIelAAOlLSDpS0AFFFFABRRRQAUUUUAFJ3paaOpoAdRRRQAUUUUAF FFFABRRRQA1u1OprdqdQAUUUUAFFFFACVzmqSCS8bHbiujb7prlbn5p3OR1pgaGhrmVyR0Fb R6Vl6GuInOO9ah6UAIvSnU1elOpAgooooAKKKKACiiigApv8VOpO9AC0UUUAFFFFABRRRQAy ZxHEzHoBXKStvkZvU5rf1aXy7QgdW4rnieaYFrTo992mB0OTXS1kaLFhWkPc4rYoYkFFFFIY UUUUAFFFFABRRRQA1adTV6U6gAooooAKKKKACiiigApv8VOpv8VADqKKKACiiigAooooAKKK KAGt0p1I3SloAKKKKACiiigAooooAKKKKAEFLTVp1ABRRRQAUUUUAFFFFABTT94U6mnrQA6i iigAooooAKKKKACiiigBG6UDpQ3SgdKAFooooAKKKKACiiigApKWigBq9TTqaOpp1ABRRRQA UUUUAFFFFABTT1FOpD1FAC0UUUAFFFFABRRRQAUUUUAIelA6UHpQOlAC0UlFAC0UUUAFFFFA BRRRQA0feNOpo+9TqACiiigAooooAKKKKAEpG7U6mtQAtLRRQAUUUUAFFFFABRRRQAhpF6Ut C9KAFooooAKSlooAKKKKACiiigBv8VOpv8VOoASloooAKKKKACiiigApjjpT6a/QUCYopaSl oGFFFFABRRRQAUUUUAFFFFADQfmNLTCpLcHFLsP940xXHUU3af7xpdp9aQXFopu0/wB6jacd aAHUU3af71G0/wB6gB9Ie1N2t/epGU8YNMLj6KaFP96jaf7xpBcfRTdp9aMH1oAWikwfWk2n P3qAHUU3af71Lhv71ACnpQvSmkHHWhVOOtMB9FM2t/eo2t/epBcdS0za396ja396gLj6KZtb +9RhvWgLjqKbhvWlw3rQFw/ipajIbfwaXD+tOwrj6Kbh/WjDetIdx1FNw3rRhvWgLj6KZhvW jDetAXHUjdKTDetNcNjrTC5JS1GofHWlw/rSsFx9FMw/qKMP6igLkV7/AMesn0rnbJN95GD0 zW7qAk+yPjnjtWHp+TeIAcHNNAdQOBRTAHxyaMPnrSC4+kBqOWTylLOwA96w77UXkJSJyF74 oA2J76CA4dxn0FTxyLIgZCCDXJKGlcKMkk10dhbvb24U4zRYdy5RTcP6ij5/agVx1FNO+j5/ UUBcdRTfn9qPn9qAuL3pajbdn3p3z+1OwXHUEZGDTRv74o+f2pBcEjRPuqB9BT6j+fPaglgO SBTC4+iow5YZBBpdze1ILj6RulRNKEGWZR+NVLjVIo+AQx9qALNxaxXEZDqM+tc3cR+TMyZy AauXGrSyDbH8g/Ws/JZs8kmmBo6KG+1kjpjmt+szSrV4Y/MIwzVo/P7UMLjqKb81Hz+1ILjq Kb8/tR8/tQFx1NTqfrR83tTQXyeKdhNklFN+f2o+f0FIdx1QXdslzEVYc9jUo346Cj5/QUwu cpPE0MpRuoqzpt2baYKT8jcGrur2hZfOC8jrisboaGCOwByMjvS1naXcNLbAdSvFXQX9BSsF x/eio3LZBpQX9BTsFySimZf0FGX9BSC4+imZf0FGW9KAuOpaZl/QUZb0oC4+kPSm5f0FBLbe lAXHDpS1ErOR0p2W9KLBcfSU3LelBL+lAXH0UzLelGW9KAuPopmW/u0Zb0oC4+mjqaTLelIC 248UwuSUUzLelALelILj6KZlvSjLf3aAuOopMt6Um5vSgLjqKblvSlyfSgLgeopajkZuMCnB mx92nYVx1FN3N6Ubm9KQ7jqKTcfSk3H0oC46im7j6Ubj6UBcfSHpTdx/u0FjjpQFxw6UUxWO OlLuP92mFx9FN3H0pNx/u0guOopu4+lG4/3aAuOopu4/3aNx9KAuPpB1NN3H+6aTcd3SmFyS imFj/dNKGPpSC4tFN3H0o3n+7QFx9FM3H0NLuPpQFx1FM3expd3saAuB7U6o2Y9hShz6GnYL j6KZvPoaN3tSsFx9FM3+xo3H0NFguNuG2wOw7CuVY5YnvmukvpSlq/y9RXNnrTC50WlJss1P HPNXKqaeStogKnpVktx0NAXFXpTqiRz3Bp28/wB00WBMfRTN3saNx9DSsFx9FM3expd3saAu Oopm/wD2TRv9jQFx9N/ipN3saaXIbpTsDZLRTN/+yaN/+yaVguh9FM3+xpd3saAuOopm/wBj SGTHUGiwXMfXJMyqmegzWWBzVm/l826dvfFRWyq9wgboTTA6Cxi8m1QHqeauVCWwgAHSnh8j oaGJND6KZv8AY0b/AGNKw7j6KZv9jRv9jQFx9FN3+xpN/saAuPopu/2NG72NAXFHSlqJZOcY NO3+xp2BND6KZv8AY0b/AGNKwXH0U3f7Gk3+xoC4+imb/Y0u/wBjQFx1NP3hRu9jTWfB4FMG ySimb/Y0b/Y0rBdD6KZv9jS7/Y0BcdRTN/saN/saAuPopm/2NG/2NFguOPSlpjNx0NG/joaY XQ+imbx6Gjf7GkFx9FM3j0NG8ehosFx9FM3j0NG8ehosFx9FN3j3o3j3oC4o70tRrJyeKXeP Q07BdD6KZvHoaN49DSsFx9FM3j0NG8ehosF0Popm8ehpd49DQFx1NPUUbvY01nwelAXRJRTd 49DSGQZ6GiwXH0U3ePQ0m8ehosFx9FM3j3o3j3osFx9FN3j3pN496LBcc3SgdKazjFIJBjoa dguiSimbx70u8UguOopm8e9LvFAXHUUzeKXeKAuOopm8Uu8UWC4DqadUfmAMRil3inYLofRT N496XcKQXHUU3ePejeKAuOopgce9LvFAXHU09RSbxSM4HNOwXH0U3zB70bxSC6H0U3eKTeKA uPopm8UbxRYLj6KZvFLvFAXFPSgdKaXGKQSDHNOwXJKKZvFG8UrBcfRTd4pN4osFx1FN3rRv WgLofRTd4o3igLgPvGlpnmDdS719aYXQ+im7xRvFILjqKbvFG9fWgLi0Um8Um9aAuh9NakDg 0M4xTsF0OopodSKN4pBdD6KbvX1o3igLjqKaWApN4oC4+im7xRvFAXFoHSk3jFNWQd6YXRJR Td4o3ikFx1FN3Ck3r60BcfRTd4o3igLjqKbvFG4UBcP4qWmFwGp28UwuOophdR3pd4pBcdRT d4o3j1oC46im7xRuFA7jqa/QUbxTXccCmJsfS0g6UtIYUUUUAFFFFABRRRQAUUUUANH3jTqa PvGnUAFFFFABRRRQAUUUUAFIaWmt2oAdRRRQAUUUUAFJS0UAFFFFACHpQvSg9KF+6KAFoooo AKKKKACiiigAooooAb/FTqb/ABU6gBKWiigAooooAKKKKACmt0p1MfpQDHUtJS0AFFFFAEc+ PJbPTFc3atsvkx/erpmGVIrmpVMV5kjGGpoDpgeKKbG26NSO4qG+uBbQM5/CkBna1dA4hU89 6yYo3mkCIMk0kjtLIWJJJNb+lWSwxCRxlz+lNASafYrbRDcAX7mr1FFIAooooASlpKWgAooo oAb/ABU6m/xU6gAooooASsTWLwl/JQkY61t1lajpjzy+ZERnuDQBjLPIgwrsPxpy3k4UqJWA PvU50m7/ALg/OnLpF0cfKB+NOwrlMuzfeYmm9TxWtFojk/vJAB7Vei023hGQu4+poC5hQWc8 33EJHritiy0pYSHkO5x27VoqoUAAYp1FwsIOBS0UUhhRRRQAUUUUAFNXqadTV70CHUUUUDCi iigBksYljZG6EVy11F5M7R+h4rrKxtctxhZh9DTQippd15E+0/dbrXRg5Ga48NtbIrqLC4Fx bKw6jg0hk56inU0/eFOoAKKKKACiiigBKWiigApD0paQ9KAAdKWkHSloAKKKKACiiigAoooo AKaOpp1NHU0AOooooAKKKKACiiigAooooAaeop1NbqKdQAUUUUAFFFFABRRRQAUh6UtIelAA OlLSDpS0AFFFFABRRRQAUUUUAFNHU06kHU0ALRRRQAUUUUAFFFFABRRRQA09qdTW7U6gBKWi igAooooAoaw220wO5rnxkuBW3rjYhQeprHtxuuUUdz3pgdPbjECAjHFSGhRhQKD0pAIvSlpF 6U6gQUUUUDCiiigApKWigApv8VOpP4qAFooooAKKKKACoLuTy7d2zjAqeszWpdtuEB5Y0AYL HLEnrV3SYPNugSMheao1t6FHiN39TTEarAYFLSN2p1IYUUUUAFFFFABRRRQAUlLRQA1cUtIv SnUAJS0UUAFFFFABRRRQAU0gFqdTf4qAFpaKKACiiigAooooAKSlooAa3SlobpS0AFFFFABR RRQAlLRRQAUlLRQA0AelLQveloAKKKKAEpaKKACiiigAppAyKdTT1FAC0UtFABRRRQAlFLRQ AlFLRQA1vumhQMcUN0pR0oEFFLRQMSilooASilooASilooAaAMmlpF706gBKKWigBKKWigBK MUtFACUhAJFOpp6igBcCjFLRQAmKMClooATFGKWigBKMUtFACEcUigYpT0oHSgQYHpRgelLR QMTAoxS0UAJijApaKAExRS0UAMAG7pTsCkH3jTqBCYoxS0UDEwKMD0paKAExRgelLRQAgApG ANOprdqBCgAdqMClooGJgelGKWigBMD0owKWigBMCjFLRQAmKQAelLSL0oAXA9KMClooATAo wPSlooATAoxS0UAJgUYFLRQA3A3dKXApP4qdQAmB6UYpaKAExRgUtFACYFGB6UtFACYFNcDA 4p9MftQJjqWkFLQMKKKKACiiigAooooAKKKKAGj7xpaQfeNOoEgpKWigYUUUUAFJS0UAJTW7 U+msOlAh1FFFAwooooAKKKSgBaKKKAEPSkX7opT0pF+6KAHUUUUAFFFFABRRRQAUlFFACA/N TqaB8xp1AkJS0lLQMKKKKACiiigApknSn01+goQmKOlLSAUtAwooooASsLV49k4b1rdrO1mP dbg45B600BYsJfNtUPtisrWpy83lA8LU+kzFbeQMRheayrhzJOznuaAJdMtjPc5P3V5NdJEM LiqWkW/lW+89X5q+vSgXUdRRRSGFFFFACUUUUALRSUUANz89Ppv8VOoEFFFFAxKWkpaACiko oAKRulLSOOKAFHSlpB0ooAKWkpaACikpaACikpaAEpqHk06moOTQIfRRSUDFopKKAFqG5iE0 LIwzkVNSUAchKhSRlI6GtLRbjZKYm6N0o1m2EcglUcN1rOhfy5VbOMGmI60n5hTqhicSKrDk EVLSAWikooGLRRRQAUUmOaKAChulFI3SgBV6UtIvSloAKKKSgBaKSigBaKSigBaap5NLSL94 0CHUlLSUDFopKWgAooooAKKSloAa3UU6mMORTqBC0UUUDCikooAWiiigApD0opGGRQAo6UtI vQUtABRRRQAUUUlAC0UlLQAU0dTTqaB8xoAdRRSUALRRSUALRSUtABRRSUAI3anU1u1LQAtF JRQAtFJRQBka6f8AViqGnpvvIx6HNWtaObhRnoKh0jP2wcdqYjohQelFB6UhiL0p1NUcUtAC 0UlFAC0UlFAC0UlFAC03+KlpMfPQA6iikoAWiikoAWsLXHzOi+grbY4Uk9q5e+mM907ZyM4F AEHeuj0qPZZqcdea56BDJMqAZya6yJAkaqOABTEK3anU1u1LSGLRSUUALRSUUALRSUtABSUt JQAi9KdTVHFOoAKKSloAKKKKACiiigApv8VLTSPmoEPopKKBi0UUUAFFFFABRRSUAI3SlpG6 UtAC0UUUAFFFFABRSUtABRRSUAIvenUxARnNPoEgoopKBi0UlFAC0UlLQAU09aWkP3hQA6kp aSgBaKKKACikooAWikooARulKOlI3SlHSgQtFJS0DCikpaACiikoAWikooAQd6dTV6mnUAFF FFABRRRQAUUlFAC009RTqafvCgGOopKWgAoopKAFopKWgAooooAQ9KB0obpQvQUALRRRQAUU lLQAUUUUAFFFJQAg+8adTAPmNOoEhaKKKBhRSUtABRRRQAU1qWkbtQA6ikpaACiiigAoopKA FopKWgBKRelKelIvSgB1FJRQAtFFJQAtFFFABRSUtADf4qdTed1OoAKKSigBaKSloAKKKKAC mt0paa/agTHClpBS0DCiiigAooooAKKKKACiiigBo+8adTR9406gAooooAKKKKACiiigApp7 U6mt2oAdRRRQAUUUUAFFFFABRRRQAh6UL0FB6UL90UALRRRQAUUUUAFFFFABRRRQA0feNOpo +8adQAUUUUAFFFFABRRRQAU1+lOpr9KBMWlpKWgYUUUUAFRzRLNGUboakooA5aYPbTOgJA6V FEoeZV9TWxrcaeWr4G7PWs3TlDX0dMR0sahIwo4AFKvSl7Ui9KQx1FFFABRRRQAUUUUAFFFF ADf4qdTf4qdQAUUUUAJS1Sn1KCCTYxJPfHarMMyTIHQ5BoAkooooAKqajK8VsWTrVuobpQ8D A+lCAwIr+dJVLOxXPSuijcSRhlOQa5J+GI966HSGLWYyelMC/RRRSAKKKKACiiigApq96dTV 6mgQ6iiigYUUUUAFFFFAFa/hE1q645xkVy5BDEGuwPIrmdRh8m7YdAeRTEaOjSlo9jNnHSta ud0mUpdAE8NxXQ0MELRRRSGFFFFABRRRQAUh6UtIelAAOlLSDpS0AFFFFABRRRQAUUUUAFNH U06mjqaAHUUUUAFFFFABRRRQAUUUUANPUU6mnqKdQAUUUUAFFFFABRRRQAUh6UtIelAAOlLS DpS0AFFFFABRRRQAUUUUAFNHU06mjqaAHUUUUAFFFFABRRRQAUUUUANbtTqa3anUAFFFFABR RRQBzurH/TWqTRVzck+gqtqLbryQ+9XdC+/J60wNqkPSlpO1IBF6U6mr0p1ABRRRQAUUUUAF FFFABTf4qdTf4qAHUUUUAFFFNdgilicAUAUtVufIg2A/M/Fc6TVi+uGuLgkngdKjghaWVVAz k00BqaNaf8t3H+7WzUcMYiiVFGABUlJgI3alpDS0AFFFFABRRRQAUUUUAFFFFACLS01elOoA KKKKACiiigAooooAKb/FTqT+KgBaKKKACiiigAooooAKKKKAEbpS0jdKKAFooooAKKKKACii igAooooAQUtIKWgAooooAKKKKACiiigApp+8KdSHrQAtFFFABRRRQAUUUUAFFFFACN0oHShu lA6UALRRRQAUUUUAFFFFABRRRQA1e9OpB3paACiiigAooooAKKKKACmnqKdTT1FADqKKKACi iigAooooAKKKKAEPSgdKD0oHSgBaKKKACiiigAooooAKKKKAGj7xp1NH3jTqACiiigAooooA KKKKACmt2p1NbtQA6iiigAooooAKKKKACiiigBKF6UUDpQAtFFFABRRRQAUUUUAFFFFADf4q dTf4qdQAUUUUAFFFFABRRRQAU1u1Opr9qBMdRSUtAwooooAKKKKACiiigAooooAaPvGnU0fe NOoAKKKKACiiigAooooAKa3anUh7UALRRRQAUUUUAFFFFABRRRQAh6UDoKD0oHSgBaKKKACi iigAooooAKKKKAGj7xp1NH3jTqACiiigAooooAKKKKACmt0p1NbpQAtLRRQAUUUUAFFFFAGV roHkKe4NUNHH+mjI7Vf1w4gUe9UNJP8Apq80wOjoXpRQtIBaKKKACiiigAooooAKKKKAG/xU 6m/xU6gAqpqFx9ntmbueBVuszWwfsox60AYLMWYk966LSEKWgJ781zeeetdDpF0JIBGeGWgD SooooAKinO2FiemKlrM1e7EUflL95qAMNzl2PvW7oqFbYk9CawlDO4AHWuptY/Kt0XGMCmIm ooopDCiiigAooooAKYnen01e9Ah1FFFAwooooAKKKKACsbXIfuSgexrZqnqcfmWb46jmmgOd hcxyqwPINdXE26NW9RXI5wa6XS5DJaLnqOKALlFFFIAooooAKKKKACkPSlpD0oAB0paQdKWg AooooAKKKKACiiigApq9TTqaOpoAdRRRQAUUUUAFFFFABRRRQA1uop1NbqKdQAUUUUAFFFFA BRRRQAUh6UtIelAAOlLSDpS0AFFFFABRRRQAUUUUAFJ3NLSdzQAtFFFABRRRQAUUUUAFFFFA DW7U6mntTqACiiigApG4BpaZMcRMfagDlrol7hycda19DjxEz8ZJxWM/3zn1re0dcWmR3NMD QpD0paQ0gEXpTqavSnUAFFFFABRRRQAUUUUAFJ/FS03+KgB1FFFABWVrV1sjEK9W61pSuI42 c9AM1yt1cNcTs7Hg9KAITkmtzRLcCMyt1zxWPbxGaZVXua6qCMRRBFGAKYiWiiikMQ0tIaWg AooooAKKKKACiiigApKWigBq9KdSL0paACiiigAooooAKKKKACm/xU6m/wAVADqKKKACiiig AooooAKKKKAGt0paRqWgBaKKKACiiigAooooAKKKKAGr3p1NXvTqACiiigAooooAKKKKACm/ xU6kPWgBaKKKACiiigAooooAKKKKAEbpQOlDdKB0oAWiiigAooooAKKKKACiiigBo6mnUg6m loAKKKKACiiigAooooAKaeop1NPUUAOooooAKKKKACiiigAooooAQ9KB0oPSgdKAFooooAKK KKACiiigAooooAaPvGnU0feNOoAKKKKACiiigAooooAKa3anUhoAWiiigAooooAKKKKACiii gBKF6UUL0oAWiiigAooooAKKKKACiiigBv8AFTqb/FTqACiiigAooooAKKKKACmv0FOpj9BQ JjhS0gpaBhRRRQAUUUUAFFFFABRRRQBEWw3HNO3n+6aUAZNLTFZjd5/umjcf7pp9FILDN/sa Nx/umn0UAM3H0o3H+7T6SgBu4/3TSM5GODT6Q9RTATecfdNG4/3TT6KQWG7j6GjcfQ06igBm 4/3TRvP900+igBu72NG72NOooAYWOOhoVjjoacelA6UwG7vY0b/Y0+ikAzf7Gjef7pp1FMBu /wBjRv8AY06ikGo3f7Gl3+xpaKA1IzJhuhpfM9jS4G7NOpisxnmc9DS7/Y06igeo3f7GjePQ 06ikGo3f7Gjf7GnUUBqN3j0NIz8cA0+kYZFMHcQSD0NG8ehp1FAajd49DRvHoadRSDUb5g9D R5g9DTqKYamZrHz22QOhrL03i8TFbWrLmyasOxbZeRn3oA6cOCO9NWQc8VIOlIoFAaibx6Gj ePQ06igNRu8UbxTqKQajfMHvR5gp1FMNRu8UbxTqKQajDIAwpfMWlIBalwPSnoGo0SA1DdIs 8DIR1FWMUYoDU5CaMxyFWGCKdBM8EgdDyK39Q09blSyjEg6e9c/LbyQsVdSCKANiHW0KgSoQ e5FT/wBr22Op/KucwaOaVh3Nm41rqsKfiaypJHlfcxJJpqoznCgk1qWWlEgPPkD0ppCbG6Tb gyeZIOB0rb8xaI41RQFAAFPwPSh2DUb5i0bxTsD0owPSkGo3evrS7x60uBRgelAajd49aPMX 1p2B6UYHpQGo3eKQSLk0/ApqgZNMHcPMWl3ilwPSjA9KA1E3r60b1pcD0owPSkGom8etG9fW lwPSjA9KA1G719aZKVeJlPORUmB6UFRjpTDU5KRdrkehrY0SUCJlJ71m36GO7kBHfNWtEJNw w7Y5oA3d6+tG9fWjaPQUuB6Ug1E3r60bx60uB6UYHpQGom9fWjevrRgelLgelAaibx60Fhjr S4HpSEDHSmGo0SLjrTt49aRVGOgpcD0o0BXDevrRvHrRtHpS4HpSDUTePWjePWlwPSjA9KA1 E3D1o3D1pcD0owPSgNRNw9aaHAYg0/A9KaFGTwKYai7l9aNy+tG0elG0egpBqG4etG4etLge lJtHpQGobh60u4etJtHoKXaPSgNRNw9aXcPWk2j0FLgelAajHcDFODA96R1BxShQO1PQWtw3 D1pdw9aTaPSl2j0pD1E3D1pdw9aNo9KNo9KA1DcPWjI9aNo9KTaPSgNQ3D1oJGOtG0elBUY6 UBqIrAjrS7h60gUY6Uu0elMNRcj1o3D1pNo9KNo9KQai5HrSbh60bR6UbR6UBqLketG4etJt HpRtHpQGouR603cM9aXaPSk2AtyKYai7h6ilyPWk2L6UbR6Ug1FyPWk3D1o2j0o2r6UBqLke tGR60m0elGxfSgNRcj1oyPWk2j0o2j0oARmAxS7h6011GBxS+WvpTDUdketGR60mxfSjaPSk Gouahu3C2zn2qXYPSqmp4SzfsTTDU5wnJrotKwtmvauc711FnGotUGO1AFjI9aQketGxfSja PSkGoisCOtOyPWmIg64p20elMFcXIoyPWk2j0o2j0pALkUZFJtHpRtFAC5HrRmk2j0o2CgNR c0mQG60bR6U0oC1MHcfketGR60mxfSjYvpSDUz9Zn2W2wHlq541qa3IDOqL2HNZlMDU0OHMr SnoOBW7ketU9OtlitUyOSMmrWxfShhqOyKMik2L6UbF9KQagSBS5FMZBilEYphqOzRmk2Cja PSkGouaM0mwelGwUBqLmjNJsFGwUBqLmjNJsFG0UAAIpaaEFLtFMNRciik2LRsFINRc0UmwU bF9KA1FzRkUmwelGwelAai5pCQGGaTYvpSMgJFMHcfRTdgpdgpBqLRSbBRtFAC0Um0UbBQAu aKTYtGwUBqDdKXNNZQRQEFMNR2aKTYKNopALRSbRRtFAC0U3YKXYKAFopNgo2CgNQBHNLTAg yaXYPemGo6ik2CjYKQC0U3YPel2igNRaKTaKNgoDUWkJGRRsFIUBNMNR1FN2D3pdg96Qai0U 3YKXYKA1FopNgo2D3oAWik2ijaKABjgUoORTWUEUioAOpphrcfRSbB70bB70g1HUU3aPejaP egB1FN2j3o2igBaWm7B70bR70AA6mlpgTk8mnbB70w1HUU3YPejYPekA6imbB6ml2D1NAC0U 3YPU0u0UALSE8ijYKRlye9AajqKbsHqaNg9TQGo6im7B6mjYPU0BqOopuz3NGwepoAfRTdnu aNvuaAFPSgHikK8Uipx1NMNR9FN2e5pNnuaQD6Kbt9zRs9zQA6im7fc0bfc0AOopu33NG33N AAD8xp1RbMt1NP2e5pgrjqKbt9zRt9zSAdRTdnuaNvuaAHUU3b7mjb7mgBaRqTZ7mkZcjqaY D6KaE4xk0bPc0g1H0U3Z7mk2e5oAfSUmz3NJs9zQA+im7Pc0bPc0ALSLRt46mmqnfJpgSUUz Z7ml2+5pAOopuz3NAX3NADqKbt9zRs9zQA6im7fc0bfc0AH8VOqMrk9adt46mmAtLTNnuaXZ 7mkA6im7fc0mz3NAD6Kbt9zRs9zQA6mP0pdvuaay9OTTBjxS0g6UtIYUUUUAFFFFABRRRQAU UUUANH3jTqaPvGnUAJRS0UAJRS0UAJRS0UAJSMDkU6mt2oAWilooAKSlooAKSlooASilooAR ulIv3RSnpQv3RQIWiiigYlFLRQAUUUUAFJS0UAMGdxp1IPvGnUCQlFLRQMSilooASloooASk fpTqa/SgQvaiiloGJRS0UAJRS0UAVNSUtZyY9K52EHz0we4rqLgZgce1csOJQfQ0wOsTOwfS helJEd0Sn1FKvSkIWilooGJRS0UAJRS0UAJS0UUANP3qWk/ip1ACUtFFACU140kGGUMPcU+i gCo2nWrHJiXPtTBpdrnPl1eop3YrEMdvFF9yNR9BUjdKdSN0pAA6UUDpS0DEopaKAEopaKAE opaKAEpiZyakpq96BC0UtFAxKKWigBKKWigBKKWigDm9XH+lscdqXRyReAD0pdZH+l9cnFGi /wDH3+FMR0NLRRSGJRS0UAJS0UUAFIelLSHpQADpS0g6UtABRRRQAlFLRQAUUUUAFNX7xp1N HU0CHUlLRQMSloooAKKKKAEopaKAGN1FOpG6inUCEopaKBiUUtFACUUtFACUHpS0h6UAA6UU DpS0AJRS0UAJmjNLRQAlFLRQAlIDyadSDrQAUUtFACUUtFACUtFFACUUtFADW7UtI3anUAJR S0UAJWdrT4tQPU1pVka63yov40AYwyXGK6u3BECA+lczaLvuox711Q4ApgFBPFLSGkA1OlPp q9KdQJCUtFFAwooooAKSlooASk/ip1N/ioAdSE4BpaZIcRsfQUAcvfOXu5CfWoo1LSKBySaJ jmRj6mpbIA3Ue7gZpiOnhG2FQeoFPoHQUtIYlLRRQAhooaloASilooASloooASloooASiloo AavSnU1elOoASloooASilooASilooAKb/FTqb/FQAtFLRQAUUUUAFFFFABSUtFADW6UtI3Sn UAFFFFABRRRQAlFLRQAUlLRQA1T1p1NHenUAFFFFACUtFFABRRRQAU0n5hTqb/FQA6kpaKAC iiigApKWigBKWiigBG6UA8UN0oHSgBaKKKACiiigAooooAKKKKAGqeTTqavU06gAooooAKKK KAEpaKKACmk8inU09RQA6iiigApKWigBKWiigAooooAQnigHig9KB0oAKKWigBKWiigApKWi gAooooAaD8xpaQfeNOoAKKKKACiiigAooooAKaxp1NagB1FJS0AJS0UUAFJS0UAJS0UUAIaR elLSL0oAdRRRQAlFLRQAUUUUAFFFFADc/PTqb/HTqBCUtFFAwpKWigAooooAKa54FOpj9KBM cKWkFLQMKKKKACiiigAooooAKKKKAGj7xp1NH3jTqACiiigAooooAKKKKACmt2p1NPagB1FF FABRRRQAUUUUAFFFFACHpSL90Up6UL90UALRRRQAUUUUAFFFFABRRRQA0fep1NH3jTqACiii gAooooAKKKKACmv0p1NbpQIWloooGFFFFABRRRQAyX/VNn0rk5D+8OOma61xlGHtXJz8TMMd DTA6i1/49o/pUi9KhsTutIyPSpl6UgHUUUUAFFFFABRRRQAUUUUAN/ip1N/ip1ABRRUFzcLb xlmNAE1LXPtrM2/gKBQNbmDcquPSgDoKKwl1yTPMa1MNcTHMRz9aANemt92s7+2YMfdbNQTa zkERofqaALWoXxtowEwWPrUWm6jJO/lygE+orHmnediztk1f0a3LSGU5AFMLm9RRRSAKKKKA CiiigApi9TT6YvU0CH0UUUDCiiigAooooAKTtS0h6GgDmdTYNeP1OKt6EoMjtjnFULwg3UhH TNa2hqBE7Y5zTEatFFFIYUUUUAFFFFABSHpS0h6UAA6UtIOlLQAUUUUAFFFFABRRRQAU0feN Opo6mgQ6iiigYUUUUAFFFFABRRRQA1uop1NbqKdQAUUUUAFFFFABRRRQAUh6UtIelAAOlLSL 0paACiiigAooooAKKKKACmjqadSd6AFooooAKKKKACiiigAooooAa3anU1u1OoEFFFFAwrD1 x8zKvoK3K5vV5N94wHbigBumgm9jxXTVz+iITdE+groKbAKTtS0h6UgEXpTqanSnUAgooooA KKKKACiiigApv8VOpv8AFQA6o7jiB/pUlRXP/HvJ/umgDk35Y1Y05c3kYPTNQN944qzpgJvU piOmpaKKQwooooARqWkaloAKKKKACiiigAooooAKKKKAGr0p1NXpTqACiiigAooooAKKKKAC mn7wp1NP3hQA6iiigAooooAKKKKACiiigBrdKWkbpTqACiiigAooooAKKKKACiiigBq06mr3 p1ABRRRQAUUUUAFFFFABTT1p1IetAC0UUUAFFFFABRRRQAUUUUAI3Q0DoKRulKOlAC0UUUAF FFFABRRRQAUUUUANHU06mjqadQAUUUUAFFFFABRRRQAUh6ilpD1FAC0UUUAFFFFABRRRQAUU UUAIelA6UHpQOlAC0UUUAFFFFABRRRQAUUUUANH3qdTR9406gAooooAKKKKACiiigApGpaa1 ADqKKKACiiigAooooAKKKKAEpF6UtIvSgB1FFFABRRRQAUUUUAFFFFADf4qdTf4qdQAUUUUA FFFFABRRRQAU1ulOpr9KAYopaQUtABRRRQAUUUUAFFFFABRRRQA0feNOpo+8adQAUUUUAFFF FABRRRQAU1u1OprdqAHUUUUAFFFFABRRRQAUUUUAIelC/dFB6UL90UALRRRQAUUUUAFFFFAB RRRQA0feNOpo+8adQAUUUUAFFFFABRRRQAU1+lOpr9KBC0tJS0DCiiigAooooARuVNcpdjFw 4PrXWVzOpxlL1/fmmBs6UQbJcHNW16VmaHJugZD2Naa9KQDqKKKACiiigAooooAKKKKAG/xU 6mn71OoEFZGtmXaMD5PWtemSRrIu1wCKBnHn60mK6V9JtnP3SPpVSfRMAmF8n0NOwrmKfrQK klheJirqQRTCOKQC80oDE4GantJIkcecgZa3YEtZEDwon5U9A1Miz06WdwWBVO5Nb8EKQRhE HAqRRgCihsBaKKKQwooooAKKKKACmKeTT6YvU0CH0UUUDCiiigAooooAKiuH8uB29BUtZmsz tHCEHR+tAGG7F3LHua6PS0CWaY781z1vH5s6J6muqiQRxqo6AUwH0UUUgCiiigAooooAKQ9K WkPSgAHSlpB0paACiiigAooooAKKKKACmj7xp1NH3jQIdRRRQMKKKKACiiigAooooAa3UU6m t1FOoAKKKKACiiigAooooAKQ9KWkPSgAXpS0g6UtABRRRQAUUUUAFFFFABSdzS0negBaKKKA CiiigAooooAKKKKAGt2p1NbtTqBBRRRQMQ9K5a9bddSH3rppmCRMxOMCuUkO6Rm65NMDX0ID EnrWxWbose22LkfeNaVDAKTtS0h6UgETpTqavSnUCQUUUUDCiiigAooooAKb/FTqb/FQA6ob s4tpPpU1Q3f/AB7SfSgDlT1OKu6Tj7av0qi3Wrukn/TUpiOkooopDCiiigBGpaQ0tABRRRQA UUUUAFFFFABRRRQAi0tNXpTqACiiigAooooAKKKKACmn7wp1NP3hQJjqKKKBhRRRQAUUUUAF FFFADW6UtI3SloAWiiigAooooAKKKKACiiigBBS0i96WgAooooAKKKKACiiigApD1FLSHrQA tFFFABRRRQAUUUUAFFFFACN0oHSkbpSjpQAtFFFABRRRQAUUUUAFFFFACDqaWkHU0tABRRRQ AUUUUAJS0UUAFIeopaQ9RQAtFFFABRRRQAUUUUAFFFFACHpQOlB6UDpQAtFFFABRRRQAUUUU AFFFFADR9406mj71OoAKKKKACiiigAooooAKa3anU1qAHUUUUAFFFFABRRRQAUUUUAJSL0pT SL0oAdRRRQAUUUUAFFFFABRRRQA3+KnU3+KnUAFFFFABRRRQAUUUUAFNfpTqY/3aBMcKWk7U tAwooooAKKKKACiiigAooooAaOpp1M3ANg0u5fUUCuOopNw9aNw9aBi0Um4etG4etAC0UmR6 0bh60ALTT2pcj1ppYcc0CH0Um4etG4etAxaKTI9aNw9aAFopMj1oyPWgBaKTI9aMj1oAD0oH SkJGOtCsCOtAh1FJketGR60DFopMj1oyPWgBaKTI9aMj1oAWikyPWjIoAT+KnUzeA2M07I9a BC0UmRRkUDFopMijIoAWikyKM0ALTX6ClpG6UCFpaQEEUZoGLRSUZoAWikozQAtYmuRYkWQD g8ZraqvexCa3ZeM44poDE0mby7oKTw3FdEnTiuTBaOUHOCprprOUS26tnPrQIsUUmaM0hi0U maKAFopKM0ALRSUUAJ/FTqaSA3NLQIWikoJoGFLWdPq0UMxQqTjuKs295DcLlG59KAHT28c6 lZFBrFvdKeHLxfMnp3FbkkyRJudgBWZc6xEAVjBb3p3CxiHPpirenTNHcqoPB4qrI+9i2OtT WMbPcrgZxzQtxM6pfuilpiH5RTs0hi0UlLQAUUUUAFFFFABTV6mlpFPJoEOooooGFFFFABRR RQAhrndXmEl0QDwvFbN/P5FszZwe1cwzMzEtySaANDR4d9xvPRa6GszSYDDCGY8tzWlTYkLR RRSGFFFFABRSUUALSHpS0h6UAA6UtIpyKWgAooooAKKKKACiiigApo6mnU0dTQA6iiigAooo oAKKKKACiiigBp6inU1jgiloAWiiigAooooAKKKKACkPSlpD0oAB0paQdKWgAooooAKKKKAC iiigApB1NLSdzQAtFFFABRRRQAUUUUAFFFFADW7U6mt2p1ABRRRQBU1NttlJ9K5nvit7WpNt uFzjcaxIhulUDqTTA6ayj8u1jX2qxTIxtjUHsKfSAKQ0tIelACL0p1NU5FOoAKKKKACiikoA WiiigApP4qWm/wAVADqgu8fZpMnAxU9V77/j0k+lAHLHGTV7SBm9XHYVQbrV/Rv+PwfSmI6O iikpDFooooARulLSGloAKKKKACiiigAooooAKSlooARelLSCloAKKSloAKKKKACiiigApp+8 KdTT96gB1FFFABRRRQAUUUUAFFFFACN0ooPSigBaKKKACiiigAooooAKKKKAEHelpBS0AFFF FABRRRQAUUUUAFIetLSHqKAFooooAKKKKACiiigAooooARulA6UN0oHSgBaKKKACiiigAooo oAKKKKAEHU0tNHU06gAooooAKKKKACiiigApD1FLTT1FADqKKKACiiigAooooAKKKKAEPSgd KD0oHSgBaKKKACiiigAooooAKKKKAGj7xp1NH3jTqBIKKKKBhRRRQAUUUUAFNanUjUALRRRQ AUUUUAFFFFABRRRQAlIvSlpF6UAOooooAKKKKACiiigAooooAb/FTqb/ABU6gAooooAKKKKA CiiigApr9KdTW6UAxRS0gpaACiiigAooooAKKKKACiiigCMoGbml8tfSlHU0tMVkN2L6UbF9 KdRSCyG7F9KXYvpS0UBZDdi+lGxfSnUUBZCbB6UhjBp9Ie1Fwshvlr6UbF9KdRQFkJsX0o2L 6UtFAWQmxfSk2L6U6igLITYvpRsWlooCyGlF9KFQYpx6Ui/dFO4WQnlr6UbF9KdRSCyG7F9K PLX0p1FAWQ3y19KNgp1FAWQ3y1o2CnUUBZDPLBajylp38VOp3YWRH5a+9L5Y96fRSuFkMMa0 eWPen0U7hZDPLFHlin0UrhZDNg96R044NSU1ulMGkNEQA6ml8se9OpaLhZDNg9TR5Y96fRSu FkM2D3o2Cn0UXCwzyx6mk8oe9SUUXCyOd1W1FvNuXkPzTtKuCsohY8HpWtf2y3MBGPmHINc2 xaKTjIKmmFjq9me5pBGPU1FYz/aLZXJ571ZouFkM8sepo8sepp9FK4WRH5fuaXyx6mnUtO4W Qzyx6mjZ7mn0UrhZELR5YcmneUPU07+KnU7sVkR+X7mo7hdkLEE8CrFIwDKQehouOyOPkYs5 PvSJIynKkj6VuzaLE7ExsUzVGbSLhM7QGHtRYLlOS5lkGHcn8aiJp8lvJGTvQr9RTMGlYYA1 Pb3bQN8oFQ4pO9AF8arMD0GKQ6pcE8HAqjSjk0Csjo9OuDdR5Y4YVd2f7Rqho0JjgLMuCa0q YWGbP9o0bPc0+ilcLDNn+0aNnuafRQFhmz/aNMEZ3Hk1NTV6mncTSE8v/aNGz/aNPopXHZDN h/vGjZ/tGn0UXCyGbP8AaNBX/aNPrO1O/FupjTlz+lFwsZ+rXPmS+WrZC9ar2Nubm4VccDk1 XYlzknk10Gk2vkQB2+81MC0IgoCg0/Yf7xpx6inUXFZEew/3jS7Pc0+ilcdhmw/3jRsP940+ ii4WGbD/AHjRsP8AeNOoouFhu0/3jQVOOtPpD0oCxGsZxwcUuw/3qeOlFO4JIbsP940bD/ep 1FAWG7D/AHjRtP8AeNOooCwm0+tJtP8Aep1FILDdp/vU3Yd3WpKQfeNMLCbT/eo2n+9T6KQW GbT/AHjRtb+9T6KAsM2n+9RtP96n0UBYZtb+9RtP96nUtAWInB45pQjf3qc3UU6ncViPa396 l2t/ep9FIdhm1v71GG/vU+igLDNrf3qNrf3qfRQFhm1s/eoKtjrTqD0phYjVGH8XFO2t/epw 6UtFwSGYb+9Rtb+9T6KQWGbW/vUbW/vU+koCw3Df3qMN/ep9FAWGYb1phVt/Bqak7mncGhu1 /wC9Rtb+9T6KQWGYb+9Rtb+9T6KAsMw3qKMN6in0UBYZhvUUYb1FPooCxE6sR1pQHx1px7U6 ncLEeH/vUuH9afRSCxia5kbATzVCzUtcoAMnNXdcz5y9MYqDSR/py80wsdAA+ByKXDetPopB YZhvWghsdafSdqAsRIrc4NOAf1FOTpTqbYkhmG9aMP8A3hT6KQ7DMP6ijDZzkU+igLDMP6ij D+op9JQFhoD9yKaQ27g1LTf4qYWEw/qKgvFY2z5IxirVQXn/AB6yfSi4WOVOM1c0oE3i7Tg1 TOM1d0gZvV6dKAOhAf1FJh/UU+ikFhuH9RR8/qKfRQFiJw2OtKA+Oop5op3Cw3D+oo+f1FPo pBYZh/UUYf1FPooCwzD+oow/qKdRQFhvz+oo+b2p1FAWI1D5PNO+f2pwop3BIZh89RS4f1FO paQWGfP6ij5/UU6igLDcPnqKPn9RT6KAsM+f2prb9wxUlIfvCncGhBv9qPn9qdRSCw35/aj5 /anUUBYb8/tR8/qKdRQFhvz+1Hz57U6igLDG346igb8dqeaKdwsN+f2o+f2p1FILDfn9qPn9 qdRQFhvz+1Hz+1OooCw35vaj5vanUUBYjG/Jp3z+1OFLTuFhnz+1Hz+1OopBYb8/tR8/tTqK AsN+b2o+f2p1FAWG/N7U1i+RipKD1FMLDfn9qDv7Yp1FILDfn9qPn9qdRQFhvz+1Hz+1OooC w35/aj5/QU6igLDG3bTSKXxyBUh6UDpTuK2o35/QUZf0FPopDsMy3oKMv6CnUUBYb8/oKPn9 BTqKAsN+f0FHz+gp1FAWIxv3HgU7L+gpw6mlphYZl/QUZf0FPopBYZl/QUZf0FPooCwzL+go +f0FOpaAsMy3oKa+7IwKlpD2phYbl/QUZf0FPopBYZlvQUZf0FPooCwzL+goy/oKfRQFhmX9 BRl/QU+igLDCWx0pFL46U89KB0phYblvSjL+lPopBYZlvSjL/wB0U+igLDMt6UZb0p9FAWGZ f+6KMt6U6igLEW59/AzTsv6U4feNOpiSGZf0oy/92n0Uh2GZf0oy/oKfRQFhm5v7tG5v7tPo oCxGC/pSOXx0qWmmncLDQz4+7S7n/u0+ikFhmX9BRl/Sn0UBYZl/Sky/oKkooCwwF/SjLegp 9FAWGEt6U1d4zxUlA6U7hYblvSjL+gp9FILDAX7iky/oKkooCwzL+goBb+7TqKAsNy3pRub+ 7T6KAsREvu4FO3P/AHaX+KnUwsMy3pRlvQU+ikFhmW9KMt6U+igLDMv6UZb0FOooCw3LelNc txxUtNbpTBoUdKWkFLSGFFFFABRRRQAUUUUAFFFFADR9406mj7xp1ABRRRQAUUUUAFFFFABT W7U6mt2oAdRRRQAUUUUAFFFFABRRRQAh6Ui/dFKelIv3RQA6iiigAooooAKKKKACiiigBo+9 TqaPvU6gBKWkpaACiiigAooooAKa/SnU1+lAmLS0naloGFFFFABRRRQAUUUUAIelYWrW2x/N UcHrit6oZIhNEyMMg00JmJpN35E3lsfleugHNcrcQtbzFD1B61uaZdieAKx+detDGX6KKKQB RRRQAUUUUAN/ip1N/ip1ABRRRQAUUUUAMdEcYZQR71WfTbV/+WQH0q5RRcDPbR7Y9Aw/Gmf2 NbKM/MfxrTprdKdxWM46NbkcFhT4dJt4m3EFj71fHSlouFhFAUYAwKWiikMKKKKACiiigApq 9TTqavU0CHUUUUDCikqjf6klupVCGf09KAHX98trGQDlz0Fc7JK0rl3OSaJZXmcu5yTVvTtP a4kDOCIx+tNBck0qx85/MkHyD9a3wMDApqIsahVGAKfQwGnqKdTT94U6kAUUUUAFFFFABRRR QAUh6UtIelAAOlLSDpS0AFFFFABRRRQAUUUUAFNH3jTqav3jQA6iiigAooooAKKKKACiiigB p6inU1uop1ABRRRQAUUUUAFFFFABSHpS0h6UAA6UtIOlLQAUUUUAFFFFABRRRQAUnc0tJ3NA C0UUUAFFFFABRRRQAUUUUAI3alpD2paACiiigDB1w/6Sv0qHSv8Aj9XpUut/8fS/Sq+mY+3J mmB09FFFIApO1LSUAIvSnU1elOoBBRRRQAUUUUAFFFFABSfxUtN/ioAdVe9/49JPpVioLwZt ZPpQBylW9MJF6m2qp61PZMI7lGPTNMR1NLSKcqDS0hhRRRQAjUtI1LQAUUUUAFFFFABRRRQA UUUUAIKWkFLQAUUUUAFFFFABRRRQAU3+KnU0/eFADqKKKACiiigAooooAKKKKAEPSikbpS0A LRRRQAUUUUAFFFFABRRRQA1adTVp1ABRRRQAUUUUAFFFFABTT1FOpp+8KAHUUUUAFFFFABRR RQAUUUUAIelA6UN0oHSgBaKKKACiiigAooooAKKKKAGjqadTR1NOoAKKKKACiiigAooooAKa eop1NPUUAOooooAKKKKACiiigAooooAQ9KB0oPSgdKAFooooAKKKKACiiigAooooAaPvU6mj 7xp1ABRRRQAUUUUAFFFFABTW6UtI1ADqKKKACiiigAooooAKKKKAEoXpRQvSgBaKKKACiiig AooooAKKKKAG/wAVOpP4qWgBKWiigAooooAKKKKACmv0FOprdBQJiilpBS0DCiiigAooooAK KKKACiiigBo+8adTR9406gAooooAKKKKACiiigAprdqdTW7UAOooooAKKKKACiiigAooooAR uhpE+6KVuhpE+6KBdR1FFFAwooooAKKKKACiiigBo+9TqaPvU6gAooooAKKKKACiiigApj9K fTH6ChCY6lpKWgYUUUUAFFFFABRRRQAlInQ0tIvQ0CMzWoN0SyqB8vWsq0nNtOrA8d66eRBJ GUboRXMXlu1vOVb8KYHTxSLLGHQ5Bp9Y+jXYx5D9e1bFIYUUUUAFFFFADT94U6mn7wp1ABRR RQAUUlLQAUUUUAFI3SlprfdoAUdKWkHSloAKKKKACiiigAooooASmp1NOqIypGGLsFHvQImp kkqRqS7ACsy51hVysK7j6npWRNcSTsWdic0DNK+1UtlIOB3asolnbuSakgtpbhtsak1t2Wlx wAPJ8z/ypiuUrLSXcq83C9cd63EQIoVRgClpaVxhRRRQA0/eFOpp6inUCCiiigYUUUUAFFFF ABSHpS0h6UAA6UtIOlLQAUUUUAFFFFABRRRQAU0feNOpo6mgQ6iiigYUUUUAFFFFABRRRQA1 uop1NPUU6gAooooAKKKKACiiigApD0paQ9KAAdKWkHSloAKKKKACiiigAooooAKaOpp1NH3j QA6iiigAooooAKKKKACiiigBp7U6mt2p1ABRRRQBga5/x8r9Kp2WRdRkY61e11f3yNntVC14 uo8nvTEdWOgpaRfuilpDCkPSlpD0oAROlOpqdKdQJBRRRQMKKKKACikpaACk/ipaT+KgBaju Bugce1SUjDIIoA5B+GNEbYcH0NS3kZiuXUjHOahBweKYjrLd98KN6ipaqaY26yTnNW6Qwooo oAa1OprU6gAooooAKKKKACiiigAooooAavSnUi0tABRRRQAUUUUAFFFFABTT94U6mn7woAdR RRQAUUUUAFFFFABRRRQAjdKWkbpS0AFFFFABRRRQAUUUUAFFFFADR3p1NXvTqACiiigAoooo AKKKKACmnqKdSHrQAtFFFABRRRQAUUUUAFFFFACN0oHSkb7ppR0oAWiiigAooooAKKKKACii igBo6mnUg6mloAKKKKACiiigAooooAKaeop1NPUUAOooooAKKKKACiiigAooooAQ9KB0oPSg dKAFooooAKKKKACiiigAooooAaPvmnU0feNOoEgooooGFFFFABRRRQAU1qdTWoAdRRRQAUUU UAFFFFABRRRQAUg6UUi9KAHUUUUAFFFFABRRRQAUUUUAJ/FS03+KnUAFFFFABRRRQAUUUUAF NbtTqa3agBRS0lLQAUUUUAFFFFABRRRQAUUUUANH3jTqYPvGnUCQtFFJQMWikooAWikooAWm t2paRuooAdRSUtABRRRQAUUUlAC0UlFAA3Q0ifdFK3Q0ifdFAuo6iikoGLRSUUALRSUUALRR SUAIPvU6mDO406gBaKSloAKKSloAKKSloAKY/SnU1+lAmOHSlpB0ooGLRRSUALRSUUALRRSc 5oADSJ0NKelNTpQLqPrP1a186Dev3lq/QRkEGgZycUhhlV16g101rOtxCrr361g6nam3mJA+ VuRT9Ku/Im2N9xqbBHRUUgORkdKKQC0UlFACfxU6mH79OoELRSUUDClpKKAFoopKAFprdKWk f7tAMUdKWkHQUUALRSUUALRSE461SudShhyM7m9BQBeqvPeQQA73GfSsS51SeXhTsX2qkSzn qSfegDVuNaYjEKY9zWbNcSTNl2Jp0FpNMfkQn3rTtdJQENN8x9KdhXMqKCSc7UUk1qW+jdGm f/gIrUjhjiGEQL9KkouAyKJIl2ooAqSkpaQwopKWgAopKKAEPUU6mn7wp1AgooooGFFFJQAt FJRQAtIelFB6UAA6UtIOgooAWikooAWikooAWikooAWmjqaWkHU0AOopKWgAopKKAFooooAK KKKAGnqKdTW6iloAWiiigAooooAKKSloAKQ9KKD0oAB0paRelLQAUUUUAFFFJQAtFJRQAtNH 3jTqaOpoAdRRSUALRRSZoAWiikoAWiiigBrdqdTWPSloAWikooAx9dQfI/fpWQhxIp9629cU GBWxyDWEODTA66E7olPtUlV7Ek2kZPpU9IBaQ0UHpQAi9KdTVPFOoEgooooGFFJRQAtFFJQA tN/ipaTPzUAOopKWgDA1uPbcK47isyuh1mLfbbv7tc8RimI3NDlzE0ZbkdBWtXNaVKY7tR68 V0gNIYtFJS0ANanU1jS0ALRRRQAUUlFAC0UUUAFFFJQAClpqninUAFFFJQAtFFFABRRRQAU0 /epaQn5hQIdRRRQMKKKKACiiigAooooAa3SlpGOBSigBaKKKACiiigAopKWgAoopKAEXvTqa venUAFFFJQAtFJS0AFFFFABTT94U6mn7woAdRRSUALRSUtABRRRQAUUUUAIelA6UN900i9BQ A6iiigAooooAKKKKACiiigBB1NLTR1NOoAKKKKACiiigAopKWgAprdRTqYx5FAmPooooGFFF JQAtFFFABRRRQAh6UDpQelA6UALRRRQAUUUUAFFFFABRRRQA0feNOpg+8afQJBRRRQMKKKKA CiiigAprUtI3agB1FJS0AFFFFABRRSUALRRRQAlIvSlNIvSgB1FFFABRRSUALRRRQAUUUUAJ /FS03+KnUAFFJS0AFFFFABRRRQAU1ugp1NfpQJi0tIKWgYUUUUAFFFFABRRRQAUUUUANHU0t RkNv+WnfP6imK46im/P7UfP7UguOopvz+1Hze1AXHUU35/aj5vagLjqD2pvze1I27A9aYXH0 U35/aj5/akFx1FN+b2pfm9qAuLRSfN7Unz+1AXHUU35/aj5vagLjj0pF+6KQ7sdqRd+O1MLj 6Kb8/tR8/tSC46im/P7UfP6CgLjqKaN1Hz+1AXHUU3L+gpfm9BQFwHWnVCSwfinZf0FOwrkl FMy/oKPm9BSHcfRTPn9BR83oKAuPopnzegoy3oKAuPprdKQFu4pHLY4FMGx9LUYL45FLlvSk Fx9FMBbuKMt6UBcdRTct6UZb0oC4+imZb0oy3pQFx1IvSky3pTVLZ6ZphclopmW9KMt6UguQ X9sLm3Zf4hyK5lgUcg8EGusJf+7WJq1oVYzAYB60wuXNKvRLGInb5x+tadcdFK0ModCQRW3b awj4WQbT69qQzWpKiSbeAVwR7GoryWSOBiq9utOwrkU2pwRSlTkkdcVchmSdA8ZyK5J2JYkn JNa2izH5kAzSGbdFR7m/u0u5v7tMVx9FMDN/do3N/doC4+imbm/u0bm/u0BcdSN0pNzf3ail uEjHzsF+poC5OOlFZj6xEnCgtWfcapNKSFbavoKQzfluIoly7qPxrOuNZRciFd3uaxC7Mckk /WnxwSSnCITQkFyWa9nmJ3SHHoKr/Mx45NaUOkStgyfKPSrcsMVjbMyxjI7mqsTczLewkmYb iEHqa2LbS4IgCw3t6mufeZ3csWNbmk3DyQYbLEUrjNEKFGFAA9qROpo3H+7TVYhjgZoFckop u4/3aNx/u0h3H0Uzcf7tG4/3TQFx9FM3H+7RuP8AdoC4+imFj6GgMf7poC449RRTGYgjil3n +6adguPopgY/3aXcfSkFx1FM3H+7S7j6UBcdRTNxz900u4+hoC46kPSk3H0NIW46UBccOlLU aucdDS7vY0BcfRTd3saNx9DQFx1FM3expd3saAHUU3d7Gjd7GgB1NHU0bvY0zed3SmDZLRTd 3saTf7GkFx9FN3exo3exoC46im7vY0bvY0BcdRTd3saN3saBgeop1Ru+McGl38dDTsK6H0U3 d7Gjd7GkFx1FN3exo3exoC46im7vY0m/2NAXH0h6U3f7Ggtx0NAXHDpS1GHwO5pd49DQFx9F N3expN49DQFx9FN3expC/saAuPopm8ehpd31oC46kHU0m4e9N34agLklFM3j0NLvHoaAuOop u72NJv56GgLj6KbvHvRvHvQFx1FM3j3pd496AuB7U6o2fGODS+YMd6dguh9FM8wUeYtKwXK2 qRl7NsdRzXMmupunDW7gdxXLNwSKYHR6PL5loATyvFX653SLpIJSH4Dd63lmVxleRSC5JSGm 7x70FhiiwXFXpTqiVwODTt496dgTQ+im7xSbx70rBcfRTN4pd4oC46imbxRvFAXH03+KjeKa Xw3SnYLofRTfMWk81fWkF0Nu032zrjPFcm4IY11bXEWCC4/OuYuwouJNvTPagBsL+XIrDgg1 1VrL50Cv6iuQBrc0S6+QwntzmgZs0U3eKN60CuBp1MZwBQJFNOwXQ+im7xRvFILjqKbvFG8U BcdRTd4o3igLjqKbvFG4UBcUUtMDjvS71osF0Oopm8Uu4UBcdRTd4o3igLjqKbvFG9aAuOpp +8KNwppcA0wuh9FN3r60u9fWkF0Oopu8Ub19aAuOopu4Ubx60BcdRTdwo3r60BcU9KKQsMUg cGgLj6KbvHrRvFAXHUU3cKN4oC46im719aN49aAuOopu8etG4etAAO9OpgcUu9fWgLodRTd6 +tG4etAXHUU0OD3o3CgLjqKbvX1o3r60BcdSd6TePWmlwCKLBdElFN3r60bh60BcdRTdw9aN w9aBjqKbvHrRuHrQFx1FN3D1o3CgBW6UDpSFhigMMUCuOopu4etG5fWgdx1FN3D1o3D1oAdR Tdw9aNw9aAuOopu4etG4etAXAdTTqYHGcUu4etArjqKbuHrRuHrQMdRTdw9aNw9aAuOopu8e tG4etAXHU0jkUbh60jOARzQJsfRTdw9aNw9aAHUU3cPWjcPWgdx1FN3D1o3D1oC46im7h60b h60AKelA6UhIxQHGOtAh1JSbh60bh60DHUUm4etG4etAC0U3cPWjcPWgB1FJuHrRuHrQAg+8 adTN4DdaXcPWgVx1FN3D1pdw9aBi0U3cPWjcPWgB1FJuHrRuHrQAUjCjcPWkZgB1oEOpabuX 1o3D1oHcdRTdw9aNw9aAHUlJuHrRuHrQA6im7h60bh60ALSLRketIrD1oEPopu4etG4etAx1 JSbh60bh60AOopu4etLuHrQAtFJuHrRketACY+anUzcN1O3D1oEFLTdw9aXI9aBi0lJuHrS7 h60ALRTdw9aNw9aAHU1+lLketNcjjmgTHClpBS0DCiiigAooooAKKKKACiiigBo6mnU0feNO oAKKKKACiiigAooooAKQ9qWmt2oAdRRRQAUUUUAFFFFABRRRQAh6Ui/dpT0oXoKAFooooAKK KKACiiigAooooAaPvU6mj7xp1ABRRRQAUUUUAFFFFABTX6cU6mv0oExaWkFLQMKKKKACiiig ApKWigBKRelLSL0oAdRRRQAVHNEs0ZRhwakooA5m80+W3fpuTsRVMgiuwIBHIzVK50uGfJX5 G9RT0Ec/FPLEQUcirT6nO8JjYhgfappNFmX7jK36VUuLCeAEuhx6iiwXKxJq7pt4lq5LgnPp VAilVaQzpRq9qR94/lSjVbU/x/pXN8mjmiwXOm/tK1/56ikOqWo/jz+Fc1zml5osFzoG1i3H TcfwqtLrfaOP86yME9OacsEjnCoxP0p2C5ak1S5c/f2j2qo8rSNlmJPvVlNOuX/5ZkfWrsei gANK/PoKLCuY+Cx45NWrfTZ58HZtU9zW/BZQQgFIxn1qxjFAGdbaRFGP3vztV9I0QYVQB7Cn 0UrjsFUdVhMtq2O3NXqZKoeNlPcUAcf+NbWgv8jp71kzp5czp6GrmjyFbraOjUAdHTV6mlpq Hk0CH0UUUDCiiigAooooAKKKKAGnqKdTT1FOoAKKKKACiiigAooooAKQ9KWkPSgAHSlpB0pa ACiiigAooooAKKKKACmjqadTR940AOooooAKKKKACiiigAooooAawzilpD1FOoEFFFFAwooo oAKKKKACkPSlpD0oARRgU6kHSloAKKKKACkpaKACiiigApoHJp1IOpoAWiiigApKWigAoooo ASloooAa1DFVGSQBTZXEa7mOAKwNQ1BrhyiHEY/WgReu9YSMlYV3Ed+1ZcuoXMuQZCAewqGK J5nCouSa17TRgDunOfYU7BcxzNK3WRj+NRnOa6n+zbTGPKFV59GgkHyEqaLIZzoPNbOjXoGY pXHtmqc+lXERYhdyjuKq7Sh96VgudiCCOKD0rnbLUpLfCv8AMnpW5Bcx3EYdDwe3pQBIg4p1 InK06hiQlFLRQMTFFLRQAlFLRQAmKjldI8s7AAetFxOtvEZH6Cubvb17t+eF7CgDQuNaUErC mfc1mzXs8zZZyPYcVDHC8rbUXcfStS20VmwZmwPQUWC5lliTyTUb5zXTx6VbJ1Xd9aJtLtZR 9zafUU9BHLc8VpaVdR2znzQee9WLjRGUZhbd7Gst42jYqykEUWHc62KWOVd0bAj2p+K5W1u5 bZ8o3Hcetb9lfJdLxww6g0gLTDNKFA7Uh7U6gBMUYpaKAExRS0UAJiilooATFFLRQA0AdaXA oXpS0AJijFLRQAmBRilooATFGKWigBKaygsKfTT96gTFwPSjApaKBiYFGKWigBMUYFLRQAmB RgelLRQA0gY6UuAO1B6UUAGBRilooATAoxS0UAJgUYFLRQAmBRilooAYFHpTsD0pFp1AhMD0 owPSlooGJgelGBS0UAJgelGB6UtFACYFNKgkU+k70CDA9KMD0paKBiYoxS0UAJijFLRQAmBR ilooAaQMUADHSlbpQOlAgwPSjA9KWigYmB6UYFLRQAmB6UYHpS0UAJgelGB6UtFADQozmlwP Sgd6WgQmB6UYHpS0UDEwPSjA9KWigBu0elLgelLRQAmB6U1lBI4p9IeooFYTaPSlwPSlooGJ tHpSbR6U6koAMD0owPSlooATA9KMD0paKAGkDFAUY6Up6UDpQITaPSjaPSnUUDsJtHpRtHpS 0UAJtHpSbR6U6igBNo9KNo9KWigCPaN3SnbR6UD7xp1ArDdo9KNo9KdRQMbtHpRtHpTqKAsJ tHpSbR6U6igBu0elIyg9qfTTQKwbVHajaPSnUUDsN2j0o2j0p1FADdo9KNo9KdRQAm0elG0e lLRQA3aMdKRVAHSnUL0oFYTaPSjaPSnUUBYbtHpRtHpTqKAsN2j0pdo9KWigYm0elGB6UtFA DNoLUu0elH8VOoFYbtHpRtHpTqKAsJtHpRgelLRQMTaPSjA9KWigBNo9KawHHFPprdKBMUUt IKWgYUUUUAFFFFABRRRQAUUUUANH3jTqYPvGn0CQUUUUDCiiigAooooAKa3UU6mt2oAdRRRQ AUUUUAFFFFABRRRQAh6UL90UHpQv3RQAtFFFABRRRQAUUUUAFFFFADR9406mj71OoAKKKKAC iiigAooooAKY/Sn0x+lCEx1LSUtAwooooAKKKKACiiigBKRelLSL0oAdRRRQAUUUUAFFFFAB VDV222be/FX6ztaOLPHvQBzwGTiuktLKH7MgeNScdcVzifeH1rrLf/UJ9KYiI6fan/litJ/Z tr/zyFW6KLsLFUWFsP8AlitOFlbjpEv5VPS0XYWIlt4l6RqPwp4UDoAKdRSGFI3SlpG6UAA6 UtIOlLQAUUUUAFIelLSE4BoA5jVIxHePjoeabp5xdxn3pdSk8y7Y9QOKZYoWukx60wOrHSmp 1NOH3RSL1NAh1FFFIYUUUUAFFFFABRRRQAnelpD1paACiiigAooooAKKKKACkPSlpD0oAB0p aQdKWgAooooAKKKKACiiigApo6mnU0dTQA6kpaKACiiigAooooAKKKKAGt1FOprdRTqACiii gAooooAKKKKACkPSlpD0oAF6ClpB0paACiiigAooooAKKKKACmj7xp1NHU0AOooooAKKKKAC iiigAooooAyNbudqiFTyetYqAuwA6k1b1Zs3rc9Ki08kXkffmmB0FjZpbxDj5yOTVuk7UtIA ooooASqN5psVwCyja/rV+koA5O4ge3kKOORTra5e3kDKeO4ro7u2S5iKlQT2Nc1cQPBIUcYI piOksp1uIQ6/lVmuXsbo28wO4hSeRXTI6ugZTkGkMdRRRQAUUUUAFIaWop5BHCzE4wKAMTWr nfMIlPC9az4o2lkCKMk0kzF5Wc8knNauhwgs0jDkcCmI0bGzW2iAwC/c1boqOaVYYy7dBSGS UVjLrRMwygCVrRuJEDKcg0APqrd2UVyp3DDdjVqigDk7q0ktZSrdOx9aZFI0UgdDgiuourdL mIo4+h9K5u5t3glKPx6e9MRvWN4LqIZwHHUVcrlbSYwTq/bvXURuJEDKcgikMfRRRQAUUUUA FFFFABRRRQA1elOpq9KdQAUUlLQAUUUUAFJnnGKWigAph++KfTf4qBDqKKKBhRRRQAUUUUAF FFFACN0paRulLQAUUUUAFFFFABRRRQAUUUUANXvTqQUtABRRRQAUUUUAFFFFABTT1p1NP3qA HUUUUAFFFFABRRRQAUUUUANbpSjpQ3SgdKAFooooAKKKKACiiigAooooAQd6WkHeloAKKKKA CiiigAooooAKQ9aWmnqKAHUUUUAFFFFABRRRQAUUUUAIelA6UHpQOlAC0UUUAFFFFABRRRQA UUUUAMH3zT6aPvGnUCQUUUUDCiiigAooooAKQ0tNagB1FFFABRRRQAUUUUAFFFFACUL0ooXp QAtFFFABRRRQAUUUUAFFFFADf4qdTf4qdQAUUUUAFFFFABRRRQAU1+gp1NboKBMUUtJS0DCi iigAooooAKKKKACiiigBg+8afTR9406gSCiiigYUUUUAFFFFACUjdqdTWHSgQtLRRQMKKKKA CkpaKACiiigBD0pF+6KU9KRRxQIdRRRQMSlpKWgAoopKAFopKKAEB+anUwD5qdQJC0UlLQMK KKKACiikoAWmSHAFOpkg4poTHilpAOKWkMKKKKACiikoAWkpaTFABSL0paag4oEPopKKBi0U mKMUAFFBFFAC1Q1hd1mx9OavVXv4/MtJB7UIDlxwQa6u0cPboR6Vyh610elMHs19uKYF6iko pAFLSUUALRSYoxQAtNc4FLikcZFAmKOlFA6UUDFopMUUALTJc+W2OuKdSEcGgDk7gETvu65q XTgDdJxTL5dt1Jj1qbSQTeLTEdKOlNQ5Jp2OKYi4LUA9ySikopDFopKKAFopKKAFopKMUAIf vCnUwj5hTqBC0UlFAxaKSigBaKSigBaRulFDdKAAdKWkHSloAKKSigBaKSloAKKKSgBaaPvG lpqj5jQIfRSUUDFopKKAFopKKAFopKWgBjfeFPpjDkU6gQtFJS0DCiiigAopKWgApD0ooPSg AXpS0gHFLQAUUlLQAUUlFAC0UlLQAU0dTS0g6mgB1FJS0AFFJRQAtFJRQAtQ3UywQs5PQVKa 53WLlpLgxg/KtAFGaVppWduSaIGKSowOCDSIjOwVRljWja6TM7BpRtX360WFc3o23Rq3qKfT EQIgUdBxTqBhRketYurXzK/lRsR64rL+0zf89W/OgDrqWuZh1W5iAG4MB6059YuW6YWlcDoi wUEk4FYmq3NtOMKT5g74qjJe3Ev3pGwe1QHJNMArW0e9Kt5DnjtWfJavHAsp6NUSMUcMDyDT YjsKWoLOUTW6uO4qakMWikooAWqep4+xPn0q3VPVVzZvigDmu9dFpMYS2U9zzXPcZro9MBFs mfSqEXqzNalCwBN3LHpWlWBrT7rkL6CpGZw+8MV1dsu23QD0rlolzKoz3rq4l2xqM9qYElFJ RSAWs/VbbzoN6j516VLc38FucO/PoKoS62pyEjJHvRcLGQRg1taNdFlMLdulY80iySllGAec U6CUxSq6noaAOtoqKCQSxK4PBFSUAFLSUUALRSUUALSUUUAC9KWmr0paAClpKWgAooooAKKK KACm/wAVLTT98UCY+iiigYUUUlAC0UUUAFFFJQAjdKWkbpS0ALRRSUALRRRQAUUlLQAUUUlA CLTqavenUAFFJRQAtFJRQAtFFJQAtJ/FS00/eFADqKKSgBaKSloAKKSigBaKKSgAbpQOlI33 aF6UCHUUlLQMKKKKACiiigAopKKAEHU06mr1NOoAKKKKACiiigAooooAKaeop1Nb7woAdRRR QAUUUlAC0UlLQAUUUUAIelA6UHpQOlAC0UUlAC0UUUAFFFJQAtFFJQAg+8adTR940tAkLRSU tAwooooAKKKKACmt2paR+1ADqKSigBaKKSgBaKKSgBaKSigANIvSlNIvSgB1FJS0AFFJRQAt FJRQAtFFJQAn8VOpvO+loAWikpaACiiigAooooAKY/anU1+goExwpaSloGFFFFABRRRQAUUU UAFFFFADR1NOpo6mnUAFFFFABRRRQAUUUUAFNbtTqa3agB1FFFABRRRQAUUUlAC0UUUAIelC /dFB6UL0FAC0UUUAFFFFABRRRQAUUUUANH3qdTR1p1ABRRRQAUUUUAFFFFABTXGQKdTX6UCY tLSUtAwooooAKKKKACiiigBDSJ0NLSL0oEOooooGFFFFABRRRQAVHP8A6h/pUlMkAMbA9MUA ck/3iK2tCb906579KxpgBKwHQGtbQesnrTA2aKKKQBRSUtABRRRQAU1ulOpD0oAB0paQdKWg AooooAKKKKAOb1eLy7wkfxc1Hp0hiu0I78Vf12MDY/fpWTGdrqQe9MR1w5FNTqaSE7oVJ9KV OpoAfRRRSGFFFFABRRRQAUUUUAIeopaQ9RS0AFFFFABRRRQAUUUUAFIelLSHpQADpS0g6UtA BRRRQAUUUUAFFFFABTR1NOpo6mgB1FFFABRRRQAUUUUAFFFFADT1FOpp6inUAFFFFABRRRQA UUUUAFIelLSHpQADpS0g6UtABRRRQAUUUUAFFFFABSDqaWkHU0ALRRRQAUUUUAFFFFADJm2R M3oK5KZjJIzMeSa6XU2K2TkelcwaAL2jxB7oN/dro6xNDGSxrcpsSCiiikMzb3SkuZDIrlWN ZN1p0tshZsbfWuoqC7QPbOCM8U7iOSAqxa2j3TlUwMetQtgMRV/RW23ePUUAWY9D/wCekv5C rsem20Q+5uI7mrlB6UXCxTurVZbQoBjHIrnCNrEHrXXKMriua1KIQ3jAAYPNAF/RJ/laE/UV sVzWmybLtMd+K6SkMWiiigAqnqn/AB5PzirlUtV/48noA5skZrotNcfZkyQOK5w083LiMIGI A96YrHVmaMHBcZ9M1zWoSB7yQjpnFVfMY87jmkznnNIZZtV33Manua6pRhQK5bTiftkfHeup HSgArK1TUTCfKiI3dz6Vo3EoihZycYFcpM5llZzySaAGOzO25iST3pvOatWVo11KFH3e5q7q VlHbwL5ac9zTsK5lYpRShSTjFPliaJgGHOKLAbWiz7ojETytalczpk3k3a88Nwa6UHikMWii igAooooAKSlooAQdKWkFLQAUUUUAFFFFABRRRQAU3+KnU0/eoAdRRRQAUUUUAFFFFABRRRQA jdKWkbpS0AFFFFABRRRQAUUUUAFFFFADVp1IO9LQAUUUUAFFFFABRRRQAU0/eFOpO9AC0UUU AFFFJQAtFFFABRRRQA1jgUo6UjdKUdKBC0UUUDCiiigAooooAKKKKAGjqadTR1NOoAKKKKAC iiigAooooAKQ9RS0h6igBaKKKACiiigAooooAKKKKAEPSgdKD0oHSgBaKKKACiiigAooooAK KKKAGj7xp1NH3jTqACiiigAooooAKKKKACmt0p1NagB1FFFABRRRQAUUUUAFFFFACUL0paRe lAC0UUUAFFFFABRRRQAUUUUAN/ip1N/ip1ABRRRQAUUUUAFFFFABTX6CnU1+goExaWkpaBhR RRQAUUUUAFFFFABRRRQAzdhuaN6+tG0Fsml2j0pi1DevrRvX1pcD0owPSkGom8Ub19aXA9KM D0oDUTePWjevrS4HpRgelAaib19aRnHFOwPSkIHFMNQ3r60b19aXA9KMD0pBqJuHrRvX1pcU YHpQGom4etG4etLgelJtGelAahuHrRuHrS4HpRgUBqIWGOtIGXHWlIGOlAAx0phqG4eoo3D1 pcD0owPSkGom9fWjcPWlwPSjaPSgNRNw9aNw9aXaPSjaPSgNRNw9aNw9aNo9KXaPSgNRm8Bs U7evrTdgLU7aPSnoCuG9c9aNw9aNo9BS7R6Ug1E3D1pdw9aNo9KNo9KA1DcPWjcPWjaPSjaP SgNRNw9aRmGOtO2j0pjqMUwdxwYEdaXcPWkCADpRtHpQGou4etGR60m0elG0elINRdw9aTcP WjaPSjaPSgNRcj1pNw9aNo9KNi56UBqLketNDj1pdo9Kasa5NMHcduHrS7h60mxfSjYvpSDU XI9aMj1pNi+lG0elAai7h60bh60mwelGxfSgNRcj1qOZgImye1P2L6VHOqiFzjtTDU5aTBdv rWtoRAV/Wsdz8x+tbOhqGjfPXNAGvketGR60mxfSjYvpSDUXI9aMj1pNg9KNooDUXI9aMj1p Ni+lGxfSgNRcj1pCeKNo9KQqMUAKGBHWlyPWmhBjmjYvpQGo7I9aM0mwelGwelAai5FGRSbB RsHpQGpma4QYF9c1iINzge9a+uDaqBe9ZEWfMX60wOrgG2FFz0FOUjcabEg8pcjtQqDJoFqS ZFGaTYKNgpD1FzRSbRRtFAC0Um0UbBQAuaM03YKXYKAAkAilyKYUBNLsFMNR2aKQIKNopBqL RSbRRsFAC5opNgo2igBaD0pNopCoxQAoIIpaYIxjmnbBTDUWik2ijaKQC0UmwUbBQGotFJtF G0UALSDqaNopoUbjQA+ik2D3pNg96A1HUUm0Ubfc0DFopNo96Ng96BC0tN2ijaPegAY4IpaY 65xzShPc0w1H0U3Z7mjb7mkA6im7frRt9zQA6im7fc0bfc0AOpD0puz3NKV46mgBQeKKYqcd TS7Pc0w1H0UzZ7ml2+5pAOopuz3NJs9zQA6lpmz3NLt9zQAtJn5qNvuabsy3WmDuSUUzZ7ml 2e5pAOopuz3NJs9zQA+im7fc0bfc0AVdUGbGSuYPWusnh3wsuTyK5WVSjsp6g0wNLRpMSlcc VvVylnKYrhTnAzg106LlQQxINAEhIAyTVeW+gi+84z6VX1USJb7kbjvXOszE5PNIaOshuoZh mOQGoNSvFt4CAQWbgCuZVypyCQfalZ2Y/MxP1oACSSSa1dEiJmL44FZ9tA9xKEUfjXS2tqtv EEUn3piLNIelN2e5o2+5pACHisbXExMjeorXVSc81k62CCnJNMSuZ1udsyFeua6pDlAfauTi P71PrXUoh2Dk9KBktFM2e5o2H1NIB1VtQXfZyAelT7T/AHjTZIt6FSTg0wORYc4FJip72E29 wydagU8jNIZfs9Oe4hLDj0Jpj6Zco4UpnPcVuWSKbZNjYGKsGMkcmq0J1OYUmzmPALj9Ktxa 1MpAZVNQ6nbvDck4+U8g1QzUspGrqd+J0VEPB5NZfPakzzVmytmuZgqjjuaANbQkYQsSMA9K 05I0lQq6hgexqOGARRhVOMVJtP8AeNMRXFjbRkFYwKo63CAqSKPatR1OOtVNSiJs2JOcc0xd Tn1O1gfQ11NpKJrZHHcVyue9b2jkva/ePB6UhmlS0woc/eNG0/3jSAfRTdp9TRtPqaAHUU3a fU0YPrQAopajVT6kUu0/3jTC46lpgU/3jS7T60guOopu0+tJtPrQA6imlT/eo2n+9QA+mn7w owfWo3QlhzTQNktFN2N/eNG0/wB6kFx1FN2n+9RtP96gB9FN2n+9RtPrQAtFN2n+9RtP96gB x6UU1gdvWgKR/FTC46im7T/eo2n+9SC4+im7T60YPrQAtFN2t/epdp/vUBcdRTcH1owfWgBR S1EqtknOKdhv71MLjqKbtP8Aeo2n+9SAdRTQrf3qXB9aAFopMH1owf71AC0HqKTaf71NZTkc 0wuSUUza3rRtb+9SC46lpuG/vUYPrQA6im4b1owfWgBaKbhvWlw396gBT0oHSmsG29aaqvj7 1ML6ktFM2t/eo2t/epBcdRTdrf3qMN60BcfRTMN/eo2t/eoC46im7W/vUuG9aAuKO9FMAbJ5 pcN60wuOopuG9aMN/epBcdRTcN60Yb1oC4+imbW9aMN/eoC46g9RSYb1prBuOaYXJKKZhvWj DetILjqWmYb1oIf1oC4+imYb+9RhvWgLj6KZhvWlAb1oC4poHSmkN60ihsdaYXJKKZhvWjD+ opBcfRTMN6ijDetAXHUU3DetGG9aAuOopuG9aXDetAXAfeNLUZ3b+Kdh/WnYSY6im4b1pcN6 0h3FopuH9RRhvUUBcdRTcN6ijDeooC46g00B/UUjbsUwuSUUwBsdaAHz1pBcdRTcN6ijDY60 BcfSU3DetBD9jQFx9FMw/qKMN60BcdQOlNw3c0i7ux4phcfRTcN60Yf1FILjqKbhvWjDZ60B cdRTcN60Yb1FAXH0U35qMN6igA/ip1RENvp2H9RTC46imnfRhvUUguOopuH9RS4b1oC4tFJh sdaTDetAXHUjdKTDeopHDcc0wbHilpBS0hhRRRQAUUUUAFFFFABRRRQA0feNOpo6mnUAFFFF ABRRRQAUUUUAFIe1LSHtQAtFFFABRRRQAUUUUAFFFFACHpQvSg9KF+6KAFooooAKKKKACiii gAooooAb/FTqaPvU6gAooooAKKKKACiiigAprdKdTW6UAxaWkpaACiiigAooooAKKKKAEoHS ikWgB1FFFABRRRQAlLRSUALVe9bbaufapHlSMZdgB71nahqEL27LG4YnjFAGG3etjQmA3rkZ rFJOK1dCVvNZu2KBG9RRRQMTvS0UUAFFFFABSN0paa3SgBR0paQdKZNMkMZdzgCgCSisCfWZ mfEQCgetRHVrojG4flQB0dFc6ur3I6lT+FSrrUgXDopPrQAzWbgyT+X0C1QgOJVPvTrmYzzN IeM9qjjOHU+9AHXxnMan2pV6mmW5zCp9qcnegQ+iiigYUUUUAFFFFABRRRQA09RTqafvCnUA FFFFABRRRQAUUUUAFIelLSHpQADpS0g6UtABRRRQAUUUUAFFFFABTR1NOpo6mgB1FFFABRRR QAUUUUAFFFFACHtS009RTqACiiigAooooAKKKKACkPSlpD0oAB0paQdKWgAooooAKKKKACii igApB1NLTR1NADqKKKACiiigAooooASsPWbTY/nL0PWt2o5o1mjKMODQgOR6Vt6Pehl8mQ8j 7uazb20e1lIP3exqujsjAg4I6U2I66SNZUKMMg1nyaLAxyGZaNP1NZQI5Th/X1rS60rjsY40 JNxzKcfSpV0SAEZZiK1KKdxWILe1it1xGoHvU9FFIYUh6UtIelACJ0rC1uTdcqo/hFbMkqww s7HAFcxNKZZmcnkmmLoSWS77qNR1zXUDpWJotvukMx6DgVuUMYUUUUgCiiigDn9ci2zq/ZhW YPpXR6vD5lqWHVea5wjBwaYjp9LCizTb3q5WDo94I28mRsKelbo5pDGSxJMhV1BBrNm0SNjm Nyv1rWoouFjCGhyBhmRSK1bS0jtY9qDnuasUU7isFFFFIY1qivMfZZMjPFStUF/II7R2PpQB y56mtvQiPKcZ5zWHnJPFb+iR7bYtjqaYGnRRRSASilooAKKKKAEFLSCloASlpKWgAooooAKK KKAEpp++KdTT98UCY+iiigYUUUUAFFFFABRRRQAjdKWmt0paAFooooAKKKKACiiigAooooAQ d6WkWloAKKKKACiiigAooooAKaetOpp+9QA6iiigAooooAKKKKACiiigBD0oHShulA6UALRR RQAUUUUAFFFFABRRRQA0dTTqQdTS0AFFFFABRRRQAUUUUAFNPUU6mnqKAHUUUUAFFFFABRRR QAUUUUAIelA6UHpQOlAC0UUUAFFFFABRRRQAUUUUANHU06mj7xp1ABRRRQAUUUUAFFFFABTW p1NbtQA6iiigAooooAKKKKACiiigBKF6UUi9KAHUUUUAFFFFABRRRQAUUUUAN/ip1N/ip1AB RRRQAUUUUAFFFFABTX6U6mP0oQmOFLSCloGFFFFABRRRQAUUUUAFFFFADB9406kH3jTqBIKK KKBhRRRQAUUUUAJSNninU1u1AMdRRRQAUUUUAFJS0UAFFFFACN0pF+6KU9KRfuigQ6iiigYl FLRQAlLRRQAlFLRQA0fepaT+KnUAJS0UUAFFFFABRRRQAlNfpT6a/SgTFHSlpKWgYUlLRQAU UUUAJRS0UAJSL0paRelAC0UtFACUjMFGScCmTzJBGXc4Arnb2/luWIyVTsBQBq3erRQnbH87 exrNl1W5kztOwe1UVRmPCkmr9vpU8wyRsX3p2C5SeWSQ5dmJ9zTME1upokYA3SsT7VYXSbVQ BsJ/GiyFc5rHrVi1u5bZsoePStqTSrZuApHvmsy702S2yw+ZPUUWC5rWWox3Iwflf0q7XIAl TkEitjT9TLFYZev96kM1+9FAOeRS0AFJS0UAJSP0p1NbpQDAH5c1z2r3RlnKKTtXitq8n8i2 Zs844rmGJdyT1NAE1nYyXZO3hR1Jq82huPuyg/UVoaZAIbVemTyauU7isc3LpVygJ2hgPSqc kTxnDqQfcV19MkhjlGHQMPcUXQHHkUqnaQfSt260ZHBaFtp9D0rJuLOa3OJEOPWiwXNWw1RC ojl4PY1pRuGyQc1yPQ1ctL+W2cDOU7g0hnTUVDbXMdym5D9anoASilooASilooASilooAYT8 4FOppHzCn0CQlFLRQMKKKKAEopaKACmt9006kboaAEX7op1IvQUtACUUtFACUtFFABRRRQAU 0dTTqaOpoAdSUtFACUtFFABRRRQAUlLRQAxjyKdSHqKdQIKKKKBhRRRQAUUUUAJQTxS0h6UA A6ClpB0paACiiigAooooASloooAKaPvGnU0feNADqKKKACkpaKAEpaKKACiiigCteW6XEWxh z2PpXOXVq9tIVb8D611TdqZNBHOu2RQRTuI5EZByCc1p2WrvFhJvmX170+80hkJeDlfSsplK kgjFFgudXb3UVwMxuD7VNmuPileJtyMVPtWjBrM6HEgDj9aQzfpC6g4JFZ6axbsmWyremKxr u7knmLlsDtigDqgwPQ0yWRY4yzkACuatL+W2YtktkdzTbm8muTl249BQBLf3zXDFF4jH61Xt 4XnkCIMk0QwvMwVFJJrobCwS1QEjMh70xE1rAtvCEX8ampaKQwpKWigApKWigBrKGUg8g1zO o2jW85x9w8g109Qz26TgrIMimhM5MHacjrWrZ6u0ahZhuX1HWm3mkSRktCCyfrWayMrYIwfe iwXOrhu4ZwNjgn0qbNcerMpyDg+1W7bUp4Orbx6GkM6WisuLWomA8xCp9qtJqVq//LUD60AW qKg+2W//AD2X86jl1K1jBPmAn0FAFlzgCsnWbsFRChye9Q3esPJ8sK7R6nrWaWZySTyfWgQI pZgB1NdTZReRbInfFZel6cxZZpBheoFbeKYBmiilpDEpaKKACkpaSgBF6U6mr0p1ABRSUtAB RRRQAUUUUAJTT98U+mn71AmOooooGFFFFABRRRQAUUUUANbpSikbpS0ALRRRQAUUUUAFFFFA BSUtFADVPWnU1e9OoAKKKKAEpaSloAKKKKACmk/MKdTTjdQA6kpaKACiiigAooooAKKKKAGt 92lXpSN92lXpQLqLRRRQMKKKKACiiigBKWikoARepp1NXqadQJBRRRQMKKKKACiiigAprdRT qaRyKAHUUUUAFFFFABRRRQAUUUUAIelA6UHpQBxQAtFFFABRSUtABRRRQAUUUUANH3jTqYPv mn0CQUUUUDCiiigAopKKACkalpGFAC0tJRQAtFJS0AFJS0lAC0UUUAIaRelKaRRxQA6ikooA WkpaTFAC0UlFABS0lFACfxU6m4+eloAKWkpaACiiigAooooAKY/QU+mv2oExRS0gpaBhRRRQ AUUUUAFFFFABRRRQA0feNOpo+8adQAUUUUAFFFFABRRRQAU1u1OprdqAHUUUUAFFFFABRRRQ AUUUUAIelC/dFB6Ui/dFADqKKKACiiigAooooAKKKKAGj71OpB96loASloooAKKKKACiiigA pr9KdTW6UCYtLSUtAwooooAKKKKACiiigBKRehpaRelADqKKa5wh+lAGFrNzvm8pW4XqKqWV o11NtzwOtRXDFp3PvW1ocYFuX7k0wLtvaQ264RRn1qxSUtIAooooAZ/HTiAwwRkUn8dOoEZG oaYGzJAAD3WsZgUbBBBrsKzNTsPOXzIx846+9O4FfTdSKkRTHjsTW0CCMjpXIMCrYPBFbOma jkCKY89AaQzXopKWgApr/dp1Nf7tAmZ2suBZhc9aw4F3yqPU1p642TGtULBSbqML1zTA6iMb Y1HoKfSDoKWkMKKKKACmuiyKVcAg9jTqKAMe90gHL2/B/u1jujIxVhgiuvqhd2CXIYgYcdDT EYUE728gZDjHaug0+9F2hyMMOornZY3hkKOMEVY064EFyGY4U9aQzp6KZG6yKGU5Bp9ABRRR QAUUUUANP3hTqaeop1AgooooGFFFFABRRRQAUh6UtIelAAOlLSDpS0AFFFFABRRRQAUUUUAF NHU06mjqaAHUUUUAFFFFABRRRQAUUUUANPUU6mt1FOoAKKKKACiiigAooooAKQ9KWkPSgAHS lpB0paACiiigAooooAKKKKACmjqadTR1NADqKKKACiiigAooooAKKKKAEPalpD2paAEqC4s4 bgYdefUVYooAwrjRXXmFg3sapTWNxEMvGQPWuqpCARgjIp3FY40qw6g00iutuoozA2UXgelc s2NxoAIonkYIgJNalro7sN0x2j0FN0NMzsx7Ct49KNgILW3jgTCKB71YpqdKdSYIKKKKBhRR RQAUUUUAFN/ip1J/FQAVDNawzrh0B96nooAypdFhbJR2X9apT6RPH9zDj2roqKdxWOTa1nXr E3HtURRh1BrsMUxoY2+8in8KNA1OR5zS7GPYmuqFrAvSJPyqQRIOiKPwo0DU5mCxmmxhDj1P ArVtNISIhpsO3p2rSIwOKWi4WAAAYHApaKKQwooooAKKKKACiiigBB0paRelLQAUUUUAFFFF ABRRRQAU3+KnU3+KgB1FFFABRRRQAUUUUAFFFFACN0paRulFAC0UUUAFFFFABRRRQAUUUUAI O9LSCloAKKKKACiiigAooooAKaeop1NP3hQA6iiigAooooAKKKKACiiigBG6GgdKG6UDpQAt FFFABRRRQAUUUUAFFFFADR1NOpB3paACiiigAooooAKKKKACmnqKdTT1FADqKKKACiiigAoo ooAKKKKAEPSgdKD0oHSgBaKKKACiiigAooooAKKKKAGj7xp1NH3jTqBIKKKKBhRRRQAUUUUA JQ1FI3agB1FFFABRRRQAUUUUAFFFFACUDpRSL0oAdRRRQAUUUUAFFFFABRRRQA3+KnU3+KnU AFFFFABRRRQAUUUUAFMfoKfTX6UITFFLSDpS0DCiiigAooooAKKKKACiiigBo6mnU0H5iKdQ AUUUUAFFFFABRRRQAU1u1Opp7UAOooooAKKKKACiiigAooooAQ9KF6Cg9KB0FAC0UUUAFFJS 0AFFFFABRRRQAn8VLTR96nUAFFJS0AFFFFABRRRQAU1ulOprdKAYopaQUtABRRRQAUUUUAFF FJQAUi9KWkXpQA6mSDMbD2p1ULrVIYWMZBZvagDAmG2VgfWt7Riv2QbeueawJnEkrMBgE9K0 dDm2zNFj73NAG9RRRkDrQAtFRG4iDbd4z9akBB6UAJ/FTqbkbqCwAyTQA6kqB7yBPvSKPxqJ dTtmk2B+aAKWr2WD5yDjuKyFJBBBwRXWuiyoVPIIrmr62+zTlR93tTEbem3YuIgrH5x1q9XN aXP5N0oPAbiukByKQxaa/wB2nU1/u0CZga1/rl57VXsJRFdKzdKm1gAXPB5xzWdn1psEbU+t bWxEgI9TS22ss0gEqgKfSsQZJwM1fstPmmdXKkLnqaVh3OkUhlBHQ0tIo2qB6UtABRRRQAUx epokdY0LMcAVnDV4hPt2kqT96gB+qWQniLov7wVzxBU4PBFdgCGUEcg1jaxZqn75BjJ5ApiJ dGulaPymOCOma1q5CNzHIGViCK6i0nFxArikMnooooAKKKKAGnqKdTT1FOoAKKKKACiiigAo oooAKQ9KWkPSgAHSlpB0paACiiigAooooAKKKKACmjqadTV6mgB1FFFABRRRQAUUUUAFFFFA DT1FOpp6inUAFFFFABRRRQAUUUUAFIelLSHpQADpS0g6UtABRRRQAUUUUAFFFFABSDqaWkHU 0ALRRRQAUUUUAFFFFABRRRQA09qdTT2p1ABRRRQAUUUUAQ3fFtJ9K5Q9c11V7/x6SfSuVNMD X0Ef6ytk9KytBH7lz71qnpSARelOpq9KdQCCiiigAooooAKKKKACk/ipaT+KgBaKKKACiiig AooooAKKKKAENFBpaACiiigAooooAKKKKACiiigBB0paQdKWgAooooAKKKKACiiigApp+9Tq afvCgB1FFFABRRRQAUUUUAFFFFACN0paRulLQAUUUUAFFFFABRRRQAUUUUANXvTqQUtABRRR QAlLSUtABRRRQAUw/fFPphHzCgTH0UUUDCiiigAooooAKKKKAEPSgdKD0oHSgBaKKKACiiig AooooAKKSloAaOpp1NHU06gAooooAKKKKACiiigApp6inUh6igBaKKKACiiigAooooAKKKKA EPSgdKD0oHSgBaKKKACiiigAooooAKKKKAGj75p1NH3jTqBIKKKKBhRRRQAUUUUAJSN2paRq AHUUUUAFFFFABRRRQAUUUUAJSL0p1IvSgBaKKKACiiigAooooAKKKKAG/wAVOpv8VOoAKKKK ACiiigAooooAKa/QU6mv0oExRS0gpaBhRRRQAUUUUAFFFFABRRRQBEULPkHFLsP9404feNOp 3JsM2H+8aNh/vU6igdhu0/3qNp9adRSCw3af71G0/wB6nUUBYbtPrSMp45zT6Rj0pg0JtP8A eNG0/wB406ikFhu0/wB40bT/AHjT6KAsM2n+8aNp/vU6igLDdp/vUu0+tOooCwwg460iqcdc U89KRegphYTa396ja3rTqKQWG7T/AHqNrf3qdS0BYZtb+9RtPrTqKAsN2t/eowfWnUUBYjIY t15p21sdaXPzUtMSQza2fvUuG9aXHqaWgdhuG/vUYb+9TqWkFhmG/vUYb1p1FAWG4b+9SOG2 9afSN0pg0NAfHWlw/wDep1LSCwzDf3qMN606igLDcN60Yb1p1FAWG4b1ow3rT6SgLDcN60xQ +Tg8VLSL0p3CxDcM0cLMW7Vy0r7pWb1NdHqzEWjYrmTnNJgkOVS3QZxViyd47pCg5zirOjFP OYPgk9M1trbxK25Y1B9cU9AD59uSaxtRvpPMKRucDrit1hkYrntTtnSUsEwpPajcNigJW3Zy c1Kt7OgwJHH41CI3PQH8qkW0nYAiJsfSlZjuSG+uCcmZvzpjXc7rtaViPTNSDTrk/wDLJqeu lXR5KY/GnYVymWz1zUtupeZdvXPar8OiyM371go9q1LawhtwNq5PqaLASRCTYMnnFUdXhLQb zyVrUqK6QPbupGRii4WOUVsOCO1dPayPLbqwI5Fcu3Dke9dDoz7rUD0NAF3D+opH3bTUlI/3 aAaOb1U/6T+FUeprR1qPbOG7EVnKCWGKHuC2N3TrALGsjKNx55rTVWAwMVFY7vsyb+uKsUNh Yb8/tR89OJA61WlvreI4aQZpBYn+f2o+f2qtHqVs5wJAPrVoMCMgjFFwsV7tHktnXjpXMsdr fSuquHAhfJ7Vyjn5z9aYHRabM8tsvTjirE8ZliZGAINUdDGLdjnqa1KLhY5OZDFIyMMEGtLR Zj80Y69aNchO5ZB06GqFpJ5VyjZxzzQB0/z+1Hz+1KpDKCO9LSCw356AXp1FAWI33ZFOG+lP 3hS07hYb89Hze1OopBYb83tR83tTqKAsNy/pS/NS0UBYb83tQd2KfSN0oCxGpbHFOy+elOHS lphYZ81BLY6U6ikFhoLelGW9KdRQFhuW9BRlvQU6igLDct6UmW3cCn0g6mmFhMtjpRlvSnUU gsNy3pQC3pT6KAsMy3pQC3cU+igLDMt6UuW9KdRQBE5bjilDN/dpzdRS07hYblvSly3pTqSk AmW9KTLelOooCw3LelLlvSnUUBYYGb+7S5OOlLQelAWI1ZvSnbm/u04dKKYWG7j6UuT6U6ik Azc3pQWb0p1FAWG7m/u0bmx92n0UBYZlv7tN3MG6VJSDqaYNCbm/u0bm/u0+ikFhm5v7tG5v 7tPooCwzcf7tLuPpS0tADcn0o3H0p1FAEbscdKUM2Pu0p7UtMLDdxx92jcf7tOopAJk+lJuP pT6KAKl85FrJ8vauZNdXdf8AHtJ9K5QjrTA2NDZgr45HpWtuOOlZOgkBZBnmtg9KAI0c88Zp 28/3TSoOKdQxJMZuP92jcfSn0UhjNx9KAx9KfRQAzcc/dNBc/wB006igLDdx/ummlyG6VLTf 4qYNMTef7po3H+7TqKAsxu4/3TRvP900+qmpTNBasy8GgCV7hE+8QPqaEuEk+6Qfoa5R5Hds sxJPqas6ZI63aBT160gOl3n+6aNx/umnDpS0ARsxxwKA5I6U5hkUtMLMbuPoaAx9DT6KQDC5 HY0bj/dNOpaAG7j6GjcfQ06igBu72NG72NOpKAGK554pd5/umlWlphZjQ5PY0u72NOopAN3e xpN3safRQAzcfQ0u4+hp1FADN3saazkMMCpaafvUwaYm8/3TRu/2TTqWkGozf7Gjf7Gn0UAN 3expN3safRQAzf7Gjf7Gn0lADGfA6GlD8dDSt0paYaibvY0bvY06ikA3d7Gjd7GnUUAML+xo 3+xp1LQAzf7Gl3cdDTqKAIw/tS7valAFOphqM3H0NG8+hp9FIBm8/wB00bvY0+igBm8/3TRv P900+igLMZu9jSMxBHFPpD1phYTd7Gjf7Gn0UgGb/Y0bvY0+igBm/wBjRv8AY0+igBm/2NG/ 2NOooDUYzYHQ0iyccg1IelA6Uws7jQ/saN/sadRSDUbv9jRv9jTqKA1G7/Y0b/Y06igNRu/n oaXcPQ0tLQBGH5PFLvHvSgcmlphqN3j0NLu9jS0UgE3Ub/Y06koAbvHoaN49DTqKA1G7x6Gk Z8YqSmsBkUwdxN49DRvHoadRSDUbvGOho8wehp1FAajd49DRvHoadRQGo3ePejePenUUBqIW GKRXGKcelIoAFMNRN496N4p1FINRu8e9G8e9OooDUTeKN496WigNRu8e9LvHvS0UBqR+Zh+l O8we9GBuJp1PQSuN3il3ilopD1G7x70u8YpaKA1E3ijeKWigNRvmD3pHcAZp9IwB60w1EEgo 3j3p2KKA1E3j3o3j3paKQajd496PMHvTqMUBqN3il3ilooAaXFIrjvmn0iimGom8e9LvFLRS DUTeKTeKdRigNRN4o3ilxRQGom8UbhS0UAML4al3ilwN1LimGo3eKXePelxRSDUTeKN4paKA 1E3ijeKWigNRN4prsMYp9I/SgGKOlLSCloGFFFFABRRRQAUUUUAFFFFADR9406mj7xp1AkJS 0UUDEpaKKAEopaKAExSMOlOprdRQA6iiigAooooAKKKKACiiigBG6UijilPShegoAWiiigBK KWigBMUUtFACUUtFADMfPTqQfeNOoEJRS0UDEopaKAEpaKKAEprjin01ulAmKBxRRS0DEoxS 0UAJRilooATFGOaWigBMUijilpF6UCGzRLLGVYZBFcrcxeVOyeh4rrqxNatSGEyLx3pgZltJ 5M6vngHmuqhdZYw6nINchWtpF8I/3Mh4PQ0hm5ikZAw5GaXIIpaAIxEg/hH5U7aKdRRcBmBv p2KT+OnUCExRS0UDExTZMBCT0xTqq6jcLDbtyNxHAoA5qfBncjgZre0VT9kz71z+ctz3rqNO j8u0Qe1MRZxTXHFPpr/dpAzE1z/lnWZDgSpk4Ga1tcX5EbH41jpgOuTxmmB10QHlrj0p+Kjt yGgQqcjFSMcKTSGY2r3pQ+ShIPc1jFiTyamvZN91I3bNNt4DPKEBwTQBFmpVupVAAkarEulX MYJChh7VTZWXhgQaLBcmN3K6lGYkH3qIDJApFRiRhTWvp2mlmEkvQdqaQrmhptv5Nsuep5q3 igDAwKWkMqajF5lo47gZrmhww5rq7kZgce1cqR8xA9aYHUWp326EelTVXsM/ZI8+lWaQCUUt FADCPmFOpD94U6gAooooASilooASiiloASkYcU6kPSgAHSigdKWgBKKWigBKWiigBKKWigBK ao+Y0+mjqaAHUlLRQAlFLRQAlFLRQAlFLRQA1uopaQ9RTqAEpaKKACiiigAooooAKQ9KWkPS gAHSlpB0paACiiigAooooASloooASkHU06mjqaAFopaKACkpaKACkpaKAEopaKAGtnIpaD2p aAEopaKAEopaKAI5wWhYD0rkpBh2B7GuukGY2HtXJzcSt9aYGjoTHznHtW6elc/omBdnPXFd AelIBqZxzTqROlOoEhKKWigYlFLRQAUlLRQAlJzup1J/FQAtFFFACVn6ycWR9zWjVDWObJuM 0Ac1itDRog91n+7VDqa0dG3fasLwMc0AdCKKWigBrUtI1LQAUUtFACUtFFABSUtFABSUtFAD V6U6mr0p1ACUtFFABRRRQAUUUUAFNP3hTqb/ABUCFpaKKBhRRRQAUUUUAFJS0UANbpSikbpS 0ALRRRQAUlLRQAlLRRQAUlLRQA1c806mr3p1AkFFFFAwooooAKKKKAEppJ3in0wj5xQJjqKW igYlLRRQAUUUUAFFFFADW+6aF6ClbpQOlAhaKKKBiUUtFACUUtFACUUtFADV6mnU0dTTqACi iigAooooASilooASkOcinU09RQAtLRRQAlFLRQAlLRRQAUUUUAIelC9KD0oHSgBaSlooAKSl ooASloooAKSlooAYM7jTqQfeNOoEgooooGFFFFABRRRQAlIx6U6mtQAtLRRQAUUUUAFJS0UA JS0UUAIaRelLSL0oAdRRRQAUlLRQAUlLRQAUUUUAN/jp1N/ip1ACUUtFABSUtFACUUtFACU1 +gp9NfpQhMUUtIKWgYUUUUAFFFFABRRRQAUUUUANH3jTqaPvGnUAFFFFABRRRQAUUUUAFNbq KdTT1FADqKKKACiiigAooooAKKKKAEPShegoPSgdKAFooooAKKKKACiiigAooooAaPvGnU0f ep1ABRRRQAUUUUAFFFFABTX6U6mv0oELS0lLQMKKKKACiiigAooooASkXpS0i9KAHU10DqVY ZBp1FAHM6hYvbSFgMoehFUhkHNdhLEkqFXAINc9qGnvbsXX5kP6U9xFnTtT2qI5ycdjWxHIs i7kYEe1chmp4LyaA/I+B6UhnV0VkW+tIQBKuD6irsV/by/dkGfegCx/HTqjDqWyGBFO3r/eF ADqKhkuYYxlpFH41nXGtKMiFdx9TQBpTTJCpZ2wBXN3121zMW/hHQUye5knbMjE+1La2kl02 EHHc0wJNPtGuZh2A5NdKoCqAOgqGztUtYgq9e5qxSYBTX6U6mt0oAo6vHusye4rnD1rrpk8y Fl9RXKSpskZT2OKYjpNMkD2iYPQYq0wypFY2iTgExE+4rbpDOUv4miuXU+uajgZklVl6g10d 7YJdrydrDvVe20dYpN0jbsdKYjQhJaJSepFMltYZfvxgn6VMBgYFLSuMiS3iQAKi8e1LGMZ+ tPpkZ6/WmLqSUUUUhle+bbayH2rlxy31rX1q5ORCvA6ms6yhM9wi+9NAdJaDFtH9KmpqjaoH pTqQBRRRQA0/eFOpp+8KdQIKKKKBhRRRQAUUUUAFIelLSN0oAB0paQdKWgAooooAKKKKACii igApo6mnUg70ALRRRQAUUUUAFFFFABRRRQA1uop1NbqKdQAUUUUAFFFFABRRRQAUh6UtIelA AOlLSDpS0AFFFFABRRRQAUUUUAFNHU06mjqaAHUUUUAFFFFABRRRQAUUUUANbtTqa3anUAFF FFABRRRQAjfdNcncjFw4HQE11h6Vyt4Nt1IPemBZ0Uf6Z+FdCelc5o523o68iujPSkAifdp1 NXpTqAQUUUUAFFFFABRRRQAU3+KnU3+KgB1FFFABVa/XdaSD2qzUVyAYHyMjFAHJYwa09DbF wwx1HWs1x8xxV/RCRd4x1FAHRUUUUAIaWmtTqACiiigAooooAKKKKACkpaSgBF6U6kHSloAK KKKACiiigAooooAKb/FTqb/FQA6iiigAooooAKKKKACiiigBrdKdTW6U6gAooooAKKKKACii igAooooAavenU1adQAUUUUAFFFFABRRRQAU0/eFOpD1oAWiiigAooooAKKKKACiiigBG6UDp Q3SgdKAFooooAKKKKACiiigAooooAaOpp1NXqadQAUUUUAFFFFABRRRQAU09RTqaeooAdRRR QAUUUUAFFFFABRRRQAh6UDpQelA6UALRRRQAUUUUAFFFFABRRRQA0feNOpo+8adQAUUUUAFF FFABRRRQAU1u1OprdqAHUUUUAFFFFABRRRQAUUUUAJQvSihelAC0UUUAFFFFABRRRQAUUUUA N/ip1N/ip1ABRRRQAUUUUAFFFFABTX7U6mv0FAmLS0gpaBhRRRQAUUUUAFFFFABRRRQA0feN Opo+8adQAUUUUAFFFFABRRRQAU1u1Opp6igB1FFFABRRRQAUUUlAC0UUUAIelC/dFB6UL0FA C0UUUAFFFFABRRRQAUUUUANH3jTqaPvU6gAooooAKKKKACiiigApj9KfTX6UCYo6UtIKWgYU UUUAFFFFABRRRQAlIvSlpF6UAOooooAKayhgQwBB9adRQBkXmkK5LwHB/u1kzWs0JxJGRXWU jKrDDAH607iOP6CkGRXTy6ZbS5+TaT6VVk0RCfkkIHoaNAMUSuo4Yj8aTzX67m/OtNtFcceY p/Cs2WPypGQ8kUWBMaXJ6k0BSenNaNhpy3UYdnIHpWvbWMFuPkXJ9TQBj2WmSTkNINqVuW9v HbxhI1AqUDFLRcAooopDCmt0p1NbpQAo6Vzurw+VdFuzc10Q6VT1O1+0W5wPmXkU0Bz1tIYZ 1YEjmuricSRqwOQRXIEFSR0Na2k35QiGU8HoaQG5RSDmloAKKSmiVC2AwzQA+mJ1P1p1Mj6m mJ7klQXU628LOSB6UtxcxW6FnYD2rnr69e7fr8g6CkMhnlaeUux5Na+i221DM3U9Koabam4n BK5Qda6NVCKABgCmIdRRRSGFFFFADT94U6mn71OoAKKKKACiiigAopKWgApD0paRulAAOlLS DpS0AFFFFABRRRQAUUUUAFNHU06mjqaAHUUUUAFFFFABRRRQAUUUUANbqKdTW6inUAFFFFAB RRRQAUUUUAFIelLSHpQADpS0g6UtABRRRQAUUUUAFFFFABTR1NOpo6mgB1FFFABRRRQAUUUU AFFFFADT2p1NPanUAFFFFABRRRQAh6Vy18ALuT611NcxqIIvJPrTAk0g/wCmr9K6M9K5vSTi 9SukPSkAidKdTV6U6gEFFFFABRRRQAUUUUAFN/ip1N/ioAdRRRQAUyY4ib6U+o5/9S/0oA5K Q5dvrV7Rji8HXkVRfhz9a0NE/wCPo89qYHQ0UUUgENLSNS0AFFFFABRRRQAUUUUAFJS0UANW nUi0tABRRRQAUUUUAFFFFABTT96nU3+KgB1FFFABRRRQAUUUUAFFFFACN0paRulFAC0UUUAF FFFABRRRQAUUUUAItLSCloAKKKKACiiigAooooAKafvU6mn71ADqKKKACiiigAooooAKKKKA EbpQOlDdKB0oAWiiigAooooAKKKKAEpaKKAEHelpB3paACiiigAooooAKKKKACmnqKdTT1FA DqKKKACiiigAooooAKKKKAEPSgdKD0oHSgBaKKKACiiigAooooAKKKKAGj7xp1NH3jTqACii igAooooAKKKKACmtTqa3agB1FFFABRRRQAUUUUAFFFFACUL0ooXpQAtFFFABRRRQAUUUUAFF FFADf4qdTf4qdQAUUUUAFFFFABRRRQAUx+1Ppj9BQJjhS0gpaBhRRRQAUUUUAFFFFABRRRQA 0dTS1GzFX4GaXe392nYm5JRUe9v7tG5v7tKw7okoqPc392l3N/dphcfRTNzf3aTc392kFySm nqKTc392mszD+GnYLklFNDN/do3N/dpWC46im7j/AHaNx/umgLjqKbuP92k3N/dphcfRTdx/ u0bj/dpBccelC9BTSxx0pFc45U0wuPopu8/3TSbz/dNKwXH0U3ef7ppN5/umiwXH0U3ef7po 3n+6adguOopm8/3TS7j/AHTQF0L3paiLkN0p3mH+6aLCuiSio95/uml3n+6aVh3Q+imbz/dN G8/3TRYLofRTPM/2TRv/ANk0WC6H000m/wD2TTXcgdDTsDaJaKiEhI+6aXzD/dNFguiSio/M /wBk0u8/3TSsF0PoqPzP9k0u/wD2TRYLofRUZkx/CaPM9jRYLokpB0pu/wBjTVkPPBp2C6Ja KZv9jR5nsaVguh9FM8z2NAk9jRYLofRUfmexo8z2NOwXRJRUfmD0NL5g9DSsF0DVy95/x8yf WukeXB6VzV4266cg96YJpmnocvDRn61s1y+mzGK6U54PBrpBKCOhosF7ElFR+YPQ0eYPQ0WC 6JKKjMgHY0eYPQ0rBdElNbpTfMHoaGkGO9OwXQ8dKDyKjEoxyDS+avvRZhdGDq9mYpvMX7jf pWcCVbIPIrqrgJPEyMpINc5c2skDncOOxp2EmjTsdWGBHP1/vVpC6hZSVkU4965PB9aAxA61 JRsX+q9UgPPrWWJ5A+8Od1Q/WgUAbttqyLB+9OW9qgl1eQ7hEoUHuayxnoKmitppThENNK4m xJJJJWLOxJNSWlpJcyAKOO5q9baUAd05/AVrRLHCoVF2j2p2sK9wt4FgiCIMVLTfMX3o8xfe lqO6HUU3zB70eYPeiwXQ+imeYPQ0eYPeiwXQp6ilqNpBkEZpRKPeiwrokopnmD3o8we9Fh3Q +imCQe9HmD3pWC6HUU3zFo8wU7BdDqD0pvmLQXGKAuhw6UUwSjHPFKJFNFguh1FN8xfWjzFo C6HUU3etLvFILoWik3rSb19aAuh9NHU0m9fWkDjcaLBdD6KbvX1o8xfWgLodRTd6+tHmL60B dDqKbvX1o3r60BdDqKbvX1pd6+tAXQHqKWmO4GKUSKe9OwXQ6im+YvrRvX1pBdDqKbvX1o3r QF0Oopu9fWjevrQF0PpD0pN6+tIXXHWiwXQ4dKKYsikdadvX1phdDqKbvX1o3r60guOopu9f WjevrQFxaKbvX1pd6+tAXQ6kHU0m9fWm+YA1AXRJRTd6+tG9fWgLjqKbvX1o3r60BcdRTd6+ oo3r6igLjqKbvX1o3r60BcD2p1MZwMc0u9fWgLodRTd6+tG9fWgLjqKbuX1FG9fWgLi1zOpg i9fNdLvX1rndXGLwkc5FMBulf8fqV0p6VzGmvsvIya6bcCOtAAvSnVGrr0zTt6+opAmh1FN3 r60bh60BcdRTdy+oo3D1oC46im7l9RRuHqKAuOpv8VG4etJvXd1oC4+im719RRuHrQFx1Rz/ AOpf6U7cPWmyuvltkjpQFzkn++frWhon/H2ee1UH/wBY2PWr2ittujkjpTA6Kim7h60bh60h imlpjOMZzSh19RQK46ik3D1pNw9aBjqKbuHrRuHrQK46im7h60bh60DHUlG4etJuHrQAo6Ut MVwR1pdw9aBXHUU3cPWl3D1oGLRSbh60ZHrQAtFJuHrRketAC03vS5HrTS6g9aBXH0U3cPWl 3D1oHcWim7h60u4etAC0UmR60ZHrQAtFJuHrRketACN0p1NYgCgMPWgQ6ikyPWjI9aBi0UmR 60ZHrQAtFJketG4etAC0UmRRketAAKWmKw55p2R60ALRSZHrRketAC0UmR60ZHrQAtFJketG R60ALTT1FLkU1mAIzQIfRSbh60ZHrQMWikyPWjcPWgBaKTI9aMj1oAWikzRketAA3SgdKRiA vWhWBHWgQ6ikyPWjI9aBi0UmR60ZoAWikyKMigBaKTI9aMigBB3p1NVhkjNLketAhaKTIoyP WgYtFJketGR60ALRSZFGRQAtNPUUuaRiARQA6ikyKMigBaKSjIoAWikyKMigBaKTIoyPWgAP SgdKCRikUjHWgQ6ikyKM0DFopKM0ALRSUZoAWikozQAg+8adTARuNOzQJC0UlGaBi0UlGaAF opKKAFprdqXNIxFADqKTIooAWikooAWikyKMigBaKTNGaAChelBpFIIoAdRSUUALRSUUALRS UUALRSZooAT+KnU3I3UuaAFopKM0ALRSZooAWikooAWmv0FLTXPFAmOFLSCloGFFFFABRRRQ AUUUUAFFFFADQPmJp1NH3jTqACiiigAooooAKKKKACmt2p1NPagB1FFFABRRRQAUUUUAFFFF ACHpQvQUHpQv3RQAtFFFABRRRQAUUUUAFFFFADcfNTqaPvGnUAJS0UUAFFFFABRRRQAU1xkU 6mtQDFAwKKWigAooooAKKKKACiiigBKRQKdSL0oAKWiigAooooASilooAKSlooAilA6n0rlb pg07lema6txnr0xXK3YAuXAGBmmJCWpYTJt654rrI87Bu64rm9JjL3i98V0wpDCjFLRQAmBR S0UAJSMOKdSN0oAQAAdKXFA6UtACYFMkhjlXa6gipKKAMufRonbMbFPaq50NgOJh+VbdFO4r HI3NuYJSjMCaiArS1mMLc5A61nLwR3pDN/TdPgEKyMNzHnmtCNFXOAKisdv2VNowMVOvU07i sLgUYpaKQxMCjApaKAEwKMClooATFGBS0UANIBIpcCkPWnUCEwKMClooGJijApaKAEwPSjAp aKAEwPSgjilpD0oAaqgCnYHpQOlLQKwmB6UYHpS0UDEwPSjApaKAEwPSjA9KWigBMCkAGTxT qaOpoELgelG0elLRQMTA9KMD0paKAEwPSjaPSlooATA9KMD0paKAI3UEinBR6UHqKdTFYbtH pS7R6UtFIBu0elLtHpS0UAN2j0o2j0p1FADdq+lBUY6U6kPSgLDVQY6UuxfSlHSlouFkN2j0 o2j0p1FAWG7R6CjYvpTqKAsN2j0o2j0p1FAWG7R6UmwFqdQOtAWE2L6UbV9KdRQFhu0elG0e lOooCw3YvpRsX0FOooCw3YPSjYvpTqKAsMZAccUCNfSlPalphZCbF9KNi+lOopBYbsX0o2L6 U6igLDNi+lYGtJtuhj0roaw9cXE6H1FMLFCzx9qjz0zXUhRiuUgOJ0PvXWLyg+lADQgPXmnb F9KF6U6i4WQ3YvpRsX0p1FILDdi+lGxfSlooCyG7F9KNi+lOooCyE2L6U3yxu6VJTf4qdwsh PLX0pdi+lLRSCyE2L6U141KHjtT6RvummFkclMMSsPerejlTd4buKq3K4uHB9TU2m/8AH6mK AOl2L6UuxfSlopBZDWQEdKBGoHSnGlp3CyGbF9KPLX0p1FILIbsX0o8tfSnUUBZDdi+lLsXH SlooCyE2L6UmxfSnUUBZDBGPSl8tfSnCincLIb5a+lLsX0paKQWQmxfSjYvpS0UBZDdi+lGx fSnUUBZCbF9KaYwSOKkpvencLITy19KPLX0p9FILIZsX0o8tfSnUUBZDdi+lLsX0paKAshux fSjYvpTqKAshpQYo8tcdKcelFO4WQ3YvpRsX0p1FILIbsX0o8tfSnUUBZDTGvpR5a+lOoouF kN2LRsWnUUBZEYjBJp3lrThS07hZDPLX0o8tfSnUUgshvlr6UeWvpTqKAshvlr6UbF9KdRQF kN2CkMYJqSk707hZDfLWgxqadRRcLIb5a+lHlr6U+ilcLIZ5a+lHlr6U6igLITYKTy1p1FAW QxoxigRACnnpQOlO7CyG+WPejy1p1FFwshvlr6UeWtOooCyG+WtBQU6ikFkN8taPLWnUUXCy IxECSTTvLFKOppadwshvlijy1p9FK4WQzy1o8tadRTuFkN8tfejy1p9FK4WQzy196RowcVJT T1FO4WQ3yl96PLX3p9FFwshvlrjHNHlr70+ilcLIZ5Y96PLFPoouFkM8se9HlrT6KLhZEZjG KRYgBUh6UDpTuwshnlj1NHlj1NSUUrhZDPLHqaTyx6mpKKLhZEflD1NHlj1NSUUXCyI/LHqa Xyx6mn0UXCyIvKBbqaXyh6mnfxU6ncVkR+WPU0eWPU1JRSuOyGeWPU0eWPU0+ii4WQzyx6mj yx6mn0UXCyGeWPU01ox6mpaa3ancLIaIgO5o8sepqSii7CyGeWPejyx6mn0UrhZDPLHvSGIH uakop3CyIxGPel8se9PopXCyGeWPU01Yh1yakpF6U7sLITyx6mjyx6mn0UrhZDPLHqaPLHqa fRRcLIZsHqaPLHvT6KLhZDPLHvRsHqafRRcLIiMYLdTThGPel/ip1O4WQwoD60nlj1NSUUrh ZDPLHvR5Y96fRRcLIZsHvR5Y9TT6KLhZDPLHqaayDg81LTH6CncTSHDpS0gpaRQUUUUAFFFF ABRRRQAUUUUANH3jTqaPvGnUAFFFFABRRRQAUUUUAFNbtTqa3agB1FFFABRRRQAUUUUAFFFF ACHpQvQUHpQvQUALRRRQAUUUUAFFFFABRRRQAg+9S00feNOoAKKKKACiiigAooooAKa3SnU1 ulAMWlpKWgAooooAKKKKACiiigApq9KdSL0oAWiiigAooooAKKKKACiiigCKTjP0rlrht87n 1NdTLyDj0rlZf9a+fWmI0tCjzI7ntxW7WNoLjDrnmtmkMKKSloAKKKKACkbpS01ulACjpS0g 6UtABRRRQAUUUUAYuuofkbtWPzXTanGslo2e3IrmiQB0piOm05y9ohOOnarC9TWbokm6Fl9D WknegB9FFFIYUUUUAFFFFABRRRQA09adTT1FOoAKKKKACiiigBKWiigApD0paQ9KAAdKWkHS loAKKKKACiiigAooooAKaOpp1NHU0AOooooAKKKKACiiigAooooAaeop1NbqKdQAUUUUAFFF FABRRRQAUh6UtIelAAOlLSDpS0AFFFFABRRRQAUUUUAFIOppaaOpoAdRRRQAUUUUAFFFFABR RRQA09qdTW7U6gAooooAKKKKACsbXh/qzWzWRr3+rj+tAGNGcOp9662I5iU+1cipww+tdZAc 26H2pgPXpTqavSnUgCiiigAooooAKKKKACm/xU6m/wAVADqKKKACkpaKAOX1AYvJPrTbBtt5 GT61LqwxetVWHPnLjg5pgdcOlLTY/wDVrn0p1IBDS0hpaACiiigAooooAKKKKACiiigBFpaa tOoAKKKKACiiigAooooAKafvU6mn7woAdRRRQAUUUUAFFFFABRRRQA1ulLSN0paAFooooAKK KKACiiigAooooAavenU1e9OoAKKKKACiiigAooooAKaeop1NP3hQA6iiigAooooAKKKKACii igBG6UDpQ3SgdKAFooooAKKKKACiiigAooooAavU06mr1NOoAKKKKACiiigAooooAKaeop1N PUUAOooooAKKKKACiiigAooooAQ9KB0oPSgdKAFooooAKKKKACiiigAooooAaPvGnU0feNOo AKKKKACiiigAooooAKRqWkagBaKKKACiiigAooooAKKKKAEpF6UtIvSgB1FFFABRRRQAUUUU AFFFFADf4qdTf4qdQAUUUUAFFFFABRRRQAU1+lOpr9qBMUUtJS0DCiiigAooooAKKKKACiii gBo+8adTR9406gAooooAKKKKACiiigAprdqdTT1FADqKKKACiiigAooooAKKKKAEPShfuig9 KF+6KAFooooAKKKKACiiigAooooAaPvGnU0feNOoAKKKKACiiigAooooAKa3SnU1ulAC0tJS 0AFFFFABRRRQAUUUUAFNXpTqavSgB1FFFABRRRQAUUUUAFFFFADGGWrmL+MxXUi++RXUfxVi a5FtlWT1GKYiDSJRHdjPQ8V0dcjC5R1YetdZE26NW9RSGPooooAKKKKACkbpS0jdKAAdKWkH SloAKKKKACiiigCK4QPCykZGK5N/ldh7110pAjYnpiuSm/1jY6ZoA1dCJJfA4rYTvWRoOcSD HFa6d6Yh9FFFIYUUUUAFFFFABRRRQA09RTqaeop1ABRRRQAUUUUAFFFFABSHpS0h6UAA6UtI OlLQAUUUUAFFFFABRRRQAU0dTTqaOpoAdRRRQAUUUUAFFFFABRRRQA1uop1NbqKdQAUUUUAF FFFABRRRQAUh6UtIelAAOlLSDpS0AFFFFABRRRQAUUUUAFNH3jTqaOpoAdRRRQAUUUUAFFFF ABRRRQA1u1OprdqdQAUUUUAFFFFABWRrw/dxn3rXrH14/LGKAMVeorrLY5tk+lcmvLCuttxt t0HtQA9elOpq9KdQCCiiigAooooAKKKKACm/xU6m/wAVADqKKKACiiigDndaBF5n1FUEyHH1 rQ1v/j6HGOKzR96gDr4DmFCfSpKgsiTaxluuKnoARqWmt2p1ABRRRQAUUUUAFFFFABRRSUAI vSnU1adQAUUUUAFFFFABRRRQAU3+KnU3+KgB1FFFABRRRQAUUUUAFFFFACN0oobpRQAtFFFA BRRRQAUUUUAFFFFADV706mrTqACiiigAooooAKKKKACmn71Opp6igB1FFFABRRRQAUUUUAFF FFACN0oHShulA6UALRRRQAUUUUAFFFFABRRRQA1epp1NHU06gAooooAKKKKACiiigApp6inU 09RQA6iiigAooooAKKKKACiiigBD0oHSg9KB0oAWiiigAooooAKKKKACiiigBo+8adTR9406 gSCiiigYUUUUAFFFFABTW7U6mt2oAdRRRQAUUUUAFFFFABRRRQAlC9KKRelADqKKKACiiigA ooooAKKKKAG/xU6m/wAVOoAKKKKACiiigAooooAKY/QU+mP0FAmOpaQUtAwooooAKKKKACii igAooooAaPvGnU0feNOoAKKKKACiiigAooooASkbqKWkI6UAOpKKKAFooooAKSlpKAFopKKA BulIv3RSnpSKPlFAh1FJRQMKKKMUALRSYooAWikoxQAg+8adTQPmzS0CQUtJiigYtFFJQAtF JiloAKa3SlpHHFAhRS0gFFAxaKSigBaKSigBaKKTFABSL0paRRQA6ikoxQAtFJRQAtFJRigB aKSigBP4qy9d/wBSh9608fPWVrp/dqKYjFFdXZn/AEWPnPFcmCMiuo05cWifSkMt0UlFAC0U UUAFNbpS0jDigBR0paQDiigBaKSigBaKSigCK5x5D59K5NvvH611N+4S1cnPSuWPU0AbWhAi Nz2zWqh5NZ+iD/RT9a0E70xD6KSikMWikpaACikpaACiiigBp+8KdTSPmFLQAtFJRQAtFJRQ AtFJRQAtIelFB6UAA6UtIOlFAC0UUlAC0UlLQAUUlFAC00dTS0gHJoAdRSUUALRSUUALRRSU ALRSUUAI3UU6msORzS0CFopKKBi0UlLQAUUUUAFIelLSHpQADpS0i9KWgAoopKAFopKKAFop KKAFpo6mlpAPmNADqKSloAKKSigBaKSigBaKSigBG7U6mMM4p1AhaKSigYtFJRQAtYevN88a 1t1ga6f9JUZ7UAZ0ILTIF65FdcgxGAfSuWsV3XcY966rHy0ACdKdTE6U6gSFopKKBi0UlFAC 0UlBoAq312LWLI5J6VjnV7jJIxVjXHU4Abkdqxe3WgDZt9bOdsqDr1Fa8c8cgG11OfeuOp6u ynKkikB2WaK5ePUbiLAWQnHrzUw1m5HXafwpgO1ts3Ix2FZmeakubhriXe+Mmoe9AHUaVMZb Rd3UcVerG0W4Aj8skD6mtgHPQ0AI1OprUtAC0UnNFAC0UlFAC0UlFAC0lFFACL0p1NXpS0AL RSUUALRRSUALRSUUALTT94U6m/xUAOopKWgAooooAKKKSgBaKKSgBG6UtI2cUtAC0UlFAC0U lLQAUUlFAC0UUlACL3p1NXvS0ALRRRQAUUlLQAUUlFAC009aWkP3hQA6ikooAWiiigAooooA KKKSgAbpQOlI3ShelAh1FJRQMWikooAWikooAWikooARepp1NXOTS0ALRSUUALRSUUALRSUU ALTT1FLSHqKAY6ikooAWikooAWikooAWikooAD0oHSg9KRegoAdRRSUALRRRQAUUlLQAUUUl ACD7xp1MGdxp1AkLRRRQMKKSloAKKSloAKa3alpGzxQJjqKSloGFFJRQAtFFJQAtFJRQAUi9 KU9KRc4oEOopKWgYUUUlAC0UlFAC0UUUAN/ip1N/jp1ABRRRQAUUlFAC0UlFAC01+lLTXzgU ITHClpB0paBhRRRQAUUUUAFFFFABRRRQAzcobBNLuX1FN2gtk07YvpTJ1DcPWl3D1pNi+lG0 elIeouR60ZHrSbR6UbR6UBqLketJuHrRtHpRtX0oDUXcPWmswGOaXaPSkZQaYai7h60u4eop Ng9KNq+gpBqLuHrRketJtHpRtHpQGouR60bh60m0elG0elAai7h60ZHrSbR6UbR6UBqBIx1o BGOtBUY6UiouOlMNR2R60ZHrSbF9KNg9KQai7h60ZHrSbB6UbF9KA1FyPWjI9aTYvpRsX0oD UXI9aMj1pNi+lGxfSgNRNw3Yp2R61GUBbFO8tfSnoLUdketGR603y19KNgoHqOyPWjIpNgo2 CkGouRRmk2CjaKAFzSMQBRsFNdBjimDuPBBHWjI9aYIlx3pfLWgNR2aM0mwUbBSDUXNGaTYK NgoDUXNGaTYM0mwZoDUdmkVgaNgpixjqaYakmaMj1pvlj3o2CkGo6im7B70eWPemGo7IoyKY yKBkmqjX9qkhRnwRRoGpezRVNbu0bpKv5043VsBnzR+dLQNSwzYaue1aYSXGBk4rVe7tiOJR j61h3xTziY2DLT0BXKw9a3tFmZoyjHgdM1hJywGcVs281parzJuY9cUIeps5orHl1aFR+7Vm PvxVY6xJnhBiloLU6HPvRXONq8xHyqB71atdURiFmBB9aA1NmkbpTECOMq2RSsnHU0w1Hggj rRUax8cmlMYPc0Bdj6Kb5Y9TSFAOpNINR9FREoBy4/Om74unmjP1o0DUZqKb7RxuxxXLng10 F/PD9mcLICcdM1zrNQBuaHKojZM4Oa1kPJrkredoZAy1rR6rCCN4amDubNFZy6naN1dh9RUi 31q2MS0g1LtGarR3Vu7bVlBP1qbYCc5NAaklFM2e5o2e5oAdRTdnuaAnuaA1FJwRS0xkORzS 7Pc0wux1LTNn+0aNvuaQD6KZs9zRs9zQA6im7Pc0bPc0w1H0h6U3Z7mgrx1NIBwII4oqNYz/ AHiKds/2jTC7H0lN2+5oKe5pAPopmz/aNLt9zQA6imbD/eNG0+poAfTR1NG33NN2ncTmmBJR Tdp9aQKc/eNIB9FM2n+8aNp9aAH0U3af7xo2n1NADqKZtP8AeNLg+tAA3UUtRupIAzzTghx9 40xXY6im7D/eNG0/3qQ7jqKbtPrRtP8AeoC46im7T/eo2n+9QA6g9KaFP940EHHWgBw6UUxV bHWl2t/ephcdRTdp/vUu0/3qQC0Um0+tJtb+9QA6im7T60bW/vUAOo70mD60wqd3Bpg2S0Uz a396jaf71ILj6KZtb+9Rtb+9QFx9FM2t/eo2t/eoC46ikw3rSYb1oAU9qWmOGx1oCtjlqYXH 1C93BGSGkUEe9Zup3zxN5aNz3rGaRnYljknvSGdWl1A/3ZV/OpQ6sOGBrjt2KeszqPlYj8aA OvyPWuc1tgbv5WzxVUXMoziRuevNQsdx560AT2EyxXKSP0FbZ1i229T+Vc6PpS0AdCurWwxk nn2qyL63IB81efeuV5ozQB1wuIj0kX86invoYVJLAkdhXMbiOhNNLE9aANv+3EzzGau2t/Dd cIcH0Nct0qSKVo2DD9KAOvoqtaPJLbqxOCRU2H9aYrmTrsRIWQDgVjEZrq54TJEysQRjuK5e Vdjso7GgES2lm90SEIBHrU8mk3MYyFDfQ0/RiftBA64rdCv3amI5Z7aZD88bD8KjKMOqkfhX WlWPcUx4A4wwUj3FGganJbaTBzXUSadDJ1QD6VVl0VD/AKt9tKyHdmIDjGDVq31CeBuHyPQ1 JNpVxHyqhx7VTkieM/OhU+4osFzROtSnrGtWINZ3squmCT1zWFmnKR2pDOxU7gCKWqWnu0lq p3dOKtYb1FOwrjqWmYf1FGG9aQXH0UzDetGG9RQFx9JTcN60uG9RQFxR0oqNQ+TzTsN6inYL jqKbh/UUuG9RSC46imYb1FGG9RQFx1FJhvUUmHz1FAXHUnej5qYwbI5pg2SUU35/UUuG9RSC 46imYb1FL81AC0UmG9RRhvUUBcWik+b1FJ8/qKAuOPSimtu2+9A345IphcdRTfm9qX5vakFx aKT5vUUfN7UBcWim4f1FHze1AXH0Uz5val+b2oAUUtRAPk4NO+f1FMLjqKb8/tR83tSC46im /P7Uvze1AXFopPm9qT5vagLjqO9J83tTW35FAXH0U35/aj5/agLj6KZ83tS/N7UAOopvze1J 83tQA6ik+b2o+b2oC4p6UDpTW3bT0pqb8dqYX1JKKb8/tR8/tSC46im/N7UfP7UBcdRSfN7U nz+1AXHUU35/aj5vagLijvS1GN+4075/amCY6im/P7Uvze1ILi0U35/aj5/agLjqKb8/tR83 tQFx1B60nze1NbfkYxQFx9FN+f2o+f2oC46im/N7UfP6CgLjqKb8/tS/N7UBcdRTPm9BR83t QFxxoHSmndjtSKXx0oC5JRTPn9BQC/oKAuPopmW9BRlvQUBcfRTPm9BR8/oKAuPopmW9BS5b 0oC4DqaWoyX38CnfP6CmJMfRTMt6Cj5vQUh3H0UzL+goy3oKAuPopmW9BRl/QUBcfTW7UgL9 wKR92KAuSUVGC+OQKXLegosFx1FN+f0FHz+goC4+imfN6UfP6CgLjqKb83pR83oKAuOpF6Un zegpql8dKYXJaSm5f0FL83oKQXHUUzL+goBb0oC4+im5b0FGW7AUBcdRTct6UZb0oC4fxU6o iW3cU7LegoC4+imfN6CjLelAXH0U35vaky3oKAH0U3LelJ83tQFx9NfpR83oKa5bjigGx4pa QUtAwooooAKKKKACiiigAooooAaPvGnU0dTTqACiiigAooooAKKKKACkPUUtNbqKAHUUUUAF FFFABRRRQAUUUUAI3SkX7opW6Ui/dFAh1FFFAwooooAKKKKACiiigBP4qWmj7xp1ABRRRQAU UUUAFFFFABTWp1NbpQA6iiigAooooAKKKKACiiigBKRaWkXpQA6iiigAooooAztWnaKHCnBN c6WJPPNb2uI7QAr90HmsA0AGfSlB4qzY2Ru3IDYArTXQ4x96Vj+FOwjDJpPwrdOixbsB2oOh x9pW/KiwXMLFKK3Boad5T+VSro1sOpY/jRYDnjz3pNpA6Gupj0+2jPEQP15qU28JGPLX8qNA 1OQNANdBqGmJIheIBSB0rnypBI9KTQzY0SZ/NKZJXFbjdK5rSHK3gGetdI33aAFHSigdKDQA jHCk1zuoX8skhRSVA9DWzfzeVbMc4PauWdizE55NADjIx6s350gY9iafBbTTthFJq+uizlQS yj2osFzMJPekNa40OXIzIuKmTQ4/45CfpTsK5hD9acTxXQro1spz8x/GnrplqScx0WC5zdID XSNpFqQRtI/Gq0mhx4JSRvoaLAYoYjocGrcGpXEOBvyPeori0khGWU4qAUrWHc6myvUuUHI3 dxVuuX02Vo7pNvc4rpx0oAWiiigBD96lpp+8KdQAUUUUAFFFFACUtFFABSHpS0h6UAA6UtIO lLQAUlLRQAUUUUAFFFFABTR1NOpo6mgB1FFFABRRRQAUUUUAFFFFADW6inU1uop1AgooooGF FFFABRRRQAUh6UtIelAAOlLSDpS0AFFFFABRRRQAUUUUAFIOppaQdTQAtFFFABRRRQAUUUUA FFFFADT2pJSRGxXrilbtTZzthc57UAcpcszTuW65qJVJp8hzIx96v6TZmaQSMMoKLBcgi02e UjC4B7mrA0W4I5Kj8a31UKMAYFOp3Ec9/Y1yP7v50qaLOfvFRW/RRcLGQmhqG+eTI9qkOi2/ q351qUh6UXCxkf2KhBxIR+FNOhk/8tR+VbC9KWi4WMNtDk/hkWs+5tnt3KuOldbWPri/Ipz+ FG4GETVuytWuJAB09aq45rotHg2QeYerUhl+JPLjVfQU+ikoAZM4SJiTgYrlJCDIxzwTW1q9 4qRmFeWP6VhKN7hR3NAGtokRMjSdhxW5VSwgFtAFyM9TVuhgFFFFABRRRQAVFLCkqEOoNS0l AHJ3kQiuHQDABpttEZZVQd6n1MYvZKZYttuozjvR1EdLbQrBCEWpqQdBS0DCiiigAooooAKK KKAEHSlpB0paACiiigAooooAKKKKACm/xU6m/wAVADqKKKACiiigAooooAKKKKAEPSihulFA C0UUUAFFFFABRRRQAUUUUAIKWkFLQAUUUUAFFFFABRRRQAUnelpp60AOooooAKKKKACiiigA ooooARulA6UN0oHSgBaKKKACiiigAooooAKKKKAGjvTqavU06gAooooAKKKKACiiigApp6in U09RQA6iiigAooooAKKKKACiiigBD0oHSg9KB0oAWiiigAooooAKKKKACiiigBv8VOpo+8ad QAUUUUAFFFFABRRRQAU1u1OprdqAHUUUUAFFFFABRRRQAUUUUAJQvSihelAC0UUUAFJS0lAC 0UUUAFFFFADf4qdTf4qdQAUUUUAFFFFABRRRQAUx+gp9NfoKBMUUtIKWgYUUUUAFFFFABRRR QAUUUUANH3jTqav3jTqACiiigAooooAKKKKACmt1FOpp6igB1FFFABRRRQAUUUUAFFFFACHp QvQUN0NIv3RQIdRRRQMKKKKACiiigAooooAaPvGnU0fep1ABRRRQAUUUUAFFFFABTW6U6mt0 oBiilpKWgAooooAKKKKACiiigBDSL0pTSJ0oAdRRRQAUUUUARXCh4WVuhFcnINsjKOgNdVeE C2cn0rk368UAaugtiR1x+NbtYuhIQHcjj1ov9UljnMcRAC96GBsfx0+s+wvluSAfv45q/QAt FFJQAd6WoJrqGA4kcA1Kjq6hlIINACS48ts9MVyNwV85tvTNddIR5bZ9K5G4wZnwOM0AS2BI uo8DPNdSfuVzukxF7sHHC810T/dpiHDpQaB0opDKOrR77Rj6c1zWOa6fU1LWb4OK5nvTA6LR 1QWoK8nvWhWfphSKxViQO5qGXWkWXai7l7mkwNeismbWolA8sFj3qzY36XS8kK/pQBcpqdTT qYh5NMRJRSUtIZFPAk0ZVhmuWu4jBOyeldbXP64m25DZ6imBVsObqPC55rqh0FcvpvF5Hzjm uoHSkAtFFFADSfmFOpp+8KdQIKKKKBhRRRQAlLRRQAUh6UtIelAAOlLSDpS0AFFFFABRRRQA UUUUAFNHU06mr1NADqKKKACiiigAooooAKKKKAGt1FOprdRTqBBRRRQMKKKKACiiigApD0pa Q9KAAdKWkHSloAKKKKACiiigAooooAKaOpp1NHU0AOooooAKKKKACiiigAooooAa3aq+oEi0 fHpVhuoqvqPFm/OOKYjlyOa6PR1As19653vXTaaQbKPAxxQBbopCcdaqy6jbRNhnGfakMt0V HFMky7o2BFSUAFIelLTWOFJNAAnSnVT+32yHa0gzVpWV1BUgg0Ah1YuvKcI3atqsfXTlUX8a AMQD5uK6uyz9lTIwcVy8Kb5lX1NdbEu2NR6CgB9RXEqwxM7HoKlrF1yb7kYPuaAMu4lM0zO3 JJqazURgzOM46Cq8aGSQKvU1q3tsI7NQOCo5qkSzNmu5pHLeYw9Oa09Iv5JJPJkO70JrGNaG jxk3QbsKmxVzo6SszUtQa3Plx43Hv6Vn2uozrONz7gTyDQB0lFNVtyg+tV728W0TJ5J6CgC1 RWXY6p9ol2SAKT0rUoA53WYyt2W9RVKFikqsOxrX15PkR++cViqcMKYHXQtviVvUVJUNrj7O mB2qakAUUUUAFFFFABRRSUAIvSnU1elOoAKKKKACiiigAooooAKb/FTqb/FQA6iiigAooooA KKKKACiiigBG6UtI3SloAKKKKACiiigAooooAKKKKAGinU1e9OoAKKKKACiiigAooooAKT+K lpD96gBaKKKACiiigAooooAKKKKAEbpQOlDdKB0oAWiiigAooooAKKKKACiiigBq9TTqavU0 6gAooooAKKKKACiiigApp6inU09RQA6iiigAooooAKKKKACiiigBD0oHSg9KB0oAWiiigAoo ooAKKKKACiiigBo+8adTR9406gSCiiigYUUUUAFFFFABTW7U6mntQA6iiigAooooAKKKKACi iigBKB0oNC9KAFooooAKKKKACiiigAooooAb/FTqb/FTqACiiigAooooAKKKKACmt0FOprdB QDFFLSUtABRRRQAUUUUAFFFFABRRRQA0dTS0g6mnUAFFFFABSUtFABSUtFACU1s5FPpD1FAB RS0UAFFFFACUUtFABRRRQA1vumhPuilPShelAgpaKKBiUUtFABSUtFACUUtFADATvNOpB1p1 ACUtFFABSUtFACUUtFACU184p9NagTFHSiiloGJS0UUAJRS0UAJRS0UAJ2pqHinUi9KBC0Ut FAxKOaWigDI1yZljWMHhutYkamR1UdTxV3VpWku2U9F4p2kQLLcbm/h5pga9vB9ntAi8tiub uQ3nvv4bPNdfjjFcvqcZju2z35oAl0h9t2PeugeQIhZuAK5rTji6TJIrX1WcxWuB1bigBDrM Afbg49avRTJMm5DkVyOc1t6GXKMDnb2pAUtWV1uyXPB6VZ0a6O4xO3Hana7H9x/wrMtX8udH 9DTA6mQ/IeO1cncAmZ/rXWKQ8YPqK5nUIjHdOPfNAFrQzidue1br/drnNLkCXa578V0jcrQI F6CloHSikMp6m2LN8+lcx3rpdXbFm3vXOpy4HvTA15ARpA9cViV0d4gXTeOy1zuOaGAlWLJi lyhzjmo5kMePcZpbZtsqsccGkB1gb5M+1YF7ezGYqrFAD2rfjIaMEdMVzepptu2A780xGrpd 81wux/vL39a0q5vSJSl2B2PFdIKQwrF15eUbFbdY+vY8tD3zQBl2TbbmMnpmuqU5UVyUB/fJ j1rrI/8AVrn0oAdRmlooAYT84p1IfvCnUCEpaKKBiUtFFACUUtFACUjdKdSHpQAi9BS0DpS0 AFJS0UAJRS0UAFFFFACU1Tkmn01epoEOooooGFFFFABRRRQAUUUUAMY8inUjdRTqBBRRRQMK KKKACiiigBKRuhp1IelACL0paB0paAEopaKACkpaKAEpaKKAEpAfmNOpo6mgB1FFFABRRRQA maWiigBKKWigBjnkVBqHNnJ9KsMORUV6AbWTPpTEcqc5xXSaUc2SZrnDXQ6Q2bNfagY3V7ny rfYp+ZuK50nJ5rS1ts3IUjgCs5F3OB60gNbQ8l2POBW3mqtharbQgDknk1Lcu0cDMoyQOlMC C51KC3baxJPtVVtXimidQCp7ZrHmkMsrO3UmmY9KQCu2XJNbuiSl7cqf4TWDW1oJykn1pga+ a5/WZd84T+7XQVzWqkG8fFICGyBN1GB611Q6Cuc0mMNdrnJxzXSCmAE4FcxqUhku2PTtXTPw prlLpt1w5HrQBZ0iMyXQb+7zVjWpWBEYPBo0NfmdsVV1SQPdtz04oEUgpZgByTXSadbeRbDK 4Y9axdOi866UHtzXT4wtAHMaic3j0unQCe4AboOTTL3m7kzwc1d0RR57E9cUAbiAKoA6Vh66 375B7Vu1zmrSb7xvbikMj05d15GK6cdK53R1zeD2FdHTAy9cGbcH0NYC/fFdBrYH2UfWsFMB x9aBHV2xJgTPXFS1Hb4MKEDHFS0hiZopaKACiiigBKDS0lACKeKdTV6U6gBKWkpaACiiigAo oooASkP3qdTT94UCFpaKKBhRRRQAUUUUAFFFFADW6UtI3SloAWiiigAooooASilpKACilpKA EXvS0ijrS0AFLRRQAlLRRQAUUUUAFJ3paafvUAOpKWigAooooAKKKKACiiigBrdKUdKRhkUo 6UCFooooGFFFFABRRRQAUlLRQA1TyadTV706gSCiiigYUUUUAFFFFABTT1FOpp6igB1FFFAB SUtFABRRRQAUUUUAIelA6UHpQOlAC0UUUAFFFFABRRRQAUUlFACAjcaWmgfMadQJC0UUUDCi iigAopKWgBKRj0paRh0oEx1FFFAwooooAKSlooAKKSloAQ9KRelLSL0oAdRSUUALSUUUALRR RQAUUUlACfx06m4+enUCEpaSigYtFFFABRRRQAU1+gp1NcZAoExRS0lLQMKKKKACiiigAooo oAKKKKAGjqadTR1NOoAKKKKACiiigAooooAKaeop1IeooAWiiigAooooAKKKKACiiigBD0oX 7ooPSgdKAFooooAKKKKACiiigAooooAaPvGnU0dadQAUUUUAFFFFABRRRQAU1ulOprdKAFpa SloAKKKKACiiigAooooAKRelFIvSgB1FFFABSHpS0h6UAcvqHN3Jn1q7oePMf1qpqS7Lxx68 1Lo7hboA9xTEdDXO6yMXfXtXRHpXM6q2b1sUhkdlxcp9a0taXMSN2rMtCRcKcgYPU1q6qVkt AVkU4pgYWK6fTI1S0Xb3Fcxmui0ecPbBe69aQCa0gNtnuDXPq2CD6V0GrzoLcpkbj2rnu9AH VWE3nWqNx0rM12PEiOB14qXRJhsMfOam1pN1ru7g00DMKCTy5lYdQa6pH3wq3qK5JetdPZSB 7RCOeKBFodKDQOlBpDMfXJRtWPPvisu2TzJ0VepNWtZP+l9e1JpKBrsHrimI1NSDCwIB6Dmu cHJrq7xQ1q4I7VyhOGoAtXiqIYiueneqg4q9FH9qttiY8xemadbaZM8gDrtUHmiwGlo5c2vz dO1Z2rri5z6it+NFijCrwAKwtZdWlAHUUAynatsnRvQ11aHcgNccDg11GnzCW2XB5ApDLdY+ vONqLg5rYrB10/vVGe3SgDPtQWnT611i/dFcvYgtcxgdc11I6UwFooopANPUU6mn7wp1ABRR RQAUUUUAFFFFABSHpS0h6UAA6UtIOlLQAUUUUAFFFFABRRRQAU0Dk06mjqaAHUUUUAFFFFAB RRRQAUUUUANPUU6mnqKdQAUUUUAFFFFABRRRQAUh6UtIelAAOlLSDpS0AFFFFABRRRQAUUUU AFNHU06k7mgBaKKKACiiigAooooAKKKKAGt2qK9OLWT6VK3aoL/H2STd0xQBy56mui0gf6GD 6mud6muj0nP2Nc0xGZrn/HyOB0rOjOGB961NdRvOViOMVlfSgZ1dlL51urAUX3/HrJk44qvp LbbRQxFO1Jg1owVhSA5o8H1q5YW6zrIW7CqRqa3nMOcdDxQhEbABiPQ1o6JNsnKdmrNc5Yn1 qa0fZcIQe9AzrD0rlr9t13J25rp1bKZ9q5i/Km7k2+tMC3oZzct9K365/Q/+Pk46YroKQEc/ +pb6Vycn32+tdNqDBbVySRx2rmD14NMDY0YfuJD+tZVyczvj1rb0lMWZJ71i3a7bhx70MRZ0 ZlF383ccV0EpxGxHpXJwSmGVXHY1qvrS7CPLJ/GkMzLhiZnJ65q7oz4useorPlcPIWUYB7VP Yz+Rcqx6UxHUMcKTXK3r+ZcO3vW5eX8SQHa4LEdAa51zuYt60hmhorhbvB7iuirkbWUxTo47 GuricPGrDuKAM7XGHkKM85rDiGZQPU1qa5IDIqdxWfaqXuYxjqaYjqYhtiUegp9IvAFLSGFF FFABRRRQAUUUUAIOlLSCloAKKKKACiiigAooooAKb/FTqb/FQA6iiigAooooAKKKKACiiigB G6UtI3SloAKKKKACiiigAooooAKKKKAEFLSCloAKKKKACiiigAooooAKafvCnUnegBaKKKAC iiigAooooAKKKKAEbpQOlDdKB0oAWiiigAooooAKKKKACiiigBq96dTV706gAooooAKKKKAC iiigApp6inUh6igBaKKKACiiigAooooAKKKKAEPSgdKD0oHSgBaKKKACiiigAooooAKKKKAG j7xp1NH3qdQAUUUUAFFFFABRRRQAU09qdSHtQAtFFFABRRRQAUUUUAFFFFACUi9KWkXpQA6i iigAooooAKKKKACiiigBv8VOpv8AFTqACiiigAooooAKKKKACmt0FOpr9BQJi0tIKWgYUUUU AFFFFABRRRQAUUUUAREHfxxS4f1pw6mlpisN+f1FGH9afRSCwwBu5FGG9RT6KAsMw3rRhvUU +igLDMN6ikYN60+g9qYWG4f1ow3qKfRSCw35vWkw3qKfRQFhmG9RRh89RT6SgLDcN6ij5vUU +koCw07sdaRd2OtPPSgdKYWE+b1FJ83tTqKQWGnf6ij5/UU6igLDfm9qPn9qdRQFhvz+1L83 tS0UBYiO7fxTv3ntTh940tO4rDPnpRv9qdRSHYb8/tR8/tTqKAsN+f2o+f2p1FAWG/N7U192 3nFS01qYNDFL46U75/QU6louFhnze1Hz+1OopBYb83tR8/oKdRQFhuX9BRl89BTqKAsNy2Og pq7s8VJSL0p3CwhLelGX9BTqKQWG5fPQUZf0p9FAWOf1pCJwzDGRVSzfZcxketamuoDGje9Y 0XEikdc0wOrDSbelc5qIb7UxYEHNdLESYlz1xTZYI5Qd6A/hQFjkTSbuOvFaVzpMyynygGU1 FFpVy7YK7fc0WHcogjFSJK8f3HK5q+dEuAOCpoXRbnAyVH40WC5nvIzn5mJPvTO9abaNOoOC pNQjS7kvgoR70WFcs6KCXYgdK0dQDPauCOMUun2QtY+fvHrU15gW759KLhY5MnBrb0iQm3Zf Q1iN944rX0Xdh+PlPehA9jWVnx0zS7nx92pB0oPSgLHMakf9MfNT6NjzzjriodUXF6+ak0Zl F3z1xxQBs3TP5D/L2rl3GHNdbLH5sZXPUVgy6VcCbaoyp70BsUoZngbchwasDUrn/nofyq9D ogKfvWIPtSNoR/hl/MUWC5Qa/uWPMzCq7uXPzMSa0m0WfdwykVXuNNmhTeeQPSiwXKYra0Rm CsAMisdUYnABJroNIt5IYcyd+lAF4swH3a5zU5/OuTxjbxW9fTGG2Zh1rlnYs5J6mkBd0pM3 IOM4rogzf3ay9DQiNmI/GtemAzc392gM392nUUARszZGBShmx92nEfMKWgLDdzf3aNzf3adR QFhu446Ubm/u0+ikFhm5s/do3H+7TqKYDdx9KGY46U+kPSkAxWJHSl3H+7Th0ooCw3cfSgsf 7pp9FAWGbj/do3H0p9FADNx9KNx/umn0UAN3H0pu4g9KfSDqaYNCbj/dNG45+7T6SkFhNx9K Tcf7pp9FADNx9DS7j6U6igBm4/3TS7vY06igCJ2IxxTg5x0NKwyRS0xWdxu4/wB00u4+lOop DG7j6GjcfSnUUAN3exo3exp1FADN/saC3HSnUHpQAxX46Uu//ZNOA4opgkxu72NG/wBjT6KQ Dd3saQtx0NPooAZv9jRv9jT6KAG7vY0zeQ3SpKTA3Zpg0xN/saUt7GlopBqN3+xo3+xp1FAa ib/Y0m/2NPooAZv9jS7/AGNOooAjZ6o6pN/ohHQmr7jOM1ja1OrMsS9RyaYa3MoDLYFdNYjy bZFIPSuetE33KD3rqlGFAoAq3kCXUe1gc9jWTJp/2cb3YEeldDVe9h863ZR1xxQmKxzLyvn7 5AHQCmmV8Y3n86k+yTkn90xx14qQadct0iNFh3KlH0q7/ZV3j/V/rU0ejTEAuQvtRYLmZzip 7WFpJVA9a2I9HhKYYnPtV23tIrdcIo+tGiDciml8m0IHBxiubkJZiTySa2NYufk8pSPesTrQ wNTRTtmPy54rc8wehqho9v5cG89WrROAM0BqZmsTHyAoOM1hgZYAHmruqXHnXBUfdXiorCAz 3K4HAOTQBvWfyWyqQQcVi6nAwuGYA4PeujUYAFMaNHbDKCKd0GpyZicLuxxTK6e9slmhKoAp HYVjHSrj+7St2C5QzSg81dGl3PHyVLHo1w65bap9DRYLmdkmkxWzHoZx+8lwfYVah0e3j+9l z70WC5iWts8sgx610sJEcQXngU6KCOEYRQKLhtkLN6CjQNTntUm826b0HAp+kJuuQx6LVGRy 8hJ6k1u6JCFgLnq1AGj5gpd496XFFINRpkHvS7xS0UBqJvFG8UtLQA3cPejcKWigBiuOlLvH oaVRilpgrjd49DRvFOxRSDUTeKN4paKAE3CjcKWigNRN4ppcA0+kI+amDuJvFLvFLRSATeKN 496WigBN4o3ilooDUTeKTeKdRQGo0sMUCQUrdKWmGom8UbxS0UgE3CjcKWigBu8Uu4UuKKA1 E3CjcKWigYwOM4p28UAUtMWom8UbhS0Ug1E3ijcKXFFACbxRvFLRQAm4UhfBFOpCMmgNRN4p d4pcUYoDUTeKN4pcUUBqJvHrRvFLijFAaibxRvFLRQGo0sMUBwRStjHNAAx0phqG8UbhS4ox SDUTcKNwpcUUAJvFG4UuKMCgNRN6+tG4UuKKA1GBxk07cPWgAc8UuKYaibh60bhS4FGBSATc KNwpcCjAoATcPWjcPWlwPSjAoDUTePWkLjNOxSEAkUw1DevrRvX1pcD0owKQaib19aC6+tLg elGB6UBqJvX1o3r60uB6UYHpQGom9fWjevrS4HpRgelAaiFhjrSBwR1pSOKAoA6Uw1DevrRv X1pcD0pMD0pBqG4etG4etLgelGB6UBqJuHrRuHrS4HpRgelAaibh60u4UYFGBQMZvG4+lO3r 60m0bicU7A9KYlcTcKN6+tLijA9KQaib19aNw9aXA9KMD0oDUTcPWjcPWlwPSjA9KA1E3D1p GYYHNOwPSmsBxTDUXevrRvHrS4HpRgelINRN6+tG8etLgelGB6UBqJuHrRvX1pcD0owPSgNR N6+tG4etLgelGB6UBqJuGOtIrinYHpSKoxQGob19aNw9aXA9KMD0oDUTcPWjevrS4HpRgelA aibh60bh60uB6UYHpQGom4etG4etLgelGBQA0uA1LuHrSbQWp2B6Uw1E3r60bh60bR6UuB6U g1E3D1o3D1pcD0owKA1E3D1o3D1pcCjA9KAE3D1prsOBmn4HpTWA4pgxwpaQUtIYUUUUAFFF FABRRRQAUUUUANH3jTqaPvGnUAFFFFABRRRQAUUUUAFNPUUtITyKAHUUUUAFFFFABRRSUALR RRQAh6UL0FDdKF6CgBaKKKACiiigAooooAKKKKAGj7xp1NH3qdQAUUlLQAUUUUAFFFFABTW6 U6mv0oBjqKQUtABRRRQAUUUUAFJS0UAJSL0paRelADqKKKACikpaAMPXmy6Lk59Ky4AWmQD1 rT10DzUPfFZ1sdtwh96YHVxjCKPan01DlRTqQDf4qWm/x06gApaSigA70UUUAFUdXl8u1Pvx V6sHW5iZAnYUAZfU1u6OrC2Ofuk8VhKATXTWMYitFA7800JlwdKD0oHSmyMFUk9qQzndZAF4 T6ioLFtl0hzjml1Cfz7gtjpxTbFS9yg96AOrU5UUtIvQUtABRRTJZkiUs7ACgB9MVQ2QRmqq apbu4QNyfWrUbA5xTQmMS1hjcsqAE1N0ozUFzdRwJl2A9KQzP1q6ATyV79axokMkiqOSTT7u fz5Wf1osmCXKFjjBoA6e1iEMCqBjip6bGwZARTqACikooATvTqafvCnUAFFFFABRRRQAUUUU AFIelLTWOBQAo6UtIOlLQAUUUUAFFFFABRRRQAU1epp1NHU0CHUUUUDCiiigAooooAKKKKAG nqKdTW6inUAFFFFABRRRQAUUUUAFIelLSHpQADpS0g6UtABRRRQAUUUUAFFFFABSDqaWkHU0 ALRRRQAUUUUAFFFFABRRRQBDdSCKIue1cvPL50zOe5rb1qTbbhcHnvXP0xGposO+YyEcLW9X NWmotartVAR3qZ9amP3VUUho36Mj1rmX1O5b/lpjPpUJu5yeZW/OgDqsoO4pDJGP4l/OuTaa Q9Xb86bvY9SaAOtE8R/jX86GnjA++v51yW9qXe2OpoA6gXUK8GRc/WlkuoVU/vFz9a5Tcc0u T60AS3TmSdyTnmktoGnlCL1qI1uaLAAnmFeT3piNK3j8qFU9BVHVL4Qx7EPzGtFuFNcresXu XJOeaQyEvkn1rd0a32ReYx5btWB3qxDezw/cc49KLgdXmm5+eub/ALTuj/y0py6rcg7t4P4U AdJRWAutTjqqGlOtT/3UoA3qMiuel1e4cYUqvuKrDULgEkSNzQB1WaRmCjJIxXL/AG+4P/LV vzpsl7O/DyMc9qAN46rbCQqW6d6W9mV7JmT5gR2rmc5NbGib33o3KUIDLSNnfCAk/Sul0+N4 rVVcYNSCCOP7iKPoKlpsQtFFFIYUUUUAFFFFABRRSUAA6UtIvSloAKKKKACiiigAooooAKTv S03+KgB1FFFABRRRQAUUUUAFFFFADW6U6mt0paAFooooAKKKKACiiigAooooAQUtNXvTqACi iigAooooAKKKKACk70tNP3hQA6iiigAooooAKKKKACiiigBG6UDpQ3SgdKAFooooAKKKKACi iigAooooAaOpp1NXqadQAUUUUAFFFFABRRRQAU09RTqaeooAdRRRQAUlLRQAUUUUAFFFFACH pQOlB6UDpQAtFFFABRRRQAUUUUAFFFFADR9406mj7xp1AIKKKKACiiigAooooAKaadTW7UAO ooooAKKKKACiiigAooooAQ0i9KU0i9KAHUUUUAFFFFABRRRQAUUUUAN/ip1N/ip1ACUtFFAB RRRQAUUUUAFNanU1+1AMUUtJS0AFFFFABRRRQAUUUUAFFFFADR940tIPvGnUAgpKWigBKKWi gBKKWigBKRhyKdTT1FAC0tFFABSUtFACUUtFABSYpaKAEI4pFHApT0oX7ooAKWiigBKKWigB KKWigBKKWigBoHzGlxSDrTqAExRS0UAJijFLRQAmKKWigBKa44p9NYUCYoHFGKWigYlFLRQA lFLRQAlGKWigBCKagwKdSL0oELRilooGJRS0UAYuvL9xscetY2cV02qRCS0bIyRyK5kjFAG9 pF4JYxEx+Za1K4+KVoW3ISD61M19ct1lb8KAOmJAfk0efFnHmLn61yrzSMPmdj+NM3HPJoA6 3zYyfvjP1prXMK5zIvHvXKF27E0wkk80AdM+p2yjO/P0qrLrSg4jQt9axKOcUAao1yTPMYx9 ap31yLmUOBiqxVh1BFB4HINACoQGBrqLYA26kEniuWHWt7SJmeAq3amhM1AOKiug3kNt64qY dKhu932d9vXFIZykn32z1zU1lOLeYORkVC3LHPWm96AOgi1eAg7sginDV7ckjJ/Kue7UCgDo W1e2A+82fpWRf3puZMjIUVUNHagAVsNkVfg1OWFdoG761n804AnoKAL0uq3LgjcF+lUnleTG 5y31qRbaVh8sbH8KctlOw4hb8qLMLlY05RnpxVpNOuW6RHFXLXSGL/vgQtOwrmhpZJtEyxJ9 6uU2KJYkCoMAU+kMSjFLRQA0j5hS4pD94U6gBKKWigBKKWigBKKWigBKRulOpD0oAB0FLSDp S0AJS0UUAJS0UUAFFFFACU1R8xp9NHU0CHUUUUDCiiigAooooAKKKKAGt94UtI3UU6gQUUUU DCiiigApKWigBKD0paQ9KAEXpS0DpS0AJRS0UAFFFFABRRRQAU0feNOpo+8aAHUUUUAFJS0U AFFFFABSUtFAFW9tFukCsSPesm80oW0BcOWNbzdqHRXUqwBB7U7isccRzTljZugJ+grpRplq DnywasJDHGAERRj0FGgHMrYXL4xCw/CpxpFyf4R+ddFS0XA59dEnJ5dRUv8AYbY/1oz9K2qK LhYxDocmB+8X8qBob/xSD8BW5SHpRcLGGNFYjiQZ+lKdDb/nqM/StpelLRcLGLHoriQb2UrW tBCsEYROlSUtFwsIRkEVz1/p0sczOilkPPHauipMUhnJC2lbpGxx7UotJif9U35V1gUDoKMU 9BHJG1mB/wBU35U0wyf3G/KuvxTdo3dBRoGpyXlt3U/lSMjYzg/lXXlFPVR+VVr3y47ZiVGM elGganLHrSgUrdTgU6FC8qgDkmkMni0+5kAKxnB709tKut3+r/HNdFCNsSg9cU+mKxz0Wj3B cBgFXuc1tWtqlsm1PxNT0tFwsNaloNLSGFFFFACUUtFABRRRQAUh6UtFADUzjmloXpRQAUUt FABRRRQAUUUUAFNP3qdTT96gBaWiigAooooAKKKKACkpaKAGt0paRulLQAtFFFABRRRQAUUU UAFJS0UANXvTqRe9LQAlLRRQAlLRRQAUUUUAFNP3hTqafvCgB1JS0UAJS0UUAFFFFABRRRQA 1ulKOlDdKB0oAKWiigApKWigBKWiigBKKWigBq5yaWkHenUAJS0UUAJS0UUAJS0UUAFNb7wp 1NPUUALS0UUAFJS0UAJS0UUAFFFFACHpQvSg9KB0oAWkpaKAEopaKACkpaKACkpaKAGDO406 kH3jTqBIKKKKBhSUtFABRRRQAlI3anU1u1AC0UtFABRRRQAUlLRQAlFLRQAh6Ui5xS0i9KAF paKKACkpaKACiiigApKWigBv8VOpv8VOoASilooASloooAKKKKACmPnin01u1AmKKWkpaBhR RRQAUUUUAFFFFABRRRQA0feNOpo6mnUAFFFFABRRRQAUUUUAFIe1LTW7UAOooooAKKKKACii igAooooAQ9KF+6KD0oXoKAFooooAKKKKACiiigAooooAaPvGnU0feNOoAKKKKACiiigAoooo AKa3SnU1ulADqKSloAKKKKACiiigAooooASkXpS0i9KAHUUUUAFFFFACEAjB6VUk022kOSmD 7VcoouBhTaJJvJidSD69qauiTk/Myit6lp3FYwxojZwZB+VPOh9cS/pWv/FTqLhYxToiqjEy 847Csd02sR6GuvlOI2wM8Vycp/eN25o3Au6ZYJdBjJnArXh0+3h+7GD9eaqaF/qn+ta1FwIJ LaKQfNGpx04rB1KzlhkL7PkPTHaulprKGGCMii4WOQSN3YBQTmui062a3t8OOTVsRRjoij8K c3SgBR0oIyMGgdKWkMpPpdq77inPsaY2kWp6KR+NaFFO4rFEaVagY2Z/Gl/su1/ufrV2ii7C xQm060VCzJgD3rnp1QSsI/u5rb1qYpGEU4zWCfWgY+2XdMoxkZrpre2hVciNc/SsnR7ZmlEh 6Ct1O9HQXUcAB0FFLRSGFFFFABRRRQAUUUUAN706kPUUtABRRRQAUUUUAFFJS0AFIelLSHpQ ADpS0g6UtABRRRQAUUUUAFFFFABTR1NOpo6mgB1FFFABRRRQAUUUUAFFFFADT1FOpp6inUAF FFFABRRRQAUUUUAFIelLSHpQADpS0g6UtABRRRQAUUUUAFFFFABSDqaWkHU0ALRRRQAUUUUA FFFFABRRRQA09qdSHtS0AFFFFABRRRQAUUUUAVr66FrAX79hVK01VppBHIg57io9dkyUT8ao 2LAXSbuBTEdMn3adTI/uin0gQUUUUDCiiigAooooAKb/ABU6k70ALVDWB/oZ6/hV+snXJAIl TJyaAMI5rU0ez8x/OfoOlZmMkCun02HyrVR3PNMRapaKKQwooooAQ0tIaWgAooooAKKKKACi iigAoopKAEXpTqavSnUAFFFFABRRRQAUUUUAFNP3qdTT96gQ6iiigYUUUUAFFFFABRRRQAjd KWkbpS0AFFFFABRRRQAUUUUAFFFFADVp1NWnUAFFFFABRRRQAUUUUAFN/ip1IetAC0UUUAFF FFABRRRQAUUUUAI3SgdKD0oHSgBaKKKACiiigAooooAKKKKAGr1NOpq96dQAUUUUAFFFFABR RRQAU09RTqaeooAdRRRQAUUUUAFFFFABRRRQAh6UDpQelA6UALRRRQAUUUUAFFFFABRRRQA0 feNOpo+8adQJBRRRQMKKKKACiiigAprdqdTW7UAOooooAKKKKACiiigAooooASkXpS0i9KAH UUUUAFFFFABRRRQAUUUUAN/ip1N/ip1ABRRRQAUUUUAFFFFABTW6U6mv0FAMUUtIKWgAoooo AKKKKACiiigAooooAaOpp1Rltrc9KXzBTsK6H0UzzBRvFKwXQ+im7xSbxQFx9FM3j3o3j3os Fx9Ie1JvFNZ8YwM0wuiSimBx70bxSsFx9FN3CjeKAuOopu8Um8ZosFx9FN3ijeKAuK3SgdKa WGKA4xTsFx9FM3ilDg0guOopu8UbxQFx1FN3ijeKAuOopu8UbxQFwH3qWmb8N7Uu9adguh1F N3rS7xSC6HUU3eKN4oC46im7x60b19aAuOppo3Cmu4AosDY+imiRSOtLvX1oC6HUU3evrRuH rQFx1FN3r60b19aAuOopu9fWjevrQFxaB0pNw9aarjvQFySim7x60bh60DHUU3cPWjcPWgB1 FN3D1o3CgLjqKbuHrRuHrQFw706oy4DU7evrRYV0DDKke1cncKVnce9dZuGOtc1qKbbt/QnN MC/oUnyOnfrWxXPaPIEucHoRW/vX1oAdRTdw9aNw9aQx1I3SjcPWkZhigQvalpgcEdaXcvrQ Fx1FN3D1o3D1oGOopNw9aTcPWgDD1x8zqvoKzYk8yRVHUmr+tA/aA3XIqpZAfaY93TNMR0tr AsEKqBzipV6mhWGBg01WGTQBJRSbh60bh60hi0Um4etG4etAC0UmR60ZHrQAtFJuHrRketAB 3paYWAPNLuHrQK46ik3D1oyPWgYtFJketGR60ALRSbh60ZHrQAtIelGR60jEAUAKOlLTVYEU uR60ALRSZHrRketAC0UmR60ZHrQAtFJketGRQAtNHU0uaQEZPNAh1FJkUZFAxaKTI9aMigBa KTNGaAFopM0UAB6ilprEAilyKBC0UmaM0DFopKKAFopKKAFpD0ozQTxQADpS01SCOKWgBaKS igBaKSigBaKSigBaQdTRSA/NigB1FJmigBaKSigBaKKKACiikoAD2paaxxS0ALRRRQAUUUUA FFFFAGHriHzUYDqKzrc4nQnsa2NcQGFW7g1iAkEH0piOsiOYwRUlQWjb7dDkdKnpMEFFFFAw ooooAKKKKACk70tNyN1AA7BVLHoK5jULj7Rcsf4RwK29UuBDbEA/MeK5s+tAE9nCZrhUFdSi 7ECjsKydEt9oMp79K2KbEFFFFIYUUUUAIaWkNFAC0UUUAFFFFABRRRQAUUUUAIvSlpBS0AFF FFABRRRQAUUUUAFN/ip1NJG6gB1FFFABRRRQAUUUUAFFFFACN0paRulAoAWiiigAooooAKKK KACiiigBBS0gpaACiiigAooooAKKKKACk70tIetAC0UUUAFFFFABRRRQAUUUUAI3SgdKD0oH SgBaKKKACiiigAooooAKKSloAaO9Opq96dQAUUUUAFFFFABRRRQAUh6ilpp6igB1FFFABRRR QAUUUUAFFFFACHpQOlB6UDpQAtFFJQAtFFFABRRRQAUUUUANH3jTqaOpp1ABRRRQAUUUUAFF FFABTWp1NagB1FFFABRRRQAUUUUAFFFFACUi9KWhelAC0UUUAFFFFABRRRQAUUUUAN/ip1N/ ip1ABRRRQAUUUUAFFFFABTX6CnU1ulAmKKWkpaBhRRRQAUUUUAFFFFABRRRQAwKNxNOwKQdT S0CQYFGKKKBhRRRQAUUUUAFIw6UtIe1AC4ooooAKKWkoAMUYFFFABRRS0AIRxSKBilPShego EGBRgUtJQMMCjAoooAMCjApaKAEwKMD0oooAbtBbpS7R6UD7xpaYg2j0owPSiikMMD0owPSi igAwPSjA9KKKADAprgYp1NY0CYoUAdKXA9KBRQAbR6UYHpS0lAwwPSjaPSiigAwPSjaPSiig AwPSmqoxTu1Ih4oELtHpRgelFFAwwPSk2j0paKAE2j0o2j0paKAE2j0o2j0paKAGFQWFO2r6 UZ+alpishNo9Kw9aiCTKwGARW7WbrUYa2DY5U0IDFtX2XCN711SAMoOK5HowNdPYS+baofag CxtHpRtHpS0UgsJtHpSMoxTqRjxQAgjXHSl2L6UoPFGaAsJsX0o2j0pc0ZoCwm1fSjaPSloz QMxNcjw6MOnSqFlzdR+mava62XRfSs+yyLlD70xHVBRjpSKoyeKcp+UU1TyaAsh20elG0elL mikMTaPSjaPSlzRmgBNo9KNo9KXNFArCbB6UbR6UuaM0BYYyAkUuxfSlzzS07hZCbF9KNo9K WikFhNo9KNg9KXNFAWE2D0o2ClzRQFhNg9KQqMdKdQTxQFkNCDFLsX0pR0ooCyE2D0o2L6U6 koCwmwelG0UtFAWE2ijYKdSUBYTaKaEGTT6RTyaYWDYPSk2LTqKQWQmwUbBS0tAWG7BRsFOp KAsJsFAQCnUUBYjZRxS7BSt1FLTCw3YKXaKdRSCw0IBRtFOooCw3aKNgp1FAWGbBS7RiloPS gLDVQYo2D3pw6UUXCwmwUbBTqSgLCbRRsFOpKAsJsFG0UtLQFhu0ZpuwFqkpoPJoCyE2CjYP en0UXCw3aKTYKfRQFhuwepo2D3p1FAWG7Pc0bR6mnUUBYYy570bBjqaVj0p1AWGbB6ml2D1N LRQFhuweppdg9TTqKAsM2e5o2D1NPooCxQ1SLNm5BPHNc4e1dTfrvtHAPauXI55pgdHpqhrR DntVvZ7mqOitm0x6GtGhsEhu33NJs9zT6KQWG7Pc0bPc0tLQFhuz3NIU9zT6SgLDdnuaaUy3 WpKimlEaMx7CmgaRhaxIGuAgPSqcSeZMqAdTRcSeZKzHuau6NGHutx6AUAbcEAiiVV44qTZ7 mnUtK4WG7Pc0mz3NPpKAsN2e5o2e5p9FAWI3TI6mlEfHU0ppadwsN2e5o2e5p9FILDCue5o2 e5p9FAWG7fc0bfc06igLDdvuaNvHU06koCwxUPrS7fc04dKWncLDNnuaXb7mlpaQWGbPc0u3 3NOooCw3b7mjb7mnUUBYbt9zTGTLDmpaaT81O4NITZ7mjZ7mn0UrhYZt9zS7fc06igLDdvua NvuadRQFhu33NJt9zT6SgLDHXI6mlCYHU0rHApadwsribfc0bfc06ikFhu33NG33NOooCwzZ /tGjb7mnUtAWGbD/AHjS7fc06koCwxUOTk0uz3NKpzmnU7gkM2n1NGz3NPopBYZs9zRs9zTq WgLDdvuaTZ7mn0UBYbtPqaayEkc1JTT96ncLCbD/AHjRsOfvGn0UgsN2n1NG0+pp1FAWG7fc 0m05+8afRQFhu0+tG0+tOooCwxlJHWkVWxy1ObpSjpTC2om0+ppNp/vGn0UgsM2n+9RtPqaf RQFhu0+tJtP940+igLDNp/vGlCn1NOooCxEEOTzTtp/vUqnrS0wshNp9TRtPrTqKQWGbT/eo 2n+8adRQFhu0/wB40bT/AHjTqKAsJtP96mspOOafSHqKYWE2nH3qNp/vU6ikFhu0/wB6gqf7 1OooCw3af71G0/3qdRQFhu1v71G1v71OooCw0g460iqcdaeelA6UwsN2t/eoCsP4qfSUgsN2 n+9RtP8Aep1FAWG7T/eow3rTqKAsN2t/eo2n+9TqKAsR7SWPzU7a396lH3jS0wSG7W/vUbW/ vU6ikFhu1v71GG9adRQFhu1v71G1v71PooCwza396kdTgc0+kamDQgVv71G1v71PopBYZtPr Rtb+9TqKAsN2n+9Rtb+9T6KAsM2n+9S7T/epaKAsNwcdaRVbHWn0i9KYWE2t/eo2t/ep1FIL Ddrf3qMN/ep1FAWG4b+9S4PrS0UBYbtPrRhv71OooCwwqS3Bpdp/vUv8VLTCw0q396ja396n UUgsN2t/epdp9aWigLDdp9aXB9aWigLDdrf3qRgeOafTX6UwaHDpS0gpaQwooooAKKKKACii igAooooAaOpp1NHU06gAooooAKKKKACiiigApp7U6mt2oAdRRRQAUUUUAFFFFABRRRQAh6UD pQelA6UALRRRQAUUUUAFFFFABRRRQA0feNOpo+9TqACiiigAooooAKKKKACmt0p1NbtQDHUU UUAFFFFABRRRQAUUUUAJSL0paRelADqKKKACiiigAooooAKKKKAG/wAVOpv8dLQAtV71N9q4 wDxT0njdiquCw7U6XmNvpQByB4Nb2hsTAwJ4B4FYUvErfU1oaLMVnKdjQB0NFJS0AFNbpTqR ulAAOlFA6UUALRRRQAUhOBk0tVNRm8m1Y56jFAGJq0wluTtOQOKTSo/Mu1zyBzVMnJ5rY0NM FpDQgNrtTU6mmPcwxglpFGPem21zFPny3BoAsUUUUAFFFFABRRRQAlFLRQAnelpO9LQAUUUU AFFFFACUtFFABSHpS0h6UAA6UtIOlLQAUUUUAFFFFABRRRQAU1epp1NXqaAHUlLRQAUUUUAF FFFABRRRQA09RS0h6inUAFFFFABRRRQAUUUUAFIelLSHpQADpS0g6UtABRRRQAUUUUAFFFFA BTR1NOpo6mgB1FFFABSUtFABRRRQAUUUUANPanUh7UtABRRRQAUUUUAFFFFAEc67oXHqK5OQ YYj3rr2GVNcpdjbcOvoaYGtoTAxOvcGtasPQWHmOPatykAUUUUAFFFFABRRRQAlZ+rSBIGHr V6WQRoWY4Arm9QuvtEhx0FMTKZNbWhREK0h6GsVQWYBeSa6uyi8q2RcYOOaALFFFFIYUlLRQ AUUUUANaloPaloAKKKKAEpaKKACiiigApKWigBF6UtIOlLQAlLRRQAUUUUAFFFFABTf4qdTf 46BMdRRRQMKKKKACiiigApKWigBrDIpaD0paACiiigAooooASilooAKSlooAao606kFLQAUU UUAJS0UUAFFFFABTf4qdSfxUALRRRQAlLRRQAUUUUAFFFFADW6Uo6UHpQOlAC0UUUAFFFFAB RRRQAlFLRQA1RyadTV706gApKWigAooooASloooASkPUU6kPUUALSUtFABSUtFACUtFFACUt FFACHpQvSg9KB0oAKKWigBKWiigBKKWigApKWigBgHzGnUg+8adQJBRRRQMKSlooASloooAS kYdKdTW7UALRS0UAJS0UUAFJS0UAFFFFACHpSKOKU0DpQAtFFFABSUtFABRRRQAUUUUAN/ip aT+KnUCCiiigYUUUUAFFFFABTH6Cn01u1AmKKWkpaBhRRRQAUUUUAFFFFABRRRQA0feNOpg+ 8afQJBRRRQMKKKKACiiigAprdRTqa3UUAOooooAKKKKACiiigAooooAQ9KF6Cg9KB0oAWiii gAooooAKKKKACiiigBo+8adTR1p1ABRRRQAUUUUAFFFFABTW6U6mP0oEOpaQUtAwooooAKKK KACiiigBKRelLSL0oAdRRRQAUUUUAFFFFABRRRQAw8NVCfVIQ7QjOemaj1e8aEbI2wxrCXLy DPJJoBDjJJHKSGIIPWrsesXAGGww960l02Ce3XcCGx1rNu9Klg5Ub19RTsFyjI++QtjGTmn2 sjpOpTg5qIqQ3pUkEphcMoGR60gOtiJMak9cU+si21qMgCZdp9R0rQhu4Zv9XIDQBPTW6UtI 3SgBR0paQdKWgAooooAKwtbmYuqD7tblY+ueUYxhhvB6UAYlSrcPEm1GI+lQmg80AOZ2Y5JJ NWLCYw3SEHAJwaqAe9W7DZ9rTeMjNAHUodyg06kUAKMdKWgAooooAKKKKAEpaKKAE/ipab/E KdQAUUUUAFFFFABRRRQAUh6UtIelAAOlLSDpS0AFFFFABRRRQAUUUUAFNXqadTR1NADqKKKA CiiigAooooAKKKKAGnqKdTT1FOoAKKKKACiiigAooooAKQ9KKD0oAB0paQdKWgAooooAKKKK ACiiigApB1NLTR1NADqKKKACiiigAooooAKKKKAEPUUtIeopaACiiigAooooAKKKa7rGuXYA e9ADLmTyoGb0FcpK5eRmPUmtrUb23kgKJL83tWCxGfWgDS0V9t3j1FdFXO6NEWud+3gd66Kg AooooAKKKKACiikPSgDE1q5feI1bA71kZzWnrEEgm8zqpqjDavMflHHvTsK5NpkStLvc4C85 rQn1kRttjTOO9Zs7CCPykYZPXFVDSY0ag1qcNkqpHpW3bTrcQq6nrXI9DWhpl59nmCsfkagD pKKarBlBByDTqACiiigBD2paRu1LQAUUUUAFFFFABRRRQAUUUUAIOlLSDpS0AFFFFABRRRQA UUUUAFNP3qdTf4qAHUUUUAFFFFABRRRQAUUUUAI3SlpG6UtABRRRQAUUUUAFFFFABRRRQAi0 tIKWgAooooAKKKKACiiigApP4qWmn7woAdRRRQAUUUUAFFFFABRRRQAjdKB0pG6Uo6UALRRR QAUUUUAFFFFABRRRQA0d6dTV706gAooooAKKKKACiiigApD1FLTT1FADqKKKACiiigAooooA KKKKAEPSgdKD0oHSgBaKKKACiiigAooooAKKKKAGj7xp1NH3jTqBIKKKKBhRRRQAUUUUAFNb tTqa3agB1FFFABRRRQAUUUUAFFFFACGgdKDQvSgBaKKKACiiigAooooAKKKKAG/x06m/xU6g AooooAKKKKACiiigApr9BTqa/SgTFpaSloGFFFFABRRRQAUUUUAFFFFADR9406mjqadQAUUU UAFFFFABRRRQAUh7UtIe1AC0UUUAFFFFABRRSUALRRRQAh6UDpQelA6UALRRRQAUUlLQAUUU UAFFFFADR9406kHWloAKKKKACiiigAooooAKY/QU+mt0oELS0lLQMKKKKACiiigAooooAQ0i 9KWkXpQA6iiigAooooAKKSigBagurhbaEu1THgVz+s3Xmy+UvRetAFK6na4lLt1Nael6aGAm lH0FZlpEZp1QDvXVxrsjCjsKYDgABgdKKWikBSu9OhueSNreorGu9MmgyVG5fUV0tBAIwadx HFkEdadHK6MCpINdDfaWk6logFesibTbmI8oT9KLDubGl3v2lNr/AHxV9ulZ2j2zQxFnGGNa LdKAFHSlpB0paQCVBcXsNv8A6xwD6UXlx5EDN37Vy00zzSF3OSaANO81gyArBlR6mspnLnLM SaQZNXbPTZrhlLKVT1osDKsMLzyBEXJNbVtoyBczncfQVftrSK2XCLz61Yp7CMa+0pEgLQg7 hWOCVYY4IrsGGRiuZ1OAw3BIHBo3DY29OuRcW4IzkcHNXK5zSbgxThC2FauipDFooooAKKKK ACikpaAG/wAVOpp+9TqACiiigAooooASloooAKQ9KWkPSgAHSlpB0paACiiigAooooAKKKKA Cmr1NOpq9TQA6iiigAooooAKKKKACiiigBp6inU09RTqACiiigAooooAKKKKACkPSlpD0oAB 0paQdKWgAooooAKKKKACiiigApo6mnUg60ALRRRQAUUUUAFFFFABRRRQAh6ilpp7U6gAoooo AKKKKAErn9Wu2kmaIN8grYvZ1ggZmNctI29iT3oAaeabzWpp2mC5jLyZC9sVNPoeATC+fY07 BczrW8mtj+7bj0NakGtqRiVMe4rKmtZofvoQPWocYNJoLnTR6rbSMFDY+tW0lSQZRgfpXHHj vVvTriSK6QAnBOCKQHU0Ug5ApaYBSE4FFYmq6jIHMMYK+poA1Z5IVjPmldvvWFe34clLcBU9 R3qi0jv95ifrSKpY4AJNAWEPJ561ZsrZpp1GzIq5Y6S0mHnBA9K2ooUhUKigCnsIxtS08RRi SIdOtZRyDXYOgdCrdDXL39ube5ZccdRRuBq6NeB4/JY/MOlatchBK0MiuvUGuptZ1uIVdT9a QyeiiigBG7UtNbtTqACiiigAooooAKKKKACiikoAB0paQdKWgAooooAKKKKACiiigApv8VOp v8VADqKKKACiiigAooooAKKKKAEbpRSN0paAFooooAKKKKACiiigAooooAQUtIKWgAooooAK KKKACiiigApp+8KdSd6AFooooAKKKKACiiigAooooAa33aUdKG6UDpQAtFFFABRRRQAUUUUA FFFFADV706mr3p1ABRRRQAUUUUAFFFFABTT1FOpp6igB1FFFABRRRQAUUUUAFFFFACHpQOlB 6UDpQAtFFFABRRRQAUUUUAFFFFADR9406mj7xp1AkFFFFAwooooAKKKKACmt2p1NbtQA6iii gAooooAKKKKACiiigBDQvSg0L0oAWiiigAooooAKKKKACiiigBv8VOpv8dOoAKKKKACiiigA ooooAKa3QU6mv2oExaWkpaBhRRRQAUUUUAFFFFABRRRQAwH5iKdUbJubjil8v/aNMm7H0Uzy /wDaNHl/7RoHdj6KZ5fP3jS+X/tGgNR1FM8v/aNHl/7RoDUfSE9Kb5f+0aRo+nJoC7JKKYI/ 9o0bP9o0BdklFM2f7Ro2f7RoC7HUU3Z/tGk8v/aNAaj6KZ5f+0aXy/8AaNAajj0oHSmFDj7x oVOPvGgLskoqPy/9o0bD/eNAXY+imeWf7xoCEfxGgLskoqPYf7xpdh/vGgLsdRTNh/vGlCH+ 8aAuxcjdilqIxktwad5Z/vGiyEmx9FMCH+8aXYf7xoHdjqKZsP8Aeo2N/eoC7H0UzYf7xpdh /vGgLjqRu1IEb+8abIpI60A3oSUVGqMB96l2N/eNFguSUVHsb+9Rsb+9SC5JRTNrf3qTY396 gLklFM2t/epNjZ+/QFx9IpyKaVb+9TVVs8HFOwrk1FR7X/vUbW/vUh3JKKZtb+9SbX/vUBcf RTNrf3qjlfyk3O+BTsFxuoS+VauQecVyxJZu5JNXtQ1Az5RfuiodNi866UenNIZraTaeUgd1 +Y9K1KgKNuABqTa/96myUySkpm1/71G1/wC9QO4+imbXz96ja/8AeoC4+snUtSMR8uE/MOpq 7dSGGIsz4rmJ5TLMzE5JNIEy1bahPHMCzllJ5FdGr7ow3rXPadZNO4bGFHrW8UYLjPFOwNkw 6UVGqvjrRiTHUUWC5S1a3kmgyh6c4rA8qTP3CK6tg+05Irnb+5aaUqOAvFGgJmhpenKoEsgB J6CtcAAYFc9p9+8bLG7fLW6u8gHdxRuBLRUeH/vCjD+tKwXH1R1C1+0W7bfvDmrYD9yKYFfJ wapCbOWwUf0Irp7CcT2ysDzjBrG1W2MMu/s1GlXTRyiIdG9aTGdFRUf7zHUUuH9RSC46im4f 1FGH9RQFx1LUeJPUUASeop2C47vTqhYPkYIp2JPUUWFckoqPD+opcP6ilYdx9FMw/qKPn9RQ Fx9FR/vPaj957U7BcfQelN+f2pG3Y5IoC48dKKjTfjtil/ee1FguPopvz+1Hz+1ILjqKb8/t R8/tQFx1FN+f2o+f2oC46kHU0nz+1NG/PGKYXJKKb8/tSfPntSC4+im/P7UfP7UBcfRTPn9q Pn9qAuPoph3+1Hz+1AXFPUU6oZN/HSnAvjoKdhXJKKjy/oKXL+gpDuPopnz+goy/oKAuPopm X9KPn9BQFx1B6UzL56Cg78dBRYLjx0oqNS+Ogp2X9BTsFx9FMy/pRl/QUguPpKbl/QUhMnoK LBckopgL9wKMv6CgLj6QdaaC3pTcvuOBTsFyWio8yf3RS5fHQUrBcfSUzL/3RQS+eAKLBcko pmX/ALooy/8AdoC4+imEt/doy392gLjj1FLULs3HGKcGfHK07BcfRTNz/wB2jc+Pu0WC5JTJ ZBHGznsKqXOoJbfewT6A1RuNWSaJk2HmkFyhd3klw5yxxngVXUFnAHeg4zxWlplk7uspHyih IGzatI/LtkXGOKmPSmBn6baCzY6U7BcNqsuGUEehrH1aO3iYYiIY+nArUMrKhJHArnb24+0T sx6dBRqJNMrEVo6XYySTLKQQo5zVa0tXuXwo4FdHAjRRKgXoKLDuTjgUtM3P/do3N/dpBcce lctqQIvHzzXTZf8Au1kanYO5M6g57inYLmNWrosMTuWYZYdM1lkYNXtJuBDPtwPm4pIGdJRU e9+y0u5/7tOwXH1ha7tLrg81tbm/u1i60MuCRg0WC5k1saLdMD5OBisj05qW3na3fenWkM62 lrDXXCAMxgnvT/7dX/nn+tAGu3anViyayrL8q4PvUsGsI52uMe9AjUoqJJjIMqMin7m/u0WC 4+io9zf3aNzf3aYXJKKZub+7Rub+7SC4+kpu5v7tGW/u0BccOlLUas3pRvbP3KdguSUVHub+ 7S7m/u0BcfRTNzf3aTc392kFx9FN3N/do3N/dphcfTf4qbub+7TWZweFosJtE1FRh2/uUbm/ u0rDuSUUzc392jc2fu0BcdRTdx/u0bm/u0BcdRTdzf3aAx/umgLjj0opjMcdKA7Y+7TC4+im b2/uml3H+7SC46im7j/do3H+7QFx1FN3H+6aNx/u0BcdRTdx/umjcf7tAXHCio1c5+7Tt5/u mnYLodRTdzf3aNx/u0guOopu4/3TRuOfumgLjqKbvP8AdNG4/wB00BcdSfxUm4/3TSFmzwKY XH0U3ef7tG8/3TQFx9FM3H+7RuP900rBcdRTd5/umjef7tAXHUU3ef7po3n+6aAuObpQOlMZ jjpQrnH3TTsF9SSimbz/AHTRvP8AdNILj6KZvP8AdNG84+6aAuPopm8/3TRvP900BcfRUZc/ 3TS7z/dNFguhV706olc5Pymnb/8AZNOwJofRTN5/umjef7ppBdD6KZuP900bz/dNAXH0Uzef 7po3/wCyaLBdD6Q9RTd/+yaRmOQcU7Bckopm8/3TRvP900rBcfRTN/8Asmjef7poC6H0Uzfx 900bvY0BdD6KZv8A9k0b/wDZNFguOPSgdKaX+XoaasmR9007BdEtFM3/AOyaQSc/dNKwXRJR TN/+yaN/+yaLBdD6KZv/ANk0B/8AZNFguh9FM3/7Jo3+xosFxR9406ofMIf7pp3mf7Jp2Emi SimeZ7GjzPY0rDuh9FM8z2NHmexosF0Popnmf7Jo3+xosF0PprdqTf7Gms/HQ07A2iWioxJ/ sml8z/ZNFguh9FM3/wCyaN/+yaVguh9FM3/7Jo3+xosF0Popm/8A2TRv/wBk0WC6HUL0ppfj oaasnHQ07Bclopnmf7Jo3+xpWC6H0Uzf/smjzP8AZNFguh9FM8z/AGTR5nsaLBdD6KZ5nsaN /saLBdC/xU6ojJhunFO8z/ZNOwXQ+imeZ7GjzP8AZNKwXQ+imb/Y0b/Y0WC6H0Uzf/smjf8A 7JosFx9NftSb/Y01nzjg07CbRJS0gpaRQUUUUAFFFFABRRRQAUUUUANHU06mjqadQAUUUUAF FFFABRRRQAUh7UtNPagB1FFFABRRRQAUUUUAFFFFACHpQOlDdKB0oAWiiigAooooAKKKKACi iigBo+9TqaPvU6gAooooAKKKKACiiigApr9BTqa/agQ6ikpaBhRRRQAUUUUAFFFFACGkXpSm kTpQIdRRSUDI5riKAZkYLVKTWbdT8u5voKztYnMlzsxgLWdzQButrkf8MbGqF/qLXShQu0Cq VG0noKAGmr2kD/S1qsltK+MRsc+1bml2DQfPIBk07CuaI+9T6b/FTqQwooooASlpKgu7lbaE ux57CgChrdygi8oHLVj2kDXE4RR+dNnlaeVnbqTWxolsAhmPU8ChAalvCsMQRR0p7dKdTW6U AKOlLSDpS0AIeRXM6nD5Vy2AcHmumqtf2y3EBGPmHSmgOXj4kUk45611tu4eFSDnjrXJyI0b lW4Ira0W63J5LHkdKQGvRRRQAUxO9Opq96BFfUYBPbMO45FcyrNHICOoNdew3KR61y99CYLl lP1pjOispvPtlfvjmrFc/pF6Im8pz8p6VvggjI6UgFooooAKKKKAG/xU6m/xU6gAooooAKKK KACiiigApD0paQ9KAAdKWkHSloAKKKKACiiigAooooAKaOpp1NHU0AOooooAKKKKACiiigAo oooAaRyKdTT1FOoAKKKKACiiigAooooAKQ0tIaAAdKWkHSloAKKKKACiiigAooooAKaOpp1I OpoAWiiigAooooAKKKKACiiigBrdqZLPHCMyOFHvTpDgZrmdQmaW6fJ4BwKANWfWIk4jBc+t Z8+q3EuQrbR7VQ5zT0ieQ4VST7UWC412Zjljk0scTyNtQEk1p2WkO5DTgqvpWxFbxRDCIB+F MRm22joYwZchq1IoliQKowBT6Wi47BUc8qQxl3OAKkrA1mdzL5efl9KQE15qkTQFIidxrG6t 6001YsYvPuUTtnmgDc0iAxWwLDBbmtCmqoVQB0FOoAKKKKACmuoZSD0NOooA5vU7L7PLlQSj c1RVtpBHBrpdTRHtG39ulcwaYHSaXd+dFtkYbhWhXHwyMjgqxFdTaSeZbqxPOKQE9Qz20VwM SIDU1FAHM6jZm3l+VTsPTiqJB9K7JkVxhgCPeoXs7dzlolJ+lPRiOSI70V0dxa2VuhZ4xisa 9MBkH2dcCloMq9KVTzR1PStCw05rn5mBVf50JBc0tH3mDJJx6GtKo4o1ijCjgCmG7gWTYZFD fWgCeikBDDIORS0AFFFFABRRRQAg6UtIOlLQAUUUUAFFFFABRRRQAU3HzU6m/wAVADqKKKAC iiigAooooAKKKKAEbpRQ3SloAKKKKACiiigAooooAKKKKAEFLSCloAKKKKACiiigAooooAKT vS00/eFADqKKKACiiigAooooAKKKKAEbpQOlDdKB0oAWiiigAooooAKKKKACiiigBq96dTV7 06gAooooAKKKKACiiigApp6inUh6igBaKKKACiiigAooooAKKKKAEPSgdKD0oHSgBaKKKACi iigAooooAKKKKAGgfMadTR1NOoAKKKKACiiigAooooAKa3anU1u1ADqKKKACiiigAooooAKK KKAEoXpQelC9KAFooooAKKKKACiiigAooooAbj5qWk/ip1AhKWiigYUUUUAFFFFABTW7U6mt QDFpaSloAKKKKACiiigAooooAKKKKAGj7xp1NHU06gAooooAKKKKACiiigApp6inU09RQA6i iigAooooAKKKKACiiigBD0oHSg9KB0oAWiiigAooooAKKKKACiiigBo606mj71OoAKKKKACi iigAooooAKY/QU+mv0oELS0lLQMKKKKACiiigAooooAQ0idKU9KROlAh1ULrU47ebyypJ71f rn9YtmSbzeqtQMstBbamd6NtbvUkGjwJ/rPnNYsE728oZDzW5batDKAJDsb3p3CxYSxtk6RL Txawg5Ea5+lSK6uuVOQaWi7FYQKB0Ap1FFIY3+KnU3+OnUAFFFFADWYKCT0rnNWuvOnIU5UV uX0nl2ztx071yjEsc+tAEtpC086oO9dXCgjjCgYwKy9DttqGVgOelbFABTW6U6mt0oBijpS0 g6UtABSUtFAGJrVsARKo+tZltM0Mqspxg11U8YliZD0Irk51MUrJ6GmI6yGQSRqwOcipK5e0 1Ka3XaCCvoa3bG8W6i3dG7ikMt0xOpp1NTqaBD6wNcUecpGM1v1ha3G5kDbDtH8VAzJBKnIP NaVjqxgj2SgsB0NZmPWkoA3jrke3/VtmpIdZhfh/l+tc8elApAdjHIsqBkOQafWVokrNAUPQ Vq0wG/xU6mn7wp1ABRRRQAUUUUAFFFFABSN0paRulAAOlLSDpS0AFFFFABRRRQAUUUUAFNHU 06mr1NADqKKKACiiigAooooAKKKKAGnqKdTT1FOoAKKKKACiiigAooooAKQ9KWkPSgAHSlpB 0paACiiigAooooAKKKKACkHU0tNHU0AOooooAKKKKACiiigAooooAguziInOOOtctKcyE571 0moxySQFYsZrnntpk5eNgPpT6C6jrZ7cSfv1Yj2retJ7QqBCUFc0V55oGR0NGoHYgg9KWuWh vriAja5I9DzV6LXGwBJGD9DSGbdFUItWtnHLbT71YS6gcArKpz70AT1zerptuic9a6MEHoay NchG1ZOPSgDDxWzotkVPnN07Vj45rptLlWS0UDGRwaALtFFFABRRRQAUUUUAQ3KB4GBGeK5W ddshB45rrXZVX5iB9a5e/wD+Ph+mM0AVl611WnpstV9xXKxMFcE8gGugj1i3WMDByB0AoA1K Y8iJ95gPqaw7jV5XysQCj171nyyvIcuxb6mgDoJtVt48gHcfaqM2syE/u1AHvWUKURu3RSRR YLj57h5mLSMT7VEAS2F5q1Fp1zMeIyB6mtax0pYCHlIZvT0p2Fcrabp+CJZl47A1tqABgDAp COlLQ2CM/WLhoYAEYgtxxXOliTkk5rq7q1juk2yD6GsK80uW3JKAsnqKVh3Cw1F4JAJGJj9P SuijdZEDKcg1x+MVoadfm3cI7Hyz+lAHR0U1HWRQykEGnUAFJS0UAIOlLSL0paACikpaACii igAooooAKafvU6mn71ADqKKKACiiigAooooAKKKKAEbpS0jdKWgAooooAKKKKACiiigAoooo AatOpBS0AFFFFABRRRQAUUUUAFJ/FS03+KgB1FFFABRRRQAUUUUAFFFFADW6Uo6UN0oHSgBa KKKACiiigAooooAKKKKAGr3p1NXvTqACiiigAooooAKKKKACmnqKdTT1FADqKKKACiiigAoo ooAKKKKAEPSgdKD0oHSgBaKKKACiiigAooooAKKKKAGjqadTR1NOoAKKKKACiiigAooooAKa 3anU1u1ADqKKKACiiigAooooAKKKKAENC9KD0oXpQAtFFFABRRRQAUUUUAFFFFADf4qdTf4q dQAUUUUAFFFFABRRRQAUx+1Ppr9qBMdRSUtAwooooAKKKKACiiigAooooAaOpp1NHU06gAoo ooAKKKKACiiigApp6inU1uooAdRRRQAUUUUAFFFFABRRRQAh6UDpQ3ShfuigBaKKKACiiigA ooooAKKKKAGjrTqaPvU6gAooooAKKKKACiiigAprdqdTX6UAOopBS0AFFFFABRRRQAVFNMkE ZeQ4FS1n6yFNod3XtQBZt7uK5U+U2SO1Sp0rmdNkaO7XaTg8GuljOVpi6j6jliSZCjjINSUU hnPX2lPCS8WWX+VZxBB5rsSM9ap3Wmw3AJxtb1FPRiMK3v57f7rZX0NatvrMTACUFT69qzp9 MniY4QsvqKqOrIdp4+tFh3OsjuIpR8kin8akrjlZkOQSD7Vet9VniwG+dfekB0P8dPrNg1WC RvnOw+9X0kSQZRgR7UAPooooAgvI1kgdWGRiuUYAMQOxrrLoboHA9K5RvvEHtTA6PSSDZrtG KvVS0sg2aYq7SAKa/SnU1ulAMUdKWkHSloAKKSloARuhrldSA+1ue9dUelcrqJH2t9o70AVh z3re0SNliLEjBrItbWS5YCNc+prprWAQQqg7UwJqanU06mp3pCH0ySNZVKuAQexoklSJdzsF HvVC41eFARH85oGE+n2USl3UKPrWJdPEZP3KYUfrTrq6luXJduOwqFI2kICgkntT1FoMPNOi ieRwqAk1rWejkkNOTj0rWitoYfuIAfWgCHTbY29uAw+Y8mrlJS0hjT94U6mn71OoEFFFFAwo oooAKKKKACkbpS0h6UAA6UtIOlLQAUUUUAFFFFABRRRQAU0dTTqaOpoAdRRRQAUUUUAFFFFA BRRRQA09RTqaeop1ABRRRQAUUUUAFFFFABSHpS0h6UAA6UtIOlLQAUUUUAFFFFABRRRQAU0d TTqaOpoAdRRRQAUUUUAFFFFABRRUEt3DCpLOOOwoAlbqKUgEYIzUccqTIrocqaloEVZ7GCYE FAD6is+XRSATFJk+hFbVFO4WOWk0+5iJ3Rkj1FVyuD0I+tdhUMlrBL9+NT+FFwOUxQCe1dFJ pFs54DL9DVWXRD/yyk/A0aAZ8F5PD9xz+PNTzam1xCY5lHPcUyXTbmLqmQPSqrow+8CKLBcY TVqwuXhnUKTtJ5HrUKQSycohI9hWjp2mSGQSTLtUdj3osFzdU5UGlpAMDFLSGFFFFABSGlpD 0oAxNZum3iJTgDk1jO2RyeavauD9sbNUAOe1ABjApVyafHE8rBVXJrd07TFjQPOgLehosFzG jt5ZGG1Cc1fh0aZ+ZWCD061uqiqMKoA9qdTuKxQg0m3i5Ybz6mrixogwqgD2FPopXHYSlooo AQ9qWkPaloAKQgEYPSlooAwtT00oTLCuV7j0rKIK9a7EjI5rOvNKjmBaL5X/AENMRl2N89s4 GSU7iuiglWaMOnQ1hJpFwXAYAD1zW1a24toRGDnFKw7k9JS0lAAvSlpB0paACiiigAooooAK KKKAEPSk/ip1N/ioAdRRRQAUUUUAFFFFABRRRQAhpaa3SloAWiiigAooooAKKKKACiiigBBS 0gpaACiiigAooooAKKKKACm/xU6m/wAVADqKKKACiiigAooooAKKKKAEbpQOlDdKB0oAWiii gAooooAKKKKACiiigBq96dTV706gAooooAKKKKACiiigApp6inU09RQA6iiigAooooAKKKKA CiiigBD0oHSg9KB0oAWiiigAooooAKKKKACiiigBo+8adTR9406gAooooAKKKKACiiigAprd qdTW7UAOooooAKKKKACiiigAooooAQ9KF6UGhelAC0UUUAFFFFABRRRQAUUUUAN/ip1N/ip1 ABRRRQAUUUUAFFFFABTW7U6mP0FAmOFLSCloGFFFFABRRRQAUUUUAFFFFADR1NOpo6mnUAJS 0UUAFFFFABSUtFACUjHkU6mntQAtLRRQAUUUUAFFFFABRRRQA1vu0L0FKelA6UALSUtFACUU tFACUtFFACUUtFADB940+kHWloAKSlooAKSlooAKSlooAKZJ0FPprUCYoopaKBiUUtFACUUt FADJJBGhZuAK5q/vGupjydg6CtfWpGS1wvQnBNc+il2CjkmgC7pVsZZw/OFroY/u1BY2y28A AGCRzVhelMQtFLRSGJRS0UAIarz2UE+d8Yye461ZooAxp9FHWJyD6Gs2e0ngPzoR74rq6QgM MEZp3FY47mpYbmWA5jcj27Vv3Onwz8ABT6ise706W3JONyeoosFzQstWWTCzkKfWtNXVxlTk Vx54q1a301sQFOV9DSGb93dJbpl+9czO4klZlHBOanvb03RUkYxVXNAG3ocw2NGTyK165vSP MN2NvTvXSUAFNc8U+mt0oAUdKKO1LQAlFLUczFImZRkgdKAIL+6W3hbJwxHFcy7M7knkk1Ld 3Mk8pMnbt6VDC4SUMRkDtQB0mlQiK1XjBPJq6SB1rCfWm2BYowPc1Smvrib70h+g4oA6Ge/t 4PvOM+g5rKuNWkJIh+UetZmcnk1JHBJK2EUtTSELLPJNy7lvrTApPStS30ZyQZmAHoK1ILKC AfIgz6mjYDDttMmnwxG1fU1t2tpFbIAqjPc1YxS0XCwlFLSUhle8u0tY9x5PYUlleJdR7hwe 4rE1aYyXRXn5eKl0Ld9obGcY5oA3j94UtJ/FTqACiiigAooooASloooASkJ4p1IelAAOlLSD pS0AFFFFACUtFFABRRRQAU1epp1NA5NAC0tFFABRRRQAUUUUAFFFFADW6ilpD1FOoAKKKKAC iiigAooooASg9KWkNAAOlLSDpS0AFFFFABSUtJQAUtFFABTQeTTqQdTQAtFFFABRRRQAUUUj HapPpQBn6reiCIxqfnb0rnyzN1qe9lM1y79s8VJptv59woYZUcmmgNfTVZLSMNV6mhQoAAwB T6GIKKKKQwooooAKKKKAEqOWCKVSHRT+FS0hoAjhjSNNqKAPapCQOvFIvSsnWbl4ysSHGetM Ea29c43DNLXJJK6uGDnIPrXU27F4EYnJIpAS0UUUAFITxS0h6UAcvqbFrtsjmqyLlgAMk1Y1 LP22TPrRYY+1xggYzTEb9nbxxRKQgDY5q1QBxS0hhSUtFABSUtJQAtFJS0ANbtTqaRS0ALRS UUAFFFFAC0UUUAFISBVa9vFtY8nluwrAudQmnf7xUegoA6dCCODS1z2m33ky7ZGLBq6BSGAI 70ALmlpMUUALRSUUAFLSUUAFJ/FS0mPmoEx1FJS0DCiiigAooooAKKKKAGt0p1IelLQAUUUU AFFFFACUtFJQAtJS0lACL3p1NWnUAFFFFACUtFFABRRRQAU3+KnU3HzUAOooooAKKKKACiii gAooooARulA6UN0oHSgBaKKKACiiigAooooAKKSloAavU06mr1NOoAKKKKACikooAKWikoAW mnqKWkI5FADqKKKACiiigAooooAKKKKAEPSgdBQelAHFAC0lLSUALRRSUALRSUUALRRSUAIP vGnUwfeNPoEgooooGFFFFABRRRQAU1u1OprDpQDHUUlLQAUUUUAFFJS0AFFFJQAUi9KU9KRR gUAOopKKAFopKKAFooooAKKKSgBP4qdTcfNS0ALRRSUALRRSUALRSUtABTH7U6muOlAmOFLS CloGFFFFABRRRQAUUUUAFFFFAETMQ/HNO3N/dpQOTS0xWG7m/u0bm9KfRSCwzc3pS5b0paKA sN3N/dpct/dpaKAG5b+7SMTxxUlNPamFhAzf3aNzf3afRSCwzLf3aXcf7tLRQA3c392jc392 n0UBYZuP92l3H+7S0UANLHHSkVjjpTz0oXoKYWG7j/do3H+7TqKQDdx/u0bj/dp1FACbj6Um 4/3afRQAzcf7ppdx9KdRQBCzkN0p28/3TTsfNS0xWYzef7ppd59DTqWgdhm4/wB00bj/AHTT 6KQWGbj6Gl3H0NOooAZuPoaRm46VJTW6UwY0OcfdNLuP9006lpBZjNx/umjec/dNPooAbu9j SB+fumn0UAQXEazxlHUkGqlvp0cE/mAFvQHtWjRTuFhu72NIr84wafSKAKA1E3/7Jo3+xp9F IBm/2NG/2NPooAZu9jRv9jTqWgBm/wBjS7vY06igCIvhhxSswIwVJFOwN1LTCzMe90wSMXhG 32rJlgkhbDqRXXVFcW0dxGUcD60XQWZyJGTUkIXeA3TvWlLosgJKOCKzXUxsVIwRQB0NjbQw KHjySe9XN49DVDR7jzIPLPVa0aGwsN3+xoZuO9OpGGRQGo1ZOOlLv9jTgABxRQGo3f7Go5nz EwAOcVNWNqmoMkvlwtjHUigNTKnjZJG3DGTUYrYt4k1OP97kOvcVai0i3j5YFz70aAc+qFug J+lWILCaUfcwPU10iQRRj5EUfhUmAKNA1Mm20qJPmmyzenar8QSL5VUAewqemqOTRcVg3j0N LvHvS0Uh6ibx70bx706igBm8e9G8e9OooDU5/WYlE4dRgMKj0iURXYBOA3FaurW4ltiwHzLz XPKSrgjsaYHWFxkGnbxVWxuFuYlPcdRVygFcbvFLvFLRSDUTeKN4paKAE3j3o3ilooATeKCw xS0HpQAwSDvTt4oUAClpgribhRvFLRSDUTeKNwpaKAE3ijcKWigBNwpA43GnUgHJoDUNwo3i lxRigNRN4o3ClxRigBNwo3D1pcUYFACbhRuFLijFADWcAijevrQwBxTsD0phqJvHrRuHrS4H pRSDUTcKNwpcCjAoATcKNw9aXFGB6UAJvHrQWGKXAoIGKA1Gq4I60b19aUKAOlLgelMNRNw9 aNw9aXA9KMCkAm9fWjevrS4HpRgelAaibh60bh60uB6UYFABuHrTdw3Yp2BSADJoDUNy+tG4 etLgelGBQGom4etG8etLijA9KA1E3D1rO1W8EcXlxt8zVLf30dqMYy56CuellaaQs3c0D1Gk Emuh0qAQW4J+83NZem2ZuJgxB2Kea6IKAMAUxCMwGKXevrQyg4o2j0oDUN6+tG4etLgelGB6 Ug1E3D1pdw9aMD0owPSgNRNw9aNw9aXA9KNo9KA1E3D1o3D1pcD0pCox0oDUarjvxWJrfM6l R261tqgx61Q1iANb7wOVp6CVznu9dPpkgNmnPQVzJJrY0WcEmJvqM0DNncPWjcPWjaPSlwPS kGom4etIzrjqKXaPSo58LC5A6CmGpzd82+7kJOeadpyBrtMkcHNVpGLSMx9avaPg3WGUHigD odygdRRuHrRsX0o2j0pBqG4etLuHrRtHpSbR6UBqG4eoo3D1o2j0o2j0oDUXcPWjcPWjaPSj aPSgNRGYDrRuX1FIygilCgdqYai7h60ZHrSbR6UbR6Ug1F3D1oyPWk2j0pdo9KADcPWk3D1o 2j0o2j0oDUztWtTcIGjxuFYLxvGcMCDXX7V9KguLSKeMhlGexp6BqcsMg10el3azW4U8MvBr Kl0u5WQhE3L61d0qylhdmlXA9KLBc1dw9aXI9aQIo7UbR6Ug1DcPWjcPWjaPSjaPSgNRdw9a Nw9aTaPSjaPSgNRcj1ppYButLtHpSFAT0pg7jsj1oyPWk2L6Uu0elINRNw9aXI9aTaPSl2j0 oDUMj1o3D1pNo9KNo9KA1FyPWjI9aTaPSjaPSgNQJGKNw9aCoxQEHpTDUXI9aMj1pNo9KNo9 KQai5HrRketG0elJtHpQAuR60ZHrSbR6UbR6UBqLketGR60m0elG0elAAGB70uR600IKXYvp TDUXI9aMj1pNo9KNi+lINRcj1oyPWk2KO1G0elAai5HrRketJtHpRtHpQGouR600sA3Jpdo9 KQoCwpg7jsj1pNw9aNo9KCi+lINRcj1oyPWk2j0o2j0oDUXI9aMik2j0o2j0oDUXI9aMik2j 0o2j0oACQBQGBHBpGUY6UKgAphrcdketGaTYPSjaPSkGouRRketJtFG0elAai596Mj1pNg9K No9KA1FyPWjNJtHpRtHpQGoisMnmnZHrTQgyeKXYvpTDUXPvRketJsX0o2D0pBqLketGRSbF 9KTYvpQGo7I9aMimhF9KXYvpQGouRSEgEZo2D0prICRTDUfkUZFN2L6Uu0Ug1FyPWjIpNi+l G0elAai5FGaTYKNg9KA1FzRmk2CjaKAFJ4pAQRSFRigIMdKYajs0ZHrTdgo2L6Ug1HUZpuwU uwUBqLmjNJsFGwUBqLmjNJsFG0UAAI3GlzTNgLGl2CmCuOyKM03YKXYKQai0U3YKXYKA1FzR mk2CjYKA1FzSMQMUmwUjICKYO4/IoyPWm+WuOlGwelINR2aM03YvpRsFAajsiik2Ck2CgNR2 RRTdi0uwUBqLmkUjFGwU0RimGo/NFN2Cl2CkGouaM0mwUgQCgNR1FJsFGwUBqLRSbBRtFAah n5qWmbBupdgphqOzRTSgpdgpBqLRSbBRsFAai0Um0UbRQAtI3ajaKaygYNMGPFLSClpDCiii gAooooAKKKKACiiigBo+8adTR1NOoAKKKKACiiigAooooAKQ9qWkPUUALRRRQAUUUUAFFFFA BRRRQAh6UDpQelC9BQAtFFFABRSUtABRRRQAUUUUAIOtLTR1NOoAKKKKACiiigAooooAKa1O pr9BQAtLSUtABRRRQAVQ1K++yIAv326VckbZGzHsK5a7maednY9+KANTTL+aWby5DkHnNbFY +hohVn/iHFbFACUi9KWkXpQA6iiigAooooAKKKKACiiigBv8VOpv8VOoAKKKKAErnNWiZLsn bgGujqnfWC3eCWKsO9NAZWju4ugq5wetdFVSxsktExncx6mrdJgFI3SlprdKAF7UtIOlLQBV v5zb2zOpGfeuXkkMkhZjyeTW3rzHykXsTWPaxebOqHuaAN7Rotlru/vVo1HDGsUSovQVJQAU UUUAFNXvTqavU0AOooooAKKKKACiiigBrLuUg965m/tjbXBB6HkGuoqteWiXUe1uCOhpoRz9 nctayhh07iukgnSeMOhyDXNXNpLbPhhx61Y0iV0ugo+6eooaGdFRRRSAKKKKACiiigApD0pa Q9KAAdKWkHSloAKKKKACiiigAooooAKaOpp1NHU0AOooooAKKKKACiiigAooooAaeop1NbqK dQAUUUUAFFFFABRRRQAUh6UtIelAAOlLSDpS0AFFFFABRRRQAUUUUAFIOppaQdTQAtFFFABU c8nlxM/oKkpCAQQelAHJTyvNMzuTyatWGntdHc3CD9a1DpFuZi5zj0q7HGkSBUAAFPYQkMKQ xhEGAKkoopDEPalpD2paACiiigAooooAKKKKACkPSlpD0oARelNmjEsTIehFOXpTqAOTuoTD KyN2NMt5TFMrAng1u6pY+enmIPnH61gFSDgjBFMR1sMiyxhlOcipKxtFuGyYW6DkVs0hhVe9 /wCPV/pVimSIHQqehoA5A9TVixcx3KHn8KtT6PMrkx4ZSas2GmeVJum5I6VVhXNVTlQadSdK WpGFFFFABRRRQAUU0so6kCmmaIdZFH40APNLUDXMP/PVfzp4miPSRfzoAkopAwPQg0tABRRR QAUUUUAFFFJQADpS01elOoAKKKKACiiigAooooAKb/FTqb/FQA6iiigAooooAKKKKACiiigB D0paRulLQAUUUUAFFFFABRRRQAUUUUAIKWmr3p1ABRRRQAUUUUAFFFFABTe9OpD96gBaKKKA CiiigAooooAKKKKAEPSgdKG6UDpQAtFFFABRRRQAUUUUAFFFFACDvS01epp1ABRRRQAUUUUA JS0lLQAUh6ilpD1oAWiiigAooooAKKKKACiiigBD0oHSg9KB0oAWkpaKACiiigAooooAKKKK AGj7xp1NH3jTqACiiigAooooAKKKKACmtTqa3agB1FFFABRRRQAUUUUAFFFFACUL0ooHSgBa KKKACiiigAooooAKKKKAE/ipab/FTqACiiigAooooAKKKKACmv0FOprdqAYopaQUtABRRRQA UUUUAFFFFABRRRQA0dTTqaOpp1ABRRRQAUUUUAFFFFABTT2p1NbqKAHUUUUAFFFFABRRRQAU UUUAIelC9BQelA6UALRRRQAUUUUAFFFFABRRRQA0feNOpo+8adQAUUUUAFFFFABRRRQAU1+g p1MfoKBMdS0lLQMKKKKAILw7bWQ+1cryW47117qHUqeh4qlFpVvHJv5b2NMB2lwmK1Gep5q7 SAADApaQCUi9KWkXpQA6iiigAooooAKKKKACiiigBv8AFTqb/FTqACiiigAooooAKKgN3AJP LMg3elTUALSN0paa3SgBR0paQdKWgDP1a28623D7y81h2oYXKbeu6urIDAg9DWYmlbbvzQ42 g5xTEaa/dGaWkpaQwooooAKavenU1e9Ah1FFFAwooooAKKKKACiiigCGaFJhtdcim29nDb/c Xn1NTEfOKdTuIKKKKQwooooAKKKKACkPSlpG6UAA6UtIOlLQAUUUUAFFFFABRRRQAU1TkmnU 1epoAdRRRQAUUUUAFFFFABRRRQA09RTqaeop1ABRRRQAUUUUAFFFFABSHpS0h6UAA6UtIOlL QAUUUUAFFFFABRRRQAUg6mlpo6mgB1FFFABRRRQAUUUUAFFFFACHtS0h6iloAKKKKACiiigA ooooAKQ9KWkPSgBF6U6mr0p1ACVSu9NiuCWX5H9avUUAU7PT47X5ur+tXKKKACiiigApo+9S 9Ki8+IPguufrQBNRSA56UtABRRUF1cLbQl2/CgAubmK2TdIfwrGutWklYrF8i+veqdxcPcSl m5z2q7Y6UZ1EkpKr6etOwXKLyyOcs7H8aYWOeTmukTTbVAP3QJ9TUn2K2/54r+VGgtTluaAT ng10smn2zY/dCopNHt25Uspo0AxYrmWI5SRgfrVuDV50wHAenzaNKuTGwas+SGWIkOjDFFgu dBBqVvMQu7De9XAwYZBzXH1ZtL6W2fqWX0NIZ1FFUrbUoJ8Ddtb0NXAQRxQAtFFIaAEXpTqa vSnUAFFFFABRRRQAUUUUAFN/ip1N/ioAdRRRQAUUUUAFFFFABRRRQAh6UtI3SloAKKKKACii igAooooAKKKKAGrTqatOoAKKKKACiiigAooooAKQ/epaafvUAOooooAKKKKACiiigAooooAR ulA6UjfdpR0oAWiiigAooooAKKKKACiiigBq96dTV706gAooooAKKKKACiiigApp6inU1vvC gB1FFFABRRRQAUUUUAFFFFACHpQOlB6UDpQAtFFJQAtFFFABRRRQAUUUUANH3jTqaPvGnUAF FFFABRRRQAUUUUAFNbtTqa3agB1FFFABRRRQAUUUUAFFFFACUL0ooXpQAtFFFABRRRQAUUUU AFFFFADf4qdTf4qdQAUUUUAFFFFABRRRQAU1+31p1MftQJjqWkFLQMKKKKACiiigAooooAKK KKAGgcmlpB9406gApKWigAooooASloooASkYcinUh6igApaKKACkpaKAEoxS0UAJRS0UANYc GhegpT0oHQUAFLRRQAlFLRQAUUUUAFJS0UAMA+Y0+mj7xp1AkJS0UUDCiiigAooooAKa3anU 1u1AMWilooAKSlooASilooAKSlooAQ0idKWkXpQIdRRRQMSilooASilooASilooAbj5qWk/i p1ACUUtFACYqO4bZAxz2qSqupuEs3z3GKAOdDFrgMDklq6qLJjUn0rlbbi4TPrXVp90UALSP 0p1NbpQDFHSigdKWgBKKWigBKKWigBKKWigBKanen01e9AhaWiigYlFLRQAUlLRQAlFLRQA0 j5hS0n8VOoAKSlooASilooASilooASkbpTqQ9KAAdKKBS0AFJS0UAJRS0UAFFFFACUi9TTqa OpoAdSd6WigAooooAKKKKACiiigBrdRS0h6inUAJRS0UAJS0UUAFJS0UAJQelLSHpQAL0ooH SloAKKKKACkpaKACkpaKAEpBnJp1IOtAC0UUUAFJS0UAFFFFABSUtFADWzkUtIe1OoASiloo AKKKKACiiigApD0paQ9KAETpS0i9KdQJCUUtFAwooooAKSlpGOATQBl6veeUnlI2GPWsMM27 OTmpr6Uy3TkjHOKSzj8y4ReOtAHR2Jc2qF+uKsUiDaoAp1ACVg6zceZN5QPC1uudqE+grlLl zLcOx7mgCfTrYz3AHYcmukUbQABgCqGjxhbUNjk1o02ISilopDGtniloNLQAlNeNZFwygj3p 9FAGXc6RG/zQnYfTtWRc2ctsfnX8a6rIprokilWAIPrTuKxyIODkVoWmqSQgLJ86/rVi70j+ K3/75NZLoyMVZcEUWC51NvcJcRhkP4VKelcpb3ElvJujYj1Fb9lfpcrgkBvSkMtp0paRDkU6 gBKWiigBKjmnjgXdIwUVLWNrkLYWUZx0NAFsara5A8zr7VcVgyhlOQa405zWhZapJBhH+ZKA Ojpv8dR291HcDMbZqX+KgGLS0UUAJS0UUAFJS0UAJRS0UANbOKWg9KKACilooASilooAQ0Ut FABSUtFADVp1IKWgAooooASloooAKKKKAEpD94U6mn7woEOpKWigYlFLRQAUUUUAFJS0UANf 7tC9KVulA6UCCilooGJS0UUAFFFFACUUtFADV706kHeloASilooAKKKKAEpaKKACmn7wp1Ie ooAWkpaKAEopaKAEopaKAEpaKKAEbpQvQUHpQOlAC0UUUAJS0UUAFFFFACUtFFADB940+mjq adQJBRRRQMSloooASilooASkbtTqa3agBaWiigApKWigBKKWigBKWiigBDSL0paB0oAWiiig ApKWigBKKWigApKWigBo++aWk/ip1AhKKWigYlFLRQAUUUUAJTX7fWn01+1AmKKWkpaBhRRR QAUUUUAFFFFABRRRQA0dTTqZvCtg0u9fUUCuOopu4etG4etA7jqKbuHrRuHrQA6im7h60bh6 0AOpD1FG4etNZgMUCuPopu5fWjcPWgdx1FN3D1pdw9aAFopu4etG4etAXHUU3cPWl3D1oAD0 oXpSEjB5oVhjrQIdRSbh60bh60DFopNw9aTcPWgB1FJuHrRketAC0UmRRkUAIOpp1M3gNjNO 3D1oFcWim7h60uR60DFopMj1oyPWgBaKTI9aMj1oAWmt2pcj1prkAdaBMfSZqOWdIoy7EYAr Alv5prgMpIAPAFAzpKKjiYtGpbrin5HrQAtFJkUZHrQAtFJkUZHrQAUi9KXIpqsPWgQ+ikyP WjI9aBi0UmRRkUALRSZFGR60ALRSZFGRQAn8VOpuRupcigBaKTNGaACqmqKGsnz2q3mmyIJI ypxgigDkFJVsjjFdHpl4LiIKxG8VhXlubedkPPpT9PkeO5Upnrg0AdTSN0pAcgUMeKAF7UtI CCKM0ALRSZozQAtFJmigBaKSigBaavelpqkZIoEPopKKBi0UUlAC0UlFAC0UUlACd6dTSQDS 0CFoopKBi0UUUAFFFFABSHpS0h6UAHalpAQRS0AFFFFABRRRQAUUUUAFNHU06mjqaAHUUUUA FFFFABRRRQAUUUUANPUU6mscEUtAhaKKKBhRRRQAUUUUAFIelLSHpQADpS0g6UtABRRRQAUU UUAFFFFABSDqaWmgjJFADqKKoapdm3iwhwxoAfdajDbNtbJb0FV4tZjdwpQjJ61hSOzMWY5J q9pmntO4kkH7sUWA6IHIyKKThF9AKxtR1MkmKE4HQmgDQutQgtuGbLegqi+uDPyRce5rGYlj knmnLG7fdQn8KLBc0zrcp/5ZrTTrc391api1mbgRt+VL9guQM+S35U7CuXF1uXPzIpFSpri5 +eI/gazHtpVPzRsPwqMgjqCDRYLnRRapbSEDcVJ9auKwYZUgiuQxViC8mtiNrnHp2pDOporO s9Vjn+WTCN+laAIIyDkUALSHpS0h6UAIvSnU1elOoAKKKKACiiigAprfdNOpDQByd2u25kHv TYZDFKrjsa0NUs5BO0iLlT1xWcImYgBSSfanZiOptZ1uIQ6n61PVHSoGgtsOME84q9SGQ3Jx bv8ASuUONxrrZhmJh7VycnEjexxTEdNpxU2abRjirJIAJNZei3CtEYs8ireoybLRz7UhlSbW FSfYqZUHBNaUbh0DDoa5Hq/rmuqswRbR7uuKAJj2paa3anUAFVry5W2hLE4PalurqO1jLOfo PWubu7p7mQuxOOw9KAHSXs7yFvMYfjV/TNQdpBFIS2ehNY9LG5R1ccEGgDsaq3djFcjJGH7G n2U/2i3V+M96sUActc2z28pVxx2PrUCsUbKnBrqri3juIyrqDXN3tq1tMVPI7GmI2NMv1mUR ucOP1rSrj0kZHDLkEV0mnXQuYAT94daQy5RRRQAVDdRedAyDqRU1FAHI3Nu9vIUcfjUNddNb xTrtkUGse80dozugO4elPcRQtbmS2lDIeO4rp4JPNRX9RmuchsJ5ZQuwgepFdFBH5MapnoMU WsFyeikzS0hhRRRQAUUUUAFFFFACN0paQ0tABRRRQAUUUUAFFFFABRRRQAgpaQUtABRRRQAU UUUAFFFFABSd6Wk70ALRRRQAUUUUAFFFFABRRRQAjdKB0obpQOlAC0UUUAFFFFABRRRQAUUU UANXvTqQd6WgAooooAKKKKACiiigApp6inUh6igBaKKKACiiigAooooAKKKKAEPSgdKD0oHS gBaKKKACiiigAooooAKKKKAGj7xp1NHU06gAooooAKKKKACiiigApG7UtIaAFooooAKKKKAC iiigAooooAShelFC9KAFooooAKKKKACiiigAooooAb/FTqb/ABU6gAooooAKKKKACiiigApr 9qdTW7UCYtLRRQMKKKKACiiigAooooAKKKKAGbQWyaXavoKB1NOoFYbtHpRtHpTqKAG7R6Uu 0elLRQMbtHpRtHpTqKAG7R6UjKOOKdSHqKBWDaPSjaPSnUUDE2j0o2j0paKAG7R6UbR6U6ig LCbR6UbR6UtFADSoweKQKMdKcelC9KBWE2j0o2j0p1FA7Ddq+lG0elOooFYbtHpRtHpTqKAs N2ijaPSnUUDsR7AWp2xfSlHU0tFxWQ3YvpRsHpTqKAsN2D0o2D0p1FAWG7R6UbB6U6igLDdo 9KZIi4qWo5hlCBTQNI57U5/MmKITtHFM02My3aDrjmmXMEqTMGRuTWro1o8QMj8buxo1DQ0w gApdi+lOopXCwzYvpS7F9KWigLITYPSk2L6U+igLDSgxTFjHelknjj++6j6mqbarbISMkkeg p3Cxe2L6UbFrM/tuLP3GpV1qEnlGApXHY0tgo2Cqkep2r4/eYPvVtWVhlSCKLhYTYKPLFOpa BWQ3YKNi06ii4WIyg3DFL5a0v8VLTuFkN2CjYKfRSuFhmwZo2CnUtFwsind2EdyvOQ3Y1Ha6 WkHLNuNaFFO7CyGeWPehlGKfSHpRcLDBGMd6XyxTqWi4WQzyxRsFPopXCwzYKRgqqSxwPWnn isTV74MfJjPH8RFAWNaN4pRlHDfQ0/YPesnQoz8zkcdBWzQFkM2D3pqpkk1LTU707hZCbB70 bBT6KVwsN2Ck2D1NPpKLhYTYKTYPU07I9aMj1ouFhpT3NAQepp1LRcLETJlgM8U7YPU0v8VO p3CyGBAO5o2D1NPopBYZs9zRsHqafUVy2yB2zjAoCxTuL6GG4EZJPqR2q6oDKGBODXJNITIS TnnPNdLp1yk9uuD8wGCKLhZFrZ7mkZeKfSHpQFhix8daXYPU04dKWncLIZsGepo2e5p9FK4W GbPc0uz3NOooCw3b7mjZ7mnUUBYbt9zTQnzdTUlNHU0BYNnuaTZ7mn0UBYZs9zS7fc06igLD NvuaNvuafRQFhu33NG33NOooCxE65wM0oTjqaceop1O4rIZtPqaXb7mnUUh2GbPc0u33p1FA WG7fc0bfc06igLDNh/vGgrx1p9IelMLEao2OuKdsPqacOlLRcEhm0+po2H+8afRSCwzaf7xo KH+8afRQFhmw46mjYf7xp9FAWGhT60zYS3WpaQdTTuDQzYf7xrC1okXKqeQBXQ1ia6mHRx9K LhYy4E8ydFPQmupihEaBVOAPSuaslLXUYHXNdUOgoC1zO1eVobfAb73GKwFBdgF5JrS11z56 r2AqvpaF71MduaANKz0pFUPL8zeh7VoLCFHy8D2FSUtF2FkRMh45pdhx96nHtRuHqKLhYYYi f4qje0jkGHUH8KsZzS0XYcqMm40dWyYm2n0PSsue0mt2IdD9e1dTTZER1KuAR70XCxyIJzV6 z1GSFgjtlP5U/UbKOI7onAz/AAk1nYoA6qGRZkDJJkVIVOPvVy9rdSWz7kPHcetdFa3aXMW5 Tz3FAWHojdmp+1v71KnSlouJIbtP96ja396nUUh2G7W/vUbT/ep1Z+oaiLY7EGX/AJUBYvbT 60FW9aw7XVJmuVEjZUnGBW8ORTCwwoSOTUYgAb5QB+FWKaPvUXE0hoVv71Ltb+9T6KB2Kl5I YIGctXMSNuct6mtrXZSI1T1rFVdxAAyaQbFiwm8m4Vux4rT1aQi3AzndWOYnjI3KRV28ZnsY t4INPYCjGMyKME811UKkRryRxXKxsVkUjsa6uJx5CsT2oCwrg44NMlfyYi7tgCoDqVtvC+YM 1R1i9V1EUZBB6kUXCxQvLprmUk9B0qOCF53CIuTUajJxXR6VaCCAMcbm5oQFb+xx5H/TTFY7 xmJyrDBBrsKwdbiCTq46tRcBdGdvNKA4B5rbCt/erntJBN4uOg610lAWGbW/vVBd2ouIirHn tVqkouFjkZY2idkYcirel3JiuAucK3FW9YtcoJl7dax14Oc0MDrQGI+9ShW/vVBp8nm2qMeu KtUBYZhvWja396nUUgsN2t/eo2t3NOooCwzYfWszU7wwkIrfN7VrVg6xalZvMXJBp7hZFRNQ uFk3Fya3rG4a6hD5xXMqjMwABzXT6dAILZRzk8nNAbljDf3qMN60+ikFhmG9aMN60+igLDMN 60Yb1p9FAWI2VsdaAr4+9TzRTCw3DetGG9afRSCwzDetGG9afRQFhmG9aMNnrT6KAsMw3rS4 b1p1FAWI1DZ68UuG9acKWgLDMN60Yb1p9FAWGYb1ow3rT6KAsMw3rRhvWn0UBYZhvWkYNkYN SU3vTCwmG9aMP60+ikFhmG9aMN6in0UBYZhvWlw3rTqKAsN+b1pMN606igLDWB280ih8daee lA6UwsNw/qKX5valopBYT5vUUYb1paKAsNw3rRhvUU+igLDMN6ij5vUU+igLEYDZPNLhvUUo 706gEhnzeoow3rTqKAsNw3rRh/UU+igLDAG9aPm9qdRQFhPmprBsj1p9IeophYT5vWj5vanU UgsJ82e1J8/qKdRQFhPm9qT5vanUUBYb83tR83qKdRQFhp3YoXdjtTj0oHSmFhvze1Hze1Oo pBYT5vaj5valooCwnze1Hze1OooAZ8+e1L83tS0UBYj+fecU75/alHU0tMEhvze1Hze1OopB Yb8/tR83tTqKAsJ83tSfP7U6igLDfn9qRt2Of0p9Ie1MLCDfjmj5/anUUgsN+f2o+f2p1FAW G/P7UHf2xTqKAsN+b2o+b2p1FAWE+b2pq76fQOlAWG/P7UfN7U6igLDfm9qPn9qdRQFhvze1 L83tS0UBYb83tS/N7UtFAWGYbfS/N7UveloCw35/al+b2paKAsJ83tSfP7U6igLCfN7Unze1 OooCwnze1NO7IzUlNftTBiilpKWkMKKKKACiiigAooooAKKKKAGjqadTB9406gSFopKKBi0U lFAC0UlFAC01uopaa2cigTH0UlLQMKKSigBaKSigBaKSigAPSgdBSN0NC9BQA6ikooAWikoo AWikpaACikooAQdTTqYPvGnUALRSUUALRSUUALRSUUALTW7UtNftQJi7QeoBpaBRmgYtFJS0 AFFJRmgAYhQSeBWNf6tjMcH/AH1RrF6d3koeO+KyooHnfCAmiwCNI0hyzFj6mk5retdKhjQG Qbm96tx28IX/AFa/lT0FdnLbWPQE0AEdjXWiKMdEX8qRreEjmNfyo0DU5LpU8F3LAco5Ht2r cm0q2kHClT7Vm3OkTRZMZ3j9aLBctW+tKQBMuD6itOGZJkDRsCK5IqykhhgjtVizvJLVwVPy 9xSGdTRUFtcLcRB071NmgBP4qdTM/PTqAFopKM0AFLSUZoAWikooAWmt0paa54oAcOlLSDpS 0AFFJRQBU1K4+z2zEH5jwK5yJGmlCjJJNXtbctcBc8AVPoUQwzkc9KYGpbRCGBUHYVNSUUgC kTvS01O9Ah9RTTxwrmRgBVTUNRW2G1Buf+VYM88lxIWdiSe1AzZn1mNciJSx9e1Z8uqXMn8e 0e1RQ2c8/wByM49TV6PRHI/eSAewp2FczmuZm+9I350C5mHSV/zrV/sNP+ezflUb6G45WQH6 0WC5Fb6tNH9/5x71pW+qwS4DHY3oayZtLuYgTt3D2qmVKthgQfeiwXOtWRXIKkH6VJXKQXUs DBkYj27VsWmrRy4WX5W9e1IZp0U1WDDIORS5oAWoLuIzW7IOpFTUUAchNC8LlXGCKuaRK0d2 FHIatu5tIbgfOoz61BaaYltKZNxY9qegi/Q3SikbpSGKOlLSDpS0AFFFJQAtFJRQAtFFFABT R1NOpq9TQA6iiigAopKWgAooooAKKSloAa3UU6mseRS0CFopKKBi0UlLQAUUUUAFIelLSHpQ ADpS0g6UtABRRRQAUUUlAC0UlLQAU0dTS0i/eNADqhuLaO5TbIM1NRQBUtbCK1JZclvU1bop M0AYGuLi6B9RVfTZfKu0IGc8Vo67GCiydxxWNE22VSPWmB145FLUcDh4lb1FPpAVNRnaCAso 5rnZbqaRss7fnXR6jG0tuUTqa5uS3lRsMh49qdhXLEOpXEI2qwI96sJrkqjDxhj7VllSD0pv NKw7mw2uv/DEPxNQXGrTyrgYUe1Z2M1KsMjY2ox/ChILjSzOcsST71qQ6Z51mHGRJ6HvSWOk u7B5htX09a3VUIoA6CnsI5KWN4nKOuCKltLp7Z8qeD1FbmoWS3Me4cOOhrnXQxsVbgjrQB1N rKJoVdehqeud0u9aGQRsfkb9K6EHIzSGLRRRQAh6Vy1+SbyQnnmuoc4Qn2rkrhg07sO5oAdZ kC6jJ6Zrq15UVzGlpvvUyBx611A6UALTf4qdTR9+gB1FFIelAHP63LvuQo/hFQaWge8QEZxz Rqn/AB+PnijS+LxMUwOiltopgBIoOOapaxEBaDaAAprSHSquop5lo4xzigRy/etF70/YEQE5 6Vn45xWjHp0s1pkcdwKLBczCcmlHP1qSW2liba6HNSWtjLO4AUgdyaVmF0P0yEzXS5GQOtdO BgYFVrKyS0TC8sepq1QMKwtaVzOvBK9q3aaVVvvAH60AZ2j23lxmRhhmrTpAAOlLQAUlLSHp QBBdRiS1kU88VypGGrqbmRY7Vy3TFcueSaYjoNGbNp9DWjVHSU2Wa+/NXqQwooooAKKKKACo 2VWbkA0+oZ5lhBduwoQmAtoFbeEUH1xUVzqMFuCC25vQVkXeqySnEeVWs5mLHJJJoYzVGtS+ dnaNnpW3BKs0SuvQ1yAGSABmup06IxWiKeuKALVFFFABRRRQA1ulLSN0paAFooooAKKKKACi kpaACiiigBq06mrTqACiiigAooooAKKKKACm/wAVOpv8VADqKKKACiiigAooooAKKKKAEbpQ OlI3SlHSgBaKKKACiiigAooooAKKKKAGjvTqavenUAFFFFABRRRQAlLSUtABTT1FOpp+8KAH UUUUAFFFFABRRRQAUUUUAIelA6UHpQOlAC0UUUAFFFFABRRRQAUUUUANH3jTqaPvGnUAFFFF ABRRRQAUUUUAFNbtTqa3agB1FFFABRRRQAUUUUAFFFFACGhelBoXpQAtFFFABRRRQAUUUUAF FFFADf4qdTf4qdQAUUUUAFFFFABRRRQAUx+1Ppj9BQJjhS0gpaBhRRRQAUUUUAFFFFABRRRQ A1fvGnU1epp1AkFFFFAwooooAKKKKACmnqKdTW6igB1FFFABRRRQAUUUUAFFFFACHpQOgoPS gdBQAtFFFABRRRQAUUUUAFFFFADR9406mj7xp1ABRRRQAUUjMFGScCqNxqsERwp3n2oAv0VU sr1LsHaCCO1W6ACmv2p1NftQJiilpKWgYUUUUAFU9RuxbQn+83Aq2TgVzmqXPn3BXPyrwKAK qK9xOAOWY10ljaJbRAAfMeprN0W1y5mYcDpW3TEBpF6UppF6UhjqKKKACiiigCleafFcKSFA f1Fc9NC8LlHBBFdbVDVLUSwF1X51700IzNLunhnCE/I3GK6IdK5AZVsjqK6XTp/PtlJPzDg0 hln+KnU3+OnUAFFFFACUtFFABRUUtxFCQJHAJqRWDDIORQAtI3SlpG6UAHalpBS0AFFFFAHO 6z/x+de1aGix7bUt6mn3emR3MgfJU9/ercMSwxhFGAKYiSiiikMSqV7dC2hbB+c9Ku1z+pFp L3Z+FNCK0Uc13P3LHqa3LXTYYVBZQzepqSytkt4RhfmI5NWqL9gEAAGAABS0UUhhRRRQAlQz 2kM4xIgPvU9FAGHd6TsGYCT/ALJrMZGjbawII9a60j5qgurKK5XDjB9R1p3EYdpqM1vgE7l9 DW3aXkd0mVOG7isS70+S3Y8Fk/vYqvHI8LhkYqRRYdzraKztP1FbgbJCA/8AOtCkAUtFFABS N0paQ9KAAdKWkHSloAKKKKACiiigAooooAKavU06mjqaAHUlLRQAUUUUAFFFFABRRRQA09RT qa3UU6gQUUUUDCiiigAooooAKQ9KWkPSgAHSlpB0paACiiigApKWigAooooAKaByadTR1NAD qKKKACkpaKAMvXAfsw6dawVyCDXS6rH5lm3HI5rm6YHU2XNrGfap6qaW++zTnkVcpANYcigo p6qDSOcYpQyt0INAiN7aF+sa/lXOanGsd2yqoA9BXUVga3Hi4DeopgVLBkFym9cg9q6hFUKM KBXIKdrAjrXU2EvnWqN3xSGWKWiigBKyNYslC+egwe9bFRyoHiZSMgihAckuQc102nTie2U9 xwa5yZNkrr6GtfQ3O1096YjXooopDGSD5G47VyU4xM/GOelde3KmuVvI2W4f5SBmmA/TPlvU rp65vTIJHuFZBgA9a6QcCgApAPmNUdRvzakKgGT3qLTL+SeUpJyfUUgNSilooA53Wowl1uA6 iqUD+XMrehrZ1yImNXA6Vhd6Yjr4JFliVlOQRTmUMCCMg1naNPvt/LJGVrTpDKI0q2WTeFP0 zV0KAMAcUtFFwI3jViCVBNOVFX7oAoY4xS0CCloooGFFFFABRRRQAUh6UVnahqKxKY4yC5/S gCpqt2MeSp6daoW0ZnnVB3NRsWdiSck1s6PZlB5zjk9KYjThjWKNUUYAFPpaKQwpMUFgoyTi qc+p28WRu3MOwoAuVDNdwQg73Ax2rEuNWnlJEZEa/rWe8jOxLEk0AbNzrWCVgTPuay57qWc5 kcn2qHnNKAx6DmgBp5p8ULysFRcmrEGnXMwyqYHqeK2rDTltgGbl6dhXIrDSkiCyS8t6elaY GOlLRSGFFFFABSUtFADWFLSNTqACiiigAooooASilooAKSlooAQUtIKWgAooooAKKKKACiii gApuPmp1N/ioAdSUtFABRRRQAUUUUAFFFFADW6Uo6UjdKUdKAFooooAKKKKACiiigApKWigB q96WkXvTqACiiigApKWigBMUUtFABTT94U6mnqKAHUUUUAFJS0UAJS0UUAFJS0UAIelA6UHp QOlABRS0UAJRS0UAFFFFACUtFFADR1NOpo6mnUAFFFFABRRRQAUUUUAJSN2p1NbtQAtFLRQA UlLRQAUUUUAFFFFACHpSL0paB0oAWiiigApKWigApKWigAooooAbj5qdTf4qdQAUUUUAFFFF ABRRRQAUxx0+tPprdvrQJi0tFFAwooooAKKKKACiiigAooooAaOpp1NHU06gAooooAKKKKAC iiigAprdRTqaeooAdRRRQAUUUUAFFFFABRRRQAjdKF6Cg9KF6CgBaKKKACiiigAooooAKKKK AGj7xp1NHU06gAprsEUsTgClrM1uRktwFYjPFAFC/wBQedyinEf86r29vLcttjXPvVdeTgc1 0+mRCO0X5cE9aEDHWNmtrFgcsepq1RRQAU1u1OprUALS0lLQAUhIA5OKWsHWLxvN8pSQB1oA 07y6jit2YMCcetc5EhmuAvXJqMsx7mtTRLfdIZT0FCA2oYxFEqqMACn1n6lfG2XahG6s5NZn XG4A0AdCaRelZS63GVG5DmmnWgvCxk/U0AbNFYb63IfuxgfWq8mrXLggMAPYUAdHkCkLqoyW AFco95cP96VvzqMyyEYLsfxoA60TRscLIpP1p5GRiuVsQ5uU25PNdSv3RQBzN/D5V249eava HLhnj/GotbQi4U+1M0Y4vAPamI6D+OnU3+OnUhhRRRQAUUlFAHPau5N2Qe1a+mHNmmTnisbV 932056Vc0W7yvkt1HSmBsU1ulLSN0pAKOlLSDpS0AFFFFABRRRQAUUVFPMsEZdugoAk7ViSx t/aqkAnnPSpH1tONiH8av2kqzp5gXFNCZYHSloopDCiiigAooooAKKKrz3kNv/rHwfSgCY/e FOqGKVZgHQ5BqagBrKHUqwyDWJqOm+UDJD93uPSt2kIDDB6U0xHIKxQgjIIrd0zUPOHlyn5+ 3vVLVLEwOZEHyN+lUI5GjcMpwR6UMZ11LVaxuPtFur9+9WaQBSN0paQ9KAAdKWkHSloAKKKK ACiiigAooooAKaOpp1NHU0AOooooAKKKKACiiigAooooAa33hTqaeop1ABRRRQAUUUUAFFFF ABSHpS0hoAB0paQdKWgAooooAKKKKACobi4jt4y0hxUpIAyelc1qlz51ycHKjgUAaH9tx78e W2PXNaUUgkUMvQ81zFlB9puAnbvXTQxiNAg6CgRLRRRQMKKKKAGTLviZfUVyci7JCvoa66ub 1WHy7tvQ80wLuiTZDRHjuK1z0rm9Lk8u7T34rpOopAc/qV9K0rRg4UelVba7eGUNuOM81Pq9 u8VwXx8rVnYoYHUWt/HccdGqprRRoxgjcKxUdkbKsVPtSvK7/eYmgBh5re0OQmNo89KwgCTx W/o9s0MZkb+LtQBqUUUUAFI3Q0tRyuEjZj0AoA5q/wAfa3x61oaEDuf0rMnk8yZn9TW1ose2 2Ln+I0xI0qKKKQwqKWCOUYdQRUtVb+5W3gLHqeBQA5Wt4BhSqipg6sMqQa5CSVmckseauadd SJKFySD2oAXVZC92wPOOKdoxP2wY9Kq3Tlrl296taO2LscZyKYjoqKKKQyK4iE0LIe4rlZ4m ilZGGCK6+sjWbTcBMg5HWmIzrC5+yzhuoPBrpY3EiBh0NcgcCtbStQCAQydCeDSGblFIDkUt ADW7U6mt2p1ABRRRQAUUlNkkSNcuwA96AH1HLMkKbnYAVnXWromVhG4+vasma5knbdIxNAF+ 81YvlIOF9TWXyzepNIASeKu2T2sJLy5Z+wAppCLOnaaWIkmHy9hWyMKMdBWM+skDEUePc1Rn vp5j8zkewpNjR0Ut3BF9+QCqFxrKKMQqW9zWKWz1yfrSUATz3k05O+Q49BVbvT0RpDtUEn0r QttImkAL4Qe/WnYVzMxzU8NpNKcJGT74rft9Mt4eSu9vU1cAAGAMUaAYcGiOSDM4UegrShso ISAqDI7mrVJ/FRcLCjiloopDCiiigAooooAKKKKAGtTqa1OoAKKKKACiiigAooooAKKKKAEH SlpFpaACiiigAooooAKKKKACk70tJ3oAWiiigAooooAKKKKACiiigBG6UDpQ3SgdKAFooooA KKKKACiiigAooooAavenU1e9OoAKKKKACiiigAooooAKaeop1NPUUAOooooAKKKKACiiigAo oooAQ9KB0oPSgdKAFooooAKKKKACiiigAooooAaOpp1NH3jTqACiiigAooooAKKKKACmt2p1 NPagB1FFFABRRRQAUUUUAFFFFACUDpRQOlAC0UUUAFFFFABRRRQAUUUUAN/ip1N/ip1ABRRR QAUUUUAFFFFABTX7U6mt2oExRS0gpaBhRRRQAUUUUAFFFFABRRRQA0dTS1GVYvwcU7Df3qYr j6KZtb+9Rtb+9SC4+im4PrRhvWgBaKTDetJhvWgLj6aeopMN/epGDHHNMLklFM2tj71GG/vU guOopMN/epMN/eoAfRTcN60mG/vUAOopuG/vUuG9aAFPShegppBx1oUHHWmA6im4b1ow3rSC 46im4b1ow3rQFx1FNw3rS4b1oC4tFNw3rS4b1oC4DqadUWG3cGnYf1phcdVLUbE3ijDYIq1h /UUuH9RQFzHt9GdJgzuNo9K2VG1QB2pMN6il+b1oAWik+b1FJh/UUguOpGpPm9RTZA2OtOwN klFMXfjtS/P6ilYLjj0NcpqDl7qQnrmuoIfHUVzGopsu3B9c8UBcrA9q6bSovLtFz1PNc0mN wznrXVWu4wJt4GKaAxtZz9p71mYNdZcWq3AxIAar/wBkw+lFkK7OdAp2K6P+zYB/yzWlSzjH SNce4p2QXfY5zYxHQmporG4l+7GcHua6MQgdET8qfhx0xRoBgDSLnONo/OpV0SYn5nUCtv5/ aj5/akBXs7FLVcD5m7mrVNO/2qOWQxRl3IwKB3MnXJMyog7U3RFzcE56CqVzOZ52f1rX0iAp F5mOW9aAuaf8VLUZ3bhTvn9qAuOopvz+1Hz+1ILjqKZ8+e1L8/tQFzL1yAsqyqOnWseKQxSB 0OCK6mRDIhRgCDWHcaXKk2EUsrHj2p2C5s2NyLmAMOo61YPSqtnA1vCFAGe9TsWxRYLj6Wo1 L47UfP7UWC4+im5f0FHzegpBcfRTMt6Cj5vQUAPrE1yc5WIHjrWwd+Ogrm9VJN2d3WgLlNPm cAdzXUafEYrcK3WsDT4hNcqPTmuiiLDgDimloJvUsUhOOtMy/oKx9Vv3B8lDjHUikUaj3kCH DSrn60Je27nCyrXKlieaATQB2AZW6EGlrkkuJI+Vdh+NXLfWJo+H+cUAdDXO6uSbs/StKHVI pRjIVvQ1kalIJLokHP0piNHRJCVZDzitasDRpSspUAkmtwF/SgLj6Kblv7tGW9KQXEmjWWJk YcEVy1xGYZ2T0NdRI7KpJAAFczdyiS5ZqYGnocgwyHr1rXrH0WMhWkC9eAa1st/doC46g9Kb lvShi208UBccOlLUKs+OgxUP2+MT+USN1FgTLdFN3N/doy3pSC46im5b+7Rlv7tAXH0UzLf3 aMt6UBcdSDqaMt6U0M2TxQFySkpuWx0oy392gLjqKblv7tG5v7tAXHUU3c392l3H0oC46imb j6UuT6UBcD1FOqJ2YEYFKGbH3adguPopu4/3aXcfSkFx1FN3H0pNx/u0BcdRTdx/u0bj/doC 4+kPSm7j/doLHB4oC44dKKjV2x93NO3H+7TsF0PopuT6Ubj/AHaQXFopu5v7tBY4+7QFzN1a +MY8pCMnrWCTW7qOntcN5iA5rObTJ9wGw/WnYLjtI3C6Urz610Y61l2EEdpy7DefetASHdwM g0WFcmopm4+lG4/3aVh3H0Uzcf7po3H+7QFx9Y2uRcpIPpWvuPpVTUY/OtmGORyKaC5zsTeX IrHsa6q3kEsKuvQiuTPXmtbR7wgeSRn0oA1Lm3S4TY/Q1j3GiypzCwcelbTOeOKUSHH3TQK6 uctJaTRHDxsKaIZGOFQn8K6pjuHKZoXA6RgfhTC5kadpjiQPOoCjoDW2BgYHSmhj/dNG8+hp DH0Uzef7po3n0pBcfWTrF4FTyUOSevtU19qCwIVHLnoK593MjEnJYmmO4+CIzShFHJNdTBGI olQdhWZpdr5Y85lJY9BWoHP900MlMfRTN5/umjcf7ppWHcfWZrUJe3DgEla0Nx/ummSgSIUZ Tg00FzkTViy/4+FzRdxCK4ZB0HSmQD96vOKOoBOczvn1qfT5vIukbseKjnhkWQlkPPfFLa20 kko2KTg0WYXOqByM0tRIxCAFTmnb/wDZNKwXH01lDqVPQ0m/2NG7/ZNAXOd1KyNtLkZKHpVI cdDXVXEazxlHU/WudvbZreUqenY0wuaGm6pjEUx47NWwrBhkHIrjunerMN9PCNqSce9IZ1B7 U6ueXWbgDlVakbWLknjaPwoA6EnFV5b63izvkGR2Fc/LqFzLndKQPQVVL5680AbVxrJ5EC8e prMuLqSc5kYn2qAnNIe1AC5oH04o+lKM+9ABn0NGeetTR2s0x+SMkeuKtR6PMeXIX9adhXSM /vShSTgKTW5BpcC/fDOf0q7HFDF9yID8KdrCvcwYdNuJsYTaPU1ow6Mg5lct7CtLfx0NG/2N IZHDaww/6uMA+tT03d7Gjd7GkGg6imb/AGNG/wBjQFx9N/io3exprPhhwaYNokopm/2NG/2N ILj6Kbu9jRu9jQFx1FN3exo3exoC46imb/Y0b/Y0BccaKazcUCT2NOwXQ+im7/Y0m/2NILj6 KZv9jRv9jQFx9FM3+xo3+xoC4+imbx6Gl3exoC4opajEgzjBpd49DTsF0Popm/joaXd7UguO opm/2NLu9jQFx1FNLgdjRvHoaAuOpO9Jv9jTS+COKYXRJRTN49DRvHoaVguh9FN3+xpN/saA uPopu8e9G8ehoC46im7vY0bh70AKelA6U1n46GhXB7GiwXQ+im7x70bhQFx1FN3CjcPegLjq KbvFG8e9AXHUUzePel3CgLgvenVGHAJGDS7x707AmPopm8Ubx70rBcfRTN496N496LBcfRTN 496XeKLBcdTT1FG8U1nAxRYLklFM3jFG8e9FguPopu8e9JvFFguPopm8Uu8UBcdRTd4o3igL inpQOlNLDFAkFFguPopm8UbxRYLj6KbvFJvHvQFx9FN3ijeKAuOopu8UbxQFwH3jTqj8wBqX eKdguh9FN3ijeKQXHUU3eKN4oC4tFJvFJvWgLofSHtTd4NDOAAadguh9FMEiml3ilYLodRTd 4o3igLjqKbvFJvFAXH0U3eKN4oC4tA6Um4YpqyDFMLokopm8Uu8UguOopu8Um8UBcfRTd4o3 igLjqKbvFG4UDD+KnVHvAanbxTsK6HUU3eKNwpBcdRTd4o3igLjqKbuFG8UBcdTW7UbhTWYH HNAMfS0gpaBhRRRQAUUUUAFFFFABRRRQAg60tNA+Y0uKAFopKKAFopKKAFopMUUALTT1FLik YcigB1FJRQAtFFJQAtFJRQAtFJRQAHpQOlB6UijgUAOopKKAFopKKAFopKKAFoopKAEHU06o yQuSelZcus7JSqpuUHrmgEa9FY1xrKmL90CHPr2qHTtRk+0Ymkyrevai4HQUUg5GaMUALRSY ooAWmtS0jdqAFpaQCigArm9ZQrdk+orpMVka5BlFlHbg0wMMZrptK3/ZAXOfSubU4YGul024 SeAbeCOCKQF2kooxzQAGkXpSkcU1BgUCH0UlFAxaKSobi5jt1zI2PagCSR1jQsxAArn9S1A3 DFEOIx+tMv797ptoOEHQVXgt3uJQig/WgCbT7U3M4BGVHWuljRY1CqMAVDZ2iWsQVevc+tWM U2IT+KnUzHzU6kMWikooAWikooAWikooAWmt0paRhkUAKKKB0ooAKM0yWRYoy7HAFYU+pzTS 7Y/lXPGO9AHQ0VHDuMS7uuKfQAVzmsJi7J7GujxWZrFqZYfMXqtMDI0+UQ3SE9Ohrp4iCMiu RHDda6TTJPNtl55HBoEXHOEJrk7lt9w7eprrGXIINcxqEBguWBGATkUhjbKGOaYJI20VrPos LL8jMD+dYaEhwynBFdTZF2tkLnJx1piMW50maFdyfvB6DrWc8bK2CCPrXZYqCe0hnGHQH3o0 A5PJFGTWvdaMynMHzA9jUVvpEzSDzRtXvRYLkmiRHzC/at6oIYFgAVBgCpqGCFpCQBkmo554 4ELOwArCv9Sa4+SPKp/OkMtapqIAMMXOeprIiiaWQKoJJ9KSONpXCqCSa6HTrEWybmH7w0xE 1jb/AGaAJ1NWaSikMWkbpRSN0oArX8his3YdcVzG9t+7JzXUXsDT2rIvWubltpYpNrIwP0ph c6ayk822RvarFUdJjeO0Afv2q7SAWikooAWiikoAWmjqaWkXqaAHUUUlAC0UlFAC0UlFAC0U lLQA09RTqY33hTqBC0UUUDCiiigAooooAKQ9KKD0oAB0paQdKKAFopKWgAoopDQBFcyiGBnP YVzkmpXLAgucH0rpJohNEUboa5i8tXt5SrDjsaAIVZnYfMSa6jTzm3XPXFcsMg8GtTT9S8hd koOPWgRv0VXhu4ZsbJASe1T0DFopKKAFpCMgg0UUAcxqMBgumGPlPIqrHI0bBkJBHeui1W0N zDlBlx0rnXjaMlWBDCmI2LLVQ5CTkD3rVjnjkGVcEfWuRGRQHYHgkfjSGdjuHrSgg965ITSD nzG/OlW6mVdokYD60AdZkUhYDuK5Vbucf8tn/OmvcSOeZGP40AdS1xCn3pFH41n3mrIoKQ/M 3r2FYRJPXJpQCTgCgLjpHaRizEkmr+mWBlIkkHyDpnvUmn6Wz4knGB2HrW0FCrtUYAqthCRq FUAU+mr0p1SCCikpaBhSGlooA5fUlIvXzxzT9Kt/PuQWHC81uzWkE5zJGCfWnQ28UI/doF+l PQRJsUjBAI96aqIjHaoH0p9NGd9AD6KKSkMWikpGcKMsQB70AOqC4to7hNsi59D6VDLqVvF/ HuPoKoz60x4iTA9TQBXutLmiJKDevrVBl2nDAg1PNe3Ev3pWx6Cq5OTzz9aBBSUdaUKc0DE9 aQD2qZIJJDhEJPsKu22kTyY3/Ivv1p2FczsVJFA8pARCxrdi0iFDl8v9avRxJGMIgUe1Ggam Hb6PM7Zk+Ra04dMtojkpuPqauUUXCwBQowAAKKWkNIYi9KdTV6U6gBKWkpaACikooAWiiigA ppA3U6m/xUAOopKWgAooooAKKSloAKSlpKAEbpS0j5xxS0CFooooGFFFFACUtJS0AFJS0lAC AU6mrTqACkpaKAEpaKKACiiigAppAzTqafvUALRRRQAtFJS0AFFFJQAtFJRQAHpQBxSN0pR0 oEFLSUUDClpKKACiiloASiiigBFAyaWmp1NOoEgopaKBiUUtFACUUUtACUh6inU0/eFAMXFF LRQAUlLRQAlFFFABRRRQAEcUgAx0obpSjpQIMUUUUDCilpKADFGKWigBMUYFLSUANAG407Ap o+8adQJBijFFFAwwKMCiigAwKMUUUAGBSMAccUtIx6UCFwPSjFFLQMTAoxRRQAYoxRRQAYox RS0AJ2pFHFL2pF6UCFxRS0UDEoxRRQAYopaKAEooooATA3UtIPvGnUCEoxRRQMMUYoooAMUY opaAEwKaw6U6muelCEx1LSDpS0DCiiigAooooAKKKKACiiigBo6mnU0feNOoAKKKKACiiigA ooooAKQ9RS009RQA6iiigAooooAKSlooAKKKKAEPShegoPSgdKAFooooAKKKKACiiigAoooo AYRnNcxfwvFcOCuATkV1A+8abLCkyFXUHNAjjyDmpbaRYpVdlyAelX7rR5UYmH519KznjaM7 WUg+9Fh3Ont76CZQFcA+hqznPSuOBx061bt9RuIMANuUdjSA6eisiHW1PEsZHuK0IbqGYZRw famBPTW7UvWmv0FAMdS0g6UtABUc8QmiZD3FSUUAcneWz20pVhx2NJbXL28gdD9R610t5apd RFW69jXOXVtJbSFWH0PrTEb1lqEdwoDEK/pVzNccMqc85q3DqdxCfv7h6NSGdNSL0rHTXP78 X5GpU1mLoUagDVpKy31uIfdRjVK51aaYFU+Qe1AGjf6ktuCseGf+VYc1xJO+52yaiLM555Jr QstLecB3+VP1NOwFW2tZLmQKo+pro7O0S1jwvLHqakhgSFAqKBipaLiCiiikMb/FTqb/ABU6 gAooooAKKKKAEJx1piTRu5VXBYdgai1BmS0cr1xWBp8jLeIQep5oA6imt0pR0pG6UAKOlVry 8S1TJ5J7VZ7VzOpytJdsD0XigB19qD3Q2j5V9KfpNs8k4kK/KvrVaytWupwo6dzXTQQpBGEQ YApgSUtFFIAproHQqehp1FAHJ3sJguGTsDxU+l3Hk3IBbCt1q/rVtvQSr1XrWGTggimB2IOR kVR1KwN2oKEBh60zSr0TRbHPzL+taNIDGtdHZJA0zDA7CthQFUAdBTqKLgFFFITigAoqCa7h iGWkWsq51lySIVwPU0Aa8syRcuwAFZ9xrKKCIVyfU1kSzyTNl2JPvTUjeVgqqST6UBsOmuJL h90jZNSWtlNcsNgwvcmtG00dQA055/uitWONY1CoAAKewtyvZ2MdqvHLHqat0UUhhRRRQAUh 6UtI3SgAHSkKg9QDSjpS0AFFFFABRUUs8cIzIwFOjdZEDIQQe9AD6KKKACmjqaZNMkKFnYCs S61Z3ysQ2g96ANuSeOIZdwBVG41iKM4jBc1gvI7feYmm5oA6iwvVvEJC7SOoq3WPocLqGkPC npWxQAUUUUAFFFFADT1FOpp6inUCCiiigYUUUUAFFFFABSHpS0h6UAA6UtIOlLQAUUUUAFFF FABUNxbpcRlXUGpqKAOcutLmhJMY3p7daoupXgjBrsKq3FjDcbtyAN60xHMKxQgqSCPStKDW Jo8CRQwqO60uaE5Qb19RVFgQeeKLBc6SLVbaTGW2k+tWkmjf7jqfoa5GlV2Q5UkH2pDOwyKW uVjv7mPAEhI96twazKp/eKGFAG/VW5sYLjJdcN/eFVk1mA43Kwq2l5buARKvPqaLhYy5NFYH 5ZAR2yKgfSLlegDfQ1v71bGCDT6dxWObOmXQ48v9aZ/Z11/zxNdPRRcLHMjTbo/8sjT10m6b +ED6mukoouFjEi0V8/vHAHtWhb6fBByF3N6mrdFFwsFIelLSHpSGIvSnU1elOoAKKKKACiii gAopKiluYolJd1GPegCam/xVnzaxAnCAuaoS6vM2doC0Ab5YL1IFVZ9Rt4cguCR2Fc7JPJKc u7N+NR0Aa0utuSfLQAeprOnupZ2LO5Pt2qMLk1NDZzTHCRmnYLkHOaMVrw6I3Blkx7Cr8GnW 8POzcfVqBHPR20sxwiE1di0ed+XKoPet5VVRhQAPanUXCxlJo0a43uW+lXIrK3i+7EufU81Y NFFwsIqKvRQPoKdRRSGFFFFABRRRQAUlLSUAIvSnUg6UtABRRRQAUUUUAFFFFABSfxUtJ/FQ AtFFFABRRRQAUUUUAFFFFADW6UtI3SloAWiiigAooooAKKKKACiiigBq06kFLQAUUUUAFFFF ABRRRQAU3+KnUn8VAC0UUUAFFFFABRRRQAUUUUAI3SgdKG6UDpQAtFFFABRRRQAUUUUAFFFF ADE7/Wn0xO/1p9DEgooooGFFFFABRRRQAU09RTqafvCgB1FFFABRRRQAUUUUAFFFFACHpQOl B6UDpQAtFFFABRRRQAUUUUAFFFFADR1NOpo6mnUAFFFFABRRRQAUUUUAFNbtTqQ9qAFooooA KKKKACiiigAooooAQ0L0oNC9KAFooooAKKKKACiiigAooooAaPvGnUneloAKKKKACiiigAoo ooAKawzinU1u1AmLS0UUDCiiigAooooAKKKKACiiigBo+8adTR1NOoAKKKKACiiigAooooAK aeop1NPUUAOooooAKKKKACiiigAooooAQ9KB0FB6UDpQAtFFFABRRRQAUUUUAFFFFADR9406 mj7xp1ACVFNawz/6xAfepqKAMmbRYzkxOVPoazrjTp4eq5HqtdPSYp3EccVIpQzA/KSDXVS2 kEo+eNfrWfPoqnmF8exo0AoQalcQH724ehrQh1dJMCUbDWdcafPBncmV9RVUjHtRYLnWxSpK u5GBHtUlcik8kfKOV+lXYNYnTh8OKQzoaKzoNWgk4k/dn3q8kqSDKMCPY0APqKaCOddsigip KWgDGuNFJOYX/A1ny2FxESGjOPUc11NJincVjkDGw6qfypCOea65o0bqoP4VGttD18tM/SjQ DliuOlPit5JmARCfwrpzbQnrEn5U9Y0QYVQB7Ci6AzbPSVTDT8t6CtQAAYHSlopXGJS0UUAF FFFADf4qdTf4qdQAUUUUAFFFFAEN2u62kA9K5mBvKnVj2auqcbkI9RXK3CeXO64xg0wOpjbc it6inN0qrpr77NCeuKst0pAL2rmtUhaK7Y9Q3IrpR0qKe2inH71A1AGVoX33rbqGC2igH7tA KmpsAooopAFFFFADJY1ljKMMg1zF9bfZ5yo+72rqaqXNnHdKQ3UdDTQmcyHZOVJBq7BqtxEA CQw96J9KuI2O1dw9RVY28qnBRuPaiwXNIa5J3iH50HW5O0S/nWZ5T/3G/KnLbyt92Nj+FFh3 LT6xct0wv0FV3vbh/vStj61JHp1y/wDyzIHvVqLRZW5d1X9aLCuZWSTyfzp8UTzPtRSxrdi0 eBOXJersUEUP+rRV+go0AyLbRySPPbHsK1be0htxiNfxNSn7wpaGwFooopDCiiigBO9LRRQA UjdKWmt0oAUdKWkHSloAKSimPLHGMu4A9zQBhaxvW6+Y8EcU7SL4RMYpDweh9KZq9zDO48ti SO/as08UMDqZtRt4hzICfQVnXOtMciBce5rHzmgc9KAJZbiWY5kcmo+tWrbT5rj7owPU1rWe lRR8yjcw/KnYVzItbGa4cBVIHqa17bR4om3SHefTtWiqqowoAFOouFhFUKMAYFLRRSGFFFFA BRRRQA1uop1NbqKdQIKKKKBhRRRQAUUUUAFIelLSHpQADpS0g6UtABRRRQAUUUUAFFFFABSD qaWkHU0AFV57KCf78Yz6irNFAGTLoqH/AFbkfWqcukXEeSoDD2roaKdxWOTeCRT8yMMe1R7e a68qCMEA1E9nbv8AeiX8qNAOVx70nOK6GTSLd/ullNV5NFOP3cufqKNAMlJpExtZh9DVhdTu V/5aH8adJplxH/Bn6VC1rMud0TflRYLlldYuB1Kn8KmTW3/ijB/GstoyOox+FJt9aVh3Nka4 M8xHH1qT+2oe6NWFtNBFFgub6axbnqGH4VINVtScbz+Vc5z24paLBc6b+0Lb/nqtL9ttyOJV /OuYxQelFgudStzDj/Wr+dKLmE9JV/OuUOaBmiwHVfa4MZ81fzpjahbKMmUfhXMc9KOaLAb0 uswr9xWY1Ul1mYj5EVRWWRRjPaiwXLUmo3Mgw0hx7VWZix5JP1qRIZH+4jN9BVmPSrhyMrtB 9adhXKIJ7UYNbkWiRjBkkJ9hVuKwt4mysYP15o0AwYLKec/Ih+pq/DordZZAPZa2QAOgxS0X CxUh063hwQmT6mrQAA4GKWikMKKKKACiiigBDS0hpaACiiigAooooAKKKKACkpaKAEHSlpB0 paACiiigAooooAKKKKACk/ipab/FQA6iiigAooooAKKKKACiiigBG6UtI1LQAUUUUAFFFFAB RRRQAUUUUAIKWkWloAKKKKACiiigAooooAKb/FTqTvQAtFFFABRRRQAUUUUAFFFFACN0oHSh ulA6UALRRRQAUUUUAFFFFABRRRQAxO/1p9MTv9afQJBRRRQMKKKKACiiigApD1FLSHqKAFoo ooAKKKKACiiigAooooAQ9KB0oPSgdKAFooooAKKKKACiiigAooooAaOpp1NHU06gAooooAKK KKACiiigAprdqdSHtQAtFFFABRRRQAUUUUAFFFFACHpQvSg9KB0oAWiiigAooooAKKKKACii igBv8VOpo+8adQAUUUUAFFFFABRRRQAU1uop1NbtQA6iiigAooooAKKKKACiiigAooooAaOp p1IOppaACiiigAooooAKKKKACmntTqQ9qAFooooAKKKKACiikoAWiiigBD0oHSg9KB0oAWii igAooooAKKKKACiiigBo+8adSDqaWgAooooAKKKKACiiigBCAetVbmygmXlAD6irdI1CEzDn 0VxzEwb2NUJbWaE/PGw/CuroKhhgjIp3CxxxHPNKkjJ91iPoa6WbTbaUH5Ap9RVCXQyDmOQE ehoApxajcxYxISPQ1di1s/8ALSMfgapS6Zcxk/u9w9qrvBKn3o2H1FFh3N5NYtm6lh+FSrqV qT/rAPrXM4OaDnNKwHUm+tv+eq0JeW5H+tX865bk0vNAHVC7gPSVfzpftUH/AD1T865Qk4pv NAHXC4hPSRfzpwkQ9GH51yAJA607e394/nQB1+RRXKLd3CDasjAfWpI9RuY+kpP1oA6iiufT WZx94K1TJrnHzRfkaANj+KnVmJrEBOWDD8KnXUrVhnzQPrQBcoqut5bt0mX86kE8TdJFP40A PpaYHU9GBp2RQAVzmsR7LskdG5ro81g64cyrigCfQ5yQ0RPTkVrN0rlbKcwTqw+hrplkV4g2 eDQBLnio1njdyiuCw7CsrVNQIHlRN9SKq6Rva8ByfegDo6WkHSjIoAWikyPWjI9aAFopu4eo pDIg6uPzoAfTE70hmiHWRfzqJbqBc5lQfjQBZpCAe1VjqFsOsq01tTtR/wAtBQBaCgdAKXAq gdYtR3Y/hUZ1qHsjGgDUorJOtoDxExH1pDridoj+dAGvRWMdb44i/WojrcueEUCgDcP3hS1g f2xOedq5qM6tdZ4cflQB0lJXMNqF0xyZT+FN+23JyfOb86AOpyPWmmRB1YfnXKNPKT/rGP40 0yP3J/OgDqmuYU+9Iv51E2oWqnBlWuXJooA6J9Yt1bAyfcCo21qIjhGrCoosBtHWwBgRH8TU L61OfuoorM2k9iakW3lf7sbH8KdguTSandSjBfA9uKrvI7feYmp0066ccRED3q3FosjYMjhR 6UWFcyetAjYjdtOPWukh0q3j5K7j71bEEYQoEUKe2KNA1OPA5q9YXUEB/ewg+9W7/SsZktx9 VrJ8tg+3ac+mKLdgOtgkSWIPHjaacvU1V0yJ4rRVfr1q0vU0DHUUUUgCiiigAooooAKKKKAG t1FOpp6inUAFFFFABRRRQAUUUUAFIelLSGgAHSlpB0paACiiigAooooAKKKKACkHWlpO5oAW iiigAooooAKKKKACiiigBp7UtB7UtADGiRuqKfwpjWsDdYl/KpqKLgV/sVtz+6XmojplqQf3 f61dop3FYzzpFtj+L86T+x7f1b860aKLsLGZ/Y0Ofvtio5NFGPklP4itekPSi4WMVdFY/wDL QAUo0WTJ/erj6VsjpRRcLGP/AGK2R+9GO/FSLosfG6Vj9BWpRRcLFJNJtUOSpb6mp0s7dPux KPwqeii7Cw0KF6AD6U6iikMKT+KlpO9AC0UUUAFFFFABRRRQAUUUUAIe1LSGloAKKKKACiii gAooooAKKKKAEHSlpB0paACiiigAooooAKKKKACm/wAVOpO9AC0UUUAFFFFABRRRQAUUUUAI 3SlpG6UtABRRRQAUUUUAFFFFABRRRQAgpaQUtABRRRQAUUUUAFFFFABSfxUtJ3oAWiiigAoo ooAKKKKACiiigBG6UDpQelA6UALRRRQAUUUUAFFFFABRRRQA1O9Opq96dQJBRRRQMKKKKAEp aSloAKQ9RS00/eFADqKKKACiiigAooooAKKKKAEPSgdKD0oHSgBaKKKACiiigAooooAKKKKA Gj7xp1NHU06gAooooAKKKKACiiigApD2paa3agB1FFFABRRRQAUUUUAFFFFACHpQvSg9KF6U ALRRRQAUUUUAFFFFABRRRQA0fep1N/iNOoAKKKKACiiigAooooAKa3anU1u1AMdRRRQAUUUU AFFFFABRRRQAUUUUARM5VumaXzP9k04AZNLTFZjPMP8AdNLv/wBk06igNRu8/wB00bz/AHTT qWgLDN/+yaN/+yadRQFmMD/7JpGc8cGpKQjkUBZiB/8AZNG//ZNOpaQajN/+yaN/HQ0+igBm /wD2TRv9jT6SmA3f/smjf/smnUUg1Gs/HQ0gfjoaeelA6Uw1G7/Y0b/9k06igNRpf2NG/wBj TqKA1G+Z7GjzPY06igNRvmexo8wehp1FINSMyYboaXzB6GnADJpaYrMZ5g9DSiQHsadRQPUb 5g9DRvHoadRSDUb5g9DR5g9DTqKA1Glx3BpryADipKRgCOaYO40SjHQ0okX3p2BRRoGo3zB7 0eYPenUUBqN3j3ppZW6rn6ipKKA1KzwWz/ehH5VC1haMceWR9Kv0YouKxQGn2gHEZpq2Fr3j NaOKRQBTuFmZ7abaMOFYVGdKtipALg1q4FGKLhZmOdIhxxI+fpUb6Rn7svHuK3MCjFFwsznn 0mUfddSKibTbgD7ufpXTYHpRgelF12Cz7nKm0nUcxt+VRmJ1OCp/KuuwPSk2Keqj8qV0PU5E hh2oIOK6lraFmyY1/KmvY2zjmJaNA1OX5o3EGuiOk2p/hI/Gmto9uRxuH40aAYIlkB+V2H40 8XM69JGH41rtosR6SMKhk0V1/wBXIG+tFkO5ni/uQMCVqgkkeQ5Zsn3q++kXI5AB/Gq7WNwB zC35UWC5WBwRzmtOLVikHlmPnHBFZ5hdeqkfhTWXBwc0rMAkfexY9TU1vdSW4/dtjPtUG0n1 NTJbStjbG35UJAStqF0f+Wx/Co/tU56yt+dWI9KunGQgH1NTDRZsDLKDTsK5SNzPj/Wt+dIZ 5iOZG/OtIaJJ3lFKuhnHMvP0osguZfmSZ++x/Gm7mPc/nWyNEQHmU/lThokXeRjRZAYZLepp CcmugGjW/dmNA0e3PXdn60aBc5/tS9q6MaTaj+En8acNMtR/yz/WjQDmSKXB7V1C2NsvSJak FvCB/q1/KjQDk9pPrRtrrRDEOka/lR5EX/PNfyo0DU5PY2OVOKcsEjchG/Kur8qPH3F/Kl2K Owo0DU5VbSY/8s2p62Nw3SM/jXTFAWHFLtHoKd0LU5sabcf3R+dSLpUx6soroNo9BRtHoKLo LMwv7Ibr5i/lTl0jI+aUZ9hW5tHpRtHpRdBZmKNHT+Kb8hUyaVar95mJrT2j0FG0egouFmUl 0+zX+AH6mpPstqo4iX8qs7R6CgqMdBSuFiJRCBgKo/CpAyDpigIMdBS7R6Ci4ahvX1o3r60b R6CjaPSkPUTevrS719aNo9BRtHpTDUN6+tM2Rb9+1d3rin7R6UbR6CgNQ3r600OuTzTto9KQ KMnigNRd6+tG9fWjaPQUbR6UBqG9fWjcvqKNo9BRtX0FINQ3L60bh60bF9KNo9KA1DcvqKNw 9aNq+lG0elAaiM4BFLvXHWmlFJ6U7YvpT0FqG9fUUbh60bV9KNq+lIeobh60bh6ijaPSjaPS gNRdw9aTcPWjaPSjaPSgNQ3D1FBYAdaNi+goKjHSgNQV1I4NG4etIEX0pdi+lAahuHrRuHqK Nq+lGxfSgNQ3D1o3D1o2L6CjYvpQGobh60bh6ijYvpRsX0oDUXI9abvG4jNLtHpTfLUnNMHc duX1o3D1o2L6UbF9KNA1F3D1o3D1pNi+lBRT2pBqLketGR60mwelGxfSgNRcj1oyPWk2L6Ub R6UBqBYDGTS5HrTSgPal2L6Uw1FyPWjI9aTYvpSeWvpSDUdketGR60mxfSjYvpQGouR60ZHr SbF9KNi+lAai5HrQSMUmxfSjYPSgNQVhjrS5HrTBGvpS7F9KegK47I9aMj1pNi+lGxfSkGou R60ZHrSbF9KTYvpQGo7I9aMj1pNg9KNi+lAai5HrSbhuxmk2L6Unlgt7Uw1H5HrRketN2L6U bF9KQajsj1oyKbsX0o2L6UBqOyPWjI9absX0o8tfSmGo7I9aM+9N8tfSjYvpSDUVmAxzS5Hr TSgNHlr6U9A1HZHrRketN2L6UbF9KQajsj1oyPWm+WtHlr6Uw1HZHrRkU3YvpRsX0pBqOyKM 03YvpS7BQGoAg96XNMES9aXy19KegajsijI9absX0o2L6Ug1HZFGRTdi0uwUBqLkUZpuxfSj YKA1HUmRu60mwUhjBNMNR+aMj1pgjWl2L6Ug1HZozTdi+lGxfSgNR2RRTdi+lLsFAai5ozTd go8taA1FYjFLkU1kBFAjUUw1HUU3YKNgpBqOopuwe9GwUBqOzRkU3y196PLWmGo6im7BRsFI NRQQe9LmmCMUvlr70wVx2aM03YKPLWkGo7IopojUUbBTDUdRTdg96PLFAajqQkA9aTYPekMY JoB3H0U3yx6mjYPegNR1FN8se9Hlj3oDUdRTdgo2D1NINR1FJsHvSbB6mgNRx6UZFNZBjvSC IepphqPopuwepo2D1NINR1FN8sepo8sepoDUdRTfLHqaNg9TQGo6im+WPU0CMD1phqCkHNOp gjGeppfLHqaNAVx1FN2D1NHl j1NINR1FN2D1NHlj1NMNR1FM8seppdg9TQGo6kJ5FJsHqaRo 8kcmgHcfRTfLGOpo2cdTSDUdRTfLHqaPLHqaA1HUU3yx6mgIB3NAajqKbsGepo2D1NMNRx6U DpTCgI6mgR4HU0Bdj6Kb5fPU0eXz1NAajqKaUz3NGz3NINR1FN2e5o2e5oDUdRTdnuaNnuaA 1FBGTS1H5eWPJp2z/aNMSbHUU3Z/tGjZ7mkPUdRTdnuaNnuaA1HUU3Z7mjZ/tGgNR1IxxjNJ s/2jSNHnuaYNsfRTBHx1NL5Y9TSC7HUU3yx6mjyx6mgNR1FN8sepo8v3NMNR1FN8sepo2D1N INR1IDkUmzjqaQR+5phdj6Kb5f8AtGjZ7mkGo6im7Pc0eX7mgNR9FM2e5o2e5oDUfRTNnuaN nuaAFz81LUfl5bqads9zTC7HUU3y/c0bPc0BqOopvlj1NGz3NINR1FN2e5o2e5oDUfTHPSjZ 7mmsnzA5poTuSClpKWkUFFFFABRRRQAUUUUAFFFFADR1NOpo6mnUAFFFFABRRRQAUUUUAFNP UU6mnqKAHUUUUAFFFFABRRRQAUUUUAI3Q0DpQelA6UALRRRQAUUUUAFFFFABRRRQAg6mlpo+ 8adQAUUUUAFFFFABRRRQAU1qdTW7UAOooooAKKKKACiiigAooooAShelLTV6UAOooooAKKKK ACiiigAooooAT+KlpP4qWgAooooAKKKKACkxS0UAMaNG6qD+FQzWcEo+aNc/SrNI3SncRVh0 62iO5Y+ferQAHQUUtK4wooooAKKKKACiiigApq96dTV70AOooooAKKKKACiiigAooooATvS0 0/eFOoAKKKKACiiigAooooAKQ9KWkPSgA7UtIOlLQAUUUUAFFFFABRRRQAUg6mlpo70AOooo oAKKKKACiiigAooooAQ9RS0h6iloAKKKKACiiigAooooAKQ9KWkPSgAHSlpB0paACiiigAoo ooAKKKKACkHWlpB1NAC0UUUAFFFFABRRRQAUUUUAIaWmnqKdQAUUUUAFFFFABRRRQAUh6UtI elAAOlLSDpS0AFFFFABRRRQAUUUUAFJ3paT+KgBaKKKACiiigAooooAKKKKAENLSHtS0AFFF FABRRRQAUUUUAFJS0lAAOlLSDpS0AFFFFABRRRQAUUUUAFJ/FS03vQA6iiigAooooAKKKKAC iiigBDS0h6UtABRRRQAUUUUAFFFFABRRRQAgpaQUtABRRRQAUUUUAFFFFABSfxUtJ/FQAtFF FABRRRQAUUUUAFFFFACN0oHShulA6UALRRRQAUUUUAFFFFABRRRQAgpaRaWgAooooAKKKKAC iiigApD1paafvCgB1FFFABRRRQAUUUUAFFFFACHpQKD0oHSgBaKKKACiiigAooooAKKKKAGj qadTR1NOoAKKKKACiiigAooooAKQ9qWmt2oAdRRRQAUUUUAFFFFABRRRQAh6UL0oPSgdKAFo oooAKKKKACiiigAooooAb/EadTf4qdQAUUUUAFFFFABRRRQAU1u1OprdqAYtLSUtABRRRQAU UUUAFFFFABRRRQA0dTTqaOpp1ABRRRQAUUUUAFFFFABTT1FOpp6igB1FFFABRRRQAUUUUAFF FFACN0oXoKD0oHQUALRRRQAUUUUAFFFFABRRRQA0dTTqaOpp1ABRRRQAUUUUAFFFFABTW7U6 mt2oAdRRRQAUUUUAFFFFABRRSUALSL0ooHSgBaKKKACiiigAooooAKKKKAG/xU6m/wAVOoAK KKKACiiigAooooAKRulLSN0oAKWkpaACiiigAooooAKKKKACmr3p1NXvQA6iiigAooooAKKK KACiiigBv8VOpv8AFTqACiiigAooooAKKKKACkPSlpD0oAO1LSDpS0AFFFFABRRRQAUUUUAF NHU06kHU0ALRRRQAUUUUAFFFFABRRRQA09RTqaeop1ABRRRQAUUUUAFFFFABSHpS0h6UAA6U tIOlLQAUUUUAFFFFABRRRQAUg6mlpB1NAC0UUUAFFFFABRRRQAUUUUAIe1LTT1FOoAKKKKAC iiigAooooAKQ9KWkPSgAXpS0i9KWgAooooAKKKKACiiigApvenU0feNADqKKKACiiigAoooo AKKKKAEPalpD2paACiiigAooooAKKKKACiikoAB0paRelLQAUUUUAFFFFABRRRQAUnelpO9A C0UUUAFFFFABRRRQAUUUUAIaWmtTqACiiigAooooAKKKKACiiigBB0paQdKWgAooooAKKKKA CiiigApO9LSfxUALRRRQAUUUUAFFFFABRRRQAjdKBQ3SgUALRRRQAUUUUAFFFFABRRRQA1e9 Opq96dQAUUUUAFFFFABRRRQAUh60tNP3hQA6iiigAooooAKKKKACiiigBD0oHSg9KB0oAWii igAooooAKKKKACiiigBo6mnU0dTTqACiiigAooooAKKKKACmt2p1NbqKAHUUUUAFFFFABRRR QAUUUUAIelC9KD0oHSgBaKKKACiiigAooooAKKKKAG/xU6mj7xp1ABRRRQAUUUUAFFFFABTW 7U6mt1FADqKSloAKKKKACiiigAooooAKKKKAGj7xp1NXqadQAUUUUAFFFFABRRRQAU09RTqa eooAdRRRQAUUUUAFFFFABRRRQAjfdNA6UN0NA6UALRRRQAUUUUAFFFFABRRRQA0dTTqaOpp1 ABRRRQAUUUUAFFFFABTW7U6mt2oBjqKSloAKKKKACiiigAooooAQ0L0oNC9KAFooooAKKKKA CiiigAooooAb/FTqb/FTqACiiigAooooAKKKKACmt0p1NbpQAopaSloAKKKKACiiigAooooA KavenU1e9ADqKKKACiiigAooooAKKKKAE70tN/ip1ABRRRQAUUUUAFFFFABSHpS0h6UAHalp B0paACiiigAooooAKKKKACmr1NOpB3oAWiiigAooooAKKKKACiiigBp6inU09RTqACiiigAo oooAKKKKACkPSlpD0oAB0paQdKWgAooooAKKKKACiiigApB1paQdTQAtFFFABRRRQAUUUUAF FFFADT1FOpp6inUAFFFFABRRRQAUUUUAFIelLSHpQAL0paRelLQAUUUUAFFFFABRRRQAU0da dTf4jQA6iiigAooooAKKKKACiiigBD2paQ9qWgAooooAKKKKACiiigApDS0lAAvSlpB0paAC iiigAooooAKKKKACk/ipaT+KgBaKKKACiiigAooooAKKKSgANLSGloAKKKKACiiigAooooAK KKKAEHSlpB0paACiiigAooooAKKKKACm/wAVOpP4qAFooooAKKKKACiiigAooooARulAoPSg UALRRRQAUUUUAFFFFABRRRQA1e9Opq96dQAUUUUAFFFFABRRRQAU0/eFOpO9AC0UUUAFFFFA BRRRQAUUUUAI3SgdKD0oHSgBaKKKACiiigAooooAKKKKAGjqadTR1NOoAKKKKACiiigAoooo AKa3anU1u1ADqKKKACiiigAooooAKKKKAEPShelB6UDpQAtFFFABRRRQAUUUUAFFFFADf4jT qb/EadQAUUUUAFFFFABRRRQAUxzyKfTW6igTHUUUUDCiiigAooooAKKKKACiiigBo6mlpoYb iM807NABS0mRRkUAFFGRRmgBaSjNGR60AFIRyKXIpGIGKAFoozRkUALRSZoyKAFpKMijIoAW ikyKM0AI3Q0o6UMeKRTkUCFpaSigYUUUUALRSZozQAUUUtADQPmNLSBhuI70tAkFFFFAwooo oAKKKWgBKRhnFOprHFAC0UUtACUUtFACUUtFACUUtFACHpSKMClpFORQA6kpaKAEopaKAEop aKAEopaKAG4+bNLSZG73p1ACUUtFACUUtFACUUtFACUjdKdSN0oABRRS0AJiilooASilooAS ilooASmr3p9NWgQtFLRQMSilooASilooASilooAb/EKWjvS0AJS0UUAJRS0UAJRS0UAJSN0p 1IelAAOlFA6UtACUUtFACUtFFABSUtFACUi55p1IO9ABRS0UAJS0UUAFJS0UAFJS0UANOcil pD1FOoAKSlooASilooAKKKKAEpG6U6kPSgAHSlpKWgBKKWigApKWigBOaKWigBKQdTTqTvQA UtFFABSUtFABSUtFABRRRQA1uopaD1FLQAlFLRQAUUUUAFJS0UAFIelLSGgBF6U6kHSloAKK KKACiiigAooooAKaPvGnUnegBaKKKACiiigAooooAKKKKAEPalpD2paACiiigBKWiigAoooo AKQ9KWkoARelLQOlLQAUUUUAFFFFABRRRQAU3+KnUnegBaKKKACkpaKAEopaKAEopaKAGtS0 GloAKKKKACkpaKAEopaKAEopaKAGjpS0DpS0AFFFFACUtFFABRRRQAlJ/FTqTvQAUUtFACUt FFABSUtFACUtFFACN0oFB6UUALRRRQAUUUUAJS0UUAJRS0UANU9aWgUtACUUtFABRRRQAlFL RQAlIc7hTqQ9aAFpKWigBKKWigBKWiigApKWigBrfdNKOgoPSgdKACilooAKSlooAKSlooAS ilooAYOpp1IOpp1ACUtFFABSUtFACUtFFACU1jyKfSHtQAUtFFABSUtFACUtFFACUtFFACHp SL0paB0oAWiiigApKWigBKKWigBKKWigBo+8aWjvS0AJRS0UAFJS0UAFFFFACU1j0p9NbtQJ i0tFFAwooooAKKKKACiiigAooooAaUB60nlr70+ii4rIZ5Yo8sU+ii4WQzy1o8tfSnUUBZDf LWjy19KdRQFkN8taDGpp1FAWQ3YtHlrTqKAshuxfSjy1p1FAWQ3y1o2Cn0UXCwzy19KPLWnU UBZDdgo2Cn0UXCyGeWPejyx70+ii4WQzyx70eWPU0+ii4WQzyx70eWKfRRcLIZ5Y96AgHc0+ ii4WRH5Qznml8sepp9FFwsiPyh6ml8sepp9FFwshnlj1NHlj1NPop3CyGeWPU0eWPU0+ilcL IZs9zQYwepNPop3CyGeXx1NJ5fuakoouFkM8sepo8v3NPoouFkM2e5o8v3NPopXCwzZ7mk8v /aNSUUXCyGeX/tGkEeOhNSUU7hZDPL9zRs/2jT6KVwshmz/aNHl/7Rp9FFwshmz/AGjSeX/t GpKKLhZDAmP4jRsP940+ii4WRH5fOcnNLsP940+incLIZs/2jRsP940+ilcLEew/3jS7D/eN Oop3Cwzyz/eNHln+8afRRcLIZ5Z/vGgxkj7xp9FFwshgjI/iNGw/3jT6KLhZDNh/vGl2H+9T qKLhYaUP940gQ/3jT6KLhYaUP940bT/ep1FAWG7D/eNIEI70+ii4WQ3af71G0/3qdRSCw3a3 96jaf7xp1FAWG7G/vUbT606imFhmxv71Ltb+9T6KVwsRlGP8VGxv71SUU7hZDNrf3qNrf3qf RQFiPa396l2t/ep9FAWGbW/vUbW/vU+ikFhm1v71JtY9Wp9LTCxGEYdGpdrf3qfRSuFhm1v7 1BVv71PooCwza396k2t/eqSigLDNretG1s/ep9FAWGbWz96k2MDkNT6Wi4WGYf1o2t/ep9FA WGYb1ow3rT6KAsMw3rRtf+9T6KAsM2v/AHqMP60+igLEbIxx81Lh/Wn0U7hYZh/WjD+tPopB YZh/UUYf+9T6KLhYZh/UUYf1p9FAWI8P6igq5GMipKKLhYjCuBgNS4f1p9FAWGYfPUUYf1FP ooCwzD+oow396n0UBYZhvWjDeop9FAWGfN6ik2tnINSUUBYZ8/tR83qKdRQFhuG9RS/N60tF AWG/N6ijD+op1FAWG/P6ij5/UU6igLDWDHuBR8/tTqKAsN+f2ow/qKdRQFhvz+1Hz+op1FAW G/P6ij5/anUUBYb8/tR859KdRQFhgDgdQaX5/anUUBYb8/tR8/tTqKAsN+f2o/ee1OooCw35 /aj5vanUUBYb8/tSbX3ZyKfRQFhvz+1Hz+1OooCw35/aj5/anUUBYb8/tR8/tTqKAsN+f2o+ f2p1FAWGMGIo/eY7U+imFhvz47UfP7U6ikFhvz+1Hz+1OooCw35/aj5/anUUBYb8/tR8/tTq KAsMAcehpfn9BTqKAsN+f2o+f2p1FAWGjf7UfPntinUUBYb8/tR8/tTqKAsJlvQU3D5zxT6K AsN+b0FHze1OooCw35/aj5/QU6igLDfm9qPn9qdRQFhvz+1GXz0FOooCww7z2ApRv9BT6Si4 WG5f0FGW9BT6KAsMy/oKMv6Cn0UBYZl/QUfP7U+igLDMv6CjL+gp9FAWIwHBPSly/oKdS0XC wzL+go+f0FPooCwz5vaj5/anUUBYb8/tRlvQU6igLDct6UhDZzxT6KAsNy/oKMv6Cn0UBYZl vQUZb0FOooCw3L+goy/oKfRQFhmW9BRlvQU+igLEbbiMYpQXA6U+incLDMt6UuW9KWikFhuW 9BRl/Sn0UBYZlvSjLegp9FAWGZb0oy392n0UBYjG8HpxS7m9KfRRcLDMv6UZb0p9FAWGbn/u 0bn/ALtPooCwzL/3aNz91p9FAWGZbutIdxOQKfRQFhu5v7tG5v7tPooCwzc392jc392n0UBY Zlv7tG5v7tPooCwzc392jc392n0UBYYSxH3aAWA6U+igLDNzf3aNz/3afRQFhm5v7tG5v7tP ooCwzLelGW9KdRQFhu5vSjc392n0UBYiBfJ44p25v7tPoouFhm5v7tG5v7tPooCwzc392jc3 92n0UBYZub+7Rub+7T6KAsR7n/u0jFyOFqSimFhoZscrRub+7T6KQWGbm/u0bm/u0+igLDNz f3aNzf3afRQFhm5v7tG5v7tPooCwzc2Pu0gZxwVqSigLDNzf3aNzf3afRQFhm5v7tG5v7tPo oCwwM392jc392n0UBYZub+7Rub+7T6KAsR5bdnFLub+7T6KAsM3N/do3N/dp9FAWGbm/u0bm /u0+igLDNzf3aNzf3afRQFhm5v7tISxI4xT6KYWCloopDCiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA/9k= --B_3401876150_7780812-- From mphmmr@gmail.com Thu Oct 20 11:14:31 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F41921F8B81 for ; Thu, 20 Oct 2011 11:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvGRoLh6gFN0 for ; Thu, 20 Oct 2011 11:14:30 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8FD021F8B75 for ; Thu, 20 Oct 2011 11:14:29 -0700 (PDT) Received: by wyh22 with SMTP id 22so3574357wyh.31 for ; Thu, 20 Oct 2011 11:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ih1ImrwJpIXOY+by1OJf4w46+81uYcf/k49JIBaGPik=; b=h4APJqhfvrnbqGd+15dZFoUWeiHT4YCL7wlp3cU5pkzs2VKWLcCg00pvdhOJZBBjT0 DIAxp8v8dREpgXdRqswYAVNnUEhwSLxhfMtQf+m7s1KIlW05Ki2cXmB675i+/9CBQB2K iUsHEmx1VFZ6BXejwM1IKt3jrwARZgOLHYiLU= MIME-Version: 1.0 Received: by 10.216.229.30 with SMTP id g30mr4295667weq.51.1319134467404; Thu, 20 Oct 2011 11:14:27 -0700 (PDT) Received: by 10.216.39.69 with HTTP; Thu, 20 Oct 2011 11:14:27 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Oct 2011 14:14:27 -0400 Message-ID: From: Michael Hammer To: Stephan Wenger Content-Type: multipart/alternative; boundary=0016e65b3fcc57332204afbeedfd Cc: "clue@ietf.org" Subject: Re: [clue] Kick-Off Item 5: description of composed pictures X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 18:14:31 -0000 --0016e65b3fcc57332204afbeedfd Content-Type: text/plain; charset=ISO-8859-1 Stephan, What I am getting from this description is that you want the aggregated feed composed of original feeds 1 and 2 to have sufficient data about the original feeds to enable an output site to do a de-aggregation of feed 3 back into its components and to put on available displays as desired. That sort of goal seems reasonable. That would require that the mixing or aggregation process leaves the feed 1 and 2 segregated within the feed 3. I imagine that some mixers might not do that, but it would provide flexibility. So, you might need a de-composable flag in addition to distinguish if that can be done. Anyway, that slides into the design. Mike On Wed, Oct 19, 2011 at 4:35 PM, Stephan Wenger wrote: > Mike, > > Not sure this is going through to the list, due to the size of the > attachment. But let's try. > > Attached is a little hand-drawing that hopefully helps understanding what I > am shooting for. > Consider a three way conference. The two "capturing" rooms, depicted on > the left side, have two cameras each, capturing scenes one and two (for the > first room), and four and five (for the second room), respectively. The > captured content is encoded by encoders marked "E" to create RTP streams 1, > 2, 4, and 5. > RTP streams 1 and 2 (from the first room) terminate an an MCU, which > composes them into a composed picture 3, encoded into RTP stream 3. The > composed picture contains 1 and 2 side-by-side, plus grey bars on top and > bottom. > The monitors of the receiving third endpoint are shown on the right side. > Streams 4 and 5 go straight to the two decoders of the main projection > wall. Stream 3 (created by the MCU) goes through a side decoder to a third > monitor (could be the monitors that many telepresence rooms have for each > participant, a monitor normally dedicated for shared content, what not). > This monitor shows the composed image. > > The CLUE architecture allows perfectly well to describe the capture > properties of streams 4 and 5. However, at present, the MCU hides the > capture properties of streams 1 and 2. Similarly, the MCU hides the render > properties of the decoder/display of stream 3. Accordingly, the geographic > parameters of captures 1 and 2 are not known at decoder 3, and, if that > decoder would want to do something a bit more sophisticated than just > decoding and displaying on the screen, it couldn't because it lacks info. > > One of this "more sophisticated" things could, for example be as follows. > Suppose the endpoint capturing 4 and 5 drops out of the call. The video > wall of the rendering endpoint goes blank. It would be desirable if the > info from 1 and 2 would be rendered on the video wall instead of the side > screen. One sensible way to do that would be that the stream 3 is feed into > both decoders responsible for the video wall, but "cut out" and upscale the > content from the composed picture created by the MCU, before rendering. > (There may be technical reasons for the presence of the MCU beyond the fact > that there are only three decoders at the receiving side). However, that's > not possible as the nature of stream 3 (being composed form 1 and 2) is not > visible at the rendering endpoint. > > My proposal is to add information related to the captures inside a composed > stream (beyond that one flag that says the stream is composed). > > Clearer? > > Stephan > > > > > > From: Michael Hammer > Date: Sat, 15 Oct 2011 13:03:07 -0400 > To: Stephan Wenger > Cc: "clue@ietf.org" > Subject: Re: [clue] Kick-Off Item 5: description of composed pictures > > Stephan, > > You use monitor as both input and output device. I hope that is not > embedded in the scheme. > The rest of this email seems to focus only on input definitions as it > probably should. > > Don't understand the comment about 3-D followed by coordinates in 3-D. It > seems like 3-D is fundamental. > > Do I understand correctly that the camera coordinates define the location > of the lense, while the bitstream is abstraction of the pixel layout for > some abstraction (via ray-tracing?) of a window? > > Or is the camera coordinates defining some virtual window in space that > through some changes in focal length could be a closeup and those farther > from the camera and narrower field of view versus wider angel and closer to > the lense with greater field of view? > > When talking about spatial things, perhaps a picture would help save a > thousand words. > > Also, I would think that what a renderer or MCU would do could be a second > discussion once the capture scheme is better understood. (Understand that > the impacts of those might drive some iterations on the basic scheme.) > > Mike > > On Fri, Oct 14, 2011 at 11:02 PM, Stephan Wenger wrote: > >> Hi, >> >> Here is the kickoff message as agreed in our F2F. >> >> We are in the process of defining a mechanism that allows us to tag in >> room "coordinates" of captures to RTP streams. In its most trivial >> incarnation, that would allow us to assign the decoded RTP streams to >> devices such as individual monitors. >> >> RTP comes from system 1, camera coordinates x, y, z, upper right x, >> y, z, lower left x, y, z >> RTP comes from system 1, camera coordinates (something else) >> >> Note that we probably need a third and even a fourth point for faithfully >> specifying a capture in 3D space, but that's not the subject of this email, >> so don't beat me up on it right now. >> >> As for the capabilities of a renderer (not defined in the framework yet), >> it should be clear that a monitor can trivially display more than one >> decoded RTP stream. Insofar, the mapping should be per part of a virtual >> display wall (or however you want to call it), and not per physical screen. >> I would hope that this is uncontroversial. >> >> Things become more tricky when there is a video mixing MCU in the picture, >> or when an endpoint creates a single RTP stream that contains information >> from multiple camera devices (through tiling, picture-in-picture). Here, we >> cannot meaningfully tag the a single geographic information to a single RTP >> stream simply because the multiple video sequences were mixed at the sample >> level, and the encoder didn't have a clue that it is actually encoding data >> stemming from more than one camera. However, the endpoint system (or the >> MCU) know the geographic metadata associated with the composed picture. So >> what I'm proposing is that we allow a single RTP stream to have more than >> one geometric information about the capture involved. For video, one would >> probably have to associate regions of the reconstructed video stream (in the >> spatial dimension) with capture geographic information as currently proposed >> in the framework. >> >> Example: a sending endpoint creating ONE RTP stream which includes TWO >> captures, tiled horizontally >> >> RTP { >> bitstream coordinates x=0 to 959, y=0, to 1080 , comes from system 1, >> camera coordinates x, y, z, x, y,z x, y, z >> bitstream coordinates x=960 to 1919, y=0 to 1080, comes from system 1, >> camera coordinates (something else) >> } >> >> Architecturally, this system would best need to be recursive, as it ought >> to be possible to throw an already composed image from MCU1 at the input of >> MCU2, which scales it down and composes it with other images to other ports. >> >> Clear enough? >> >> Thanks, >> Stephan >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --0016e65b3fcc57332204afbeedfd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Stephan,
=A0
What I am getting from this descripti= on is that you want the aggregated feed composed of original feeds 1 and 2 = to have sufficient data about the original feeds to enable an output site t= o do a de-aggregation of feed 3 back into its components and to put on avai= lable displays as desired.
=A0
That sort of goal seems reasonable.=A0 That would requir= e that the mixing or aggregation process leaves the feed 1 and 2 segregated= within the feed 3.=A0 I imagine that some mixers might not do that, but it= would provide flexibility.=A0 So, you might need a de-composable flag in a= ddition to distinguish if that can be done.=A0 Anyway, that slides into the= design.
=A0
Mike

On Wed, Oct= 19, 2011 at 4:35 PM, Stephan Wenger <stewe@stewe.org> wrote:
Mike,

Not = sure this is going through to the list, due to the size of the attachment. = =A0But let's try.

Attached is a little hand-drawing that hopefully helps = understanding what I am shooting for.
Consider a three way confer= ence. =A0The two "capturing" rooms, depicted on the left side, ha= ve two cameras each, capturing scenes one and two (for the first room), and= four and five (for the second room), respectively. =A0The captured content= is encoded by encoders marked "E" to create RTP streams 1, 2, 4,= and 5.
RTP streams 1 and 2 (from the first room) terminate an an MCU, which c= omposes them into a composed picture 3, encoded into RTP stream 3. =A0The c= omposed picture contains 1 and 2 side-by-side, plus grey bars on top and bo= ttom. =A0
The monitors of the receiving third endpoint are shown on the right si= de. =A0Streams 4 and 5 go straight to the two decoders of the main projecti= on wall. =A0Stream 3 (created by the MCU) goes through a side decoder to a = third monitor (could be the monitors that many telepresence rooms have for = each participant, a monitor normally dedicated for shared content, what not= ). =A0This monitor shows the composed image.

The CLUE architecture allows perfectly well to describe= the capture properties of streams 4 and 5. =A0However, at present, the MCU= hides the capture properties of streams 1 and 2. =A0Similarly, the MCU hid= es the render properties of the decoder/display of stream 3. =A0Accordingly= , the geographic parameters of captures 1 and 2 are not known at decoder 3,= and, if that decoder would want to do something a bit more sophisticated t= han just decoding and displaying on the screen, it couldn't because it = lacks info.

One of this "more sophisticated" things could= , for example be as follows. =A0Suppose the endpoint capturing 4 and 5 drop= s out of the call. =A0The video wall of the rendering endpoint goes blank. = =A0It would be desirable if the info from 1 and 2 would be rendered on the = video wall instead of the side screen. =A0One sensible way to do that would= be that the stream 3 is feed into both decoders responsible for the video = wall, but "cut out" and upscale the content from the composed pic= ture created by the MCU, before rendering. =A0(There may be technical reaso= ns for the presence of the MCU beyond the fact that there are only three de= coders at the receiving side). =A0However, that's not possible as the n= ature of stream 3 (being composed form 1 and 2) is not visible at the rende= ring endpoint.

My proposal is to add information related to the captur= es inside a composed stream (beyond that one flag that says the stream is c= omposed).

Clearer?

Stepha= n =A0 =A0





=
From: Michael Hammer <mphmmr@gmail.com>
= Date: Sat, 15 Oct 2011 13:03:07 = -0400
To: Stephan Wenger <stewe@stewe.org>
Cc: "clue@ietf.org" <clue@ietf.org>
Subject: Re: [clue] Kick-Off Ite= m 5: description of composed pictures

Stephan,
=A0
You use monito= r as both input and output device.=A0 I hope that is not embedded in the sc= heme.
The rest of this email seems to focus only on input definitions as it = probably should.
=A0
Don't understand the comment a= bout 3-D followed by coordinates in 3-D.=A0 It seems like 3-D is fundamenta= l.
=A0
Do I understand correctly that the camera coordinates de= fine the location of the lense, while the bitstream is abstraction of the p= ixel layout for some abstraction (via ray-tracing?) of a window?
=A0
Or is the camera coordinates defining some virtual window in = space that through some changes in focal length could be a closeup and thos= e farther from the camera and narrower field of view versus wider angel and= closer to the lense with greater field of view?
=A0
When talking about spatial things, perhaps a picture wou= ld help save a thousand words.
=A0
Also, I would think = that what=A0a renderer or MCU would do=A0could be a second discussion once = the capture scheme is better understood.=A0 (Understand that the impacts of= those might drive some iterations on the basic scheme.)
=A0
Mike

On Fri, Oct= 14, 2011 at 11:02 PM, Stephan Wenger <stewe@stewe.org> wrote:=
Hi,

Here i= s the kickoff message as agreed in our F2F.

We are= in the process of defining a mechanism that allows us to tag in room "= ;coordinates" of captures to RTP streams. =A0In its most trivial incar= nation, that would allow us to assign the decoded RTP streams to devices su= ch as individual monitors.

RTP <id#1> comes from system 1, camera coordinate= s x, y, z, upper right x, y, z, lower left x, y, z=A0
RTP <id#= 2> comes from system 1, camera coordinates (something else)

Note that we probably need a third and even a fourth point f= or faithfully specifying a capture in 3D space, but that's not the subj= ect of this email, so don't beat me up on it right now.=A0

As for the capabilities of a renderer (not defined in the fr= amework yet), it should be clear that a monitor can trivially display more = than one decoded RTP stream. =A0Insofar, the mapping should be per part of = a virtual display wall (or however you want to call it), and not per physic= al screen. =A0I would hope that this is uncontroversial.

Things become more tricky when there is a video mixing = MCU in the picture, or when an endpoint creates a single RTP stream that co= ntains information from multiple camera devices (through tiling, picture-in= -picture). =A0Here, we cannot meaningfully tag the a single geographic info= rmation to a single RTP stream simply because the multiple video sequences = were mixed at the sample level, and the encoder didn't have a clue that= it is actually encoding data stemming from more than one camera. =A0Howeve= r, the endpoint system (or the MCU) know the geographic metadata associated= with the composed picture. =A0So what I'm proposing is that we allow a= single RTP stream to have more than one geometric information about the ca= pture involved. =A0For video, one would probably have to associate regions = of the reconstructed video stream (in the spatial dimension) with capture g= eographic information as currently proposed in the framework.

Example: a sending endpoint creating ONE RTP stream whi= ch includes TWO captures, tiled horizontally

RTP &= lt;id#2> {
=A0 =A0 bitstream coordinates x=3D0 to 959, y=3D0, = to 1080 , comes from system 1, camera coordinates x, y, z, x, y,z x, y, z
=A0 =A0 bitstream coordinates x=3D960 to 1919, y=3D0 to 1080, comes fr= om system 1, camera coordinates (something else)=A0
}
<= br>
Architecturally, this system would best need to be recursive,= as it ought to be possible to throw an already composed image from MCU1 at= the input of MCU2, which scales it down and composes it with other images = to other ports.

Clear enough?

Thanks,
Stephan


___________________________________= ____________
clue mailing list
clu= e@ietf.org
https://www.ietf.org/mailman/listinfo/clue



_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


--0016e65b3fcc57332204afbeedfd-- From stewe@stewe.org Thu Oct 20 12:05:16 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09F11F0C36 for ; Thu, 20 Oct 2011 12:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=-0.677, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYSxCt-XWfYG for ; Thu, 20 Oct 2011 12:05:15 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD9821F8753 for ; Thu, 20 Oct 2011 12:05:14 -0700 (PDT) Received: from [192.168.1.64] (unverified [71.202.147.60]) by stewe.org (SurgeMail 3.9e) with ESMTP id 51888-1743317 for multiple; Thu, 20 Oct 2011 21:05:12 +0200 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Thu, 20 Oct 2011 12:05:01 -0700 From: Stephan Wenger To: Michael Hammer Message-ID: Thread-Topic: [clue] Kick-Off Item 5: description of composed pictures In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3401957112_12617473" X-Originating-IP: 71.202.147.60 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.147.60) was found in the spamhaus database. http://www.spamhaus.net Cc: "clue@ietf.org" Subject: Re: [clue] Kick-Off Item 5: description of composed pictures X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 19:05:17 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3401957112_12617473 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Mike, > From: Michael Hammer > That sort of goal seems reasonable. That would require that the mixing or > aggregation process leaves the feed 1 and 2 segregated within the feed 3. I > imagine that some mixers might not do that, but it would provide flexibility. > So, you might need a de-composable flag in addition to distinguish if that can > be done. Anyway, that slides into the design. The use case I was referring to is that the MCU performs video mixing in the traditional way MCUs perform tiling (that is: reconstruction of the video streams, aggregation on the pixel level, encoding). In other words, feed 3 is a single RTP stream containing a single coded video stream. To decompose that stream, you need spatial information in the renderer domain where each image is located in the tiled composed image. That is what I want to add, in addition to the "decomposable" flag you are suggesting (which would simply be an indication that the spatial information is present for this RTP stream). Stephan From: Michael Hammer Date: Thu, 20 Oct 2011 14:14:27 -0400 To: Stephan Wenger Cc: "clue@ietf.org" Subject: Re: [clue] Kick-Off Item 5: description of composed pictures Stephan, What I am getting from this description is that you want the aggregated feed composed of original feeds 1 and 2 to have sufficient data about the original feeds to enable an output site to do a de-aggregation of feed 3 back into its components and to put on available displays as desired. That sort of goal seems reasonable. That would require that the mixing or aggregation process leaves the feed 1 and 2 segregated within the feed 3. I imagine that some mixers might not do that, but it would provide flexibility. So, you might need a de-composable flag in addition to distinguish if that can be done. Anyway, that slides into the design. Mike On Wed, Oct 19, 2011 at 4:35 PM, Stephan Wenger wrote: > Mike, > > Not sure this is going through to the list, due to the size of the attachment. > But let's try. > > Attached is a little hand-drawing that hopefully helps understanding what I am > shooting for. > Consider a three way conference. The two "capturing" rooms, depicted on the > left side, have two cameras each, capturing scenes one and two (for the first > room), and four and five (for the second room), respectively. The captured > content is encoded by encoders marked "E" to create RTP streams 1, 2, 4, and > 5. > RTP streams 1 and 2 (from the first room) terminate an an MCU, which composes > them into a composed picture 3, encoded into RTP stream 3. The composed > picture contains 1 and 2 side-by-side, plus grey bars on top and bottom. > The monitors of the receiving third endpoint are shown on the right side. > Streams 4 and 5 go straight to the two decoders of the main projection wall. > Stream 3 (created by the MCU) goes through a side decoder to a third monitor > (could be the monitors that many telepresence rooms have for each participant, > a monitor normally dedicated for shared content, what not). This monitor > shows the composed image. > > The CLUE architecture allows perfectly well to describe the capture properties > of streams 4 and 5. However, at present, the MCU hides the capture properties > of streams 1 and 2. Similarly, the MCU hides the render properties of the > decoder/display of stream 3. Accordingly, the geographic parameters of > captures 1 and 2 are not known at decoder 3, and, if that decoder would want > to do something a bit more sophisticated than just decoding and displaying on > the screen, it couldn't because it lacks info. > > One of this "more sophisticated" things could, for example be as follows. > Suppose the endpoint capturing 4 and 5 drops out of the call. The video wall > of the rendering endpoint goes blank. It would be desirable if the info from > 1 and 2 would be rendered on the video wall instead of the side screen. One > sensible way to do that would be that the stream 3 is feed into both decoders > responsible for the video wall, but "cut out" and upscale the content from the > composed picture created by the MCU, before rendering. (There may be > technical reasons for the presence of the MCU beyond the fact that there are > only three decoders at the receiving side). However, that's not possible as > the nature of stream 3 (being composed form 1 and 2) is not visible at the > rendering endpoint. > > My proposal is to add information related to the captures inside a composed > stream (beyond that one flag that says the stream is composed). > > Clearer? > > Stephan > > > > > > From: Michael Hammer > Date: Sat, 15 Oct 2011 13:03:07 -0400 > To: Stephan Wenger > Cc: "clue@ietf.org" > Subject: Re: [clue] Kick-Off Item 5: description of composed pictures > > Stephan, > > You use monitor as both input and output device. I hope that is not embedded > in the scheme. > The rest of this email seems to focus only on input definitions as it probably > should. > > Don't understand the comment about 3-D followed by coordinates in 3-D. It > seems like 3-D is fundamental. > > Do I understand correctly that the camera coordinates define the location of > the lense, while the bitstream is abstraction of the pixel layout for some > abstraction (via ray-tracing?) of a window? > > Or is the camera coordinates defining some virtual window in space that > through some changes in focal length could be a closeup and those farther from > the camera and narrower field of view versus wider angel and closer to the > lense with greater field of view? > > When talking about spatial things, perhaps a picture would help save a > thousand words. > > Also, I would think that what a renderer or MCU would do could be a second > discussion once the capture scheme is better understood. (Understand that the > impacts of those might drive some iterations on the basic scheme.) > > Mike > > On Fri, Oct 14, 2011 at 11:02 PM, Stephan Wenger wrote: >> Hi, >> >> Here is the kickoff message as agreed in our F2F. >> >> We are in the process of defining a mechanism that allows us to tag in room >> "coordinates" of captures to RTP streams. In its most trivial incarnation, >> that would allow us to assign the decoded RTP streams to devices such as >> individual monitors. >> >> RTP comes from system 1, camera coordinates x, y, z, upper right x, y, >> z, lower left x, y, z >> RTP comes from system 1, camera coordinates (something else) >> >> Note that we probably need a third and even a fourth point for faithfully >> specifying a capture in 3D space, but that's not the subject of this email, >> so don't beat me up on it right now. >> >> As for the capabilities of a renderer (not defined in the framework yet), it >> should be clear that a monitor can trivially display more than one decoded >> RTP stream. Insofar, the mapping should be per part of a virtual display >> wall (or however you want to call it), and not per physical screen. I would >> hope that this is uncontroversial. >> >> Things become more tricky when there is a video mixing MCU in the picture, or >> when an endpoint creates a single RTP stream that contains information from >> multiple camera devices (through tiling, picture-in-picture). Here, we >> cannot meaningfully tag the a single geographic information to a single RTP >> stream simply because the multiple video sequences were mixed at the sample >> level, and the encoder didn't have a clue that it is actually encoding data >> stemming from more than one camera. However, the endpoint system (or the >> MCU) know the geographic metadata associated with the composed picture. So >> what I'm proposing is that we allow a single RTP stream to have more than one >> geometric information about the capture involved. For video, one would >> probably have to associate regions of the reconstructed video stream (in the >> spatial dimension) with capture geographic information as currently proposed >> in the framework. >> >> Example: a sending endpoint creating ONE RTP stream which includes TWO >> captures, tiled horizontally >> >> RTP { >> bitstream coordinates x=0 to 959, y=0, to 1080 , comes from system 1, >> camera coordinates x, y, z, x, y,z x, y, z >> bitstream coordinates x=960 to 1919, y=0 to 1080, comes from system 1, >> camera coordinates (something else) >> } >> >> Architecturally, this system would best need to be recursive, as it ought to >> be possible to throw an already composed image from MCU1 at the input of >> MCU2, which scales it down and composes it with other images to other ports. >> >> Clear enough? >> >> Thanks, >> Stephan >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --B_3401957112_12617473 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Mike,

From: Michael Hammer <mphmmr@gmail.com>
That = sort of goal seems reasonable.  That would require that the mixing or a= ggregation process leaves the feed 1 and 2 segregated within the feed 3.&nbs= p; I imagine that some mixers might not do that, but it would provide flexib= ility.  So, you might need a de-composable flag in addition to distingu= ish if that can be done.  Anyway, that slides into the design.

The use case I was referring to is that the MC= U performs video mixing in the traditional way MCUs perform tiling (that is:= reconstruction of the video streams, aggregation on the pixel level, encodi= ng).  In other words, feed 3 is a single RTP stream containing a single= coded video stream.  To decompose that stream, you need spatial inform= ation in the renderer domain where each image is located in the tiled compos= ed image.  That is what I want to add, in addition to the "decomposable= " flag you are suggesting (which would simply be an indication that the spat= ial information is present for this RTP stream).

St= ephan

From: Michael = Hammer <mphmmr@gmail.com>
Date: Thu, 20 Oct 2011 14:14:27 -0400To: Stephan Wenger <stewe@stewe.org>
Cc: "clue@ietf.org" <clue@ietf.org>
Subject: Re: [clue] Kick-Off Item 5: description of composed pic= tures

Stephan,
 
What = I am getting from this description is that you want the aggregated feed comp= osed of original feeds 1 and 2 to have sufficient data about the original fe= eds to enable an output site to do a de-aggregation of feed 3 back into its = components and to put on available displays as desired.
 
That sort of goal seems reasonable.  That would require that the= mixing or aggregation process leaves the feed 1 and 2 segregated within the= feed 3.  I imagine that some mixers might not do that, but it would pr= ovide flexibility.  So, you might need a de-composable flag in addition= to distinguish if that can be done.  Anyway, that slides into the desi= gn.
 
Mike

On= Wed, Oct 19, 2011 at 4:35 PM, Stephan Wenger <stewe@stewe.org> wrote:
Mike,

Not sure this is going through to the list, due to the size of the attach= ment.  But let's try.

Attached is a little han= d-drawing that hopefully helps understanding what I am shooting for.
Consider a three way conference.  The two "capturing" rooms, depicte= d on the left side, have two cameras each, capturing scenes one and two (for= the first room), and four and five (for the second room), respectively. &nb= sp;The captured content is encoded by encoders marked "E" to create RTP stre= ams 1, 2, 4, and 5.
RTP streams 1 and 2 (from the first room) term= inate an an MCU, which composes them into a composed picture 3, encoded into= RTP stream 3.  The composed picture contains 1 and 2 side-by-side, plu= s grey bars on top and bottom.  
The monitors of the receivin= g third endpoint are shown on the right side.  Streams 4 and 5 go strai= ght to the two decoders of the main projection wall.  Stream 3 (created= by the MCU) goes through a side decoder to a third monitor (could be the mo= nitors that many telepresence rooms have for each participant, a monitor nor= mally dedicated for shared content, what not).  This monitor shows the = composed image.

The CLUE architecture allows perfec= tly well to describe the capture properties of streams 4 and 5.  Howeve= r, at present, the MCU hides the capture properties of streams 1 and 2. &nbs= p;Similarly, the MCU hides the render properties of the decoder/display of s= tream 3.  Accordingly, the geographic parameters of captures 1 and 2 ar= e not known at decoder 3, and, if that decoder would want to do something a = bit more sophisticated than just decoding and displaying on the screen, it c= ouldn't because it lacks info.

One of this "more so= phisticated" things could, for example be as follows.  Suppose the endp= oint capturing 4 and 5 drops out of the call.  The video wall of the re= ndering endpoint goes blank.  It would be desirable if the info from 1 = and 2 would be rendered on the video wall instead of the side screen.  = One sensible way to do that would be that the stream 3 is feed into both dec= oders responsible for the video wall, but "cut out" and upscale the content = from the composed picture created by the MCU, before rendering.  (There= may be technical reasons for the presence of the MCU beyond the fact that t= here are only three decoders at the receiving side).  However, that's n= ot possible as the nature of stream 3 (being composed form 1 and 2) is not v= isible at the rendering endpoint.

My proposal is to= add information related to the captures inside a composed stream (beyond th= at one flag that says the stream is composed).

Clea= rer?

Stephan    





From: Michael Hammer <mphmmr@gmail.com>
Date: Sat, 15 Oct 2011 13:03:07 -0400
To: Stephan Wenger <stewe@stewe.org>
Cc: "clue@ietf= .org" <clue@ietf.org>
Subject: Re: [clue] Kick-= Off Item 5: description of composed pictures

When talking about spatial things, perhaps a picture would help save a thou= sand words.
On Fri, Oct 14, 2011 at 11:02 PM, S= tephan Wenger <stewe@stewe.org> wrote:
Hi,

Here is the kic= koff message as agreed in our F2F.

We are in the pr= ocess of defining a mechanism that allows us to tag in room "coordinates" of= captures to RTP streams.  In its most trivial incarnation, that would = allow us to assign the decoded RTP streams to devices such as individual mon= itors.

RTP <id#1> comes from system 1, camera= coordinates x, y, z, upper right x, y, z, lower left x, y, z 
RTP <id#2> comes from system 1, camera coordinates (something else)<= /div>

Note that we probably need a third and even a fourt= h point for faithfully specifying a capture in 3D space, but that's not the = subject of this email, so don't beat me up on it right now. 
=
As for the capabilities of a renderer (not defined in the fra= mework yet), it should be clear that a monitor can trivially display more th= an one decoded RTP stream.  Insofar, the mapping should be per part of = a virtual display wall (or however you want to call it), and not per physica= l screen.  I would hope that this is uncontroversial.

Things become more tricky when there is a video mixing MCU in the pi= cture, or when an endpoint creates a single RTP stream that contains informa= tion from multiple camera devices (through tiling, picture-in-picture). &nbs= p;Here, we cannot meaningfully tag the a single geographic information to a = single RTP stream simply because the multiple video sequences were mixed at = the sample level, and the encoder didn't have a clue that it is actually enc= oding data stemming from more than one camera.  However, the endpoint s= ystem (or the MCU) know the geographic metadata associated with the composed= picture.  So what I'm proposing is that we allow a single RTP stream t= o have more than one geometric information about the capture involved.  = ;For video, one would probably have to associate regions of the reconstructe= d video stream (in the spatial dimension) with capture geographic informatio= n as currently proposed in the framework.

Example: = a sending endpoint creating ONE RTP stream which includes TWO captures, tile= d horizontally

RTP <id#2> {
  =   bitstream coordinates x=3D0 to 959, y=3D0, to 1080 , comes from system 1,= camera coordinates x, y, z, x, y,z x, y, z
    bitstrea= m coordinates x=3D960 to 1919, y=3D0 to 1080, comes from system 1, camera coordi= nates (something else) 
}

Architectu= rally, this system would best need to be recursive, as it ought to be possib= le to throw an already composed image from MCU1 at the input of MCU2, which = scales it down and composes it with other images to other ports.
<= br>
Clear enough?

Thanks,
Steph= an


___________________________________________= ____
clue mailing list
clue@ie= tf.org
https://www.ietf.org/mailman/listinfo/clue



_______________________________________= ________
clue mailing list
clue@ietf.org
https://w= ww.ietf.org/mailman/listinfo/clue

Mary.=A0

On Fri, Oct 7, 2011 at 6:58 PM, Roni Even <Even.roni@huawei.com> wrot= e:

OK,

I wil= l prepare a presentation on issues with the framework version 01 and the wa= y forward and would like to get some time to present it. It will be based o= n the issues I mentioned here and the comments I sent to the list.

I am = afraid that part of it will repeat other presentations but this is how you = want to handle it.

Roni

=A0

From:= Mary Barnes [mailto:mary.ietf.barnes@gmail.com] =
Sent: Friday, October 07, 2011 11:44 PM
To: Roni Even
Cc: Paul Kyzivat; clue@ietf.org


Subject: Re: [clue] interim meeting agenda for frame= work doc discussion

=A0

We would very much appre= ciate it if you could prepare a presentation. =A0The chairs have a proposed= agenda in terms of order of topics to be discussed, but it was the expecta= tion that the document authors lead the discussion, with the chairs facilit= ating in order to get consensus on specific issues. =A0Really, no different= than how we do things during the WG sessions - we just have more time to d= iscuss issues and we'll have the opportunity to revisit things if we ge= t stuck on a specific issue. =A0 I apologize as I should have put names aga= inst the agenda items to make that more clear. =A0

=A0

I don't recall that we told anyone to wait to submit ideas/draf= ts until the romanow-dispatch-framework document was updated. =A0That docum= ent is not a WG document - it is just the only proposal we have on the tabl= e that could be considered as a WG deliverable, but that decision has not b= een made by the WG. =A0We do need input from all WG members to determine th= e best approach for the CLUE framework deliverable. =A0

=A0

Thanks,

Mary.=A0

On Fri, Oct 7, 2011 at 4:31 PM, Roni Even <Even.roni@huawei.com> wrote:

Hi,
I think that the major topics I see for discu= ssion are:

1. The capture area, point and scale attributes.
2. Th= e architecture, relation between EPs, Scene, capture set and how does
presentation or presentations fit in the model.
3. Hierarchy of attribut= es, should they be available for each layer of the
model. Scene, capture= set, media captures?
4. Where should the protocol be specified, do we s= plit this document to two?
And what is the extensibility mechanism.
5. Relation of attributes and e= ncoding parameters to SDP (duplicate?)

I can prepare a presentation = but is this the chairs want to do it. I was
thinking that the chairs wil= l define the discussion topics, I know that the
framework is an individual draft but I was under the impression that thechairs will treat it as if we are discussing a WG document and not an
i= ndividual draft and this was the major reason for having the interim
meeting, discussing a WG document. I was considering to prepare an
indiv= idual draft with other members of the group, was told to wait and see
th= e new revision of the individual draft which is better than the previous one but I expect the discussion to be managed by the WG chairs and based on=
the document and other inputs including comments that were sent to the = list.

Please let me know if I should prepare a presentation or are t= he chairs
going to accumulate the issues and present them for better efficiency
Regards
Roni



>= -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On B= ehalf Of

> Paul Kyzivat
> Sent: Friday, Octobe= r 07, 2011 9:03 PM
> To: clue@ietf.org
> Subject: Re: [clue] interim meeting agenda= for framework doc discussion

>
> Roni,
>
> On 10/7= /11 2:16 PM, Roni Even wrote:
> > Hi Mary,
> >
> &g= t; I assume that the comments sent to the list before Monday will also
> be
> > discussed.
>
> It may be logistically diff= icult to formally address them all, since
> they may be happening con= currently with the development of the charts
> used to guide discussi= on. People who have provided comments recently
> would be well advised to be prepared to bring them up again in context=
> during the meeting.
>
> =A0 =A0 =A0 Thanks,
> = =A0 =A0 =A0 Paul
>
> > Roni
> >
> > *From:= *clue-bounces@ie= tf.org [mailto:clue-bounces@ietf.org] *On
> Behalf
> > Of *Mary Barnes
> > *Sent:* Friday, Octob= er 07, 2011 8:05 PM
> > *To:* Allyn Romanow (allyn)
> > *= Cc:* clue@ietf.org > > *Subject:* Re: [clue] interim meeting agenda for framework doc> discussion
> >
> > Hi folks,
> >
> &= gt; Per Allyn's note below, if you do have some ideas (which we very mu= ch
> > welcome) on particular issues that you would like to present, cha= rts
> > would be most helpful as we will have some remote particip= ants. The
> > chairs will need all charts (including for the frame= work) no later
> than
> > 5pm Eastern on Monday, October 10th. Any charts rece= ived after that
> time
> > may not be able to be presented a= s the chairs need to get them
> uploaded
> > and will be bus= y with other logistics prior to the meeting.
> >
> > Thanks,
> >
> > Mary.
> >=
> > On Fri, Oct 7, 2011 at 1:46 AM, Allyn Romanow (allyn)
>= <allyn@cisco.com
> > <mailto:a= llyn@cisco.com>> wrote:
> >
> > HI Folks,
&g= t; >
> > Here is a proposal for the framework portion of the in= terim meeting.
> >
> > Goal: Move the draft-romanow-clue-framework toward a= cceptance as a WG
> draft
> >
> > Agenda:
> &= gt;
> > Overview - 50 minutes
> >
> > *Overview = - presentation by draft authors of new material*
> >
> > .Area of capture
> >
> > .Segment = switching. VAD. What information in VAD
> >
> > *Issues*<= br>> >
> > .Area of Capture
> >
> > .3 mes= sage exchange - provider and consumer. Devices are both.
> >
> > oInitial capabilities message
> >
> &= gt; .Measurements - are degrees, radians necessary
> >
> >= ; .Definitions - Roni's email (unless it is sorted out on email)
> >
> > What are additional issues people feel need to be ag= reed upon that
> stand
> > in the way of the document becomi= ng a WG draft? In order to make
> > progress, the discussion will = be kept to identified issues. New ones
> can
> > be added during the meeting, of course.
> ><= br>> > If you have a particular viewpoint on an issue, it would help = to have
> > some slides to describe it
> >
> > > > _______________________________________________
> > clue= mailing list
> > clue@ietf.org <mailto:clue@ietf.org>
> > https://www.ietf.org/mailman/listinfo/clue
> >
>= >
> >
> > ___________________________________________= ____
> > clue mailing list
> > clue@ietf.org
> > https://www.ietf.org/mailman/= listinfo/clue
>
> _______________________________________________
> clue m= ailing list
> clue= @ietf.org
> https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing listclue@ietf.org
http= s://www.ietf.org/mailman/listinfo/clue

=A0

<= /div>


<= /body> --B_3401957112_12617473-- From internet-drafts@ietf.org Fri Oct 21 08:47:23 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37AD1F0C7A; Fri, 21 Oct 2011 08:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGjU8qscFkM4; Fri, 21 Oct 2011 08:47:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE281F0C62; Fri, 21 Oct 2011 08:47:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111021154723.15627.74629.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2011 08:47:23 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:47:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tEle= presence Working Group of the IETF. Title : Framework for Telepresence Multi-Streams Author(s) : Allyn Romanow Mark Duckworth Andrew Pepperell Brian Baldino Filename : draft-ietf-clue-framework-00.txt Pages : 32 Date : 2011-10-21 This memo offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple RTP streams. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-clue-framework-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-clue-framework-00.txt From Mark.Duckworth@polycom.com Fri Oct 21 09:13:28 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECB01F0C81 for ; Fri, 21 Oct 2011 09:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBnIS45dSoHu for ; Fri, 21 Oct 2011 09:13:28 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 25DB01F0C76 for ; Fri, 21 Oct 2011 09:13:26 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Fri, 21 Oct 2011 09:13:26 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 21 Oct 2011 09:13:46 -0700 Thread-Topic: New Version Notification for draft-ietf-clue-framework-00.txt Thread-Index: AcyQCLve/giThzaOSGeaeziUxuQSGAAAxaPA Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61CE300330@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [clue] FW: New Version Notification for draft-ietf-clue-framework-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 16:13:28 -0000 VGhpcyAtMDAgdmVyc2lvbiBvZiB0aGUgd29ya2luZyBncm91cCBmcmFtZXdvcmsgZG9jdW1lbnQg aGFzIG9ubHkgbWlub3IgY2hhbmdlcyBmcm9tIGRyYWZ0LXJvbWFub3ctY2x1ZS1mcmFtZXdvcmst MDE6DQotIFN3aXRjaCBvcmRlciBvZiBwcm92aWRlciBhbmQgY29uc3VtZXIgbWVzc2FnZSBzZWN0 aW9ucyB0byBtYXRjaCB0aGUgb3JkZXIgb2YgdGhlIG1lc3NhZ2UgZmxvdw0KLSBNb3ZlIGEgcGFy YWdyYXBoIGFib3V0IHRoZSBtZXNzYWdlIGZsb3cgZnJvbSB0aGUgbWVkaWEgY2FwdHVyZSBzZWN0 aW9uIHRvIHRoZSBtZXNzYWdlIHNlY3Rpb24NCi0gRml4IHNvbWUgdHlwb2dyYXBoaWNhbCBlcnJv cnMgYW5kIG90aGVyIG1pbm9yIGVkaXRvcmlhbCBjaGFuZ2VzDQoNCkkgcGxhbiB0byBzdWJtaXQg YSAtMDEgdmVyc2lvbiBuZXh0IHdlZWssIHdpdGggYSBmZXcgbW9yZSBjaGFuZ2VzIHRoZSB3b3Jr aW5nIGdyb3VwIGFncmVlZCBvbiBhdCB0aGUgaW50ZXJpbSBtZWV0aW5nLg0KDQpNYXJrIER1Y2t3 b3J0aA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IEZyaWRh eSwgT2N0b2JlciAyMSwgMjAxMSAxMTo0NyBBTQ0KVG86IER1Y2t3b3J0aCwgTWFyaw0KQ2M6IGJi YWxkaW5vQGNpc2NvLmNvbTsgRHVja3dvcnRoLCBNYXJrOyBhbGx5bkBjaXNjby5jb207IGFwZXBw ZXJlQGNpc2NvLmNvbQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1pZXRmLWNsdWUtZnJhbWV3b3JrLTAwLnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtaWV0Zi1jbHVlLWZyYW1ld29yay0wMC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBNYXJrIER1Y2t3b3J0aCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnku DQoNCkZpbGVuYW1lOgkgZHJhZnQtaWV0Zi1jbHVlLWZyYW1ld29yaw0KUmV2aXNpb246CSAwMA0K VGl0bGU6CQkgRnJhbWV3b3JrIGZvciBUZWxlcHJlc2VuY2UgTXVsdGktU3RyZWFtcw0KQ3JlYXRp b24gZGF0ZToJIDIwMTEtMTAtMTkNCldHIElEOgkJIGNsdWUNCk51bWJlciBvZiBwYWdlczogMzIN Cg0KQWJzdHJhY3Q6DQogICBUaGlzIG1lbW8gb2ZmZXJzIGEgZnJhbWV3b3JrIGZvciBhIHByb3Rv Y29sIHRoYXQgZW5hYmxlcyBkZXZpY2VzIGluIGENCiAgIHRlbGVwcmVzZW5jZSBjb25mZXJlbmNl IHRvIGludGVyb3BlcmF0ZSBieSBzcGVjaWZ5aW5nIHRoZQ0KICAgcmVsYXRpb25zaGlwcyBiZXR3 ZWVuIG11bHRpcGxlIFJUUCBzdHJlYW1zLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From stephane.cazeaux@orange.com Mon Oct 24 00:59:02 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AE721F8C6A for ; Mon, 24 Oct 2011 00:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgDaqb-LzLmE for ; Mon, 24 Oct 2011 00:59:01 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDDC21F8C69 for ; Mon, 24 Oct 2011 00:58:57 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B66DDAB0005; Mon, 24 Oct 2011 09:59:56 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 1EF6DAB0004; Mon, 24 Oct 2011 09:59:55 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr ([10.194.32.11]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Oct 2011 09:58:54 +0200 Received: from FTRDMB03.rd.francetelecom.fr ([fe80::4c06:6ece:ed2d:797e]) by FTRDCH01.rd.francetelecom.fr ([::1]) with mapi id 14.01.0270.001; Mon, 24 Oct 2011 09:58:53 +0200 From: To: , Thread-Topic: [clue] the presentation use case Thread-Index: AcxHlL8VW+C7KhbYQU2HJX/U8MKZpAFFKK/A///k6YCAAFO3gIAACg4AgAAqsQCAAFTQgP/uhI7ggCNGD4D/+k3aoIALuqeA/6gpJ1D/T+EmUP6bGiVA/TYXO6D6Wxnn4A== Date: Mon, 24 Oct 2011 07:58:53 +0000 Message-ID: References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com><4E309135.7070408@alum.mit.edu><001b01cc4cd6$77d28760$67779620$%roni@huawei.com><4E30DFDE.3040601@alum.mit.edu><9ECCF01B52E7AB408A7EB85352642141031F2E5E@ftrdmel0.rd.francetelecom.fr><4E314AD3.1030406@alum.mit.edu><4E403783.70706@alum.mit.edu><4E454723.4080501@alum.mit.edu><44C6B6B2D0CF424AA90B6055548D7A61CE060BFF@CRPMBOXPRD01.polycom.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D43087@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D43087@xmb-sjc-221.amer.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.193.117] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Oct 2011 07:58:54.0049 (UTC) FILETIME=[C64EAD10:01CC9222] Subject: Re: [clue] the presentation use case X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 07:59:02 -0000 Hi, Sorry for the delay in the response. My point does not concern what kind of document can be conveyed in the pres= entation stream, but the fact that the use case assumes that the presentati= on stream is a _video_ presentation stream (i.e. presentation is coded usin= g a video codec). The example of the excel doc aims to highlight that video= coding is not convenient to the readability of such document. A proposal is to use the wording "stream" or "presentation stream" instead = of "video stream", "video presentation stream" or "presentation video" in t= he section 3.4, so that the use case is more agnostic to the solution. Stephane. -----Message d'origine----- De=A0: Allyn Romanow (allyn) [mailto:allyn@cisco.com]=20 Envoy=E9=A0: lundi 10 octobre 2011 20:34 =C0=A0: CAZEAUX Stephane RD-BIZZ-CAE; clue@ietf.org Objet=A0: RE: [clue] the presentation use case Hi Stephane,=20 Could you supply the text that you would like to have added? It would good = to be very specific, rather than general, since that what the use cases are= - the specific scenarios of interest to you. Since xcel (over RTP) was your example, and as Mark said, it is currently c= overed, I'm not sure exactly what case you have in mind that is either not = already covered or in scope for the current charter. Thanks, Allyn > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > stephane.cazeaux@orange.com > Sent: Monday, October 10, 2011 10:30 AM > To: clue@ietf.org > Subject: Re: [clue] the presentation use case >=20 > Hi, >=20 > Thus I still think that the use case, as currently described, is too > restrictive. One could think that only the video based presentation is > considered within the use cases, while we probably all agree that CLUE > is more generic. Could it be appropriate to indicate explicitly in the > use case that other solutions for document sharing could also be > considered in the future? >=20 > St=E9phane. >=20 > -----Message d'origine----- > De=A0: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de > Duckworth, Mark > Envoy=E9=A0: vendredi 7 octobre 2011 19:51 > =C0=A0: clue@ietf.org > Objet=A0: Re: [clue] the presentation use case >=20 > Hi St=E9phane, >=20 > The CLUE framework is intended to handle any media type that is carried > over RTP. The framework document should be relating to "media > captures" and "media streams" in general, except when there is a need > to be more specific about video or audio or any other media type. > There are probably some places in the document where it would be better > to be more general, to make sure it applies to any media type where > appropriate. >=20 > So if you want to send excel sheet data over RTP, then CLUE should be > able to handle it regarding associating it with audio or giving it some > spatial relationship to other media streams, for example. >=20 > I think this is as far as CLUE should go with regard to document > sharing. I think additional use cases about document sharing are not > relevant to CLUE. My thinking is based on this statement from the CLUE > charter: >=20 > "The focus of this work is on multiple RTP audio and video streams. > Other media types may be considered, however development of > methodologies for them is not within the scope of this work." >=20 > Regards, > Mark Duckworth >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of stephane.cazeaux@orange.com > > Sent: Friday, October 07, 2011 7:25 AM > > To: clue@ietf.org > > Subject: [clue] the presentation use case > > > > Hi > > > > I will not be able to attend physically to the interim meeting. > > > > However I had a comment on the presentation use case, which I still > > consider we need to agree on. > > In the use case draft, the presentation use case is restricted to the > > video based solution. To me, it should be modified so that: > > - It does not restrict the solution to the video > > - It includes the need to share any kind of documents (including > > complex documents such as excel sheets) and the ability to have > remote > > control > > > > See below the discussion. > > > > Regards, > > St=E9phane. > > > > > > > > -----Message d'origine----- > > De=A0: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Envoy=E9=A0: vendred= i 12 > > ao=FBt 2011 17:31 =C0=A0: CAZEAUX Stephane RD-BIZZ-CAE Cc=A0: clue@ietf= .org > > Objet=A0: Re: [clue] Comment on the presentation use case > > > > On 8/12/11 4:48 AM, stephane.cazeaux@orange-ftgroup.com wrote: > > > Hi Paul, > > > > > > I understand your suggestion, and I am aware that it could be a > > solution. It certainly makes sense, but I am not sure of how it could > > be integrated in CLUE. To me, this is a matter of application > > integration, at application level. > > > > > > My suggestion is that we should think of a solution that provides > > more satisfying collaboration within telepresence, with the same > level > > of interoperability and multistream interaction as presentation video > > stream provides, but with more satisfying quality (video is not > > suitable for all kinds of shared documents) and more collaborative > > features. > > > I don't think that the kind of relationship that you suggest is the > > only solution. > > > > IMO the main thing is to not constrain the mechanism used for > > collaboration/web sharing. That stuff is evolving at "web speed". > > Anything you nail down that is constraining will be obsolete before > it > > gets out. > > > > (I've been looking more at RTCWEB recently, and I'm wondering if > > perhaps CLUE ought to be based on that.) > > > > Thanks, > > Paul (as individual) > > > > > Stephane. > > > > > > > > > -----Message d'origine----- > > > De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Envoy=E9 : lundi 8 > > > ao=FBt 2011 21:23 =C0 : CAZEAUX Stephane RD-BIZZ-CAE Cc : clue@ietf.o= rg > > > Objet : Re: [clue] Comment on the presentation use case > > > > > > On 8/8/11 11:56 AM, stephane.cazeaux@orange-ftgroup.com wrote: > > >> Hi, > > >> > > >> To me, it should be part of the telepresence protocols at least to > > enable the interoperability, as the presentation based on video > stream > > allows it. > > >> > > >> The point is that video stream is not convenient for the use cases > > >> I > > suggested. But it does not necessarily mean that we should bundle a > > full data sharing protocol with telepresence. Something simpler, like > > the RFB option of draft-garcia-mmusic-sdp-collaboration, could be a > > candidate. > > > > > > What I was suggesting is that maybe it would make sense to turn > > > those relationships "inside out". > > > > > > For instance when I use a collaboration tool like Webex, the > > > collaboration is set up first via the web, and defines the set of > > > participants. Then a voice session can be added. For pragmatic > > reasons, > > > the voice conferencing seems to be pretty distinct. (I'm not > certain > > how > > > webex handles video. I suspect it is doing it via the web, not the > > > telephony conference.) > > > > > > Its not hard to imagine the same sort of setup, but with a > > > multiparty telepresence session instead of the traditional voice > > > conference. In such a case, you would probably want the > > > collaboration tool (webex, > > or > > > whatever) to mediate the UI for the web collaboration, the roster, > > etc. > > > It might delegate a lot of that to the telepresence infrastructure. > > > > > > But that does raise some questions about how all the components fit > > > together. Is there a single screen for the collaboration session in > > > a telepresence room? What about input to that - keyboard, mouse, > etc.? > > Or > > > do we assume that each person in the room has their own computer > > > with input, display, etc. and maybe a way to slave the web > > > collaboration session to one or more of the big displays in the > room? > > > > > > What probably *can't* be done right now is nail down a particular > > > web collaboration service (e.g. Webex) or protocol. That does > > > complicate slaving the collaboration session to a screen, unless > its > > > done by > > having > > > someone connect a video connection to their own computer. > > > > > > Thanks, > > > Paul > > > > > >> Stephane. > > >> > > >> > > >> -----Message d'origine----- > > >> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la > > >> part > > de Paul Kyzivat > > >> Envoy=E9 : jeudi 28 juillet 2011 13:41 =C0 : CHATRAS Bruno RD-CORE-I= SS > > >> Cc : clue@ietf.org Objet : Re: [clue] Comment on the presentation > > >> use case > > >> > > >> On 7/28/11 2:37 AM, bruno.chatras@orange-ftgroup.com wrote: > > >>> I think we should take a look to > > >>> http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration- > 0 > > >>> 0 > > >> > > >> Maybe. But that is almost orthogonal to what I was suggesting. > > >> > > >> THanks, > > >> Paul > > >> (as individual) > > >> > > >>> Bruno > > >>> > > >>>> -----Message d'origine----- > > >>>> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la > > part de > > >>>> Paul Kyzivat > > >>>> Envoy=E9 : jeudi 28 juillet 2011 06:05 =C0 : Roni Even Cc : > > >>>> clue@ietf.org Objet : Re: [clue] Comment on the presentation use > > >>>> case > > >>>> > > >>>> On 7/27/11 11:28 PM, Roni Even wrote: > > >>>>> Hi, > > >>>>> HTTP is not defining a common data sharing protocol. WebEx may > > >>>>> be > > >>>> carried > > >>>>> over HTTP but the data sharing application is not standard. > What > > I > > >>>> meant is > > >>>>> that it can either be something that is a common data sharing > > >>>> protocol or > > >>>>> something that is carried as an RTP payload which require some > > common > > >>>>> defined protocol on top. > > >>>> > > >>>> I was being a bit tongue in cheek, though not entirely. > > >>>> Of course you are right - that if you want to push data to > > everybody > > >>>> you > > >>>> need more. > > >>>> > > >>>> But data sharing by pointing a video camera at a piece of paper > > >>>> is > > a > > >>>> tad > > >>>> out of date. Connecting the video port on a user's computer as a > > video > > >>>> source and distributing it with the other video is better than > > that. > > >>>> But > > >>>> its not nearly as convenient as webex or any of its competitors. > > >>>> > > >>>> It isn't entirely clear that its *necessary* to bundle the data > > sharing > > >>>> application with the telepresence protocols. Its kind of > limiting > > since > > >>>> the web apps evolve very rapidly. Perhaps we should be doing the > > >>>> opposite of that: providing a way to embed the control of the > > >>>> telepresence system into a web app. > > >>>> > > >>>> Thanks, > > >>>> Paul > > >>>> > > >>>>>> -----Original Message----- > > >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf > > >>>> Of > > >>>>>> Paul Kyzivat > > >>>>>> Sent: Thursday, July 28, 2011 1:29 AM > > >>>>>> To: clue@ietf.org > > >>>>>> Subject: Re: [clue] Comment on the presentation use case > > >>>>>> > > >>>>>> On 7/27/11 6:07 PM, Roni Even wrote: > > >>>>>>> Hi Stephane, > > >>>>>>> > > >>>>>>> Is there a standard protocol that is used for conveying this > > >>>>>>> information, is it RTP based. > > >>>>>> > > >>>>>> AFAIK this is often http. (E.g. webex) > > >>>>>> > > >>>>>>> To me this is a separate application that can be integrated > in > > the > > >>>>>>> application level and not as part of the multistream. > > >>>>>> > > >>>>>> I guess this depends on whether the support for it is > > >>>>>> integrated > > >>>> into > > >>>>>> the "room", or is just incidental equipment brought by the > > users, > > >>>> not > > >>>>>> formally related to the telepresence session. > > >>>>>> > > >>>>>> Thanks, > > >>>>>> Paul > > >>>>>> (speaking as an individual) > > >>>>>> > > >>>>>>> Roni > > >>>>>>> > > >>>>>>> *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > > Behalf Of > > >>>>>>> *stephane.cazeaux@orange-ftgroup.com > > >>>>>>> *Sent:* Thursday, July 21, 2011 2:33 PM > > >>>>>>> *To:* clue@ietf.org > > >>>>>>> *Subject:* [clue] Comment on the presentation use case* > > >>>>>>> > > >>>>>>> ** > > >>>>>>> > > >>>>>>> *Hi,* > > >>>>>>> > > >>>>>>> ** > > >>>>>>> > > >>>>>>> *The presentation use case as described in the use-cases > > document > > >>>> is > > >>>>>>> based on the assumption that the presentation stream relies > on > > a > > >>>>>> video > > >>>>>>> stream, and is limited to usage of presentation video > streams. > > But > > >>>> we > > >>>>>>> could also consider collaborative use cases, meaningful for > > >>>>>>> telepresence, which are not covered by the existing text.* > > >>>>>>> > > >>>>>>> *I propose to complete the existing text as follows:* > > >>>>>>> > > >>>>>>> ** > > >>>>>>> > > >>>>>>> *Furthermore, although most today's systems use video streams > > for > > >>>>>>> presentations, there are use cases where this is not > suitable. > > For > > >>>>>> example:* > > >>>>>>> > > >>>>>>> *- The professor which shares an electronic whiteboard (could > > be a > > >>>>>>> whiteboard application on a PC, with screen capture of the > PC) > > >>>> where > > >>>>>> all > > >>>>>>> students can participate. Students will take control of the > > shared > > >>>>>>> whiteboard in turns.* > > >>>>>>> > > >>>>>>> *- In a multipoint meeting, a shared document can be kept > > always > > >>>>>> visible > > >>>>>>> in a screen, while other documents are presented on other > > screens > > >>>>>> (with > > >>>>>>> possible in turns presentation). For instance, for the > purpose > > of > > >>>>>> shared > > >>>>>>> design document, notes taking, polls, etc. A shared document > > >>>> implies > > >>>>>>> that all participants can modify it in turns.* > > >>>>>>> > > >>>>>>> *"* > > >>>>>>> > > >>>>>>> ** > > >>>>>>> > > >>>>>>> ** > > >>>>>>> > > >>>>>>> *St ephane. v> > > >>>>>>> * > > >>>>>>> > > >>>>>>> * > > >>>>>>> * > > >>>>>>> > > >>>>>>> *_______________________________________________ > > >>>>>>> clue mailing list > > >>>>>>> clue@ietf.org > > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > > >>>>>>> * > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> clue mailing list > > >>>>>> clue@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/clue > > >>>>> > > >>>>> > > >>>> > > >>>> _______________________________________________ > > >>>> clue mailing list > > >>>> clue@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/clue > > >>> > > >> > > >> _______________________________________________ > > >> clue mailing list > > >> clue@ietf.org > > >> https://www.ietf.org/mailman/listinfo/clue > > >> > > > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Mon Oct 24 02:02:58 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D4D21F8C16 for ; Mon, 24 Oct 2011 02:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.282 X-Spam-Level: X-Spam-Status: No, score=-105.282 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6dd3HwtMq3d for ; Mon, 24 Oct 2011 02:02:57 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id D9DD021F8C13 for ; Mon, 24 Oct 2011 02:02:55 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTK00JT0BQ93U@szxga03-in.huawei.com> for clue@ietf.org; Mon, 24 Oct 2011 17:01:21 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTK000KZBQ980@szxga03-in.huawei.com> for clue@ietf.org; Mon, 24 Oct 2011 17:01:21 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-199-250.red.bezeqint.net [79.183.199.250]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LTK00AE4BPXKS@szxml11-in.huawei.com>; Mon, 24 Oct 2011 17:01:21 +0800 (CST) Date: Mon, 24 Oct 2011 10:59:01 +0200 From: Roni Even In-reply-to: To: stephane.cazeaux@orange.com, allyn@cisco.com, clue@ietf.org Message-id: <077901cc922b$32c14e00$9843ea00$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=ISO-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcxHlL8VW+C7KhbYQU2HJX/U8MKZpAFFKK/A///k6YCAAFO3gIAACg4AgAAqsQCAAFTQgP/uhI7ggCNGD4D/+k3aoIALuqeA/6gpJ1D/T+EmUP6bGiVA/TYXO6D6Wxnn4PSx557A References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com> <4E309135.7070408@alum.mit.edu> <001b01cc4cd6$77d28760$67779620$%roni@huawei.com> <4E30DFDE.3040601@alum.mit.edu> <9ECCF01B52E7AB408A7EB85352642141031F2E5E@ftrdmel0.rd.francetelecom.fr> <4E314AD3.1030406@alum.mit.edu> <4E403783.70706@alum.mit.edu> <4E454723.4080501@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A61CE060BFF@CRPMBOXPRD01.polycom.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC05D43087@xmb-sjc-221.amer.cisco.com> Subject: Re: [clue] the presentation use case X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 09:02:58 -0000 Hi Stephane, Thanks for the clarification. I will change the text to use presentation stream. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > stephane.cazeaux@orange.com > Sent: Monday, October 24, 2011 9:59 AM > To: allyn@cisco.com; clue@ietf.org > Subject: Re: [clue] the presentation use case >=20 > Hi, >=20 > Sorry for the delay in the response. >=20 > My point does not concern what kind of document can be conveyed in the > presentation stream, but the fact that the use case assumes that the > presentation stream is a _video_ presentation stream (i.e. = presentation > is coded using a video codec). The example of the excel doc aims to > highlight that video coding is not convenient to the readability of > such document. >=20 > A proposal is to use the wording "stream" or "presentation stream" > instead of "video stream", "video presentation stream" or = "presentation > video" in the section 3.4, so that the use case is more agnostic to = the > solution. >=20 > Stephane. >=20 > -----Message d'origine----- > De=A0: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > Envoy=E9=A0: lundi 10 octobre 2011 20:34 > =C0=A0: CAZEAUX Stephane RD-BIZZ-CAE; clue@ietf.org > Objet=A0: RE: [clue] the presentation use case >=20 > Hi Stephane, > Could you supply the text that you would like to have added? It would > good to be very specific, rather than general, since that what the use > cases are - the specific scenarios of interest to you. >=20 > Since xcel (over RTP) was your example, and as Mark said, it is > currently covered, I'm not sure exactly what case you have in mind = that > is either not already covered or in scope for the current charter. >=20 > Thanks, > Allyn >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > > stephane.cazeaux@orange.com > > Sent: Monday, October 10, 2011 10:30 AM > > To: clue@ietf.org > > Subject: Re: [clue] the presentation use case > > > > Hi, > > > > Thus I still think that the use case, as currently described, is too > > restrictive. One could think that only the video based presentation > is > > considered within the use cases, while we probably all agree that > CLUE > > is more generic. Could it be appropriate to indicate explicitly in > the > > use case that other solutions for document sharing could also be > > considered in the future? > > > > St=E9phane. > > > > -----Message d'origine----- > > De=A0: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la = part > de > > Duckworth, Mark > > Envoy=E9=A0: vendredi 7 octobre 2011 19:51 > > =C0=A0: clue@ietf.org > > Objet=A0: Re: [clue] the presentation use case > > > > Hi St=E9phane, > > > > The CLUE framework is intended to handle any media type that is > carried > > over RTP. The framework document should be relating to "media > > captures" and "media streams" in general, except when there is a = need > > to be more specific about video or audio or any other media type. > > There are probably some places in the document where it would be > better > > to be more general, to make sure it applies to any media type where > > appropriate. > > > > So if you want to send excel sheet data over RTP, then CLUE should = be > > able to handle it regarding associating it with audio or giving it > some > > spatial relationship to other media streams, for example. > > > > I think this is as far as CLUE should go with regard to document > > sharing. I think additional use cases about document sharing are = not > > relevant to CLUE. My thinking is based on this statement from the > CLUE > > charter: > > > > "The focus of this work is on multiple RTP audio and video streams. > > Other media types may be considered, however development of > > methodologies for them is not within the scope of this work." > > > > Regards, > > Mark Duckworth > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > > > Of stephane.cazeaux@orange.com > > > Sent: Friday, October 07, 2011 7:25 AM > > > To: clue@ietf.org > > > Subject: [clue] the presentation use case > > > > > > Hi > > > > > > I will not be able to attend physically to the interim meeting. > > > > > > However I had a comment on the presentation use case, which I = still > > > consider we need to agree on. > > > In the use case draft, the presentation use case is restricted to > the > > > video based solution. To me, it should be modified so that: > > > - It does not restrict the solution to the video > > > - It includes the need to share any kind of documents (including > > > complex documents such as excel sheets) and the ability to have > > remote > > > control > > > > > > See below the discussion. > > > > > > Regards, > > > St=E9phane. > > > > > > > > > > > > -----Message d'origine----- > > > De=A0: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Envoy=E9=A0: = vendredi > 12 > > > ao=FBt 2011 17:31 =C0=A0: CAZEAUX Stephane RD-BIZZ-CAE Cc=A0: = clue@ietf.org > > > Objet=A0: Re: [clue] Comment on the presentation use case > > > > > > On 8/12/11 4:48 AM, stephane.cazeaux@orange-ftgroup.com wrote: > > > > Hi Paul, > > > > > > > > I understand your suggestion, and I am aware that it could be a > > > solution. It certainly makes sense, but I am not sure of how it > could > > > be integrated in CLUE. To me, this is a matter of application > > > integration, at application level. > > > > > > > > My suggestion is that we should think of a solution that = provides > > > more satisfying collaboration within telepresence, with the same > > level > > > of interoperability and multistream interaction as presentation > video > > > stream provides, but with more satisfying quality (video is not > > > suitable for all kinds of shared documents) and more collaborative > > > features. > > > > I don't think that the kind of relationship that you suggest is > the > > > only solution. > > > > > > IMO the main thing is to not constrain the mechanism used for > > > collaboration/web sharing. That stuff is evolving at "web speed". > > > Anything you nail down that is constraining will be obsolete = before > > it > > > gets out. > > > > > > (I've been looking more at RTCWEB recently, and I'm wondering if > > > perhaps CLUE ought to be based on that.) > > > > > > Thanks, > > > Paul (as individual) > > > > > > > Stephane. > > > > > > > > > > > > -----Message d'origine----- > > > > De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Envoy=E9 : = lundi 8 > > > > ao=FBt 2011 21:23 =C0 : CAZEAUX Stephane RD-BIZZ-CAE Cc : > clue@ietf.org > > > > Objet : Re: [clue] Comment on the presentation use case > > > > > > > > On 8/8/11 11:56 AM, stephane.cazeaux@orange-ftgroup.com wrote: > > > >> Hi, > > > >> > > > >> To me, it should be part of the telepresence protocols at least > to > > > enable the interoperability, as the presentation based on video > > stream > > > allows it. > > > >> > > > >> The point is that video stream is not convenient for the use > cases > > > >> I > > > suggested. But it does not necessarily mean that we should bundle = a > > > full data sharing protocol with telepresence. Something simpler, > like > > > the RFB option of draft-garcia-mmusic-sdp-collaboration, could be = a > > > candidate. > > > > > > > > What I was suggesting is that maybe it would make sense to turn > > > > those relationships "inside out". > > > > > > > > For instance when I use a collaboration tool like Webex, the > > > > collaboration is set up first via the web, and defines the set = of > > > > participants. Then a voice session can be added. For pragmatic > > > reasons, > > > > the voice conferencing seems to be pretty distinct. (I'm not > > certain > > > how > > > > webex handles video. I suspect it is doing it via the web, not > the > > > > telephony conference.) > > > > > > > > Its not hard to imagine the same sort of setup, but with a > > > > multiparty telepresence session instead of the traditional voice > > > > conference. In such a case, you would probably want the > > > > collaboration tool (webex, > > > or > > > > whatever) to mediate the UI for the web collaboration, the > roster, > > > etc. > > > > It might delegate a lot of that to the telepresence > infrastructure. > > > > > > > > But that does raise some questions about how all the components > fit > > > > together. Is there a single screen for the collaboration session > in > > > > a telepresence room? What about input to that - keyboard, mouse, > > etc.? > > > Or > > > > do we assume that each person in the room has their own computer > > > > with input, display, etc. and maybe a way to slave the web > > > > collaboration session to one or more of the big displays in the > > room? > > > > > > > > What probably *can't* be done right now is nail down a = particular > > > > web collaboration service (e.g. Webex) or protocol. That does > > > > complicate slaving the collaboration session to a screen, unless > > its > > > > done by > > > having > > > > someone connect a video connection to their own computer. > > > > > > > > Thanks, > > > > Paul > > > > > > > >> Stephane. > > > >> > > > >> > > > >> -----Message d'origine----- > > > >> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la > > > >> part > > > de Paul Kyzivat > > > >> Envoy=E9 : jeudi 28 juillet 2011 13:41 =C0 : CHATRAS Bruno = RD-CORE- > ISS > > > >> Cc : clue@ietf.org Objet : Re: [clue] Comment on the > presentation > > > >> use case > > > >> > > > >> On 7/28/11 2:37 AM, bruno.chatras@orange-ftgroup.com wrote: > > > >>> I think we should take a look to > > > >>> http://tools.ietf.org/html/draft-garcia-mmusic-sdp- > collaboration- > > 0 > > > >>> 0 > > > >> > > > >> Maybe. But that is almost orthogonal to what I was suggesting. > > > >> > > > >> THanks, > > > >> Paul > > > >> (as individual) > > > >> > > > >>> Bruno > > > >>> > > > >>>> -----Message d'origine----- > > > >>>> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De > la > > > part de > > > >>>> Paul Kyzivat > > > >>>> Envoy=E9 : jeudi 28 juillet 2011 06:05 =C0 : Roni Even Cc : > > > >>>> clue@ietf.org Objet : Re: [clue] Comment on the presentation > use > > > >>>> case > > > >>>> > > > >>>> On 7/27/11 11:28 PM, Roni Even wrote: > > > >>>>> Hi, > > > >>>>> HTTP is not defining a common data sharing protocol. WebEx > may > > > >>>>> be > > > >>>> carried > > > >>>>> over HTTP but the data sharing application is not standard. > > What > > > I > > > >>>> meant is > > > >>>>> that it can either be something that is a common data = sharing > > > >>>> protocol or > > > >>>>> something that is carried as an RTP payload which require > some > > > common > > > >>>>> defined protocol on top. > > > >>>> > > > >>>> I was being a bit tongue in cheek, though not entirely. > > > >>>> Of course you are right - that if you want to push data to > > > everybody > > > >>>> you > > > >>>> need more. > > > >>>> > > > >>>> But data sharing by pointing a video camera at a piece of > paper > > > >>>> is > > > a > > > >>>> tad > > > >>>> out of date. Connecting the video port on a user's computer = as > a > > > video > > > >>>> source and distributing it with the other video is better = than > > > that. > > > >>>> But > > > >>>> its not nearly as convenient as webex or any of its > competitors. > > > >>>> > > > >>>> It isn't entirely clear that its *necessary* to bundle the > data > > > sharing > > > >>>> application with the telepresence protocols. Its kind of > > limiting > > > since > > > >>>> the web apps evolve very rapidly. Perhaps we should be doing > the > > > >>>> opposite of that: providing a way to embed the control of the > > > >>>> telepresence system into a web app. > > > >>>> > > > >>>> Thanks, > > > >>>> Paul > > > >>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > On > > > Behalf > > > >>>> Of > > > >>>>>> Paul Kyzivat > > > >>>>>> Sent: Thursday, July 28, 2011 1:29 AM > > > >>>>>> To: clue@ietf.org > > > >>>>>> Subject: Re: [clue] Comment on the presentation use case > > > >>>>>> > > > >>>>>> On 7/27/11 6:07 PM, Roni Even wrote: > > > >>>>>>> Hi Stephane, > > > >>>>>>> > > > >>>>>>> Is there a standard protocol that is used for conveying > this > > > >>>>>>> information, is it RTP based. > > > >>>>>> > > > >>>>>> AFAIK this is often http. (E.g. webex) > > > >>>>>> > > > >>>>>>> To me this is a separate application that can be = integrated > > in > > > the > > > >>>>>>> application level and not as part of the multistream. > > > >>>>>> > > > >>>>>> I guess this depends on whether the support for it is > > > >>>>>> integrated > > > >>>> into > > > >>>>>> the "room", or is just incidental equipment brought by the > > > users, > > > >>>> not > > > >>>>>> formally related to the telepresence session. > > > >>>>>> > > > >>>>>> Thanks, > > > >>>>>> Paul > > > >>>>>> (speaking as an individual) > > > >>>>>> > > > >>>>>>> Roni > > > >>>>>>> > > > >>>>>>> *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > > > Behalf Of > > > >>>>>>> *stephane.cazeaux@orange-ftgroup.com > > > >>>>>>> *Sent:* Thursday, July 21, 2011 2:33 PM > > > >>>>>>> *To:* clue@ietf.org > > > >>>>>>> *Subject:* [clue] Comment on the presentation use case* > > > >>>>>>> > > > >>>>>>> ** > > > >>>>>>> > > > >>>>>>> *Hi,* > > > >>>>>>> > > > >>>>>>> ** > > > >>>>>>> > > > >>>>>>> *The presentation use case as described in the use-cases > > > document > > > >>>> is > > > >>>>>>> based on the assumption that the presentation stream = relies > > on > > > a > > > >>>>>> video > > > >>>>>>> stream, and is limited to usage of presentation video > > streams. > > > But > > > >>>> we > > > >>>>>>> could also consider collaborative use cases, meaningful = for > > > >>>>>>> telepresence, which are not covered by the existing text.* > > > >>>>>>> > > > >>>>>>> *I propose to complete the existing text as follows:* > > > >>>>>>> > > > >>>>>>> ** > > > >>>>>>> > > > >>>>>>> *Furthermore, although most today's systems use video > streams > > > for > > > >>>>>>> presentations, there are use cases where this is not > > suitable. > > > For > > > >>>>>> example:* > > > >>>>>>> > > > >>>>>>> *- The professor which shares an electronic whiteboard > (could > > > be a > > > >>>>>>> whiteboard application on a PC, with screen capture of the > > PC) > > > >>>> where > > > >>>>>> all > > > >>>>>>> students can participate. Students will take control of = the > > > shared > > > >>>>>>> whiteboard in turns.* > > > >>>>>>> > > > >>>>>>> *- In a multipoint meeting, a shared document can be kept > > > always > > > >>>>>> visible > > > >>>>>>> in a screen, while other documents are presented on other > > > screens > > > >>>>>> (with > > > >>>>>>> possible in turns presentation). For instance, for the > > purpose > > > of > > > >>>>>> shared > > > >>>>>>> design document, notes taking, polls, etc. A shared > document > > > >>>> implies > > > >>>>>>> that all participants can modify it in turns.* > > > >>>>>>> > > > >>>>>>> *"* > > > >>>>>>> > > > >>>>>>> ** > > > >>>>>>> > > > >>>>>>> ** > > > >>>>>>> > > > >>>>>>> *St ephane. v> > > > >>>>>>> * > > > >>>>>>> > > > >>>>>>> * > > > >>>>>>> * > > > >>>>>>> > > > >>>>>>> *_______________________________________________ > > > >>>>>>> clue mailing list > > > >>>>>>> clue@ietf.org > > > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > > > >>>>>>> * > > > >>>>>> > > > >>>>>> _______________________________________________ > > > >>>>>> clue mailing list > > > >>>>>> clue@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/clue > > > >>>>> > > > >>>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> clue mailing list > > > >>>> clue@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/clue > > > >>> > > > >> > > > >> _______________________________________________ > > > >> clue mailing list > > > >> clue@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/clue > > > >> > > > > > > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From jonathan@vidyo.com Mon Oct 24 18:08:31 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CD411E80CF for ; Mon, 24 Oct 2011 18:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMiQMNtUIlHC for ; Mon, 24 Oct 2011 18:08:30 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id BCE3711E8090 for ; Mon, 24 Oct 2011 18:08:30 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 761E2554CC0 for ; Mon, 24 Oct 2011 21:08:30 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 06DE6554C70 for ; Mon, 24 Oct 2011 21:08:30 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Mon, 24 Oct 2011 21:08:22 -0400 From: Jonathan Lennox To: "clue@ietf.org" Date: Mon, 24 Oct 2011 21:08:28 -0400 Thread-Topic: I-D Action: draft-lennox-clue-rtp-usage-00.txt Thread-Index: AcySspJywofWIStDQl6O2J0qKZ+p6A== Message-ID: <28519E53-D8D4-42B0-8360-73118BDFEF8B@vidyo.com> References: <20111024235904.22306.9198.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [clue] Fwd: I-D Action: draft-lennox-clue-rtp-usage-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 01:08:31 -0000 Hello all -- Allyn Romanow and I have written a draft discussing RTP usage for CLUE Tele= presence sessions. The contents are fairly similar to the presentation I d= id on this subject at the interim in Andover. The draft is still fairly sketchy; we may publish an updated version before= the -01 deadline next Monday. Comments are welcome. Begin forwarded message: > From: "internet-drafts@ietf.org" > Date: October 24, 2011 7:59:04 PM EDT > To: "i-d-announce@ietf.org" > Subject: I-D Action: draft-lennox-clue-rtp-usage-00.txt > Reply-To: "internet-drafts@ietf.org" >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 > Title : Real-Time Transport Protocol (RTP) Usage for Teleprese= nce Sessions > Author(s) : Jonathan Lennox > Allyn Romanow > Filename : draft-lennox-clue-rtp-usage-00.txt > Pages : 7 > Date : 2011-10-24 >=20 > This document describes mechanisms and recommended practice for > transmitting the media streams of telepresence sessions using the > Real-Time Transport Protocol (RTP). >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lennox-clue-rtp-usage-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-lennox-clue-rtp-usage-00.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 -- Jonathan Lennox jonathan@vidyo.com From jonathan@vidyo.com Mon Oct 24 18:12:30 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17ABA21F8D37 for ; Mon, 24 Oct 2011 18:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvI6qwRMvFZH for ; Mon, 24 Oct 2011 18:12:29 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE9C21F8A71 for ; Mon, 24 Oct 2011 18:12:29 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id CB7E779FCD5 for ; Mon, 24 Oct 2011 21:12:28 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 55ACA79F948 for ; Mon, 24 Oct 2011 21:12:28 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Mon, 24 Oct 2011 21:12:25 -0400 From: Jonathan Lennox To: Stephan Wenger , "clue@ietf.org" Date: Mon, 24 Oct 2011 21:12:26 -0400 Thread-Topic: Two drafts I just published Thread-Index: AcySsyCBeQ9BDXXZT5OE0+mocultGQ== Message-ID: <185480CF-FE45-4748-9EC9-6F6A20E7C071@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_005_185480CFFE4547489EC96F6A20E7C071vidyocom_" MIME-Version: 1.0 Subject: [clue] Two drafts I just published X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 01:12:30 -0000 --_005_185480CFFE4547489EC96F6A20E7C071vidyocom_ Content-Type: multipart/alternative; boundary="_000_185480CFFE4547489EC96F6A20E7C071vidyocom_" --_000_185480CFFE4547489EC96F6A20E7C071vidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I just published drafts for the RTCWeb and the CLUE working groups, on the = usage of RTP in both cases. Their primary purpose from our point of view i= s to socialize the idea of source multiplexing; other than that they're pri= marily IETF good-citizen work, plus stopping things from going in direction= s too inimical to our architecture. -- Jonathan Lennox jonathan@vidyo.com --_000_185480CFFE4547489EC96F6A20E7C071vidyocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I just published drafts for the R= TCWeb and the CLUE working groups, on the usage of RTP in both cases. = Their primary purpose from our point of view is to socialize the idea of s= ource multiplexing; other than that they're primarily IETF good-citizen wor= k, plus stopping things from going in directions too inimical to our archit= ecture.


--
Jonathan Lennox
jonathan@vidyo.com
= --_000_185480CFFE4547489EC96F6A20E7C071vidyocom_-- --_005_185480CFFE4547489EC96F6A20E7C071vidyocom_ Content-Type: message/rfc822 Received: from BH019.mail.lan (10.110.21.119) by HUB023.mail.lan (10.110.17.23) with Microsoft SMTP Server id 8.3.192.1; Mon, 24 Oct 2011 20:53:43 -0400 Received: from mx1.myoutlookonline.com ([10.110.13.25]) by BH019.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Oct 2011 20:53:43 -0400 Received: from p01c12m026.mxlogic.net ([208.65.145.247]) by mx1.myoutlookonline.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Oct 2011 20:53:43 -0400 Received: from unknown [166.84.1.89] (EHLO mailbackend.panix.com) by p01c12m026.mxlogic.net(mxl_mta-6.11.0-7) with ESMTP id 69806ae4.0.2342392.00-2234.3139242.p01c12m026.mxlogic.net (envelope-from ); Mon, 24 Oct 2011 18:53:42 -0600 (MDT) Received: from compute01.cs.columbia.edu (compute01.cs.columbia.edu [128.59.11.31]) by mailbackend.panix.com (Postfix) with ESMTP id F11DC2817A for ; Mon, 24 Oct 2011 20:53:41 -0400 (EDT) From: "internet-drafts@ietf.org" To: "i-d-announce@ietf.org" Content-Class: urn:content-classes:message Date: Mon, 24 Oct 2011 19:27:40 -0400 Subject: I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt Thread-Topic: I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt Thread-Index: AcySsIMiB70XAZTbTn+W55afm8XKtA== Message-ID: <20111024232740.11885.97235.idtracker@ietfa.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , Reply-To: "internet-drafts@ietf.org" Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: HUB023.mail.lan X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: 1 X-MS-TNEF-Correlator: acceptlanguage: en-US x-originalarrivaltime: 25 Oct 2011 00:53:43.0918 (UTC) FILETIME=[8B7F58E0:01CC92B0] dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1319498861; bh=InTPuz/vtHI45ja6AINxq+FEhCmE415SIqzYD/VkbBI=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=blbwsuYaMtej+dneTcrOX2rpyG1f+gkc7Il/kf/8Pku5X4SfV1RYzKWJhRjtmr8uM Ai5gQGnKJ0Xz1NHlwwSSfAbAe2r0qR48pOk8t7GlxxilFON6EAZDL4JcRcgRDn1kzT 5l6zYNswGQxjaxYnAYqTKtaDt5uJEJF/TtQv1Ae4= errors-to: i-d-announce-bounces@ietf.org x-virus-scanned: amavisd-new at amsl.com x-spam-status: No, score=-2.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,RCVD_IN_DNSWL_MED autolearn=disabled version=3.3.1 x-spam-level: x-virus-status: No x-spam-checker-version: SpamAssassin 3.3.1 (2010-03-16) on mailcrunch1.panix.com delivered-to: i-d-announce@ietfa.amsl.com list-id: Internet Draft Announcements only list-archive: x-scanned-by: MIMEDefang 2.68 on 128.59.28.165 x-mail-from: list-post: x-source-ip: [166.84.1.89] x-spam: [F=0.2000000000; B=0.500(0); spf=0.500; STSI=0.500(8); STSM=0.500(8); CM=0.500; MH=0.500(2011102426); S=0.200(2010122901); SC=none] x-analysisout: [CjuIK1q_8ugA:10 a=jM_x9b4JT8QA:10 a=lZB815dzVvQA:10] x-mailman-version: 2.1.12 x-beenthere: i-d-announce@ietf.org x-original-to: i-d-announce@ietfa.amsl.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Multiplexing Multiple Media Types In a Single Real-Time = Transport Protocol (RTP) Session Author(s) : Jonathan Lennox Jonathan Rosenberg Filename : draft-lennox-rtcweb-rtp-media-type-mux-00.txt Pages : 11 Date : 2011-10-24 This document describes mechanisms and recommended practice for transmitting media streams of multiple media types (e.g., audio and video) over a single Real-Time Transport Protocol (RTP) session, primarily for the use of Real-Time Communication for the Web (rtcweb). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lennox-rtcweb-rtp-media-type-mux-= 00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-lennox-rtcweb-rtp-media-type-mux-0= 0.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_005_185480CFFE4547489EC96F6A20E7C071vidyocom_ Content-Type: message/rfc822 Received: from BH013.mail.lan (10.110.21.113) by HUB013.mail.lan (10.110.17.13) with Microsoft SMTP Server id 8.3.192.1; Mon, 24 Oct 2011 20:58:44 -0400 Received: from mx1.myoutlookonline.com ([10.110.13.21]) by BH013.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Oct 2011 20:58:57 -0400 Received: from p01c11m016.mxlogic.net ([208.65.144.247]) by mx1.myoutlookonline.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Oct 2011 20:58:45 -0400 Received: from unknown [166.84.1.89] (EHLO mailbackend.panix.com) by p01c11m016.mxlogic.net(mxl_mta-6.11.0-7) with ESMTP id 1d906ae4.0.730050.00-2215.1079903.p01c11m016.mxlogic.net (envelope-from ); Mon, 24 Oct 2011 18:58:58 -0600 (MDT) Received: from compute01.cs.columbia.edu (compute01.cs.columbia.edu [128.59.11.31]) by mailbackend.panix.com (Postfix) with ESMTP id 91FB32846F for ; Mon, 24 Oct 2011 20:58:57 -0400 (EDT) From: "internet-drafts@ietf.org" To: "i-d-announce@ietf.org" Content-Class: urn:content-classes:message Date: Mon, 24 Oct 2011 19:59:04 -0400 Subject: I-D Action: draft-lennox-clue-rtp-usage-00.txt Thread-Topic: I-D Action: draft-lennox-clue-rtp-usage-00.txt Thread-Index: AcySsT+cAL309z/8Qcul9fQWBC2dug== Message-ID: <20111024235904.22306.9198.idtracker@ietfa.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , Reply-To: "internet-drafts@ietf.org" Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: HUB013.mail.lan X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: 0 X-MS-TNEF-Correlator: acceptlanguage: en-US x-originalarrivaltime: 25 Oct 2011 00:58:45.0187 (UTC) FILETIME=[3F115930:01CC92B1] dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1319500746; bh=2v8735bdhj8GNkVqQKIFmglwBL3AE5UCBIoMkUrhwZE=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=eMo4tVqu1CEMiWmjev3Hz5r7fv1H5Xx7SdZ5HJCsxUB4vgP11QsSl1OsdehJHyuda kSEFj7e3c8U0yZC4nrWAF4A5c4wNY4x3rnwGzyhM8b5Vrmq5xXvegNENsLv6Rn55EN H800OvqlbOvU7iza/Tc7EGrqMjLT+5t7B44DsH/4= errors-to: i-d-announce-bounces@ietf.org x-virus-scanned: amavisd-new at amsl.com x-spam-status: No, score=-2.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,RCVD_IN_DNSWL_MED autolearn=disabled version=3.3.1 x-spam-level: x-virus-status: No x-spam-checker-version: SpamAssassin 3.3.1 (2010-03-16) on mailcrunch2.panix.com delivered-to: i-d-announce@ietfa.amsl.com list-id: Internet Draft Announcements only list-archive: x-scanned-by: MIMEDefang 2.68 on 128.59.28.170 x-mail-from: list-post: x-source-ip: [166.84.1.89] x-spam: [F=0.2000000000; B=0.500(0); spf=0.500; STSI=0.500(8); STSM=0.500(8); CM=0.500; MH=0.500(2011102426); S=0.200(2010122901); SC=none] x-analysisout: [CjuIK1q_8ugA:10 a=jM_x9b4JT8QA:10 a=lZB815dzVvQA:10] x-mailman-version: 2.1.12 x-beenthere: i-d-announce@ietf.org x-original-to: i-d-announce@ietfa.amsl.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Real-Time Transport Protocol (RTP) Usage for Telepresenc= e Sessions Author(s) : Jonathan Lennox Allyn Romanow Filename : draft-lennox-clue-rtp-usage-00.txt Pages : 7 Date : 2011-10-24 This document describes mechanisms and recommended practice for transmitting the media streams of telepresence sessions using the Real-Time Transport Protocol (RTP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lennox-clue-rtp-usage-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-lennox-clue-rtp-usage-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_005_185480CFFE4547489EC96F6A20E7C071vidyocom_-- From jonathan@vidyo.com Mon Oct 24 18:14:30 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DF51F0C3B for ; Mon, 24 Oct 2011 18:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMzCR6Lc4y5L for ; Mon, 24 Oct 2011 18:14:29 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 975541F0C38 for ; Mon, 24 Oct 2011 18:14:27 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 50910553D23 for ; Mon, 24 Oct 2011 21:14:27 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB027.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 89023553C7A for ; Mon, 24 Oct 2011 21:14:26 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Mon, 24 Oct 2011 21:14:11 -0400 From: Jonathan Lennox To: "clue@ietf.org" Date: Mon, 24 Oct 2011 21:14:22 -0400 Thread-Topic: [clue] Two drafts I just published Thread-Index: AcySs2cQmSkf6Z9vQhGedW36iBM1OA== Message-ID: References: <185480CF-FE45-4748-9EC9-6F6A20E7C071@vidyo.com> In-Reply-To: <185480CF-FE45-4748-9EC9-6F6A20E7C071@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E94BB76856634C249D3CEFA9C53C7F45vidyocom_" MIME-Version: 1.0 Subject: Re: [clue] Two drafts I just published X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 01:14:30 -0000 --_000_E94BB76856634C249D3CEFA9C53C7F45vidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, that was (obviously) not meant for the public mailing list. :-) On Oct 24, 2011, at 9:12 PM, Jonathan Lennox wrote: I just published drafts for the RTCWeb and the CLUE working groups, on the = usage of RTP in both cases. Their primary purpose from our point of view i= s to socialize the idea of source multiplexing; other than that they're pri= marily IETF good-citizen work, plus stopping things from going in direction= s too inimical to our architecture. -- Jonathan Lennox jonathan@vidyo.com From: "internet-drafts@ietf.org" > Date: October 24, 2011 7:27:40 PM EDT To: "i-d-announce@ietf.org" > Subject: I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt Reply-To: "internet-drafts@ietf.org" > A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Multiplexing Multiple Media Types In a Single Real-Time T= ransport Protocol (RTP) Session Author(s) : Jonathan Lennox Jonathan Rosenberg Filename : draft-lennox-rtcweb-rtp-media-type-mux-00.txt Pages : 11 Date : 2011-10-24 This document describes mechanisms and recommended practice for transmitting media streams of multiple media types (e.g., audio and video) over a single Real-Time Transport Protocol (RTP) session, primarily for the use of Real-Time Communication for the Web (rtcweb). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lennox-rtcweb-rtp-media-type-mux-= 00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-lennox-rtcweb-rtp-media-type-mux-0= 0.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From: "internet-drafts@ietf.org" Date: October 24, 2011 7:59:04 PM EDT To: "i-d-announce@ietf.org" Subject: I-D Action: draft-lennox-clue-rtp-usage-00.txt Reply-To: "internet-drafts@ietf.org" A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Real-Time Transport Protocol (RTP) Usage for Telepresence= Sessions Author(s) : Jonathan Lennox Allyn Romanow Filename : draft-lennox-clue-rtp-usage-00.txt Pages : 7 Date : 2011-10-24 This document describes mechanisms and recommended practice for transmitting the media streams of telepresence sessions using the Real-Time Transport Protocol (RTP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lennox-clue-rtp-usage-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-lennox-clue-rtp-usage-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue -- Jonathan Lennox jonathan@vidyo.com --_000_E94BB76856634C249D3CEFA9C53C7F45vidyocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, that was (obviously= ) not meant for the public mailing list. :-)

O= n Oct 24, 2011, at 9:12 PM, Jonathan Lennox wrote:

I just published drafts for the R= TCWeb and the CLUE working groups, on the usage of RTP in both cases. = Their primary purpose from our point of view is to socialize the idea of s= ource multiplexing; other than that they're primarily IETF good-citizen wor= k, plus stopping things from going in directions too inimical to our archit= ecture.


--
Jonathan Lennox
jonathan@vidyo.com

Date: October 24, 2011 7:27:40 PM EDT
To: "i-d= -announce@ietf.org" <i-d-an= nounce@ietf.org>

<= br>A New Internet-Draft is available from the on-line Internet-Drafts direc= tories.

Title           : Mu= ltiplexing Multiple Media Types In a Single Real-Time Transport Protocol (R= TP) Session
Author(s)       : Jonathan Lennox
&n= bsp;            = ;            Jo= nathan Rosenberg
Filename        : draft-lennox= -rtcweb-rtp-media-type-mux-00.txt
Pages       &nbs= p;   : 11
Date         &nbs= p;  : 2011-10-24

  This document describes mech= anisms and recommended practice for
  transmitting media stre= ams of multiple media types (e.g., audio and
  video) over a = single Real-Time Transport Protocol (RTP) session,
  primaril= y for the use of Real-Time Communication for the Web
  (rtcwe= b).


A URL for this Internet-Draft is:
http= ://www.ietf.org/internet-drafts/draft-lennox-rtcweb-rtp-media-type-mux-00.t= xt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/

This Internet-Draft can be retrieved at:
ftp://ftp.iet= f.org/internet-drafts/draft-lennox-rtcweb-rtp-media-type-mux-00.txt
____= ___________________________________________
I-D-Announce mailing listI-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announc= e
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp:= //ftp.ietf.org/ietf/1shadow-sites.txt




From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>=
Date: October 24, 2011 7:59:04= PM EDT
To: "i-d-announce@ietf.= org" <i-d-announce@ietf.org>
Subject: I-D Action: draft-lennox-clue-rtp-usage-00.txt
Reply-To: "internet-drafts@ietf.org" = <internet-drafts@ietf.org>


A New Internet-Dra= ft is available from the on-line Internet-Drafts directories.

Title  &nbs= p;        : Real-Time Transport Pro= tocol (RTP) Usage for Telepresence Sessions
Author(s)     &nbs= p; : Jonathan Lennox
       &nb= sp;            =      Allyn Romanow
Filename      = ;  : draft-lennox-clue-rtp-usage-00.txt
Pages     &n= bsp;     : 7
Date       &nb= sp;    : 2011-10-24

  This document d= escribes mechanisms and recommended practice for
  transmitti= ng the media streams of telepresence sessions using the
  Rea= l-Time Transport Protocol (RTP).


A URL for this Internet-Draft i= s:
http://www.ietf.org/internet-drafts/draft-lennox-clue-rtp-usage-00.tx= t

Internet-Drafts are also available by anonymous FTP at:
ftp://f= tp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at= :
ftp://ftp.ietf.org/internet-drafts/draft-lennox-clue-rtp-usage-00.txt<= br>_______________________________________________
I-D-Announce mailing = list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-= announce
Internet-Draft directories: http://www.ietf.org/shadow.html
= or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



_______________= ________________________________
clue mailing list
clue@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/clue

--
Jonathan Lennox
jonathan@vidyo.com

= --_000_E94BB76856634C249D3CEFA9C53C7F45vidyocom_-- From marshall.eubanks@gmail.com Mon Oct 24 20:44:54 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E693011E80D5 for ; Mon, 24 Oct 2011 20:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.404 X-Spam-Level: X-Spam-Status: No, score=-103.404 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oz6bmdJIWcoj for ; Mon, 24 Oct 2011 20:44:54 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id F413811E80CC for ; Mon, 24 Oct 2011 20:44:53 -0700 (PDT) Received: by ywt2 with SMTP id 2so90019ywt.31 for ; Mon, 24 Oct 2011 20:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=xlcGq+IeK4EfSOV2eesSR8AV3l9bUFC3XNs6Ltv8yxc=; b=vXwuo3N0+9pyrigwBV12dAqUJno+tPSrEABB7ULNkYumSzKBLZyl5oPIkF/sOj9+3r 7Ir2W8PTPm0A2JsU4b7qAZldR130R6IAwzAkOW76JYeyj99eWQDFL/0Sx7dBlrGnJ+EO W/R6QcVsOPLHLdK47HEF9i0PB15boFYwMvYLU= MIME-Version: 1.0 Received: by 10.182.164.74 with SMTP id yo10mr3911927obb.69.1319514293577; Mon, 24 Oct 2011 20:44:53 -0700 (PDT) Received: by 10.182.14.65 with HTTP; Mon, 24 Oct 2011 20:44:53 -0700 (PDT) Date: Mon, 24 Oct 2011 23:44:53 -0400 Message-ID: From: Marshall Eubanks To: clue Content-Type: multipart/alternative; boundary=e89a8f646acfbea77404b0175c09 Subject: [clue] New draft on Transport Options for Clue X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 03:44:55 -0000 --e89a8f646acfbea77404b0175c09 Content-Type: text/plain; charset=ISO-8859-1 We just published a draft on Transport Options for Clue, draft-wenger-clue-transport-01 (it's -01 as I fixed some issues with the author list in -00). http://tools.ietf.org/html/draft-wenger-clue-transport-01 : A new version of I-D, draft-wenger-clue-transport-01.txt has been successfully submitted by Marshall Eubanks and posted to the IETF repository. Filename: draft-wenger-clue-transport Revision: 01 Title: Transport Options for Clue Creation date: 2011-10-24 WG ID: Individual Submission Number of pages: 9 It clearly needs some work... Regards Marshall --e89a8f646acfbea77404b0175c09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We just published a draft= on=A0Transport Options for Clue,=A0draft-wenger-clue-transport-01
(it's -01 as I fixed some issues with the author list in -00).=A0


It clearly n= eeds some work...

Regards
Marshall

--e89a8f646acfbea77404b0175c09-- From pkyzivat@alum.mit.edu Thu Oct 27 07:22:57 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355D921F8B26 for ; Thu, 27 Oct 2011 07:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRu5QMghL68p for ; Thu, 27 Oct 2011 07:22:56 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id AF62D21F861E for ; Thu, 27 Oct 2011 07:22:53 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta07.westchester.pa.mail.comcast.net with comcast id ppoi1h0091uE5Es57qNute; Thu, 27 Oct 2011 14:22:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta16.westchester.pa.mail.comcast.net with comcast id pqNt1h00d0tdiYw3cqNtGh; Thu, 27 Oct 2011 14:22:53 +0000 Message-ID: <4EA9693A.5000006@alum.mit.edu> Date: Thu, 27 Oct 2011 10:22:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Minutes of interim meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 14:22:57 -0000 I've posted the minutes of the interim meeting. Go to http://www.ietf.org/proceedings/interim/2011/10/11/clue/proceedings.html and click "Minutes". Thanks to Allyn, Roni, and Spencer for the raw notes. Thanks, Paul From Mark.Duckworth@polycom.com Thu Oct 27 08:30:25 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521DA21F8880 for ; Thu, 27 Oct 2011 08:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5FplVawhH5J for ; Thu, 27 Oct 2011 08:30:24 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 2190A21F847D for ; Thu, 27 Oct 2011 08:30:21 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Thu, 27 Oct 2011 08:30:21 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 27 Oct 2011 08:30:28 -0700 Thread-Topic: Kick-off Item 2: Layout, composition, switching discussion Thread-Index: AcyUvVrMDMQ5UufGQp+yMcU2E0ehsQ== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61CE42473E@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A61CE42473ECRPMBOXPRD01pol_" MIME-Version: 1.0 Subject: [clue] Kick-off Item 2: Layout, composition, switching discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 15:30:25 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A61CE42473ECRPMBOXPRD01pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is following up on the major issues list from the interim meeting in A= ndover. Issues for discussion: 1. Item 5 video composition (discussion kicked off by Stephan) is a p= art of this. But more generally, the same sort of issue applies to other m= edia types, not just video. a. For example, should a provider that mixes audio be able to indicat= e to the consumer which audio sources are in the mix? b. Proposal - the more general case should be consistent with the outc= ome of the Item 5 discussion. 2. Should a provider that mixes or composes other media captures/stre= ams into a new stream be able to indicate some information about the algori= thm it uses to choose which other captures/streams to mix? a. Proposal - no, CLUE does not need this. 3. Should a provider that mixes or composes media be able to allow th= e consumer to make a choice about which other captures/streams are included= in the mix? a. This should be covered by Major Issue Item 3 source selection - (d= iscussion to be kicked off by Jonathan) 4. Do we need support in CLUE for allowing a media consumer to reques= t the provider to compose or mix particular media sources into a new media = stream, using a particular algorithm? a. Proposal - no, CLUE does not need this. b. But if something like item 5 idea is accepted, then maybe a provide= r can offer a few alternatives and a consumer can choose among them Mark Duckworth --_000_44C6B6B2D0CF424AA90B6055548D7A61CE42473ECRPMBOXPRD01pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is followin= g up on the major issues list from the interim meeting in Andover.

Issues for discussion:

1.       Item 5 video composition (discussion kicked off by Stephan) is a part= of this.  But more generally, the same sort of issue applies to other= media types, not just video.

a.       For example, should a provider that mixes audio be able to indicate to = the consumer which audio sources are in the mix?

b.      = Proposal – the more general case should be consisten= t with the outcome of the Item 5 discussion.

2.       Should a provider that mixes or composes other media captures/streams into= a new stream be able to indicate some information about the algorithm it u= ses to choose which other captures/streams to mix?

a.     &nbs= p; Proposal – no, CLUE does not need this.

3.     &n= bsp; Should a provider that mixes or composes media= be able to allow the consumer to make a choice about which other captures/= streams are included in the mix?

a.       This should be covered by Major Issue Item 3 source selection –= ; (discussion to be kicked off by Jonathan)

4.       = Do we need support in CLUE for allowing a media consumer to request the pro= vider to compose or mix particular media sources into a new media stream, u= sing a particular algorithm?

a.       Proposal – no, CLUE does not need this.

b.      = But if something like item 5 idea is accepted, then maybe = a provider can offer a few alternatives and a consumer can choose among the= m

 

Mark Duckworth

 

=
= --_000_44C6B6B2D0CF424AA90B6055548D7A61CE42473ECRPMBOXPRD01pol_-- From Even.roni@huawei.com Thu Oct 27 14:57:48 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073FC1F0C49 for ; Thu, 27 Oct 2011 14:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.334 X-Spam-Level: X-Spam-Status: No, score=-106.334 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkFZBmyVfzBp for ; Thu, 27 Oct 2011 14:57:46 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id E2C261F0C48 for ; Thu, 27 Oct 2011 14:57:45 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTQ00FOZVO8R2@szxga04-in.huawei.com> for clue@ietf.org; Fri, 28 Oct 2011 05:57:45 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTQ00AHJVO8MI@szxga04-in.huawei.com> for clue@ietf.org; Fri, 28 Oct 2011 05:57:44 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-199-250.red.bezeqint.net [79.183.199.250]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LTQ00MK1VO2IS@szxml11-in.huawei.com>; Fri, 28 Oct 2011 05:57:44 +0800 (CST) Date: Thu, 27 Oct 2011 23:55:04 +0200 From: Roni Even In-reply-to: <44C6B6B2D0CF424AA90B6055548D7A61CE42473E@CRPMBOXPRD01.polycom.com> To: "'Duckworth, Mark'" , clue@ietf.org Message-id: <0a0301cc94f3$19359ed0$4ba0dc70$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_bnBe0bvz00jWYRWB4OHr9A)" Content-language: en-us Thread-index: AcyUvVrMDMQ5UufGQp+yMcU2E0ehsQANDRgg References: <44C6B6B2D0CF424AA90B6055548D7A61CE42473E@CRPMBOXPRD01.polycom.com> Subject: Re: [clue] Kick-off Item 2: Layout, composition, switching discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 21:57:48 -0000 This is a multi-part message in MIME format. --Boundary_(ID_bnBe0bvz00jWYRWB4OHr9A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Mark, I understand that you have two topics 1. Allowing the consumer to select specific media streams for a mix (for example, left camera from room 1, middle camera from room 2 and left camera from room 3) which I think should be possible. This will require information and protocol that will allow this functionality. 2. Allowing the provider to specify the mixture algorithm and for the consumer to ask for a specific one. I think that we need at least to enable the provider and consumer to specify or request site switch or segment switch mode. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Thursday, October 27, 2011 5:30 PM To: clue@ietf.org Subject: [clue] Kick-off Item 2: Layout, composition, switching discussion This is following up on the major issues list from the interim meeting in Andover. Issues for discussion: 1. Item 5 video composition (discussion kicked off by Stephan) is a part of this. But more generally, the same sort of issue applies to other media types, not just video. a. For example, should a provider that mixes audio be able to indicate to the consumer which audio sources are in the mix? b. Proposal - the more general case should be consistent with the outcome of the Item 5 discussio 2. Should a provider that mixes or composes other media captures/streams into a new stream be able to indicate some information about the algorithm it uses to choose which other captures/streams to mix? a. Proposal - no, CLUE does not need this. 3. Should a provider that mixes or composes media be able to allow the consumer to make a choice about which other captures/streams are included in the mix? a. This should be covered by Major Issue Item 3 source selection - (discussion to be kicked off by Jonathan) 4. Do we need support in CLUE for allowing a media consumer to request the provider to compose or mix particular media sources into a new media stream, using a particular algorithm? a. Proposal - no, CLUE does not need this. b. But if something like item 5 idea is accepted, then maybe a provider can offer a few alternatives and a consumer can choose among them Mark Duckworth --Boundary_(ID_bnBe0bvz00jWYRWB4OHr9A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Mark,

I understand that you = have two topics

 

1.       = Allowing the consumer to select specific media = streams for a mix (for example, left camera from room 1, middle camera = from room 2 and left camera from room 3) which I think should be = possible. This will require information and protocol that will allow = this functionality.

2.       = Allowing the provider  to specify the = mixture algorithm and for the consumer to ask for a specific one. I = think that we need at least to enable the provider and consumer to = specify or request site switch or segment switch = mode.

=

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Thursday, October 27, 2011 5:30 = PM
To: clue@ietf.org
Subject: [clue] Kick-off Item = 2: Layout, composition, switching = discussion

 

This is = following up on the major issues list from the interim meeting in = Andover.

Issues for = discussion:

1.       = Item 5 video composition = (discussion kicked off by Stephan) is a part of this.  But more = generally, the same sort of issue applies to other media types, not just = video.

a.       = For example, should a = provider that mixes audio be able to indicate to the consumer which = audio sources are in the mix?

b.      = Proposal – = the more general case should be consistent with the outcome of the Item = 5 discussio

 

2.       = Should a provider that = mixes or composes other media captures/streams into a new stream be able = to indicate some information about the algorithm it uses to choose which = other captures/streams to mix?

a.       = Proposal – no, CLUE = does not need this.

3.       = Should a provider that = mixes or composes media be able to allow the consumer to make a choice = about which other captures/streams are included in the = mix?

a.       = This should be covered by = Major Issue Item 3 source selection – (discussion to be kicked off = by Jonathan)

4.       = Do we need support in = CLUE for allowing a media consumer to request the provider to compose or = mix particular media sources into a new media stream, using a particular = algorithm?

a.       = Proposal – no, CLUE = does not need this.

b.      = But if something like = item 5 idea is accepted, then maybe a provider can offer a few = alternatives and a consumer can choose among them

 

Mark = Duckworth

 

= --Boundary_(ID_bnBe0bvz00jWYRWB4OHr9A)-- From pkyzivat@alum.mit.edu Thu Oct 27 15:21:00 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5EA91F0C3D for ; Thu, 27 Oct 2011 15:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdtE6Gmr-TQ1 for ; Thu, 27 Oct 2011 15:20:59 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id AE4391F0C44 for ; Thu, 27 Oct 2011 15:20:56 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by QMTA11.westchester.pa.mail.comcast.net with comcast id puoG1h0051ZXKqc5ByLxHD; Thu, 27 Oct 2011 22:20:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta21.westchester.pa.mail.comcast.net with comcast id pyLw1h00V0tdiYw3hyLwWk; Thu, 27 Oct 2011 22:20:57 +0000 Message-ID: <4EA9D946.3090402@alum.mit.edu> Date: Thu, 27 Oct 2011 18:20:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A61CE42473E@CRPMBOXPRD01.polycom.com> <0a0301cc94f3$19359ed0$4ba0dc70$%roni@huawei.com> In-Reply-To: <0a0301cc94f3$19359ed0$4ba0dc70$%roni@huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Kick-off Item 2: Layout, composition, switching discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 22:21:01 -0000 On 10/27/11 5:55 PM, Roni Even wrote: > Hi Mark, > > I understand that you have two topics > > 1.Allowing the consumer to select specific media streams for a mix (for > example, left camera from room 1, middle camera from room 2 and left > camera from room 3) which I think should be possible. This will require > information and protocol that will allow this functionality. > > 2.Allowing the provider to specify the mixture algorithm and for the > consumer to ask for a specific one. I think that we need at least to > enable the provider and consumer to specify or request site switch or > segment switch mode. This all sounds useful. But ISTM there should be a very clear distinction between choices that affect only the consumer making the choice, and those that affect other consumers, because of physical or resource constraints. Typically it won't matter as long as there are only two endpoints, but as soon as there are more it may. Thanks, Paul > Roni > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Duckworth, Mark > *Sent:* Thursday, October 27, 2011 5:30 PM > *To:* clue@ietf.org > *Subject:* [clue] Kick-off Item 2: Layout, composition, switching discussion > > This is following up on the major issues list from the interim meeting > in Andover. > > Issues for discussion: > > 1.Item 5 video composition (discussion kicked off by Stephan) is a part > of this. But more generally, the same sort of issue applies to other > media types, not just video. > > a.For example, should a provider that mixes audio be able to indicate to > the consumer which audio sources are in the mix? > > b.Proposal – the more general case should be consistent with the outcome > of the Item 5 discussio > > 2.Should a provider that mixes or composes other media captures/streams > into a new stream be able to indicate some information about the > algorithm it uses to choose which other captures/streams to mix? > > a.Proposal – no, CLUE does not need this. > > 3.Should a provider that mixes or composes media be able to allow the > consumer to make a choice about which other captures/streams are > included in the mix? > > a.This should be covered by Major Issue Item 3 source selection – > (discussion to be kicked off by Jonathan) > > 4.Do we need support in CLUE for allowing a media consumer to request > the provider to compose or mix particular media sources into a new media > stream, using a particular algorithm? > > a.Proposal – no, CLUE does not need this. > > b.But if something like item 5 idea is accepted, then maybe a provider > can offer a few alternatives and a consumer can choose among them > > Mark Duckworth > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Fri Oct 28 08:50:37 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC6A21F8549 for ; Fri, 28 Oct 2011 08:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.296 X-Spam-Level: X-Spam-Status: No, score=-103.296 tagged_above=-999 required=5 tests=[AWL=-2.801, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqyVqBD9WD2D for ; Fri, 28 Oct 2011 08:50:34 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3B59B21F853E for ; Fri, 28 Oct 2011 08:50:34 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTS00CQ097XVK@szxga03-in.huawei.com> for clue@ietf.org; Fri, 28 Oct 2011 23:47:58 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTS00GWO97X99@szxga03-in.huawei.com> for clue@ietf.org; Fri, 28 Oct 2011 23:47:57 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-199-250.red.bezeqint.net [79.183.199.250]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LTS007A897JGZ@szxml12-in.huawei.com>; Fri, 28 Oct 2011 23:47:57 +0800 (CST) Date: Fri, 28 Oct 2011 17:45:07 +0200 From: Roni Even In-reply-to: <4EA9D946.3090402@alum.mit.edu> To: 'Paul Kyzivat' , clue@ietf.org Message-id: <0a9c01cc9588$9b23d750$d16b85f0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcyU9s2mF2IGdyC/R22f7h9iIWP72gAkTRng References: <44C6B6B2D0CF424AA90B6055548D7A61CE42473E@CRPMBOXPRD01.polycom.com> <0a0301cc94f3$19359ed0$4ba0dc70$%roni@huawei.com> <4EA9D946.3090402@alum.mit.edu> Subject: Re: [clue] Kick-off Item 2: Layout, composition, switching discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 15:50:38 -0000 Paul, A consumer should be able to request specific streams from the offered set. The provider (probably an MCU) may send them mixed as one stream or as separate streams. As for mixing, I think that many MCUs can send a different mixed stream to each consumer. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Friday, October 28, 2011 12:21 AM > To: clue@ietf.org > Subject: Re: [clue] Kick-off Item 2: Layout, composition, switching > discussion > > On 10/27/11 5:55 PM, Roni Even wrote: > > Hi Mark, > > > > I understand that you have two topics > > > > 1.Allowing the consumer to select specific media streams for a mix > (for > > example, left camera from room 1, middle camera from room 2 and left > > camera from room 3) which I think should be possible. This will > require > > information and protocol that will allow this functionality. > > > > 2.Allowing the provider to specify the mixture algorithm and for the > > consumer to ask for a specific one. I think that we need at least to > > enable the provider and consumer to specify or request site switch or > > segment switch mode. > > This all sounds useful. But ISTM there should be a very clear > distinction between choices that affect only the consumer making the > choice, and those that affect other consumers, because of physical or > resource constraints. Typically it won't matter as long as there are > only two endpoints, but as soon as there are more it may. > > Thanks, > Paul > > > Roni > > > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > Behalf > > Of *Duckworth, Mark > > *Sent:* Thursday, October 27, 2011 5:30 PM > > *To:* clue@ietf.org > > *Subject:* [clue] Kick-off Item 2: Layout, composition, switching > discussion > > > > This is following up on the major issues list from the interim > meeting > > in Andover. > > > > Issues for discussion: > > > > 1.Item 5 video composition (discussion kicked off by Stephan) is a > part > > of this. But more generally, the same sort of issue applies to other > > media types, not just video. > > > > a.For example, should a provider that mixes audio be able to indicate > to > > the consumer which audio sources are in the mix? > > > > b.Proposal - the more general case should be consistent with the > outcome > > of the Item 5 discussio > > > > 2.Should a provider that mixes or composes other media > captures/streams > > into a new stream be able to indicate some information about the > > algorithm it uses to choose which other captures/streams to mix? > > > > a.Proposal - no, CLUE does not need this. > > > > 3.Should a provider that mixes or composes media be able to allow the > > consumer to make a choice about which other captures/streams are > > included in the mix? > > > > a.This should be covered by Major Issue Item 3 source selection - > > (discussion to be kicked off by Jonathan) > > > > 4.Do we need support in CLUE for allowing a media consumer to request > > the provider to compose or mix particular media sources into a new > media > > stream, using a particular algorithm? > > > > a.Proposal - no, CLUE does not need this. > > > > b.But if something like item 5 idea is accepted, then maybe a > provider > > can offer a few alternatives and a consumer can choose among them > > > > Mark Duckworth > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Fri Oct 28 10:24:07 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9674121F87C2 for ; Fri, 28 Oct 2011 10:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lXdlfE+-GVq for ; Fri, 28 Oct 2011 10:24:07 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id BC7C721F85A8 for ; Fri, 28 Oct 2011 10:24:06 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta04.westchester.pa.mail.comcast.net with comcast id qEV71h0071ei1Bg54HQ7Ck; Fri, 28 Oct 2011 17:24:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta24.westchester.pa.mail.comcast.net with comcast id qHQ61h0340tdiYw3kHQ6Rl; Fri, 28 Oct 2011 17:24:07 +0000 Message-ID: <4EAAE534.1020703@alum.mit.edu> Date: Fri, 28 Oct 2011 13:24:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Roni Even References: <44C6B6B2D0CF424AA90B6055548D7A61CE42473E@CRPMBOXPRD01.polycom.com> <0a0301cc94f3$19359ed0$4ba0dc70$%roni@huawei.com> <4EA9D946.3090402@alum.mit.edu> <0a9c01cc9588$9b23d750$d16b85f0$%roni@huawei.com> In-Reply-To: <0a9c01cc9588$9b23d750$d16b85f0$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Kick-off Item 2: Layout, composition, switching discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 17:24:07 -0000 On 10/28/11 11:45 AM, Roni Even wrote: > Paul, > A consumer should be able to request specific streams from the offered set. > The provider (probably an MCU) may send them mixed as one stream or as > separate streams. As for mixing, I think that many MCUs can send a different > mixed stream to each consumer. > Roni I think you are saying there won't be cases where requests by one consumer impact what another consumer can get. If so then the distinction I was asking about is moot. But some of these points suggest mechanisms to make requests that aren't just selections from an offered set, and that raise the possibility of requests that require more than a preplanned resource allocation. My point is that *if* this is possible it puts a different spin on the entire negotiation process. Thanks, Paul >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Friday, October 28, 2011 12:21 AM >> To: clue@ietf.org >> Subject: Re: [clue] Kick-off Item 2: Layout, composition, switching >> discussion >> >> On 10/27/11 5:55 PM, Roni Even wrote: >>> Hi Mark, >>> >>> I understand that you have two topics >>> >>> 1.Allowing the consumer to select specific media streams for a mix >> (for >>> example, left camera from room 1, middle camera from room 2 and left >>> camera from room 3) which I think should be possible. This will >> require >>> information and protocol that will allow this functionality. >>> >>> 2.Allowing the provider to specify the mixture algorithm and for the >>> consumer to ask for a specific one. I think that we need at least to >>> enable the provider and consumer to specify or request site switch or >>> segment switch mode. >> >> This all sounds useful. But ISTM there should be a very clear >> distinction between choices that affect only the consumer making the >> choice, and those that affect other consumers, because of physical or >> resource constraints. Typically it won't matter as long as there are >> only two endpoints, but as soon as there are more it may. >> >> Thanks, >> Paul >> >>> Roni >>> >>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On >> Behalf >>> Of *Duckworth, Mark >>> *Sent:* Thursday, October 27, 2011 5:30 PM >>> *To:* clue@ietf.org >>> *Subject:* [clue] Kick-off Item 2: Layout, composition, switching >> discussion >>> >>> This is following up on the major issues list from the interim >> meeting >>> in Andover. >>> >>> Issues for discussion: >>> >>> 1.Item 5 video composition (discussion kicked off by Stephan) is a >> part >>> of this. But more generally, the same sort of issue applies to other >>> media types, not just video. >>> >>> a.For example, should a provider that mixes audio be able to indicate >> to >>> the consumer which audio sources are in the mix? >>> >>> b.Proposal - the more general case should be consistent with the >> outcome >>> of the Item 5 discussio >>> >>> 2.Should a provider that mixes or composes other media >> captures/streams >>> into a new stream be able to indicate some information about the >>> algorithm it uses to choose which other captures/streams to mix? >>> >>> a.Proposal - no, CLUE does not need this. >>> >>> 3.Should a provider that mixes or composes media be able to allow the >>> consumer to make a choice about which other captures/streams are >>> included in the mix? >>> >>> a.This should be covered by Major Issue Item 3 source selection - >>> (discussion to be kicked off by Jonathan) >>> >>> 4.Do we need support in CLUE for allowing a media consumer to request >>> the provider to compose or mix particular media sources into a new >> media >>> stream, using a particular algorithm? >>> >>> a.Proposal - no, CLUE does not need this. >>> >>> b.But if something like item 5 idea is accepted, then maybe a >> provider >>> can offer a few alternatives and a consumer can choose among them >>> >>> Mark Duckworth >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From stephen.botzko@gmail.com Sat Oct 29 16:45:13 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3A811E8080 for ; Sat, 29 Oct 2011 16:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fG1YdLaX8-YS for ; Sat, 29 Oct 2011 16:45:13 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C247911E807F for ; Sat, 29 Oct 2011 16:45:12 -0700 (PDT) Received: by vws5 with SMTP id 5so4998190vws.31 for ; Sat, 29 Oct 2011 16:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rxxotcAlHPJ3zK8RA9lSsHeB+m5D0hduQOsmfgWu4A8=; b=ouOOqjNEnX6MraESbIGKpw4KCc191YZbXC8wRzYSTOD20BN2XynB0KjL+l7K+k5ELQ OF0oL4jZ8Aes92uXy/yhn6GUgxAHkXavI6hVx0ZqMBgi2ukymMTHC/qYiluJJ4KF1krf ypjauVgZKErUqp07dQfhD/UjdrqVfq03DMn8k= MIME-Version: 1.0 Received: by 10.52.69.235 with SMTP id h11mr2047080vdu.92.1319931912235; Sat, 29 Oct 2011 16:45:12 -0700 (PDT) Received: by 10.52.112.196 with HTTP; Sat, 29 Oct 2011 16:45:12 -0700 (PDT) In-Reply-To: <4EAAE534.1020703@alum.mit.edu> References: <44C6B6B2D0CF424AA90B6055548D7A61CE42473E@CRPMBOXPRD01.polycom.com> <0a0301cc94f3$19359ed0$4ba0dc70$%roni@huawei.com> <4EA9D946.3090402@alum.mit.edu> <0a9c01cc9588$9b23d750$d16b85f0$%roni@huawei.com> <4EAAE534.1020703@alum.mit.edu> Date: Sat, 29 Oct 2011 19:45:12 -0400 Message-ID: From: Stephen Botzko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=20cf307c9f08c1ac5704b0789876 Cc: clue@ietf.org Subject: Re: [clue] Kick-off Item 2: Layout, composition, switching discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 23:45:13 -0000 --20cf307c9f08c1ac5704b0789876 Content-Type: text/plain; charset=ISO-8859-1 In-line Stephen Botzko On Fri, Oct 28, 2011 at 1:24 PM, Paul Kyzivat wrote: > On 10/28/11 11:45 AM, Roni Even wrote: > >> Paul, >> A consumer should be able to request specific streams from the offered >> set. >> The provider (probably an MCU) may send them mixed as one stream or as >> separate streams. As for mixing, I think that many MCUs can send a >> different >> mixed stream to each consumer. >> Roni >> > > I think you are saying there won't be cases where requests by one consumer > impact what another consumer can get. If so then the distinction I was > asking about is moot. > > But some of these points suggest mechanisms to make requests that aren't > just selections from an offered set, and that raise the possibility of > requests that require more than a preplanned resource allocation. My point > is that *if* this is possible it puts a different spin on the entire > negotiation process. > [sb]It would mean that the provider needs to be able to deny the request. Are you seeing other implications? > Thanks, > Paul > > > -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >>> Paul Kyzivat >>> Sent: Friday, October 28, 2011 12:21 AM >>> To: clue@ietf.org >>> Subject: Re: [clue] Kick-off Item 2: Layout, composition, switching >>> discussion >>> >>> On 10/27/11 5:55 PM, Roni Even wrote: >>> >>>> Hi Mark, >>>> >>>> I understand that you have two topics >>>> >>>> 1.Allowing the consumer to select specific media streams for a mix >>>> >>> (for >>> >>>> example, left camera from room 1, middle camera from room 2 and left >>>> camera from room 3) which I think should be possible. This will >>>> >>> require >>> >>>> information and protocol that will allow this functionality. >>>> >>>> 2.Allowing the provider to specify the mixture algorithm and for the >>>> consumer to ask for a specific one. I think that we need at least to >>>> enable the provider and consumer to specify or request site switch or >>>> segment switch mode. >>>> >>> >>> This all sounds useful. But ISTM there should be a very clear >>> distinction between choices that affect only the consumer making the >>> choice, and those that affect other consumers, because of physical or >>> resource constraints. Typically it won't matter as long as there are >>> only two endpoints, but as soon as there are more it may. >>> >>> Thanks, >>> Paul >>> >>> Roni >>>> >>>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On >>>> >>> Behalf >>> >>>> Of *Duckworth, Mark >>>> *Sent:* Thursday, October 27, 2011 5:30 PM >>>> *To:* clue@ietf.org >>>> *Subject:* [clue] Kick-off Item 2: Layout, composition, switching >>>> >>> discussion >>> >>>> >>>> This is following up on the major issues list from the interim >>>> >>> meeting >>> >>>> in Andover. >>>> >>>> Issues for discussion: >>>> >>>> 1.Item 5 video composition (discussion kicked off by Stephan) is a >>>> >>> part >>> >>>> of this. But more generally, the same sort of issue applies to other >>>> media types, not just video. >>>> >>>> a.For example, should a provider that mixes audio be able to indicate >>>> >>> to >>> >>>> the consumer which audio sources are in the mix? >>>> >>>> b.Proposal - the more general case should be consistent with the >>>> >>> outcome >>> >>>> of the Item 5 discussio >>>> >>>> 2.Should a provider that mixes or composes other media >>>> >>> captures/streams >>> >>>> into a new stream be able to indicate some information about the >>>> algorithm it uses to choose which other captures/streams to mix? >>>> >>>> a.Proposal - no, CLUE does not need this. >>>> >>>> 3.Should a provider that mixes or composes media be able to allow the >>>> consumer to make a choice about which other captures/streams are >>>> included in the mix? >>>> >>>> a.This should be covered by Major Issue Item 3 source selection - >>>> (discussion to be kicked off by Jonathan) >>>> >>>> 4.Do we need support in CLUE for allowing a media consumer to request >>>> the provider to compose or mix particular media sources into a new >>>> >>> media >>> >>>> stream, using a particular algorithm? >>>> >>>> a.Proposal - no, CLUE does not need this. >>>> >>>> b.But if something like item 5 idea is accepted, then maybe a >>>> >>> provider >>> >>>> can offer a few alternatives and a consumer can choose among them >>>> >>>> Mark Duckworth >>>> >>>> >>>> >>>> ______________________________**_________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/**listinfo/clue >>>> >>> >>> ______________________________**_________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/**listinfo/clue >>> >> >> >> > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --20cf307c9f08c1ac5704b0789876 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In-line
Stephen Botzko

On Fri, Oct 28,= 2011 at 1:24 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 10/28/11 11:45 AM, Roni Even wrote:
Paul,
A consumer should be able to request specific streams from the offered set.=
The provider (probably an MCU) may send them mixed as one stream or as
separate streams. As for mixing, I think that many MCUs can send a differen= t
mixed stream to each consumer.
Roni

I think you are saying there won't be cases where requests by one consu= mer impact what another consumer can get. If so then the distinction I was = asking about is moot.

But some of these points suggest mechanisms to make requests that aren'= t just selections from an offered set, and that raise the possibility of re= quests that require more than a preplanned resource allocation. My point is= that *if* this is possible it puts a different spin on the entire negotiat= ion process.

[sb]It would mean that the provider needs to be able = to deny the request.=A0 Are you seeing other implications?


=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul


-----Original Message-----
From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
Paul Kyzivat
Sent: Friday, October 28, 2011 12:21 AM
To: clue@ietf.org Subject: Re: [clue] Kick-off Item 2: Layout, composition, switching
discussion

On 10/27/11 5:55 PM, Roni Even wrote:
Hi Mark,

I understand that you have two topics

1.Allowing the consumer to select specific media streams for a mix
(for
example, left camera from room 1, middle camera from room 2 and left
camera from room 3) which I think should be possible. This will
require
information and protocol that will allow this functionality.

2.Allowing the provider to specify the mixture algorithm and for the
consumer to ask for a specific one. I think that we need at least to
enable the provider and consumer to specify or request site switch or
segment switch mode.

This all sounds useful. But ISTM there should be a very clear
distinction between choices that affect only the consumer making the
choice, and those that affect other consumers, because of physical or
resource constraints. Typically it won't matter as long as there are only two endpoints, but as soon as there are more it may.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul

Roni

*From:*clue-boun= ces@ietf.org [mailto:clue-bounces@ietf.org] *On
Behalf
Of *Duckworth, Mark
*Sent:* Thursday, October 27, 2011 5:30 PM
*To:* clue@ietf.org<= br> *Subject:* [clue] Kick-off Item 2: Layout, composition, switching
discussion

This is following up on the major issues list from the interim
meeting
in Andover.

Issues for discussion:

1.Item 5 video composition (discussion kicked off by Stephan) is a
part
of this. But more generally, the same sort of issue applies to other
media types, not just video.

a.For example, should a provider that mixes audio be able to indicate
to
the consumer which audio sources are in the mix?

b.Proposal - the more general case should be consistent with the
outcome
of the Item 5 discussio

2.Should a provider that mixes or composes other media
captures/streams
into a new stream be able to indicate some information about the
algorithm it uses to choose which other captures/streams to mix?

a.Proposal - no, CLUE does not need this.

3.Should a provider that mixes or composes media be able to allow the
consumer to make a choice about which other captures/streams are
included in the mix?

a.This should be covered by Major Issue Item 3 source selection -
(discussion to be kicked off by Jonathan)

4.Do we need support in CLUE for allowing a media consumer to request
the provider to compose or mix particular media sources into a new
media
stream, using a particular algorithm?

a.Proposal - no, CLUE does not need this.

b.But if something like item 5 idea is accepted, then maybe a
provider
can offer a few alternatives and a consumer can choose among them

Mark Duckworth



_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue



_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf307c9f08c1ac5704b0789876-- From pkyzivat@alum.mit.edu Mon Oct 31 08:35:09 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA40421F8C56 for ; Mon, 31 Oct 2011 08:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7bRmrDO-HBl for ; Mon, 31 Oct 2011 08:35:09 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id DEEDF21F8C99 for ; Mon, 31 Oct 2011 08:35:08 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta08.westchester.pa.mail.comcast.net with comcast id rTXT1h0030QuhwU58Tb9FX; Mon, 31 Oct 2011 15:35:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta02.westchester.pa.mail.comcast.net with comcast id rTb81h02i0tdiYw3NTb871; Mon, 31 Oct 2011 15:35:09 +0000 Message-ID: <4EAEC02F.20401@alum.mit.edu> Date: Mon, 31 Oct 2011 11:35:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Stephen Botzko References: <44C6B6B2D0CF424AA90B6055548D7A61CE42473E@CRPMBOXPRD01.polycom.com> <0a0301cc94f3$19359ed0$4ba0dc70$%roni@huawei.com> <4EA9D946.3090402@alum.mit.edu> <0a9c01cc9588$9b23d750$d16b85f0$%roni@huawei.com> <4EAAE534.1020703@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Kick-off Item 2: Layout, composition, switching discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 15:35:10 -0000 inline On 10/29/11 7:45 PM, Stephen Botzko wrote: > In-line > Stephen Botzko > > On Fri, Oct 28, 2011 at 1:24 PM, Paul Kyzivat > wrote: > > On 10/28/11 11:45 AM, Roni Even wrote: > > Paul, > A consumer should be able to request specific streams from the > offered set. > The provider (probably an MCU) may send them mixed as one stream > or as > separate streams. As for mixing, I think that many MCUs can send > a different > mixed stream to each consumer. > Roni > > > I think you are saying there won't be cases where requests by one > consumer impact what another consumer can get. If so then the > distinction I was asking about is moot. > > But some of these points suggest mechanisms to make requests that > aren't just selections from an offered set, and that raise the > possibility of requests that require more than a preplanned resource > allocation. My point is that *if* this is possible it puts a > different spin on the entire negotiation process. > > > [sb]It would mean that the provider needs to be able to deny the > request. Are you seeing other implications? If requests are always to be denied when they negatively impact some other participant, then that is probably sufficient. The problem I am considering is if a request might be accepted even though it negatively impacts some other participant. In such a case the one making the request ought to know the implications. For instance, at one point there was talk of a camera that could either one of two views. Both could be offered as captures, but they are mutually exclusive to the entire collection of remote endpoints. In a two endpoint call there is no problem allowing the remote endpoint to choose. But when there is an MCU and more than two endpoints, the MCU could still offer both captures, but a choice among them by one endpoint removes the choice from the others. What I am thinking of is something like floor control: access to scarce resources should be explicitly managed. Perhaps in such a situation the two alternative captures aren't represented the same way that normal capture sets are. Rather there is some distinct control mechanism that has the effect of altering the available capture sets. Thanks, Paul > Thanks, > Paul > > > -----Original Message----- > From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org > ] On Behalf Of > Paul Kyzivat > Sent: Friday, October 28, 2011 12:21 AM > To: clue@ietf.org > Subject: Re: [clue] Kick-off Item 2: Layout, composition, > switching > discussion > > On 10/27/11 5:55 PM, Roni Even wrote: > > Hi Mark, > > I understand that you have two topics > > 1.Allowing the consumer to select specific media streams > for a mix > > (for > > example, left camera from room 1, middle camera from > room 2 and left > camera from room 3) which I think should be possible. > This will > > require > > information and protocol that will allow this functionality. > > 2.Allowing the provider to specify the mixture algorithm > and for the > consumer to ask for a specific one. I think that we need > at least to > enable the provider and consumer to specify or request > site switch or > segment switch mode. > > > This all sounds useful. But ISTM there should be a very clear > distinction between choices that affect only the consumer > making the > choice, and those that affect other consumers, because of > physical or > resource constraints. Typically it won't matter as long as > there are > only two endpoints, but as soon as there are more it may. > > Thanks, > Paul > > Roni > > *From:*clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org > ] *On > > Behalf > > Of *Duckworth, Mark > *Sent:* Thursday, October 27, 2011 5:30 PM > *To:* clue@ietf.org > *Subject:* [clue] Kick-off Item 2: Layout, composition, > switching > > discussion > > > This is following up on the major issues list from the > interim > > meeting > > in Andover. > > Issues for discussion: > > 1.Item 5 video composition (discussion kicked off by > Stephan) is a > > part > > of this. But more generally, the same sort of issue > applies to other > media types, not just video. > > a.For example, should a provider that mixes audio be > able to indicate > > to > > the consumer which audio sources are in the mix? > > b.Proposal - the more general case should be consistent > with the > > outcome > > of the Item 5 discussio > > 2.Should a provider that mixes or composes other media > > captures/streams > > into a new stream be able to indicate some information > about the > algorithm it uses to choose which other captures/streams > to mix? > > a.Proposal - no, CLUE does not need this. > > 3.Should a provider that mixes or composes media be able > to allow the > consumer to make a choice about which other > captures/streams are > included in the mix? > > a.This should be covered by Major Issue Item 3 source > selection - > (discussion to be kicked off by Jonathan) > > 4.Do we need support in CLUE for allowing a media > consumer to request > the provider to compose or mix particular media sources > into a new > > media > > stream, using a particular algorithm? > > a.Proposal - no, CLUE does not need this. > > b.But if something like item 5 idea is accepted, then > maybe a > > provider > > can offer a few alternatives and a consumer can choose > among them > > Mark Duckworth > > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > From internet-drafts@ietf.org Mon Oct 31 12:41:35 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1D111E8196; Mon, 31 Oct 2011 12:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yny4ogSSByXp; Mon, 31 Oct 2011 12:41:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D476711E818C; Mon, 31 Oct 2011 12:41:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031194134.2947.8769.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 12:41:34 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 19:41:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tEle= presence Working Group of the IETF. Title : Requirements for Telepresence Multi-Streams Author(s) : Allyn Romanow Stephen Botzko Filename : draft-ietf-clue-telepresence-requirements-01.txt Pages : 12 Date : 2011-10-31 This memo discusses the requirements for a specification that enables telepresence interoperability, by describing the relationship between multiple RTP streams. In addition, the problem statement and definitions are also covered herein. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-clue-telepresence-requiremen= ts-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-clue-telepresence-requirement= s-01.txt From internet-drafts@ietf.org Mon Oct 31 14:22:21 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFACF11E8268; Mon, 31 Oct 2011 14:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kBLp-ugdb7O; Mon, 31 Oct 2011 14:22:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC3911E81E7; Mon, 31 Oct 2011 14:22:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031212220.19329.11050.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 14:22:20 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 21:22:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tEle= presence Working Group of the IETF. Title : Framework for Telepresence Multi-Streams Author(s) : Allyn Romanow Mark Duckworth Andrew Pepperell Brian Baldino Filename : draft-ietf-clue-framework-01.txt Pages : 34 Date : 2011-10-31 This memo offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple RTP streams. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-clue-framework-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-clue-framework-01.txt From allyn@cisco.com Mon Oct 31 15:49:06 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7C211E8338 for ; Mon, 31 Oct 2011 15:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCrhWiEo31BH for ; Mon, 31 Oct 2011 15:49:05 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E16F211E8336 for ; Mon, 31 Oct 2011 15:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=1660; q=dns/txt; s=iport; t=1320101346; x=1321310946; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=z/xUsZonCXkZIgtFby5cyC3w/3XHJIlbxjZ8uCGZ6Wg=; b=TrN9AATIz5NxZ2xoF/gSNyuHQBlDsUilducY1WpDjspjbRELPU1mkRLa ufHFhyzFjZ2wixCrkpt21i1W2DDXhG/lQ4z9YE7paUD+Zlk87qD2fuzej VZ5VZpFNmuaDy6Gj1GR95uS5cmOakP4r/n2xlidzudqdoflo776yqi7ek I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsBAOgkr06rRDoG/2dsb2JhbABDhHeUbEOOCoEGgQWBcgEBAQEDEgEQDQRDDgYBCBEEAQEDAgYGFwECAgMBRAcBAQUEAQQTCBqcQYEmAYxKkXaBMIY+M2EEiAaRPoxJ X-IronPort-AV: E=Sophos;i="4.69,435,1315180800"; d="scan'208";a="11524509" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 31 Oct 2011 22:49:05 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9VMn5wE000844 for ; Mon, 31 Oct 2011 22:49:05 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 15:49:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 31 Oct 2011 15:49:04 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC06060DD2@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-lennox-clue-rtp-usage-01.txt Thread-Index: AcyYGK4Jz+cpDAI9QZ+43TVkXphlzQABkhLg From: "Allyn Romanow (allyn)" To: X-OriginalArrivalTime: 31 Oct 2011 22:49:05.0480 (UTC) FILETIME=[4AE48480:01CC981F] Subject: [clue] FW: New Version Notification for draft-lennox-clue-rtp-usage-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 22:49:06 -0000 Rm9sa3MsDQpIZXJlJ3MgYSBkcmFmdCBieSBKb25hdGhhbiwgUGF1bCBXaXR0eSwgYW5kIG15c2Vs ZiB0aGF0IGRpc2N1c3NlcyB0aGUgaXNzdWVzIGludm9sdmVkIGluIG11bHRpcGxleGluZyBSVFAg c3RyZWFtcyBvbiBhIHNpbmdsZSBSVFAgc2Vzc2lvbi0gaW4gcGFydGljdWxhciBpdCBsb29rcyBh dCBkaWZmZXJlbnQgbWV0aG9kcyBvZiBkZW11bHRpcGxleGluZyBvciBtYXBwaW5nIHRoZSBzdHJl YW1zLg0KDQpBbGx5bg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNl bnQ6IE1vbmRheSwgT2N0b2JlciAzMSwgMjAxMSAzOjAyIFBNDQpUbzogam9uYXRoYW5AdmlkeW8u Y29tDQpDYzogam9uYXRoYW5AdmlkeW8uY29tOyBBbGx5biBSb21hbm93IChhbGx5bik7IFBhdWwg V2l0dHkgKHBhdXdpdHR5KQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1sZW5ub3gtY2x1ZS1ydHAtdXNhZ2UtMDEudHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1sZW5ub3gtY2x1ZS1ydHAtdXNhZ2UtMDEudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgSm9uYXRoYW4gTGVubm94IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw b3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1sZW5ub3gtY2x1ZS1ydHAtdXNhZ2UNClJldmlz aW9uOgkgMDENClRpdGxlOgkJIFJlYWwtVGltZSBUcmFuc3BvcnQgUHJvdG9jb2wgKFJUUCkgVXNh Z2UgZm9yIFRlbGVwcmVzZW5jZSBTZXNzaW9ucw0KQ3JlYXRpb24gZGF0ZToJIDIwMTEtMTAtMzEN CldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMg0KDQpB YnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIG1lY2hhbmlzbXMgYW5kIHJlY29t bWVuZGVkIHByYWN0aWNlIGZvcg0KICAgdHJhbnNtaXR0aW5nIHRoZSBtZWRpYSBzdHJlYW1zIG9m IHRlbGVwcmVzZW5jZSBzZXNzaW9ucyB1c2luZyB0aGUNCiAgIFJlYWwtVGltZSBUcmFuc3BvcnQg UHJvdG9jb2wgKFJUUCkuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0K From stewe@stewe.org Mon Oct 31 16:02:56 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535F611E833C for ; Mon, 31 Oct 2011 16:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aR8zxpLCVl66 for ; Mon, 31 Oct 2011 16:02:55 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 936A511E8363 for ; Mon, 31 Oct 2011 16:02:55 -0700 (PDT) Received: from [192.168.1.64] (unverified [71.202.147.60]) by stewe.org (SurgeMail 3.9e) with ESMTP id 55060-1743317 for ; Tue, 01 Nov 2011 00:02:54 +0100 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Mon, 31 Oct 2011 16:02:29 -0700 From: Stephan Wenger To: "clue@ietf.org" Message-ID: Thread-Topic: New Version Notification for draft-wenger-clue-definitions-02.txt In-Reply-To: <20111031230059.18140.82722.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 71.202.147.60 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.147.60) was found in the spamhaus database. http://www.spamhaus.net Subject: [clue] FW: New Version Notification for draft-wenger-clue-definitions-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:02:56 -0000 Hi, I rev-ed the definitions draft by mechanically copy-pasting those definitions from the framework draft that were not already present. Stephan On 10.31.2011 16:00 , "internet-drafts@ietf.org" wrote: >A new version of I-D, draft-wenger-clue-definitions-02.txt has been >successfully submitted by Stephan Wenger and posted to the IETF >repository. > >Filename: draft-wenger-clue-definitions >Revision: 02 >Title: CLUE Definitions >Creation date: 2011-10-31 >WG ID: Individual Submission >Number of pages: 9 > >Abstract: > This document collects terminology and definitions to be used > consistently among documents produced in the CLUE working group. > > > > > >The IETF Secretariat