From rem-conf Thu Oct 01 03:15:08 1998 From rem-conf-request@es.net Thu Oct 01 03:15:07 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zOffR-0007B0-00; Thu, 1 Oct 1998 03:09:01 -0700 Received: from mp1715.hknet.com ([202.67.252.78] helo=mailer1.hinet.net) by mail2.es.net with smtp (Exim 1.92 #1) id 0zOffO-0007Aa-00; Thu, 1 Oct 1998 03:08:58 -0700 To: From: Subject: "Market Research in Asia" Date: Thu, 1 Oct 1998 14:36:40 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Planning any marketing research in Asia? The combination of MBL's over a decade of experience in the region together with fourteen operating companies across Asia/Australia provides you with the value-added you need from your research program. For full details, mailto:forsales@bigfoot.com?Subject=MBL_ASIA_PACIFIC From rem-conf Thu Oct 01 09:49:46 1998 From rem-conf-request@es.net Thu Oct 01 09:49:45 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zOlmf-00006D-00; Thu, 1 Oct 1998 09:40:53 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zOlme-000063-00; Thu, 1 Oct 1998 09:40:52 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id JAA18389 for ; Thu, 1 Oct 1998 09:40:51 -0700 (PDT) Message-Id: <3.0.3.32.19981001094051.00a71e70@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 01 Oct 1998 09:40:51 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 10/07 Berkeley, Multimedia, Interfaces, and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list
Electronic Books and Reading Appliances: Can Computers Help Us Read?
Wednesday October 7, 1998 12:30-2:00 PDT 405 Soda Hall
Bill N. Schilit FX Palo Alto Laboratory
Electronic books are hot, but why would I want to read a book on a computer anyway? In this talk I'll describe our research developing "reading appliances" -- portable computers specialized for reading and critical thinking. I'll present a number of ways that knowledge work can be augmented and transformed by the use of such appliances. These insights are based on the implementation of XLibris, an "active reading machine." This work is in collaboration with Morgan Price, Gene Golovchinsky and Cathy Marshall. ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Thu Oct 01 10:58:53 1998 From rem-conf-request@es.net Thu Oct 01 10:58:52 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zOmwO-0001Rb-00; Thu, 1 Oct 1998 10:55:00 -0700 Received: from gateway-gw.pictel.com [140.242.1.1] by mail1.es.net with smtp (Exim 1.81 #2) id 0zOmwK-0001RB-00; Thu, 1 Oct 1998 10:54:58 -0700 Received: from pictel.com (roadrunner.pictel.com) by gateway-gw.pictel.com (4.1/cf.gw.970707.rdw) id AA00873; Thu, 1 Oct 98 13:53:06 EDT Received: from python.pictel.com by pictel.com (4.1/SMI-4.1) id AA06002; Thu, 1 Oct 98 13:51:58 EDT Received: by python.pictel.com (5.x/SMI-SVR4) id AA12157; Thu, 1 Oct 1998 13:51:39 -0400 Date: Thu, 1 Oct 1998 13:51:39 -0400 From: garys@python.pictel.com (Gary Sullivan) Message-Id: <9810011751.AA12157@python.pictel.com> To: fblair@s-vision.com, h323implementors@imtc.org, itu-adv-video@listserv.iterated.com, potsag@imtc.org, rem-conf@es.net, sg16.lbc@research.kpn.com, spike@8x8.COM Subject: Re: H.263 Picture Type Bits X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Forrest et al, In regard to the "split screen" and "doc camera" bits in H.263: The document camera bit is used in a number of systems, somewhere along the lines of how Mr. Helman says 8x8 uses it. I don't think anyone uses the split screen bit anymore. I heard there was once a product that used it, but that was a long time ago. These bits do not have any effect on the decoding of a bitstream. They are strictly informational. Best Wishes, Gary Sullivan >------------------------------------------- >From spike@8x8.COM Tue Sep 22 11:16:38 1998 >Date: Tue, 22 Sep 1998 08:15:43 -0700 >From: spike@8x8.COM (Daniel Helman) >Subject: Re: H.263 Picture Type Bits >To: potsag@imtc.org, h323implementors@imtc.org, sg16.lbc@research.kpn.com, rem-conf@es.net, fblair@s-vision.com The document camera bit is just that; it is on when the image is coming from a second camera pointed at a document. We use a 1->0 transition on this bit to indicate that the previous image should be stored for later viewing. If you have this storage capability your user interface can switch between live video and stored documents. We don't use the split screen bit. Dan Helman spike@8x8.com > Date: Tue, 22 Sep 1998 08:43:37 -0600 > From: Forrest Blair > > I'm looking for more detailed information about H.263 picture type bits 3 > and 4. Bit 3 is defined as "Split screen indicator" and bit 4 as "Document > camera indicator". > > The standard does not clearly define the purpose of these bits and how they > should be handled by the decoder if they are turned on. Any information you > have would be most helpful. > > Also, I'm curious to know if any encoders are actively using these features. > > Thanks in advance. > > Forrest Blair > Sorenson Vision, Inc. > From rem-conf Thu Oct 01 11:00:24 1998 From rem-conf-request@es.net Thu Oct 01 11:00:24 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zOn0p-0001Ur-00; Thu, 1 Oct 1998 10:59:35 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zOn0o-0001Ud-00; Thu, 1 Oct 1998 10:59:34 -0700 Received: from quimby.cs.berkeley.edu (quimby.CS.Berkeley.EDU [128.32.131.169]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with ESMTP id KAA00305 for ; Thu, 1 Oct 1998 10:59:33 -0700 (PDT) Message-Id: <199810011759.KAA00305@gumby.CS.Berkeley.EDU> X-Mailer: exmh version 1.6.9 8/22/96 From: "Larry Rowe" To: rem-conf@es.net Subject: [Berkeley MIG Seminar] "Electronic Books and Reading Appliances: Can Computers Help Us Read?" Bill Schilit Wed 10/7/98 Reply-To: Rowe@bmrc.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Oct 1998 10:59:32 -0700 Sender: larry@bmrc.berkeley.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi - After many months of problems with multicast both on and off the Berkeley campus, the problems seem to have been resolved thanks to the work of Ken Lindahl, Kevin Almeroth, and Bill Fenner and the installation of the CALREN2 network in the Bay Area. Consequently, after several months of poor service/quality, we are back on the air. We have substantially improved the audio/video quality of the broadcasts and will continue to improve over the next couple of months. I think you'll also see that we have some very exciting seminars scheduled this semester (see http://bmrc.berkeley.edu/mig). The announcement for this week's seminar is below. You can join the session at the following addresses: video 224.2.163.7/57076 audio 224.2.147.61/27202 Please send me email if you have problems or questions about the broadcast. Larry -- Professor Lawrence A. Rowe Internet: Rowe@BMRC.Berkeley.EDU Computer Science Division - EECS Phone: 510-642-5117 University of California, Berkeley Fax: 510-642-5615 Berkeley, CA 94720-1776 URL: http://www.bmrc.berkeley.edu/~larry -- Electronic Books and Reading Appliances: Can Computers Help Us Read? Bill N. Schilit (FX Palo Alto Laboratory) Wednesday October 7, 1998 12:30-2:00 PDT 405 Soda Hall Electronic books are hot, but why would I want to read a book on a computer anyway? In this talk I'll describe our research developing "reading appliances" -- portable computers specialized for reading and critical thinking. I'll present a number of ways that knowledge work can be augmented and transformed by the use of such appliances. These insights are based on the implementation of XLibris, an "active reading machine." This work is in collaboration with Morgan Price, Gene Golovchinsky and Cathy Marshall. From rem-conf Thu Oct 01 14:47:51 1998 From rem-conf-request@es.net Thu Oct 01 14:47:50 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zOqPS-0004L6-00; Thu, 1 Oct 1998 14:37:14 -0700 Received: from du68.compunetlink.com ([207.182.124.68] helo=207.182.124.68) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zOqPR-0004Kl-00; Thu, 1 Oct 1998 14:37:13 -0700 From: wealth@angelfire.com To: rem-conf@es.net Reply-To: wealth@angelfire.com Subject: Seeking Commission Based Sales Representatives and Distributors Message-Id: Date: Thu, 1 Oct 1998 14:37:13 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We are seeking commission-based sales representatives and distributors in your geographic market to spearhead the national roll-out for our Consumer Smart Product line. Whether you are a student or a senior citizen, everyone is qualified to earn extra income within our company. Could you use extra income? Are you tired of get rich schemes? If you can answer YES to these questions, then this is the perfect opportunity for you. This is not a pyramid or get rich quick scheme. This is a serious, legitmate business opportunity. We offer Consumer Smart Products at prices everyone can afford! Our products are useful for everyone and they make perfect gifts! All our products emphasize "Quality, Function and Value" For additional information, please reply to this email with more info in your subject heading. Only serious applicants need apply. Thank You From rem-conf Fri Oct 02 08:59:33 1998 From rem-conf-request@es.net Fri Oct 02 08:59:33 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zP7Ty-0004vC-00; Fri, 2 Oct 1998 08:51:02 -0700 Received: from usr63-dialup20.mix2.atlanta.cw.net (mail.mia.bellsouth.net) [166.55.226.148] by mail1.es.net with smtp (Exim 1.81 #2) id 0zP7Tw-0004uz-00; Fri, 2 Oct 1998 08:51:00 -0700 To: From: Subject: advertisement Date: Wed, 30 Sep 1998 12:42:20 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Digital Cities move over! Sidewalk move over!! City Search watch out!! The internet's fastest growing city guide search engine is here: http://www.onlinecityguide.com Win 2500 American Airlines Advantage miles in our City Trivia Contest!! Slash ALL of your travel costs IN HALF with our discount travel card!! We have over 1575 U. S. cities on line..You've got to see it to believe it!! Call us at 800-856-9870 for more info!!!!! Bookmark this site NOW!!! this message is sent by E Mail King and Assocites 1790 Bonhill Rd mississauga, On 561 540 4028 From rem-conf Sat Oct 03 10:05:34 1998 From rem-conf-request@es.net Sat Oct 03 10:05:32 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zPUty-0007OZ-00; Sat, 3 Oct 1998 09:51:26 -0700 Received: from mail.zrz.tu-berlin.de [130.149.4.15] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zPUtw-0007OP-00; Sat, 3 Oct 1998 09:51:24 -0700 Received: from ft.ee.TU-Berlin.DE (actually ftsu07.ee.TU-Berlin.DE) by mail.zrz.TU-Berlin.DE with SMTP (IC-PP); Sat, 3 Oct 1998 18:48:48 +0200 Received: from ftsu31 by ft.ee.TU-Berlin.DE (8.8.6/ZRZ-Gen-8) with SMTP id SAA16178 for ; Sat, 3 Oct 1998 18:48:36 +0200 (MET DST) Sender: momuc98@ft.ee.TU-Berlin.DE Message-ID: <36165564.22A3@ft.ee.tu-berlin.de> Date: Sat, 03 Oct 1998 18:48:36 +0200 From: momuc98 Organization: Technical University of Berlin X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5 sun4m) MIME-Version: 1.0 To: miint@ft.ee.TU-Berlin.DE Subject: Only a few days before MoMuC'98 and DEMO'98 Content-Type: text/plain; charset=us-ascii; name="last-call" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="last-call" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colleague, Enclosed is the last Call-for-Participation for MoMuC'98 and DEMO'98 with some highlights of the technical program. Please feel free to distribute it to interested colleagues and post it as appropriate. Also, please accept our sincere apologies if you receive multiple copies of this CFP. For your registration use the forms found in http://momuc98.ee.tu-berlin.de/reg.html Best regards MoMuC'98 CALL FOR PARTICIPATION and TECHNICAL PROGRAM MoMuC '98 Fifth International Workshop on Mobile Multimedia Communication and DEMO'98 First Workshop on Wireless Broadband Testbeds Berlin, Germany October 12-15, 1998 WWW: http://momuc98.ee.tu-berlin.de http://comet.columbia.edu/demo98/ email: momuc98@ee.tu-berlin.de MoMuC'98 is technical Co-Sponsored by IEEE (German Section), ComSoc, ITG Germany, Telecommunication Networks Group Technical University Berlin supported from the European's Commission ACTS Programme. financial sponsored by Ericsson, Siemens, Philips, NEC Europe, ALOHA Networks Inc, Novedia, DEMO'98 is sponsored by NOKIA (DEMO'98), Center for Telecommunications Research, Columbia University in cooperation with ACM-SIGMOBILE TECHNICAL PROGRAM http://momuc98.ee.tu-berlin.de/pprogram.html http://comet.ctr.columbia.edu/demo98/outline.html The 3-day technical program primarily consists of contributed research papers. In addition, there are distinguished invited speakers and expert panel sessions providing a broad perspective in each technical area. DEMO'98 follows on the 4th day demonstrating operational state-of-the-art wireless broadband prototypes and testbeds, including wireless ATM systems, high speed wireless LANs and next generation cellular systems. INVITED TALKS (http://momuc98.ee.tu-berlin.de/talks.html) Speaker: Prof. David J. Goodman, From: WINLAB, Rutgers University, USA Title: A New Paradigm for Mobile Multimedia Communications Speaker: Prof. H. Tominaga, Chairman of MoMuC-J From: Waseda University, Tokio, JAPAN Title: Background, History, Motivation and the Future Vision of Mobile Multimedia Communication Speaker: Prof. Norman Abramson From: ALOHA Networks, Inc., USA Title: ALOHA to the Web Speaker: Prof. Dr. Hiroshi YASUDA From: The University of Tokio, JAPAN Title: Visual Technology Trend in Mobile Multimedia PANELS (http://momuc98.ee.tu-berlin.de/panels.html) Broadband Wireless in ACTS: Lessons and Key Challenges Chairmann: Dr. Jorge Pereira, European Commission Real Applications of Multimedia Mobile Communications Chairman: D. Raychaudhuri, NEC, Princeton SESSIONS (http://momuc98.ee.tu-berlin.de/sessions.html) October 12. - System Architectures for Mobile Multimedia Support (1) - QoS Support in Wireless ATM - System Architectures for Mobile Multimedia Support (2) - QoS Support in Wireless Networks October 13. - Wireless Internet Access (1) - Mobile Multimedia Performance issues (1) - Wireless Internet Access (2) - Mobile Multimedia Performance Issues (2) October 14. - Radio Interfaces for Mobile Multimedia - Wireless Links Enhancements for Mobile Multimedia Support - Wireless ATM Handover - Middleware DEMO'98 October 15. - International Broadband Wireless Initiatives European View: The ETSI Broadband Radio Access Network (BRAN) Japanese View: Multimedia Mobile Access Communication Systems (MMAC) US view: IEEE Wireless LAN Committee P 802.11 Project - Project Presentations and Demos DEMO: 25 Mbps/5 GHz Radio ATM Project Developers: Olivetti and Oracle Research Lab (ORL), Cambridge, UK DEMO: 25 Mbps/5 GHz Wireless ATM System Developers: NEC USA, C&C Research Laboratories DEMO: 50 MHz AWACS DEMO SYSTEM Developers: Elektrobit, NTT, Alcatel DEMO: 20 Mbps/5 GHz Radio ATM Project Developers: Magic WAND, ACTS project DEMO: DAB/GSM Communication System for Mobile Interactive Services. Developers: ACTS MEMO Project, Robert Bosch GmbH and Deutsche Telekom AG DEMO: The MOBIWARE Toolkit for Open Programmable Mobile Networking Developers: Center for Telecommunications Research, Columbia University DEMO: Adaptive Compression for Wireless Communications Developers: Uppsala University, Sweden From rem-conf Sat Oct 03 10:21:53 1998 From rem-conf-request@es.net Sat Oct 03 10:21:53 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zPVEe-0007fY-00; Sat, 3 Oct 1998 10:12:48 -0700 Received: from mail.zrz.tu-berlin.de [130.149.4.15] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zPVEc-0007fM-00; Sat, 3 Oct 1998 10:12:46 -0700 Received: from ft.ee.TU-Berlin.DE (actually ftsu07.ee.TU-Berlin.DE) by mail.zrz.TU-Berlin.DE with SMTP (IC-PP); Sat, 3 Oct 1998 18:54:47 +0200 Received: from ftsu31 by ft.ee.TU-Berlin.DE (8.8.6/ZRZ-Gen-8) with SMTP id SAA16403 for ; Sat, 3 Oct 1998 18:53:25 +0200 (MET DST) Sender: momuc98@ft.ee.TU-Berlin.DE Message-ID: <36165684.7997@ft.ee.tu-berlin.de> Date: Sat, 03 Oct 1998 18:53:24 +0200 From: momuc98 Organization: Technical University of Berlin X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5 sun4m) MIME-Version: 1.0 To: miint@ft.ee.TU-Berlin.DE Subject: Only a few days before MoMuC'98 and DEMO'98 Content-Type: text/plain; charset=us-ascii; name="last-call" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="last-call" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colleague, Enclosed is the last Call-for-Participation for MoMuC'98 and DEMO'98 with some highlights of the technical program. Please feel free to distribute it to interested colleagues and post it as appropriate. Also, please accept our sincere apologies if you receive multiple copies of this CFP. For your registration use the forms found in http://momuc98.ee.tu-berlin.de/reg.html Best regards MoMuC'98 CALL FOR PARTICIPATION and TECHNICAL PROGRAM MoMuC '98 Fifth International Workshop on Mobile Multimedia Communication and DEMO'98 First Workshop on Wireless Broadband Testbeds Berlin, Germany October 12-15, 1998 WWW: http://momuc98.ee.tu-berlin.de http://comet.columbia.edu/demo98/ email: momuc98@ee.tu-berlin.de MoMuC'98 is technical Co-Sponsored by IEEE (German Section), ComSoc, ITG Germany, Telecommunication Networks Group Technical University Berlin supported from the European's Commission ACTS Programme. financial sponsored by Ericsson, Siemens, Philips, NEC Europe, ALOHA Networks Inc, Novedia, DEMO'98 is sponsored by NOKIA (DEMO'98), Center for Telecommunications Research, Columbia University in cooperation with ACM-SIGMOBILE TECHNICAL PROGRAM http://momuc98.ee.tu-berlin.de/pprogram.html http://comet.ctr.columbia.edu/demo98/outline.html The 3-day technical program primarily consists of contributed research papers. In addition, there are distinguished invited speakers and expert panel sessions providing a broad perspective in each technical area. DEMO'98 follows on the 4th day demonstrating operational state-of-the-art wireless broadband prototypes and testbeds, including wireless ATM systems, high speed wireless LANs and next generation cellular systems. INVITED TALKS (http://momuc98.ee.tu-berlin.de/talks.html) Speaker: Prof. David J. Goodman, From: WINLAB, Rutgers University, USA Title: A New Paradigm for Mobile Multimedia Communications Speaker: Prof. H. Tominaga, Chairman of MoMuC-J From: Waseda University, Tokio, JAPAN Title: Background, History, Motivation and the Future Vision of Mobile Multimedia Communication Speaker: Prof. Norman Abramson From: ALOHA Networks, Inc., USA Title: ALOHA to the Web Speaker: Prof. Dr. Hiroshi YASUDA From: The University of Tokio, JAPAN Title: Visual Technology Trend in Mobile Multimedia PANELS (http://momuc98.ee.tu-berlin.de/panels.html) Broadband Wireless in ACTS: Lessons and Key Challenges Chairmann: Dr. Jorge Pereira, European Commission Real Applications of Multimedia Mobile Communications Chairman: D. Raychaudhuri, NEC, Princeton SESSIONS (http://momuc98.ee.tu-berlin.de/sessions.html) October 12. - System Architectures for Mobile Multimedia Support (1) - QoS Support in Wireless ATM - System Architectures for Mobile Multimedia Support (2) - QoS Support in Wireless Networks October 13. - Wireless Internet Access (1) - Mobile Multimedia Performance issues (1) - Wireless Internet Access (2) - Mobile Multimedia Performance Issues (2) October 14. - Radio Interfaces for Mobile Multimedia - Wireless Links Enhancements for Mobile Multimedia Support - Wireless ATM Handover - Middleware DEMO'98 October 15. - International Broadband Wireless Initiatives European View: The ETSI Broadband Radio Access Network (BRAN) Japanese View: Multimedia Mobile Access Communication Systems (MMAC) US view: IEEE Wireless LAN Committee P 802.11 Project - Project Presentations and Demos DEMO: 25 Mbps/5 GHz Radio ATM Project Developers: Olivetti and Oracle Research Lab (ORL), Cambridge, UK DEMO: 25 Mbps/5 GHz Wireless ATM System Developers: NEC USA, C&C Research Laboratories DEMO: 50 MHz AWACS DEMO SYSTEM Developers: Elektrobit, NTT, Alcatel DEMO: 20 Mbps/5 GHz Radio ATM Project Developers: Magic WAND, ACTS project DEMO: DAB/GSM Communication System for Mobile Interactive Services. Developers: ACTS MEMO Project, Robert Bosch GmbH and Deutsche Telekom AG DEMO: The MOBIWARE Toolkit for Open Programmable Mobile Networking Developers: Center for Telecommunications Research, Columbia University DEMO: Adaptive Compression for Wireless Communications Developers: Uppsala University, Sweden From rem-conf Sun Oct 04 10:25:33 1998 From rem-conf-request@es.net Sun Oct 04 10:25:33 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zPrkJ-0001uj-00; Sun, 4 Oct 1998 10:14:59 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zPrkI-0001uZ-00; Sun, 4 Oct 1998 10:14:58 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 4 Oct 1998 18:14:54 +0100 To: rem-conf@es.net Subject: RTP multiplexing Date: Sun, 04 Oct 1998 18:14:52 +0200 Message-ID: <1732.907521292@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list One of the main areas of discussion during the AVT meeting in Chicago was multiplexing multiple streams into a single RTP stream. Jonathan Rosenberg and Barani Subbiah presented somewhat similar proposals applicable for the efficient connection of PSTN gateways using RTP, whilst Tohru Hoshi and Mark Handley presented more general proposals. draft-ietf-avt-aggregation-00.txt draft-ietf-avt-mux-rtp-00.txt draft-tanigawa-rtp-multiplex-00.txt http://north.east.isi.edu/~mjh/slides/murge.8.98.ps It is clearly undesirable to have multiple protocols where a single solution might be found, so it was resolved that the group should work further on the problem definition with a view to combining these proposals. As a precurser to this, Jonathan Rosenberg committed to producing an update of his earlier "Issues and Options for RTP Multiplexing" document. This is now available as draft-ietf-avt-muxissues-00.txt The purpose of this note is to draw attention to this new draft and to encourage discussion of these issues. In particular, I wish to pose the following question to the group: are we designing an application specific protocol (interconnection of ITGs) or a general purpose one? We have the full range of proposals to choose from... -- Colin Perkins Email: c.perkins@cs.ucl.ac.uk Department of Computer Science Phone: (+44) 171 419 3666 University College London WWW : http://www.cs.ucl.ac.uk/staff/c.perkins/ From rem-conf Mon Oct 05 02:36:54 1998 From rem-conf-request@es.net Mon Oct 05 02:36:53 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zQ6z8-0000am-00; Mon, 5 Oct 1998 02:31:18 -0700 Received: from laposte.bsf.alcatel.fr (bsf.alcatel.fr) [193.104.128.7] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zQ6z5-0000aS-00; Mon, 5 Oct 1998 02:31:15 -0700 Received: from cabsimp1 (cabsimp1.col.bsf.alcatel.fr [155.132.46.160]) by bsf.alcatel.fr (8.8.8/8.8.8) with SMTP id LAA12112 for ; Mon, 5 Oct 1998 11:35:37 +0200 (MET DST) Received: from cabs40.clb by cabsimp1 (SMI-8.6/SMI-4.1) id LAA03611; Mon, 5 Oct 1998 11:29:16 +0200 Received: from c5s144.clb by cabs40.clb (SMI-8.6/SMI-SVR4) id LAA23144; Mon, 5 Oct 1998 11:28:52 +0200 Received: by c5s144.clb (SMI-8.6/SMI-SVR4) id LAA03133; Mon, 5 Oct 1998 11:32:35 +0200 Date: Mon, 5 Oct 1998 11:32:35 +0200 From: massin@col.bsf.alcatel.fr (Raphael Massin) Message-Id: <199810050932.LAA03133@c5s144.clb> To: rem-conf@es.net Subject: RTCP retransmission interval : maintaining the session members X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello all, I've just read the draft-ietf-avt-rtp-new-01.ps and it seems to me there is a print error in the 'bin' algorithm. How must be corrected the sentence : "When a new participant shows up whose SSRC matches the key under the current mask (with m bits), the SSRC identifier is placed in bin (???) in bin m that still match under the m+1 bit mask are moved from bin m to bin m+1, otherwise they are discarded as mentioned previously" ? Maybe this one could make it: "When a new participant shows up whose SSRC matches the key under the current mask (with m bits), the SSRC identifier is placed in bin m. When the mask size is increased from m to m+1, SSRC identifiers in bin m that still match under the m+1 bit mask are moved from bin m to bin m+1, otherwise they are discarded as mentioned previously". Best Regards, Raphael MASSIN Alcatel Telecom From rem-conf Mon Oct 05 04:50:09 1998 From rem-conf-request@es.net Mon Oct 05 04:50:08 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zQ94b-0002Do-00; Mon, 5 Oct 1998 04:45:05 -0700 Received: from idsc.gov.eg [163.121.2.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zQ94Z-0002Dc-00; Mon, 5 Oct 1998 04:45:04 -0700 Received: from ibr.gov.eg (governorates.idsc.gov.eg [163.121.13.80] (may be forged)) by idsc.gov.eg (8.8.8/8.8.8) with SMTP id NAA13992; Mon, 5 Oct 1998 13:39:04 +0200 (EET) Message-ID: <3618B112.27AE@idsc.gov.eg> Date: Mon, 05 Oct 1998 13:44:18 +0200 From: amr ibrahim Reply-To: mocscc@idsc.gov.eg X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net CC: videophone@es.net Subject: question on video conferencing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list hi we are students in faculty of engineering and we want to ask you about the video conferncing over a lan since we will do our project in it 1.what links do i search in 2.if you have any info about the subject from installing and constructing and the topolgies and everything if you please From rem-conf Mon Oct 05 07:02:45 1998 From rem-conf-request@es.net Mon Oct 05 07:02:45 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zQBAl-0004Ze-00; Mon, 5 Oct 1998 06:59:35 -0700 Received: from (matilda.wpine.com) [140.249.38.180] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zQBAk-0004ZU-00; Mon, 5 Oct 1998 06:59:35 -0700 Received: from alf-mobile ([140.249.42.94]) by matilda.wpine.com (Post.Office MTA v3.1 release PO203a ID# 0-34401U600L100S0) with SMTP id AAA4965; Mon, 5 Oct 1998 09:55:36 -0400 From: aeisenberg@wpine.com (Alfred Eisenberg) To: , Subject: RE: question on video conferencing Date: Mon, 5 Oct 1998 09:52:59 -0400 Message-ID: <000601bdf067$768b99c0$5e2af98c@alf-mobile.wpine.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <3618B112.27AE@idsc.gov.eg> Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list here's a start for a low cost solution. http://www.wpine.com/Products/index.html works on a lan or over the internet. alf >-----Original Message----- >From: amr ibrahim [mailto:mocscc@idsc.gov.eg] >Sent: Monday, October 05, 1998 7:44 AM >To: rem-conf@es.net >Cc: videophone@es.net >Subject: question on video conferencing > > >hi we are students in faculty of engineering and we want to ask you >about the video conferncing over a lan since we will do our project in >it >1.what links do i search in >2.if you have any info about the subject from installing and >constructing and the topolgies and everything if you please > From rem-conf Mon Oct 05 07:12:34 1998 From rem-conf-request@es.net Mon Oct 05 07:12:34 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zQBMU-00059g-00; Mon, 5 Oct 1998 07:11:42 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zQBMS-00056E-00; Mon, 5 Oct 1998 07:11:40 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA19208; Mon, 5 Oct 1998 10:10:37 -0400 (EDT) Message-Id: <199810051410.KAA19208@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-muxissues-00.txt Date: Mon, 05 Oct 1998 10:10:36 -0400 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Issues and Options for RTP Multiplexing Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-muxissues-00.txt Pages : 27 Date : 02-Oct-98 This memorandum discusses the issues and options involved in the design of a new transport protocol for multiplexed voice within a single packet. The intended application is the interconnection of devices which provide trunking or long distance telephone service over the Internet. Such devices have many voice connections simultaneously between them. Multiplexing them into the same connection improves on the efficiency, enables the use of low bitrate voice codecs, and improves scalability. Options and issues con- cerning timestamping, payload type identification, length indication, and channel identification are discussed. Sev- eral possible header formats are identified, and their efficiencies are compared. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-muxissues-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-muxissues-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-muxissues-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19981002111125.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-muxissues-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-muxissues-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981002111125.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Oct 05 07:25:04 1998 From rem-conf-request@es.net Mon Oct 05 07:25:04 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zQBYR-00067D-00; Mon, 5 Oct 1998 07:24:03 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0zQBYQ-000671-00; Mon, 5 Oct 1998 07:24:02 -0700 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Oct 5 10:23:30 EDT 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id KAA01401; Mon, 5 Oct 1998 10:23:29 -0400 (EDT) Message-ID: <3618D5A6.5B7C9089@dnrc.bell-labs.com> Date: Mon, 05 Oct 1998 10:20:22 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Raphael Massin CC: rem-conf@es.net Subject: Re: RTCP retransmission interval : maintaining the session members References: <199810050932.LAA03133@c5s144.clb> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Raphael Massin wrote: > > Hello all, > > I've just read the draft-ietf-avt-rtp-new-01.ps and it seems to me there is > a print error in the 'bin' algorithm. How must be corrected the sentence : > > "When a new participant shows up whose SSRC matches the key under the current > mask (with m bits), the SSRC identifier is placed in bin (???) in bin m that > still match under the m+1 bit mask are moved from bin m to bin m+1, otherwise > they are discarded as mentioned previously" ? Right; it seems a sentence is missing. In any case, it was agreed at the last meeting to move the sampling stuff into a separate document, and make it experimental track. The original latex source for the text appears correct, so this should be fixed when its moved. Thanks, Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Mon Oct 05 08:33:56 1998 From rem-conf-request@es.net Mon Oct 05 08:33:54 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zQCX0-0007lL-00; Mon, 5 Oct 1998 08:26:38 -0700 Received: from mail-relay.sig.eds.com [194.74.220.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zQCWz-0007kd-00; Mon, 5 Oct 1998 08:26:37 -0700 Received: from smtpmta.sig.eds.com (smtpmta.sig.eds.com [194.74.220.5]) by mail-relay.sig.eds.com (8.8.7/8.8.7) with SMTP id RAA05733 for ; Mon, 5 Oct 1998 17:09:56 +0100 Received: by smtpmta.sig.eds.com(Lotus SMTP MTA SMTP MTA v1.1.04 (495.1 10-24-1997)) id 80256694.0054D35C ; Mon, 5 Oct 1998 16:26:31 +0100 X-Lotus-FromDomain: CITYMAX From: "Shereen A Fahmy" To: rem-conf@es.net Message-ID: Date: Mon, 5 Oct 1998 17:21:36 +0300 Subject: Videoconferencing Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, This is Eng. Shereen Fahmy, I'm doing my researches in Videoconferencing techniques and algorithms. I realised that this is the videoconferencing mailing list, discussing all topics related to videoconferencing. I'm interested in the technique used and the algorithm applied in this desktop, would you please support me with some information concerning that. I would be very grateful if you guide me with references used. It will be appreciated if you reply to my mail. Thank you, Shereen From rem-conf Mon Oct 05 21:37:12 1998 From rem-conf-request@es.net Mon Oct 05 21:37:11 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zQOjy-0001PK-00; Mon, 5 Oct 1998 21:28:50 -0700 Received: from (mailer1.hinet.net) [202.67.219.140] by mail1.es.net with smtp (Exim 1.81 #2) id 0zQOjw-0001PA-00; Mon, 5 Oct 1998 21:28:48 -0700 To: From: Subject: Discount Insurance - Free Quotation Date: Tue, 6 Oct 1998 08:57:04 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We are specialist Investment and Insurance brokers.Throughout Asia, we can provide tailor made packages at the lowest prices to fulfill all of your needs. Please reply now for the full details! mailto:replynow@bitsmart.com?Subject=INVESTMENT_INSURANCE_DETAILS From rem-conf Tue Oct 06 00:21:44 1998 From rem-conf-request@es.net Tue Oct 06 00:21:43 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zQROv-0003K1-00; Tue, 6 Oct 1998 00:19:17 -0700 Received: from ss3000e.cselt.it [163.162.4.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zQROt-0003Jr-00; Tue, 6 Oct 1998 00:19:16 -0700 Received: from rabadan.cselt.stet.it by ss3000e.cselt.stet.it (PMDF V5.1-12 #29348) with ESMTP id <0F0E000C09I4LJ@ss3000e.cselt.stet.it> for rem-conf@es.net; Tue, 6 Oct 1998 09:15:40 +0200 (MET DST) Received: by rabadan.cselt.stet.it with Internet Mail Service (5.5.2232.9) id ; Tue, 06 Oct 1998 09:18:44 +0200 Content-return: allowed Date: Tue, 06 Oct 1998 09:19:03 +0200 From: Bracali Fabio Subject: vic+m-jpeg+Silicon Graphics O2 To: "'rem-conf@es.net'" Message-id: <69A4AB2CD710D211A0AF00805FA6EAF104274A@xrr3.cselt.stet.it> Old-X-Envelope-to: rem-conf@es.net MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi I have a Silicon Graphics O2 and I would like to use vic (and vat) to multicast some events in our corporate network. I also would like to use jpeg encoding (instaed of h261) because we have developed a client here in CSELT that uses it and we need to make some tests; Does anyone know if it is possible to use the built-in video capture card (mvp?) of O2 for this purpose? In the source distribution of vic I've noticed there is the code for the old Cosmo cards but I don't think it would work if I compile it in a new binary. Thanks Fabio From rem-conf Tue Oct 06 16:33:25 1998 From rem-conf-request@es.net Tue Oct 06 16:33:24 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zQgQS-0004P3-00; Tue, 6 Oct 1998 16:21:52 -0700 Received: from hertz.ece.wisc.edu [128.104.183.33] by mail1.es.net with smtp (Exim 1.81 #2) id 0zQgQR-0004Ot-00; Tue, 6 Oct 1998 16:21:51 -0700 Received: by hertz.ece.wisc.edu (SMI-8.6/SMI-SVR4) id SAA27878; Tue, 6 Oct 1998 18:21:39 -0500 Date: Tue, 6 Oct 1998 18:21:39 -0500 From: dovrolis@hertz.ece.wisc.edu (Constantinos) Message-Id: <199810062321.SAA27878@hertz.ece.wisc.edu> To: rem-conf@es.net Subject: OS issues in streaming apps Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: VfrZ1nPXi1OiibuKBfdtaA== X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi there, I am trying to find papers that discuss challenging operating system issues in the design of streaming mutimedia applications, or, on the other side, challenging issues on the design of operating systems to efficiently support streaming applications. Does anybody know of a good starting point for such works? Thanks a lot, Constantinos From rem-conf Thu Oct 08 06:13:09 1998 From rem-conf-request@es.net Thu Oct 08 06:13:08 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zRFVm-000532-00; Thu, 8 Oct 1998 05:49:42 -0700 Received: from mailserver.c-lab.de [131.234.80.124] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zRFVk-00052s-00; Thu, 8 Oct 1998 05:49:40 -0700 Received: from dagobert.c-lab.de (dagobert.c-lab.de [131.234.80.159]) by mailserver.c-lab.de (8.8.8/8.8.8) with ESMTP id OAA27603 for ; Thu, 8 Oct 1998 14:49:29 +0200 (MET DST) Received: from dagobert (localhost [127.0.0.1]) by dagobert.c-lab.de (8.7.5/8.7.3) with SMTP id OAA02138 for ; Thu, 8 Oct 1998 14:49:28 +0200 (MET DST) Sender: atteln@c-lab.de Message-ID: <361CB4D6.4658@uni-paderborn.de> Date: Thu, 08 Oct 1998 14:49:26 +0200 From: Simon Schneider X-Mailer: Mozilla 3.04 (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: rem-conf@es.net Subject: RSVP & Mbone Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I'm a student from Paderborn, Germany and currently work with a research project about multimedia on the internet. I'm looking for people who tried to use the RSVP protocol to make resource reservations on the MBone net ! Have there been projects in the past which realised the use of RSVP with MBone tools like vic or nv ? What we will try to do is send video over the MBone, but with a guaranteed quality of service. Has anybody ever done anything like this ? Thanks for help & hints, Simon Schneider, C-Lab, Paderborn From rem-conf Thu Oct 08 08:06:10 1998 From rem-conf-request@es.net Thu Oct 08 08:06:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zRHXQ-0006b6-00; Thu, 8 Oct 1998 07:59:32 -0700 Received: from engine3-dc.wdc.cwi.net [205.136.1.212] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zRHXO-0006aw-00; Thu, 8 Oct 1998 07:59:30 -0700 Received: from houston_cc_smtp.hai.com (hai.com [207.124.15.67]) by engine3-dc.wdc.cwi.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 100-36394U2500L250S0) with SMTP id AAA12456 for ; Thu, 8 Oct 1998 10:59:28 -0400 Received: from ccMail by houston_cc_smtp.hai.com (ccMail Link to SMTP R8.30.00.7) id AA907858722; Thu, 08 Oct 1998 10:58:46 -0400 Message-Id: <9810089078.AA907858722@houston_cc_smtp.hai.com> X-Mailer: ccMail Link to SMTP R8.30.00.7 Date: Thu, 08 Oct 1998 10:56:00 -0400 From: "Jackson Scott D." To: Subject: No subject given MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: "cc:Mail Note Part" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list unsubscribe sjackson@hai-net.com From rem-conf Thu Oct 08 08:57:01 1998 From rem-conf-request@es.net Thu Oct 08 08:57:01 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zRIPH-0007e6-00; Thu, 8 Oct 1998 08:55:11 -0700 Received: from zephyr.isi.edu [128.9.160.160] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zRIPG-0007dw-00; Thu, 8 Oct 1998 08:55:10 -0700 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id IAA29669; Thu, 8 Oct 1998 08:55:01 -0700 (PDT) Date: Thu, 8 Oct 1998 08:52:44 -0700 From: braden@ISI.EDU Posted-Date: Thu, 8 Oct 1998 08:52:44 -0700 Message-Id: <199810081552.AA17059@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Thu, 8 Oct 1998 08:52:44 -0700 To: rem-conf@es.net, atteln@uni-paderborn.de Subject: Re: RSVP & Mbone X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list *> *> I'm looking for people who tried to use the RSVP protocol to make *> resource reservations on the MBone net ! *> *> Have there been projects in the past which realised the use of RSVP with *> MBone tools like vic or nv ? *> RSVP-capable versions of vic and vat have been available from ISI for several years. See http://www.isi.edu/rsvp/release.html for information. Bob Braden From rem-conf Thu Oct 08 10:07:11 1998 From rem-conf-request@es.net Thu Oct 08 10:07:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zRJRT-0001EU-00; Thu, 8 Oct 1998 10:01:31 -0700 Received: from zephyr.isi.edu [128.9.160.160] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zRJRS-0001EK-00; Thu, 8 Oct 1998 10:01:30 -0700 Received: from roo.isi.edu (roo.isi.edu [128.9.160.127]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id KAA04204; Thu, 8 Oct 1998 10:01:30 -0700 (PDT) Posted-Date: Thu, 8 Oct 1998 10:01:29 -0700 (PDT) Received: from localhost by roo.isi.edu (5.65c/4.0.3-6) id ; Thu, 8 Oct 1998 10:01:29 -0700 Date: Thu, 8 Oct 1998 10:01:29 -0700 (PDT) From: Steven Berson To: Simon Schneider Cc: rem-conf@es.net Subject: Re: RSVP & Mbone In-Reply-To: <361CB4D6.4658@uni-paderborn.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Thu, 8 Oct 1998, Simon Schneider wrote: > Hi, > I'm a student from Paderborn, Germany and currently work with a research > project about multimedia on the internet. > I'm looking for people who tried to use the RSVP protocol to make > resource reservations on the MBone net ! > Have there been projects in the past which realised the use of RSVP with > MBone tools like vic or nv ? > What we will try to do is send video over the MBone, but with a > guaranteed quality of service. > Has anybody ever done anything like this ? Simon, At ISI, we are currently using RSVP with vic and vat for video conferencing. We recently did a release of our latest vic and vat code modified for use with RSVP (available from the RSVP web page - http://www.isi.edu/rsvp). Steve From rem-conf Thu Oct 08 10:10:16 1998 From rem-conf-request@es.net Thu Oct 08 10:10:16 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zRJZI-0001UW-00; Thu, 8 Oct 1998 10:09:36 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zRJZG-0001TS-00; Thu, 8 Oct 1998 10:09:35 -0700 Received: from thud.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Oct 1998 18:00:18 +0100 Date: Thu, 08 Oct 1998 18:00:03 +0100 Message-ID: <1139.907866003@cs.ucl.ac.uk> From: Jon Crowcroft Subject: IWQoS 99 Call for Papers BCC: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ------- Blind-Carbon-Copy to: jon Subject: IWQoS 99 Call for Papers Date: Thu, 08 Oct 1998 18:00:03 +0100 Message-ID: <1139.907866003@cs.ucl.ac.uk> From: Jon Crowcroft see http://www.cs.ucl.ac.uk/research/iwqos99 jon p.s. apologies for cross replies to cross posting ------- End of Blind-Carbon-Copy From rem-conf Thu Oct 08 15:12:51 1998 From rem-conf-request@es.net Thu Oct 08 15:12:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zRODL-0005Js-00; Thu, 8 Oct 1998 15:07:15 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zRODK-0005Ji-00; Thu, 8 Oct 1998 15:07:14 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id PAA16418 for ; Thu, 8 Oct 1998 15:07:13 -0700 (PDT) Message-Id: <3.0.3.32.19981008150712.00ba1b50@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 08 Oct 1998 15:07:12 -0700 To: rem-conf@es.net From: Florissa Colina Subject: 10/14 Seminar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia Research Center Berkeley Multimedia, Interfaces, and Graphics Seminar PRoPs: Towards Transparent Interfaces to the Real World Eric Paulos Computer Science Division - EECS University of California, Berkeley Wednesday October 14, 1998 12:30-2:00 PDT 405 Soda Hall Abstract: The internet has increased our tele-connectivity by allowing us to exchange text, images, sound, and video with anyone whose interests we share, professionally or socially, regardless of geographic location. But even with the rapid adoption of these new tools for human communication and interaction it is obvious that something is missing. Current internet applications fail to provide us with an adequate interface into the real world in which we live, work, and play. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Thu Oct 08 15:54:37 1998 From rem-conf-request@es.net Thu Oct 08 15:54:36 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zROur-0006Gl-00; Thu, 8 Oct 1998 15:52:13 -0700 Received: from smtp.salixtech.com (salix.com) [38.220.190.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zROup-0006GT-00; Thu, 8 Oct 1998 15:52:12 -0700 Received: from Biollante.salix.com ([10.1.1.21]) by gateway.salix.com with SMTP id <27780>; Thu, 8 Oct 1998 18:50:45 -0400 Received: by localhost with Microsoft MAPI; Thu, 8 Oct 1998 18:56:21 -0400 Message-ID: <01BDF2ED.56BC64C0.nm@salix.com> From: Negar Moshiri Reply-To: "nm@salix.com" To: "rem-conf@es.net" Subject: Date: Thu, 8 Oct 1998 18:56:20 -0400 Organization: SALIX Technologies, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 18 TEXT X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Does anybody know where I can get a draft copy of H.323 Version 3? Thanks, Negar Moshiri _______________________________________________________________ ========= =========== Negar Moshiri mailto:nm@salix.com ============ Staff Engineer http://www.salix.com ============ SALIX Technologies, Inc. == ==== == 904 Wind River Lane TEL: (301) 417-0017 == Suite 101 FAX: (301) 990-6400 === Gaithersburg, MD 20878 The statements contained herein are strictly those of their author, and unless otherwise specifically indicated should not be attributed to SALIX® or its management. From rem-conf Thu Oct 08 17:14:02 1998 From rem-conf-request@es.net Thu Oct 08 17:14:01 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zRQ7f-0007fb-00; Thu, 8 Oct 1998 17:09:31 -0700 Received: from (proxy2.activetouch.com) [202.47.133.202] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zRQ7e-0007ex-00; Thu, 8 Oct 1998 17:09:30 -0700 Received: from ANEWORLD by proxy2.activetouch.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id R5CN3S4R; Thu, 8 Oct 1998 17:06:57 -0700 Message-ID: <361D5564.88221B0F@activetouch.com> Date: Thu, 08 Oct 1998 17:14:28 -0700 From: Tony Zhao X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: "nm@salix.com" CC: "rem-conf@es.net" Subject: Re: References: <01BDF2ED.56BC64C0.nm@salix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list APC-1411-E June 1998 TITLE: Changes to H.323 for Version 3 ftp://standard.pictel.com/avc-site/9806_Can/ Negar Moshiri wrote: > Does anybody know where I can get a draft copy of H.323 Version 3? > > Thanks, > > Negar Moshiri > > _______________________________________________________________ > ========= > =========== Negar Moshiri mailto:nm@salix.com > ============ Staff Engineer http://www.salix.com > ============ SALIX Technologies, Inc. > == ==== == 904 Wind River Lane TEL: (301) 417-0017 > == Suite 101 FAX: (301) 990-6400 > === Gaithersburg, MD 20878 > > The statements contained herein are strictly those of > their author, and unless otherwise specifically indicated > should not be attributed to SALIX(r) or its management. From rem-conf Thu Oct 08 17:48:56 1998 From rem-conf-request@es.net Thu Oct 08 17:48:56 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zRQh9-0000mr-00; Thu, 8 Oct 1998 17:46:11 -0700 Received: from 171-108-99.ipt.aol.com (sorry) [152.171.108.99] by mail1.es.net with smtp (Exim 1.81 #2) id 0zRQh7-0000lk-00; Thu, 8 Oct 1998 17:46:10 -0700 To: From: Subject: ** CRITICAL MESSAGE ** Date: Thu, 8 Oct 1998 14:16:38 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list If you want tens of thousands of hits to your site, WITHOUT ADVERTISING, I can show you how to do it, IN 30 SECONDS! Click below for that information: http://www.clueclub.com/hits From rem-conf Thu Oct 08 19:21:38 1998 From rem-conf-request@es.net Thu Oct 08 19:21:37 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zRS8C-0002E0-00; Thu, 8 Oct 1998 19:18:12 -0700 Received: from george.lbl.gov [131.243.2.12] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zRS8B-0002Dq-00; Thu, 8 Oct 1998 19:18:11 -0700 Received: (from mperry@localhost) by george.lbl.gov (8.8.8/8.8.8) id TAA25087; Thu, 8 Oct 1998 19:17:34 -0700 (PDT) Date: Thu, 8 Oct 1998 19:17:34 -0700 (PDT) From: Marcia Perry (ITG staff) Message-Id: <199810090217.TAA25087@george.lbl.gov> To: DAAgarwal@lbl.gov, Jason_Sylvester@3com.com, Ksiple@home.com, MPerry@lbl.gov, M_Howard-Jeweler@lbl.gov, Rowe@BMRC.Berkeley.edu, bjorn@it.kth.se, cpmcparland@lbl.gov, ferenc@deepthought.EECS.Berkeley.EDU, ikeda@hike.te.chiba-u.ac.jp, itf@mcs.anl.gov, jam@mattheij.nl, jim.myers@pnl.gov, mbone@isi.edu, olson@mcs.anl.gov, philippe.galvez@cern.ch, rem-conf@es.net, roland@irdu.nus.edu.sg, toonen@mcs.anl.gov, van@ee.lbl.gov Subject: Devserv Update X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi All, We've updated devserv to version 0.4.2 and added new UNIX and Windows devserv src/bin packages to our web/ftp sites (http://www-itg.lbl.gov/mbone/devserv and ftp://george.lbl.gov/pub/mbone/devserv). UNIX versions include solaris and freeBSD (Irix to come within a day or so). The changes include: added command line option for the time-to-live (you can now use "-t " to override the default of 1), deleted home position values from devserv's description messages, and deleted numerous temporary objects. We expect to add security (e.g., checking device access) very soon so further updates will be available to you within the next few weeks. Since SuperComputing '98 is coming up, we wanted to get this out as soon as possible so those interested could beat on it before SC98. We tested with the Sony camera but no longer have the Canon VCC1/VCC3. So I hope the changes made things more efficient and didn't break existing functionality... If there are problems or questions, please let us know-- Marcia Perry & Deb Agarwal Imaging and Distributed Collaboratories Group Lawrence Berkeley National Lab From rem-conf Fri Oct 09 01:14:22 1998 From rem-conf-request@es.net Fri Oct 09 01:14:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zRXdl-0005Yu-00; Fri, 9 Oct 1998 01:11:09 -0700 Received: from elsa.irit.fr [141.115.64.162] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zRXdk-0005Yk-00; Fri, 9 Oct 1998 01:11:08 -0700 Received: from elsa (localhost [127.0.0.1]) by elsa.irit.fr (8.8.8/8.8.8) with SMTP id KAA01654 for ; Fri, 9 Oct 1998 10:11:00 +0200 (MET DST) Sender: sarafogl@irit.fr Message-ID: <361DC513.4057@irit.fr> Date: Fri, 09 Oct 1998 10:10:59 +0200 From: Philippe SARAFOGLOU X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5 sun4m) MIME-Version: 1.0 To: rem-conf@es.net Subject: RTP protocol : Mixer, translator Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I'm a student from Toulouse, France and currently work with a research project about multimedia on the internet. I'm looking for people who tried to use the mixer or translator defined in the RFC 1890 RTP protocol. Have there been daemons in the past which realised the functionality of mixer or translator. Thanks for help & hints, Philippe Sarafoglou, IRIT, Toulouse From rem-conf Fri Oct 09 02:54:56 1998 From rem-conf-request@es.net Fri Oct 09 02:54:55 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zRZDd-00072i-00; Fri, 9 Oct 1998 02:52:17 -0700 Received: from basil.cdt.luth.se [130.240.64.67] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zRZDb-00072S-00; Fri, 9 Oct 1998 02:52:16 -0700 Received: from salt (peppar@salt.cdt.luth.se [130.240.64.42]) by basil.cdt.luth.se (8.8.8/8.7.3) with ESMTP id LAA27288; Fri, 9 Oct 1998 11:51:47 +0200 (MET DST) Message-Id: <199810090951.LAA27288@basil.cdt.luth.se> X-Mailer: exmh version 2.0.2 2/24/98 To: Philippe SARAFOGLOU cc: rem-conf@es.net Subject: Re: RTP protocol : Mixer, translator In-reply-to: Your message of "Fri, 09 Oct 1998 10:10:59 +0200." <361DC513.4057@irit.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Fri, 09 Oct 1998 11:51:46 +0200 From: Peter Parnes X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list sarafogl@irit.fr said: > Have there been daemons in the past which realised the functionality > of mixer or translator. We at CDT have experimented with over the last years and have a prototype called mTunnel that acts as both a mixer and translater*. (An earlier version of this tool was called mTranslator that did only unicast/multicast translation and the end-point application had to be aware of the difference while mTunnel have removed this "need"). *Translator meaning that is does both unicast/multicast translation but also that is does media conversion. Something I don't think I have mentioned on this list before is the results on our experiments with compression of aggregated RTP streams (which is can be done when tunneling mcast traffic containing audio, video and other media being used on the MBone today). Anyhow, we did that earlier this year and found that up to 15% bandwidth gain for certain situations and typically around 8-10% gain for normal usage. An initial assumption is that the compression must be totally stateless so it can handle lost packets in the tunnel and of course much higher compression levels might be gained if that assumption is lost. More information can be found in my mTunnel paper that is currently being published in a Computer Communication coming out any day now. It can be found at . We have also made some experiments with media scaling of RTP transported video, meaning that instead of shaping traffic on packet level we do it on frame level. This produced a much better result than just throwing away packets at random. /P From rem-conf Fri Oct 09 05:51:59 1998 From rem-conf-request@es.net Fri Oct 09 05:51:58 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zRbye-00012J-00; Fri, 9 Oct 1998 05:49:00 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zRbyc-000129-00; Fri, 9 Oct 1998 05:48:59 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 9 Oct 1998 13:48:42 +0100 To: Philippe SARAFOGLOU cc: rem-conf@es.net Subject: Re: RTP protocol : Mixer, translator In-reply-to: Your message of "Fri, 09 Oct 1998 10:10:59 +0200." <361DC513.4057@irit.fr> Date: Fri, 09 Oct 1998 13:48:41 +0200 Message-ID: <1184.907937321@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Philippe SARAFOGLOU writes: >I'm looking for people who tried to use the mixer or translator defined >in the RFC 1890 RTP protocol. > >Have there been daemons in the past which realised the functionality of >mixer or translator. We've had an RTP translator and mixer built into the UCL audio tool, RAT, (http://www-mice.cs.ucl.ac.uk/multimedia/projects/rat/) for a while now. This does audio mixing, media conversion (transcoding between multiple audio compression formats) and translation between multiple sessions (multicast-unicast and multicast-multicast, plus we're working on IPv4-IPv6 translation...). Colin From rem-conf Fri Oct 09 09:14:26 1998 From rem-conf-request@es.net Fri Oct 09 09:14:25 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zRf1h-00035x-00; Fri, 9 Oct 1998 09:04:21 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zRf1g-00035n-00; Fri, 9 Oct 1998 09:04:20 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 9 Oct 1998 17:04:11 +0100 To: rem-conf@es.net cc: casner@cisco.com Subject: Revised AVT charter and draft-mckay-qcelp-01.txt Date: Fri, 09 Oct 1998 17:04:10 +0200 Message-ID: <2118.907949050@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list As has been discussed on this list previously, the current AVT charter is badly in need of revision. I enclose below a proposal for updating the charter which Steve and I have been discussing. Comments are most welcome. One question which arises from this is the status of the PureVoice payload format document, draft-mckay-qcelp-01.txt, which has been in working group last call for a couple of weeks now. The outstanding issue with this document is the presence of a payload format specific means of indicating encryption of the RTP payload (and not the header) when the RTP spec defines a payload format independent mechanism. We need to resolve this issue in order to progress this document, so I propose the following question to the group: should this document be progressed as is, or should the encryption feature be removed? Colin ------------------------------------------------------------------------------- Audio/Video Transport (avt) Chair(s): Stephen Casner Colin Perkins Transport Area Director(s): Scott Bradner Vern Paxson Transport Area Advisor: Vern Paxson Mailing Lists: General Discussion:rem-conf@es.net To Subscribe: rem-conf-request@es.net Archive: ftp://nic.es.net/pub/mailing-lists/mail-archive/rem-conf Description of Working Group: The Audio/Video Transport Working Group was formed to specify protocols for real-time transmission of audio and video over UDP and IP multicast. Although the original target was an experimental protocol, in the time since the group was originally chartered much research and develpment has been undertaken in this area, leading to the specification of the standards-track Real-time Transport Protocol (RTP). RTP provides the necessary end-to-end network transport functions for the delivery of real-time data, but does not address resource reservation, guaranteed quality-of-service or call-setup (other working groups are focusing on these problems). An integral part of RTP is the control protocol (RTCP) which augments the data transport to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. The base RTP specification was deliberately designed to be malleable, with profile documents specifying its use in particular scenarios and payload format documents defining the packetisation of particular media formats. The AVT group has developed a profile for audio/video conferencing applications with minimal control and a large range of payload format specifications. We have also developed a header compression mechanism for RTP streams and a document giving guidelines for the use of FEC as packet loss protection. We are in the process of developing a MIB for RTP systems. The future goals of the working group are to revise RTP and the A/V profile for advancement to draft standard stage, to complete the MIB, to produce a guidelines document for future developers of payload formats and to continue development of new payload format documents (including the possibility of producing a "generic" payload format). Goals and Milestones: - JPEG, BT656 and H.263+ payload formats are done - Compressed RTP is done but waiting on other documents Sep 98 - Working group last call on PureVoice (qcelp) payload format - Post "issues with multiplexing" draft (update to Rosenberg's draft from December 1996). Oct 98 - Submit revised payload for MPEG4 elementary streams - Decide how to proceed with multiplexing protocol: one generic payload format or a number of application specific formats Nov 98 - Split generic FEC draft into parity FEC and R-S drafts - Working group last call on parity FEC draft - Submit merged generic payload format draft - Submit revised Guidelines for Payload Format Authors draft - Submit revised RTP MIB - Submit revised RTP draft - Submit revised A/V profile draft - Split SSRC sampling section out of RTP and submit as a new draft - Submit multiplexing draft(s) Dec 98 - Working group last call on RTP, A/V profile, MIB and Guidelines documents after the December IETF Jan 99 - Submit revised RTP and A/V profile documents to IESG for publication as draft standards. - Submit RTP MIB to IESG for publication as an RFC - Revise MPEG4 payload format document and prepare implementation results ready for working group last call - Begin work on transport of multiplexed MPEG4 streams Feb 99 - Submit revised generic payload format draft - Submit revised multiplexing draft(s) Apr 99 - Working group last call on generic payload format document ------------------------------------------------------------------------------- From rem-conf Fri Oct 09 14:29:59 1998 From rem-conf-request@es.net Fri Oct 09 14:29:59 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zRk0A-0006F6-00; Fri, 9 Oct 1998 14:23:06 -0700 Received: from mage.qualcomm.com [129.46.174.16] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zRk09-0006Eu-00; Fri, 9 Oct 1998 14:23:05 -0700 Received: from [129.46.172.254] (jnoerenberg-mac.qualcomm.com [129.46.172.254]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id OAA07213; Fri, 9 Oct 1998 14:21:59 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <2118.907949050@cs.ucl.ac.uk> X-Mailer: Eudora [Macintosh version 4.1b32-11.98] X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Fri, 9 Oct 1998 14:21:38 -0700 To: Colin Perkins From: "John W. Noerenberg" Subject: Re: Revised AVT charter and draft-mckay-qcelp-01.txt Cc: rem-conf@es.net, casner@cisco.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 5:04 PM +0200 10/9/98, Colin Perkins wrote: > >We need to resolve this issue in order to progress this document, so I >propose the following question to the group: should this document be >progressed as is, or should the encryption feature be removed? I'd recommend preserving the ability to encrypt the payload as described in draft-mckay. As noted section 9.1 in the current RTP draft, applications exist where payload encryption that is distinct from the encryption provided by lower layer is desirable. Furthermore, in consideration of RTP mux'ing schemes, if multiple payloads are catenated into a single RTP packet, as has been proposed, then the only way to insure that a particular stream is encrypted from end to end is to allow individual payloads to be encrypted even though its neighbors may not be encrypted. The alternative would be to require the multiplexing gateways at the endpoints to sort the individual streams into encrypted and unencrypted streams before building the packets to be communicated between the gateways. This seems like an unreasonable complication for the gateways, in addition to reducing the overall benefit of multiplexing the streams. This approach would also prevent end-to-end encryption of particular streams when multiplexing is employed, if individual payloads are not allowed to be encrypted. best, john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- no matter what a waste one has made of one's life, it is ever possible to find some path to redemption -- Charles Frazier, "Cold Mountain", Vintage Books, 1997 ---------------------------------------------------------------------- From rem-conf Fri Oct 09 14:56:53 1998 From rem-conf-request@es.net Fri Oct 09 14:56:53 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zRkU7-00075M-00; Fri, 9 Oct 1998 14:54:03 -0700 Received: from george.lbl.gov [131.243.2.12] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zRkU6-00075C-00; Fri, 9 Oct 1998 14:54:02 -0700 Received: (from mperry@localhost) by george.lbl.gov (8.8.8/8.8.8) id OAA26785; Fri, 9 Oct 1998 14:53:36 -0700 (PDT) Date: Fri, 9 Oct 1998 14:53:36 -0700 (PDT) From: Marcia Perry (ITG staff) Message-Id: <199810092153.OAA26785@george.lbl.gov> To: DAAgarwal@lbl.gov, Jason_Sylvester@3com.com, Ksiple@home.com, MPerry@lbl.gov, M_Howard-Jeweler@lbl.gov, Rowe@BMRC.Berkeley.edu, bjorn@it.kth.se, cpmcparland@lbl.gov, ferenc@deepthought.EECS.Berkeley.EDU, ikeda@hike.te.chiba-u.ac.jp, itf@mcs.anl.gov, jam@mattheij.nl, jim.myers@pnl.gov, mbone@isi.edu, olson@mcs.anl.gov, philippe.galvez@cern.ch, rem-conf@es.net, roland@irdu.nus.edu.sg, toonen@mcs.anl.gov, van@ee.lbl.gov Subject: Devserv under Windows X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi All, Please note that for Windows 95/NT, the HOME variable must be set. Either in autoexec.bat or on the DOS shell command line, make an entry such as: set HOME=C:\ I'm sorry to have omitted this from the documentation. Marcia Perry Imaging and Distributed Collaboratories Group Lawrence Berkeley National Lab From rem-conf Fri Oct 09 16:28:54 1998 From rem-conf-request@es.net Fri Oct 09 16:28:53 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zRlrZ-0000h3-00; Fri, 9 Oct 1998 16:22:21 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zRlrY-0000gt-00; Fri, 9 Oct 1998 16:22:20 -0700 Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id QAA09996 for ; Fri, 9 Oct 1998 16:15:20 -0700 Received: from scv3.apple.com (scv3.apple.com) by mailgate.apple.com (mailgate.apple.com - SMTPRS 2.0.15) with ESMTP id ; Fri, 09 Oct 1998 16:15:10 -0700 Received: from [17.255.20.102] (dsinger2.apple.com [17.255.20.102]) by scv3.apple.com (8.8.5/8.8.5) with ESMTP id QAA14446; Fri, 9 Oct 1998 16:14:58 -0700 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: References: <2118.907949050@cs.ucl.ac.uk> MIME-Version: 1.0 Date: Fri, 9 Oct 1998 16:09:55 -0700 To: rem-conf@es.net From: Dave Singer Subject: Re: Revised AVT charter and draft-mckay-qcelp-01.txt Cc: Colin Perkins , casner@cisco.com Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I'm happy to see the encryption left in, if only because I want it clear that if you son't support encryption and that bit is set, then you don't interoperate. David Singer Apple Computer/QuickTime 408-974-3162 From rem-conf Sat Oct 10 12:52:08 1998 From rem-conf-request@es.net Sat Oct 10 12:52:06 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zS4rs-0007aj-00; Sat, 10 Oct 1998 12:39:56 -0700 Received: from rolex.csc.ncsu.edu [152.1.213.197] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zS4rq-0007aZ-00; Sat, 10 Oct 1998 12:39:54 -0700 Received: (from rhee@localhost) by rolex.csc.ncsu.edu (8.8.4/UC02Jan97) id PAA16648 for rem-conf@es.net; Sat, 10 Oct 1998 15:39:53 -0400 (EDT) Date: Sat, 10 Oct 1998 15:39:53 -0400 (EDT) From: rhee@eos.ncsu.edu Message-Id: <199810101939.PAA16648@rolex.csc.ncsu.edu> To: rem-conf@es.net Subject: CFP for Collaborative Computing X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Call for Papers IEEE Internet Computing (http://www.computer.org/internet) ----------------------------------------------------------- Special Issue on Multimedia and Collaborative Computing over the Internet (March/April 1999). ------------------------------------------------------------ Submission deadline: 31 October 1998 Guest Editor: Injong Rhee Department of Computer Science North Carolina State University Raleigh, NC 27695-7534 Phone: 919-515-3305 Fax: 919-515-7925 WWW: www.csc.ncsu.edu/faculty/rhee email: rhee@csc.ncsu.edu The Internet is evolving to bring an integrated communication service supporting data, voice, and video to classrooms, workplaces, and homes. Using this enabling network infrastructure, novel computer-supported collaboration technologies are emerging to allow geographically dispersed groups of co-workers to conduct a range of work-related activities. This special issue covers these emerging technologies for Internet-based multimedia collaboration. Topics of interest for technical papers include: * long-distance collaboration tools, application-sharing tools, * user interface design for CSCW applications * synchronous and asynchronous collaboration techniques, * real-time multimedia delivery, * operating systems and network support for real-time collaboration, * techniques for handling user migration, * comparative studies of existing collaboration tools and technologies, * security and authentication methods for distributed collaboration, * algorithms for synchronization among multiple users in collaboration sessions, * multicast techniques for collaboration involving many participants, * techniques for handling heterogeneous user environments. We are especially interested in research papers that describe real Internet experiments using developed collaboration technologies. Work-in-progress papers describing the state of on-going research projects in multimedia collaboration are also encouraged. Papers should explicate the technical issues related to the Internet. Research papers should demonstrate the feasibility of the approach and describe the state of realization. Case studies and applied papers should discuss the key factors that made the system work and should also mention the pitfalls and problems encountered and how they may be overcome. Paper should explicate the technical issues related to the Internet. Research papers should demonstrate the feasibility of the approach and describe the state of realization. Case studies and applied papers should discuss the key factors that made the system work and should also mention the pitfalls and problems encountered and how they may be overcome. Submission, Approval, Review, and Acceptance. --------------------------------------------- The submission process for IC differs from other IEEE Computer Society publications. Authors should send e-mail to a member of the IC Editorial Board (rhee@csc.ncsu.edu), giving a URL where the editor can review the article, preferably in HTML format with GIF artwork (postscript or pdf format is also accepted). Upon approval by a member of the Editorial Board, all feature articles will then undergo a technical peer review consistent with other archival publications. Articles for review should be in HTML or a common format easily read by reviewers. Authors will send all files to an anonymous ftp site provided by the IC managing editor in the Computer Society's publications office. When an article consists of a collection of HTML and GIF files, all internal links pointing to this file should be relative. More information about submission guideline can be found in http://www.computer.org/internet/edguide.htm  From rem-conf Sun Oct 11 22:52:39 1998 From rem-conf-request@es.net Sun Oct 11 22:52:37 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zSajV-0002Yl-00; Sun, 11 Oct 1998 22:41:25 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zSajU-0002YN-00; Sun, 11 Oct 1998 22:41:24 -0700 Received: from rtp-dial-1-41.cisco.com (rtp-dial-1-41.cisco.com [171.70.158.41]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id WAA05269; Sun, 11 Oct 1998 22:40:16 -0700 (PDT) Date: Sun, 11 Oct 1998 22:39:28 -0700 (Pacific Daylight Time) From: Stephen Casner To: "John W. Noerenberg" cc: Colin Perkins , rem-conf@es.net Subject: Re: Revised AVT charter and draft-mckay-qcelp-01.txt In-Reply-To: Message-ID: X-X-Sender: casner@ursamajor.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > I'd recommend preserving the ability to encrypt the payload as described in > draft-mckay. As noted section 9.1 in the current RTP draft, applications > exist where payload encryption that is distinct from the encryption > provided by lower layer is desirable. The question is not whether to allow encryption of the payload by itself. As you note, section 9.1 already mentions that. The question is instead whether this particular encoding should have its own method for indicating that the payload is encrypted which is different from the method in section 9.1. The latter method is to use the payload type to indicate an encrypted payload. This method can be used with any payload format and allows the application to perform the decryption in a payload-independent manner. The method proposed in draft-mckay uses a bit in the payload header, which is specific to this payload format, and which also means that not all of the payload is encrypted (since that bit must be in the clear). > Furthermore, in consideration of RTP mux'ing schemes, if multiple payloads > are catenated into a single RTP packet, as has been proposed, then the only > way to insure that a particular stream is encrypted from end to end is to > allow individual payloads to be encrypted even though its neighbors may not > be encrypted. Using the payload type as the indicator of encryption does not preclude encrypting some of the payloads in a multiplexing scheme except for the one proposal that assumed the payload type was the same for all streams. (I would prefer not to make this assumption for other reasons in addition to this encryption question.) If the ability to encrypt some of the streams is valuable (it probably is), then should we require all encodings that might be used to set aside a payload header bit to indicate encryption? Or do you assume that QCELP is the only encoding worth consideration? :-) -- Steve From rem-conf Mon Oct 12 10:00:51 1998 From rem-conf-request@es.net Mon Oct 12 10:00:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zSlEP-0007kV-00; Mon, 12 Oct 1998 09:54:01 -0700 Received: from mage.qualcomm.com [129.46.174.16] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zSlEN-0007kF-00; Mon, 12 Oct 1998 09:53:59 -0700 Received: from ecr-nt (ecr-nt.qualcomm.com [129.46.171.181]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with SMTP id JAA01679; Mon, 12 Oct 1998 09:52:50 -0700 (PDT) Message-Id: <199810121652.JAA01679@mage.qualcomm.com> X-Sender: ecr@nala.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 12 Oct 1998 09:52:44 -0700 To: Stephen Casner , "John W. Noerenberg" From: "Eric C. Rosen" Subject: Re: Revised AVT charter and draft-mckay-qcelp-01.txt Cc: Colin Perkins , rem-conf@es.net In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 10:39 PM 10/11/98 -0700, Stephen Casner wrote: >> I'd recommend preserving the ability to encrypt the payload as described in >> draft-mckay. As noted section 9.1 in the current RTP draft, applications >> exist where payload encryption that is distinct from the encryption >> provided by lower layer is desirable. > >The question is not whether to allow encryption of the payload by >itself. As you note, section 9.1 already mentions that. The question >is instead whether this particular encoding should have its own method >for indicating that the payload is encrypted which is different from >the method in section 9.1. The latter method is to use the payload >type to indicate an encrypted payload. This method can be used with >any payload format and allows the application to perform the >decryption in a payload-independent manner. The method proposed in >draft-mckay uses a bit in the payload header, which is specific to >this payload format, and which also means that not all of the payload >is encrypted (since that bit must be in the clear). The problem with Section 9.1, as I interpret it, is that it appears to require some a priori information to be sent, such as a session description or something to the same effect, which indicates (1) the source will be encrypted and (2) the payload type for the encrypted source. There are applications where this additional information may not be available and hence it is useful to reserve a bit in the payload itself to indicate that the vocoder frames in the payload are encrypted. > If the >ability to encrypt some of the streams is valuable (it probably is), >then should we require all encodings that might be used to set aside a >payload header bit to indicate encryption? Or do you assume that >QCELP is the only encoding worth consideration? :-) > -- Steve Steve was making this comment with respect to the multiplexing argument, but I would argue that an explicit encrypted bit makes sense for most (if not all) payloads in general. Ideally the bit should probably be in the RTP header itself. --Eric From rem-conf Mon Oct 12 10:46:53 1998 From rem-conf-request@es.net Mon Oct 12 10:46:52 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zSm0t-0000si-00; Mon, 12 Oct 1998 10:44:07 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zSm0s-0000sY-00; Mon, 12 Oct 1998 10:44:06 -0700 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA17675; Mon, 12 Oct 1998 13:44:04 -0400 (EDT) Received: from cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by opus.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA27459; Mon, 12 Oct 1998 13:44:01 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <36223FE0.76E87145@cs.columbia.edu> Date: Mon, 12 Oct 1998 13:44:00 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5b1 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Eric C. Rosen" CC: Stephen Casner , "John W. Noerenberg" , Colin Perkins , rem-conf@es.net Subject: Re: Revised AVT charter and draft-mckay-qcelp-01.txt References: <199810121652.JAA01679@mage.qualcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Eric C. Rosen wrote: > > The problem with Section 9.1, as I interpret it, is that it appears to > require some a priori information to be sent, such as a session description > or something to the same effect, which indicates (1) the source will be > encrypted and (2) the payload type for the encrypted source. There are > applications where this additional information may not be available and > hence it is useful to reserve a bit in the payload itself to indicate > that the vocoder frames in the payload are encrypted. However, some form of out-of-band information is required for dynamic PT mapping in any event. Whether you assign one or two dynamic payload types for an encoding does not seem to make much difference. Putting a bit in the payload makes encryption a pain since you either have to waste a whole byte for this or the first byte can't be encrypted. Even in that case, if your encryption algorithm prefers word-aligned data, you loose. > > Steve was making this comment with respect to the multiplexing argument, > but I would argue that an explicit encrypted bit makes sense for most > (if not all) payloads in general. Ideally the bit should probably be in > the RTP header itself. Unfortunately, there are no spare header bits. > > --Eric -- Henning Schulzrinne schulzrinne@cs.columbia.edu Dept. of Comp. Sci. ph +1 212 939-7042 Columbia University fax +1 212 666-0140 New York, NY 10027 http://www.cs.columbia.edu/~hgs From rem-conf Mon Oct 12 12:38:42 1998 From rem-conf-request@es.net Mon Oct 12 12:38:41 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zSnim-0002UG-00; Mon, 12 Oct 1998 12:33:32 -0700 Received: from mysa.qualcomm.com [129.46.52.23] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zSnil-0002Tx-00; Mon, 12 Oct 1998 12:33:31 -0700 Received: from [129.46.219.172] (kjmckay.qualcomm.com [129.46.219.172]) by mysa.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id MAA07487; Mon, 12 Oct 1998 12:31:36 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <36223FE0.76E87145@cs.columbia.edu> References: <199810121652.JAA01679@mage.qualcomm.com> Date: Mon, 12 Oct 1998 12:33:36 -0700 To: Henning Schulzrinne , "Eric C. Rosen" From: "Kyle J. McKay" Subject: Re: Revised AVT charter and draft-mckay-qcelp-01.txt Cc: Stephen Casner , "John W. Noerenberg" , Colin Perkins , rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 10:44 -0700 10/12/1998, Henning Schulzrinne wrote: >Eric C. Rosen wrote: >> Steve was making this comment with respect to the multiplexing argument, >> but I would argue that an explicit encrypted bit makes sense for most >> (if not all) payloads in general. Ideally the bit should probably be in >> the RTP header itself. > >Unfortunately, there are no spare header bits. The SSRC identifier space could be divided into two spaces. One for encrypted sources and one for non-encrypted sources. Although this would slightly increase the likelihood of a SSRC collision, the RTP draft already specifies a mechanism to resolve this. This has the advantage of not requiring another header bit, being payload independent, and providing additional information when receiving packets from a mixer. When secure transmissions are important, encrypted output from a mixer can be examined to make sure all CSRCs were also encrypted. Kyle From rem-conf Tue Oct 13 09:03:54 1998 From rem-conf-request@es.net Tue Oct 13 09:03:54 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zSxs9-0004aY-00; Mon, 12 Oct 1998 23:23:53 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zSxs8-0004Z4-00; Mon, 12 Oct 1998 23:23:52 -0700 Received: from rtp-dial-1-57.cisco.com (rtp-dial-1-57.cisco.com [171.70.158.57]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id XAA10613; Mon, 12 Oct 1998 23:22:03 -0700 (PDT) Date: Mon, 12 Oct 1998 23:21:14 -0700 (Pacific Daylight Time) From: Stephen Casner To: "Eric C. Rosen" , Henning Schulzrinne , "Kyle J. McKay" cc: "John W. Noerenberg" , Colin Perkins , rem-conf@es.net Subject: Re: Revised AVT charter and draft-mckay-qcelp-01.txt In-Reply-To: Message-ID: X-X-Sender: casner@ursamajor.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Eric C. Rosen wrote: > The problem with Section 9.1, as I interpret it, is that it appears to > require some a priori information to be sent, such as a session description > or something to the same effect, which indicates (1) the source will be > encrypted and (2) the payload type for the encrypted source. There are > applications where this additional information may not be available and > hence it is useful to reserve a bit in the payload itself to indicate > that the vocoder frames in the payload are encrypted. Henning Schulzrinne replied: > However, some form of out-of-band information is required for dynamic PT > mapping in any event. Whether you assign one or two dynamic payload > types for an encoding does not seem to make much difference. And even if you would not otherwise be using a dynamic payload type, you still need to communicate the port numbers to be used. There must be some control communication that occurs between the participants before the RTP packets start flowing. Maybe a key exchange for the encryption. Put the mapping for the payload type indicating encryption with that other control information. I've made this comment many times in explaining dynamic payload types. Eric also said: > Steve was making this comment with respect to the multiplexing argument, > but I would argue that an explicit encrypted bit makes sense for most > (if not all) payloads in general. Ideally the bit should probably be in > the RTP header itself. There may well be a number of other bits that one could try to put into the RTP header. I'm not sure an encryption indication is the most important. Kyle J. McKay wrote: > The SSRC identifier space could be divided into two spaces. One for > encrypted sources and one for non-encrypted sources. Although this would > slightly increase the likelihood of a SSRC collision, the RTP draft already > specifies a mechanism to resolve this. This has the advantage of not > requiring another header bit, being payload independent, and providing > additional information when receiving packets from a mixer. When secure > transmissions are important, encrypted output from a mixer can be examined > to make sure all CSRCs were also encrypted. This would establish a bad precedent and would create incompatibilities with existing implementations. Instead, we take the bit from the payload type field (by using two payload types) which is exactly what the payload type field is for (to be filled with types allocated by the application to indicate the kinds of data it needs to carry). In fact, I can imagine that there might be more than one bit of information you would want to say about encryption, which could be accommodated by allocating more than two payload type values: perhaps multiple keys, or multiple algorithms. -- Steve From rem-conf Tue Oct 13 09:04:14 1998 From rem-conf-request@es.net Tue Oct 13 09:04:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zSszh-0000nv-00; Mon, 12 Oct 1998 18:11:21 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zSszf-0000nc-00; Mon, 12 Oct 1998 18:11:19 -0700 Received: from quimby.cs.berkeley.edu (quimby.CS.Berkeley.EDU [128.32.131.169]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with ESMTP id SAA04778 for ; Mon, 12 Oct 1998 18:11:18 -0700 (PDT) Message-Id: <199810130111.SAA04778@gumby.CS.Berkeley.EDU> X-Mailer: exmh version 1.6.9 8/22/96 From: "Larry Rowe" To: rem-conf@es.net Subject: [UCB MIG Seminar] "PRoPs: Towards Transparent Interfaces to the Real World," E. Paulos (UCB) Reply-To: Rowe@bmrc.berkeley.edu Mime-Version: 1.0 Content-Type: text/enriched; charset=us-ascii Date: Mon, 12 Oct 1998 18:11:18 -0700 Sender: larry@bmrc.berkeley.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list PRoPs: Towards Transparent Interfaces to the Real World Eric Paulos (U.C. Berkeley) Wednesday October 14, 1998 12:30-2:00 PDT 405 Soda Hall The internet has increased our tele-connectivity by allowing us to exchange text, images, sound, and video with anyone whose interests we share, professionally or socially, regardless of geographic location. But even with the rapid adoption of these new tools for human communication and interaction it is obvious that something is missing. Current internet applications fail to provide us with an adequate interface into the real world in which we live, work, and play. This talk will describe one such approach to solving this problem with simple, inexpensive, internet-controlled, untethered tele-robots or PRoPs (Personal Roving Presences) to provide the sensation of tele-embodiment in a remote real space. The physical tele-robot provides video and audio links to the remote space as well as providing a visible, mobile entity with which other people can interact. PRoPs also enable their users to perform a wide gamut of human activities in the remote space, such as wandering around, conversing with people, hanging out, pointing, examining objects, reading, and making simple gestures. The focus of this work is to identify and distill a small yet sufficient number of traits that are vital to human communication and interaction and to physically implement them on PRoPs. For more information please visit www.prop.org. This work is in collaborationewith John Canny. -- The MBONE addresses for the seminar are: video 224.2.163.7/57076 audio 224.2.147.61/27202 From rem-conf Tue Oct 13 09:04:33 1998 From rem-conf-request@es.net Tue Oct 13 09:04:33 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zT2Rj-0000Qn-00; Tue, 13 Oct 1998 04:16:55 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zT2Ri-0000Qc-00; Tue, 13 Oct 1998 04:16:54 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA19822; Tue, 13 Oct 1998 07:15:20 -0400 (EDT) Message-Id: <199810131115.HAA19822@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: rem-conf@es.net From: The IESG Subject: Protocol Action: RTP Payload Format for JPEG-compressed Video to Proposed Standard Date: Tue, 13 Oct 1998 07:15:20 -0400 Sender: scoya@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has approved the Internet-Draft 'RTP Payload Format for JPEG-compressed Video' as a Proposed Standard. This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Scott Bradner and Vern Paxson. Technical Summary This document defines a format for transmitting JPEG-compressed video streams over RTP. It includes mechanisms for fragmenting frames across multiple packets, inserting restart markers into the stream, and specifying quantization tables, along with sample source code for implementing these mechanisms. It is a revision of RFC 2035, and replaces it on the standards track. Working Group Summary These revisions were presented to the AVT working group without controversy, and completed the working group last call without negative comments. The document includes a summary of changes with respect to RFC 2035. Protocol Quality Vern Paxson reviewed the specification for the IESG. From rem-conf Tue Oct 13 09:05:07 1998 From rem-conf-request@es.net Tue Oct 13 09:05:06 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zT0DH-0006Rn-00; Tue, 13 Oct 1998 01:53:51 -0700 Received: from (fsnt.future.futsoft.com) [38.242.192.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zT0DC-0006Pc-00; Tue, 13 Oct 1998 01:53:50 -0700 Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Tue, 13 Oct 1998 14:20:28 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id OAA32369; Tue, 13 Oct 1998 14:19:21 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <3623C47B@msgate.future.futsoft.com>; Tue, 13 Oct 98 14:22:03 PDT From: vishwas To: rem-conf Cc: mbone , "'IDMR'" , "'IPMULTICAST@STARDUST.COM'" Subject: Solaris Serial interfaces Date: Tue, 13 Oct 98 14:20:00 PDT Message-Id: <3623C47B@msgate.future.futsoft.com> X-Mailer: Microsoft Mail V3.0 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Everybody, I am installing mrouted 3.8 on solaris, AS I did not find any for LINUX.!!!! :-( , BUT now my problem is I have just one ethernet interface in solaris. So I have to use serial interfaces. I dont know wether or not SLIP or PPP can be configured on solaris. I AM ONLY INTERESTED IN CONFIGURING SLIP THOUGH, IF THERE IS NO OTHER WAY I HAVE TO GO FOR PPP. Have anybody configured SLIP in SOLARIS.? or atleast PPP...? Let me know if atleast I could find some pointers regarding this. Thanks for ur time. Regards vishwa From rem-conf Tue Oct 13 10:43:43 1998 From rem-conf-request@es.net Tue Oct 13 10:43:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zT8Nx-00063v-00; Tue, 13 Oct 1998 10:37:25 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zT8Nw-00063l-00; Tue, 13 Oct 1998 10:37:24 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id KAA16975 for ; Tue, 13 Oct 1998 10:37:23 -0700 (PDT) Message-Id: <3.0.3.32.19981013103723.00c08db0@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 13 Oct 1998 10:37:23 -0700 To: rem-conf@es.net From: Florissa Colina Subject: 10/14 Seminar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia Research Center Berkeley Multimedia, Interfaces, and Graphics Seminar PRoPs: Towards Transparent Interfaces to the Real World Eric Paulos Computer Science Division - EECS University of California, Berkeley Wednesday October 14, 1998 12:30-2:00 PDT 405 Soda Hall Abstract: The internet has increased our tele-connectivity by allowing us to exchange text, images, sound, and video with anyone whose interests we share, professionally or socially, regardless of geographic location. But even with the rapid adoption of these new tools for human communication and interaction it is obvious that something is missing. Current internet applications fail to provide us with an adequate interface into the real world in which we live, work, and play. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Tue Oct 13 12:22:43 1998 From rem-conf-request@es.net Tue Oct 13 12:22:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zT9wH-0007kt-00; Tue, 13 Oct 1998 12:16:57 -0700 Received: from axl01it.ntc.nokia.com [131.228.118.232] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zT9wF-0007kj-00; Tue, 13 Oct 1998 12:16:56 -0700 Received: from miller.americas.nokia.com (miller.americas.nokia.com [172.18.180.20]) by axl01it.ntc.nokia.com (8.8.5/8.6.9) with ESMTP id WAA22788; Tue, 13 Oct 1998 22:15:38 +0300 (EET DST) Received: from rhino.ntc.nokia.com (rhino.americas.nokia.com) by miller.americas.nokia.com with ESMTP (1.39.111.2/16.2) id AA019875977; Tue, 13 Oct 1998 15:12:57 -0400 Received: from Microsoft Mail (PU Serial #1991) by rhino.ntc.nokia.com (PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm)) id AA-1998Oct13.152100.1991.353853; Tue, 13 Oct 1998 15:13:15 -0400 From: sengodan@NASBPD01BS.ntc.nokia.com (Sengodan Senthil NRC/Boston) To: casner@cisco.com (Stephen Casner), ecr@qualcomm.com (Eric C. Rosen), hgs@cs.columbia.edu (Henning Schulzrinne), kylem@qualcomm.com (Kyle J. McKay) Cc: C.Perkins@cs.ucl.ac.uk (Colin Perkins), jwn2@qualcomm.com (John W. Noerenberg), rem-conf@es.net (rem-conf) Message-Id: <1998Oct13.152100.1991.353853@rhino.ntc.nokia.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: Nokia Telecommunications Date: Tue, 13 Oct 1998 15:13:15 -0400 Subject: Re: Revised AVT charter and draft-mckay- X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Eric Rosen said: > Steve was making this comment with respect to the multiplexing argument, > but I would argue that an explicit encrypted bit makes sense for most > (if not all) payloads in general. Ideally the bit should probably be in > the RTP header itself. I'd argue that encryption for the non-multiplexed case can merely be indicated by the choice of the dynamic payload type. While an E bit indicates that the payload is encrypted, the choice of a certain = encryption mechanism may still have to be determined from the dynamic payload type. This would be the case when more than one security mechanism may be applied. In such a case, the E bit seems redundant. Steve Casner said: > Using the payload type as the indicator of encryption does not > preclude encrypting some of the payloads in a multiplexing scheme > except for the one proposal that assumed the payload type was the same > for all streams. (I would prefer not to make this assumption for > other reasons in addition to this encryption question.) If the > ability to encrypt some of the streams is valuable (it probably is), > then should we require all encodings that might be used to set aside a > payload header bit to indicate encryption? For the multiplexed case, including the payload type in the header of each of the individual streams facilitates dynamic switching of encoding (codecs or security mechanisms) after having established which payload type corresponds to which encoding. The mux proposal that does not use payload types in the mini-headers achieves similar functionality by other means that is more bandwidth efficient. It defines a bit called the transition bit (T) within the mini-header whose purpose is= to indicate to the receiver that a new encoding (codec/security mechanism) is currently in effect. This is done by toggling the bit. Prior to a change in encoding, the transmitter needs to convey to the receiver what the new encoding is going to be for a particular stream. The receiver then knows that the new encoding has been applied to the stream when it notices that the T bit is toggled. The advantage is that a change in encoding is identified by the use of a = single bit, as against an entire byte (for payload type). The disadvantage is that= prior to each change, you have to signal to the receiver of the change to a= = certain encoding. Assuming that a little bit of latency can be tolerated when a = change in encoding is desired, I'd argue that the bandwidth savings are more significant. Steve Casner said: > The method proposed in > draft-mckay uses a bit in the payload header, which is specific to > this payload format, and which also means that not all of the payload > is encrypted (since that bit must be in the clear). The E bit having to go in the clear seems equivalent to the payload type having to go in the clear. If the dynamic payload type did not go in the clear, the receiver will not know which security mechanism to apply for decryption. This is because a stream could potentially define several security mechanisms and assign dynamic payload types to each of them. - Senthil Senthil Sengodan Nokia Research Center, Boston From rem-conf Tue Oct 13 14:49:44 1998 From rem-conf-request@es.net Tue Oct 13 14:49:43 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zTCF8-0001q5-00; Tue, 13 Oct 1998 14:44:34 -0700 Received: from mage.qualcomm.com [129.46.174.16] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zTCF7-0001ou-00; Tue, 13 Oct 1998 14:44:33 -0700 Received: from ecr-nt (ecr-nt.qualcomm.com [129.46.171.181]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with SMTP id OAA26335; Tue, 13 Oct 1998 14:42:47 -0700 (PDT) Message-Id: <199810132142.OAA26335@mage.qualcomm.com> X-Sender: ecr@nala.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 13 Oct 1998 14:42:39 -0700 To: Stephen Casner , "Eric C. Rosen" , Henning Schulzrinne , "Kyle J. McKay" From: "Eric C. Rosen" Subject: Re: Revised AVT charter and draft-mckay-qcelp-01.txt Cc: "John W. Noerenberg" , Colin Perkins , rem-conf@es.net In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In the QCELP payload specification, the Encrypted (E) bit signals the presence of an additional byte's worth of crypto header fields, which in turn may signal the presence or length of cryptosync and cryptocheck data. In this sense, the E bit has the same meaning as the Cryptocheck Presence (K) bit or the Cryptosync Length (CSL) field. It signals the inclusion of additional fields later in the payload. [ Aside: No objections to the K or CSL fields have been noted. ] It seems unwise to me to rely on out-of-band control information, such as the payload type, to determine whether this extra byte is present in the payload. In fact, it seems reasonable not to view the E bit as an encryption flag. It's utility is limited to indicating the inclusion of additional fields. Nothing prevents applications from using RTP's Section 9.1 encryption scheme with the QCELP specification. An application which did would not need to include the additional crypto fields defined in the QCELP draft and hence not set the E bit. I understand and agree with the arguments to keep signaling information out of the RTP payload. But although the E bit can obviously be interpreted as an encryption signal, it's intent is to keep the interpretation of the payload self-contained. I wonder if perhaps the E bit had been originally defined as: CryptoByte (C): 1 bit Indicates the presence or absence of an additional octet of payload fields, whose format and meaning are described in Section 6. there would not be any objection to setting the first bit of the payload when this additional information is present in the payload. --Eric From rem-conf Tue Oct 13 22:36:42 1998 From rem-conf-request@es.net Tue Oct 13 22:36:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zTJXc-0005y2-00; Tue, 13 Oct 1998 22:32:08 -0700 Received: from hyalos.is.ocha.ac.jp [133.65.66.10] (root) by mail1.es.net with smtp (Exim 1.81 #2) id 0zTJXY-0005xO-00; Tue, 13 Oct 1998 22:32:04 -0700 Received: from 133.65.66.10 by hyalos.is.ocha.ac.jp (SMI-8.6/SMI-SVR4/97-06-21-domain) id OAA22889; Wed, 14 Oct 1998 14:30:42 +0900 From: bord556@usa.net Message-Id: <199810140530.OAA22889@hyalos.is.ocha.ac.jp> Date: Tue, 13 Oct 98 22:42:52 EST To: friend@255l.com Subject: Warning this Joke is intended for Adults only! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |---------------http://www.eroticboxoffice.com/gmh ---------| |This filthy joke was brought to you by the wonderful folks| |at http://www.eroticboxoffice.com/gmh. Feel free to send this | |joke to anyone you think might get a kick out if it ... | |and for more great jokes visit WWW.THEDIRTYJOKE.COM ... | |--------PRETTIER THAN PLAYBOY, HOTTER THAN HUSTLER--------| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| Girlfriend 1.0 I'm currently running the latest version of GirlFriend and I've been having some problems lately. I've been running the same version of DrinkingBuddies 1.0 forever as my primary application, and all the GirlFriend releases I've tried have always conflicted with it. I hear that DrinkingBuddies won't crash if GirlFriend is run in background mode and the sound is turned off. But I'm embarrassed to say I can't find the switch to turn the sound off. I just run them separately, and it works okay. GirlFriend also seems to have a problem coexisting with my Golf program, often trying to abort Golf with some sort of timing incompatibility. I probably should have stayed with GirlFriend 1.0, but I thought I might see better performance from GirlFriend 2.0. After months of conflicts and other problems, I consulted a friend who has had experience with GirlFriend 2.0. He said I probably didn't have enough cache to run GirlFriend 2.0, and eventually it would require a Token Ring to run properly. He was right - as soon as I purged my cache, it uninstalled itself. Shortly after that, I installed GirlFriend 3.0 beta. All the bugs were supposed to be gone, but the first time I used it, it gave me a virus anyway. I had to clean out my whole system and shut down for a while.=20 I very cautiously upgraded to GirlFriend 4.0. This time I used a SCSI probe first and also installed a virus protection program. It worked okay for a while until I discovered that GirlFriend 1.0 was still in my system. I tried running GirlFriend 1.0 again with GirlFriend 4.0 still installed, but GirlFriend 4.0 has a feature I didn't know about that automatically senses the presence of any other version of GirlFriend and communicates with it in some way, which results in the immediate removal of both versions. The version I have now works pretty well, but there are still some problems. Like all versions of GirlFriend, it is written in some obscure language I can't understand, much less reprogram. Frankly I think there is too much attention paid to the look and feel rather than the desired functionality. Also, to get the best connections with your hardware, you usually have to use gold-plated contacts. And I've never liked how GirlFriend is totally "object-oriented." A year ago, a friend of mine upgraded his version of GirlFriend to GirlFriendPlus 1.0, which is a Terminate and Stay Resident version of GirlFriend. He discovered that GirlFriendPlus 1.0 expires within a year if you don't upgrade to Fianc=E9e 1.0. So he did, but soon after that, he had to upgrade to Wife 1.0, which he describes as a huge resource hog. It has taken up all his space, so he can't load anything else. One of the primary reasons he decided to go with Wife 1.0 was because it came bundled with FreeSexPlus. Well, it turns out the resource allocation module of Wife 1.0 sometimes prohibits access to FreeSexPlus, particularly the new Plug-Ins he wanted to try. On top of that, Wife 1.0 must be running on a well warmed-up system before he can do anything. Although he did not ask for it, Wife 1.0 came with MotherInLaw which has an automatic pop-up feature he can't turn off. I told him to try installing Mistress 1.0, but he said he heard if you try to run it without first uninstalling Wife 1.0, Wife 1.0 will delete MSMoney files before doing the uninstall itself. Then Mistress 1.0 won't install anyway because of insufficient resources. |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |----------------http://www.eroticboxoffice.com/gmh --------| |If you're looking for the sexiest women on the net, you | |should start you're hunt at http://www.eroticboxoffice.com/gmh | |We have the youngest most, adorable girls you'll ever see!| |And you won't find 'em anywhere else ... | |-------------------THE HUNT STARTS HERE-------------------| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| From rem-conf Wed Oct 14 09:36:25 1998 From rem-conf-request@es.net Wed Oct 14 09:36:24 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zTTgf-0003Yj-00; Wed, 14 Oct 1998 09:22:09 -0700 Received: from pi4.informatik.uni-mannheim.de [134.155.48.125] (-2146555104) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zTTgd-0003YY-00; Wed, 14 Oct 1998 09:22:07 -0700 Received: from solon.informatik.uni-mannheim.de (root@solon [134.155.48.102]) by pi4.informatik.uni-mannheim.de (8.8.8/8.8.8) with ESMTP id SAA25698; Wed, 14 Oct 1998 18:20:19 +0200 (MET DST) Received: from pi4.informatik.uni-mannheim.de (geyer@localhost [127.0.0.1]) by solon.informatik.uni-mannheim.de (8.8.8/8.8.8) with ESMTP id SAA19902; Wed, 14 Oct 1998 18:20:18 +0200 (MET DST) Sender: geyer@pi4.informatik.uni-mannheim.de Message-ID: <3624CF41.436AB1B2@pi4.informatik.uni-mannheim.de> Date: Wed, 14 Oct 1998 18:20:17 +0200 From: Werner Geyer Organization: University of Mannheim X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: rem-conf@es.net, mbone@ISI.EDU, akll@wi2.wiso.uni-erlangen.de Subject: dlb-1.8b2 whiteboard release now available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, A new version (1.8b2) of our whiteboard dlb is now available on our ftp server. Check the download area at http://www.informatik.uni-mannheim.de/~geyer/dlb/dlb.eng.html In contrast to earlier versions we have - included voting, online feedback and chat - improved security - enabled scalable images in a variety of formats - fixed many bugs Thanks to all the helpful comments on the earlier alpha version. Since new features come along with new bugs, we are again looking forward to your feedback. Regards, Werner ______________________________________________________________ Werner Geyer, University of Mannheim, Praktische Informatik IV Tel +49-621-292-1526 ,Fax +49-621-292-5745 EMail: geyer@pi4.informatik.uni-mannheim.de http://www.informatik.uni-mannheim.de/~geyer/ From rem-conf Thu Oct 15 06:41:47 1998 From rem-conf-request@es.net Thu Oct 15 06:41:44 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zTnVu-0000WM-00; Thu, 15 Oct 1998 06:32:22 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zTnVs-0000WA-00; Thu, 15 Oct 1998 06:32:20 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 15 Oct 1998 14:31:17 +0100 To: "Eric C. Rosen" cc: Stephen Casner , Henning Schulzrinne , "Kyle J. McKay" , "John W. Noerenberg" , rem-conf@es.net Subject: Re: Revised AVT charter and draft-mckay-qcelp-01.txt In-reply-to: Your message of "Tue, 13 Oct 1998 14:42:39 PDT." <199810132142.OAA26335@mage.qualcomm.com> Date: Thu, 15 Oct 1998 14:31:15 +0200 Message-ID: <1057.908458275@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> "Eric C. Rosen" writes: >In the QCELP payload specification, the Encrypted (E) bit signals >the presence of an additional byte's worth of crypto header fields, >which in turn may signal the presence or length of cryptosync and >cryptocheck data. In this sense, the E bit has the same meaning >as the Cryptocheck Presence (K) bit or the Cryptosync Length (CSL) >field. It signals the inclusion of additional fields later in the >payload. > >[ Aside: No objections to the K or CSL fields have been noted. ] > >It seems unwise to me to rely on out-of-band control information, >such as the payload type, to determine whether this extra byte is >present in the payload. > >In fact, it seems reasonable not to view the E bit as an encryption >flag. It's utility is limited to indicating the inclusion of >additional fields. Nothing prevents applications from using RTP's >Section 9.1 encryption scheme with the QCELP specification. An >application which did would not need to include the additional crypto >fields defined in the QCELP draft and hence not set the E bit. > >I understand and agree with the arguments to keep signaling information >out of the RTP payload. But although the E bit can obviously be interpreted >as an encryption signal, it's intent is to keep the interpretation >of the payload self-contained. I wonder if perhaps the E bit had been >originally defined as: > > CryptoByte (C): 1 bit > Indicates the presence or absence of an additional octet of payload > fields, whose format and meaning are described in Section 6. > >there would not be any objection to setting the first bit of the payload >when this additional information is present in the payload. My feeling is that there would have been objections. What you have here is really two payload formats merged into one: QCELP and encrypted QCELP. With standard RTP encryption, the payload format does not change when the data is encrypted. The encryption can be performed within the RTP layer, and the codec need not be aware that this is occuring. This is not the case with the QCELP payload format which requires the codec to be aware of the encryption. If it is required that the decoding process is changed when encryption is present this should be signalled by a change in the payload format, which is the standard means of choosing the decoder. Colin From rem-conf Thu Oct 15 10:24:26 1998 From rem-conf-request@es.net Thu Oct 15 10:24:26 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zTqru-0003xW-00; Thu, 15 Oct 1998 10:07:18 -0700 Received: from (fsnt.future.futsoft.com) [38.242.192.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zTqrp-0003xC-00; Thu, 15 Oct 1998 10:07:17 -0700 Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Thu, 15 Oct 1998 22:34:03 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id WAA01297; Thu, 15 Oct 1998 22:33:46 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <3626DB3A@msgate.future.futsoft.com>; Thu, 15 Oct 98 22:35:54 PDT From: vishwas To: "'Dave.Brillhart@sun.com'" Cc: rem-conf , linux-ppp Subject: Linux- Solaris PPP Date: Thu, 15 Oct 98 22:33:00 PDT Message-Id: <3626DB3A@msgate.future.futsoft.com> X-Mailer: Microsoft Mail V3.0 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Dave, I want to use a NULL MODEM cable between Linux and Solaris and do Just Routing. I am not interested in in any Login accounts and Modem fundas. How can I go ahed with this in Solaris..? Till now I get some {{{$@#%#$ LCP data in my asppp.log But it halts at expect: (in:) This login is there in /etc/uucp/Systems I dont want any ppp user, I just want to do ROUTING, Can U update ur 23 steps to configure Solaris PPP, for this kind of configurations Regards vishwa (Software Engineer, Future Software Pvt. Ltd, Chennai, India) From rem-conf Thu Oct 15 17:53:37 1998 From rem-conf-request@es.net Thu Oct 15 17:53:36 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zTy3j-0002FO-00; Thu, 15 Oct 1998 17:47:59 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zTy3h-0002FE-00; Thu, 15 Oct 1998 17:47:57 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id RAA31614; Thu, 15 Oct 1998 17:47:57 -0700 (PDT) Message-Id: <3.0.3.32.19981015174755.00a94260@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 15 Oct 1998 17:47:55 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 10/21 Berkeley Multimedia, Interfaces & Graphics Seminar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar Indexing Large Scale Rich Media Content for Enterprise Applications Eric Hoffert Magnifi, Inc. Wednesday, October 21, 1998 12:30-2:30pm 405 Soda Hall Rich media content is exploding. QuickTime is now on more than 50 million personal computers. More than 30 million RealAudio and RealVideo players have been distributed on the Internet. Adobe Acrobat, a key format for publishing rich media documents, is hosted at more than 250,000 web sites. Content rich sites such as CNN host information across text, images, sound and video - but 95% of the information at the CNN site is contained entirely in images, sound and video. The trend towards broader usage of rich media is accelerating across broadcast, publishing, corporate, educational, and government sites - for both Internet and Intranet deployment. But rich media is hard to find. Most indexing engines provide little, if any, support to effectively search for rich media objects. Even if one can find a file, there is often still a significant hurdle to download or stream a media file of interest to see or hear what it is about. Given the large size of multimedia files, the variety of media formats, and the typically low bandwidth connections of Internet and Intranet users, there are significant barriers to finding what you want, when you want it. The solution to this challenge is the development of a system that can rapidly index large volumes of rich media content and present search results in an easy to use interface. In this talk, we will review the details of a large scale indexing system for rich media content. The major building blocks - a crawler for locating media assets on distributed networks, media blocks for intelligent content understanding, and media search, an interface for search and retrieval of rich assets, will all be discussed. Component technologies for media indexing - content previewing, content analysis, and contextual relevance will be explained. The system we will review is currently in use primarily in marketing applications - at large Intranet sites such as Citicorp and Boeing, and at high traffic Internet Top 100 sites such as Warner Bros. Online, and CNN Interactive. The media indexing system is now being used to create network based brand asset catalogs that can be shared across the "marketing content supply chain". The marketing supply chain includes corporate marketing departments, and all of their key content suppliers - advertising agencies, design firms, video production studios, et. al. In this context, the media indexing engine is a key component of a three tier enterprise system for brand management and creative workflow based on java, CORBA and Oracle 8. The use of this system will be described for building enterprise wide brand asset catalogs. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Fri Oct 16 20:22:50 1998 From rem-conf-request@es.net Fri Oct 16 20:22:48 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zUMV8-0001ps-00; Fri, 16 Oct 1998 19:53:54 -0700 Received: from mysa.qualcomm.com [129.46.52.23] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zUMV7-0001pb-00; Fri, 16 Oct 1998 19:53:53 -0700 Received: from armada.qualcomm.com (dvassilo.qualcomm.com [129.46.172.190]) by mysa.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with SMTP id TAA02235 for ; Fri, 16 Oct 1998 19:52:51 -0700 (PDT) X-PGP-DH-Fingerprint: 6F62 552C 7730 B45D 2FDF  AC3E B6BD 356A 58D1 FF20 Message-Id: <4.1.19981016195245.00aff900@clea.qualcomm.com> X-Sender: dvassilo@clea.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 16 Oct 1998 19:52:51 -0700 To: rem-conf@es.net From: Dan Vassilovski Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove danv From rem-conf Sat Oct 17 16:54:16 1998 From rem-conf-request@es.net Sat Oct 17 16:54:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zUfyT-0002Yb-00; Sat, 17 Oct 1998 16:41:29 -0700 Received: from mailgw3.lmco.com [192.35.35.23] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zUfyQ-0002YR-00; Sat, 17 Oct 1998 16:41:26 -0700 Received: from emss04g01.ems.lmco.com ([166.17.13.122]) by mailgw3.lmco.com (8.8.8/8.8.8) with ESMTP id TAA32304 for ; Sat, 17 Oct 1998 19:41:25 -0400 (EDT) Received: from emss35m01.ems.lmco.com ([158.187.107.140]) by lmco.com (PMDF V5.1-10 #20546) with ESMTP id <0F0Z00JVQWH1DG@lmco.com> for rem-conf@es.net; Sat, 17 Oct 1998 19:41:25 -0400 (EDT) Received: by emss35m01.owg.fs.lmco.com with Internet Mail Service (5.5.2232.9) id <450ZSG0B>; Sat, 17 Oct 1998 19:44:22 -0400 Content-return: allowed Date: Sat, 17 Oct 1998 19:41:56 -0400 From: "Driscoll, Daniel" Subject: To: "'rem-conf@es.net'" Message-id: <99AA2270B1E6D111BCE10000F805F17FF0ACCD@emss35m02.owg.fs.lmco.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove daniel.driscoll@lmco.com From rem-conf Sun Oct 18 16:14:28 1998 From rem-conf-request@es.net Sun Oct 18 16:14:26 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zV1ji-00054D-00; Sun, 18 Oct 1998 15:55:42 -0700 Received: from caboose.zip.com.au [203.12.97.11] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zV1jf-000541-00; Sun, 18 Oct 1998 15:55:40 -0700 Received: from zip.com.au (jeff44.zip.com.au [203.62.150.172]) by caboose.zip.com.au (8.9.1/8.9.1) with ESMTP id IAA13761 for ; Mon, 19 Oct 1998 08:55:29 +1000 Message-ID: <362A72B9.70E8E63E@zip.com.au> Date: Mon, 19 Oct 1998 08:59:05 +1000 From: Phil Brewer X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: remove Content-Type: multipart/mixed; boundary="------------1E4471549485D597295E7D41" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------1E4471549485D597295E7D41 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit remove brewerp@zip.com.au --------------1E4471549485D597295E7D41 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Phil Brewer Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Phil Brewer n: Brewer;Phil org: Chubb VISION adr: 87 Racecourse Road;;North Melbourne;Melbourne;Victoria;3051;AUSTRALIA email;internet: brewerp@zip.com.au title: CCTV/Video Support Engineer tel;work: +61 3 9241 5522 tel;fax: +61 3 9328 2304 tel;home: 0417 054 099 x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------1E4471549485D597295E7D41-- From rem-conf Sun Oct 18 21:03:07 1998 From rem-conf-request@es.net Sun Oct 18 21:03:06 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zV6PW-0000ZI-00; Sun, 18 Oct 1998 20:55:10 -0700 Received: from fezik.qualcomm.com [129.46.2.74] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zV6PV-0000YZ-00; Sun, 18 Oct 1998 20:55:09 -0700 Received: from armada.qualcomm.com (dvassilo.qualcomm.com [129.46.172.190]) by fezik.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with SMTP id UAA25368 for ; Sun, 18 Oct 1998 20:54:07 -0700 (PDT) X-PGP-DH-Fingerprint: 6F62 552C 7730 B45D 2FDF  AC3E B6BD 356A 58D1 FF20 Message-Id: <4.1.19981018205410.00afe910@clea.qualcomm.com> X-Sender: dvassilo@clea.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 18 Oct 1998 20:54:27 -0700 To: rem-conf@es.net From: Dan Vassilovski Subject: remove Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove danv@qualcomm.com From rem-conf Mon Oct 19 06:43:04 1998 From rem-conf-request@es.net Mon Oct 19 06:43:04 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zVFSa-00005J-00; Mon, 19 Oct 1998 06:34:56 -0700 Received: from engine3-dc.wdc.cwi.net [205.136.1.212] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zVFSZ-000057-00; Mon, 19 Oct 1998 06:34:55 -0700 Received: from houston_cc_smtp.hai.com (hai.com [207.124.15.67]) by engine3-dc.wdc.cwi.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 100-36394U2500L250S0) with SMTP id AAA11111 for ; Mon, 19 Oct 1998 09:34:54 -0400 Received: from ccMail by houston_cc_smtp.hai.com (ccMail Link to SMTP R8.30.00.7) id AA908804051; Mon, 19 Oct 1998 09:34:14 -0400 Message-Id: <9810199088.AA908804051@houston_cc_smtp.hai.com> X-Mailer: ccMail Link to SMTP R8.30.00.7 Date: Mon, 19 Oct 1998 09:31:31 -0400 From: "Jackson Scott D." To: Subject: remove MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: "cc:Mail Note Part" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove sjackson@hai-net.com From rem-conf Mon Oct 19 08:01:24 1998 From rem-conf-request@es.net Mon Oct 19 08:01:23 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zVGhE-0001ms-00; Mon, 19 Oct 1998 07:54:08 -0700 Received: from amon.siol.net [193.189.160.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zVGhC-0001mP-00; Mon, 19 Oct 1998 07:54:06 -0700 Received: from admin ([193.189.183.79]) by amon.siol.net (Post.Office MTA v3.5.1 release 219 ID# 620-52342U30000L30000S0V35) with SMTP id net; Mon, 19 Oct 1998 16:53:48 +0200 From: "=?iso-8859-2?B?VE9NQa4=?=" To: "Jan-Peter Richter" , , , , , , Subject: Re: Date: Wed, 14 Oct 1998 23:57:46 +0200 Message-ID: <01bdf7bd$ae391ca0$LocalHost@admin> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list -----Izvorno sporoèilo----- Od: Jan-Peter Richter Za: mbone@ISI.EDU ; rem-conf@es.net ; cabernet-events@newcastle.ac.uk ; mmt-liste@tu-dresden.de ; int-serv@ISI.EDU ; rsvp@ISI.EDU Datum: 25. avgust 1998 12:32 > > > --> We apologize if you receive multiple copies of this. <-- > >======================================================================= > > >******************************************************************** > > Preliminary Call for Papers > > Workshop on > > Modeling Multimedia Support in > Next Generation High Speed Networks (NGHSN99) > > Warsaw, Poland, June 1st to 2nd, 1999 > > co-located with > ESM'99 > European Simulation Multiconference > > >Highly demanding applications such as multimedia are becoming more and >more important in today's high speed networks. The design of future >communication infrastructures will be strongly influenced by experiences >made today, and support for modern application will be available. >However, >making such applications feasible will not work when based on ad-hoc >solutions due to the high complexity of the whole problem field. Rather, >models, simulation and analysis should be employed to direct future >developments. > >The goal of this workshop is to survey and advance the state of the art >in modeling and simulation support for future generation high-speed >networks and >applications. Possible topics include, but are not limited to > >- traffic models >- modeling techniques (automata-based techniques, Markov chains, Petri > Nets etc.) >- simulation (languages, tools) >- real-time issues >- Quality of Service (modeling, Internet support, pricing and charging >etc.) >- multimedia in the Internet and WWW >- multicast and Group Communication (modeling, simulation, QoS > support) >- programmable networks: active networks and open signalling > > > >Requested Contributions and Submission Procedure: >------------------------------------------------- > > >Please submit your full-length paper (Postscript or PDF, 11pt font min, >8 pages max.) >electronically using our web site at >http://www.i-u.de/resources/events/NGHSN99/. You will find further >instructions about the submission process there. > >If you cannot submit electronically, please send 5 hardcopies of your >paper to > >Dr. Stefan Fischer >International University >School of Information Technology >International University Campus 1 >D-76646 Bruchsal >Germany > >Accepted papers will be published in workshop proceedings (by SCS). > > > >Important Dates: >---------------- > >November 1st, 1998: Submission of papers >January 15th, 1999: Notification of Acceptance >March 1st, 1999: Camera-Ready Copy > > >General Chair: >-------------- >Hermann de Meer, Columbia University, New York, USA > >Program Chair: >-------------- >Stefan Fischer, International University, Bruchsal, Germany > >Program Committee: >------------------ >Gregor v. Bochmann, University of Ottawa, Canada >Gunter Bolch, University of Erlangen, Germany >Torsten Braun, University of Berne, Sitzerland >Jan Bredereke, McMaster University, Hamilton, Canada >Stanislaw Budkowski, INT Evry, France >Michel Diaz, LAAS, France >Reinhard Gotzhein, University of Kaiserslautern, Germany >Abdelhakim Hafid, University of Western Ontario, London, Canada >Stefan Leue, University of Waterloo, Canada >Jozef Lubacz, Warsaw University of Technology, Poland >Jan de Meer, GMD FOKUS, Berlin, Germany >Bruno Mueller-Clostermann, University of Essen, Germany >Andrzej Pach, Cracow University of Mining, Poland >Otto Spaniol, RWTH Aachen, Germany >Heinrich Stuettgen, NEC Europe, Germany >Janos Sztrik, University of Debrecin, Hungary >Miklos Telek, University of Budapest, Hungary >Kishor S. Trivedi, Duke University, USA >Ralph Wittmann, TU Braunschweig, Germany >Lars Wolf, TU Darmstadt, Germany >Martina Zitterbart, TU Braunschweig, Germany > > >For further information, contact: > >Hermann de Meer (hdm@comet.columbia.edu) or >Stefan Fischer (Stefan.Fischer@i-u.de) > > > From rem-conf Mon Oct 19 08:21:37 1998 From rem-conf-request@es.net Mon Oct 19 08:21:36 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zVH3D-0002Zk-00; Mon, 19 Oct 1998 08:16:51 -0700 Received: from (alpha.telecom-co.net) [200.21.27.100] by mail1.es.net with smtp (Exim 1.81 #2) id 0zVH3A-0002ZX-00; Mon, 19 Oct 1998 08:16:49 -0700 Received: by alpha.telecom-co.net; id AA20394; Mon, 19 Oct 1998 10:15:54 -0500 Message-Id: <362B5743.F15CC713@alpha.telecom-co.net> Date: Mon, 19 Oct 1998 10:14:12 -0500 From: Diego Daniel Sosa Organization: ITEC - Telecom, Colombia X-Mailer: Mozilla 4.05 [en] (Win95; I) Mime-Version: 1.0 To: "rem-conf@es.net" Subject: PC Connection to the MBONE ?Possible? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, I am wondering if there is an application for getting hooked to the MBone, despite the fact I do not know whether there are mrouters between me and the MBone (which should obviously use a tunnel). Questions: Is it possible to attend to the following seminar even if we have not configured our routers for multicast? How can I implement a tunnel from my Pc to send/receive from and to an IPMulticast address? >The seminar is broadcast on the Internet Mbone. The addresses are video >224.2.163.7/57076 and audio 224.2.147.61/27202. I would really appreciate if anyone could help me configure any of these applications or have suggestions for getting connected to the MBone fast. Thanks in advance, Daniel. ------------------------------------------------------------------------------- Diego Daniel Sosa Research Division - Engineer Technical Institute of Electronics and Communications ITEC - TELECOM, COL. Email: dsosa@alpha.telecom-co.net , d-sosa@uniandes.edu.co ------------------------------------------------------------------------------- From rem-conf Mon Oct 19 13:51:25 1998 From rem-conf-request@es.net Mon Oct 19 13:51:24 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zVM7F-00006b-00; Mon, 19 Oct 1998 13:41:21 -0700 Received: from proxy3.ba.best.com [206.184.139.14] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zVM7E-00006Q-00; Mon, 19 Oct 1998 13:41:20 -0700 Received: from mg-20425418-22.ricochet.net (mg-20425418-22.ricochet.net [204.254.18.22]) by proxy3.ba.best.com (8.9.0/8.9.0/best.out) with SMTP id NAA19126; Mon, 19 Oct 1998 13:37:46 -0700 (PDT) Message-Id: <3.0.5.16.19981019133038.2f2f7ba4@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Mon, 19 Oct 1998 13:30:38 To: Diego Daniel Sosa From: Ross Finlayson Subject: Re: PC Connection to the MBONE ?Possible? Cc: "rem-conf@es.net" In-Reply-To: <362B5743.F15CC713@alpha.telecom-co.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 10:14 AM 10/19/98 -0500, Diego Daniel Sosa wrote: >I am wondering if there is an application for getting hooked to the >MBone, despite the fact I do not know whether there are mrouters between >me and the MBone (which should obviously use a tunnel). > >Questions: Is it possible to attend to the following seminar even if we >have not configured our routers for multicast? How can I implement a >tunnel from my Pc to send/receive from and to an IPMulticast address? If you have access to (i.e., have an account on) a machine that is *already* on the MBone, then your PC can set up an 'ad hoc' connection to the MBone, using UMTP (the UDP Multicast Tunneling Protocol). On the MBone machine you would run a UMTP server (such as "liveGate" ), and on your PC you would run a UMTP client (such as "multikit" , which also gives you a session directory). If the seminar that you're interested in is being announced in the standard SDP/SAP MBone session directory, then you should be able to see and join it (once you have appropriate multicast audio/video helper applications, of course). Of course, this depends upon you having access to a machine that's already on the MBone. In any case, you should think of this approach (UMTP tunneling) as being only a short-term solution. You should really be configuring your routers for multicast, and get on the MBone 'for real'. Is there any reason why you're not doing this? Ross. From rem-conf Tue Oct 20 00:36:11 1998 From rem-conf-request@es.net Tue Oct 20 00:36:08 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zVW8i-0004gH-00; Tue, 20 Oct 1998 00:23:32 -0700 Received: from pop3.tu-dresden.de [141.30.2.83] by mail1.es.net with smtp (Exim 1.81 #2) id 0zVW8h-0004g6-00; Tue, 20 Oct 1998 00:23:31 -0700 Received: from rmail.urz.tu-dresden.de by rks3 with SMTP (PP); Tue, 20 Oct 1998 09:18:51 +0200 Received: from rncmm2.urz.tu-dresden.de by rmail with SMTP (IC-PP); Tue, 20 Oct 1998 09:20:19 +0200 Received: from localhost (fleck@localhost) by rncmm2.urz.tu-dresden.de (8.8.8/8.8.8) with SMTP id JAA03539; Tue, 20 Oct 1998 09:23:10 +0200 (MET DST) X-Authentication-Warning: rncmm2.urz.tu-dresden.de: fleck owned process doing -bs Date: Tue, 20 Oct 1998 09:23:09 +0200 (MET DST) From: Christoph Fleck X-Sender: fleck@rncmm2.urz.tu-dresden.de Reply-To: Multimedia Referenzzentrum To: Diego Daniel Sosa cc: "rem-conf@es.net" Subject: Re: PC Connection to the MBONE ?Possible? In-Reply-To: <362B5743.F15CC713@alpha.telecom-co.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, > I am wondering if there is an application for getting hooked to the > MBone, despite the fact I do not know whether there are mrouters between > me and the MBone (which should obviously use a tunnel). > > Questions: Is it possible to attend to the following seminar even if we > have not configured our routers for multicast? How can I implement a > tunnel from my Pc to send/receive from and to an IPMulticast address? > > >The seminar is broadcast on the Internet Mbone. The addresses are video > > >224.2.163.7/57076 and audio 224.2.147.61/27202. You have not to set up a tunnel. It would be easy if you find somebody with MBone connection, who would give you a account or run two processes of rtptrans (one for audio, one for video): rtptrans 224.2.163.7/57076/127 your.ip-adress.video/yourvideoport rtptrans 224.2.147.61/27202/127 your.ip-adress.audio/youraudioport rtptrans is one of the rtptools. It run on FreeBSD, Linux, Solaris, IRIX, ... Works good and stable :-) . Tools you can find at: http://www.cs.columbia.edu/~hgs/rtptools/ (my copy at ftp://ftp-mm.urz.tu-dresden.de/pub/mbone/rtptools/) If you could not find anybody near you, I can do that. But your audio/video have to cross the atlantic twice. So I belive you will get a lot of loss. Rgds, Christoph Fleck ,------------------------------------------------------------------. | Referenzzentrum fuer multimediale Teledienste (MMRZ), TU Dresden | | Dr. Klaus Koehler, Christoph Fleck | | e-mail: mmt-ref@tu-dresden.de Tel.: 0351 / 463 5653 | | WWW: http://www-mm.urz.tu-dresden.de (GERMANY) | `------------------------------------------------------------------' From rem-conf Tue Oct 20 07:35:57 1998 From rem-conf-request@es.net Tue Oct 20 07:35:57 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zVckH-0000hM-00; Tue, 20 Oct 1998 07:26:45 -0700 Received: from beech.sucs.soton.ac.uk [152.78.129.138] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zVckD-0000h9-00; Tue, 20 Oct 1998 07:26:44 -0700 Received: from cedar.sucs.soton.ac.uk (cedar.sucs.soton.ac.uk [152.78.128.92]) by beech.sucs.soton.ac.uk (8.8.8/relay-02) with ESMTP id PAA17682 for ; Tue, 20 Oct 1998 15:26:34 +0100 (BST) Received: from brillig (brillig.tsms.soton.ac.uk [152.78.49.7]) by cedar.sucs.soton.ac.uk (8.8.8/relay-02) with SMTP id PAA07305 for ; Tue, 20 Oct 1998 15:20:18 +0100 (BST) Message-Id: <3.0.1.32.19981020152213.00a68dd0@pop3.soton.ac.uk> X-Sender: djp@pop3.soton.ac.uk X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 20 Oct 1998 15:22:13 +0100 To: rem-conf@es.net From: David Price Subject: Remove Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove djp@soton.ac.uk From rem-conf Tue Oct 20 08:24:45 1998 From rem-conf-request@es.net Tue Oct 20 08:24:44 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zVdZF-0001ij-00; Tue, 20 Oct 1998 08:19:25 -0700 Received: from gate.alcatel.be (btmplq.god.bel.alcatel.be) [195.207.101.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zVdZD-0001iY-00; Tue, 20 Oct 1998 08:19:23 -0700 Received: from se9ws191.sebb.bel.alcatel.be (se9ws191.sebb.bel.alcatel.be [138.203.168.191]) by btmplq.god.bel.alcatel.be (8.9.1a/8.9.1) with SMTP id RAA04276 for ; Tue, 20 Oct 1998 17:17:09 +0200 (MET DST) Date: Tue, 20 Oct 1998 17:17:09 +0200 (MET DST) From: wangd@sebb.bel.alcatel.be Message-Id: <199810201517.RAA04276@btmplq.god.bel.alcatel.be> To: rem-conf@es.net Subject: Remove Cc: wangd@btmplq.god.bel.alcatel.be X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list From rem-conf Tue Oct 20 10:05:13 1998 From rem-conf-request@es.net Tue Oct 20 10:05:12 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zVf7F-0003HZ-00; Tue, 20 Oct 1998 09:58:37 -0700 Received: from ursamajor.cisco.com [171.69.63.56] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zVf7E-0003GK-00; Tue, 20 Oct 1998 09:58:36 -0700 Received: from casner-pc1.cisco.com (casner-pc1.cisco.com [171.71.37.112]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA17511; Tue, 20 Oct 1998 09:57:17 -0700 (PDT) Date: Tue, 20 Oct 1998 09:59:00 -0700 (Pacific Daylight Time) From: Stephen Casner To: "Eric C. Rosen" cc: rem-conf@es.net Subject: Re: Revised AVT charter and draft-mckay-qcelp-01.txt In-Reply-To: <199810132142.OAA26335@mage.qualcomm.com> Message-ID: X-X-Sender: casner@ursamajor.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Tue, 13 Oct 1998, Eric C. Rosen wrote: > In the QCELP payload specification, the Encrypted (E) bit signals > the presence of an additional byte's worth of crypto header fields, > which in turn may signal the presence or length of cryptosync and > cryptocheck data. In this sense, the E bit has the same meaning > as the Cryptocheck Presence (K) bit or the Cryptosync Length (CSL) > field. It signals the inclusion of additional fields later in the > payload. > > It seems unwise to me to rely on out-of-band control information, > such as the payload type, to determine whether this extra byte is > present in the payload. I disagree. Why does it seem unwise? I contend that the variable presence or absence of the additional byte and the cryptosync and crytocheck data is a misfeature. I would expect that a particular stream would always use exactly the same configuration of these bits in every packet. Hence there is no need to waste that extra byte in each packet and to force the receiver to execute several conditional checks. Instead, by binding to the payload type, one can write "fast path" code that implements the common case with no conditionals. If you do need to change the settings on the fly, you can define multiple dynamic payload types for the different sets of settings. We've exercised this philosophy as much as we could in the design of RTP itself and in other payload formats. > In fact, it seems reasonable not to view the E bit as an encryption > flag. It's utility is limited to indicating the inclusion of > additional fields. Nothing prevents applications from using RTP's > Section 9.1 encryption scheme with the QCELP specification. An > application which did would not need to include the additional crypto > fields defined in the QCELP draft and hence not set the E bit. And then there would be two ways to do the same thing, leading to reduced interoperability. I have some more comments about other aspects of the proposal that I will send in another message. -- Steve From rem-conf Tue Oct 20 11:46:17 1998 From rem-conf-request@es.net Tue Oct 20 11:46:17 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zVggG-0004eU-00; Tue, 20 Oct 1998 11:38:52 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zVggF-0004eK-00; Tue, 20 Oct 1998 11:38:51 -0700 Received: from quimby.cs.berkeley.edu (quimby.CS.Berkeley.EDU [128.32.131.169]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with ESMTP id LAA24516; Tue, 20 Oct 1998 11:38:39 -0700 (PDT) Message-Id: <199810201838.LAA24516@gumby.CS.Berkeley.EDU> X-Mailer: exmh version 1.6.9 8/22/96 From: "Larry Rowe" To: rem-conf@es.net cc: larry@gumby.CS.Berkeley.EDU Subject: [UCB MIG Seminar] Wed 10/21 12.30-2 PDT: E. Hoffert "Indexing Rich Media Content for Enterprise Applications" Reply-To: Rowe@bmrc.berkeley.edu Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="===_0_Tue_Oct_20_11:38:07_PDT_1998" Date: Tue, 20 Oct 1998 11:38:39 -0700 Sender: larry@bmrc.berkeley.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multipart MIME message. --===_0_Tue_Oct_20_11:38:07_PDT_1998 Content-Type: text/plain; charset=us-ascii Indexing Rich Media Content for Enterprise Applications Eric Hoffert (Magnifi, Inc.) (Wednesday October 21, 1998 12:30-2:00 PDT 405 Soda Hall) Rich media content is exploding. QuickTime is now on more than 50 million personal computers. More than 30 million RealAudio and RealVideo players have been distributed on the Internet. Adobe Acrobat, a key format for publishing rich media documents, is hosted at more than 250,000 web sites. Content rich sites such as CNN host information cross text, images, sound and video - but 95% of the information at the CNN site is contained entirely in images, sound and video. The trend towards broader usage of rich media is accelerating across broadcast, publishing, corporate, educational, and government sites - for both Internet and Intranet deployment. But rich media is hard to find. Most indexing engines provide little, if any, support to effectively search for rich media objects. Even if one can find a file, there is often still a significant hurdle to download or stream a media file of interest to see or hear what it is about. Given the large size of multimedia files, the variety of media formats, and the typically low bandwidth connections of Internet and Intranet users, there are significant barriers to finding what you want, when you want it. The solution to this challenge is the development of a system that can rapidly index large volumes of rich media content and present search results in an easy to use interface. In this talk, we will review the details of a large scale indexing system for rich media content. The major building blocks - a crawler for locating media assets on distributed networks, media blocks for intelligent content understanding, and media search, an interface for search and retrieval of rich assets, will all be discussed. Component technologies for media indexing - content previewing, content analysis, and contextual relevance will be explained. The system we will review is currently in use primarily in marketing applications - at large Intranet sites such as Citicorp and Boeing, and at high traffic Internet Top 100 sites such as Warner Bros. Online, and CNN Interactive. The media indexing system is now being used to create network based brand asset catalogs that can be shared across the "marketing content supply chain". The marketing supply chain includes corporate marketing departments, and all of their key content suppliers - advertising agencies, design firms, video production studios, et. al. In this context, the media indexing engine is a key component of a three tier enterprise system for brand management and creative workflow based on java, CORBA and Oracle 8. The use of this system will be described for building enterprise wide brand asset catalogs. --- Note: Eric was one of the original developers of Apple Quicktime and Quicktime Conferencing. --- The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Or, you can use the attached SDP file to connect to the session. Larry Rowe -- Professor Lawrence A. Rowe Internet: Rowe@BMRC.Berkeley.EDU Computer Science Division - EECS Phone: 510-642-5117 University of California, Berkeley Fax: 510-642-5615 Berkeley, CA 94720-1776 URL: http://www.bmrc.berkeley.edu/~larry --- Attachment: --===_0_Tue_Oct_20_11:38:07_PDT_1998 Content-Type: text/plain; charset=us-ascii Content-Description: UCBMIG.sdp v=0 o=fitzboy 3112717552 3112718191 IN IP4 128.32.32.118 s=UCBerkeley Multimedia, Interfaces and Graphics Seminar i=Broadcasting the UCBerkeley Multimedia, Interfaces and Graphics seminar. Various guest speakers will be appearing and giving talks. Check the web site for upcoming speakers. This is a weekly broadcast until the end of the semester, in December. u=http://bmrc.berkeley.edu/courseware/cs298/fall98/index.html p=fitzboy 510-643-7106 e=fitzboy t=3113148600 3115575000 r=604800 7200 0 a=tool:sdr v2.3a1 a=type:test m=audio 27202 RTP/AVP 0 c=IN IP4 224.2.147.61/127 a=ptime:40 m=video 57076 RTP/AVP 31 c=IN IP4 224.2.163.7/127 --===_0_Tue_Oct_20_11:38:07_PDT_1998-- From rem-conf Tue Oct 20 14:24:55 1998 From rem-conf-request@es.net Tue Oct 20 14:24:55 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zVjA3-0006lK-00; Tue, 20 Oct 1998 14:17:47 -0700 Received: from (matilda.wpine.com) [140.249.38.180] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zVj9x-0006l2-00; Tue, 20 Oct 1998 14:17:42 -0700 Received: from alf-mobile ([140.249.42.94]) by matilda.wpine.com (Post.Office MTA v3.1 release PO203a ID# 0-34401U600L100S0) with SMTP id AAA19891; Tue, 20 Oct 1998 17:13:55 -0400 From: aeisenberg@wpine.com (Alfred Eisenberg) To: , Subject: unsubscribe Date: Tue, 20 Oct 1998 17:08:22 -0400 Message-ID: <004a01bdfc6d$c51a1e60$5e2af98c@alf-mobile.wpine.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >-----Original Message----- >From: 71288840@24841.com [mailto:71288840@24841.com] >Sent: Monday, August 31, 1998 4:11 PM >To: niomi@hisbe.com >Subject: Market Timing > > >MT is delivered to our subscribers via an automated list >service; unsubscribing instructions are at the end of this >letter. > > >September 20, 1998 > > >Table of Contents - Market Timing - Sept 20 edition > > >1. MT Interviews NuOncology Management >2. Market Commentary >3. MT in Europe >4. Departments > > >1. MT Interviews NuOncology Management > >NuOncology Labs Inc. Symbol: NLAB - OTC Bulletin Board > >We apologize for not getting this letter out a few days ago >but there is a lot going on with this company - for instance, >only Tuesday of this week MT received a request to be kept updated >about NuOncology's progress, from an Asian based pharmaceutical >concern. > >MT met with the Senior Management of NuOncology Labs Inc. >on September 10, 1998, at the offices of their investment >relations firm in Washington, D.C. > >MT met with Mr. Robert S. Thomas, Chairman and President, Mr. >Philip F. Enlow, Executive Vice President and Mr. Joe Kane, a >financial consultant to NuOncology Labs Inc. > >As you can appreciate in a meeting such as this, there are >legal and regulatory restrictions on what information can be >shared with MT and our readers, but from the information we >did receive there is no doubt this company is making significant >progress. > >We received confirmation that the doctors at the Baker-Sanger >Laboratory in Houston, Texas are in the final phases of testing >and validating Arglabin and determining its method of action. >We also learned that one of the original doctors from Kazakstan >is in Houston and assisting in this process. > >The completion of these tests will be followed by the publishing >of a paper, in a recognized medical journal, discussing the >findings of NuOncology's research team. This paper will be co-authored >by at least four physicians with extensive experience and >credentials in oncological research, including Dr. R. Michael >Williams, NuOncology's Medical Director and Chief Scientific Officer. > >Our impression was that this paper would be completed very soon >and if the demeanor of the people we met with is any indication, >the results are what NuOncology and their shareholders want to see - >our feeling is that Arglabin is an FTI. > >SN will immediately publish a synopsis of the paper when it is >available. > >We also gained an appreciation of how far ahead of other >biopharmaceutical companies NuOncology is at the present time. > >To the best of MT's knowledge no one has published information >on clinical (human) trials of FTI's. NuOncology Labs Inc, on the other >hand, has all of the clinical results from the Institute of >Phytochemistry, in Kazakstan, for the treatment of over 200 >patients with various types of cancers. > >In addition, on a visit to take place between October 19-29, >1998, further results will be available from clinical trials >involving 40 liver cancer and 60 breast cancer patients. These >tests have been conducted so as to conform to the international >protocols for medical research and should help to add credence >to the effectiveness of Arglabin. For this reason alone, NuOncology >Labs Inc could be 1-2 years ahead of their many industry competitors >who are trying to develop FTI's. (There are at least 8 major >pharmaceutical companies conducting research in this area.) > >We were also pleased to confirm that the patents for the lead >compound, Arglabin, and the broader patents for its related and >derivative compounds are held in the United States and controlled >by NuOncology Labs Inc. > >One of the key questions to our readers is "What is all this >worth?" The best answer MT could come up with was by making >an analogy to another cancer treatment, Taxol, that seems to >work in a similar way to Arglabin. > >Taxol is a $1 billion a year drug today. It has one serious >problem in that it is highly toxic. Arglabin, conversely, has >minimal toxic side effects and in clinical trials appears to >work as well and in some cases better than Taxol, depending on >the type of cancer being treated. > >Assuming that the clinical trials continue to confirm Arglabin's >efficacy as a cancer treatment, one way of looking at the >valuation of Arglabin would be as a less toxic Taxol. This could >easily lead to Arglabin becoming the treatment of choice and >thereby giving it a value at least equal to Taxol. > >In our next letter we will discuss a number of other developments >underway in the predictive and chemosensitivity testing areas of >NuOncology's business. MT wishes to thank the management of >NuOncology Labs Inc. for taking the time for this meeting and >providing ourselves and our readers with these insights into >their company and their business. > >MT continues to feel very bullish about this company and encourage >our readers to closely follow this rapidly developing situation. >We believe the shares of NuOncology Labs Inc. (NLAB) to be very >attractive at prices up to $10. > > > >2. Market Commentary > >If the market rally can be credited to the strong hints >of an interest rate cut late last week and Monday, and >the slide in the market in the middle of last week can be >blamed on Mr. Clinton's personal problems then this market >is not in bad shape and is likely to move higher. > >We believe that Mr. Greenspan's guidance of the economy is >key to how the U.S. economic future will unfold. In fact, the >future of a number of large Asian and South American economies >are dependent on his guidance. > >The "doom and gloom" crowd project the present set of trends >and parameters into the future and get a self fulfilling >prophecy of economic disaster. This is where we differ from >those that are predicting a more negative outlook - we do not >assume the monetary authorities of the major economic powers >are going to do nothing. > >MT believes that the position that is now being taken by the >Fed in the U.S. is that America will have to try and ward off a >global recession by initially lowering interest rates and >thereby encouraging domestic growth. They will also lend >enough money, through the IMF, to reflate many of the world's >troubled economies. > >This scenario is only possible because the US economy is strong, >unemployment is low, interest rates are at historic lows (and >probably heading lower), there is no apparent inflationary >pressures, and there is no external threat to the U.S.. > >Mr. Clinton is less than 2 months away from what most pundits >will soon be referring to as the "lame duck" period of his >Presidency. Although we do not think it likely that he will >be impeached, if it does occur, we do not think it will be >a factor in the economic equation. > >The bottom line is that the U.S. will need to be the engine to >keep many of the world's economies afloat and resuming the type >of growth they have shown in the past. > >For this reason MT believes that the future for the U.S. economy >and stock market is positive and there will continue to be >opportunities to profit for the savvy investor. > > >3. MT in Europe > >MT is expanding its readership in certain 'key' economic centers >in Europe. For the convenience of our readers, MT will now be >available in German. For those subscribers who would like to receive >their issues of MT in German simply type "German" in the subject >and send an e-mail to : > >Wetpapiere@USA.net > >There is no need to write a letter as you >will automatically be sent future issues of MT in German. > > >4. Departments > > >A. Stock Quotes >B. MT Privacy Policy >C. Disclaimer >D. How to Unsubscribe > > >A. Stock Quotes > >To get a stock quote please go to: > >http://www.StockGuide.com > > >B. MT Privacy Policy > >At MT we respect your privacy and will NEVER release your e-mail >address to a third party for any reason. > > >C. Disclaimer > >Please read our disclaimer at: > >http://206.132.163.167/krichx/mtdis.htm > > >D. How to Unsubscribe > > >To unsubscribe to MT simply put 'unsubscribe' in the subject and return to: > >UnsubscribeMT@USA.net > >You will be unsubscribed instantly. > > From rem-conf Tue Oct 20 21:19:03 1998 From rem-conf-request@es.net Tue Oct 20 21:19:01 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zVpd3-0002Fn-00; Tue, 20 Oct 1998 21:12:09 -0700 Received: from mail-gw6.pacbell.net [206.13.28.41] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zVpd2-0002Fd-00; Tue, 20 Oct 1998 21:12:08 -0700 Received: from [192.168.0.1] (ppp-206-170-7-87.rdcy01.pacbell.net [206.170.7.87]) by mail-gw6.pacbell.net (8.8.8/8.7.1+antispam) with SMTP id VAA23501; Tue, 20 Oct 1998 21:12:02 -0700 (PDT) X-Sender: ario@postoffice.pacbell.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 Oct 1998 21:11:59 -0700 To: aeisenberg@wpine.com (Alfred Eisenberg) From: Ari@OLTECO.com (Ari Ollikainen) Subject: Re: unsubscribe Cc: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >>-----Original Message----- >>From: 71288840@24841.com [mailto:71288840@24841.com] >>Sent: Monday, August 31, 1998 4:11 PM >>To: niomi@hisbe.com >>Subject: Market Timing >> [silly spam removed] >> Thanks! My mailbox really needed THAT...now I have TWO copies to dispose of, as do the others on the rem-conf list. What's the point of mailing spam back to the mailing list that was in turn spammed? IF *you* want to get off (unsubscribe) the rem-conf list send your request to: rem-conf-request@es.net putting UNSUBSCRIBE in the Subject: field as well as the body. (You might indicate the e-mail address you want unsubscribed IF it's different than the address in the From: part of your message.) While I'm here, ALL the people sending "remove"s should heed my advice in the previous paragraph. Thank you. OLTECO Ari Ollikainen P.O. BOX 3688 Networking Technology and Architecture Stanford, CA Ari@OLTECO.com 94309-3688 415.517.3519 From rem-conf Wed Oct 21 00:35:00 1998 From rem-conf-request@es.net Wed Oct 21 00:34:58 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zVsfR-0003p6-00; Wed, 21 Oct 1998 00:26:49 -0700 Received: from beech.sucs.soton.ac.uk [152.78.129.138] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zVsfP-0003ow-00; Wed, 21 Oct 1998 00:26:48 -0700 Received: from cedar.sucs.soton.ac.uk (cedar.sucs.soton.ac.uk [152.78.128.92]) by beech.sucs.soton.ac.uk (8.8.8/relay-02) with ESMTP id IAA24522 for ; Wed, 21 Oct 1998 08:26:46 +0100 (BST) Received: from apollo.sucs.staff.sucs.soton.ac.uk (apollo.staff.sucs.soton.ac.uk [152.78.132.46]) by cedar.sucs.soton.ac.uk (8.8.8/relay-02) with SMTP id IAA20326 for ; Wed, 21 Oct 1998 08:21:29 +0100 (BST) From: David Holter Reply-To: D.A.Holter@soton.ac.uk To: rem-conf@es.net Subject: Remove Message-ID: Date: Wed, 21 Oct 1998 08:23:34 +0100 (BST) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.4 Build (40) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove D.A.Holter@soton.ac.uk ---------------------- David Holter Networking Group Computing Services University of Southampton UK +44 1703 593571 +44 1703 593939 D.A.Holter@soton.ac.uk From rem-conf Wed Oct 21 08:59:58 1998 From rem-conf-request@es.net Wed Oct 21 08:59:57 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zW0XU-0001cd-00; Wed, 21 Oct 1998 08:51:08 -0700 Received: from fwgate-2.rss.rockwell.com (fwgate-2.nb.rss.rockwell.com) [157.152.197.3] (firewall-user) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zW0XT-0001cS-00; Wed, 21 Oct 1998 08:51:07 -0700 Received: by fwgate-2.nb.rss.rockwell.com; id IAA18111; Wed, 21 Oct 1998 08:50:57 -0700 (PDT) From: Received: from npbsmtp1.nb.rss.rockwell.com(157.152.161.153) by fwgate-2.nb.rss.rockwell.com via smap (4.1) id xmac18091; Wed, 21 Oct 98 08:50:33 -0700 Received: by npbsmtp1.nb.rockwell.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 882566A4.0056166C ; Wed, 21 Oct 1998 08:40:18 -0700 X-Lotus-FromDomain: RSS To: rem-conf@es.net Message-ID: <882566A4.0056148A.00@npbsmtp1.nb.rockwell.com> Date: Wed, 21 Oct 1998 17:21:20 +0200 Subject: DirectShow Filter [To rem-conf@es.net] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sirs, Environment: WindowsNT 5.0 beta 2 DirectShow toolbox I need to implement a DirectShow source filter which reads data >from a socket connection and dumps it downstream to some transform filter. The socket would deliver RTP data frames or G.72x data. The data to be read are originating from an ISDN connection. Do you have source code or fragments I could start with ? Regards Norbert Rossello norbert.rossello@rss.rockwell.com From rem-conf Wed Oct 21 11:32:14 1998 From rem-conf-request@es.net Wed Oct 21 11:32:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zW2x5-0004ol-00; Wed, 21 Oct 1998 11:25:43 -0700 Received: from post.queensu.ca [130.15.126.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zW2x4-0004ob-00; Wed, 21 Oct 1998 11:25:42 -0700 Received: from eleceng.ee.queensu.ca (eleceng.ee.queensu.ca [130.15.16.1]) by post.queensu.ca (8.9.0/8.9.0) with SMTP id OAA29603; Wed, 21 Oct 1998 14:24:44 -0400 (EDT) Received: from htm5.queensu.ca by eleceng.ee.queensu.ca (4.1/SMI-4.1) id AA12793; Wed, 21 Oct 98 14:24:43 EDT Received: by htm5.queensu.ca (4.1/SMI-4.1) id AA01758; Wed, 21 Oct 98 14:24:33 EDT Date: Wed, 21 Oct 1998 14:24:29 -0400 (EDT) From: Hussein Mouftah X-Sender: mouftah@htm5 To: multicomm@research.panasonic.com, multicomm@cc.bellcore.com, comswtc@gmu.edu, atm@bbn.com, ieeetcpc@ccvm.sunysb.edu, hipparch@sophia.inria.fr, rem-conf@es.net, commsoft@cc.bellecore.com, tccc@ieee.org, ietf@cnri.reston.va.us Subject: Call-for-Papers of IEEE BSS'99 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list IEEE BSS '99 3rd IEEE International Workshop on Broadband Switching Systems Kingston, Ontario, Canada, June 1-3, 1999 http://www.ece.queensu.ca/dept/bss.html CALL FOR PAPERS OBJECTIVE ========== The goal of this workshop is to provide an effective forum for discussing new directions, new challenges, new opportunities, and new advances on Broadband Switching Systems, and to foster communications among researchers and engineers from both academia and industry with a common interest in improving Broadband Switching Systems. SCOPE ===== The primary focus of the workshop is on new and original research results of Switching Systems for the Broadband Internet and for QoS on Demand. We solicit the submission of papers that address novel, challenging, and innovative results. The topics that will be addressed include, but are not limited to: o ATM Switching Systems o Wireless ATM Switching o IP/ATM Interworking o IP Switching o Gigabit Switching o Gigabit Routers o Photonic Switching o Quality of Services (QoS) Issues o Routing and Control of Congestion, Admission, and Flow o Alternate Approaches to Broadband Switching o Performance Evaluation of Broadband Switching Systems o Broadband Network Operations and Management o Broadband Switching Systems Field Trials o Other Aspects of Broadband Switching SUBMISSION =========== Authors are invited to submit original papers. Papers that may be submitted for consideration include those that have not previously been published in other forums or conferences. All submitted papers will be refereed for quality, correctness, originality, and relevance. All accepted papers will be published in the workshop proceedings. Manuscripts should include an abstract and be limited to 3,000 words. Submissions should include the title, author name(s), author's affiliation, e-mail address, fax number and postal address. In case of multiple authors, an indication of which author is responsible for correspondence and preparing the camera-ready paper for the proceedings should also be included. Four double-spaced copies of the manuscript, or one copy of the manuscript in PostScript format should be submitted by January 31st, 1999 to: Dr. Hussein Mouftah Chair, BSS'99 Department of Electrical and Computer Engineering, Queen's University Kingston, Ontario, Canada K7L 3N6 Phone: 613 545 2934 Fax: 613 545 6615 Email: mouftah@eleceng.ee.queensu.ca Technical Program Committee: =========================== G.S. Kuo (National Central University, Taiwan) Andrzej Jajszczyk (University of Technology and Agriculture (ATR), Poland) Richard Vickers (Nortel Networks, Canada) Mounir Hamdi (Technical University of Hong Kong, Hong Kong) Mohammad Atiquzzaman (University of Dayton, USA) Ibrahim Gedeon (Nortel Networks, Canada) Tom Chen (Southern Methodist University, USA) Horst Besier (Deutsche Telekom, Germany) Maurizio Decina (Politecnico di Milano/CEFRIEL, Italy) Ken-ichi Sato (NTT, Japan) IMPORTANT DATES =============== Paper submission deadline: January 31st, 1999 Notification of acceptance: April 2nd, 1999 Camera-ready papers due: April 26th, 1999 TUTORIALS ========= Proposals are solicited for tutorials. Please send your proposal by January 31st, 1999 to Dr. Hussein Mouftah ---------------------------- From rem-conf Wed Oct 21 12:12:14 1998 From rem-conf-request@es.net Wed Oct 21 12:12:13 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zW3dL-0006QH-00; Wed, 21 Oct 1998 12:09:23 -0700 Received: from sirius.ctr.columbia.edu [128.59.64.60] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zW3dK-0006Q6-00; Wed, 21 Oct 1998 12:09:22 -0700 Received: from comet.columbia.edu (hdm@nebula.comet.columbia.edu [128.59.68.18]) by sirius.ctr.columbia.edu (8.9.1/8.6.4.287) with ESMTP id PAA04798; Wed, 21 Oct 1998 15:09:16 -0400 (EDT) From: hdm@comet.columbia.edu (Herman De Meer) Received: (from hdm@localhost) by comet.columbia.edu (8.9.1/8.8.7/COMET) id PAA10792; Wed, 21 Oct 1998 15:09:14 -0400 (EDT) Message-Id: <199810211909.PAA10792@comet.columbia.edu> Subject: New Book Announcement To: rem-conf@es.net Date: Wed, 21 Oct 1998 15:09:13 -0400 (EDT) Cc: cabernet-events@newcastle.ac.uk X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list *********** NEW BOOK ANNOUNCEMENT ************ ``Queueing Networks and Markov Chains: Modeling and Performance Evaluation with Computer Science Applications'' Gunter Bolch / Stefan Greiner / Hermann de Meer / Kishor S. Trivedi ISBN 0-471-19366-6 Hardcover: US$89.95 est. Copyright: 1998 Pub Date: Aug 1998 John Wiley & Sons, New York 726 pages Subject: Engineering / Engineering, Electrical / Communication & Information CONTENTS Performance analysis seeks to discover the information bottlenecks in a computer system, and allows the system designer to create an optimal system for a specific need. This book presents a self-contained and complete presentation of the theory and application of computer performance evaluation based on queueing theory and Markov chains. After beginning with basic probability theory, Queueing Networks and Markov Chains proceeds to the more complicated topics of queueing networks and Markov chains, using applications and examples to illustrate key points. 1.Introduction 2.Markov Chains, Modeling Process, Stochastic Petri Nets 3.Steady-State Solution of Markov Chains 4.Steady-State Aggregation/Disaggregation Methods 5.Transient Solution of Markov Chains 6.Single Station Queueing Systems 7.Queueing Networks 8.Algorithms for Product-Form Networks 9.Approximation Algorithms for Product-Form Networks 10.Algorithms for Non-Product-Form Networks 11.Optimization 12.Performance Analysis Tools 13.Applications From rem-conf Wed Oct 21 13:58:54 1998 From rem-conf-request@es.net Wed Oct 21 13:58:53 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zW5FH-0000FU-00; Wed, 21 Oct 1998 13:52:39 -0700 Received: from mirage.cs.berkeley.edu (CS.Berkeley.EDU) [128.32.130.49] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zW5FG-0000FJ-00; Wed, 21 Oct 1998 13:52:38 -0700 Received: (from yatin@localhost) by CS.Berkeley.EDU (8.7.5/8.7.3) id NAA31473; Wed, 21 Oct 1998 13:52:45 -0700 Message-Id: <199810212052.NAA31473@ CS.Berkeley.EDU> X-Mailer: exmh version 2.0.2 2/24/98 To: rem-conf@es.net Cc: mash-users@mash.cs.berkeley.edu Subject: MASH beta release From: Yatin Chawathe Reply-To: Yatin Chawathe X-url: http://www.cs.berkeley.edu/~yatin Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Oct 1998 13:52:45 -0700 Sender: yatin@cs.berkeley.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The MASH Research Project at Berkeley has recently released a beta version of its software -- the MASH multimedia/networking toolkit. This toolkit is freely available for download from http://www-mash.cs.berkeley.edu/mash/software/download.html The MASH project and its software builds on the collective work of the MBone research community (notably, the vic, vat, and wb multicast conferencing tols from LBL) with new approaches to and variants of multimedia control protocols, reliable multicast, real-time transcoding "proxies", wecasting applications, multimedia archive systems, and network programmable "active services". Further details of the project are available at http://www-mash.cs.berkeley.edu/mash/ The MASH toolkit is an extensible, object-oriented programming environment based on the Obect Tcl extension of Tcl and on C++. MASH provides a rich set of classes that provide a flexible framework for composing and protoyping networked multimedia applications. In addition to the core toolkit, we are distributing a number of mash "scripts" that comprise a suite of applications that exercise our system (e.g., the vic video tool is now a mash script interpreted by the mash shell rather than a stand-alone executable). We hope that this release fosters extensions and exchange of research multimedia applications and provides a useful platform to the community for related research in multimedia networking. This is a very experimental beta release. We do not yet recommend that you use these tools in place of the current, more robust MBone tools. But we do encourage you to try them out and provide us with feedback on their current capabilities and/or limitations. Thanks, The MASH Group From rem-conf Thu Oct 22 04:07:55 1998 From rem-conf-request@es.net Thu Oct 22 04:07:54 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zWIRJ-0002Vh-00; Thu, 22 Oct 1998 03:57:57 -0700 Received: from chico.rediris.es [130.206.1.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zWIQd-0002VN-00; Thu, 22 Oct 1998 03:57:21 -0700 Received: from news.rediris.es (news.rediris.es [130.206.1.38]) by chico.rediris.es (8.9.1/8.9.1) with ESMTP id MAA12621 for ; Thu, 22 Oct 1998 12:56:59 +0200 (MET DST) Received: from news.rediris.es (o2.rediris.es [130.206.1.45]) by news.rediris.es (8.8.7/8.8.7.7) with ESMTP id MAA08202 for ; Thu, 22 Oct 1998 12:56:53 +0200 (MET DST) Message-Id: <199810221056.MAA08202@news.rediris.es> X-Mailer: exmh version 2.0.1 12/23/97 From: Angel Mateo To: rem-conf@es.net Subject: User control for mbone Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 1998 12:56:53 +0200 Sender: amateo@news.rediris.es X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, We have several LANS and we are intrested in deploy, install or configur= e a = mechanism to be able to control the users that connects to the MBone. Wha= t we = want to do is to configure our network to: * All the users can connect and join to an MBone session. * Only authoriced people can create sessions. A possible solution would be to installed only mSD in one machine and do= n=B4t = install sdr, but this doesn't avoid people to installed sdr in a machine = and = to create a session. Does any way to do this? Thanks, ----------------------------------------- Angel L. Mateo Martinez RedIRIS/CSIC C/ Serrano, 142 28006 Madrid (Spain) Tlfo: +34-91-5855145 Fax: +34-91-5855146 From rem-conf Thu Oct 22 07:30:45 1998 From rem-conf-request@es.net Thu Oct 22 07:30:44 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zWLf3-0006CC-00; Thu, 22 Oct 1998 07:24:21 -0700 Received: from nis-tradewind.paisley.ac.uk (wpmail.paisley.ac.uk) [146.191.32.5] by mail1.es.net with smtp (Exim 1.81 #2) id 0zWLey-0006AC-00; Thu, 22 Oct 1998 07:24:16 -0700 Received: from Gate-Message_Server by wpmail.paisley.ac.uk with Novell_GroupWise; Thu, 22 Oct 1998 14:23:36 +0000 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 22 Oct 1998 14:22:58 +0000 From: Delia Atherton To: rem-conf@es.net Subject: EuropIA98 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_B6E1A2F8.30513EBF" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_B6E1A2F8.30513EBF Content-Type: text/plain Content-Disposition: inline Dear Colleague Please find attached the final programme. Best regards, --=_B6E1A2F8.30513EBF Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="EIAFPGM1.TXT" RVVST1BJQSAnOTggIDogQ1lCRVJERVNJR04NCk1lZGlhLCBDb21tdW5pY2F0aW9uICYgRGVzaWdu IFByYWN0aWNlDQpNZWRpYSAmIENvbW11bmljYXRpb24gZGFucyBsYSBQcmF0aXF1ZSBkZSBsYSBD b25jZXB0aW9uDQoNClNldmVudGggSW50ZXJuYXRpb25hbCBDb25mZXJlbmNlIG9uIHRoZSBBcHBs aWNhdGlvbi9JbXBsaWNhdGlvbnMgb2YgQ29tcHV0ZXIgTmV0d29ya2luZyBpbiBBcmNoaXRlY3R1 cmUsIENvbnN0cnVjdGlvbiwgRGVzaWduLCBDaXZpbCBFbmdpbmVlcmluZyBhbmQgVXJiYW4gUGxh bm5pbmcNCg0KU2VwdGnobWUgQ29sbG9xdWUgSW50ZXJuYXRpb25hbCBzdXIgbGVzIGFwcGxpY2F0 aW9ucyBldCBsZXMgaW1wbGljYXRpb25zIGRlcyBub3V2ZWxsZXMgdGVjaG5vbG9naWVzIGRlIGwn aW5mb3JtYXRpb24gZXQgZGUgbGEgY29tbXVuaWNhdGlvbiBlbiBBcmNoaXRlY3R1cmUsIENvbnN0 cnVjdGlvbiBldCBlbiBQbGFuaWZpY2F0aW9uIFVyYmFpbmUNCg0KT3JnYW5pc2VkIGJ5IC8gT3Jn YW5pc+kgcGFyOg0KVW5pdmVyc2l0eSBvZiBQYWlzbGV5IDogRGVwYXJ0bWVudCBvZiBDb21wdXRp bmcgYW5kIEluZm9ybWF0aW9uIFN5c3RlbQ0KVW5pdmVyc2l06SBkZSBDYWVuIDogQy5BLkUuTiAo R1JFWUMsIE1SU0gpDQpQ9GxlIFVuaXZlcnNpdGFpcmUgTOlvbmFyZCBEZSBWaW5jaSA6IElGQU1J RiwgUGFyaXMgbGEgROlmZW5zZQ0KRXVyb3BpYSBQcm9kdWN0aW9ucywgUGFyaXMNCg0KDQpQQVJJ UyA6IDI1LCAyNiwgMjcgTk9WRU1CRVINClD0bGUgVW5pdmVyc2l0YWlyZSBM6W9uYXJkIGRlIFZp bmNpDQpQYXJpcyBsYSBE6WZlbnNlDQoNCldlZG5lc2RheSAyNS8xMS8xOTk4IC8gTWVyY3JlZGkg MjUgTm92ZW1icmUgMTk5OA0KDQpPcGVubmluZyBTZXNzaW9uIC8gT3V2ZXJ0dXJlIGR1IENvbGxv cXVlIC0gVmlkZW8gQ29uZmVyZW5jZQ0KDQo5aDAwIC0gOWgxNSAJRHIuIENoZXJpZiBCUkFOS0ks IFVuaXZlcnNpdHkgb2YgUGFpc2xleSwgRUlBJzk4IENoYWlybWFuDQoNCjloIDE1IC0gOWg0NSAJ TS4gUmljaGFyZCBTSEFXLCBQcm9mZXNzb3IsIFByaW5jaXBhbCBvZiBUaGUgVW5pdmVyc2l0eSBv ZiBQYWlzbGV5DQoNCjloIDQ1IC0gMTBoMDUgCU0uIE1pY2hlbCBCQVJBVCwgRGlyZWN0ZXVyIEfp bulyYWwgZHUgUPRsZSBVbml2ZXJzaXRhaXJlIEzpb25hcmQgZGUgVmluY2kNCg0KMTBoMDUgLSAx MGYxNSAJTS4gQ2hyaXN0aWFuIFNBTkRFUiwgRGlyZWN0ZXVyIGRlIGwnSUZBTUlGDQoNCjEwaDE1 IC0gMTBoNDUJSW52aXRlZCBTcGVha2VyIC8gQ29uZulyZW5jZSBpbnZpdOllDQpNLiBNLiBM6Wds aXNlLCBQcm9mZXNzZXVyLCBFY29sZSBkJ0FyY2hpdGVjdHVyZSBkZSBUb3Vsb3VzZQ0KQ29uc3Rp dHV0aW9uIGQndW5lIG3pbW9pcmUgcGVyc29ubmVsbGUg4CBwYXJ0aXIgZGUgcmVwculzZW50YXRp b25zIGRpc3PpbWlu6WVzLiANCg0KMTBoNDUgLSAxMWgxNSBDb2ZmZWUgQnJlYWsgLyBQYXVzZSBD YWbpDQoNClNFU1NJT04gSSAoU2hvcnQgcGFwZXJzIC8gY29tbXVuaWNhdGlvbnMgY291cnRlcyA6 IDExaDE1IC0gMTJoMzApDQpDWUJFUiBERVNJR04gRU5WSVJPTk1FTlQgVlMgUkVBTCBERVNJR04g RU5WSVJPTk1FTlQgDQoNCk0uIENyb3dlLCAgUy4gS3lkZA0KVW5pdmVyc2l0eSBvZiBQYWlzbGV5 LCBVSw0KQWdlbnRzIGFuZCBzdWdnZXN0aW9ucyBpbiBhIFdlYi1iYXNlZCBkeW5hbWljIHdvcmtm bG93IG1vZGVsLg0KDQpOLiBCYXVwaW4gJiAgSy4gWnJlaWsNCkNORVQsIENhZW4sIFVuaXZlcnNp dHkgb2YgQ2FlbiwgRnJhbmNlDQpU6WzpZGVjaXNpb246IE4uVC5JLkMuIGV0IGNvbmNlcHRpb24g Y29vcGVyYXRpdmUuDQoNCk0uIENsYXl0b24NClRleGFzIEEmTSBVbml2ZXJzaXR5LCBVU0ENCkRp c3RyaWJ1dGVkIGRlc2lnbiBrbm93bGVkZ2UgdXNpbmcgZm9ybSwgZnVuY3Rpb24gYW5kIGJlaGF2 aW91cg0KDQpZLiBSZXplDQpVbml2ZXJzaXTpIG9mIENhZW4sIEZyYW5jZSwNCkwnaHlwZXJtZWRp YTogdW5lIGF1dHJlIGZhY29uIGRlIHJlcHJlc2VudGVyLg0KDQpDLiBERVNIQVlFUw0KRWNvbGUg ZCdBcmNoaXRlY3R1cmUgZGUgUGFyaXMtVmFsLURlLU1Bcm5lLCBGcmFuY2UNClBlcmNlcHRpb24g c3BhdGlhbGUgZCd1biBlbnZpcm9ubWVudCBhcmNoaXRlY3R1cmFsOiBhc3BlY3RzDQppbmZvcm1h dGlvbm5lbCBldCBjb21tdW5pY2F0aW9ubmVsLg0KDQoNClNFU1NJT04gSUkgKFNob3J0IHBhcGVy cyAvIGNvbW11bmljYXRpb25zIGNvdXJ0ZXMgOiAxNGgwMCAtIDE1aDE1KQ0KV0VCIEJBU0VEIERF U0lHTg0KSU5URVJORVQgREFOUyBMQSBQUkFUSVFVRSBERSBMQSBDT05DRVBUSU9ODQpOLiBLYXJh Y2FwaWxpZGlzLCBPLiBBYm91IEtoYWxlZA0KRVBGTCwgU3dpdHplcmxhbmQNCkVzdGFibGlzaGlu ZyBjb21tdW5pY2F0aW9uIGJldHdlZW4gYSB3ZWItYmFzZWQgYXJndW1lbnRhdGlvbg0KYW5kIHJl bW90ZSBkYXRhYmFzZXMNCg0KRi4gQW1lemlhbmUsIFMuIExhc3NlcnJlDQpFY29sZSBkJ0FyY2hp dGVjdHVyZSBkZSBNYXJzZWlsbGUgLCBGcmFuY2UNCkJ1aWxkaW5nIGluZm9ybWF0aW9uIGluIGNv b3BlcmF0aXZlIHByb2R1Y3Rpb24gY29udGV4dA0KDQpNLiBCb3ViZWtyaQ0KVW5pdmVyc2l0eSBv ZiBJbGxpbm9pcywgVVNBDQpDb21wdXRlciBOZXR3b3JraW5nIGFuZCBMaWdodGluZyBEZXNpZ24g SW5zdHJ1Y3Rpb24uDQoNCkcuIFZhc3F1ZXogZGUgVmVsYXNjbywgTi4gSG9sbGFuZA0KVGV4YXMg QSZNIFVuaXZlcnNpdHksIFVTQQ0KQ29tcHV0ZXIgbWVkaWF0ZWQgcmVjaXByb2NhbCBkaXN0YW5j ZSBlZHVjYXRpb24uDQoNClAuIFZhbiBkZXIgVmVlciwgSS5TLlNhcml5aWxkaXosINYuIENpZnRj aW9nbHUNCkRlbGZ0IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neSwgVGhlIE5ldGhlcmxhbmRzDQpP cmRlcmluZyBvZiBJbmZvcm1hdGlvbiBhbmQgRnVuY3Rpb25hbGl0eSBmb3IgZGVjaXNpb24gc3Vw cG9ydCBpbg0KYnVpbGRpbmcgZGVzaWduLg0KDQpQT1NURVJTICYgUmFmcmHuY2hpc3NlbWVudCAo MTVoMTUgLSAxN2gxNSkNCg0KVEhVU0RBWSAyNi8xMS8xOTk4IC8gSmV1ZGkgMjYgTm92ZW1icmUg MTk5OA0KDQoNClNFU1NJT04gSUlJIDogICg5aDAwIC0gMTBoMzApDQpPTiBMSU5FIERJU1RSSUJV VEVEIERFU0lHTiBFTlZJUk9OTUVOVA0KRU5WSVJPTk5FTUVOVCBEWU5BTUlRVUUgUE9VUiBMQSBD T05DRVBUSU9OIENPT1BFUkFUSVZFDQoNClIuIENveW5lLCBKLiBMZWUsIEQuIER1bmNhbiwgUy4g T2ZsdW9nbHUNClVuaXZlcnNpdHkgb2YgRWRpbmJ1cmdoLCBVSw0KQXBwbHlpbmcgd2ViLWJhc2Vk IHByb2R1Y3QgbGlicmFyaWVzLg0KDQoNCkwuIE1hcnRpbiwgVGhlIEplcmRlIFBhcnRuZXJzaGlw IEludGVybmF0aW9uYWwgSW5jLiwgVVNBIA0KQXJjaGl0ZWN0dXJlIGluIGRpZ2l0YWwgZG9tYWlu OiBmcm9tIGFyY3RpYyBpbWFnZXMgdG8gZGVzZXJ0DQpkcmVhbWxhbmRzLg0KDQpCYXJrb3dza2ks IEMuIEJyYW5raSwgRS4gR3JhYnNrYSwgVy4gUGFsYWN6DQpVbml2ZXJzaXR5IG9mIFBhaXNsZXks IFUuSy4sIElGVFJTLCBQb2xhbmQsIElDUywgUG9sYW5kDQpUb3dhcmRzIGNvbGxhYm9yYXRpdmUg ZHNlaWduLg0KDQoxMGgzMCAtIDExaDAwIENvZmZlZSBCcmVhayAvIHBhdXNlIENhZukNCg0KU0VT U0lPTiBJVjogKDExaDAwLTEzaDAwKQ0KREFUQSBBQ1FVSVNJVElPTiBDWUJFUlNQQUNFDQpDWUJF Ui1FU1BBQ0VTIFBPVVIgTCdBQ1FVSVNJVElPTiBERVMgRE9OTkVFUyBFTiBDT05DRVBUSU9ODQoN ClAuIE1jSW50b3NoLCBBcml6b25hIFN0YXRlIFVuaXZlcnNpdHksIFVTQQ0KS25vd2xlZGdlIGFj cXVpc2l0aW9uIHVzaW5nIFZSTUwgYW5kIHVuaWZpZWQgbW9kZWxpbmcgbGFuZ3VhZ2U6IHRoZSBj YXNlIG9mIHRoZSBSR0IgY29tcHV0ZXIgcm9vbS4NCg0KQS4gUm91c3NlbCAmIEsuIFpyZWlrDQpD TkVULCBDYWVuLCBVbml2ZXJzaXR5IG9mIENhZW4sIEZyYW5jZQ0KTGEgc3VwZXJjaGFyZ2Ug6Wxl Y3Ryb25pcXVlIGVuIGNvbmNlcHRpb24gIkxlIFByb2pldCBCQUxJIg0KDQpILiBBaW5zbGV5LCBD LiBHaGFvdWkNCkxpdmVycG9vbCBKb2huIE1vb3JlcyBVbml2ZXJpdHksIFUuSy4NClN0cnVjdHVy aW5nIGh5cGVybWVkaWEgbGVhcm5pbmcgbWF0ZXJpYWwgdG8gY29tbXVuaWNhdGUga25vd2xlZGdl Lg0KDQpFLiBIZW5yeSwgRC4gQm9pc3NpZXIsIEMuIEJvdWxlbWlhDQpMQU1ILCBDVVNULCBMQU1I LCBGcmFuY2UNCkFjcXVpc2l0aW9uIGV0IGV4dHJhY3Rpb24gZGVzIGNvbm5haXNzYW5jZXMgcG91 ciBsYSBnZW5lcmF0aW9uIGRlIHN5c3RlbWVzIGRlIGZvbmRhdGlvbnMgZGUgYmF0aW1lbnRzLg0K DQoNClNFU1NJT04gViA6IDE0aDMwIC0gMTZoMDANCkNZQkVSREVTSUdOIFNPQ0lBTCBGRUFUVVJF Uw0KQ1lCRVJDT05DRVBUSU9OIDogQVNQRUNUIFNPQ0lBTA0KDQpDLiBUd2VlZA0KVGhlIFF1ZWVu J3MgVW5pdmVyc2l0eSBvZiBCZWxmYXN0LCBOb3J0aGVybiBJcmVsYW5kDQpEZXZlbG9waW5nIGFu IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHNvY2lhbCBjb250ZXh0IG9mIENBQUQgaW4gcHJhY3RpY2Uu DQoNCk0uIENyb3dlLCBTLiBLeWRkDQpVbml2ZXJzaXR5IG9mIFBhaXNsZXksIFUuSy4NCkRlbGVn YXRpb24gYW5kIGludGVyZmVyZW5jZTogdGhlIHBlcnNvbmFsIHdvcmtzdGF0aW9uIGFuZCB0aGUN CmNvcnBvcmF0ZSBuZXR3b3JrLg0KDQpNLiBTbXl0aA0KTmFwaWVyIFVuaXZlcnNpdHksIFUuSy4N ClRoZSBhY3Rpdml0eSBvZiBkZXNpZ24gYXMgcmV2ZWFsZWQgYnkgdG9vbCB1c2FnZS4NCg0KMTZo MDAgLSAxNmgzMCBDb2ZmZWUgQnJlYWsgLyBwYXVzZSBDYWbpDQoNClNFU1NJT04gVkkgOiAoMTZo MzAgLSAxOGgwMCkNCkNZQkVSIEFSQ0hJVEVDVFVSQUwgREVTSUdOIExBTkdVQUdFUw0KTEFOR0FH RVMgREUgTEEgQ1lCRVJDT05DRVBUSU9OIEFSQ0hJVEVDVFVSQUxFDQoNCkEuVi4gTW9lcmUsIEgu IE5ldWtlcm1hbnMsIEEuSGV5bGlnaGVuDQpLLlUuIExldXZlbiwgQmVsZ2lxdWUNClRoZSBsYW5n dWFnZSBvZiBDeWJlcnNwYWNlOiBhbiBhcmNoaXRlY3R1cmFsIGFwcHJvYWNoLg0KDQpQLiBTemFs YXBhaiwgRC4gQ2hhbmcNClVuaXZlcnNpdHkgb2YgU2hlZmZpZWxkLCBVLksuDQpDb21wdXRlciBB cmNoaXRlY3R1cmFsIFByZXNlbnRhdGlvbiAtIGZyb20gcGh5c2ljYWwgbW9kZWxzIGluIHNwYWNl IHRvIHZpcnR1YWwgbW9kZWxzIGluIGN5YmVyc3BhY2UuDQoNCkEuQnJpZGdlcywgVC5EaW1pdHJp b3MNClVuaXZlcnNpdHkgb2YgU3RyYXRoY2x5ZGUsIFUuSy4NClRoZSBpbXBhY3Qgb2YgZm9ybSBv biBtb3ZlbWVudCB3aXRoaW4gdmlydHVhbCBlbnZpcm9ubWVudHMuDQoNCg0KDQpGcmlkYXkgMjcv MTEvMTk5OCAvIFZlbmRyZWRpIDI3IE5vdmVtYmVyIDE5OTgNCg0KDQpTRVNTSU9OIFZJSSA6ICg5 aDAwIC0gMTBoMzApDQpDWUJFUiBERVNJR04gREVDSVNJT04gU1VQUE9SVA0KQ1lCRVIgRU5WSVJP Tk5FTUVOVCBEJ0FJREUgQSBMQSBERUNJU0lPTiBFTiBDT05DRVBUSU9ODQoNClIuIEJlaGVzaHRp LCBSLiBNaWNoZWxzDQpULlUuRGVsZnQsIHRoZSBOZXRoZXJsYW5kcw0KVGhlIEdsb2JhbCAgR0lT OiBhIGNhc2Ugc3R1ZHkuDQoNClYuIFNyZGFub3ZpYywgTS4gSm92YW5vdmljLCBELiBMZWtpYw0K VW5pdmVyc2l0eSBvZiBCZWxncmFkZSwgRi5ILkksIFl1Z29zbGF2aWENCkFuIGFwcGxpY2F0aW9u IG9mIEdJUyB0ZWNobm9sb2d5IG9mIGZsb29kIGNvbnRyb2wuDQoNCk4uIEViZWwsIEouRy4gSmVh bm5vdCwgWS5BLiBSZWtpaywgSi5QLiBWYWRlciwgQy5WYW5vaXJiZWVrDQpFUEZMLCBTd2l0emVy bGFuZA0KQ0FEQU06IHRvd2FyZHMgYSB3ZWItYmFzZWQgaW5mb3JtYXRpb24gYW5kIGRlY2lzaW9u IHN1cHBvcnQgc3lzdGVtIGZvciBhcHByb3ByaWF0ZW5lc3MgaW4gbWVkaWNpbmUuDQoNCjEwaDMw IC0gMTFoMDAgQ29mZmVlIEJyZWFrIC8gcGF1c2UgQ2Fm6Q0KDQpTRVNTSU9OIFZJSUk6ICgxMWgw MC0xMmgzMCkNCkNZQkVSIENPTU1VTklDQVRJT04NCkNZQkVSIENPTU1VTklDQVRJT04NCg0KUy4g TmV3dG9uLCBKLiBSdXRoZXJmb3JkDQpVbml2ZXJzaXR5IG9mIFdlc3Rlcm4gU3lkbmV5LCBVbml2 ZXJzaXR5IG9mIFN5ZG5leQ0KV2hhdCBmdXR1cmUgZm9yIG9ubGluZSBjb21tdW5pY2F0aW9uIGRl c2lnbj8NCg0KUy5Hcm9zamVhbiwgUC4gRmV4bWVyLCBDLiBCcmFzc2FjDQpVbml2ZXNyaXTpIGRl IE5hbmN5LCBGcmFuY2UNCkNlcyAib3V0aWxzIHBoeWNob2xnaXF1ZXMiIGF1IGNvZXVyIGR1IHBy b2Nlc3N1cyBkZSBjb25jZXB0aW9uLg0KDQpHLiBWYXNxdWV6LCBFLiBBa2xlbWFuDQpUZXhhcyBB Jk0gVW5pdmVyc2l0eQ0KQSBjdXJyaWN1bHVtIGZvciB2aXJ0dWFsIGFyY2hpdGVjdHVyZS4NCg0K TS4gRW5nZWxpLCBQLiBTaWJlbmFsZXINCkFyY2hpdGVjdHVyZSBhbmQgQ0FBRCwgU3dpdHplcmxh bmQNCkRpc2NvdmVyaW5nIHRoZSBkaWdpdGFsIHRlcnJpdG9yeQ0KDQoNClNFU1NJT04gSVggOiAo MTRoMDAgLSAxNWgzMCkNCkNZQkVSIERFU0lHTiBWUyBSRUFMIERFU0lHTg0KQ1lCRVJDT05DRVBU SU9OIFZTIENPTkNFUFRJT04NCg0KSi5QLiBHb3VsZXR0ZSwgUy4gTWFycXVlcw0KRWNvbGUgZCdB cmNoaXRlY3R1cmUgZGUgVG91bG91c2UsIEZyYW5jZSwgVUZQRSwgQnJhemlsDQpCZXR3ZWVuIHJl YWwgYW5kIHZpcnR1YWwgd29ybGRzOiBkZXNpZ24gc3R1ZGllcyBpbiBjeWJlcnNwYWNlLg0KDQpM LiBNYWRyYXpvLCBBLiBXZWRlcg0KRS5ULkguIFp1cmljaCwgU3dpdHplcmxhbmQNCkFBTFRPIG9u IHRoZSBpbnRlcm5ldDogYXJjaGl0ZWN0dXJhbCBhbmFseXNpcyBhbmQgY29uY2VwdCByZXByZXNl bnRhdGlvbiB3aXRoIGNvbXB1dGVyIG1lZGlhLg0KDQpZLksuIEthbmcsIEsuRC4gQ2h1bmcNClB1 c2FuIE5hdGlvbmFsIFVuaXZlcnNpdHksIEtvcmVhDQpNX05PRDogRGVzaWduIGFuZCBhbmFseXNp cyBvZiBtdWx0aW1lZGlhIG5ld3Mgb24gZGVtYW5kIHN5c3RlbS4NCg0KQy4gQnJhc3NhYywgTi4g R3JlZ29yaSwgUC4gUmVtb3Vzc2VuYXJkDQpVbml2ZXJzaXR5IG9mIE5hbmN5LCBGcmFuY2UNClRo ZSBVc2VyIGFzIGFuIEFjdG9yIGZvciBFZHVjYXRpb25hbCBNdWx0aW1lZGlhIFNvZnR3YXJlIERl c2lnbiBQcm9jZXNzDQoNCjE1aDMwIC0gMTZoMDAgQ29mZmVlIEJyZWFrIC8gcGF1c2UgQ2Fm6Q0K DQpTRVNTSU9OIFggOiANCk9OIExJTkUgQ09MTEFCT1JBVElWRSBERVNJR04gDQpDT05DRVBUSU9O IENPTExBQk9SQVRJVkUNCg0KTS4gSmFiYXINClVuaXZlcnNpdHkgVGVsZWtvbSwgTWFsYXlzaWEN CkRlc2lnbiBJbnNwZWN0b3IgYW5kIGNvbnN0cmFpbnQgaW50ZXJwb2xhdG9yIGluIGFzc2VtYmxl LWRpc2Fzc2VtYmxlIGNvbGxhYm9yYXRpdmUgZGVzaWduIGZvciB0aGUgd29ybGQgd2lkZSBtYW51 ZmFjdHVyaW5nIHdlYi4NCg0KQy4gQnJhbmtpLCBCLiBMZWVzLCBBaXJkDQpVbml2ZXJzaXR5IG9m IFBhaXNsZXksIFUuSy4NClRyYWNpbmcgV2ViIEJhc2VkIERlc2lnbiBDb25jZXJucw0KDQpWLiBC b3VyZGFraXMNClVuaXZlcnNpdHkgb2YgQmF0aC4gVUsNClV0aWxpc2luZyBVcmJhbiBWaXJ0dWFs IEVudmlyb25tZW50cw0KDQoNCjE3aDMwIDogQ0xPVFVSRSANCg0KUHJvZmVzc29yIEsuIFpyZWlr LCBVbml2ZXJzaXTpIGRlIENhZW4gOiBDLkEuRS5OIChHUkVZQywgTVJTSCkNCkV1cm9wSUEgQ29u ZmVyZW5jZXMgQ0hBSVJNQU4NCg0KDQoNClJFR0lTVFJBVElPTiBGT1JNIC8gSU5TQ1JJUFRJT04N Cg0KRVVST1BJQSAnOTggQ1lCRVJERVNJR04NCg0KUE9MRSBVTklWRVJTSVRBSVJFIExFT05BUkRP IERBIFZJTkNJDQoNClBBUklTIDogMjUsIDI2LCAyNyBOT1ZFTUJFUg0KDQoNCk5BTUUgLyBOb20N Cg0KQUZGSUxJQVRJT046DQoNCkFERFJFU1MgLyBBZGRyZXNzZQ0KDQoNClBPU1QgQ09ERS1DSVRZ IC8gQ29kZSBQb3N0YWwgVmlsbGUNCg0KQ09VTlRSWSAvIFBheXM6DQoNCg0KDQpSRUdJU1RSQVRJ T04gRkVFUzogRnJhaXMgZCdJbnNjcmlwdGlvbg0KQVVUSE9SUyAvIEF1dGV1cnMJCQkxNTUwRkYN Ck5PTiBBVVRIT1JTIC8gTm9uLUF1dGV1cnMJMTk1MEZGCQ0KU1RVREVOVFMgLyBFdHVkaWFudHMg OgkJODAwRkYNClBsZWFzZSBtYWtlIGNoZXF1ZXMgcGF5YWJsZSB0byA6ICAgICAgRXVyb3BJQSBQ cm9kdWN0aW9ucw0KQWNjb3VudCBObzogCQkJCTMwMDAyIDAwNDQyIDAwMDAwMDY5OTFaIDU4DQpC YW5xdWUgOgkJCQlDcmVkaXQgTHlvbm5haXMsIEFnZW5jZSBQYXJpcyBNYXJjZWF1DQoJCQkJCTQ0 IEF2ZW51ZSBNYXJjZWF1DQoJCQkJCTc1MDA4IFBhcmlzLCBGcmFuY2UNCg0KUGxlYXNlIGVuc3Vy ZSB0aGF0IHlvdXIgYmFuayBjb3ZlcnMgYW55IHRyYW5zZmVyIGNoYXJnZXMuDQoNClRoZSBTdWJz Y3JpcHRpb24gRm9ybSBTaG91bGQgYmUgc2VudCB0byAvIEluc2NyaXB0aW9uLCBDaOlxdWVzIGV0 IEJvbnMgZGUgQ29tbWFuZGVzIGRvaXZlbnQg6nRyZSBhZHJlc3PpcyDgIDoNCg0KRXVyb3BpYSBQ cm9kdWN0aW9ucw0KMTUsIGF2ZW51ZSBkZSBT6Wd1cg0KNzUwMDcgUGFyaXMNClRlbCAoMzMpICgx KSA0NSA1MSAyNiAwNw0KRmF4ICgzMykgKDEpIDQ1IDUxIDI2IDMyDQplLW1haWw6IGpwY291c2lu QHdvcmxkbmV0LmZyICB3aXRoIGFuIGVtYWlsIGNvcHkgdG8gbXlzZWxmLg0KDQoNCkhPVEVMUw0K aHR0cDovL3d3dy5mcmFuY2UtaG90ZWwtZ3VpZGUuY29tLzc1cGFjY3VlLmh0bQ0KaHR0cDovL3d3 dy52aXNpdC1wYXJpcy5jb20vaG90ZWxzL2luZGV4Lmh0bWwNCmh0dHA6Ly93d3cucGFyaXNlcnZl LnRtLmZyL2hvdGVsL2luZGV4Lmh0bQ0KDQpOLkI6ICBIb3RlbHMgbmV4dCB0byB0aGUgbGluZSAx IG9mIHRoZSBtZXRybyAoQ2hhdGVhdSBkZSBWaW5jZW5uZSAtIExhIERlZmVuc2UpIG9yIHRoZSBS RVIgQSBhcmUgcmVjb21tZW5kZWQgKGkuZS4gbmV4dCB0byBFdG9pbGUsIENoYW1wcyBFbHlzZWVz LCBDb25jb3JkZSwgTG91dnJlLCBDaGF0ZWxldCwgQmFzdGlsbGUsDQpWZW5jZW5uZSwgZXRjLikN Cg0KVHJhbnNwb3J0YXRpb25zIChNRVRSTywgUkVSIGFuZCBCdXMpIC8gVHJhbnNwb3J0cw0KaHR0 cDovL3d3dy5yYXRwLmZyLw0KaHR0cDovL3d3dy5yYXRwLmZyL1RyYW5zcG9yL3RyYW5zcGRmMS5o dG0NCmVpdGhlciBpbiBFbmdsaXNoIG9yIEZyZW5jaA0KTWV0cm8ncyBtYXA6DQpodHRwOi8vd3d3 LnJhdHAuZnIvSW1hZ2VzL1BkZi9tZXRybzIucGRmDQpSRVIncyBNYXANCmh0dHA6Ly93d3cucmF0 cC5mci9JbWFnZXMvUGRmL3Jlci5wZGYNCg0K --=_B6E1A2F8.30513EBF Content-Type: application/rtf Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="EIAFPGM.RTF" Content-Description: Rich-Text-Format e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcdWMxIFxkZWZmNFxkZWZsYW5nMTAzM1xkZWZsYW5nZmUx MDMze1xmb250dGJse1xmMFxmcm9tYW5cZmNoYXJzZXQwXGZwcnEye1wqXHBhbm9zZSAwMjAyMDYw MzA1MDQwNTAyMDMwNH1UaW1lcyBOZXcgUm9tYW47fXtcZjFcZnN3aXNzXGZjaGFyc2V0MFxmcHJx MntcKlxwYW5vc2UgMDIwYjA2MDQwMjAyMDIwMjAyMDR9QXJpYWw7fQ0Ke1xmMlxmbW9kZXJuXGZj aGFyc2V0MFxmcHJxMXtcKlxwYW5vc2UgMDIwNzAzMDkwMjAyMDUwMjA0MDR9Q291cmllciBOZXc7 fXtcZjRcZnJvbWFuXGZjaGFyc2V0MFxmcHJxMntcKlxwYW5vc2UgMDIwMjA2MDMwNTA0MDUwMjAz MDR9VGltZXN7XCpcZmFsdCBUaW1lcyBOZXcgUm9tYW59O30NCntcZjhcZnJvbWFuXGZjaGFyc2V0 MFxmcHJxMntcKlxwYW5vc2UgMDAwMDAwMDAwMDAwMDAwMDAwMDB9VG1zIFJtbntcKlxmYWx0IFRp bWVzIE5ldyBSb21hbn07fXtcZjM5XGZyb21hblxmY2hhcnNldDBcZnBycTJ7XCpccGFub3NlIDAy MDIwNjAzMDUwNDA1MDIwMzA0fVRpbWVzIE5ldyAoVzEpO317XGY2MVxmcm9tYW5cZmNoYXJzZXQy MzhcZnBycTIgVGltZXMgTmV3IFJvbWFuIENFO30NCntcZjYyXGZyb21hblxmY2hhcnNldDIwNFxm cHJxMiBUaW1lcyBOZXcgUm9tYW4gQ3lyO317XGY2NFxmcm9tYW5cZmNoYXJzZXQxNjFcZnBycTIg VGltZXMgTmV3IFJvbWFuIEdyZWVrO317XGY2NVxmcm9tYW5cZmNoYXJzZXQxNjJcZnBycTIgVGlt ZXMgTmV3IFJvbWFuIFR1cjt9e1xmNjZcZnJvbWFuXGZjaGFyc2V0MTg2XGZwcnEyIFRpbWVzIE5l dyBSb21hbiBCYWx0aWM7fXtcZjY3XGZzd2lzc1xmY2hhcnNldDIzOFxmcHJxMiBBcmlhbCBDRTt9 DQp7XGY2OFxmc3dpc3NcZmNoYXJzZXQyMDRcZnBycTIgQXJpYWwgQ3lyO317XGY3MFxmc3dpc3Nc ZmNoYXJzZXQxNjFcZnBycTIgQXJpYWwgR3JlZWs7fXtcZjcxXGZzd2lzc1xmY2hhcnNldDE2Mlxm cHJxMiBBcmlhbCBUdXI7fXtcZjcyXGZzd2lzc1xmY2hhcnNldDE4NlxmcHJxMiBBcmlhbCBCYWx0 aWM7fXtcZjczXGZtb2Rlcm5cZmNoYXJzZXQyMzhcZnBycTEgQ291cmllciBOZXcgQ0U7fQ0Ke1xm NzRcZm1vZGVyblxmY2hhcnNldDIwNFxmcHJxMSBDb3VyaWVyIE5ldyBDeXI7fXtcZjc2XGZtb2Rl cm5cZmNoYXJzZXQxNjFcZnBycTEgQ291cmllciBOZXcgR3JlZWs7fXtcZjc3XGZtb2Rlcm5cZmNo YXJzZXQxNjJcZnBycTEgQ291cmllciBOZXcgVHVyO317XGY3OFxmbW9kZXJuXGZjaGFyc2V0MTg2 XGZwcnExIENvdXJpZXIgTmV3IEJhbHRpYzt9fXtcY29sb3J0Ymw7XHJlZDBcZ3JlZW4wXGJsdWUw O1xyZWQwXGdyZWVuMFxibHVlMjU1Ow0KXHJlZDBcZ3JlZW4yNTVcYmx1ZTI1NTtccmVkMFxncmVl bjI1NVxibHVlMDtccmVkMjU1XGdyZWVuMFxibHVlMjU1O1xyZWQyNTVcZ3JlZW4wXGJsdWUwO1xy ZWQyNTVcZ3JlZW4yNTVcYmx1ZTA7XHJlZDI1NVxncmVlbjI1NVxibHVlMjU1O1xyZWQwXGdyZWVu MFxibHVlMTI4O1xyZWQwXGdyZWVuMTI4XGJsdWUxMjg7XHJlZDBcZ3JlZW4xMjhcYmx1ZTA7XHJl ZDEyOFxncmVlbjBcYmx1ZTEyODtccmVkMTI4XGdyZWVuMFxibHVlMDsNClxyZWQxMjhcZ3JlZW4x MjhcYmx1ZTA7XHJlZDEyOFxncmVlbjEyOFxibHVlMTI4O1xyZWQxOTJcZ3JlZW4xOTJcYmx1ZTE5 Mjt9e1xzdHlsZXNoZWV0e1x3aWRjdGxwYXJcYWRqdXN0cmlnaHQgXGY0XGxhbmcxMDM2XGNncmlk IFxzbmV4dDAgTm9ybWFsO317XHMxXGtlZXBuXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcYlxmNFx1 bFxsYW5nMTAzNlxjZ3JpZCBcc2Jhc2Vkb24wIFxzbmV4dDAgaGVhZGluZyAxO317DQpcczJca2Vl cG5cd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxiXGlcZjRcbGFuZzEwMzZcY2dyaWQgXHNiYXNlZG9u MCBcc25leHQwIGhlYWRpbmcgMjt9e1xzM1xrZWVwblx3aWRjdGxwYXJcYWRqdXN0cmlnaHQgXGJc ZjRcbGFuZzEwMzZcY2dyaWQgXHNiYXNlZG9uMCBcc25leHQwIGhlYWRpbmcgMzt9e1wqXGNzMTAg XGFkZGl0aXZlIERlZmF1bHQgUGFyYWdyYXBoIEZvbnQ7fXtcczE1XHdpZGN0bHBhclxhZGp1c3Ry aWdodCANClxiXGY0XHVsXGxhbmcxMDM2XGNncmlkIFxzYmFzZWRvbjAgXHNuZXh0MTUgQm9keSBU ZXh0O317XHMxNlxub3dpZGN0bHBhclxhZGp1c3RyaWdodCBcZjQgXHNiYXNlZG9uMCBcc25leHQx NiBUZXh0ZSBwYXIgZFwnZTlmYXV0O317XCpcY3MxNyBcYWRkaXRpdmUgXGYyIEluaXRpYWxTdHls ZTt9e1xzMThcc2E4MFxzbDI0MFxzbG11bHQwXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcYlxmNFxj ZjFcY2dyaWQgXHNiYXNlZG9uMCBcc25leHQxOCANCjAxIGF1dGV1cjt9e1xzMTlcc2wyNDBcc2xt dWx0MFx3aWRjdGxwYXJcYWRqdXN0cmlnaHQgXGlcZjRcZnMyMFxjZjFcY2dyaWQgXHNiYXNlZG9u MCBcc25leHQxOSAwMSBhZHJlc3NlO317XHMyMFxzYjI0MFx3aWRjdGxwYXJcYWRqdXN0cmlnaHQg XGJcZjRcZnMyOFxsYW5nMjA1NyBcc2Jhc2Vkb24wIFxzbmV4dDIxIGF1dGhvcjt9e1xzMjFccWpc c2wzMDBcc2xtdWx0MFx3aWRjdGxwYXJcYWRqdXN0cmlnaHQgXGY0XGxhbmcyMDU3IA0KXHNiYXNl ZG9uMjAgXHNuZXh0MjIgYWZmaWxpYXRpb247fXtcczIyXHFqXHNsMjYwXHNsbXVsdDBcd2lkY3Rs cGFyXGFkanVzdHJpZ2h0IFxmNFxmczIwXGxhbmcyMDU3IFxzYmFzZWRvbjAgXHNuZXh0MCBhYnN0 cmFjdDt9e1xzMjNcc2IyODQwXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcYlxmNFxmczM2XGxhbmcx MDM2XGNncmlkIFxzYmFzZWRvbjAgXHNuZXh0MjAgdGl0bGU7fXtcczI0XHdpZGN0bHBhcg0KXHRx Y1x0eDQzMjBcdHFyXHR4ODY0MFxhZGp1c3RyaWdodCBcc2hhZFxmOFxmczIwXGxhbmcxMDI0XGNn cmlkIFxzYmFzZWRvbjAgXHNuZXh0MjQgZm9vdGVyO317XHMyNVx3aWRjdGxwYXJcYWRqdXN0cmln aHQgXGYyXGZzMjBcY2dyaWQgXHNiYXNlZG9uMCBcc25leHQyNSBQbGFpbiBUZXh0O317XCpcY3My NiBcYWRkaXRpdmUgXHVsXGNmMiBcc2Jhc2Vkb24xMCBIeXBlcmxpbms7fX17XGluZm8NCntcdGl0 bGUgSGVyZWFmdGVyIHdoYXQgY2FuIEkgZ2dlc3QgeW91IGZvciBFSUFcJzkyOTggcHJvZ3JhbW1l fXtcYXV0aG9yIFpyZWlrfXtcb3BlcmF0b3IgYnJhbi1jaTB9e1xjcmVhdGltXHlyMTk5OFxtbzEw XGR5MjFcaHIxNFxtaW4yNX17XHJldnRpbVx5cjE5OThcbW8xMFxkeTIyXGhyMTR9e1xwcmludGlt XHlyMTk5OFxtbzEwXGR5MjFcaHIxMlxtaW4zMH17XHZlcnNpb24xNX17XGVkbWluczEzMX17XG5v ZnBhZ2VzOH0NCntcbm9md29yZHMxMjk3fXtcbm9mY2hhcnM3Mzk2fXtcKlxjb21wYW55IEJ1cmVh dXRpcXVlfXtcbm9mY2hhcnN3czB9e1x2ZXJuODl9fVxwYXBlcncxMTkwNlxwYXBlcmgxNjgzOFxt YXJnbDE0MTdcbWFyZ3IxNDE3XG1hcmd0MTQxN1xtYXJnYjE0MTcgXGRlZnRhYjcwOFx3aWRvd2N0 cmxcZnRuYmpcYWVuZGRvY1xoeXBoaG90ejQyNVxoeXBoY2FwczBcZm9ybXNoYWRlXHZpZXdraW5k NFx2aWV3c2NhbGUxMDBccGdicmRyaGVhZFxwZ2JyZHJmb290IA0KXGZldDBcc2VjdGQgXGxpbmV4 MFxoZWFkZXJ5NzA5XGZvb3Rlcnk3MDlcY29sc3g3MDlcZW5kbmhlcmVcc2VjdGRlZmF1bHRjbCB7 XCpccG5zZWNsdmwxXHBudWNybVxwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmd7XHBudHh0YSAu fX17XCpccG5zZWNsdmwyXHBudWNsdHJccG5zdGFydDFccG5pbmRlbnQ3MjBccG5oYW5ne1xwbnR4 dGEgLn19e1wqXHBuc2VjbHZsM1xwbmRlY1xwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmd7XHBu dHh0YSAufX0NCntcKlxwbnNlY2x2bDRccG5sY2x0clxwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhh bmd7XHBudHh0YSApfX17XCpccG5zZWNsdmw1XHBuZGVjXHBuc3RhcnQxXHBuaW5kZW50NzIwXHBu aGFuZ3tccG50eHRiICh9e1xwbnR4dGEgKX19e1wqXHBuc2VjbHZsNlxwbmxjbHRyXHBuc3RhcnQx XHBuaW5kZW50NzIwXHBuaGFuZ3tccG50eHRiICh9e1xwbnR4dGEgKX19e1wqXHBuc2VjbHZsN1xw bmxjcm1ccG5zdGFydDFccG5pbmRlbnQ3MjBccG5oYW5nDQp7XHBudHh0YiAofXtccG50eHRhICl9 fXtcKlxwbnNlY2x2bDhccG5sY2x0clxwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmd7XHBudHh0 YiAofXtccG50eHRhICl9fXtcKlxwbnNlY2x2bDlccG5sY3JtXHBuc3RhcnQxXHBuaW5kZW50NzIw XHBuaGFuZ3tccG50eHRiICh9e1xwbnR4dGEgKX19XHBhcmRccGxhaW4gXHMyXHFjXGtlZXBuXHdp ZGN0bHBhclxvdXRsaW5lbGV2ZWwxXGFkanVzdHJpZ2h0IFxiXGlcZjRcbGFuZzEwMzZcY2dyaWQg ew0KXGYxXGZzNDQgRVVST1BJQSBccnF1b3RlIDk4ICA6IENZQkVSREVTSUdODQpccGFyIH1ccGFy ZFxwbGFpbiBccWNcd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxmNFxsYW5nMTAzNlxjZ3JpZCB7XGJc aVxmMVxmczM2IE1lZGlhLCBDb21tdW5pY2F0aW9uICYgRGVzaWduIFByYWN0aWNlDQpccGFyIH17 XGJcZjFcZnMzNiBNZWRpYSAmIENvbW11bmljYXRpb24gZGFucyBsYSBQcmF0aXF1ZSBkZSBsYSBD b25jZXB0aW9uDQpccGFyIH1ccGFyZCBcd2lkY3RscGFyXGFkanVzdHJpZ2h0IHtcaVxmMVxmczM2 IA0KXHBhciB9XHBhcmQgXHFjXHdpZGN0bHBhclxhZGp1c3RyaWdodCB7XGlcZjEgU2V2ZW50aCBJ bnRlcm5hdGlvbmFsIENvbmZlcmVuY2Ugb24gdGhlIEFwcGxpY2F0aW9uL0ltcGxpY2F0aW9ucyBv ZiBDb21wdXRlciBOZXR3b3JraW5nIGluIEFyY2hpdGVjdHVyZSwgQ29uc3RydWN0aW9uLCBEZXNp Z24sIENpdmlsIEVuZ2luZWVyaW5nIGFuZCBVcmJhbiBQbGFubmluZw0KXHBhciB9e1xmMSANClxw YXIgU2VwdGlcJ2U4bWUgQ29sbG9xdWUgSW50ZXJuYXRpb25hbCBzdXIgbGVzIGFwcGxpY2F0aW9u cyBldCBsZXMgaW1wbGljYXRpb25zIGRlcyBub3V2ZWxsZXMgdGVjaG5vbG9naWVzIGRlIGwnaW5m b3JtYXRpb24gZXQgZGUgbGEgY29tbXVuaWNhdGlvbiBlbiBBcmNoaXRlY3R1cmUsIENvbnN0cnVj dGlvbiBldCBlbiBQbGFuaWZpY2F0aW9uIFVyYmFpbmV9e1xmMVxmczI4IA0KXHBhciB9e1xiXGYx XGZzMjggDQpccGFyIH17XGJcaVxmMSBPcmdhbmlzZWQgYnl9e1xiXGYxICAvIE9yZ2FuaXNcJ2U5 IHBhcjoNClxwYXIgVW5pdmVyc2l0eSBvZiBQYWlzbGV5IDogRGVwYXJ0bWVudCBvZiBDb21wdXRp bmcgYW5kIEluZm9ybWF0aW9uIFN5c3RlbQ0KXHBhciBVbml2ZXJzaXRcJ2U5IGRlIENhZW4gOiBD LkEuRS5OIChHUkVZQywgTVJTSCkNClxwYXIgUFwnZjRsZSBVbml2ZXJzaXRhaXJlIExcJ2U5b25h cmQgRGUgVmluY2kgOiBJRkFNSUYsIFBhcmlzIGxhIERcJ2U5ZmVuc2UNClxwYXIgRXVyb3BpYSBQ cm9kdWN0aW9ucywgUGFyaXN9e1xiXGYxXGZzMzIgDQpccGFyIA0KXHBhciB9e1xiXGlcZjEgDQpc cGFyIFBBUklTIDogMjUsIDI2LCAyNyBOT1ZFTUJFUg0KXHBhciB9e1xmMVxmczMyXHVsIFBcJ2Y0 bGUgVW5pdmVyc2l0YWlyZSBMXCdlOW9uYXJkIGRlIFZpbmNpDQpccGFyIFBhcmlzIGxhIERcJ2U5 ZmVuc2UNClxwYXIgfVxwYXJkIFx3aWRjdGxwYXJcYWRqdXN0cmlnaHQge1xmMSANClxwYXIgfVxw YXJkXHBsYWluIFxzMVxrZWVwblx3aWRjdGxwYXJcb3V0bGluZWxldmVsMFxhZGp1c3RyaWdodCBc YlxmNFx1bFxsYW5nMTAzNlxjZ3JpZCB7XGlcZjEgV2VkbmVzZGF5IDI1LzExLzE5OTggfXtcZjEg LyBNZXJjcmVkaSAyNSBOb3ZlbWJyZSAxOTk4fXtcaVxmMSANClxwYXIgfVxwYXJkXHBsYWluIFx3 aWRjdGxwYXJcYWRqdXN0cmlnaHQgXGY0XGxhbmcxMDM2XGNncmlkIHtcaVxmMSANClxwYXIgfVxw YXJkXHBsYWluIFxzMVxrZWVwblx3aWRjdGxwYXJcb3V0bGluZWxldmVsMFxhZGp1c3RyaWdodCBc YlxmNFx1bFxsYW5nMTAzNlxjZ3JpZCB7XGlcZjEgT3Blbm5pbmcgU2Vzc2lvbiAvIH17XGYxIE91 dmVydHVyZSBkdSBDb2xsb3F1ZSAtIFZpZGVvIENvbmZlcmVuY2V9e1xpXGYxIA0KXHBhciB9XHBh cmRccGxhaW4gXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcZjRcbGFuZzEwMzZcY2dyaWQge1xmMSAN ClxwYXIgfXtcZjFcZnMyMCA5aDAwIC0gOWgxNSBcdGFiIERyLiB9e1xiXGYxXGZzMjAgQ2hlcmlm IEJSQU5LSX17XGYxXGZzMjAgLCBVbml2ZXJzaXR5IG9mIFBhaXNsZXksIEVJQVxycXVvdGUgOTgg Q2hhaXJtYW4NClxwYXIgDQpccGFyIDloIDE1IC0gOWg0NSBcdGFiIE0uIH17XGJcZjFcZnMyMCBS aWNoYXJkIFNIQVd9e1xmMVxmczIwICwgUHJvZmVzc29yLCBQcmluY2lwYWwgb2YgVGhlIFVuaXZl cnNpdHkgb2YgUGFpc2xleQ0KXHBhciANClxwYXIgfVxwYXJkXHBsYWluIFxzMTVcd2lkY3RscGFy XGFkanVzdHJpZ2h0IFxiXGY0XHVsXGxhbmcxMDM2XGNncmlkIHtcYjBcZjFcZnMyMFx1bG5vbmUg OWggNDUgLSAxMGgwNSBcdGFiIE0uIH17XGYxXGZzMjBcdWxub25lIE1pY2hlbCBCQVJBVH17XGIw XGYxXGZzMjBcdWxub25lICwgRGlyZWN0ZXVyIEdcJ2U5blwnZTlyYWwgZHUgUFwnZjRsZSBVbml2 ZXJzaXRhaXJlIExcJ2U5b25hcmQgZGUgVmluY2kNClxwYXIgDQpccGFyIDEwaDA1IC0gMTBmMTUg XHRhYiBNLiB9e1xmMVxmczIwXHVsbm9uZSBDaHJpc3RpYW4gU0FOREVSfXtcYjBcZjFcZnMyMFx1 bG5vbmUgLCBEaXJlY3RldXIgZGUgbCdJRkFNSUYNClxwYXIgDQpccGFyIH17XGYxXGZzMjBcdWxu b25lIDEwaDE1IC0gMTBoNDVcdGFiIH17XGlcZjFcZnMyMFx1bG5vbmUgSW52aXRlZCBTcGVha2Vy IC99e1xmMVxmczIwXHVsbm9uZSAgQ29uZlwnZTlyZW5jZSBpbnZpdFwnZTllDQpccGFyIH17XGIw XGYxXGZzMjBcdWxub25lIE0uIE0uIExcJ2U5Z2xpc2UsIFByb2Zlc3NldXIsIEVjb2xlIGQnQXJj aGl0ZWN0dXJlIGRlIFRvdWxvdXNlDQpccGFyIH17XGlcZjFcZnMyMFx1bG5vbmUgQ29uc3RpdHV0 aW9uIGQndW5lIG1cJ2U5bW9pcmUgcGVyc29ubmVsbGUgXCdlMCBwYXJ0aXIgZGUgcmVwclwnZTlz ZW50YXRpb25zIGRpc3NcJ2U5bWluXCdlOWVzLiANClxwYXIgfXtcYjBcZjFcZnMyMFx1bG5vbmUg DQpccGFyIH17XGIwXGYxXHVsbm9uZSAxMGg0NSAtIDExaDE1IH17XGIwXGlcZjEgQ29mZmVlIEJy ZWFrfXtcYjBcZjEgIC8gfXtcYjBcZjFcdWxub25lIFBhdXNlIENhZlwnZTl9e1xmMSANClxwYXIg DQpccGFyIFNFU1NJT04gSVx+fXtcYjBcZjEgKH17XGIwXGlcZjEgU2hvcnQgcGFwZXJzfXtcYjBc ZjEgIC8gY29tbXVuaWNhdGlvbnMgY291cnRlcyA6IDExaDE1IC0gMTJoMzApDQpccGFyIH17XGlc ZjFcdWxub25lIENZQkVSIERFU0lHTiBFTlZJUk9OTUVOVCBWUyBSRUFMIERFU0lHTiBFTlZJUk9O TUVOVCANClxwYXIgfVxwYXJkXHBsYWluIFx3aWRjdGxwYXJcYWRqdXN0cmlnaHQgXGY0XGxhbmcx MDM2XGNncmlkIHtcZjEgDQpccGFyIE0uIENyb3dlLCAgUy4gS3lkZA0KXHBhciBVbml2ZXJzaXR5 IG9mIFBhaXNsZXksIFVLDQpccGFyIH17XGJcaVxmMSBBZ2VudHMgYW5kIHN1Z2dlc3Rpb25zIGlu IGEgV2ViLWJhc2VkIGR5bmFtaWMgd29ya2Zsb3cgbW9kZWwuDQpccGFyIH17XGYxIA0KXHBhciBO LiBCYXVwaW4gJiAgSy4gWnJlaWsNClxwYXIgQ05FVCwgQ2FlbiwgVW5pdmVyc2l0eSBvZiBDYWVu LCBGcmFuY2UNClxwYXIgfXtcYlxpXGYxIFRcJ2U5bFwnZTlkZWNpc2lvbjogTi5ULkkuQy4gZXQg Y29uY2VwdGlvbiBjb29wZXJhdGl2ZS4NClxwYXIgfXtcZjEgDQpccGFyIE0uIENsYXl0b24NClxw YXIgVGV4YXMgQSZNIFVuaXZlcnNpdHksIFVTQQ0KXHBhciB9e1xiXGlcZjEgRGlzdHJpYnV0ZWQg ZGVzaWduIGtub3dsZWRnZSB1c2luZyBmb3JtLCBmdW5jdGlvbiBhbmQgYmVoYXZpb3VyDQpccGFy IH17XGYxIA0KXHBhciB9XHBhcmRccGxhaW4gXHMxNlxxalx3aWRjdGxwYXJcYWRqdXN0cmlnaHQg XGY0IHtcY3MxN1xmMSBZLiBSZXplDQpccGFyIFVuaXZlcnNpdFwnZTkgb2YgQ2FlbiwgRnJhbmNl LA0KXHBhciB9XHBhcmRccGxhaW4gXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcZjRcbGFuZzEwMzZc Y2dyaWQge1xiXGlcZjEgTCdoeXBlcm1lZGlhOiB1bmUgYXV0cmUgZmFjb24gZGUgcmVwcmVzZW50 ZXIuDQpccGFyIH17XGYxIA0KXHBhciB9XHBhcmRccGxhaW4gXHMxOFxzbDI0MFxzbG11bHQwXHdp ZGN0bHBhclxhZGp1c3RyaWdodCBcYlxmNFxjZjFcY2dyaWQge1xiMFxmMSBDLiBERVNIQVlFUw0K XHBhciB9XHBhcmRccGxhaW4gXHMxOVxzbDI0MFxzbG11bHQwXHdpZGN0bHBhclxhZGp1c3RyaWdo dCBcaVxmNFxmczIwXGNmMVxjZ3JpZCB7XGkwXGYxXGZzMjQgRWNvbGUgZCdBcmNoaXRlY3R1cmUg ZGUgUGFyaXMtVmFsLURlLU1Bcm5lLCBGcmFuY2UNClxwYXIgfVxwYXJkXHBsYWluIFx3aWRjdGxw YXJcYWRqdXN0cmlnaHQgXGY0XGxhbmcxMDM2XGNncmlkIHtcYlxpXGYxIFBlcmNlcHRpb24gc3Bh dGlhbGUgZCd1biBlbnZpcm9ubWVudCBhcmNoaXRlY3R1cmFsOiBhc3BlY3RzDQpccGFyIGluZm9y bWF0aW9ubmVsIGV0IGNvbW11bmljYXRpb25uZWwuDQpccGFyIH17XGYxIA0KXHBhciANClxwYXIg fVxwYXJkXHBsYWluIFxzMTVcd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxiXGY0XHVsXGxhbmcxMDM2 XGNncmlkIHtcZjEgU0VTU0lPTiBJSVx+fXtcYjBcZjEgKH17XGIwXGlcZjEgU2hvcnQgcGFwZXJz fXtcYjBcZjEgIC8gY29tbXVuaWNhdGlvbnMgY291cnRlcyA6IDE0aDAwIC0gMTVoMTUpDQpccGFy IH1ccGFyZFxwbGFpbiBcczFca2VlcG5cd2lkY3RscGFyXG91dGxpbmVsZXZlbDBcYWRqdXN0cmln aHQgXGJcZjRcdWxcbGFuZzEwMzZcY2dyaWQge1xpXHVsbm9uZSBXRUIgQkFTRUQgREVTSUdODQpc cGFyIH1ccGFyZFxwbGFpbiBcd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxmNFxsYW5nMTAzNlxjZ3Jp ZCB7XGJcY2FwcyBJbnRlcm5ldCBkYW5zIGxhIHByYXRpcXVlIGRlIGxhIGNvbmNlcHRpb259ew0K XHBhciB9XHBhcmRccGxhaW4gXHMyMFxzYjI0MFx3aWRjdGxwYXJcYWRqdXN0cmlnaHQgXGJcZjRc ZnMyOFxsYW5nMjA1NyB7XGIwXGYxXGZzMjQgTi4gS2FyYWNhcGlsaWRpcywgTy4gQWJvdSBLaGFs ZWQNClxwYXIgfVxwYXJkXHBsYWluIFxzMjFccWpcc2wzMDBcc2xtdWx0MFx3aWRjdGxwYXJcYWRq dXN0cmlnaHQgXGY0XGxhbmcyMDU3IHtcaVxmMSBFUEZMLCBTd2l0emVybGFuZH17XGlcZjFcZnMy MCANClxwYXIgfVxwYXJkXHBsYWluIFx3aWRjdGxwYXJcYWRqdXN0cmlnaHQgXGY0XGxhbmcxMDM2 XGNncmlkIHtcYlxpXGYxIEVzdGFibGlzaGluZyBjb21tdW5pY2F0aW9uIGJldHdlZW4gYSB3ZWIt YmFzZWQgYXJndW1lbnRhdGlvbg0KXHBhciBhbmQgcmVtb3RlIGRhdGFiYXNlcw0KXHBhciB9e1xm MSANClxwYXIgfVxwYXJkXHBsYWluIFxzMTZcd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxmNCB7XGYx XGxhbmcxMDM2XGNncmlkIEYuIEFtZXppYW5lLCBTLiBMYXNzZXJyZQ0KXHBhciB9XHBhcmRccGxh aW4gXHMyMVxxalxzbDMwMFxzbG11bHQwXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcZjRcbGFuZzIw NTcge1xmMSBFY29sZSBkXHJxdW90ZSBBcmNoaXRlY3R1cmUgZGUgTWFyc2VpbGxlICwgRnJhbmNl DQpccGFyIH1ccGFyZFxwbGFpbiBcczE2XHdpZGN0bHBhclxhZGp1c3RyaWdodCBcZjQge1xiXGlc ZjEgQnVpbGRpbmcgaW5mb3JtYXRpb24gaW4gY29vcGVyYXRpdmUgcHJvZHVjdGlvbiBjb250ZXh0 DQpccGFyIH1ccGFyZFxwbGFpbiBcd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxmNFxsYW5nMTAzNlxj Z3JpZCB7XGYxIA0KXHBhciBNLiBCb3ViZWtyaQ0KXHBhciB9XHBhcmRccGxhaW4gXHMyNFx3aWRj dGxwYXJcYWRqdXN0cmlnaHQgXHNoYWRcZjhcZnMyMFxsYW5nMTAyNFxjZ3JpZCB7XHNoYWQwXGYx XGZzMjRcbGFuZzEwMzMgVW5pdmVyc2l0eSBvZiBJbGxpbm9pcywgVVNBDQpccGFyIH1ccGFyZFxw bGFpbiBcd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxmNFxsYW5nMTAzNlxjZ3JpZCB7XGJcaVxmMSBD b21wdXRlciBOZXR3b3JraW5nIGFuZCBMaWdodGluZyBEZXNpZ24gSW5zdHJ1Y3Rpb24uDQpccGFy IH17XGYxIA0KXHBhciBHLiBWYXNxdWV6IGRlIFZlbGFzY28sIE4uIEhvbGxhbmQNClxwYXIgVGV4 YXMgQSZNIFVuaXZlcnNpdHksIFVTQQ0KXHBhciB9e1xiXGlcZjEgQ29tcHV0ZXIgbWVkaWF0ZWQg cmVjaXByb2NhbCBkaXN0YW5jZSBlZHVjYXRpb24uDQpccGFyIH17XGYxIA0KXHBhciBQLiBWYW4g ZGVyIFZlZXIsIEkuUy5TYXJpeWlsZGl6LCB9e1wnZDZ9e1xmMSAuIENpZnRjaW9nbHUNClxwYXIg fVxwYXJkXHBsYWluIFxzMTZcbm93aWRjdGxwYXJcdHgxNDJcYWRqdXN0cmlnaHQgXGY0IHtcZjFc ZXhwbmQtNFxleHBuZHR3LTIwXGxhbmcxMDM2XGNncmlkIERlbGZ0IFVuaXZlcnNpdHkgb2YgVGVj aG5vbG9neSwgVGhlIE5ldGhlcmxhbmRzDQpccGFyIH1ccGFyZFxwbGFpbiBcd2lkY3RscGFyXGFk anVzdHJpZ2h0IFxmNFxsYW5nMTAzNlxjZ3JpZCB7XGJcaVxmMSBPcmRlcmluZyBvZiBJbmZvcm1h dGlvbiBhbmQgRnVuY3Rpb25hbGl0eSBmb3IgZGVjaXNpb24gc3VwcG9ydCBpbg0KXHBhciBidWls ZGluZyBkZXNpZ24ufXtcZjEgDQpccGFyIA0KXHBhciB9XHBhcmRccGxhaW4gXHMzXGtlZXBuXHdp ZGN0bHBhclxvdXRsaW5lbGV2ZWwyXGFkanVzdHJpZ2h0IFxiXGY0XGxhbmcxMDM2XGNncmlkIHtc ZjEgUE9TVEVSUyAmIFJhZnJhXCdlZWNoaXNzZW1lbnQgKDE1aDE1IC0gMTdoMTUpDQpccGFyIH1c cGFyZFxwbGFpbiBcd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxmNFxsYW5nMTAzNlxjZ3JpZCB7XGYx IA0KXHBhciB9XHBhcmRccGxhaW4gXHMxXGtlZXBuXHdpZGN0bHBhclxvdXRsaW5lbGV2ZWwwXGFk anVzdHJpZ2h0IFxiXGY0XHVsXGxhbmcxMDM2XGNncmlkIHtcaVxmMSBUSFVTREFZIDI2LzExLzE5 OTh9e1xmMSAgLyBKZXVkaSAyNiBOb3ZlbWJyZSAxOTk4DQpccGFyIH1ccGFyZFxwbGFpbiBcd2lk Y3RscGFyXGFkanVzdHJpZ2h0IFxmNFxsYW5nMTAzNlxjZ3JpZCB7XGYxIA0KXHBhciANClxwYXIg fVxwYXJkXHBsYWluIFxzMVxrZWVwblx3aWRjdGxwYXJcb3V0bGluZWxldmVsMFxhZGp1c3RyaWdo dCBcYlxmNFx1bFxsYW5nMTAzNlxjZ3JpZCB7XGYxIFNFU1NJT04gSUlJXH46ICAoOWgwMCAtIDEw aDMwKQ0KXHBhciB9e1xpXGYxXHVsbm9uZSBPTiBMSU5FIERJU1RSSUJVVEVEIERFU0lHTiBFTlZJ Uk9OTUVOVA0KXHBhciB9XHBhcmRccGxhaW4gXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcZjRcbGFu ZzEwMzZcY2dyaWQge1xiXGNhcHNcZjEgRW52aXJvbm5lbWVudCBkeW5hbWlxdWUgcG91ciBsYSBj b25jZXB0aW9uIGNvb3BcJ2U5cmF0aXZlDQpccGFyIH17XGYxIA0KXHBhciBSLiBDb3luZSwgSi4g TGVlLCBELiBEdW5jYW4sIFMuIE9mbHVvZ2x1DQpccGFyIFVuaXZlcnNpdHkgb2YgRWRpbmJ1cmdo LCBVSw0KXHBhciB9e1xiXGlcZjEgQXBwbHlpbmcgd2ViLWJhc2VkIHByb2R1Y3QgbGlicmFyaWVz Lg0KXHBhciB9e1xmMSANClxwYXIgDQpccGFyIEwuIE1hcnRpbiwgVGhlIEplcmRlIFBhcnRuZXJz aGlwIEludGVybmF0aW9uYWwgSW5jLiwgVVNBIH17XGJcaVxmMSANClxwYXIgQXJjaGl0ZWN0dXJl IGluIGRpZ2l0YWwgZG9tYWluOiBmcm9tIGFyY3RpYyBpbWFnZXMgdG8gZGVzZXJ0DQpccGFyIGRy ZWFtbGFuZHMuDQpccGFyIH17XGYxIA0KXHBhciBCYXJrb3dza2ksIEMuIEJyYW5raSwgRS4gR3Jh YnNrYSwgVy4gUGFsYWN6DQpccGFyIFVuaXZlcnNpdHkgb2YgUGFpc2xleSwgVS5LLiwgSUZUUlMs IFBvbGFuZCwgSUNTLCBQb2xhbmQNClxwYXIgfXtcYlxpXGYxIFRvd2FyZHMgY29sbGFib3JhdGl2 ZSBkc2VpZ24uDQpccGFyIH17XGYxIA0KXHBhciB9e1xpXGYxIDEwaDMwIC0gMTFoMDAgQ29mZmVl IEJyZWFrfXtcZjEgIC8gcGF1c2UgQ2FmXCdlOQ0KXHBhciANClxwYXIgfVxwYXJkXHBsYWluIFxz MVxrZWVwblx3aWRjdGxwYXJcb3V0bGluZWxldmVsMFxhZGp1c3RyaWdodCBcYlxmNFx1bFxsYW5n MTAzNlxjZ3JpZCB7XGYxIFNFU1NJT05cfklWOiAoMTFoMDAtMTNoMDApDQpccGFyIH17XGlcZjFc dWxub25lIERBVEEgQUNRVUlTSVRJT04gQ1lCRVJTUEFDRQ0KXHBhciB9XHBhcmRccGxhaW4gXHdp ZGN0bHBhclxhZGp1c3RyaWdodCBcZjRcbGFuZzEwMzZcY2dyaWQge1xiXGNhcHNcZjEgQ3liZXIt RXNwYWNlcyBwb3VyIGwnYWNxdWlzaXRpb24gZGVzIGRvbm5cJ2U5ZXMgZW4gY29uY2VwdGlvbg0K XHBhciB9e1xmMSANClxwYXIgUC4gTWNJbnRvc2gsIEFyaXpvbmEgU3RhdGUgVW5pdmVyc2l0eSwg VVNBDQpccGFyIH17XGJcaVxmMSBLbm93bGVkZ2UgYWNxdWlzaXRpb24gdXNpbmcgVlJNTCBhbmQg dW5pZmllZCBtb2RlbGluZyBsYW5ndWFnZTogdGhlIGNhc2Ugb2YgdGhlIFJHQiBjb21wdXRlciBy b29tLg0KXHBhciB9e1xmMSANClxwYXIgQS4gUm91c3NlbCAmIEsuIFpyZWlrDQpccGFyIENORVQs IENhZW4sIFVuaXZlcnNpdHkgb2YgQ2FlbiwgRnJhbmNlDQpccGFyIH17XGJcaVxmMSBMYSBzdXBl cmNoYXJnZSBcJ2U5bGVjdHJvbmlxdWUgZW4gY29uY2VwdGlvbiAiTGUgUHJvamV0IEJBTEkiDQpc cGFyIH17XGYxIA0KXHBhciBILiBBaW5zbGV5LCBDLiBHaGFvdWkNClxwYXIgTGl2ZXJwb29sIEpv aG4gTW9vcmVzIFVuaXZlcml0eSwgVS5LLg0KXHBhciB9e1xiXGlcZjEgU3RydWN0dXJpbmcgaHlw ZXJtZWRpYSBsZWFybmluZyBtYXRlcmlhbCB0byBjb21tdW5pY2F0ZSBrbm93bGVkZ2UuDQpccGFy IH17XGYxIA0KXHBhciBFLiBIZW5yeSwgRC4gQm9pc3NpZXIsIEMuIEJvdWxlbWlhDQpccGFyIExB TUgsIENVU1QsIExBTUgsIEZyYW5jZQ0KXHBhciB9e1xiXGlcZjEgQWNxdWlzaXRpb24gZXQgZXh0 cmFjdGlvbiBkZXMgY29ubmFpc3NhbmNlcyBwb3VyIGxhIGdlbmVyYXRpb24gZGUgc3lzdGVtZXMg ZGUgZm9uZGF0aW9ucyBkZSBiYXRpbWVudHMuDQpccGFyIH17XGYxIA0KXHBhciANClxwYXIgfVxw YXJkXHBsYWluIFxzMVxrZWVwblx3aWRjdGxwYXJcb3V0bGluZWxldmVsMFxhZGp1c3RyaWdodCBc YlxmNFx1bFxsYW5nMTAzNlxjZ3JpZCB7XGYxIFNFU1NJT04gViA6IDE0aDMwIC0gMTZoMDANClxw YXIgfXtcaVxmMVx1bG5vbmUgQ1lCRVJERVNJR04gU09DSUFMIEZFQVRVUkVTDQpccGFyIH1ccGFy ZFxwbGFpbiBcd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxmNFxsYW5nMTAzNlxjZ3JpZCB7XGJcY2Fw cyBDeWJlckNvbmNlcHRpb24gOiBhc3BlY3Qgc29jaWFsDQpccGFyIH17DQpccGFyIH17XGYxIEMu IFR3ZWVkDQpccGFyIFRoZSBRdWVlbidzIFVuaXZlcnNpdHkgb2YgQmVsZmFzdCwgTm9ydGhlcm4g SXJlbGFuZA0KXHBhciB9e1xiXGlcZjEgRGV2ZWxvcGluZyBhbiB1bmRlcnN0YW5kaW5nIG9mIHRo ZSBzb2NpYWwgY29udGV4dCBvZiBDQUFEIGluIHByYWN0aWNlLg0KXHBhciB9e1xmMSANClxwYXIg TS4gQ3Jvd2UsIFMuIEt5ZGQNClxwYXIgVW5pdmVyc2l0eSBvZiBQYWlzbGV5LCBVLksuDQpccGFy IH17XGJcaVxmMSBEZWxlZ2F0aW9uIGFuZCBpbnRlcmZlcmVuY2U6IHRoZSBwZXJzb25hbCB3b3Jr c3RhdGlvbiBhbmQgdGhlDQpccGFyIGNvcnBvcmF0ZSBuZXR3b3JrLg0KXHBhciB9e1xmMSANClxw YXIgTS4gU215dGgNClxwYXIgTmFwaWVyIFVuaXZlcnNpdHksIFUuSy4NClxwYXIgfXtcYlxpXGYx IFRoZSBhY3Rpdml0eSBvZiBkZXNpZ24gYXMgcmV2ZWFsZWQgYnkgdG9vbCB1c2FnZS4NClxwYXIg fXtcZjEgDQpccGFyIH17XGlcZjEgMTZoMDAgLSAxNmgzMCBDb2ZmZWUgQnJlYWt9e1xmMSAgLyBw YXVzZSBDYWZcJ2U5DQpccGFyIA0KXHBhciB9XHBhcmRccGxhaW4gXHMxXGtlZXBuXHdpZGN0bHBh clxvdXRsaW5lbGV2ZWwwXGFkanVzdHJpZ2h0IFxiXGY0XHVsXGxhbmcxMDM2XGNncmlkIHtcZjEg U0VTU0lPTiBWSVx+OiAoMTZoMzAgLSAxOGgwMCkNClxwYXIgfXtcZjFcdWxub25lIENZQkVSIEFS Q0hJVEVDVFVSQUwgREVTSUdOIExBTkdVQUdFUw0KXHBhciB9XHBhcmRccGxhaW4gXHdpZGN0bHBh clxhZGp1c3RyaWdodCBcZjRcbGFuZzEwMzZcY2dyaWQge1xiXGNhcHNcZjEgTGFuZ2FnZXMgZGUg bGEgY3liZXJjb25jZXB0aW9uIGFyY2hpdGVjdHVyYWxlDQpccGFyIH17XGYxIA0KXHBhciBBLlYu IE1vZXJlLCBILiBOZXVrZXJtYW5zLCBBLkhleWxpZ2hlbg0KXHBhciBLLlUuIExldXZlbiwgQmVs Z2lxdWUNClxwYXIgfXtcYlxpXGYxIFRoZSBsYW5ndWFnZSBvZiBDeWJlcnNwYWNlOiBhbiBhcmNo aXRlY3R1cmFsIGFwcHJvYWNoLg0KXHBhciB9e1xmMSANClxwYXIgUC4gU3phbGFwYWosIEQuIENo YW5nDQpccGFyIFVuaXZlcnNpdHkgb2YgU2hlZmZpZWxkLCBVLksuDQpccGFyIH17XGJcaVxmMSBD b21wdXRlciBBcmNoaXRlY3R1cmFsIFByZXNlbnRhdGlvbiAtIGZyb20gcGh5c2ljYWwgbW9kZWxz IGluIHNwYWNlIHRvIHZpcnR1YWwgbW9kZWxzIGluIGN5YmVyc3BhY2UuDQpccGFyIH17XGYxIA0K XHBhciBBLkJyaWRnZXMsIFQuRGltaXRyaW9zDQpccGFyIFVuaXZlcnNpdHkgb2YgU3RyYXRoY2x5 ZGUsIFUuSy4NClxwYXIgfXtcYlxpXGYxIFRoZSBpbXBhY3Qgb2YgZm9ybSBvbiBtb3ZlbWVudCB3 aXRoaW4gdmlydHVhbCBlbnZpcm9ubWVudHMuDQpccGFyIH17XGYxIA0KXHBhciANClxwYXIgDQpc cGFyIH1ccGFyZFxwbGFpbiBcczFca2VlcG5cd2lkY3RscGFyXG91dGxpbmVsZXZlbDBcYWRqdXN0 cmlnaHQgXGJcZjRcdWxcbGFuZzEwMzZcY2dyaWQge1xpXGYxIEZyaWRheSAyNy8xMS8xOTk4fXtc ZjEgIC8gVmVuZHJlZGkgMjcgTm92ZW1iZXIgMTk5OA0KXHBhciANClxwYXIgfVxwYXJkXHBsYWlu IFx3aWRjdGxwYXJcYWRqdXN0cmlnaHQgXGY0XGxhbmcxMDM2XGNncmlkIHtcZjEgDQpccGFyIH1c cGFyZFxwbGFpbiBcczFca2VlcG5cd2lkY3RscGFyXG91dGxpbmVsZXZlbDBcYWRqdXN0cmlnaHQg XGJcZjRcdWxcbGFuZzEwMzZcY2dyaWQge1xmMSBTRVNTSU9OIFZJSVx+OiAoOWgwMCAtIDEwaDMw KQ0KXHBhciB9e1xpXGYxXHVsbm9uZSBDWUJFUiBERVNJR04gREVDSVNJT04gU1VQUE9SVA0KXHBh ciB9XHBhcmRccGxhaW4gXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcZjRcbGFuZzEwMzZcY2dyaWQg e1xiXGNhcHNcZjEgQ3liZXIgZW52aXJvbm5lbWVudCBkJ2FpZGUgXCdlMCBsYSBEXCdlOWNpc2lv biBlbiBDb25jZXB0aW9uDQpccGFyIH17XGYxIA0KXHBhciBSLiBCZWhlc2h0aSwgUi4gTWljaGVs cw0KXHBhciBULlUuRGVsZnQsIHRoZSBOZXRoZXJsYW5kcw0KXHBhciB9e1xiXGlcZjEgVGhlIEds b2JhbCAgR0lTOiBhIGNhc2Ugc3R1ZHkuDQpccGFyIH17XGYxIA0KXHBhciBWLiBTcmRhbm92aWMs IE0uIEpvdmFub3ZpYywgRC4gTGVraWMNClxwYXIgVW5pdmVyc2l0eSBvZiBCZWxncmFkZSwgRi5I LkksIFl1Z29zbGF2aWENClxwYXIgfXtcYlxpXGYxIEFuIGFwcGxpY2F0aW9uIG9mIEdJUyB0ZWNo bm9sb2d5IG9mIGZsb29kIGNvbnRyb2wuDQpccGFyIH17XGYxIA0KXHBhciBOLiBFYmVsLCBKLkcu IEplYW5ub3QsIFkuQS4gUmVraWssIEouUC4gVmFkZXIsIEMuVmFub2lyYmVlaw0KXHBhciBFUEZM LCBTd2l0emVybGFuZA0KXHBhciB9e1xiXGlcZjEgQ0FEQU06IHRvd2FyZHMgYSB3ZWItYmFzZWQg aW5mb3JtYXRpb24gYW5kIGRlY2lzaW9uIHN1cHBvcnQgc3lzdGVtIGZvciBhcHByb3ByaWF0ZW5l c3MgaW4gbWVkaWNpbmUuDQpccGFyIH17XGYxIA0KXHBhciB9e1xpXGYxIDEwaDMwIC0gMTFoMDAg Q29mZmVlIEJyZWFrfXtcZjEgIC8gcGF1c2UgQ2FmXCdlOQ0KXHBhciANClxwYXIgfVxwYXJkXHBs YWluIFxzMVxrZWVwblx3aWRjdGxwYXJcb3V0bGluZWxldmVsMFxhZGp1c3RyaWdodCBcYlxmNFx1 bFxsYW5nMTAzNlxjZ3JpZCB7XGYxIFNFU1NJT05cflZJSUk6ICgxMWgwMC0xMmgzMCkNClxwYXIg fXtcaVxmMVx1bG5vbmUgQ1lCRVIgQ09NTVVOSUNBVElPTg0KXHBhciB9e1xmMVx1bG5vbmUgQ1lC RVIgQ09NTVVOSUNBVElPTg0KXHBhciB9XHBhcmRccGxhaW4gXHdpZGN0bHBhclxhZGp1c3RyaWdo dCBcZjRcbGFuZzEwMzZcY2dyaWQge1xmMSANClxwYXIgUy4gTmV3dG9uLCBKLiBSdXRoZXJmb3Jk DQpccGFyIFVuaXZlcnNpdHkgb2YgV2VzdGVybiBTeWRuZXksIFVuaXZlcnNpdHkgb2YgU3lkbmV5 DQpccGFyIH17XGJcaVxmMSBXaGF0IGZ1dHVyZSBmb3Igb25saW5lIGNvbW11bmljYXRpb24gZGVz aWduPw0KXHBhciB9e1xmMSANClxwYXIgUy5Hcm9zamVhbiwgUC4gRmV4bWVyLCBDLiBCcmFzc2Fj DQpccGFyIFVuaXZlc3JpdFwnZTkgZGUgTmFuY3ksIEZyYW5jZQ0KXHBhciB9e1xiXGlcZjEgQ2Vz ICJvdXRpbHMgcGh5Y2hvbGdpcXVlcyIgYXUgY29ldXIgZHUgcHJvY2Vzc3VzIGRlIGNvbmNlcHRp b24uDQpccGFyIH17XGYxIA0KXHBhciBHLiBWYXNxdWV6LCBFLiBBa2xlbWFuDQpccGFyIFRleGFz IEEmTSBVbml2ZXJzaXR5DQpccGFyIH17XGJcaVxmMSBBIGN1cnJpY3VsdW0gZm9yIHZpcnR1YWwg YXJjaGl0ZWN0dXJlLg0KXHBhciB9e1xmMSANClxwYXIgTS4gRW5nZWxpLCBQLiBTaWJlbmFsZXIN ClxwYXIgQXJjaGl0ZWN0dXJlIGFuZCBDQUFELCBTd2l0emVybGFuZA0KXHBhciB9e1xiXGlcZjEg RGlzY292ZXJpbmcgdGhlIGRpZ2l0YWwgdGVycml0b3J5DQpccGFyIH17XGYxIA0KXHBhciANClxw YXIgfVxwYXJkXHBsYWluIFxzMVxrZWVwblx3aWRjdGxwYXJcb3V0bGluZWxldmVsMFxhZGp1c3Ry aWdodCBcYlxmNFx1bFxsYW5nMTAzNlxjZ3JpZCB7XGYxIFNFU1NJT05cfklYIDogKDE0aDAwIC0g MTVoMzApDQpccGFyIH17XGlcZjFcdWxub25lIENZQkVSIERFU0lHTiBWUyBSRUFMIERFU0lHTg0K XHBhciB9XHBhcmRccGxhaW4gXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcZjRcbGFuZzEwMzZcY2dy aWQge1xiXGNhcHMgQ3liZXJDb25jZXB0aW9uIHZzIENvbmNlcHRpb24NClxwYXIgfXtcYlxjYXBz XGYxIA0KXHBhciB9e1xmMSBKLlAuIEdvdWxldHRlLCBTLiBNYXJxdWVzDQpccGFyIEVjb2xlIGQn QXJjaGl0ZWN0dXJlIGRlIFRvdWxvdXNlLCBGcmFuY2UsIFVGUEUsIEJyYXppbA0KXHBhciB9e1xi XGlcZjEgQmV0d2VlbiByZWFsIGFuZCB2aXJ0dWFsIHdvcmxkczogZGVzaWduIHN0dWRpZXMgaW4g Y3liZXJzcGFjZS4NClxwYXIgfXtcZjEgDQpccGFyIEwuIE1hZHJhem8sIEEuIFdlZGVyDQpccGFy IEUuVC5ILiBadXJpY2gsIFN3aXR6ZXJsYW5kDQpccGFyIH17XGJcaVxmMSBBQUxUTyBvbiB0aGUg aW50ZXJuZXQ6IGFyY2hpdGVjdHVyYWwgYW5hbHlzaXMgYW5kIGNvbmNlcHQgcmVwcmVzZW50YXRp b24gd2l0aCBjb21wdXRlciBtZWRpYS4NClxwYXIgfXtcZjEgDQpccGFyIFkuSy4gS2FuZywgSy5E LiBDaHVuZw0KXHBhciBQdXNhbiBOYXRpb25hbCBVbml2ZXJzaXR5LCBLb3JlYQ0KXHBhciB9e1xi XGlcZjEgTV9OT0Q6IERlc2lnbiBhbmQgYW5hbHlzaXMgb2YgbXVsdGltZWRpYSBuZXdzIG9uIGRl bWFuZCBzeXN0ZW0uDQpccGFyIA0KXHBhciB9e1xmMSBDLiBCcmFzc2FjLCBOLiBHcmVnb3JpLCBQ LiBSZW1vdXNzZW5hcmQNClxwYXIgVW5pdmVyc2l0eSBvZiBOYW5jeSwgRnJhbmNlDQpccGFyIH17 XGJcaVxmMSBUaGUgVXNlciBhcyBhbiBBY3RvciBmb3IgRWR1Y2F0aW9uYWwgTXVsdGltZWRpYSBT b2Z0d2FyZSBEZXNpZ24gUHJvY2Vzcw0KXHBhciB9e1xmMSANClxwYXIgfXtcaVxmMSAxNWgzMCAt IDE2aDAwIENvZmZlZSBCcmVha317XGYxICAvIHBhdXNlIENhZlwnZTkNClxwYXIgDQpccGFyIH1c cGFyZFxwbGFpbiBcczFca2VlcG5cd2lkY3RscGFyXG91dGxpbmVsZXZlbDBcYWRqdXN0cmlnaHQg XGJcZjRcdWxcbGFuZzEwMzZcY2dyaWQge1xmMSBTRVNTSU9OIFhcfjogDQpccGFyIE9OIExJTkUg Q09MTEFCT1JBVElWRSBERVNJR04gDQpccGFyIH1ccGFyZFxwbGFpbiBcd2lkY3RscGFyXGFkanVz dHJpZ2h0IFxmNFxsYW5nMTAzNlxjZ3JpZCB7XGJcY2FwcyBDb25jZXB0aW9uIGNvbGxhYm9yYXRp dmUNClxwYXIgfXtcZjEgDQpccGFyIE0uIEphYmFyDQpccGFyIFVuaXZlcnNpdHkgVGVsZWtvbSwg TWFsYXlzaWENClxwYXIgfXtcYlxpXGYxIERlc2lnbiBJbnNwZWN0b3IgYW5kIGNvbnN0cmFpbnQg aW50ZXJwb2xhdG9yIGluIGFzc2VtYmxlLWRpc2Fzc2VtYmxlIGNvbGxhYm9yYXRpdmUgZGVzaWdu IGZvciB0aGUgd29ybGQgd2lkZSBtYW51ZmFjdHVyaW5nIHdlYi4NClxwYXIgfXtcZjEgDQpccGFy IEMuIEJyYW5raSwgQi4gTGVlcywgQWlyZA0KXHBhciBVbml2ZXJzaXR5IG9mIFBhaXNsZXksIFUu Sy4NClxwYXIgfXtcYlxpXGYxIFRyYWNpbmcgV2ViIEJhc2VkIERlc2lnbiBDb25jZXJucw0KXHBh ciB9e1xmMSANClxwYXIgfVxwYXJkIFxxalx3aWRjdGxwYXJcYWRqdXN0cmlnaHQge1xmMSBWLiBC b3VyZGFraXMNClxwYXIgVW5pdmVyc2l0eSBvZiBCYXRoLiBVSw0KXHBhciB9e1xiXGlcZjEgVXRp bGlzaW5nIFVyYmFuIFZpcnR1YWwgRW52aXJvbm1lbnRzDQpccGFyIH1ccGFyZCBcd2lkY3RscGFy XGFkanVzdHJpZ2h0IHtcZjEgDQpccGFyIA0KXHBhciB9XHBhcmRccGxhaW4gXHMyXGtlZXBuXHdp ZGN0bHBhclxvdXRsaW5lbGV2ZWwxXGFkanVzdHJpZ2h0IFxiXGlcZjRcbGFuZzEwMzZcY2dyaWQg e1xpMFxmMVx1bCAxN2gzMFx+OiBDTE9UVVJFIA0KXHBhciB9XHBhcmRccGxhaW4gXHdpZGN0bHBh clxhZGp1c3RyaWdodCBcZjRcbGFuZzEwMzZcY2dyaWQge1xmMSANClxwYXIgfXtcYlxpXGYxIFBy b2Zlc3NvciBLLiBacmVpaywgfXtcYlxmMSBVbml2ZXJzaXRcJ2U5IGRlIENhZW4gOiBDLkEuRS5O IChHUkVZQywgTVJTSCkNClxwYXIgfXtcYlxpXGYxIEV1cm9wSUEgQ29uZmVyZW5jZXMgQ0hBSVJN QU4NClxwYXIgDQpccGFyIA0KXHBhciB9XHBhcmRccGxhaW4gXHMyNVxxY1x3aWRjdGxwYXJcYWRq dXN0cmlnaHQgXGYyXGZzMjBcY2dyaWQge1xiXGYzOVxmczI0IFxwYWdlIH17XGJcZjM5XGZzMzYg UkVHSVNUUkFUSU9OIEZPUk0gLyBJTlNDUklQVElPTg0KXHBhciB9e1xiXGYzOVxmczI0IA0KXHBh ciBFVVJPUElBICc5OCBDWUJFUkRFU0lHTg0KXHBhciANClxwYXIgUE9MRSBVTklWRVJTSVRBSVJF IExFT05BUkRPIERBIFZJTkNJDQpccGFyIA0KXHBhciBQQVJJUyA6IDI1LCAyNiwgMjcgTk9WRU1C RVINClxwYXIgfVxwYXJkIFxzMjVccWpcd2lkY3RscGFyXGFkanVzdHJpZ2h0IHtcZjM5XGZzMjQg DQpccGFyIA0KXHBhciB9e1xpXGYzOVxmczI0IE5BTUV9e1xmMzlcZnMyNCAgLyBOb20NClxwYXIg DQpccGFyIEFGRklMSUFUSU9OOg0KXHBhciANClxwYXIgfXtcaVxmMzlcZnMyNCBBRERSRVNTfXtc ZjM5XGZzMjQgIC8gQWRkcmVzc2UNClxwYXIgDQpccGFyIA0KXHBhciB9e1xpXGYzOVxmczI0IFBP U1QgQ09ERS1DSVRZfXtcZjM5XGZzMjQgIC8gQ29kZSBQb3N0YWwgVmlsbGUNClxwYXIgDQpccGFy IH17XGlcZjM5XGZzMjQgQ09VTlRSWX17XGYzOVxmczI0ICAvIFBheXM6DQpccGFyIA0KXHBhciAN ClxwYXIgDQpccGFyIH17XGJcaVxmMzlcZnMyNFx1bCBSRUdJU1RSQVRJT04gRkVFU317XGJcZjM5 XGZzMjRcdWwgOiBGcmFpcyBkJ0luc2NyaXB0aW9ufXtcZjM5XGZzMjQgDQpccGFyIH17XGlcZjM5 XGZzMjQgQVVUSE9SU317XGYzOVxmczI0ICAvIEF1dGV1cnNcdGFiIFx0YWIgXHRhYiAxNTUwRkYN ClxwYXIgfXtcaVxmMzlcZnMyNCBOT04gQVVUSE9SUyAvfXtcZjM5XGZzMjQgIE5vbi1BdXRldXJz XHRhYiAxOTUwRkZcdGFiIA0KXHBhciB9e1xpXGYzOVxmczI0IFNUVURFTlRTIC99e1xmMzlcZnMy NCAgRXR1ZGlhbnRzIDpcdGFiIFx0YWIgODAwRkYNClxwYXIgUGxlYXNlIG1ha2UgY2hlcXVlcyBw YXlhYmxlIHRvIDogICAgICBFdXJvcElBIFByb2R1Y3Rpb25zDQpccGFyIEFjY291bnQgTm86IFx0 YWIgXHRhYiBcdGFiIFx0YWIgMzAwMDIgMDA0NDIgMDAwMDAwNjk5MVogNTgNClxwYXIgQmFucXVl IDpcdGFiIFx0YWIgXHRhYiBcdGFiIENyZWRpdCBMeW9ubmFpcywgQWdlbmNlIFBhcmlzIE1hcmNl YXUNClxwYXIgXHRhYiBcdGFiIFx0YWIgXHRhYiBcdGFiIDQ0IEF2ZW51ZSBNYXJjZWF1DQpccGFy IFx0YWIgXHRhYiBcdGFiIFx0YWIgXHRhYiA3NTAwOCBQYXJpcywgRnJhbmNlDQpccGFyIA0KXHBh ciBQbGVhc2UgZW5zdXJlIHRoYXQgeW91ciBiYW5rIGNvdmVycyBhbnkgdHJhbnNmZXIgY2hhcmdl cy4NClxwYXIgDQpccGFyIH17XGlcZjM5XGZzMjQgVGhlIFN1YnNjcmlwdGlvbiBGb3JtIFNob3Vs ZCBiZSBzZW50IHRvfXtcZjM5XGZzMjQgIC8gSW5zY3JpcHRpb24sIENoXCdlOXF1ZXMgZXQgQm9u cyBkZSBDb21tYW5kZXMgZG9pdmVudCBcJ2VhdHJlIGFkcmVzc1wnZTlzIFwnZTAgOg0KXHBhciAN ClxwYXIgRXVyb3BpYSBQcm9kdWN0aW9ucw0KXHBhciAxNSwgYXZlbnVlIGRlIFNcJ2U5Z3VyDQpc cGFyIDc1MDA3IFBhcmlzDQpccGFyIFRlbCAoMzMpICgxKSA0NSA1MSAyNiAwNw0KXHBhciBGYXgg KDMzKSAoMSkgNDUgNTEgMjYgMzINClxwYXIgfXtlLW1haWw6IH17XGZpZWxke1wqXGZsZGluc3Qg eyBIWVBFUkxJTksgbWFpbHRvOmpwY291c2luQHdvcmxkbmV0LmZyIH17e1wqXGRhdGFmaWVsZCAN CjAwZDBjOWVhNzlmOWJhY2UxMThjODIwMGFhMDA0YmE5MGIwMjAwMDAwMDE3MDAwMDAwMTUwMDAw MDA2YTAwNzAwMDYzMDA2ZjAwNzUwMDczMDA2OTAwNmUwMDQwMDA3NzAwNmYwMDcyMDA2YzAwNjQw MDZlMDA2NTAwNzQwMDJlMDA2NjAwNzIwMDAwMDBlMGM5ZWE3OWY5YmFjZTExOGM4MjAwYWEwMDRi YTkwYjM4MDAwMDAwNmQwMDYxMDA2OTAwNmMwMDc0MDA2ZjAwM2EwMDZhMDA3MDAwNjMwMDZmMDA3 NTAwNzMwMDY5MDA2ZTAwNDAwMDc3MDA2ZjAwDQo3MjAwNmMwMDY0MDA2ZTAwNjUwMDc0MDAyZTAw NjYwMDcyMDAwMDAwMDAwMDAwMDAwMH19fXtcZmxkcnNsdCB7XGNzMjZcdWxcY2YyIGpwY291c2lu QHdvcmxkbmV0LmZyfX19e1xmMzlcZnMyNCAgIH17d2l0aCBhbiBlbWFpbCBjb3B5IHRvIG15c2Vs Zi4NClxwYXIgfXtcZjM5XGZzMjQgDQpccGFyIA0KXHBhciB9e1xiXGYzOVxmczI0XHVsIEhPVEVM Uw0KXHBhciB9e1xmMzlcZnMyNCBodHRwOi8vd3d3LmZyYW5jZS1ob3RlbC1ndWlkZS5jb20vNzVw YWNjdWUuaHRtDQpccGFyIGh0dHA6Ly93d3cudmlzaXQtcGFyaXMuY29tL2hvdGVscy9pbmRleC5o dG1sDQpccGFyIGh0dHA6Ly93d3cucGFyaXNlcnZlLnRtLmZyL2hvdGVsL2luZGV4Lmh0bQ0KXHBh ciANClxwYXIgfXtcYlxmMzlcZnMyNFx1bCBOLkI6IH17XGYzOVxmczI0ICBIb3RlbHMgbmV4dCB0 byB0aGUgbGluZSAxIG9mIHRoZSBtZXRybyAoQ2hhdGVhdSBkZSBWaW5jZW5uZSAtIExhIERlZmVu c2UpIG9yIHRoZSBSRVIgQSBhcmUgcmVjb21tZW5kZWQgKGkuZS4gbmV4dCB0byBFdG9pbGUsIENo YW1wcyBFbHlzZWVzLCBDb25jb3JkZSwgTG91dnJlLCBDaGF0ZWxldCwgQmFzdGlsbGUsDQpccGFy IFZlbmNlbm5lLCBldGMuKQ0KXHBhciANClxwYXIgfXtcYlxpXGYzOVxmczI0XHVsIFRyYW5zcG9y dGF0aW9ucyAoTUVUUk8sIFJFUiBhbmQgQnVzKX17XGYzOVxmczI0XHVsICAvIH17XGJcZjM5XGZz MjRcdWwgVHJhbnNwb3J0c317XGYzOVxmczI0XHVsIA0KXHBhciB9e1xmMzlcZnMyNCBodHRwOi8v d3d3LnJhdHAuZnIvDQpccGFyIGh0dHA6Ly93d3cucmF0cC5mci9UcmFuc3Bvci90cmFuc3BkZjEu aHRtDQpccGFyIGVpdGhlciBpbiBFbmdsaXNoIG9yIEZyZW5jaA0KXHBhciBNZXRybydzIG1hcDoN ClxwYXIgaHR0cDovL3d3dy5yYXRwLmZyL0ltYWdlcy9QZGYvbWV0cm8yLnBkZg0KXHBhciBSRVIn cyBNYXANClxwYXIgaHR0cDovL3d3dy5yYXRwLmZyL0ltYWdlcy9QZGYvcmVyLnBkZg0KXHBhciB9 XHBhcmRccGxhaW4gXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcZjRcbGFuZzEwMzZcY2dyaWQge1xi XGlcZjEgDQpccGFyIH19 --=_B6E1A2F8.30513EBF-- From rem-conf Thu Oct 22 08:22:47 1998 From rem-conf-request@es.net Thu Oct 22 08:22:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zWMUy-0000EK-00; Thu, 22 Oct 1998 08:18:00 -0700 Received: from nis-tradewind.paisley.ac.uk (wpmail.paisley.ac.uk) [146.191.32.5] by mail1.es.net with smtp (Exim 1.81 #2) id 0zWMUv-0000DT-00; Thu, 22 Oct 1998 08:17:57 -0700 Received: from Gate-Message_Server by wpmail.paisley.ac.uk with Novell_GroupWise; Thu, 22 Oct 1998 14:19:13 +0000 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 22 Oct 1998 14:18:34 +0000 From: Delia Atherton To: rem-conf@es.net Subject: EuropIA8 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_BEE9AAF1.B5D4BB3A" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_BEE9AAF1.B5D4BB3A Content-Type: text/plain Content-Disposition: inline Dear Colleague Please find attach the final programme. Best regards, --=_BEE9AAF1.B5D4BB3A Content-Type: application/rtf Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="EIAFPGM.RTF" Content-Description: Rich-Text-Format e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcdWMxIFxkZWZmNFxkZWZsYW5nMTAzM1xkZWZsYW5nZmUx MDMze1xmb250dGJse1xmMFxmcm9tYW5cZmNoYXJzZXQwXGZwcnEye1wqXHBhbm9zZSAwMjAyMDYw MzA1MDQwNTAyMDMwNH1UaW1lcyBOZXcgUm9tYW47fXtcZjFcZnN3aXNzXGZjaGFyc2V0MFxmcHJx MntcKlxwYW5vc2UgMDIwYjA2MDQwMjAyMDIwMjAyMDR9QXJpYWw7fQ0Ke1xmMlxmbW9kZXJuXGZj aGFyc2V0MFxmcHJxMXtcKlxwYW5vc2UgMDIwNzAzMDkwMjAyMDUwMjA0MDR9Q291cmllciBOZXc7 fXtcZjRcZnJvbWFuXGZjaGFyc2V0MFxmcHJxMntcKlxwYW5vc2UgMDIwMjA2MDMwNTA0MDUwMjAz MDR9VGltZXN7XCpcZmFsdCBUaW1lcyBOZXcgUm9tYW59O30NCntcZjhcZnJvbWFuXGZjaGFyc2V0 MFxmcHJxMntcKlxwYW5vc2UgMDAwMDAwMDAwMDAwMDAwMDAwMDB9VG1zIFJtbntcKlxmYWx0IFRp bWVzIE5ldyBSb21hbn07fXtcZjM5XGZyb21hblxmY2hhcnNldDBcZnBycTJ7XCpccGFub3NlIDAy MDIwNjAzMDUwNDA1MDIwMzA0fVRpbWVzIE5ldyAoVzEpO317XGY2MVxmcm9tYW5cZmNoYXJzZXQy MzhcZnBycTIgVGltZXMgTmV3IFJvbWFuIENFO30NCntcZjYyXGZyb21hblxmY2hhcnNldDIwNFxm cHJxMiBUaW1lcyBOZXcgUm9tYW4gQ3lyO317XGY2NFxmcm9tYW5cZmNoYXJzZXQxNjFcZnBycTIg VGltZXMgTmV3IFJvbWFuIEdyZWVrO317XGY2NVxmcm9tYW5cZmNoYXJzZXQxNjJcZnBycTIgVGlt ZXMgTmV3IFJvbWFuIFR1cjt9e1xmNjZcZnJvbWFuXGZjaGFyc2V0MTg2XGZwcnEyIFRpbWVzIE5l dyBSb21hbiBCYWx0aWM7fXtcZjY3XGZzd2lzc1xmY2hhcnNldDIzOFxmcHJxMiBBcmlhbCBDRTt9 DQp7XGY2OFxmc3dpc3NcZmNoYXJzZXQyMDRcZnBycTIgQXJpYWwgQ3lyO317XGY3MFxmc3dpc3Nc ZmNoYXJzZXQxNjFcZnBycTIgQXJpYWwgR3JlZWs7fXtcZjcxXGZzd2lzc1xmY2hhcnNldDE2Mlxm cHJxMiBBcmlhbCBUdXI7fXtcZjcyXGZzd2lzc1xmY2hhcnNldDE4NlxmcHJxMiBBcmlhbCBCYWx0 aWM7fXtcZjczXGZtb2Rlcm5cZmNoYXJzZXQyMzhcZnBycTEgQ291cmllciBOZXcgQ0U7fQ0Ke1xm NzRcZm1vZGVyblxmY2hhcnNldDIwNFxmcHJxMSBDb3VyaWVyIE5ldyBDeXI7fXtcZjc2XGZtb2Rl cm5cZmNoYXJzZXQxNjFcZnBycTEgQ291cmllciBOZXcgR3JlZWs7fXtcZjc3XGZtb2Rlcm5cZmNo YXJzZXQxNjJcZnBycTEgQ291cmllciBOZXcgVHVyO317XGY3OFxmbW9kZXJuXGZjaGFyc2V0MTg2 XGZwcnExIENvdXJpZXIgTmV3IEJhbHRpYzt9fXtcY29sb3J0Ymw7XHJlZDBcZ3JlZW4wXGJsdWUw O1xyZWQwXGdyZWVuMFxibHVlMjU1Ow0KXHJlZDBcZ3JlZW4yNTVcYmx1ZTI1NTtccmVkMFxncmVl bjI1NVxibHVlMDtccmVkMjU1XGdyZWVuMFxibHVlMjU1O1xyZWQyNTVcZ3JlZW4wXGJsdWUwO1xy ZWQyNTVcZ3JlZW4yNTVcYmx1ZTA7XHJlZDI1NVxncmVlbjI1NVxibHVlMjU1O1xyZWQwXGdyZWVu MFxibHVlMTI4O1xyZWQwXGdyZWVuMTI4XGJsdWUxMjg7XHJlZDBcZ3JlZW4xMjhcYmx1ZTA7XHJl ZDEyOFxncmVlbjBcYmx1ZTEyODtccmVkMTI4XGdyZWVuMFxibHVlMDsNClxyZWQxMjhcZ3JlZW4x MjhcYmx1ZTA7XHJlZDEyOFxncmVlbjEyOFxibHVlMTI4O1xyZWQxOTJcZ3JlZW4xOTJcYmx1ZTE5 Mjt9e1xzdHlsZXNoZWV0e1x3aWRjdGxwYXJcYWRqdXN0cmlnaHQgXGY0XGxhbmcxMDM2XGNncmlk IFxzbmV4dDAgTm9ybWFsO317XHMxXGtlZXBuXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcYlxmNFx1 bFxsYW5nMTAzNlxjZ3JpZCBcc2Jhc2Vkb24wIFxzbmV4dDAgaGVhZGluZyAxO317DQpcczJca2Vl cG5cd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxiXGlcZjRcbGFuZzEwMzZcY2dyaWQgXHNiYXNlZG9u MCBcc25leHQwIGhlYWRpbmcgMjt9e1xzM1xrZWVwblx3aWRjdGxwYXJcYWRqdXN0cmlnaHQgXGJc ZjRcbGFuZzEwMzZcY2dyaWQgXHNiYXNlZG9uMCBcc25leHQwIGhlYWRpbmcgMzt9e1wqXGNzMTAg XGFkZGl0aXZlIERlZmF1bHQgUGFyYWdyYXBoIEZvbnQ7fXtcczE1XHdpZGN0bHBhclxhZGp1c3Ry aWdodCANClxiXGY0XHVsXGxhbmcxMDM2XGNncmlkIFxzYmFzZWRvbjAgXHNuZXh0MTUgQm9keSBU ZXh0O317XHMxNlxub3dpZGN0bHBhclxhZGp1c3RyaWdodCBcZjQgXHNiYXNlZG9uMCBcc25leHQx NiBUZXh0ZSBwYXIgZFwnZTlmYXV0O317XCpcY3MxNyBcYWRkaXRpdmUgXGYyIEluaXRpYWxTdHls ZTt9e1xzMThcc2E4MFxzbDI0MFxzbG11bHQwXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcYlxmNFxj ZjFcY2dyaWQgXHNiYXNlZG9uMCBcc25leHQxOCANCjAxIGF1dGV1cjt9e1xzMTlcc2wyNDBcc2xt dWx0MFx3aWRjdGxwYXJcYWRqdXN0cmlnaHQgXGlcZjRcZnMyMFxjZjFcY2dyaWQgXHNiYXNlZG9u MCBcc25leHQxOSAwMSBhZHJlc3NlO317XHMyMFxzYjI0MFx3aWRjdGxwYXJcYWRqdXN0cmlnaHQg XGJcZjRcZnMyOFxsYW5nMjA1NyBcc2Jhc2Vkb24wIFxzbmV4dDIxIGF1dGhvcjt9e1xzMjFccWpc c2wzMDBcc2xtdWx0MFx3aWRjdGxwYXJcYWRqdXN0cmlnaHQgXGY0XGxhbmcyMDU3IA0KXHNiYXNl ZG9uMjAgXHNuZXh0MjIgYWZmaWxpYXRpb247fXtcczIyXHFqXHNsMjYwXHNsbXVsdDBcd2lkY3Rs cGFyXGFkanVzdHJpZ2h0IFxmNFxmczIwXGxhbmcyMDU3IFxzYmFzZWRvbjAgXHNuZXh0MCBhYnN0 cmFjdDt9e1xzMjNcc2IyODQwXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcYlxmNFxmczM2XGxhbmcx MDM2XGNncmlkIFxzYmFzZWRvbjAgXHNuZXh0MjAgdGl0bGU7fXtcczI0XHdpZGN0bHBhcg0KXHRx Y1x0eDQzMjBcdHFyXHR4ODY0MFxhZGp1c3RyaWdodCBcc2hhZFxmOFxmczIwXGxhbmcxMDI0XGNn cmlkIFxzYmFzZWRvbjAgXHNuZXh0MjQgZm9vdGVyO317XHMyNVx3aWRjdGxwYXJcYWRqdXN0cmln aHQgXGYyXGZzMjBcY2dyaWQgXHNiYXNlZG9uMCBcc25leHQyNSBQbGFpbiBUZXh0O317XCpcY3My NiBcYWRkaXRpdmUgXHVsXGNmMiBcc2Jhc2Vkb24xMCBIeXBlcmxpbms7fX17XGluZm8NCntcdGl0 bGUgSGVyZWFmdGVyIHdoYXQgY2FuIEkgZ2dlc3QgeW91IGZvciBFSUFcJzkyOTggcHJvZ3JhbW1l fXtcYXV0aG9yIFpyZWlrfXtcb3BlcmF0b3IgYnJhbi1jaTB9e1xjcmVhdGltXHlyMTk5OFxtbzEw XGR5MjFcaHIxNFxtaW4yNX17XHJldnRpbVx5cjE5OThcbW8xMFxkeTIyXGhyMTR9e1xwcmludGlt XHlyMTk5OFxtbzEwXGR5MjFcaHIxMlxtaW4zMH17XHZlcnNpb24xNX17XGVkbWluczEzMX17XG5v ZnBhZ2VzOH0NCntcbm9md29yZHMxMjk3fXtcbm9mY2hhcnM3Mzk2fXtcKlxjb21wYW55IEJ1cmVh dXRpcXVlfXtcbm9mY2hhcnN3czB9e1x2ZXJuODl9fVxwYXBlcncxMTkwNlxwYXBlcmgxNjgzOFxt YXJnbDE0MTdcbWFyZ3IxNDE3XG1hcmd0MTQxN1xtYXJnYjE0MTcgXGRlZnRhYjcwOFx3aWRvd2N0 cmxcZnRuYmpcYWVuZGRvY1xoeXBoaG90ejQyNVxoeXBoY2FwczBcZm9ybXNoYWRlXHZpZXdraW5k NFx2aWV3c2NhbGUxMDBccGdicmRyaGVhZFxwZ2JyZHJmb290IA0KXGZldDBcc2VjdGQgXGxpbmV4 MFxoZWFkZXJ5NzA5XGZvb3Rlcnk3MDlcY29sc3g3MDlcZW5kbmhlcmVcc2VjdGRlZmF1bHRjbCB7 XCpccG5zZWNsdmwxXHBudWNybVxwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmd7XHBudHh0YSAu fX17XCpccG5zZWNsdmwyXHBudWNsdHJccG5zdGFydDFccG5pbmRlbnQ3MjBccG5oYW5ne1xwbnR4 dGEgLn19e1wqXHBuc2VjbHZsM1xwbmRlY1xwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmd7XHBu dHh0YSAufX0NCntcKlxwbnNlY2x2bDRccG5sY2x0clxwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhh bmd7XHBudHh0YSApfX17XCpccG5zZWNsdmw1XHBuZGVjXHBuc3RhcnQxXHBuaW5kZW50NzIwXHBu aGFuZ3tccG50eHRiICh9e1xwbnR4dGEgKX19e1wqXHBuc2VjbHZsNlxwbmxjbHRyXHBuc3RhcnQx XHBuaW5kZW50NzIwXHBuaGFuZ3tccG50eHRiICh9e1xwbnR4dGEgKX19e1wqXHBuc2VjbHZsN1xw bmxjcm1ccG5zdGFydDFccG5pbmRlbnQ3MjBccG5oYW5nDQp7XHBudHh0YiAofXtccG50eHRhICl9 fXtcKlxwbnNlY2x2bDhccG5sY2x0clxwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmd7XHBudHh0 YiAofXtccG50eHRhICl9fXtcKlxwbnNlY2x2bDlccG5sY3JtXHBuc3RhcnQxXHBuaW5kZW50NzIw XHBuaGFuZ3tccG50eHRiICh9e1xwbnR4dGEgKX19XHBhcmRccGxhaW4gXHMyXHFjXGtlZXBuXHdp ZGN0bHBhclxvdXRsaW5lbGV2ZWwxXGFkanVzdHJpZ2h0IFxiXGlcZjRcbGFuZzEwMzZcY2dyaWQg ew0KXGYxXGZzNDQgRVVST1BJQSBccnF1b3RlIDk4ICA6IENZQkVSREVTSUdODQpccGFyIH1ccGFy ZFxwbGFpbiBccWNcd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxmNFxsYW5nMTAzNlxjZ3JpZCB7XGJc aVxmMVxmczM2IE1lZGlhLCBDb21tdW5pY2F0aW9uICYgRGVzaWduIFByYWN0aWNlDQpccGFyIH17 XGJcZjFcZnMzNiBNZWRpYSAmIENvbW11bmljYXRpb24gZGFucyBsYSBQcmF0aXF1ZSBkZSBsYSBD b25jZXB0aW9uDQpccGFyIH1ccGFyZCBcd2lkY3RscGFyXGFkanVzdHJpZ2h0IHtcaVxmMVxmczM2 IA0KXHBhciB9XHBhcmQgXHFjXHdpZGN0bHBhclxhZGp1c3RyaWdodCB7XGlcZjEgU2V2ZW50aCBJ bnRlcm5hdGlvbmFsIENvbmZlcmVuY2Ugb24gdGhlIEFwcGxpY2F0aW9uL0ltcGxpY2F0aW9ucyBv ZiBDb21wdXRlciBOZXR3b3JraW5nIGluIEFyY2hpdGVjdHVyZSwgQ29uc3RydWN0aW9uLCBEZXNp Z24sIENpdmlsIEVuZ2luZWVyaW5nIGFuZCBVcmJhbiBQbGFubmluZw0KXHBhciB9e1xmMSANClxw YXIgU2VwdGlcJ2U4bWUgQ29sbG9xdWUgSW50ZXJuYXRpb25hbCBzdXIgbGVzIGFwcGxpY2F0aW9u cyBldCBsZXMgaW1wbGljYXRpb25zIGRlcyBub3V2ZWxsZXMgdGVjaG5vbG9naWVzIGRlIGwnaW5m b3JtYXRpb24gZXQgZGUgbGEgY29tbXVuaWNhdGlvbiBlbiBBcmNoaXRlY3R1cmUsIENvbnN0cnVj dGlvbiBldCBlbiBQbGFuaWZpY2F0aW9uIFVyYmFpbmV9e1xmMVxmczI4IA0KXHBhciB9e1xiXGYx XGZzMjggDQpccGFyIH17XGJcaVxmMSBPcmdhbmlzZWQgYnl9e1xiXGYxICAvIE9yZ2FuaXNcJ2U5 IHBhcjoNClxwYXIgVW5pdmVyc2l0eSBvZiBQYWlzbGV5IDogRGVwYXJ0bWVudCBvZiBDb21wdXRp bmcgYW5kIEluZm9ybWF0aW9uIFN5c3RlbQ0KXHBhciBVbml2ZXJzaXRcJ2U5IGRlIENhZW4gOiBD LkEuRS5OIChHUkVZQywgTVJTSCkNClxwYXIgUFwnZjRsZSBVbml2ZXJzaXRhaXJlIExcJ2U5b25h cmQgRGUgVmluY2kgOiBJRkFNSUYsIFBhcmlzIGxhIERcJ2U5ZmVuc2UNClxwYXIgRXVyb3BpYSBQ cm9kdWN0aW9ucywgUGFyaXN9e1xiXGYxXGZzMzIgDQpccGFyIA0KXHBhciB9e1xiXGlcZjEgDQpc cGFyIFBBUklTIDogMjUsIDI2LCAyNyBOT1ZFTUJFUg0KXHBhciB9e1xmMVxmczMyXHVsIFBcJ2Y0 bGUgVW5pdmVyc2l0YWlyZSBMXCdlOW9uYXJkIGRlIFZpbmNpDQpccGFyIFBhcmlzIGxhIERcJ2U5 ZmVuc2UNClxwYXIgfVxwYXJkIFx3aWRjdGxwYXJcYWRqdXN0cmlnaHQge1xmMSANClxwYXIgfVxw YXJkXHBsYWluIFxzMVxrZWVwblx3aWRjdGxwYXJcb3V0bGluZWxldmVsMFxhZGp1c3RyaWdodCBc YlxmNFx1bFxsYW5nMTAzNlxjZ3JpZCB7XGlcZjEgV2VkbmVzZGF5IDI1LzExLzE5OTggfXtcZjEg LyBNZXJjcmVkaSAyNSBOb3ZlbWJyZSAxOTk4fXtcaVxmMSANClxwYXIgfVxwYXJkXHBsYWluIFx3 aWRjdGxwYXJcYWRqdXN0cmlnaHQgXGY0XGxhbmcxMDM2XGNncmlkIHtcaVxmMSANClxwYXIgfVxw YXJkXHBsYWluIFxzMVxrZWVwblx3aWRjdGxwYXJcb3V0bGluZWxldmVsMFxhZGp1c3RyaWdodCBc YlxmNFx1bFxsYW5nMTAzNlxjZ3JpZCB7XGlcZjEgT3Blbm5pbmcgU2Vzc2lvbiAvIH17XGYxIE91 dmVydHVyZSBkdSBDb2xsb3F1ZSAtIFZpZGVvIENvbmZlcmVuY2V9e1xpXGYxIA0KXHBhciB9XHBh cmRccGxhaW4gXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcZjRcbGFuZzEwMzZcY2dyaWQge1xmMSAN ClxwYXIgfXtcZjFcZnMyMCA5aDAwIC0gOWgxNSBcdGFiIERyLiB9e1xiXGYxXGZzMjAgQ2hlcmlm IEJSQU5LSX17XGYxXGZzMjAgLCBVbml2ZXJzaXR5IG9mIFBhaXNsZXksIEVJQVxycXVvdGUgOTgg Q2hhaXJtYW4NClxwYXIgDQpccGFyIDloIDE1IC0gOWg0NSBcdGFiIE0uIH17XGJcZjFcZnMyMCBS aWNoYXJkIFNIQVd9e1xmMVxmczIwICwgUHJvZmVzc29yLCBQcmluY2lwYWwgb2YgVGhlIFVuaXZl cnNpdHkgb2YgUGFpc2xleQ0KXHBhciANClxwYXIgfVxwYXJkXHBsYWluIFxzMTVcd2lkY3RscGFy XGFkanVzdHJpZ2h0IFxiXGY0XHVsXGxhbmcxMDM2XGNncmlkIHtcYjBcZjFcZnMyMFx1bG5vbmUg OWggNDUgLSAxMGgwNSBcdGFiIE0uIH17XGYxXGZzMjBcdWxub25lIE1pY2hlbCBCQVJBVH17XGIw XGYxXGZzMjBcdWxub25lICwgRGlyZWN0ZXVyIEdcJ2U5blwnZTlyYWwgZHUgUFwnZjRsZSBVbml2 ZXJzaXRhaXJlIExcJ2U5b25hcmQgZGUgVmluY2kNClxwYXIgDQpccGFyIDEwaDA1IC0gMTBmMTUg XHRhYiBNLiB9e1xmMVxmczIwXHVsbm9uZSBDaHJpc3RpYW4gU0FOREVSfXtcYjBcZjFcZnMyMFx1 bG5vbmUgLCBEaXJlY3RldXIgZGUgbCdJRkFNSUYNClxwYXIgDQpccGFyIH17XGYxXGZzMjBcdWxu b25lIDEwaDE1IC0gMTBoNDVcdGFiIH17XGlcZjFcZnMyMFx1bG5vbmUgSW52aXRlZCBTcGVha2Vy IC99e1xmMVxmczIwXHVsbm9uZSAgQ29uZlwnZTlyZW5jZSBpbnZpdFwnZTllDQpccGFyIH17XGIw XGYxXGZzMjBcdWxub25lIE0uIE0uIExcJ2U5Z2xpc2UsIFByb2Zlc3NldXIsIEVjb2xlIGQnQXJj aGl0ZWN0dXJlIGRlIFRvdWxvdXNlDQpccGFyIH17XGlcZjFcZnMyMFx1bG5vbmUgQ29uc3RpdHV0 aW9uIGQndW5lIG1cJ2U5bW9pcmUgcGVyc29ubmVsbGUgXCdlMCBwYXJ0aXIgZGUgcmVwclwnZTlz ZW50YXRpb25zIGRpc3NcJ2U5bWluXCdlOWVzLiANClxwYXIgfXtcYjBcZjFcZnMyMFx1bG5vbmUg DQpccGFyIH17XGIwXGYxXHVsbm9uZSAxMGg0NSAtIDExaDE1IH17XGIwXGlcZjEgQ29mZmVlIEJy ZWFrfXtcYjBcZjEgIC8gfXtcYjBcZjFcdWxub25lIFBhdXNlIENhZlwnZTl9e1xmMSANClxwYXIg DQpccGFyIFNFU1NJT04gSVx+fXtcYjBcZjEgKH17XGIwXGlcZjEgU2hvcnQgcGFwZXJzfXtcYjBc ZjEgIC8gY29tbXVuaWNhdGlvbnMgY291cnRlcyA6IDExaDE1IC0gMTJoMzApDQpccGFyIH17XGlc ZjFcdWxub25lIENZQkVSIERFU0lHTiBFTlZJUk9OTUVOVCBWUyBSRUFMIERFU0lHTiBFTlZJUk9O TUVOVCANClxwYXIgfVxwYXJkXHBsYWluIFx3aWRjdGxwYXJcYWRqdXN0cmlnaHQgXGY0XGxhbmcx MDM2XGNncmlkIHtcZjEgDQpccGFyIE0uIENyb3dlLCAgUy4gS3lkZA0KXHBhciBVbml2ZXJzaXR5 IG9mIFBhaXNsZXksIFVLDQpccGFyIH17XGJcaVxmMSBBZ2VudHMgYW5kIHN1Z2dlc3Rpb25zIGlu IGEgV2ViLWJhc2VkIGR5bmFtaWMgd29ya2Zsb3cgbW9kZWwuDQpccGFyIH17XGYxIA0KXHBhciBO LiBCYXVwaW4gJiAgSy4gWnJlaWsNClxwYXIgQ05FVCwgQ2FlbiwgVW5pdmVyc2l0eSBvZiBDYWVu LCBGcmFuY2UNClxwYXIgfXtcYlxpXGYxIFRcJ2U5bFwnZTlkZWNpc2lvbjogTi5ULkkuQy4gZXQg Y29uY2VwdGlvbiBjb29wZXJhdGl2ZS4NClxwYXIgfXtcZjEgDQpccGFyIE0uIENsYXl0b24NClxw YXIgVGV4YXMgQSZNIFVuaXZlcnNpdHksIFVTQQ0KXHBhciB9e1xiXGlcZjEgRGlzdHJpYnV0ZWQg ZGVzaWduIGtub3dsZWRnZSB1c2luZyBmb3JtLCBmdW5jdGlvbiBhbmQgYmVoYXZpb3VyDQpccGFy IH17XGYxIA0KXHBhciB9XHBhcmRccGxhaW4gXHMxNlxxalx3aWRjdGxwYXJcYWRqdXN0cmlnaHQg XGY0IHtcY3MxN1xmMSBZLiBSZXplDQpccGFyIFVuaXZlcnNpdFwnZTkgb2YgQ2FlbiwgRnJhbmNl LA0KXHBhciB9XHBhcmRccGxhaW4gXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcZjRcbGFuZzEwMzZc Y2dyaWQge1xiXGlcZjEgTCdoeXBlcm1lZGlhOiB1bmUgYXV0cmUgZmFjb24gZGUgcmVwcmVzZW50 ZXIuDQpccGFyIH17XGYxIA0KXHBhciB9XHBhcmRccGxhaW4gXHMxOFxzbDI0MFxzbG11bHQwXHdp ZGN0bHBhclxhZGp1c3RyaWdodCBcYlxmNFxjZjFcY2dyaWQge1xiMFxmMSBDLiBERVNIQVlFUw0K XHBhciB9XHBhcmRccGxhaW4gXHMxOVxzbDI0MFxzbG11bHQwXHdpZGN0bHBhclxhZGp1c3RyaWdo dCBcaVxmNFxmczIwXGNmMVxjZ3JpZCB7XGkwXGYxXGZzMjQgRWNvbGUgZCdBcmNoaXRlY3R1cmUg ZGUgUGFyaXMtVmFsLURlLU1Bcm5lLCBGcmFuY2UNClxwYXIgfVxwYXJkXHBsYWluIFx3aWRjdGxw YXJcYWRqdXN0cmlnaHQgXGY0XGxhbmcxMDM2XGNncmlkIHtcYlxpXGYxIFBlcmNlcHRpb24gc3Bh dGlhbGUgZCd1biBlbnZpcm9ubWVudCBhcmNoaXRlY3R1cmFsOiBhc3BlY3RzDQpccGFyIGluZm9y bWF0aW9ubmVsIGV0IGNvbW11bmljYXRpb25uZWwuDQpccGFyIH17XGYxIA0KXHBhciANClxwYXIg fVxwYXJkXHBsYWluIFxzMTVcd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxiXGY0XHVsXGxhbmcxMDM2 XGNncmlkIHtcZjEgU0VTU0lPTiBJSVx+fXtcYjBcZjEgKH17XGIwXGlcZjEgU2hvcnQgcGFwZXJz fXtcYjBcZjEgIC8gY29tbXVuaWNhdGlvbnMgY291cnRlcyA6IDE0aDAwIC0gMTVoMTUpDQpccGFy IH1ccGFyZFxwbGFpbiBcczFca2VlcG5cd2lkY3RscGFyXG91dGxpbmVsZXZlbDBcYWRqdXN0cmln aHQgXGJcZjRcdWxcbGFuZzEwMzZcY2dyaWQge1xpXHVsbm9uZSBXRUIgQkFTRUQgREVTSUdODQpc cGFyIH1ccGFyZFxwbGFpbiBcd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxmNFxsYW5nMTAzNlxjZ3Jp ZCB7XGJcY2FwcyBJbnRlcm5ldCBkYW5zIGxhIHByYXRpcXVlIGRlIGxhIGNvbmNlcHRpb259ew0K XHBhciB9XHBhcmRccGxhaW4gXHMyMFxzYjI0MFx3aWRjdGxwYXJcYWRqdXN0cmlnaHQgXGJcZjRc ZnMyOFxsYW5nMjA1NyB7XGIwXGYxXGZzMjQgTi4gS2FyYWNhcGlsaWRpcywgTy4gQWJvdSBLaGFs ZWQNClxwYXIgfVxwYXJkXHBsYWluIFxzMjFccWpcc2wzMDBcc2xtdWx0MFx3aWRjdGxwYXJcYWRq dXN0cmlnaHQgXGY0XGxhbmcyMDU3IHtcaVxmMSBFUEZMLCBTd2l0emVybGFuZH17XGlcZjFcZnMy MCANClxwYXIgfVxwYXJkXHBsYWluIFx3aWRjdGxwYXJcYWRqdXN0cmlnaHQgXGY0XGxhbmcxMDM2 XGNncmlkIHtcYlxpXGYxIEVzdGFibGlzaGluZyBjb21tdW5pY2F0aW9uIGJldHdlZW4gYSB3ZWIt YmFzZWQgYXJndW1lbnRhdGlvbg0KXHBhciBhbmQgcmVtb3RlIGRhdGFiYXNlcw0KXHBhciB9e1xm MSANClxwYXIgfVxwYXJkXHBsYWluIFxzMTZcd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxmNCB7XGYx XGxhbmcxMDM2XGNncmlkIEYuIEFtZXppYW5lLCBTLiBMYXNzZXJyZQ0KXHBhciB9XHBhcmRccGxh aW4gXHMyMVxxalxzbDMwMFxzbG11bHQwXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcZjRcbGFuZzIw NTcge1xmMSBFY29sZSBkXHJxdW90ZSBBcmNoaXRlY3R1cmUgZGUgTWFyc2VpbGxlICwgRnJhbmNl DQpccGFyIH1ccGFyZFxwbGFpbiBcczE2XHdpZGN0bHBhclxhZGp1c3RyaWdodCBcZjQge1xiXGlc ZjEgQnVpbGRpbmcgaW5mb3JtYXRpb24gaW4gY29vcGVyYXRpdmUgcHJvZHVjdGlvbiBjb250ZXh0 DQpccGFyIH1ccGFyZFxwbGFpbiBcd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxmNFxsYW5nMTAzNlxj Z3JpZCB7XGYxIA0KXHBhciBNLiBCb3ViZWtyaQ0KXHBhciB9XHBhcmRccGxhaW4gXHMyNFx3aWRj dGxwYXJcYWRqdXN0cmlnaHQgXHNoYWRcZjhcZnMyMFxsYW5nMTAyNFxjZ3JpZCB7XHNoYWQwXGYx XGZzMjRcbGFuZzEwMzMgVW5pdmVyc2l0eSBvZiBJbGxpbm9pcywgVVNBDQpccGFyIH1ccGFyZFxw bGFpbiBcd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxmNFxsYW5nMTAzNlxjZ3JpZCB7XGJcaVxmMSBD b21wdXRlciBOZXR3b3JraW5nIGFuZCBMaWdodGluZyBEZXNpZ24gSW5zdHJ1Y3Rpb24uDQpccGFy IH17XGYxIA0KXHBhciBHLiBWYXNxdWV6IGRlIFZlbGFzY28sIE4uIEhvbGxhbmQNClxwYXIgVGV4 YXMgQSZNIFVuaXZlcnNpdHksIFVTQQ0KXHBhciB9e1xiXGlcZjEgQ29tcHV0ZXIgbWVkaWF0ZWQg cmVjaXByb2NhbCBkaXN0YW5jZSBlZHVjYXRpb24uDQpccGFyIH17XGYxIA0KXHBhciBQLiBWYW4g ZGVyIFZlZXIsIEkuUy5TYXJpeWlsZGl6LCB9e1wnZDZ9e1xmMSAuIENpZnRjaW9nbHUNClxwYXIg fVxwYXJkXHBsYWluIFxzMTZcbm93aWRjdGxwYXJcdHgxNDJcYWRqdXN0cmlnaHQgXGY0IHtcZjFc ZXhwbmQtNFxleHBuZHR3LTIwXGxhbmcxMDM2XGNncmlkIERlbGZ0IFVuaXZlcnNpdHkgb2YgVGVj aG5vbG9neSwgVGhlIE5ldGhlcmxhbmRzDQpccGFyIH1ccGFyZFxwbGFpbiBcd2lkY3RscGFyXGFk anVzdHJpZ2h0IFxmNFxsYW5nMTAzNlxjZ3JpZCB7XGJcaVxmMSBPcmRlcmluZyBvZiBJbmZvcm1h dGlvbiBhbmQgRnVuY3Rpb25hbGl0eSBmb3IgZGVjaXNpb24gc3VwcG9ydCBpbg0KXHBhciBidWls ZGluZyBkZXNpZ24ufXtcZjEgDQpccGFyIA0KXHBhciB9XHBhcmRccGxhaW4gXHMzXGtlZXBuXHdp ZGN0bHBhclxvdXRsaW5lbGV2ZWwyXGFkanVzdHJpZ2h0IFxiXGY0XGxhbmcxMDM2XGNncmlkIHtc ZjEgUE9TVEVSUyAmIFJhZnJhXCdlZWNoaXNzZW1lbnQgKDE1aDE1IC0gMTdoMTUpDQpccGFyIH1c cGFyZFxwbGFpbiBcd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxmNFxsYW5nMTAzNlxjZ3JpZCB7XGYx IA0KXHBhciB9XHBhcmRccGxhaW4gXHMxXGtlZXBuXHdpZGN0bHBhclxvdXRsaW5lbGV2ZWwwXGFk anVzdHJpZ2h0IFxiXGY0XHVsXGxhbmcxMDM2XGNncmlkIHtcaVxmMSBUSFVTREFZIDI2LzExLzE5 OTh9e1xmMSAgLyBKZXVkaSAyNiBOb3ZlbWJyZSAxOTk4DQpccGFyIH1ccGFyZFxwbGFpbiBcd2lk Y3RscGFyXGFkanVzdHJpZ2h0IFxmNFxsYW5nMTAzNlxjZ3JpZCB7XGYxIA0KXHBhciANClxwYXIg fVxwYXJkXHBsYWluIFxzMVxrZWVwblx3aWRjdGxwYXJcb3V0bGluZWxldmVsMFxhZGp1c3RyaWdo dCBcYlxmNFx1bFxsYW5nMTAzNlxjZ3JpZCB7XGYxIFNFU1NJT04gSUlJXH46ICAoOWgwMCAtIDEw aDMwKQ0KXHBhciB9e1xpXGYxXHVsbm9uZSBPTiBMSU5FIERJU1RSSUJVVEVEIERFU0lHTiBFTlZJ Uk9OTUVOVA0KXHBhciB9XHBhcmRccGxhaW4gXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcZjRcbGFu ZzEwMzZcY2dyaWQge1xiXGNhcHNcZjEgRW52aXJvbm5lbWVudCBkeW5hbWlxdWUgcG91ciBsYSBj b25jZXB0aW9uIGNvb3BcJ2U5cmF0aXZlDQpccGFyIH17XGYxIA0KXHBhciBSLiBDb3luZSwgSi4g TGVlLCBELiBEdW5jYW4sIFMuIE9mbHVvZ2x1DQpccGFyIFVuaXZlcnNpdHkgb2YgRWRpbmJ1cmdo LCBVSw0KXHBhciB9e1xiXGlcZjEgQXBwbHlpbmcgd2ViLWJhc2VkIHByb2R1Y3QgbGlicmFyaWVz Lg0KXHBhciB9e1xmMSANClxwYXIgDQpccGFyIEwuIE1hcnRpbiwgVGhlIEplcmRlIFBhcnRuZXJz aGlwIEludGVybmF0aW9uYWwgSW5jLiwgVVNBIH17XGJcaVxmMSANClxwYXIgQXJjaGl0ZWN0dXJl IGluIGRpZ2l0YWwgZG9tYWluOiBmcm9tIGFyY3RpYyBpbWFnZXMgdG8gZGVzZXJ0DQpccGFyIGRy ZWFtbGFuZHMuDQpccGFyIH17XGYxIA0KXHBhciBCYXJrb3dza2ksIEMuIEJyYW5raSwgRS4gR3Jh YnNrYSwgVy4gUGFsYWN6DQpccGFyIFVuaXZlcnNpdHkgb2YgUGFpc2xleSwgVS5LLiwgSUZUUlMs IFBvbGFuZCwgSUNTLCBQb2xhbmQNClxwYXIgfXtcYlxpXGYxIFRvd2FyZHMgY29sbGFib3JhdGl2 ZSBkc2VpZ24uDQpccGFyIH17XGYxIA0KXHBhciB9e1xpXGYxIDEwaDMwIC0gMTFoMDAgQ29mZmVl IEJyZWFrfXtcZjEgIC8gcGF1c2UgQ2FmXCdlOQ0KXHBhciANClxwYXIgfVxwYXJkXHBsYWluIFxz MVxrZWVwblx3aWRjdGxwYXJcb3V0bGluZWxldmVsMFxhZGp1c3RyaWdodCBcYlxmNFx1bFxsYW5n MTAzNlxjZ3JpZCB7XGYxIFNFU1NJT05cfklWOiAoMTFoMDAtMTNoMDApDQpccGFyIH17XGlcZjFc dWxub25lIERBVEEgQUNRVUlTSVRJT04gQ1lCRVJTUEFDRQ0KXHBhciB9XHBhcmRccGxhaW4gXHdp ZGN0bHBhclxhZGp1c3RyaWdodCBcZjRcbGFuZzEwMzZcY2dyaWQge1xiXGNhcHNcZjEgQ3liZXIt RXNwYWNlcyBwb3VyIGwnYWNxdWlzaXRpb24gZGVzIGRvbm5cJ2U5ZXMgZW4gY29uY2VwdGlvbg0K XHBhciB9e1xmMSANClxwYXIgUC4gTWNJbnRvc2gsIEFyaXpvbmEgU3RhdGUgVW5pdmVyc2l0eSwg VVNBDQpccGFyIH17XGJcaVxmMSBLbm93bGVkZ2UgYWNxdWlzaXRpb24gdXNpbmcgVlJNTCBhbmQg dW5pZmllZCBtb2RlbGluZyBsYW5ndWFnZTogdGhlIGNhc2Ugb2YgdGhlIFJHQiBjb21wdXRlciBy b29tLg0KXHBhciB9e1xmMSANClxwYXIgQS4gUm91c3NlbCAmIEsuIFpyZWlrDQpccGFyIENORVQs IENhZW4sIFVuaXZlcnNpdHkgb2YgQ2FlbiwgRnJhbmNlDQpccGFyIH17XGJcaVxmMSBMYSBzdXBl cmNoYXJnZSBcJ2U5bGVjdHJvbmlxdWUgZW4gY29uY2VwdGlvbiAiTGUgUHJvamV0IEJBTEkiDQpc cGFyIH17XGYxIA0KXHBhciBILiBBaW5zbGV5LCBDLiBHaGFvdWkNClxwYXIgTGl2ZXJwb29sIEpv aG4gTW9vcmVzIFVuaXZlcml0eSwgVS5LLg0KXHBhciB9e1xiXGlcZjEgU3RydWN0dXJpbmcgaHlw ZXJtZWRpYSBsZWFybmluZyBtYXRlcmlhbCB0byBjb21tdW5pY2F0ZSBrbm93bGVkZ2UuDQpccGFy IH17XGYxIA0KXHBhciBFLiBIZW5yeSwgRC4gQm9pc3NpZXIsIEMuIEJvdWxlbWlhDQpccGFyIExB TUgsIENVU1QsIExBTUgsIEZyYW5jZQ0KXHBhciB9e1xiXGlcZjEgQWNxdWlzaXRpb24gZXQgZXh0 cmFjdGlvbiBkZXMgY29ubmFpc3NhbmNlcyBwb3VyIGxhIGdlbmVyYXRpb24gZGUgc3lzdGVtZXMg ZGUgZm9uZGF0aW9ucyBkZSBiYXRpbWVudHMuDQpccGFyIH17XGYxIA0KXHBhciANClxwYXIgfVxw YXJkXHBsYWluIFxzMVxrZWVwblx3aWRjdGxwYXJcb3V0bGluZWxldmVsMFxhZGp1c3RyaWdodCBc YlxmNFx1bFxsYW5nMTAzNlxjZ3JpZCB7XGYxIFNFU1NJT04gViA6IDE0aDMwIC0gMTZoMDANClxw YXIgfXtcaVxmMVx1bG5vbmUgQ1lCRVJERVNJR04gU09DSUFMIEZFQVRVUkVTDQpccGFyIH1ccGFy ZFxwbGFpbiBcd2lkY3RscGFyXGFkanVzdHJpZ2h0IFxmNFxsYW5nMTAzNlxjZ3JpZCB7XGJcY2Fw cyBDeWJlckNvbmNlcHRpb24gOiBhc3BlY3Qgc29jaWFsDQpccGFyIH17DQpccGFyIH17XGYxIEMu IFR3ZWVkDQpccGFyIFRoZSBRdWVlbidzIFVuaXZlcnNpdHkgb2YgQmVsZmFzdCwgTm9ydGhlcm4g SXJlbGFuZA0KXHBhciB9e1xiXGlcZjEgRGV2ZWxvcGluZyBhbiB1bmRlcnN0YW5kaW5nIG9mIHRo ZSBzb2NpYWwgY29udGV4dCBvZiBDQUFEIGluIHByYWN0aWNlLg0KXHBhciB9e1xmMSANClxwYXIg TS4gQ3Jvd2UsIFMuIEt5ZGQNClxwYXIgVW5pdmVyc2l0eSBvZiBQYWlzbGV5LCBVLksuDQpccGFy IH17XGJcaVxmMSBEZWxlZ2F0aW9uIGFuZCBpbnRlcmZlcmVuY2U6IHRoZSBwZXJzb25hbCB3b3Jr c3RhdGlvbiBhbmQgdGhlDQpccGFyIGNvcnBvcmF0ZSBuZXR3b3JrLg0KXHBhciB9e1xmMSANClxw YXIgTS4gU215dGgNClxwYXIgTmFwaWVyIFVuaXZlcnNpdHksIFUuSy4NClxwYXIgfXtcYlxpXGYx IFRoZSBhY3Rpdml0eSBvZiBkZXNpZ24gYXMgcmV2ZWFsZWQgYnkgdG9vbCB1c2FnZS4NClxwYXIg fXtcZjEgDQpccGFyIH17XGlcZjEgMTZoMDAgLSAxNmgzMCBDb2ZmZWUgQnJlYWt9e1xmMSAgLyBw YXVzZSBDYWZcJ2U5DQpccGFyIA0KXHBhciB9XHBhcmRccGxhaW4gXHMxXGtlZXBuXHdpZGN0bHBh clxvdXRsaW5lbGV2ZWwwXGFkanVzdHJpZ2h0IFxiXGY0XHVsXGxhbmcxMDM2XGNncmlkIHtcZjEg U0VTU0lPTiBWSVx+OiAoMTZoMzAgLSAxOGgwMCkNClxwYXIgfXtcZjFcdWxub25lIENZQkVSIEFS Q0hJVEVDVFVSQUwgREVTSUdOIExBTkdVQUdFUw0KXHBhciB9XHBhcmRccGxhaW4gXHdpZGN0bHBh clxhZGp1c3RyaWdodCBcZjRcbGFuZzEwMzZcY2dyaWQge1xiXGNhcHNcZjEgTGFuZ2FnZXMgZGUg bGEgY3liZXJjb25jZXB0aW9uIGFyY2hpdGVjdHVyYWxlDQpccGFyIH17XGYxIA0KXHBhciBBLlYu IE1vZXJlLCBILiBOZXVrZXJtYW5zLCBBLkhleWxpZ2hlbg0KXHBhciBLLlUuIExldXZlbiwgQmVs Z2lxdWUNClxwYXIgfXtcYlxpXGYxIFRoZSBsYW5ndWFnZSBvZiBDeWJlcnNwYWNlOiBhbiBhcmNo aXRlY3R1cmFsIGFwcHJvYWNoLg0KXHBhciB9e1xmMSANClxwYXIgUC4gU3phbGFwYWosIEQuIENo YW5nDQpccGFyIFVuaXZlcnNpdHkgb2YgU2hlZmZpZWxkLCBVLksuDQpccGFyIH17XGJcaVxmMSBD b21wdXRlciBBcmNoaXRlY3R1cmFsIFByZXNlbnRhdGlvbiAtIGZyb20gcGh5c2ljYWwgbW9kZWxz IGluIHNwYWNlIHRvIHZpcnR1YWwgbW9kZWxzIGluIGN5YmVyc3BhY2UuDQpccGFyIH17XGYxIA0K XHBhciBBLkJyaWRnZXMsIFQuRGltaXRyaW9zDQpccGFyIFVuaXZlcnNpdHkgb2YgU3RyYXRoY2x5 ZGUsIFUuSy4NClxwYXIgfXtcYlxpXGYxIFRoZSBpbXBhY3Qgb2YgZm9ybSBvbiBtb3ZlbWVudCB3 aXRoaW4gdmlydHVhbCBlbnZpcm9ubWVudHMuDQpccGFyIH17XGYxIA0KXHBhciANClxwYXIgDQpc cGFyIH1ccGFyZFxwbGFpbiBcczFca2VlcG5cd2lkY3RscGFyXG91dGxpbmVsZXZlbDBcYWRqdXN0 cmlnaHQgXGJcZjRcdWxcbGFuZzEwMzZcY2dyaWQge1xpXGYxIEZyaWRheSAyNy8xMS8xOTk4fXtc ZjEgIC8gVmVuZHJlZGkgMjcgTm92ZW1iZXIgMTk5OA0KXHBhciANClxwYXIgfVxwYXJkXHBsYWlu IFx3aWRjdGxwYXJcYWRqdXN0cmlnaHQgXGY0XGxhbmcxMDM2XGNncmlkIHtcZjEgDQpccGFyIH1c cGFyZFxwbGFpbiBcczFca2VlcG5cd2lkY3RscGFyXG91dGxpbmVsZXZlbDBcYWRqdXN0cmlnaHQg XGJcZjRcdWxcbGFuZzEwMzZcY2dyaWQge1xmMSBTRVNTSU9OIFZJSVx+OiAoOWgwMCAtIDEwaDMw KQ0KXHBhciB9e1xpXGYxXHVsbm9uZSBDWUJFUiBERVNJR04gREVDSVNJT04gU1VQUE9SVA0KXHBh ciB9XHBhcmRccGxhaW4gXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcZjRcbGFuZzEwMzZcY2dyaWQg e1xiXGNhcHNcZjEgQ3liZXIgZW52aXJvbm5lbWVudCBkJ2FpZGUgXCdlMCBsYSBEXCdlOWNpc2lv biBlbiBDb25jZXB0aW9uDQpccGFyIH17XGYxIA0KXHBhciBSLiBCZWhlc2h0aSwgUi4gTWljaGVs cw0KXHBhciBULlUuRGVsZnQsIHRoZSBOZXRoZXJsYW5kcw0KXHBhciB9e1xiXGlcZjEgVGhlIEds b2JhbCAgR0lTOiBhIGNhc2Ugc3R1ZHkuDQpccGFyIH17XGYxIA0KXHBhciBWLiBTcmRhbm92aWMs IE0uIEpvdmFub3ZpYywgRC4gTGVraWMNClxwYXIgVW5pdmVyc2l0eSBvZiBCZWxncmFkZSwgRi5I LkksIFl1Z29zbGF2aWENClxwYXIgfXtcYlxpXGYxIEFuIGFwcGxpY2F0aW9uIG9mIEdJUyB0ZWNo bm9sb2d5IG9mIGZsb29kIGNvbnRyb2wuDQpccGFyIH17XGYxIA0KXHBhciBOLiBFYmVsLCBKLkcu IEplYW5ub3QsIFkuQS4gUmVraWssIEouUC4gVmFkZXIsIEMuVmFub2lyYmVlaw0KXHBhciBFUEZM LCBTd2l0emVybGFuZA0KXHBhciB9e1xiXGlcZjEgQ0FEQU06IHRvd2FyZHMgYSB3ZWItYmFzZWQg aW5mb3JtYXRpb24gYW5kIGRlY2lzaW9uIHN1cHBvcnQgc3lzdGVtIGZvciBhcHByb3ByaWF0ZW5l c3MgaW4gbWVkaWNpbmUuDQpccGFyIH17XGYxIA0KXHBhciB9e1xpXGYxIDEwaDMwIC0gMTFoMDAg Q29mZmVlIEJyZWFrfXtcZjEgIC8gcGF1c2UgQ2FmXCdlOQ0KXHBhciANClxwYXIgfVxwYXJkXHBs YWluIFxzMVxrZWVwblx3aWRjdGxwYXJcb3V0bGluZWxldmVsMFxhZGp1c3RyaWdodCBcYlxmNFx1 bFxsYW5nMTAzNlxjZ3JpZCB7XGYxIFNFU1NJT05cflZJSUk6ICgxMWgwMC0xMmgzMCkNClxwYXIg fXtcaVxmMVx1bG5vbmUgQ1lCRVIgQ09NTVVOSUNBVElPTg0KXHBhciB9e1xmMVx1bG5vbmUgQ1lC RVIgQ09NTVVOSUNBVElPTg0KXHBhciB9XHBhcmRccGxhaW4gXHdpZGN0bHBhclxhZGp1c3RyaWdo dCBcZjRcbGFuZzEwMzZcY2dyaWQge1xmMSANClxwYXIgUy4gTmV3dG9uLCBKLiBSdXRoZXJmb3Jk DQpccGFyIFVuaXZlcnNpdHkgb2YgV2VzdGVybiBTeWRuZXksIFVuaXZlcnNpdHkgb2YgU3lkbmV5 DQpccGFyIH17XGJcaVxmMSBXaGF0IGZ1dHVyZSBmb3Igb25saW5lIGNvbW11bmljYXRpb24gZGVz aWduPw0KXHBhciB9e1xmMSANClxwYXIgUy5Hcm9zamVhbiwgUC4gRmV4bWVyLCBDLiBCcmFzc2Fj DQpccGFyIFVuaXZlc3JpdFwnZTkgZGUgTmFuY3ksIEZyYW5jZQ0KXHBhciB9e1xiXGlcZjEgQ2Vz ICJvdXRpbHMgcGh5Y2hvbGdpcXVlcyIgYXUgY29ldXIgZHUgcHJvY2Vzc3VzIGRlIGNvbmNlcHRp b24uDQpccGFyIH17XGYxIA0KXHBhciBHLiBWYXNxdWV6LCBFLiBBa2xlbWFuDQpccGFyIFRleGFz IEEmTSBVbml2ZXJzaXR5DQpccGFyIH17XGJcaVxmMSBBIGN1cnJpY3VsdW0gZm9yIHZpcnR1YWwg YXJjaGl0ZWN0dXJlLg0KXHBhciB9e1xmMSANClxwYXIgTS4gRW5nZWxpLCBQLiBTaWJlbmFsZXIN ClxwYXIgQXJjaGl0ZWN0dXJlIGFuZCBDQUFELCBTd2l0emVybGFuZA0KXHBhciB9e1xiXGlcZjEg RGlzY292ZXJpbmcgdGhlIGRpZ2l0YWwgdGVycml0b3J5DQpccGFyIH17XGYxIA0KXHBhciANClxw YXIgfVxwYXJkXHBsYWluIFxzMVxrZWVwblx3aWRjdGxwYXJcb3V0bGluZWxldmVsMFxhZGp1c3Ry aWdodCBcYlxmNFx1bFxsYW5nMTAzNlxjZ3JpZCB7XGYxIFNFU1NJT05cfklYIDogKDE0aDAwIC0g MTVoMzApDQpccGFyIH17XGlcZjFcdWxub25lIENZQkVSIERFU0lHTiBWUyBSRUFMIERFU0lHTg0K XHBhciB9XHBhcmRccGxhaW4gXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcZjRcbGFuZzEwMzZcY2dy aWQge1xiXGNhcHMgQ3liZXJDb25jZXB0aW9uIHZzIENvbmNlcHRpb24NClxwYXIgfXtcYlxjYXBz XGYxIA0KXHBhciB9e1xmMSBKLlAuIEdvdWxldHRlLCBTLiBNYXJxdWVzDQpccGFyIEVjb2xlIGQn QXJjaGl0ZWN0dXJlIGRlIFRvdWxvdXNlLCBGcmFuY2UsIFVGUEUsIEJyYXppbA0KXHBhciB9e1xi XGlcZjEgQmV0d2VlbiByZWFsIGFuZCB2aXJ0dWFsIHdvcmxkczogZGVzaWduIHN0dWRpZXMgaW4g Y3liZXJzcGFjZS4NClxwYXIgfXtcZjEgDQpccGFyIEwuIE1hZHJhem8sIEEuIFdlZGVyDQpccGFy IEUuVC5ILiBadXJpY2gsIFN3aXR6ZXJsYW5kDQpccGFyIH17XGJcaVxmMSBBQUxUTyBvbiB0aGUg aW50ZXJuZXQ6IGFyY2hpdGVjdHVyYWwgYW5hbHlzaXMgYW5kIGNvbmNlcHQgcmVwcmVzZW50YXRp b24gd2l0aCBjb21wdXRlciBtZWRpYS4NClxwYXIgfXtcZjEgDQpccGFyIFkuSy4gS2FuZywgSy5E LiBDaHVuZw0KXHBhciBQdXNhbiBOYXRpb25hbCBVbml2ZXJzaXR5LCBLb3JlYQ0KXHBhciB9e1xi XGlcZjEgTV9OT0Q6IERlc2lnbiBhbmQgYW5hbHlzaXMgb2YgbXVsdGltZWRpYSBuZXdzIG9uIGRl bWFuZCBzeXN0ZW0uDQpccGFyIA0KXHBhciB9e1xmMSBDLiBCcmFzc2FjLCBOLiBHcmVnb3JpLCBQ LiBSZW1vdXNzZW5hcmQNClxwYXIgVW5pdmVyc2l0eSBvZiBOYW5jeSwgRnJhbmNlDQpccGFyIH17 XGJcaVxmMSBUaGUgVXNlciBhcyBhbiBBY3RvciBmb3IgRWR1Y2F0aW9uYWwgTXVsdGltZWRpYSBT b2Z0d2FyZSBEZXNpZ24gUHJvY2Vzcw0KXHBhciB9e1xmMSANClxwYXIgfXtcaVxmMSAxNWgzMCAt IDE2aDAwIENvZmZlZSBCcmVha317XGYxICAvIHBhdXNlIENhZlwnZTkNClxwYXIgDQpccGFyIH1c cGFyZFxwbGFpbiBcczFca2VlcG5cd2lkY3RscGFyXG91dGxpbmVsZXZlbDBcYWRqdXN0cmlnaHQg XGJcZjRcdWxcbGFuZzEwMzZcY2dyaWQge1xmMSBTRVNTSU9OIFhcfjogDQpccGFyIE9OIExJTkUg Q09MTEFCT1JBVElWRSBERVNJR04gDQpccGFyIH1ccGFyZFxwbGFpbiBcd2lkY3RscGFyXGFkanVz dHJpZ2h0IFxmNFxsYW5nMTAzNlxjZ3JpZCB7XGJcY2FwcyBDb25jZXB0aW9uIGNvbGxhYm9yYXRp dmUNClxwYXIgfXtcZjEgDQpccGFyIE0uIEphYmFyDQpccGFyIFVuaXZlcnNpdHkgVGVsZWtvbSwg TWFsYXlzaWENClxwYXIgfXtcYlxpXGYxIERlc2lnbiBJbnNwZWN0b3IgYW5kIGNvbnN0cmFpbnQg aW50ZXJwb2xhdG9yIGluIGFzc2VtYmxlLWRpc2Fzc2VtYmxlIGNvbGxhYm9yYXRpdmUgZGVzaWdu IGZvciB0aGUgd29ybGQgd2lkZSBtYW51ZmFjdHVyaW5nIHdlYi4NClxwYXIgfXtcZjEgDQpccGFy IEMuIEJyYW5raSwgQi4gTGVlcywgQWlyZA0KXHBhciBVbml2ZXJzaXR5IG9mIFBhaXNsZXksIFUu Sy4NClxwYXIgfXtcYlxpXGYxIFRyYWNpbmcgV2ViIEJhc2VkIERlc2lnbiBDb25jZXJucw0KXHBh ciB9e1xmMSANClxwYXIgfVxwYXJkIFxxalx3aWRjdGxwYXJcYWRqdXN0cmlnaHQge1xmMSBWLiBC b3VyZGFraXMNClxwYXIgVW5pdmVyc2l0eSBvZiBCYXRoLiBVSw0KXHBhciB9e1xiXGlcZjEgVXRp bGlzaW5nIFVyYmFuIFZpcnR1YWwgRW52aXJvbm1lbnRzDQpccGFyIH1ccGFyZCBcd2lkY3RscGFy XGFkanVzdHJpZ2h0IHtcZjEgDQpccGFyIA0KXHBhciB9XHBhcmRccGxhaW4gXHMyXGtlZXBuXHdp ZGN0bHBhclxvdXRsaW5lbGV2ZWwxXGFkanVzdHJpZ2h0IFxiXGlcZjRcbGFuZzEwMzZcY2dyaWQg e1xpMFxmMVx1bCAxN2gzMFx+OiBDTE9UVVJFIA0KXHBhciB9XHBhcmRccGxhaW4gXHdpZGN0bHBh clxhZGp1c3RyaWdodCBcZjRcbGFuZzEwMzZcY2dyaWQge1xmMSANClxwYXIgfXtcYlxpXGYxIFBy b2Zlc3NvciBLLiBacmVpaywgfXtcYlxmMSBVbml2ZXJzaXRcJ2U5IGRlIENhZW4gOiBDLkEuRS5O IChHUkVZQywgTVJTSCkNClxwYXIgfXtcYlxpXGYxIEV1cm9wSUEgQ29uZmVyZW5jZXMgQ0hBSVJN QU4NClxwYXIgDQpccGFyIA0KXHBhciB9XHBhcmRccGxhaW4gXHMyNVxxY1x3aWRjdGxwYXJcYWRq dXN0cmlnaHQgXGYyXGZzMjBcY2dyaWQge1xiXGYzOVxmczI0IFxwYWdlIH17XGJcZjM5XGZzMzYg UkVHSVNUUkFUSU9OIEZPUk0gLyBJTlNDUklQVElPTg0KXHBhciB9e1xiXGYzOVxmczI0IA0KXHBh ciBFVVJPUElBICc5OCBDWUJFUkRFU0lHTg0KXHBhciANClxwYXIgUE9MRSBVTklWRVJTSVRBSVJF IExFT05BUkRPIERBIFZJTkNJDQpccGFyIA0KXHBhciBQQVJJUyA6IDI1LCAyNiwgMjcgTk9WRU1C RVINClxwYXIgfVxwYXJkIFxzMjVccWpcd2lkY3RscGFyXGFkanVzdHJpZ2h0IHtcZjM5XGZzMjQg DQpccGFyIA0KXHBhciB9e1xpXGYzOVxmczI0IE5BTUV9e1xmMzlcZnMyNCAgLyBOb20NClxwYXIg DQpccGFyIEFGRklMSUFUSU9OOg0KXHBhciANClxwYXIgfXtcaVxmMzlcZnMyNCBBRERSRVNTfXtc ZjM5XGZzMjQgIC8gQWRkcmVzc2UNClxwYXIgDQpccGFyIA0KXHBhciB9e1xpXGYzOVxmczI0IFBP U1QgQ09ERS1DSVRZfXtcZjM5XGZzMjQgIC8gQ29kZSBQb3N0YWwgVmlsbGUNClxwYXIgDQpccGFy IH17XGlcZjM5XGZzMjQgQ09VTlRSWX17XGYzOVxmczI0ICAvIFBheXM6DQpccGFyIA0KXHBhciAN ClxwYXIgDQpccGFyIH17XGJcaVxmMzlcZnMyNFx1bCBSRUdJU1RSQVRJT04gRkVFU317XGJcZjM5 XGZzMjRcdWwgOiBGcmFpcyBkJ0luc2NyaXB0aW9ufXtcZjM5XGZzMjQgDQpccGFyIH17XGlcZjM5 XGZzMjQgQVVUSE9SU317XGYzOVxmczI0ICAvIEF1dGV1cnNcdGFiIFx0YWIgXHRhYiAxNTUwRkYN ClxwYXIgfXtcaVxmMzlcZnMyNCBOT04gQVVUSE9SUyAvfXtcZjM5XGZzMjQgIE5vbi1BdXRldXJz XHRhYiAxOTUwRkZcdGFiIA0KXHBhciB9e1xpXGYzOVxmczI0IFNUVURFTlRTIC99e1xmMzlcZnMy NCAgRXR1ZGlhbnRzIDpcdGFiIFx0YWIgODAwRkYNClxwYXIgUGxlYXNlIG1ha2UgY2hlcXVlcyBw YXlhYmxlIHRvIDogICAgICBFdXJvcElBIFByb2R1Y3Rpb25zDQpccGFyIEFjY291bnQgTm86IFx0 YWIgXHRhYiBcdGFiIFx0YWIgMzAwMDIgMDA0NDIgMDAwMDAwNjk5MVogNTgNClxwYXIgQmFucXVl IDpcdGFiIFx0YWIgXHRhYiBcdGFiIENyZWRpdCBMeW9ubmFpcywgQWdlbmNlIFBhcmlzIE1hcmNl YXUNClxwYXIgXHRhYiBcdGFiIFx0YWIgXHRhYiBcdGFiIDQ0IEF2ZW51ZSBNYXJjZWF1DQpccGFy IFx0YWIgXHRhYiBcdGFiIFx0YWIgXHRhYiA3NTAwOCBQYXJpcywgRnJhbmNlDQpccGFyIA0KXHBh ciBQbGVhc2UgZW5zdXJlIHRoYXQgeW91ciBiYW5rIGNvdmVycyBhbnkgdHJhbnNmZXIgY2hhcmdl cy4NClxwYXIgDQpccGFyIH17XGlcZjM5XGZzMjQgVGhlIFN1YnNjcmlwdGlvbiBGb3JtIFNob3Vs ZCBiZSBzZW50IHRvfXtcZjM5XGZzMjQgIC8gSW5zY3JpcHRpb24sIENoXCdlOXF1ZXMgZXQgQm9u cyBkZSBDb21tYW5kZXMgZG9pdmVudCBcJ2VhdHJlIGFkcmVzc1wnZTlzIFwnZTAgOg0KXHBhciAN ClxwYXIgRXVyb3BpYSBQcm9kdWN0aW9ucw0KXHBhciAxNSwgYXZlbnVlIGRlIFNcJ2U5Z3VyDQpc cGFyIDc1MDA3IFBhcmlzDQpccGFyIFRlbCAoMzMpICgxKSA0NSA1MSAyNiAwNw0KXHBhciBGYXgg KDMzKSAoMSkgNDUgNTEgMjYgMzINClxwYXIgfXtlLW1haWw6IH17XGZpZWxke1wqXGZsZGluc3Qg eyBIWVBFUkxJTksgbWFpbHRvOmpwY291c2luQHdvcmxkbmV0LmZyIH17e1wqXGRhdGFmaWVsZCAN CjAwZDBjOWVhNzlmOWJhY2UxMThjODIwMGFhMDA0YmE5MGIwMjAwMDAwMDE3MDAwMDAwMTUwMDAw MDA2YTAwNzAwMDYzMDA2ZjAwNzUwMDczMDA2OTAwNmUwMDQwMDA3NzAwNmYwMDcyMDA2YzAwNjQw MDZlMDA2NTAwNzQwMDJlMDA2NjAwNzIwMDAwMDBlMGM5ZWE3OWY5YmFjZTExOGM4MjAwYWEwMDRi YTkwYjM4MDAwMDAwNmQwMDYxMDA2OTAwNmMwMDc0MDA2ZjAwM2EwMDZhMDA3MDAwNjMwMDZmMDA3 NTAwNzMwMDY5MDA2ZTAwNDAwMDc3MDA2ZjAwDQo3MjAwNmMwMDY0MDA2ZTAwNjUwMDc0MDAyZTAw NjYwMDcyMDAwMDAwMDAwMDAwMDAwMH19fXtcZmxkcnNsdCB7XGNzMjZcdWxcY2YyIGpwY291c2lu QHdvcmxkbmV0LmZyfX19e1xmMzlcZnMyNCAgIH17d2l0aCBhbiBlbWFpbCBjb3B5IHRvIG15c2Vs Zi4NClxwYXIgfXtcZjM5XGZzMjQgDQpccGFyIA0KXHBhciB9e1xiXGYzOVxmczI0XHVsIEhPVEVM Uw0KXHBhciB9e1xmMzlcZnMyNCBodHRwOi8vd3d3LmZyYW5jZS1ob3RlbC1ndWlkZS5jb20vNzVw YWNjdWUuaHRtDQpccGFyIGh0dHA6Ly93d3cudmlzaXQtcGFyaXMuY29tL2hvdGVscy9pbmRleC5o dG1sDQpccGFyIGh0dHA6Ly93d3cucGFyaXNlcnZlLnRtLmZyL2hvdGVsL2luZGV4Lmh0bQ0KXHBh ciANClxwYXIgfXtcYlxmMzlcZnMyNFx1bCBOLkI6IH17XGYzOVxmczI0ICBIb3RlbHMgbmV4dCB0 byB0aGUgbGluZSAxIG9mIHRoZSBtZXRybyAoQ2hhdGVhdSBkZSBWaW5jZW5uZSAtIExhIERlZmVu c2UpIG9yIHRoZSBSRVIgQSBhcmUgcmVjb21tZW5kZWQgKGkuZS4gbmV4dCB0byBFdG9pbGUsIENo YW1wcyBFbHlzZWVzLCBDb25jb3JkZSwgTG91dnJlLCBDaGF0ZWxldCwgQmFzdGlsbGUsDQpccGFy IFZlbmNlbm5lLCBldGMuKQ0KXHBhciANClxwYXIgfXtcYlxpXGYzOVxmczI0XHVsIFRyYW5zcG9y dGF0aW9ucyAoTUVUUk8sIFJFUiBhbmQgQnVzKX17XGYzOVxmczI0XHVsICAvIH17XGJcZjM5XGZz MjRcdWwgVHJhbnNwb3J0c317XGYzOVxmczI0XHVsIA0KXHBhciB9e1xmMzlcZnMyNCBodHRwOi8v d3d3LnJhdHAuZnIvDQpccGFyIGh0dHA6Ly93d3cucmF0cC5mci9UcmFuc3Bvci90cmFuc3BkZjEu aHRtDQpccGFyIGVpdGhlciBpbiBFbmdsaXNoIG9yIEZyZW5jaA0KXHBhciBNZXRybydzIG1hcDoN ClxwYXIgaHR0cDovL3d3dy5yYXRwLmZyL0ltYWdlcy9QZGYvbWV0cm8yLnBkZg0KXHBhciBSRVIn cyBNYXANClxwYXIgaHR0cDovL3d3dy5yYXRwLmZyL0ltYWdlcy9QZGYvcmVyLnBkZg0KXHBhciB9 XHBhcmRccGxhaW4gXHdpZGN0bHBhclxhZGp1c3RyaWdodCBcZjRcbGFuZzEwMzZcY2dyaWQge1xi XGlcZjEgDQpccGFyIH19 --=_BEE9AAF1.B5D4BB3A Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="EIAFPGM1.TXT" RVVST1BJQSAnOTggIDogQ1lCRVJERVNJR04NCk1lZGlhLCBDb21tdW5pY2F0aW9uICYgRGVzaWdu IFByYWN0aWNlDQpNZWRpYSAmIENvbW11bmljYXRpb24gZGFucyBsYSBQcmF0aXF1ZSBkZSBsYSBD b25jZXB0aW9uDQoNClNldmVudGggSW50ZXJuYXRpb25hbCBDb25mZXJlbmNlIG9uIHRoZSBBcHBs aWNhdGlvbi9JbXBsaWNhdGlvbnMgb2YgQ29tcHV0ZXIgTmV0d29ya2luZyBpbiBBcmNoaXRlY3R1 cmUsIENvbnN0cnVjdGlvbiwgRGVzaWduLCBDaXZpbCBFbmdpbmVlcmluZyBhbmQgVXJiYW4gUGxh bm5pbmcNCg0KU2VwdGnobWUgQ29sbG9xdWUgSW50ZXJuYXRpb25hbCBzdXIgbGVzIGFwcGxpY2F0 aW9ucyBldCBsZXMgaW1wbGljYXRpb25zIGRlcyBub3V2ZWxsZXMgdGVjaG5vbG9naWVzIGRlIGwn aW5mb3JtYXRpb24gZXQgZGUgbGEgY29tbXVuaWNhdGlvbiBlbiBBcmNoaXRlY3R1cmUsIENvbnN0 cnVjdGlvbiBldCBlbiBQbGFuaWZpY2F0aW9uIFVyYmFpbmUNCg0KT3JnYW5pc2VkIGJ5IC8gT3Jn YW5pc+kgcGFyOg0KVW5pdmVyc2l0eSBvZiBQYWlzbGV5IDogRGVwYXJ0bWVudCBvZiBDb21wdXRp bmcgYW5kIEluZm9ybWF0aW9uIFN5c3RlbQ0KVW5pdmVyc2l06SBkZSBDYWVuIDogQy5BLkUuTiAo R1JFWUMsIE1SU0gpDQpQ9GxlIFVuaXZlcnNpdGFpcmUgTOlvbmFyZCBEZSBWaW5jaSA6IElGQU1J RiwgUGFyaXMgbGEgROlmZW5zZQ0KRXVyb3BpYSBQcm9kdWN0aW9ucywgUGFyaXMNCg0KDQpQQVJJ UyA6IDI1LCAyNiwgMjcgTk9WRU1CRVINClD0bGUgVW5pdmVyc2l0YWlyZSBM6W9uYXJkIGRlIFZp bmNpDQpQYXJpcyBsYSBE6WZlbnNlDQoNCldlZG5lc2RheSAyNS8xMS8xOTk4IC8gTWVyY3JlZGkg MjUgTm92ZW1icmUgMTk5OA0KDQpPcGVubmluZyBTZXNzaW9uIC8gT3V2ZXJ0dXJlIGR1IENvbGxv cXVlIC0gVmlkZW8gQ29uZmVyZW5jZQ0KDQo5aDAwIC0gOWgxNSAJRHIuIENoZXJpZiBCUkFOS0ks IFVuaXZlcnNpdHkgb2YgUGFpc2xleSwgRUlBJzk4IENoYWlybWFuDQoNCjloIDE1IC0gOWg0NSAJ TS4gUmljaGFyZCBTSEFXLCBQcm9mZXNzb3IsIFByaW5jaXBhbCBvZiBUaGUgVW5pdmVyc2l0eSBv ZiBQYWlzbGV5DQoNCjloIDQ1IC0gMTBoMDUgCU0uIE1pY2hlbCBCQVJBVCwgRGlyZWN0ZXVyIEfp bulyYWwgZHUgUPRsZSBVbml2ZXJzaXRhaXJlIEzpb25hcmQgZGUgVmluY2kNCg0KMTBoMDUgLSAx MGYxNSAJTS4gQ2hyaXN0aWFuIFNBTkRFUiwgRGlyZWN0ZXVyIGRlIGwnSUZBTUlGDQoNCjEwaDE1 IC0gMTBoNDUJSW52aXRlZCBTcGVha2VyIC8gQ29uZulyZW5jZSBpbnZpdOllDQpNLiBNLiBM6Wds aXNlLCBQcm9mZXNzZXVyLCBFY29sZSBkJ0FyY2hpdGVjdHVyZSBkZSBUb3Vsb3VzZQ0KQ29uc3Rp dHV0aW9uIGQndW5lIG3pbW9pcmUgcGVyc29ubmVsbGUg4CBwYXJ0aXIgZGUgcmVwculzZW50YXRp b25zIGRpc3PpbWlu6WVzLiANCg0KMTBoNDUgLSAxMWgxNSBDb2ZmZWUgQnJlYWsgLyBQYXVzZSBD YWbpDQoNClNFU1NJT04gSSAoU2hvcnQgcGFwZXJzIC8gY29tbXVuaWNhdGlvbnMgY291cnRlcyA6 IDExaDE1IC0gMTJoMzApDQpDWUJFUiBERVNJR04gRU5WSVJPTk1FTlQgVlMgUkVBTCBERVNJR04g RU5WSVJPTk1FTlQgDQoNCk0uIENyb3dlLCAgUy4gS3lkZA0KVW5pdmVyc2l0eSBvZiBQYWlzbGV5 LCBVSw0KQWdlbnRzIGFuZCBzdWdnZXN0aW9ucyBpbiBhIFdlYi1iYXNlZCBkeW5hbWljIHdvcmtm bG93IG1vZGVsLg0KDQpOLiBCYXVwaW4gJiAgSy4gWnJlaWsNCkNORVQsIENhZW4sIFVuaXZlcnNp dHkgb2YgQ2FlbiwgRnJhbmNlDQpU6WzpZGVjaXNpb246IE4uVC5JLkMuIGV0IGNvbmNlcHRpb24g Y29vcGVyYXRpdmUuDQoNCk0uIENsYXl0b24NClRleGFzIEEmTSBVbml2ZXJzaXR5LCBVU0ENCkRp c3RyaWJ1dGVkIGRlc2lnbiBrbm93bGVkZ2UgdXNpbmcgZm9ybSwgZnVuY3Rpb24gYW5kIGJlaGF2 aW91cg0KDQpZLiBSZXplDQpVbml2ZXJzaXTpIG9mIENhZW4sIEZyYW5jZSwNCkwnaHlwZXJtZWRp YTogdW5lIGF1dHJlIGZhY29uIGRlIHJlcHJlc2VudGVyLg0KDQpDLiBERVNIQVlFUw0KRWNvbGUg ZCdBcmNoaXRlY3R1cmUgZGUgUGFyaXMtVmFsLURlLU1Bcm5lLCBGcmFuY2UNClBlcmNlcHRpb24g c3BhdGlhbGUgZCd1biBlbnZpcm9ubWVudCBhcmNoaXRlY3R1cmFsOiBhc3BlY3RzDQppbmZvcm1h dGlvbm5lbCBldCBjb21tdW5pY2F0aW9ubmVsLg0KDQoNClNFU1NJT04gSUkgKFNob3J0IHBhcGVy cyAvIGNvbW11bmljYXRpb25zIGNvdXJ0ZXMgOiAxNGgwMCAtIDE1aDE1KQ0KV0VCIEJBU0VEIERF U0lHTg0KSU5URVJORVQgREFOUyBMQSBQUkFUSVFVRSBERSBMQSBDT05DRVBUSU9ODQpOLiBLYXJh Y2FwaWxpZGlzLCBPLiBBYm91IEtoYWxlZA0KRVBGTCwgU3dpdHplcmxhbmQNCkVzdGFibGlzaGlu ZyBjb21tdW5pY2F0aW9uIGJldHdlZW4gYSB3ZWItYmFzZWQgYXJndW1lbnRhdGlvbg0KYW5kIHJl bW90ZSBkYXRhYmFzZXMNCg0KRi4gQW1lemlhbmUsIFMuIExhc3NlcnJlDQpFY29sZSBkJ0FyY2hp dGVjdHVyZSBkZSBNYXJzZWlsbGUgLCBGcmFuY2UNCkJ1aWxkaW5nIGluZm9ybWF0aW9uIGluIGNv b3BlcmF0aXZlIHByb2R1Y3Rpb24gY29udGV4dA0KDQpNLiBCb3ViZWtyaQ0KVW5pdmVyc2l0eSBv ZiBJbGxpbm9pcywgVVNBDQpDb21wdXRlciBOZXR3b3JraW5nIGFuZCBMaWdodGluZyBEZXNpZ24g SW5zdHJ1Y3Rpb24uDQoNCkcuIFZhc3F1ZXogZGUgVmVsYXNjbywgTi4gSG9sbGFuZA0KVGV4YXMg QSZNIFVuaXZlcnNpdHksIFVTQQ0KQ29tcHV0ZXIgbWVkaWF0ZWQgcmVjaXByb2NhbCBkaXN0YW5j ZSBlZHVjYXRpb24uDQoNClAuIFZhbiBkZXIgVmVlciwgSS5TLlNhcml5aWxkaXosINYuIENpZnRj aW9nbHUNCkRlbGZ0IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neSwgVGhlIE5ldGhlcmxhbmRzDQpP cmRlcmluZyBvZiBJbmZvcm1hdGlvbiBhbmQgRnVuY3Rpb25hbGl0eSBmb3IgZGVjaXNpb24gc3Vw cG9ydCBpbg0KYnVpbGRpbmcgZGVzaWduLg0KDQpQT1NURVJTICYgUmFmcmHuY2hpc3NlbWVudCAo MTVoMTUgLSAxN2gxNSkNCg0KVEhVU0RBWSAyNi8xMS8xOTk4IC8gSmV1ZGkgMjYgTm92ZW1icmUg MTk5OA0KDQoNClNFU1NJT04gSUlJIDogICg5aDAwIC0gMTBoMzApDQpPTiBMSU5FIERJU1RSSUJV VEVEIERFU0lHTiBFTlZJUk9OTUVOVA0KRU5WSVJPTk5FTUVOVCBEWU5BTUlRVUUgUE9VUiBMQSBD T05DRVBUSU9OIENPT1BFUkFUSVZFDQoNClIuIENveW5lLCBKLiBMZWUsIEQuIER1bmNhbiwgUy4g T2ZsdW9nbHUNClVuaXZlcnNpdHkgb2YgRWRpbmJ1cmdoLCBVSw0KQXBwbHlpbmcgd2ViLWJhc2Vk IHByb2R1Y3QgbGlicmFyaWVzLg0KDQoNCkwuIE1hcnRpbiwgVGhlIEplcmRlIFBhcnRuZXJzaGlw IEludGVybmF0aW9uYWwgSW5jLiwgVVNBIA0KQXJjaGl0ZWN0dXJlIGluIGRpZ2l0YWwgZG9tYWlu OiBmcm9tIGFyY3RpYyBpbWFnZXMgdG8gZGVzZXJ0DQpkcmVhbWxhbmRzLg0KDQpCYXJrb3dza2ks IEMuIEJyYW5raSwgRS4gR3JhYnNrYSwgVy4gUGFsYWN6DQpVbml2ZXJzaXR5IG9mIFBhaXNsZXks IFUuSy4sIElGVFJTLCBQb2xhbmQsIElDUywgUG9sYW5kDQpUb3dhcmRzIGNvbGxhYm9yYXRpdmUg ZHNlaWduLg0KDQoxMGgzMCAtIDExaDAwIENvZmZlZSBCcmVhayAvIHBhdXNlIENhZukNCg0KU0VT U0lPTiBJVjogKDExaDAwLTEzaDAwKQ0KREFUQSBBQ1FVSVNJVElPTiBDWUJFUlNQQUNFDQpDWUJF Ui1FU1BBQ0VTIFBPVVIgTCdBQ1FVSVNJVElPTiBERVMgRE9OTkVFUyBFTiBDT05DRVBUSU9ODQoN ClAuIE1jSW50b3NoLCBBcml6b25hIFN0YXRlIFVuaXZlcnNpdHksIFVTQQ0KS25vd2xlZGdlIGFj cXVpc2l0aW9uIHVzaW5nIFZSTUwgYW5kIHVuaWZpZWQgbW9kZWxpbmcgbGFuZ3VhZ2U6IHRoZSBj YXNlIG9mIHRoZSBSR0IgY29tcHV0ZXIgcm9vbS4NCg0KQS4gUm91c3NlbCAmIEsuIFpyZWlrDQpD TkVULCBDYWVuLCBVbml2ZXJzaXR5IG9mIENhZW4sIEZyYW5jZQ0KTGEgc3VwZXJjaGFyZ2Ug6Wxl Y3Ryb25pcXVlIGVuIGNvbmNlcHRpb24gIkxlIFByb2pldCBCQUxJIg0KDQpILiBBaW5zbGV5LCBD LiBHaGFvdWkNCkxpdmVycG9vbCBKb2huIE1vb3JlcyBVbml2ZXJpdHksIFUuSy4NClN0cnVjdHVy aW5nIGh5cGVybWVkaWEgbGVhcm5pbmcgbWF0ZXJpYWwgdG8gY29tbXVuaWNhdGUga25vd2xlZGdl Lg0KDQpFLiBIZW5yeSwgRC4gQm9pc3NpZXIsIEMuIEJvdWxlbWlhDQpMQU1ILCBDVVNULCBMQU1I LCBGcmFuY2UNCkFjcXVpc2l0aW9uIGV0IGV4dHJhY3Rpb24gZGVzIGNvbm5haXNzYW5jZXMgcG91 ciBsYSBnZW5lcmF0aW9uIGRlIHN5c3RlbWVzIGRlIGZvbmRhdGlvbnMgZGUgYmF0aW1lbnRzLg0K DQoNClNFU1NJT04gViA6IDE0aDMwIC0gMTZoMDANCkNZQkVSREVTSUdOIFNPQ0lBTCBGRUFUVVJF Uw0KQ1lCRVJDT05DRVBUSU9OIDogQVNQRUNUIFNPQ0lBTA0KDQpDLiBUd2VlZA0KVGhlIFF1ZWVu J3MgVW5pdmVyc2l0eSBvZiBCZWxmYXN0LCBOb3J0aGVybiBJcmVsYW5kDQpEZXZlbG9waW5nIGFu IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHNvY2lhbCBjb250ZXh0IG9mIENBQUQgaW4gcHJhY3RpY2Uu DQoNCk0uIENyb3dlLCBTLiBLeWRkDQpVbml2ZXJzaXR5IG9mIFBhaXNsZXksIFUuSy4NCkRlbGVn YXRpb24gYW5kIGludGVyZmVyZW5jZTogdGhlIHBlcnNvbmFsIHdvcmtzdGF0aW9uIGFuZCB0aGUN CmNvcnBvcmF0ZSBuZXR3b3JrLg0KDQpNLiBTbXl0aA0KTmFwaWVyIFVuaXZlcnNpdHksIFUuSy4N ClRoZSBhY3Rpdml0eSBvZiBkZXNpZ24gYXMgcmV2ZWFsZWQgYnkgdG9vbCB1c2FnZS4NCg0KMTZo MDAgLSAxNmgzMCBDb2ZmZWUgQnJlYWsgLyBwYXVzZSBDYWbpDQoNClNFU1NJT04gVkkgOiAoMTZo MzAgLSAxOGgwMCkNCkNZQkVSIEFSQ0hJVEVDVFVSQUwgREVTSUdOIExBTkdVQUdFUw0KTEFOR0FH RVMgREUgTEEgQ1lCRVJDT05DRVBUSU9OIEFSQ0hJVEVDVFVSQUxFDQoNCkEuVi4gTW9lcmUsIEgu IE5ldWtlcm1hbnMsIEEuSGV5bGlnaGVuDQpLLlUuIExldXZlbiwgQmVsZ2lxdWUNClRoZSBsYW5n dWFnZSBvZiBDeWJlcnNwYWNlOiBhbiBhcmNoaXRlY3R1cmFsIGFwcHJvYWNoLg0KDQpQLiBTemFs YXBhaiwgRC4gQ2hhbmcNClVuaXZlcnNpdHkgb2YgU2hlZmZpZWxkLCBVLksuDQpDb21wdXRlciBB cmNoaXRlY3R1cmFsIFByZXNlbnRhdGlvbiAtIGZyb20gcGh5c2ljYWwgbW9kZWxzIGluIHNwYWNl IHRvIHZpcnR1YWwgbW9kZWxzIGluIGN5YmVyc3BhY2UuDQoNCkEuQnJpZGdlcywgVC5EaW1pdHJp b3MNClVuaXZlcnNpdHkgb2YgU3RyYXRoY2x5ZGUsIFUuSy4NClRoZSBpbXBhY3Qgb2YgZm9ybSBv biBtb3ZlbWVudCB3aXRoaW4gdmlydHVhbCBlbnZpcm9ubWVudHMuDQoNCg0KDQpGcmlkYXkgMjcv MTEvMTk5OCAvIFZlbmRyZWRpIDI3IE5vdmVtYmVyIDE5OTgNCg0KDQpTRVNTSU9OIFZJSSA6ICg5 aDAwIC0gMTBoMzApDQpDWUJFUiBERVNJR04gREVDSVNJT04gU1VQUE9SVA0KQ1lCRVIgRU5WSVJP Tk5FTUVOVCBEJ0FJREUgQSBMQSBERUNJU0lPTiBFTiBDT05DRVBUSU9ODQoNClIuIEJlaGVzaHRp LCBSLiBNaWNoZWxzDQpULlUuRGVsZnQsIHRoZSBOZXRoZXJsYW5kcw0KVGhlIEdsb2JhbCAgR0lT OiBhIGNhc2Ugc3R1ZHkuDQoNClYuIFNyZGFub3ZpYywgTS4gSm92YW5vdmljLCBELiBMZWtpYw0K VW5pdmVyc2l0eSBvZiBCZWxncmFkZSwgRi5ILkksIFl1Z29zbGF2aWENCkFuIGFwcGxpY2F0aW9u IG9mIEdJUyB0ZWNobm9sb2d5IG9mIGZsb29kIGNvbnRyb2wuDQoNCk4uIEViZWwsIEouRy4gSmVh bm5vdCwgWS5BLiBSZWtpaywgSi5QLiBWYWRlciwgQy5WYW5vaXJiZWVrDQpFUEZMLCBTd2l0emVy bGFuZA0KQ0FEQU06IHRvd2FyZHMgYSB3ZWItYmFzZWQgaW5mb3JtYXRpb24gYW5kIGRlY2lzaW9u IHN1cHBvcnQgc3lzdGVtIGZvciBhcHByb3ByaWF0ZW5lc3MgaW4gbWVkaWNpbmUuDQoNCjEwaDMw IC0gMTFoMDAgQ29mZmVlIEJyZWFrIC8gcGF1c2UgQ2Fm6Q0KDQpTRVNTSU9OIFZJSUk6ICgxMWgw MC0xMmgzMCkNCkNZQkVSIENPTU1VTklDQVRJT04NCkNZQkVSIENPTU1VTklDQVRJT04NCg0KUy4g TmV3dG9uLCBKLiBSdXRoZXJmb3JkDQpVbml2ZXJzaXR5IG9mIFdlc3Rlcm4gU3lkbmV5LCBVbml2 ZXJzaXR5IG9mIFN5ZG5leQ0KV2hhdCBmdXR1cmUgZm9yIG9ubGluZSBjb21tdW5pY2F0aW9uIGRl c2lnbj8NCg0KUy5Hcm9zamVhbiwgUC4gRmV4bWVyLCBDLiBCcmFzc2FjDQpVbml2ZXNyaXTpIGRl IE5hbmN5LCBGcmFuY2UNCkNlcyAib3V0aWxzIHBoeWNob2xnaXF1ZXMiIGF1IGNvZXVyIGR1IHBy b2Nlc3N1cyBkZSBjb25jZXB0aW9uLg0KDQpHLiBWYXNxdWV6LCBFLiBBa2xlbWFuDQpUZXhhcyBB Jk0gVW5pdmVyc2l0eQ0KQSBjdXJyaWN1bHVtIGZvciB2aXJ0dWFsIGFyY2hpdGVjdHVyZS4NCg0K TS4gRW5nZWxpLCBQLiBTaWJlbmFsZXINCkFyY2hpdGVjdHVyZSBhbmQgQ0FBRCwgU3dpdHplcmxh bmQNCkRpc2NvdmVyaW5nIHRoZSBkaWdpdGFsIHRlcnJpdG9yeQ0KDQoNClNFU1NJT04gSVggOiAo MTRoMDAgLSAxNWgzMCkNCkNZQkVSIERFU0lHTiBWUyBSRUFMIERFU0lHTg0KQ1lCRVJDT05DRVBU SU9OIFZTIENPTkNFUFRJT04NCg0KSi5QLiBHb3VsZXR0ZSwgUy4gTWFycXVlcw0KRWNvbGUgZCdB cmNoaXRlY3R1cmUgZGUgVG91bG91c2UsIEZyYW5jZSwgVUZQRSwgQnJhemlsDQpCZXR3ZWVuIHJl YWwgYW5kIHZpcnR1YWwgd29ybGRzOiBkZXNpZ24gc3R1ZGllcyBpbiBjeWJlcnNwYWNlLg0KDQpM LiBNYWRyYXpvLCBBLiBXZWRlcg0KRS5ULkguIFp1cmljaCwgU3dpdHplcmxhbmQNCkFBTFRPIG9u IHRoZSBpbnRlcm5ldDogYXJjaGl0ZWN0dXJhbCBhbmFseXNpcyBhbmQgY29uY2VwdCByZXByZXNl bnRhdGlvbiB3aXRoIGNvbXB1dGVyIG1lZGlhLg0KDQpZLksuIEthbmcsIEsuRC4gQ2h1bmcNClB1 c2FuIE5hdGlvbmFsIFVuaXZlcnNpdHksIEtvcmVhDQpNX05PRDogRGVzaWduIGFuZCBhbmFseXNp cyBvZiBtdWx0aW1lZGlhIG5ld3Mgb24gZGVtYW5kIHN5c3RlbS4NCg0KQy4gQnJhc3NhYywgTi4g R3JlZ29yaSwgUC4gUmVtb3Vzc2VuYXJkDQpVbml2ZXJzaXR5IG9mIE5hbmN5LCBGcmFuY2UNClRo ZSBVc2VyIGFzIGFuIEFjdG9yIGZvciBFZHVjYXRpb25hbCBNdWx0aW1lZGlhIFNvZnR3YXJlIERl c2lnbiBQcm9jZXNzDQoNCjE1aDMwIC0gMTZoMDAgQ29mZmVlIEJyZWFrIC8gcGF1c2UgQ2Fm6Q0K DQpTRVNTSU9OIFggOiANCk9OIExJTkUgQ09MTEFCT1JBVElWRSBERVNJR04gDQpDT05DRVBUSU9O IENPTExBQk9SQVRJVkUNCg0KTS4gSmFiYXINClVuaXZlcnNpdHkgVGVsZWtvbSwgTWFsYXlzaWEN CkRlc2lnbiBJbnNwZWN0b3IgYW5kIGNvbnN0cmFpbnQgaW50ZXJwb2xhdG9yIGluIGFzc2VtYmxl LWRpc2Fzc2VtYmxlIGNvbGxhYm9yYXRpdmUgZGVzaWduIGZvciB0aGUgd29ybGQgd2lkZSBtYW51 ZmFjdHVyaW5nIHdlYi4NCg0KQy4gQnJhbmtpLCBCLiBMZWVzLCBBaXJkDQpVbml2ZXJzaXR5IG9m IFBhaXNsZXksIFUuSy4NClRyYWNpbmcgV2ViIEJhc2VkIERlc2lnbiBDb25jZXJucw0KDQpWLiBC b3VyZGFraXMNClVuaXZlcnNpdHkgb2YgQmF0aC4gVUsNClV0aWxpc2luZyBVcmJhbiBWaXJ0dWFs IEVudmlyb25tZW50cw0KDQoNCjE3aDMwIDogQ0xPVFVSRSANCg0KUHJvZmVzc29yIEsuIFpyZWlr LCBVbml2ZXJzaXTpIGRlIENhZW4gOiBDLkEuRS5OIChHUkVZQywgTVJTSCkNCkV1cm9wSUEgQ29u ZmVyZW5jZXMgQ0hBSVJNQU4NCg0KDQoNClJFR0lTVFJBVElPTiBGT1JNIC8gSU5TQ1JJUFRJT04N Cg0KRVVST1BJQSAnOTggQ1lCRVJERVNJR04NCg0KUE9MRSBVTklWRVJTSVRBSVJFIExFT05BUkRP IERBIFZJTkNJDQoNClBBUklTIDogMjUsIDI2LCAyNyBOT1ZFTUJFUg0KDQoNCk5BTUUgLyBOb20N Cg0KQUZGSUxJQVRJT046DQoNCkFERFJFU1MgLyBBZGRyZXNzZQ0KDQoNClBPU1QgQ09ERS1DSVRZ IC8gQ29kZSBQb3N0YWwgVmlsbGUNCg0KQ09VTlRSWSAvIFBheXM6DQoNCg0KDQpSRUdJU1RSQVRJ T04gRkVFUzogRnJhaXMgZCdJbnNjcmlwdGlvbg0KQVVUSE9SUyAvIEF1dGV1cnMJCQkxNTUwRkYN Ck5PTiBBVVRIT1JTIC8gTm9uLUF1dGV1cnMJMTk1MEZGCQ0KU1RVREVOVFMgLyBFdHVkaWFudHMg OgkJODAwRkYNClBsZWFzZSBtYWtlIGNoZXF1ZXMgcGF5YWJsZSB0byA6ICAgICAgRXVyb3BJQSBQ cm9kdWN0aW9ucw0KQWNjb3VudCBObzogCQkJCTMwMDAyIDAwNDQyIDAwMDAwMDY5OTFaIDU4DQpC YW5xdWUgOgkJCQlDcmVkaXQgTHlvbm5haXMsIEFnZW5jZSBQYXJpcyBNYXJjZWF1DQoJCQkJCTQ0 IEF2ZW51ZSBNYXJjZWF1DQoJCQkJCTc1MDA4IFBhcmlzLCBGcmFuY2UNCg0KUGxlYXNlIGVuc3Vy ZSB0aGF0IHlvdXIgYmFuayBjb3ZlcnMgYW55IHRyYW5zZmVyIGNoYXJnZXMuDQoNClRoZSBTdWJz Y3JpcHRpb24gRm9ybSBTaG91bGQgYmUgc2VudCB0byAvIEluc2NyaXB0aW9uLCBDaOlxdWVzIGV0 IEJvbnMgZGUgQ29tbWFuZGVzIGRvaXZlbnQg6nRyZSBhZHJlc3PpcyDgIDoNCg0KRXVyb3BpYSBQ cm9kdWN0aW9ucw0KMTUsIGF2ZW51ZSBkZSBT6Wd1cg0KNzUwMDcgUGFyaXMNClRlbCAoMzMpICgx KSA0NSA1MSAyNiAwNw0KRmF4ICgzMykgKDEpIDQ1IDUxIDI2IDMyDQplLW1haWw6IGpwY291c2lu QHdvcmxkbmV0LmZyICB3aXRoIGFuIGVtYWlsIGNvcHkgdG8gbXlzZWxmLg0KDQoNCkhPVEVMUw0K aHR0cDovL3d3dy5mcmFuY2UtaG90ZWwtZ3VpZGUuY29tLzc1cGFjY3VlLmh0bQ0KaHR0cDovL3d3 dy52aXNpdC1wYXJpcy5jb20vaG90ZWxzL2luZGV4Lmh0bWwNCmh0dHA6Ly93d3cucGFyaXNlcnZl LnRtLmZyL2hvdGVsL2luZGV4Lmh0bQ0KDQpOLkI6ICBIb3RlbHMgbmV4dCB0byB0aGUgbGluZSAx IG9mIHRoZSBtZXRybyAoQ2hhdGVhdSBkZSBWaW5jZW5uZSAtIExhIERlZmVuc2UpIG9yIHRoZSBS RVIgQSBhcmUgcmVjb21tZW5kZWQgKGkuZS4gbmV4dCB0byBFdG9pbGUsIENoYW1wcyBFbHlzZWVz LCBDb25jb3JkZSwgTG91dnJlLCBDaGF0ZWxldCwgQmFzdGlsbGUsDQpWZW5jZW5uZSwgZXRjLikN Cg0KVHJhbnNwb3J0YXRpb25zIChNRVRSTywgUkVSIGFuZCBCdXMpIC8gVHJhbnNwb3J0cw0KaHR0 cDovL3d3dy5yYXRwLmZyLw0KaHR0cDovL3d3dy5yYXRwLmZyL1RyYW5zcG9yL3RyYW5zcGRmMS5o dG0NCmVpdGhlciBpbiBFbmdsaXNoIG9yIEZyZW5jaA0KTWV0cm8ncyBtYXA6DQpodHRwOi8vd3d3 LnJhdHAuZnIvSW1hZ2VzL1BkZi9tZXRybzIucGRmDQpSRVIncyBNYXANCmh0dHA6Ly93d3cucmF0 cC5mci9JbWFnZXMvUGRmL3Jlci5wZGYNCg0K --=_BEE9AAF1.B5D4BB3A-- From rem-conf Thu Oct 22 13:19:34 1998 From rem-conf-request@es.net Thu Oct 22 13:19:33 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zWR3p-0004Ce-00; Thu, 22 Oct 1998 13:10:17 -0700 Received: from mail.aceltd.com (ace-pdc.aceltd.com) [38.200.249.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zWR3n-0004CU-00; Thu, 22 Oct 1998 13:10:15 -0700 Received: by ACE-PDC with Internet Mail Service (5.0.1460.8) id ; Thu, 22 Oct 1998 16:09:17 -0400 Message-ID: <237BD340B58ED111857500A0C99DBA9C149F27@ACE-PDC> From: Robert Kaplan To: "'rem-conf@es.net'" Subject: remove Date: Thu, 22 Oct 1998 16:09:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list remove rkaplan@aceltd.com Robert Kaplan Director of Product Development 14101 Sullyfield Circle Chantilly, Va 20151 (P) 703-968-5700 (F) 703-968-4331 From rem-conf Thu Oct 22 17:09:57 1998 From rem-conf-request@es.net Thu Oct 22 17:09:57 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zWUh5-0006sS-00; Thu, 22 Oct 1998 17:03:03 -0700 Received: from acsys.anu.edu.au [150.203.20.41] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zWUh3-0006rG-00; Thu, 22 Oct 1998 17:03:02 -0700 Received: from accordion (accordion [150.203.20.58]) by acsys.anu.edu.au (8.9.1/8.9.1) with SMTP id KAA24448; Fri, 23 Oct 1998 10:01:21 +1000 (EST) Message-Id: <3.0.32.19981023100145.00988ec0@acsys.anu.edu.au> X-Sender: markus@acsys.anu.edu.au X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 23 Oct 1998 10:01:46 +1000 To: Angel Mateo , rem-conf@es.net From: Markus Buchhorn Subject: Re: User control for mbone Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Angel > We have several LANS and we are intrested in deploy, install or configure a >mechanism to be able to control the users that connects to the MBone. What we >want to do is to configure our network to: > >* All the users can connect and join to an MBone session. >* Only authoriced people can create sessions. > Does any way to do this? I think the easy answer is no - if you have a multicast infrastructure in place for people to join and participate in the MBONE then there is no way to stop those same people sending session advertisement packets (from whatever tools they choose, or even write themselves) to that same infrastructure. One also can create meetings/conferences by emailing round a specific multicast IP address/port and never advertise it through the sap system anyway. Now, I could imagine restricting your feed to be one way, so people can join and listen/view sessions but not transmit to it - and then locally-created session advertisements will only be advertised on your network and not to the world. Or you could put filters on your network boundary to look for sap packets and block them. Perhaps that would even work across your LANs but it's an ugly approach (and wouldn't work on an individual LAN). Why do you want to do this? sap/sdp isn't exactly a bandwidth hog so is there another reason ? Cheers, Markus Markus Buchhorn, Advanced Computational Systems CRC | Ph: +61 2 62798810 email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602 Australian National University, Canberra 0200, Australia |Mobile: 0417 281429 From rem-conf Thu Oct 22 23:53:44 1998 From rem-conf-request@es.net Thu Oct 22 23:53:44 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zWate-0003ER-00; Thu, 22 Oct 1998 23:40:26 -0700 Received: from chico.rediris.es [130.206.1.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zWat5-0003Dg-00; Thu, 22 Oct 1998 23:40:25 -0700 Received: from news.rediris.es (news.rediris.es [130.206.1.38]) by chico.rediris.es (8.9.1/8.9.1) with ESMTP id IAA07507; Fri, 23 Oct 1998 08:39:43 +0200 (MET DST) Received: from news.rediris.es (o2.rediris.es [130.206.1.45]) by news.rediris.es (8.8.7/8.8.7.7) with ESMTP id IAA13019; Fri, 23 Oct 1998 08:39:42 +0200 (MET DST) Message-Id: <199810230639.IAA13019@news.rediris.es> X-Mailer: exmh version 2.0.1 12/23/97 From: Angel Mateo To: Markus Buchhorn cc: rem-conf@es.net Subject: Re: User control for mbone In-reply-to: Your message of "Fri, 23 Oct 1998 10:01:46 +1000." <3.0.32.19981023100145.00988ec0@acsys.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Oct 1998 08:39:36 +0200 Sender: amateo@news.rediris.es X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > = > Why do you want to do this? sap/sdp isn't exactly a bandwidth hog so is= > there another reason ? > = The idea is not to limit to the sap/sdp, but to our users can only use = sessions announced, so they can't put traffic in a multicast group that i= s not = announced. We want to offer this service to student of universities and we know fro= m = previous experiences that the student always use the service in the corre= ct = way and in the wrong way, so we would like to avoid to use the wrong one.= The = problem is that we guess that if we don't control the service, soon we wi= ll = have a lot of trafic in our network that it doesn't belong to any session= =2E Angel ----------------------------------------- Angel L. Mateo Martinez RedIRIS/CSIC C/ Serrano, 142 28006 Madrid (Spain) Tlfo: +34-91-5855145 Fax: +34-91-5855146 From rem-conf Fri Oct 23 02:03:03 1998 From rem-conf-request@es.net Fri Oct 23 02:03:02 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zWd1M-0005RO-00; Fri, 23 Oct 1998 01:56:32 -0700 Received: from relay9.uu.net [192.48.96.85] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zWd1L-0005RE-00; Fri, 23 Oct 1998 01:56:31 -0700 Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQfmhv02480; Fri, 23 Oct 1998 04:56:28 -0400 (EDT) Received: by neserve0.uu.net id QQfmhv12624; Fri, 23 Oct 1998 04:55:39 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: User control for mbone In-Reply-To: <3.0.32.19981023100145.00988ec0@acsys.anu.edu.au> from Markus Buchhorn at "Oct 23, 1998 10: 1:46 am" To: markus@acsys.anu.edu.au (Markus Buchhorn) Date: Fri, 23 Oct 1998 04:55:39 -0400 (EDT) Cc: angel.mateo@rediris.es, rem-conf@es.net, na-eng@UU.NET X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Another approach could be to put the authorized people on a separate segment and only announce that segment into the mbone. Others could have in-house sessions, but onl the blessed people could make sessions and send multicast traffic. This also means that the unblessed people will not be able to interact with a conference--they will just be able to listen. If running MSDP, one could limit the SA announcements from your domain--this has the ability to limit both source and group pairs from leaving. The following is just an idea--it is half-baked and may not work...but isn't that how things start? An authentication and authorization system could be created to track user requests. A user would start a home-brew application to authenticate. Assuming the user is successful, the server side could log into one (or many) border routers to adjust the master MSDP SA announce filters. Once the time limit is up, the server thing could remove the host from the SA list. Other mechanisms may need to be tested to actually force the user to be removed from a conference. The only mechanism I can think of right now is to use join filters on the borders for his s,g in adition to setting up the SA announce msg filter. _J Markus Buchhorn said: > > Hi Angel > > > We have several LANS and we are intrested in deploy, install or configure a > >mechanism to be able to control the users that connects to the MBone. What > we > >want to do is to configure our network to: > > > >* All the users can connect and join to an MBone session. > >* Only authoriced people can create sessions. > > > Does any way to do this? > > I think the easy answer is no - if you have a multicast infrastructure in > place for people to join and participate in the MBONE then there is no way > to stop those same people sending session advertisement packets (from > whatever tools they choose, or even write themselves) to that same > infrastructure. One also can create meetings/conferences by emailing round > a specific multicast IP address/port and never advertise it through the sap > system anyway. > > Now, I could imagine restricting your feed to be one way, so people can > join and listen/view sessions but not transmit to it - and then > locally-created session advertisements will only be advertised on your > network and not to the world. Or you could put filters on your network > boundary to look for sap packets and block them. Perhaps that would even > work across your LANs but it's an ugly approach (and wouldn't work on an > individual LAN). > > Why do you want to do this? sap/sdp isn't exactly a bandwidth hog so is > there another reason ? > > Cheers, > Markus > > Markus Buchhorn, Advanced Computational Systems CRC | Ph: +61 2 62798810 > email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602 > Australian National University, Canberra 0200, Australia |Mobile: 0417 281429 > From rem-conf Fri Oct 23 09:44:37 1998 From rem-conf-request@es.net Fri Oct 23 09:44:36 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zWk9r-0002NG-00; Fri, 23 Oct 1998 09:33:47 -0700 Received: from fwgate-2.rss.rockwell.com (fwgate-2.nb.rss.rockwell.com) [157.152.197.3] (firewall-user) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zWk9q-0002N6-00; Fri, 23 Oct 1998 09:33:46 -0700 Received: by fwgate-2.nb.rss.rockwell.com; id JAA04375; Fri, 23 Oct 1998 09:33:40 -0700 (PDT) From: Received: from npbsmtp1.nb.rss.rockwell.com(157.152.161.153) by fwgate-2.nb.rss.rockwell.com via smap (4.1) id xma004348; Fri, 23 Oct 98 09:33:20 -0700 Received: by npbsmtp1.nb.rockwell.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 882566A6.005A0074 ; Fri, 23 Oct 1998 09:23:03 -0700 X-Lotus-FromDomain: RSS To: rem-conf@es.net Message-ID: <882566A6.0059FF2C.00@npbsmtp1.nb.rockwell.com> Date: Fri, 23 Oct 1998 18:34:08 +0200 Subject: TAPI3.0 Samples [To rem-conf@es.net] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sirs, Do you have any TAPI3.0 source application ? (Setting TAPI, connections, data/voice tranfert, ...) Best Regards Norbert Rosselllo norbert.rossello@rss.rockwell.com From rem-conf Fri Oct 23 12:16:57 1998 From rem-conf-request@es.net Fri Oct 23 12:16:55 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zWmWM-0004hA-00; Fri, 23 Oct 1998 12:05:10 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zWmWL-0004h0-00; Fri, 23 Oct 1998 12:05:09 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id MAA28501; Fri, 23 Oct 1998 12:05:07 -0700 (PDT) Message-Id: <3.0.3.32.19981023120506.00a782c0@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 23 Oct 1998 12:05:06 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 10/28 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar Why I like Working with Cable Networks ...The View from @Home (Wednesday October 28, 1998 12:30-2:00 PDT 405 Soda Hall) Milo Medin At Home Corporation The @Home cable modem service will be coming to the Berkeley/Oakland area in the next several months. Learn about the technology involved in deliverying high-speed internet service to the home at low cost and the opportunities and problems dealing with the cable infrastructure and companies. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Fri Oct 23 15:26:39 1998 From rem-conf-request@es.net Fri Oct 23 15:26:37 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zWpYy-00076Z-00; Fri, 23 Oct 1998 15:20:04 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0zWpYx-00076P-00; Fri, 23 Oct 1998 15:20:03 -0700 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Oct 23 18:18:15 EDT 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id SAA20364; Fri, 23 Oct 1998 18:18:13 -0400 (EDT) Message-ID: <3631000F.7B007E1D@dnrc.bell-labs.com> Date: Fri, 23 Oct 1998 18:15:43 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Sengodan Senthil NRC/Boston CC: Stephen Casner , "Eric C. Rosen" , Henning Schulzrinne , "Kyle J. McKay" , Colin Perkins , "John W. Noerenberg" , rem-conf Subject: Re: Revised AVT charter and draft-mckay- References: <1998Oct13.152100.1991.353853@rhino.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sengodan Senthil NRC/Boston wrote: > > > Using the payload type as the indicator of encryption does not > > preclude encrypting some of the payloads in a multiplexing scheme > > except for the one proposal that assumed the payload type was the same > > for all streams. (I would prefer not to make this assumption for > > other reasons in addition to this encryption question.) If the > > ability to encrypt some of the streams is valuable (it probably is), > > then should we require all encodings that might be used to set aside a > > payload header bit to indicate encryption? > > For the multiplexed case, including the payload type in the header of > each of the individual streams facilitates dynamic switching of encoding > (codecs or security mechanisms) after having established which payload > type corresponds to which encoding. The mux proposal > that does not use payload types in the mini-headers achieves similar > functionality by other means that is more bandwidth efficient. It defines > a bit called the transition bit (T) within the mini-header whose purpose is > to indicate to the receiver that a new encoding (codec/security > mechanism) is currently in effect. This is done by toggling the bit. Prior > to a change in encoding, the transmitter needs to convey to the receiver > what the new encoding is going to be for a particular stream. > The receiver then knows that the new encoding has been applied > to the stream when it notices that the T bit is toggled. > > The advantage is that a change in encoding is identified by the use of a single > bit, as against an entire byte (for payload type). The disadvantage is that > prior to each change, you have to signal to the receiver of the change to a certain > encoding. Assuming that a little bit of latency can be tolerated when a change > in encoding is desired, I'd argue that the bandwidth savings are more > significant. I have some concerns about the use of this toggle bit in general, as it can introduce some bizarre failure modes in certain conditions. Most of these relate to synchronization problems - the signaling and media may often take different paths through the network, and there is absolutely no guarantee on the relative time of arrival of a media packet and a signaling packet. However, the use of the toggle bit depends on some amount of synchronization. So, consider an example: A signals B about a change in encoding from X to Y, and toggles the T bit. Very shortly thereafter, A signalings B about yet another change >from Y to Z, and toggles the bit once more. As it so happens, the voice >from A to B was in silence during the brief period when Y was in use, and nothing was sent. So, the media packets which arrive at B are only those used with codec X and Z. Both X and Z have the same value for the toggle bit. When should B use Z instead of X? One might say to switch after the signaling message changing X to Y is received. However, a delayed packet may arrive, and thus be mis-decoded. The use of the toggle bit raises the same kinds of issues as in the design of the sequence number size in a windowed flow control system (see the draft I submitted). By using a single bit, you are restricted to 1 change in encoding per RTT. You will also run into sequence number rollaround issues, just as the one I describe above. To be fairly robust and safe, you should really use much more than one bit, say 7 or 8 bits, of SN (which will avoid the problem above). In that case, may as well just use the full PT. This avoids all of these sync headaches, and fits much more in line with the original design of RTP. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Sun Oct 25 09:39:26 1998 From rem-conf-request@es.net Sun Oct 25 09:39:24 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zXTuU-0004Y3-00; Sun, 25 Oct 1998 09:24:58 -0800 Received: from usr9-dialup36.mix2.atlanta.cw.net (Safe and Sound) [166.55.53.36] by mail1.es.net with smtp (Exim 1.81 #2) id 0zXTuP-0004Xt-00; Sun, 25 Oct 1998 09:24:56 -0800 From: Safe & Sound Products To: Message-Id: <419.436093.51683611lisarae@mail.usa.com> Subject: Here it is! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Sun, 25 Oct 1998 09:24:56 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ///// Supercharge your computer with Desktop Server 98 ///// This ad is being sent in compliance with Senate bill 1618, Title 3, section 301. http://www.senate.gov/~murkowski/commercialemail/s771index.html DESKTOP SERVER 98 IS THE SIMPLEST WAY TO BRING NEW VISITORS TO YOUR WEBSITE & BUSINESS! Now you can stop worrying about losing your ISP so much. Desktop Server 98 completely eliminates all the hassles normally associated with sending bulk email. Desktop Server turns your personal computer into a "REAL" email server so you don't have to use any of your ISP's email resources. Now, it's almost impossible for ISP's to complain, because all the email advertisements are going out through your own computer. Your ISP won't even know you are sending email. For more information put "more info" on the subject line and email me at makemoney01@mailexcite.com Lisa Rae Dubonet Further transmissions to you by the sender of the email may be stopped at no cost to you by sending a reply to this email address with the word 'Remove' in the subject line. From rem-conf Sun Oct 25 14:01:41 1998 From rem-conf-request@es.net Sun Oct 25 14:01:40 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zXY8x-0006su-00; Sun, 25 Oct 1998 13:56:11 -0800 Received: from usr24-dialup20.mix2.atlanta.cw.net (Safe and Sound) [166.55.56.212] by mail1.es.net with smtp (Exim 1.81 #2) id 0zXY8t-0006sk-00; Sun, 25 Oct 1998 13:56:09 -0800 From: Safe & Sound Products To: Message-Id: <419.436093.70526111lisarae@mail.usa.com> Subject: Here it is! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Sun, 25 Oct 1998 13:56:09 -0800 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ///// Supercharge your computer with Desktop Server 98 ///// This ad is being sent in compliance with Senate bill 1618, Title 3, section 301. http://www.senate.gov/~murkowski/commercialemail/s771index.html DESKTOP SERVER 98 IS THE SIMPLEST WAY TO BRING NEW VISITORS TO YOUR WEBSITE & BUSINESS! Now you can stop worrying about losing your ISP so much. Desktop Server 98 completely eliminates all the hassles normally associated with sending bulk email. Desktop Server turns your personal computer into a "REAL" email server so you don't have to use any of your ISP's email resources. Now, it's almost impossible for ISP's to complain, because all the email advertisements are going out through your own computer. Your ISP won't even know you are sending email. For more information put "more info" on the subject line and email me at makemoney01@mailexcite.com Lisa Rae Dubonet Further transmissions to you by the sender of the email may be stopped at no cost to you by sending a reply to this email address with the word 'Remove' in the subject line. From rem-conf Tue Oct 27 07:56:10 1998 From rem-conf-request@es.net Tue Oct 27 07:56:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zYBAn-0002dB-00; Tue, 27 Oct 1998 07:36:41 -0800 Received: from mailhost.broadcast.com (mailhost.audionet.com) [206.190.32.50] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zYBAm-0002d1-00; Tue, 27 Oct 1998 07:36:40 -0800 Received: from eluczycki (eluczycki.broadcast.com [206.190.34.246]) by mailhost.audionet.com (Post.Office MTA v3.1 release PO205e ID# 0-56930U500L400S0) with SMTP id AAA188; Tue, 27 Oct 1998 09:27:09 -0600 Message-Id: <4.1.19981027093206.00b17100@mail.broadcast.com> X-Sender: eds@mail.broadcast.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 27 Oct 1998 09:35:38 -0600 To: mbone@cilea.it From: eluczycki@broadcast.com (Ed Luczycki) Subject: MBone Booking Cc: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Would it be possible to book the following on the MBone. Start: 10-29-98 GMT 18:00 Stop: 10-29-98 GMT 21:00 Title: NASA Shuttle Launch with John Glenn Contact: webmaster@broadcast.com Notes: Brought to you by NASA TV and broadcast.com. Requires either the Real Media Player from Real Networks or the Microsoft Windows Media Player. I attempted to use the web form but was unsuccessful. If there is another method that must be used plese let me know. Thanks, eds From rem-conf Tue Oct 27 08:13:49 1998 From rem-conf-request@es.net Tue Oct 27 08:13:48 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zYBZA-000308-00; Tue, 27 Oct 1998 08:01:52 -0800 Received: from fwgate-2.rss.rockwell.com (fwgate-2.nb.rss.rockwell.com) [157.152.197.3] (firewall-user) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zYBZ8-0002zm-00; Tue, 27 Oct 1998 08:01:51 -0800 Received: by fwgate-2.nb.rss.rockwell.com; id IAA03748; Tue, 27 Oct 1998 08:01:14 -0800 (PST) From: Received: from npbsmtp1.nb.rss.rockwell.com(157.152.161.153) by fwgate-2.nb.rss.rockwell.com via smap (4.1) id xma003729; Tue, 27 Oct 98 08:00:44 -0800 Received: by npbsmtp1.nb.rockwell.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 882566AA.0057893C ; Tue, 27 Oct 1998 07:56:07 -0800 X-Lotus-FromDomain: RSS To: rem-conf@es.net cc: ailkov@esd.dl.nec.com, schenck@compuserve.com, brucep@msn.com, oded_k@tabs.co.il Message-ID: <882566AA.005787DA.00@npbsmtp1.nb.rockwell.com> Date: Tue, 27 Oct 1998 17:00:19 +0100 Subject: TAPI3.0: Get UDP Port Number [] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sir, My environment: WindowsNT 5.0 beta2 UDP Port number: When a TAPI3.0 communication is established between two Tapi3.0 applications: for example between the "Incoming" application (Tapi sample from SDK) and NetMeeting. Do you know how can I get the UDT Port number that the two cessions have negotiated ? Best Regards Norbert Rossello norbert.rossello@rss.rockwell.com brucep@msn.com From rem-conf Tue Oct 27 08:50:51 1998 From rem-conf-request@es.net Tue Oct 27 08:50:51 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zYCBx-0004Ue-00; Tue, 27 Oct 1998 08:41:57 -0800 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zYCBw-0004UT-00; Tue, 27 Oct 1998 08:41:56 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id IAA16716; Tue, 27 Oct 1998 08:41:56 -0800 (PST) Message-Id: <3.0.3.32.19981027084153.0090d7b0@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 27 Oct 1998 08:41:53 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 10/28 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar Why I like Working with Cable Networks ...The View from @Home Wednesday October 28, 1998 12:30-2:00pm 405 Soda Hall Milo Medin At Home Corporation The @Home cable modem service will be coming to the Berkeley/Oakland area in the next several months. Learn about the technology involved in deliverying high-speed internet service to the home at low cost and the opportunities and problems dealing with the cable infrastructure and companies. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Tue Oct 27 13:15:56 1998 From rem-conf-request@es.net Tue Oct 27 13:15:55 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zYGKC-0000l8-00; Tue, 27 Oct 1998 13:06:44 -0800 Received: from mailer.psc.edu [128.182.58.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zYGKB-0000ky-00; Tue, 27 Oct 1998 13:06:43 -0800 Received: from psc.edu (haroun.psc.edu [128.182.61.58]) by mailer.psc.edu (8.8.7/8.8.7/mailer) with ESMTP id QAA06286; Tue, 27 Oct 1998 16:06:41 -0500 (EST) Message-ID: <363635B0.445F51AF@psc.edu> Date: Tue, 27 Oct 1998 16:05:52 -0500 From: Peter Berger X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net, vbns-techs@nlanr.net Subject: Joint NLANR/I2 Techs Workshop Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The Joint NLANR/Internet2 Techs Workshop will be multicast on the MBone and vBNS Multicast infrastructure on November 2-3 from 9 am - 5 pm and on November 4th from 9 am - noon. H.261 will be multicast to the MBone and vBNS, and MPEG1 (viewable with IP/TV software)will be multicast to the vBNS. RealVideo will also be available at http://alderaan.ncsa.uicu.edu/live0.ram. For more information on the conference, please visit: http://ncne.nlanr.net and click on the workshop link. Thanks, Peter Berger Coordinator, NLANR Engineering Services. From rem-conf Tue Oct 27 15:27:11 1998 From rem-conf-request@es.net Tue Oct 27 15:27:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zYIPv-0002iF-00; Tue, 27 Oct 1998 15:20:47 -0800 Received: from chi-qbu-nvb-vty10.as.wcom.net (hiredhits.com) [209.154.105.10] by mail1.es.net with smtp (Exim 1.81 #2) id 0zYIPn-0002hY-00; Tue, 27 Oct 1998 15:20:41 -0800 DATE: Tue, 27 Oct 1998 17:33:04 -0600 Message-ID: Subject: FREE DEMO of Software That Puts You On OVER 1000 Search Engines! From: hire@hiredhits.com To: $user@es.net MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Greetings! I thought I would take some time today to let you know about a wonderful new software package that will dramatically increase your web site's visibility. It's called The Spider, and I have been using it for several months and enjoyed a tremendous increase in my website's traffic. This software has impressed me so much that I decided to buy the reseller rights to it. And now, we are offering it on a FREE DEMO basis. Before I let you in on our secret download location, let me tell you a bit more about it. 1) 1000 + Supported Search Engines (Pro), 450 for standard edition 2) Batch Processing - allows you to take control of your website promotions - for all of your pages and sites. With a built in on-board database and batch processing, you can accurately register as many sites or pages as you like, all at once. 3) Categorized submissions - accuracy is critical when placing your site; our program recognizes and properly places you in all of our supported search engines. Don't be fooled by the competition - the shotgun approach does not work! 4) True CGI based registration - while other programs simply email your site information to search engine webmasters in the vain hope they will manually enter your information, The Search Engine Spider interacts with the server directly, custom formatting your site information for each and every supported engine. 5) Small Size, Fast Execution : The Spider is written entirely in the C programming language, and takes advantage of the true 32 bit multithreaded programming environment provided therein. It's fast: in our internal testing, the new program will perform 450 individual registrations in just under 18 minutes. Testing was done on a 28.8 dialup line. 6) Automatic Update Feature: No more weekly and monthly downloads! In an effort to keep up to date with search engine changes and updates, we have now incorporated a feature that will automate this task. Here's how it works: a.. Each time the program is loaded, it will automatically connect to our server and verify that the current search engine database is loaded on your user's machine. If it is not, it will automatically initiate a download. b. Once the download is complete (typically 20-30 seconds on a 28.8K connection), normal program operation will resume with the new database. 7) Improved Error Checking: anytime an error is generated during submission, by any user anywhere, the program updates our server with the search engine name, time and date of the error, and the nature of the error. Our resource manager for this project checks his log daily and investigates each and every error and has the ability to dynamically and instantly update the master database with the corrections. Once the correction is made, the Automatic Update Feature kicks in, distributing the updated registration database to every user worldwide the next time they use the program. To get your FREE DEMO of this amazing software, please visit: http://www.hiredhits.com/ If you would prefer us to send you a CD with The Spider, along with free demos of over 10 of our other web promotion software packages, please visit: http://www.hiredhits.com/order/process_cd.htm If you are having problems connecting to the above links, please give us a call at 773-271-8484 and we will arrange another way for you to get your FREE DEMO. Thanks again for your time and please let me know if you have any questions. Best Regards, Amy Horowitz MasterPromote, Inc. 120 Broadview Village Square Suite 315 Broadview, IL 60153 773-271-8484 ********* To remove yourself from this mailing list, please visit http://www.hiredhits.com and type your name in the "Remove Me!" box. We will promptly remove your name from future mailings. Sorry for any inconveince we may have caused From rem-conf Tue Oct 27 16:18:09 1998 From rem-conf-request@es.net Tue Oct 27 16:18:08 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zYJEz-0003qn-00; Tue, 27 Oct 1998 16:13:33 -0800 Received: from mage.qualcomm.com [129.46.174.16] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zYJEy-0003pp-00; Tue, 27 Oct 1998 16:13:32 -0800 Received: from ecr-nt (ecr-nt.qualcomm.com [129.46.171.181]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with SMTP id QAA19479; Tue, 27 Oct 1998 16:12:30 -0800 (PST) Message-Id: <199810280012.QAA19479@mage.qualcomm.com> X-Sender: ecr@nala.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 27 Oct 1998 16:12:29 -0800 To: rem-conf@es.net From: "Eric C. Rosen" Subject: Re: draft-mckay-qcelp-01.txt Cc: agum@qualcomm.com In-Reply-To: References: <199810132142.OAA26335@mage.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In response to the comments and criticisms, I would like to propose that we replace the first two paragraphs of Section 6 of the specification with the following: Senders MAY explicitly encrypt the PureVoice data frames as a means of guarding against eavesdropping, or rely on lower level confidentiality services to encrypt the media stream as a unit when necessary. Applications may use any appropriate algorithm to encrypt data frames. The encryption algorithm, key length, key exchange mechanisms, and other encryption algorithm parameters are not defined here. An extended payload format is defined to support explicitly encrypting PureVoice data frames, which MUST be used in conjunction with a dynamic payload type. When this extended payload format is used, the first bit in the RTP payload is set to one and additional crypto payload fields are defined according to the following format: --Eric At 09:59 AM 10/20/98 -0700, Stephen Casner wrote: >On Tue, 13 Oct 1998, Eric C. Rosen wrote: > >> In the QCELP payload specification, the Encrypted (E) bit signals >> the presence of an additional byte's worth of crypto header fields, >> which in turn may signal the presence or length of cryptosync and >> cryptocheck data. In this sense, the E bit has the same meaning >> as the Cryptocheck Presence (K) bit or the Cryptosync Length (CSL) >> field. It signals the inclusion of additional fields later in the >> payload. >> >> It seems unwise to me to rely on out-of-band control information, >> such as the payload type, to determine whether this extra byte is >> present in the payload. > >I disagree. Why does it seem unwise? I contend that the variable >presence or absence of the additional byte and the cryptosync and >crytocheck data is a misfeature. I would expect that a particular >stream would always use exactly the same configuration of these bits >in every packet. Hence there is no need to waste that extra byte in >each packet and to force the receiver to execute several conditional >checks. Instead, by binding to the payload type, one can write "fast >path" code that implements the common case with no conditionals. >If you do need to change the settings on the fly, you can define >multiple dynamic payload types for the different sets of settings. >We've exercised this philosophy as much as we could in the design of >RTP itself and in other payload formats. > >> In fact, it seems reasonable not to view the E bit as an encryption >> flag. It's utility is limited to indicating the inclusion of >> additional fields. Nothing prevents applications from using RTP's >> Section 9.1 encryption scheme with the QCELP specification. An >> application which did would not need to include the additional crypto >> fields defined in the QCELP draft and hence not set the E bit. > >And then there would be two ways to do the same thing, leading to >reduced interoperability. > >I have some more comments about other aspects of the proposal that I >will send in another message. > -- Steve > From rem-conf Wed Oct 28 09:58:20 1998 From rem-conf-request@es.net Wed Oct 28 09:58:19 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zYZcJ-0005Cd-00; Wed, 28 Oct 1998 09:42:43 -0800 Received: from fwgate-2.rss.rockwell.com (fwgate-2.nb.rss.rockwell.com) [157.152.197.3] (firewall-user) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zYZcH-0005CT-00; Wed, 28 Oct 1998 09:42:41 -0800 Received: by fwgate-2.nb.rss.rockwell.com; id JAA13325; Wed, 28 Oct 1998 09:42:34 -0800 (PST) From: Received: from npbsmtp1.nb.rss.rockwell.com(157.152.161.153) by fwgate-2.nb.rss.rockwell.com via smap (4.1) id xmab13298; Wed, 28 Oct 98 09:42:07 -0800 Received: by npbsmtp1.nb.rockwell.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 882566AB.0060CF6C ; Wed, 28 Oct 1998 09:37:25 -0800 X-Lotus-FromDomain: RSS To: rem-conf@es.net Message-ID: <882566AB.0060CD49.00@npbsmtp1.nb.rockwell.com> Date: Wed, 28 Oct 1998 18:42:06 +0100 Subject: TAPI3 Outgoing sample [To rem-conf@es.net] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sirs, The TAPI3 "outgoing" call sample given with the NT5.0 beta 2 does not work because it refers to objects like IEnumAddressTypes that do no longer exist ! Do you have a running sample ? Thanks Best Regards norbert.rossello@rss.rockwell.com From rem-conf Wed Oct 28 15:11:36 1998 From rem-conf-request@es.net Wed Oct 28 15:11:34 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zYeg9-00014q-00; Wed, 28 Oct 1998 15:07:01 -0800 Received: from diva.eecs.berkeley.edu [128.32.156.110] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zYeg7-00014g-00; Wed, 28 Oct 1998 15:06:59 -0800 Received: from hubaux.eecs.berkeley.edu (hubaux.EECS.Berkeley.EDU [128.32.171.176]) by diva.EECS.Berkeley.EDU (8.8.5/8.8.3) with SMTP id PAA08850; Wed, 28 Oct 1998 15:04:22 -0800 Message-Id: <3.0.1.32.19981028150142.0076cd34@diva.eecs.berkeley.edu> X-Sender: hubaux@diva.eecs.berkeley.edu X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 28 Oct 1998 15:01:42 -0800 To: hubaux@diva.EECS.Berkeley.EDU From: Jean-Pierre Hubaux Subject: CfP: IEEE Comm Mag Issue on Hybrid Services Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colleague, You will find hereafter the Call for Papers for a Feature Topic Issue of the IEEE Communications Magazine (http://www.comsoc.org). We apologize in case you receive multiple copies of this Email. With best regards, The guest editors CALL FOR PAPERS - IEEE COMMUNICATIONS MAGAZINE Feature Topic Issue on The Provision of Communication Services over Hybrid Networks (publication: July 1999) -------------------------------------------------------------- Submission deadline: January 5, 1999 Guest Editors: Jean-Pierre Hubaux David Nagel Swiss Fed. Inst. of Technology, President, AT&T Labs Lausanne On leave at the Univ. of California, AT&T Labs Berkeley, until January 9, 1999 295 North Maple Avenue EECS Dept, 267 Cory Hall Basking Ridge Berkeley,CA 94720 NJ 07920 USA USA tel: + 1-510-642-9719 tel: + 1-908-221-2903 fax: + 1-510-642-2845 hubaux@diva.EECS.Berkeley.EDU dnagel@att.com As society moves relentlessly into the information age, there is a growing demand for seamless operation of services over hybrid networks. By hybrid networks, we intend primarily the integration of the Public Switched Telephone Network (PSTN) (including the cellular networks) and the IP network. These two families of networks have been designed with radically different objectives. However, both of them are going to continue to exist at least for a couple of decades. Both are growing at a breathtaking pace; the PSTN is regaining momentum by leveraging on the high popularity of (mobile and fixed) cellular networks, while the internet suite is now the dominant technology for data communications. At the same time, we are witnessing a dramatic evolution of the telecommunications industry. This Feature Topic Issue is devoted to the architecture and provision of services over hybrid networks. These services are the ones now and soon to be offered to end-users by service providers and network operators; we call them hybrid services. Topics of interest include: * Creation of hybrid services * Deployment of hybrid services * Operation and management of hybrid services * Validation of hybrid services * Middleware for hybrid services * Network planning and dimensioning * New hybrid services: access to Internet services from cellular terminals, access to the PSTN from a mobile IP phone, hybrid call centers,... * Traffic control and performance issues related to hybrid services * Security of hybrid services * Billing of hybrid services * Hybrid services involving other access networks (cable, ATM, WLANs,...) * Mobility-related services * Terminals for hybrid services * Computer Telephony Integration services * Partial replacement of telecom equipment by Internet technology for the control and/or transport of voice services * Dependability and scalability of hybrid services Tutorial and survey papers will be considered for acceptance. Research papers will be considered as well, provided that they are understandable and informative for non specialists of the area covered by this issue. Although the Feature Topic Issue is essentially devoted to technical aspects, prospective authors are also encouraged to address economic and/or regulatory questions. Submission, Approval, Review, and Acceptance. --------------------------------------------- Authors are requested to send e-mail by January 5 to both guest editors, giving a URL where the guest-editors can review the article, preferably in HTML format with GIF artwork (postscript or pdf format is also accepted). Upon approval by the guest-editors, all feature articles will then undergo a technical peer review consistent with other archival publications. Potential authors may wish to consult the author information and guidelines, which are given at http://pubs.comsoc.org/ci1/ Articles for review should be in HTML or a common format easily read by reviewers. Authors will send all files to an anonymous ftp site provided by the guest editors. When an article consists of a collection of HTML and GIF files, all internal links pointing to this file should be relative. Note: there is currently a call for papers for a joint Feature Topic Issue of Internet IEEE Network and IEEE Internet magazines on Internet telephony, to be edited by Henning Schulzrinne. There are some commonalities between the two Feature Topic Issues. However, the focus of each of them is different, and appropriate coordination efforts will be made to avoid overlaps. Submission Deadline: January 5, 1999 Acceptance Notification: March 15, 1999 Final Manuscripts Due: May 1, 1999 Publication of Complete Feature Topic Issue: July 1999 From rem-conf Wed Oct 28 15:11:36 1998 From rem-conf-request@es.net Wed Oct 28 15:11:36 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zYegL-00015X-00; Wed, 28 Oct 1998 15:07:13 -0800 Received: from diva.eecs.berkeley.edu [128.32.156.110] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zYegK-00015N-00; Wed, 28 Oct 1998 15:07:12 -0800 Received: from hubaux.eecs.berkeley.edu (hubaux.EECS.Berkeley.EDU [128.32.171.176]) by diva.EECS.Berkeley.EDU (8.8.5/8.8.3) with SMTP id PAA08882; Wed, 28 Oct 1998 15:06:12 -0800 Message-Id: <3.0.1.32.19981028150332.0076cd34@diva.eecs.berkeley.edu> X-Sender: hubaux@diva.eecs.berkeley.edu X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 28 Oct 1998 15:03:32 -0800 To: hubaux@diva.EECS.Berkeley.EDU From: Jean-Pierre Hubaux Subject: CfP: IEEE Comm Mag Issue on Hybrid Services Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colleague, You will find hereafter the Call for Papers for a Feature Topic Issue of the IEEE Communications Magazine (http://www.comsoc.org). We apologize in case you receive multiple copies of this Email. With best regards, The guest editors CALL FOR PAPERS - IEEE COMMUNICATIONS MAGAZINE Feature Topic Issue on The Provision of Communication Services over Hybrid Networks (publication: July 1999) -------------------------------------------------------------- Submission deadline: January 5, 1999 Guest Editors: Jean-Pierre Hubaux David Nagel Swiss Fed. Inst. of Technology, President, AT&T Labs Lausanne On leave at the Univ. of California, AT&T Labs Berkeley, until January 9, 1999 295 North Maple Avenue EECS Dept, 267 Cory Hall Basking Ridge Berkeley,CA 94720 NJ 07920 USA USA tel: + 1-510-642-9719 tel: + 1-908-221-2903 fax: + 1-510-642-2845 hubaux@diva.EECS.Berkeley.EDU dnagel@att.com As society moves relentlessly into the information age, there is a growing demand for seamless operation of services over hybrid networks. By hybrid networks, we intend primarily the integration of the Public Switched Telephone Network (PSTN) (including the cellular networks) and the IP network. These two families of networks have been designed with radically different objectives. However, both of them are going to continue to exist at least for a couple of decades. Both are growing at a breathtaking pace; the PSTN is regaining momentum by leveraging on the high popularity of (mobile and fixed) cellular networks, while the internet suite is now the dominant technology for data communications. At the same time, we are witnessing a dramatic evolution of the telecommunications industry. This Feature Topic Issue is devoted to the architecture and provision of services over hybrid networks. These services are the ones now and soon to be offered to end-users by service providers and network operators; we call them hybrid services. Topics of interest include: * Creation of hybrid services * Deployment of hybrid services * Operation and management of hybrid services * Validation of hybrid services * Middleware for hybrid services * Network planning and dimensioning * New hybrid services: access to Internet services from cellular terminals, access to the PSTN from a mobile IP phone, hybrid call centers,... * Traffic control and performance issues related to hybrid services * Security of hybrid services * Billing of hybrid services * Hybrid services involving other access networks (cable, ATM, WLANs,...) * Mobility-related services * Terminals for hybrid services * Computer Telephony Integration services * Partial replacement of telecom equipment by Internet technology for the control and/or transport of voice services * Dependability and scalability of hybrid services Tutorial and survey papers will be considered for acceptance. Research papers will be considered as well, provided that they are understandable and informative for non specialists of the area covered by this issue. Although the Feature Topic Issue is essentially devoted to technical aspects, prospective authors are also encouraged to address economic and/or regulatory questions. Submission, Approval, Review, and Acceptance. --------------------------------------------- Authors are requested to send e-mail by January 5 to both guest editors, giving a URL where the guest-editors can review the article, preferably in HTML format with GIF artwork (postscript or pdf format is also accepted). Upon approval by the guest-editors, all feature articles will then undergo a technical peer review consistent with other archival publications. Potential authors may wish to consult the author information and guidelines, which are given at http://pubs.comsoc.org/ci1/ Articles for review should be in HTML or a common format easily read by reviewers. Authors will send all files to an anonymous ftp site provided by the guest editors. When an article consists of a collection of HTML and GIF files, all internal links pointing to this file should be relative. Note: there is currently a call for papers for a joint Feature Topic Issue of Internet IEEE Network and IEEE Internet magazines on Internet telephony, to be edited by Henning Schulzrinne. There are some commonalities between the two Feature Topic Issues. However, the focus of each of them is different, and appropriate coordination efforts will be made to avoid overlaps. Submission Deadline: January 5, 1999 Acceptance Notification: March 15, 1999 Final Manuscripts Due: May 1, 1999 Publication of Complete Feature Topic Issue: July 1999 From rem-conf Thu Oct 29 01:50:40 1998 From rem-conf-request@es.net Thu Oct 29 01:50:38 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zYoc2-0007MP-00; Thu, 29 Oct 1998 01:43:26 -0800 Received: from iw-1.hyogo-iic.ne.jp [203.136.199.4] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zYoc0-0007ME-00; Thu, 29 Oct 1998 01:43:24 -0800 Received: by iw-1.hyogo-iic.ne.jp (8.8.8+2.7Wbeta7/3.4W2) id SAA17111; Thu, 29 Oct 1998 18:48:54 +0900 (JST) From: trvactyy@yahoo.com Received: from eyY0Nqoe5 by www-sv.hyogo-iic.ne.jp (8.7.6+2.6Wbeta7/3.3W9-NEC) id SAA22076; Thu, 29 Oct 1998 18:41:35 +0900 (JST) Message-Id: <199810290941.SAA22076@www-sv.hyogo-iic.ne.jp> DATE: 29 Oct 98 1:32:37 AM SUBJECT: Increase your website's search engine ranking. Be Found. Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list INCREASE YOUR WEB SITE'S SEARCH ENGINE RANKING. BE FOUND. If your Web site isn't getting the traffic it should, it's likely that it's not ranked well on the major Internet search engines. According to recent Internet E-commerce studies, over 90% of consumers find the Web sites they visit by using "The Big Eight" search engines, which are Yahoo!, Excite, AltaVista, Infoseek, Lycos, Web Crawler, HotBot, and Northern Light. If your website isn't located in the Top-30 listings of these engines, chances are your site will never be seen. The single most important thing you can do increase your Web site's traffic is to increase your search engine ranking. ------------- "PUT YOUR NAME IN LIGHTS -- List your business with search engines to make sure potential customers can find it." -- BIZ Excite, PC Computing magazine, November 1998 ------------- THE BASICS: HOW SEARCH ENGINES RANK YOUR SITE When you submit your website to a search engine to be indexed in its database, it sends a "robot" to scan your page. Using complex algorithms to rank your page for keyword relevance, the "robot" determines whether you'll be ranked number 1 or 1,000,000 when potential visitors conduct a search looking for sites like yours. Because the search engines are constantly changing their algorithms to provide users with the best possible search results, there's only one true solution to high search engine placement--us. In short, submission alone isn't enough. *Good search engine ranking* is critical to your site's success. ------------- HERE'S WHAT WE DO -- A UNIQUE, SUCCESSFUL APPROACH In order to counter the ever-changing search engine algorithms, we create an entire series of "entry pages" that are optimized for the search engines--one for every keyword (or keyword phrase) that you provide. Each entry page is optimized for a different set of algorithm variables. In other words, instead of having only *one* page struggling to rank well on all engines, we create separate, search engine-specific entry pages for each keyword. As a result, your pages rank well because they contain information relevant to search queries that are related to your industry. ------------- HOW ENTRY PAGES AFFECT YOUR WEB SITE'S CURRENT STRUCTURE Put simply, they don't. When creating entry pages we *do not* make any changes to the existing structure, content, or functionality of your current site. The entry pages act as a welcome screen for your Web site when people enter from your highly ranked link on the search engine. The pages will say a few introductory words about your site, which are keyword and/or keyword phrase rich, and then provide a link that asks the visitor to "Click Here To Enter," which moves them directly to your current homepage. ------------ HERE'S WHAT WE DON'T *EVER* DO TO HELP YOUR SEARCH ENGINE RANK We *will not* build pages for irrelevant--yet "popular"--keywords. Also, we will *never* "spamdex" pages. "Spamdexing" is "stuffing" a Web page full of words for the search engine's robots. You may have seen spamdexing, which is placing many words in the same text color as a background onto a Web page. Spamdexing will actually get your pages "kicked" from search engine indexes. What we *will* do is simply present very relevant keywords for your site to the search engines in the way that they "like" to see it. ------------- "It's simple: If they can't find you on the search engines, they can't buy from you." -- J. LeRoss, Internet Sales Consultant ------------ HOW WELL DOES THE SERVICE WORK? We'll send you a detailed report of your current search engine ranking on "The Big Eight" engines before we begin. Then, once your new entry pages have been indexed, we'll send you a second report showing how they've ranked. Here's a sampling of some results we've acheived for previous clients. (These examples are for competitive keywords--not just obscure words on which no one is conducting searches.) <> 6 top-10 rankings on Infoseek for different relevant keywords <> 18 top-10 rankings across the major search engines <> 3 top-10 rankings on Alta Vista for one keyword <> 16 total *number one* rankings <> 40 top-30 rankings, spread across the different engines. <> 1 to 2 hits per week increased to 500 per day <> 45,000 hits per month grew to 108,000. ------------ HOW MUCH DOES YOUR SERVICE COST? Our services are $385. This includes: <> Construction of optimized entry pages for up to 20 keywords -- This gives you good "coverage" in your industry <> Submission of the keyword-dense entry pages to the major search engines <> A complete report of your search engine rankings before we submit <> A complete report of your search engine rankings after submission--so you can see the ranking results When you contact us, ask about other services we provide that may be able to help your Internet initiatives succeed. ------------ HOW DO I GET STARTED? <> Call us--we'll answer any questions you may have and provide a no-cost initial consultation. <> Submit your keywords and/or keyword phrases (up to 20) to us <> Remit payment ------------ COMMENTS FROM CLIENTS "Incredible! Our site is now receiving more hits in a day than we used to get in an entire month. [My boss] is still eating his words." -- Bob W. "I knew the search engines were a fantastic marketing tool, but my company simply didn't have the time to devote to search engine placement. It has proven to be the best money we've ever spent on marketing." -- Shelley H. "I worked for weeks to get good search engine placement, but I could never crack the top 80 . . . my site was deserted. Within a month [after using your service], I'd had more hits than I'd had in the last year. I wouldn't believe it if it hadn't happened to me." -- Chris L. ------------ OUR JOB: INCREASE YOUR WEB SITE'S RANKING. We can't *guarantee* that better ranking will increase the number of visitors that "surf" to your Web site. Some highly-ranked websites still don't get much traffic--much depends on your particular industry and choice of keywords. *However*, high rankings, in most cases, *do mean* increased Web site traffic. And, we have *never* failed to increase a client's ranking. Ever. ------------ CONTACT A REPRESENTATIVE: Search Engine Success Group, (410) 783-8269 ----------------------- If you've received this message in error--and are not interested in our services--please click reply. From rem-conf Thu Oct 29 04:08:42 1998 From rem-conf-request@es.net Thu Oct 29 04:08:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zYqoP-0001EG-00; Thu, 29 Oct 1998 04:04:21 -0800 Received: from mailhost.mandalux.com (mandala.mandalux.com) [62.160.209.1] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zYqoM-0001E4-00; Thu, 29 Oct 1998 04:04:18 -0800 Received: from localhost (root@localhost) by mandala.mandalux.com (8.8.8/8.8.8) with SMTP id OAA09240; Thu, 29 Oct 1998 14:00:54 +0100 Date: Thu, 29 Oct 1998 14:00:54 +0100 From: Groupe des ventes Received: by mandala.mandalux.com (bulk_mailer v1.5); Thu, 29 Oct 1998 13:50:16 +0100 To: undisclosed-recipients:; Message-ID: Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [English version of this text follows French one.] Mandala International présente: *************************** * LINUX ENTERPRISE SERVER * *************************** La Solution complète pour l'Administration & la Sécurité de votre Réseau sous Linux L'offre Linux Enterprise Server, c'est la garantie d'un système fiable, sécurisé orienté internet, compatible avec votre système actuel. Cette distribution Linux proposée en exclusivité par Mandala International est particulièrement adaptée aux entreprises désireuses d'améliorer l'administration de leur réseau en terme de sécurité, puissance et rapidité d'accès à l'information, mais aussi en terme de coût. Pour 2.990 Frs H.T. (460 Euro) l'offre Linux Enterprise Server c'est : * La dernière version du noyau Linux (2.0.35) * Un programme graphique d'installation et de configuration de votre serveur * 400 utilitaires standards Unix * 50 outils d'administration, de supervision et de sécurité de votre réseau * Des serveurs standards * Une gamme complète de services ( 90 jours d'assistance à l'installation et à la configuration) Pour plus d'informations, consultez notre site http://www.mandalux.com Par email: mailto:proserver@mandalux.com Découvrez l'ensemble de nos solutions du 4 au 6 novembre à INTEROP (Porte de Versailles - Paris) sur le stand K68. Toute l'équipe de Mandala International se tient à votre entière disposition pour de plus amples renseignements. Thomas CLOUET Karine HAEGEMAN Chargé d'Affaires Chargée d'Affaires 01.47.61.84.92 01.47.61.84.93 e-mail : thomas@mandalux.com e-mail : karine@mandalux.com Site Web: http://www.mandalux.com ***************************** ENGLISH VERSION ****************** Mandala International proudly presents: *************************** * LINUX ENTERPRISE SERVER * *************************** The whole admin and security solution for your corporate networks. We offer Linux Enterprise Server, which allows a really stable system, Inernet oriented and secured, fully compatible with your computing systems. This Linux distribution built and sold by Mandala International is fully adapted to feed the needs of companies willing a better network administration and an enhanced security. You'll get power, speed, and low cost network server. For 2.990 French Francs (VAT excluded) (460 Euro), Enterprise Server offers: * Latest stable Linux Kernel * Graphic install and setup tools * 400 usual Unix commands and tools * 50 specific admin and fine tuning tools, as well as security tools and supervision programs. * Standard servers (Apache and more...) * Full 90 days service, including help for install, configuration, server config, network deploiment. More info on http://www.mandalux.com Email info: mailto:proserver@mandalux.com Our full product range will be presented on Interop show (Porte de Versailles Paris France) booth K68 - November 4-6 1998. Mandala Team will be happy to feed you with whatever information you need. Thomas CLOUET Karine HAEGEMAN Business attendant Business Attendant +33 1.47.61.84.92 +33 1.47.61.84.93 e-mail : thomas@mandalux.com e-mail : karine@mandalux.com Visit our web site: http://www.mandalux.com From rem-conf Thu Oct 29 06:20:12 1998 From rem-conf-request@es.net Thu Oct 29 06:20:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zYsrz-0002nM-00; Thu, 29 Oct 1998 06:16:11 -0800 Received: from gateway-le0.cyanamid.com [198.138.106.253] by mail1.es.net with smtp (Exim 1.81 #2) id 0zYsrx-0002n1-00; Thu, 29 Oct 1998 06:16:10 -0800 Received: from igate.cyanamid.com by gateway-le0.Cyanamid.COM via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 29 Oct 1998 14:15:08 UT Received: from pth030.pt.Cyanamid.COM ([141.173.51.30] (may be forged)) by igate.Cyanamid.COM (8.8.6/8.8.6) with ESMTP id JAA24149; Thu, 29 Oct 1998 09:15:06 -0500 (EST) Date: Thu, 29 Oct 1998 09:15:06 -0500 (EST) From: Robert Fausey To: trvactyy@yahoo.com cc: rem-conf@es.net In-Reply-To: <199810290941.SAA22076@www-sv.hyogo-iic.ne.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list From rem-conf Thu Oct 29 07:55:09 1998 From rem-conf-request@es.net Thu Oct 29 07:55:06 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zYuM7-00044v-00; Thu, 29 Oct 1998 07:51:23 -0800 Received: from io.iao.fhg.de [137.251.36.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zYuLy-00044Z-00; Thu, 29 Oct 1998 07:51:17 -0800 Received: from clint.swt.iao.fhg.de by io.iao.fhg.de with SMTP (iao.fhg.de:9403141) id QAA21989; Thu, 29 Oct 1998 16:48:07 +0100 (MET) Received: by clint.swt.iao.fhg.de(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 412566AC.00580B95 ; Thu, 29 Oct 1998 17:01:41 +0100 X-Lotus-FromDomain: IAO From: Britt.Siegmund@iao.fhg.de To: 74464.45@compuserve.com Message-ID: <412566AC.0056D047.94@clint.swt.iao.fhg.de> Date: Thu, 29 Oct 1998 17:01:33 +0100 Subject: HCII99 Call for Papers Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sorry, if you receive this mail more than once. Please dump it then! CALL FOR PAPERS ***** 8th Int. Conference on Human-Computer Interaction ***** HCI International '99 (jointly with 15th Symposium on Human Interface, Japan) August 22-27, 1999, Munich, Germany Important Submission DEADLINES: Papers (Ext. Abstracts): Nov. 30, 1998 Special Interest Groups: Sept. 30, 1998 Demos/Posters: April 30, 1999 Submission Requirements and further Information: see conference web site: http://hci99.iao.fhg.de *** HCI International '99 - Creating New Relationships *** You are cordially invited to participate in HCI International '99, the 8th conference in a major series of events addressing all areas of Human-Computer Interaction. Under the general theme of 'Creating New Relationships' new links and synergies will be explored between information technologies and their users, between people working together, and in the context of the rapidly evolving global information society. The conference will provide an international forum for exchanging and discussing ideas, research results and experiences related to analyzing, designing, developing, applying, and evaluating information and communication technologies for work, leisure, and personal growth. Four major areas are in the focus of the program: - Ergonomics and health aspects of work with computers - Human-computer interfaces - Organizational aspects of information and communication technologies - Communication and interaction in information networks For more details, please visit the HCI International '99 Web site: http://hci99.iao.fhg.de For questions and further information, please contact: HCI International '99 - Conference Secretary Fraunhofer IAO Nobelstr. 12 70569 Stuttgart Germany Phone: +49 711 970 2331 Fax: +49 711 970 2300 Email: HCI99@iao.fhg.de Conference Organisation: General Conference Chair: Hans-Joerg Bullinger, Fraunhofer IAO, Germany Program Chair: Juergen Ziegler, Fraunhofer IAO, Germany Organizational Chair: Rolf Ilg, University of Stuttgart, Germany Conference and Program Comittees: see Conference Web Site Cooperating Societies: Chinese Academy of Sciences EC Telematics Applications Programme European Strategic Programme for Research and Development in Information Technology ESPRIT Gesellschaft fuer Informatik e.V. (GI) Human Factors and Ergonomics Society IFIP WG9.1 Computers and Work International Ergonomics Association Japan Ergonomics Society Oesterreichische Computer Gesellschaft Schweizer Informatiker Gesellschaft - Software Ergonomic (PS: Conference dinner in the world-famous Hofbrauhaus!) From rem-conf Thu Oct 29 08:35:52 1998 From rem-conf-request@es.net Thu Oct 29 08:35:52 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zYuzY-00055E-00; Thu, 29 Oct 1998 08:32:08 -0800 Received: from axl01it.ntc.nokia.com [131.228.118.232] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zYuzW-000554-00; Thu, 29 Oct 1998 08:32:06 -0800 Received: from miller.americas.nokia.com (miller.americas.nokia.com [172.18.180.20]) by axl01it.ntc.nokia.com (8.8.5/8.6.9) with ESMTP id SAA14620; Thu, 29 Oct 1998 18:31:28 +0200 (EET) Received: from bosteels (bsdhcp181182.americas.nokia.com) by miller.americas.nokia.com with SMTP (1.39.111.2/16.2) id AA214708725; Thu, 29 Oct 1998 11:32:05 -0500 Received: by localhost with Microsoft MAPI; Thu, 29 Oct 1998 11:33:06 -0500 Message-Id: <01BE032F.E5A059B0.Jarno.Rajahalme@research.nokia.com> From: Jarno Rajahalme Reply-To: "Jarno.Rajahalme@research.nokia.com" To: "'jdrosen@dnrc.bell-labs.co'" , "'senthil.sengodan@research.nokia.com'" Cc: "'baranitharan.subbiah@research.nokia.com'" , "'casner@cisco.com'" , "'ecr@qualcomm.com'" , "'hgs@cs.columbia.edu'" , "'kylem@qualcomm.com'" , "'C.Perkins@cs.ucl.ac.uk'" Cc: "'jwn2@qualcomm.com'" , "'rem-conf@es.net'" Subject: RE: Revised AVT charter and draft-mckay- Date: Thu, 29 Oct 1998 11:33:04 -0500 Organization: Nokia Research Center / Boston X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Friday, October 23, 1998 6:16 PM, EXT Jonathan Rosenberg [SMTP:jdrosen@dnrc.bell-labs.com] wrote: > > I have some concerns about the use of this toggle bit in general, as it > can introduce some bizarre failure modes in certain conditions. Most of > these relate to synchronization problems - the signaling and media may > often take different paths through the network, and there is absolutely > no guarantee on the relative time of arrival of a media packet and a > signaling packet. However, the use of the toggle bit depends on some > amount of synchronization. So, consider an example: > > A signals B about a change in encoding from X to Y, and toggles the T > bit. Very shortly thereafter, A signalings B about yet another change > from Y to Z, and toggles the bit once more. As it so happens, the voice > from A to B was in silence during the brief period when Y was in use, > and nothing was sent. So, the media packets which arrive at B are only > those used with codec X and Z. Both X and Z have the same value for the > toggle bit. When should B use Z instead of X? One might say to switch > after the signaling message changing X to Y is received. However, a > delayed packet may arrive, and thus be mis-decoded. > I think there is a simple solution to the problem presented above. When A is signaling B about the change in encoding, the B needs to either accept or reject the change (B might not be able to decode the proposed change). A will toggle the transition bit (and change the encoding) only after receiving the response from B. To guarantee that the synchronization is not lost, B will wait to see the actual change on the received toggle bits, if there was a change pending before accepting further changes. Also, A will most probably be periodically sending out background noise parameters also during silence, so that the possible wait will actually end. Note that if there is no data to send, the time it takes to signal about the change does not matter. > The use of the toggle bit raises the same kinds of issues as in the > design of the sequence number size in a windowed flow control system > (see the draft I submitted). By using a single bit, you are restricted > to 1 change in encoding per RTT. The tradeoff is between the anticipated frequency of changes, and the additional header overhead. In a heavily multiplexed situation the additional byte can increase the header overhead from 20% to 30%, which is quite much, if the application is such that 1 change per RTT is acceptable (especially when RTTs have the tendency to get shorter with advances in network technology). > You will also run into sequence number > rollaround issues, just as the one I describe above. To be fairly robust > and safe, you should really use much more than one bit, say 7 or 8 bits, > of SN (which will avoid the problem above). Sequence number clearly needs more than one bit, and no-one has proposed signaling the SN increases. Also, the SN increases for each packet sent only and not during the silence. The number of SN bits required depends on the anticipated packet loss, the payload length (in time) and the real-time constraints of the application. I'd say that the minimum number of SN bits is such that consecutive packet losses causing the rollaround issue would not allow adequate compensation for the losses. When this happens, any number of additional bits will not help to fix the stream, and it is reasonable to expect the receiver to resynchronize to the stream anyway (i.e. filling the playout buffer to the minimum watermark etc.). In a QoS engineered network the required number of bits is a way less than 7 or 8, at lease for real time voice. To me it seems that the issue with SN is totally different from the issue with the transition bit/PT. Jarno -- Jarno Rajahalme Nokia Research Center / Boston 3 Burlington Woods Drive, Suite 260 Burlington, MA 01803, USA From rem-conf Thu Oct 29 09:05:56 1998 From rem-conf-request@es.net Thu Oct 29 09:05:56 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zYvQo-00060R-00; Thu, 29 Oct 1998 09:00:18 -0800 Received: from ns.stardust.com (ziggy.stardust.com) [205.184.205.34] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zYvQm-00060G-00; Thu, 29 Oct 1998 09:00:16 -0800 Received: from jester (dhcp204-101.stardust.com [205.184.204.101]) by ziggy.stardust.com (8.8.8/8.8.8/Debian/GNU/Stardust) with SMTP id JAA20107 for ; Thu, 29 Oct 1998 09:00:16 -0800 Message-Id: <3.0.5.32.19981029090058.00a63910@stardust.com> X-Sender: martinb@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 29 Oct 1998 09:00:58 -0800 To: rem-conf@es.net From: Marty Bickford Subject: BOF: Simple Multicast - A New Proposal (Nov 15th) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list There are important meetings (BOFs) that people on this list may want to attend. They will take place at iBAND. iBAND is an in-depth, technical conference on new Internet bandwidth technologies and the opportunities they create in enterprise and ISP networks. Switching, IP Multicast, QoS, ToS, CoS, Integrated services, SLAs, voice over IP, DSL, Satellite, Caching, Gigabit Ethernet and more will be covered. Speakers include: Judy Estrin, Fred Baker, Bob Braden, Radia Perlman, Kevin Werbach, Kevin Almeroth, Jonathan Rosenberg, Yoel Gat, Yoram Bernet, Brian Carpenter, Dave Thaler, Rod Murchison, and more. iBAND is Nov 15-17 at the DoubleTree Hotel in San Jose, CA. http://www.stardust.com/iband/ The BOF description is below. Other BOFs will include: - Linux and Bandwidth Management, David S. Miller - QoS-Enabled Windows Applications, Bob Quinn & Tim Moore - The Need for a QoS Forum, Martin Hall - Active Networks, Bob Quinn - RSVP: Past, Present, and Future, Bob Braden - Wave Division Multiplexing (WDM) and NTONC, Hal Edwards Simple Multicast - A New Proposal (Nov 15th) -------------------------------------------- This BOF discusses a design for multicast, called "simple multicast" that is very simple, low overhead, makes multicast address allocation trivial, and works both within and between domains. It is generally agreed that current multicast algorithms do not scale, so the belief is that the current algorithms (such as DVMRP, MOSPF, or PIM) be confined to a domain, and that another class of algorithms be used to interconnect domains. The central simplifying assumption behind "simple multicast" is that the group be identified by two pieces of information: the core address and the multicast address, and that members that want to join discover the 8 byte identifier rather than just the multicast address. The result is that instead of 28 bits of multicast address that must be administered over the entire Internet, in aggregatable blocks dynamically acquired by each domain, each core node can administer the entire multicast address space. We will compare this approach to the current PIM/BGMP/MASC/AAP approach, as well as to the recently suggested Express model, which deals only with per-source trees. Led by Dr. Radia Perlman of the Boston Center for Networking, Sun Microsystems Laboratories You do need to register. Register and get more information on iBAND at: http://www.stardust.com/iband/ ____________________________________________________ Marty Bickford - 408.879.8080 (8081-fax) Stardust Forums - http://www.stardust.com iBAND 98 - http://www.stardust.com/iband/ From rem-conf Thu Oct 29 09:28:26 1998 From rem-conf-request@es.net Thu Oct 29 09:28:25 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zYvmM-0006tD-00; Thu, 29 Oct 1998 09:22:34 -0800 Received: from also.media.org [204.62.246.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zYvmK-0006t3-00; Thu, 29 Oct 1998 09:22:32 -0800 Received: (from carl@localhost) by also.media.org (8.9.1/8.9.1/980727bjb) id MAA06021; Thu, 29 Oct 1998 12:16:46 -0500 (EST) From: Carl Malamud Message-Id: <199810291716.MAA06021@also.media.org> Subject: Re: BOF: Simple Multicast - A New Proposal (Nov 15th) To: martinb@stardust.com (Marty Bickford) Date: Thu, 29 Oct 1998 12:16:46 -0500 (EST) Cc: rem-conf@es.net In-Reply-To: <3.0.5.32.19981029090058.00a63910@stardust.com> from "Marty Bickford" at Oct 29, 98 09:00:58 am Organization: Invisible Worlds, Inc. X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Is there a way for people who are not willing or able to fork out $695 to get more information or to see these BOFs via the net? Carl According to Marty Bickford: > There are important meetings (BOFs) that people on this > list may want to attend. They will take place at iBAND. > iBAND is an in-depth, technical conference on new Internet > bandwidth technologies and the opportunities they create in > enterprise and ISP networks. Switching, IP Multicast, QoS, > ToS, CoS, Integrated services, SLAs, voice over IP, DSL, > Satellite, Caching, Gigabit Ethernet and more will be covered. > Speakers include: Judy Estrin, Fred Baker, Bob Braden, Radia > Perlman, Kevin Werbach, Kevin Almeroth, Jonathan Rosenberg, > Yoel Gat, Yoram Bernet, Brian Carpenter, Dave Thaler, > Rod Murchison, and more. > iBAND is Nov 15-17 at the DoubleTree Hotel in San Jose, CA. > http://www.stardust.com/iband/ > The BOF description is below. Other BOFs will include: > - Linux and Bandwidth Management, David S. Miller > - QoS-Enabled Windows Applications, Bob Quinn & Tim Moore > - The Need for a QoS Forum, Martin Hall > - Active Networks, Bob Quinn > - RSVP: Past, Present, and Future, Bob Braden > - Wave Division Multiplexing (WDM) and NTONC, Hal Edwards > Simple Multicast - A New Proposal (Nov 15th) > -------------------------------------------- > This BOF discusses a design for multicast, called "simple > multicast" that is very simple, low overhead, makes multicast > address allocation trivial, and works both within and between > domains. It is generally agreed that current multicast > algorithms do not scale, so the belief is that the current > algorithms (such as DVMRP, MOSPF, or PIM) be confined to a > domain, and that another class of algorithms be used to > interconnect domains. The central simplifying assumption > behind "simple multicast" is that the group be identified > by two pieces of information: the core address and the > multicast address, and that members that want to join > discover the 8 byte identifier rather than just the multicast > address. The result is that instead of 28 bits of multicast > address that must be administered over the entire Internet, > in aggregatable blocks dynamically acquired by each domain, > each core node can administer the entire multicast address space. > We will compare this approach to the current PIM/BGMP/MASC/AAP > approach, as well as to the recently suggested Express model, > which deals only with per-source trees. > Led by Dr. Radia Perlman of the Boston Center for Networking, > Sun Microsystems Laboratories > You do need to register. Register and get more information > on iBAND at: http://www.stardust.com/iband/ > ____________________________________________________ > Marty Bickford - 408.879.8080 (8081-fax) > Stardust Forums - http://www.stardust.com > iBAND 98 - http://www.stardust.com/iband/ From rem-conf Thu Oct 29 09:43:55 1998 From rem-conf-request@es.net Thu Oct 29 09:43:55 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zYw4x-0007gk-00; Thu, 29 Oct 1998 09:41:47 -0800 Received: from ns.stardust.com (ziggy.stardust.com) [205.184.205.34] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zYw4w-0007ga-00; Thu, 29 Oct 1998 09:41:46 -0800 Received: from jester (dhcp204-101.stardust.com [205.184.204.101]) by ziggy.stardust.com (8.8.8/8.8.8/Debian/GNU/Stardust) with SMTP id JAA22209; Thu, 29 Oct 1998 09:41:39 -0800 Message-Id: <3.0.5.32.19981029094223.00a97c20@stardust.com> X-Sender: martinb@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 29 Oct 1998 09:42:23 -0800 To: Carl Malamud From: Marty Bickford Subject: Re: BOF: Simple Multicast - A New Proposal (Nov 15th) Cc: rem-conf@es.net In-Reply-To: <199810291716.MAA06021@also.media.org> References: <3.0.5.32.19981029090058.00a63910@stardust.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We do have a few educational/research passes for iBAND (email me directly). We aren't planning on a net feed. At 12:16 PM 10/29/98 -0500, Carl Malamud wrote: >Is there a way for people who are not willing or able to fork >out $695 to get more information or to see these BOFs via >the net? > >Carl > >According to Marty Bickford: > >> There are important meetings (BOFs) that people on this >> list may want to attend. They will take place at iBAND. > >> iBAND is an in-depth, technical conference on new Internet >> bandwidth technologies and the opportunities they create in >> enterprise and ISP networks. Switching, IP Multicast, QoS, >> ToS, CoS, Integrated services, SLAs, voice over IP, DSL, >> Satellite, Caching, Gigabit Ethernet and more will be covered. >> Speakers include: Judy Estrin, Fred Baker, Bob Braden, Radia >> Perlman, Kevin Werbach, Kevin Almeroth, Jonathan Rosenberg, >> Yoel Gat, Yoram Bernet, Brian Carpenter, Dave Thaler, >> Rod Murchison, and more. > >> iBAND is Nov 15-17 at the DoubleTree Hotel in San Jose, CA. >> http://www.stardust.com/iband/ > >> The BOF description is below. Other BOFs will include: > >> - Linux and Bandwidth Management, David S. Miller >> - QoS-Enabled Windows Applications, Bob Quinn & Tim Moore >> - The Need for a QoS Forum, Martin Hall >> - Active Networks, Bob Quinn >> - RSVP: Past, Present, and Future, Bob Braden >> - Wave Division Multiplexing (WDM) and NTONC, Hal Edwards > >> Simple Multicast - A New Proposal (Nov 15th) >> -------------------------------------------- >> This BOF discusses a design for multicast, called "simple >> multicast" that is very simple, low overhead, makes multicast >> address allocation trivial, and works both within and between >> domains. It is generally agreed that current multicast >> algorithms do not scale, so the belief is that the current >> algorithms (such as DVMRP, MOSPF, or PIM) be confined to a >> domain, and that another class of algorithms be used to >> interconnect domains. The central simplifying assumption >> behind "simple multicast" is that the group be identified >> by two pieces of information: the core address and the >> multicast address, and that members that want to join >> discover the 8 byte identifier rather than just the multicast >> address. The result is that instead of 28 bits of multicast >> address that must be administered over the entire Internet, >> in aggregatable blocks dynamically acquired by each domain, >> each core node can administer the entire multicast address space. > >> We will compare this approach to the current PIM/BGMP/MASC/AAP >> approach, as well as to the recently suggested Express model, >> which deals only with per-source trees. > >> Led by Dr. Radia Perlman of the Boston Center for Networking, >> Sun Microsystems Laboratories > >> You do need to register. Register and get more information >> on iBAND at: http://www.stardust.com/iband/ > >> ____________________________________________________ >> Marty Bickford - 408.879.8080 (8081-fax) >> Stardust Forums - http://www.stardust.com > >> iBAND 98 - http://www.stardust.com/iband/ > > ____________________________________________________ Marty Bickford - 408.879.8080 (8081-fax) Stardust Forums - http://www.stardust.com iBAND 98 - http://www.stardust.com/iband/ From rem-conf Thu Oct 29 12:25:04 1998 From rem-conf-request@es.net Thu Oct 29 12:25:03 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zYyUI-0001zh-00; Thu, 29 Oct 1998 12:16:06 -0800 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zYyUH-0001zX-00; Thu, 29 Oct 1998 12:16:05 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id MAA17654; Thu, 29 Oct 1998 12:16:05 -0800 (PST) Message-Id: <3.0.3.32.19981029121604.00a915f0@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 29 Oct 1998 12:16:04 -0800 To: (Recipient list suppressed) From: Florissa Colina Subject: 11/04 Berkeley Multimedia, Interfaces and Graphics Seminar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Interfaces and Graphics Seminar The Use of Documents in Offices Wednesday November 4, 1998 12:30-2:00 PM 405 Soda Hall Annette Adler Xerox Palo Alto Research Center This talk is about how documents get used. It describes a project, Goldfish, that I've been involved with for the last two years here at Xerox. Goldfish considers how people in a variety of office settings use documents, emerging document types and document appliances (such as pagers and palm pilots), particularly in the context of: 1. intermingled virtual and physical environments (and how folks negotiate getting back and forth) 2. heterogeneous media and document components (digital, paper, voice as well as mixtures of text, graphics, color/black and white, etc.) 3. multiple locations for work Using examples from real people in real offices I will talk about particularly interesting patterns of use that point at possible directions for further work. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. Sponsored by the Berkeley Multimedia Research Center ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Thu Oct 29 18:00:30 1998 From rem-conf-request@es.net Thu Oct 29 18:00:29 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zZ3jQ-00060B-00; Thu, 29 Oct 1998 17:52:04 -0800 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0zZ3jO-000600-00; Thu, 29 Oct 1998 17:52:02 -0800 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Oct 29 20:51:13 EST 1998 Received: from dnrc.bell-labs.com ([135.17.200.64]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id UAA04531; Thu, 29 Oct 1998 20:51:07 -0500 (EST) Message-ID: <36391B19.60228A91@dnrc.bell-labs.com> Date: Thu, 29 Oct 1998 20:49:13 -0500 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: "Jarno.Rajahalme@research.nokia.com" CC: "'jdrosen@dnrc.bell-labs.co'" , "'senthil.sengodan@research.nokia.com'" , "'baranitharan.subbiah@research.nokia.com'" , "'casner@cisco.com'" , "'ecr@qualcomm.com'" , "'hgs@cs.columbia.edu'" , "'kylem@qualcomm.com'" , "'C.Perkins@cs.ucl.ac.uk'" , "'jwn2@qualcomm.com'" , "'rem-conf@es.net'" Subject: Re: Revised AVT charter and draft-mckay- References: <01BE032F.E5A059B0.Jarno.Rajahalme@research.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jarno Rajahalme wrote: > So, the media packets which arrive at B are only > > those used with codec X and Z. Both X and Z have the same value for the > > toggle bit. When should B use Z instead of X? One might say to switch > > after the signaling message changing X to Y is received. However, a > > delayed packet may arrive, and thus be mis-decoded. > > > > I think there is a simple solution to the problem presented above. When A > is signaling B about the change in encoding, the B needs to either accept > or reject the change (B might not be able to decode the proposed change). A > will toggle the transition bit (and change the encoding) only after > receiving the response from B. To guarantee that the synchronization is not > lost, B will wait to see the actual change on the received toggle bits, if > there was a change pending before accepting further changes. Also, A will > most probably be periodically sending out background noise parameters also > during silence, so that the possible wait will actually end. Note that if > there is no data to send, the time it takes to signal about the change does > not matter. That helps; this is pretty much what was defined in draft-ietf-avt-muxissues. However, I simply question whether this is worth it. You'll have a constraint on changes per second, introduce additional signaling functionality, and add latency to the system. Why not stick with the original RTP model? We're not talking about so many bits here. > > You will also run into sequence number > > rollaround issues, just as the one I describe above. To be fairly robust > > and safe, you should really use much more than one bit, say 7 or 8 bits, > > of SN (which will avoid the problem above). > > Sequence number clearly needs more than one bit, and no-one has proposed > signaling the SN increases. Also, the SN increases for each packet sent > only and not during the silence. The number of SN bits required depends on > the anticipated packet loss, the payload length (in time) and the real-time > constraints of the application. I'd say that the minimum number of SN bits > is such that consecutive packet losses causing the rollaround issue would > not allow adequate compensation for the losses. When this happens, any > number of additional bits will not help to fix the stream, and it is > reasonable to expect the receiver to resynchronize to the stream anyway > (i.e. filling the playout buffer to the minimum watermark etc.). In a QoS > engineered network the required number of bits is a way less than 7 or 8, > at lease for real time voice. Sorry for my abuse of terminology which has caused some confusion. I was not referring to the regular sequence number which you discuss above. My point was that your toggle bit is effectively a 1 bit sequence number, limiting your rate of changes to 1 per RTT. This sequence number represents changes in semantics of the payload, as signaled out of band. You can increase "throughput", that is, the number of changes per RTT, by increasing this to more bits. Increasing it to more bits would also help avoid the "wraparound problem", whereby packet encodings are confused because the bit has toggled twice between the time a late packet was sent and received (although the regular SN could be used to help here, at the cost of additional complexity - you'll need to store a list of past codecs for each range of sequence numbers). -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Fri Oct 30 09:39:58 1998 From rem-conf-request@es.net Fri Oct 30 09:39:57 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zZIOk-0005ij-00; Fri, 30 Oct 1998 09:31:42 -0800 Received: from pinea.xerox.fr [193.56.117.2] (firewall-user) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zZIOc-0005iX-00; Fri, 30 Oct 1998 09:31:36 -0800 Received: from meije.grenoble.xrce.xerox.com (meije.grenoble.xrce.xerox.com [13.202.220.10]) by pinea.xerox.fr (8.9.0/8.9.0) with ESMTP id SAA14112; Fri, 30 Oct 1998 18:31:00 +0100 (MET) Received: from caucase.grenoble.xrce.xerox.com (caucase.grenoble.xrce.xerox.com [13.202.222.150]) by meije.grenoble.xrce.xerox.com (8.9.1a/8.9.1) with ESMTP id SAA26448; Fri, 30 Oct 1998 18:30:56 +0100 (MET) Received: by caucase.grenoble.xrce.xerox.com with Internet Mail Service (5.5.2232.9) id ; Fri, 30 Oct 1998 18:30:56 +0100 Message-ID: From: Franck Martel To: "'Christian.Donot@inria.fr'" , "'mbone-fr@inria.fr'" , "'rem-conf@es.net'" , "'Pierre.Laforgie@imag.fr'" Subject: Connexion Mbone Date: Fri, 30 Oct 1998 18:30:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Bonjour, Je travaille actuellement a Meylan (38) sur les systemes de videoconference. Les outils dont je dispose sont des stations Unix SUN SS20 equipees de cartes video Sun, de camera Flexcam et de microphones Sun. Ces stations sont configurees avec les outils Mbone Vic, Rat et Vat. Aujourd'hui je suis en train de choisir les equipements de videoconference adaptes aux plateformes PCs (cartes audio et video, cameras et microphones). J'envisage de tester les outils MBone et souhaiterais vivement pour cela me connecter au FMBone et au MBone. D'ou les questions suivantes: 1) Que conseillez vous en matiere de cartes d'acquisition video, de carte audio, de camera et de microphone pour equiper des PCs fonctionnants sous Windows NT4.0? des stations Unix fonctionnants sous Solaris 2.5 ou 2.6? 2) Pouvez vous m'indiquer la marche a suivre pour se connecter au FMBone et MBone? Merci. En attendant votre reponse je vous prie d'agreer l'expression de mes sentiments les meilleurs. Franck MARTEL-BADINGA. -------------------------------------------------------------------------------------- XEROX RESEARCH CENTER EUROPE 6 chemin de Maupertuis 38240 Meylan FRANCE Phone: +33 (0)476.61.51.14 Email : martel@xrce.xerox.com -------------------------------------------------------------------------------------- From rem-conf Fri Oct 30 13:44:18 1998 From rem-conf-request@es.net Fri Oct 30 13:44:17 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zZM8M-0001Pz-00; Fri, 30 Oct 1998 13:31:02 -0800 Received: from dnssrv.nippan.co.jp [202.235.14.66] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zZM8D-0001PC-00; Fri, 30 Oct 1998 13:30:53 -0800 Received: from dnssrv.nippan.co.jp by dnssrv.nippan.co.jp (8.8.2/4.03) id GAA12850; Sat, 31 Oct 1998 06:21:48 +0900 From: return31@yahoo.com Date: Fri, 30 Oct 98 14:22:22 EST To: shawn555@msn.com Subject: Market Timing Message-ID: <359DFE77.4AC9@erols.com> Reply-To: jonny@worldnet.att.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list October 29, 1998 Market Timing Table of Contents 1. Market Commentary 2. USDI - a player in the IRIDIUM Satellite project 3. NLAB update 4. Departments 1. MARKET COMMENTARY As predicted in our last issue the US equity markets have stabilized and begun to head higher again. Asian markets have had a nice rebound and some currencies have begun to strengthen against the US dollar. Hong Kong continues to show some weakness, but these problems can probably be traced back to the actions of the Chinese government in Beijing. During the last week European markets have also begun to move higher once again. Against this backdrop and more importantly to our subscribers, there is a groundswell of interest and commentary developing in and about the "small cap" sector of the market. The Russell 2000 small cap index has moved from a low of 303.87 in the first week of October/98 to close on October 23/98 at 367.05. This is an increase of over 17% in 2 weeks. We believe the market is entering a phase where interest will begin to increase in this long neglected sector of the market. There are excellent investment grade and speculative opportunities in this area, which have long been overlooked by the institutional money managers with their fixation on the Dow 30 stocks. The DOW is now beginning to look, if not a little tired, at least fully valued. The fund managers are now going to have to go to work and find new areas in which to deploy their client's money. Leverage is a bad word on Wall Street these days and without leverage these managers are stuck with relatively low returns in the bond and money markets (under 5% on 30 year US treasury bills). It is our feeling this will result in more money flowing into the smaller cap sector of the market - and remember - with the huge amount of money now in mutual funds and the market in general, it only takes a relatively small reallocation of assets by market participants, to have a substantial impact on the price of these smaller company's shares. 2. US DIGITAL COMMUNICATIONS INC. (USDI) We are profiling a new company in this issue of MT: US Digital Communications Inc. Symbol: USDI Trades: OTC BB USDI is a proxy for one of the biggest events in the evolution of wirelesses communications the IRIDIUM Global Communications System. USDI in conjunction with its subsidiaries SKYSITE (http://www.skysite.com), INSAT and PROJECT 77 (http://www.project77.com), is a supplier of both the Motorola and Kyocera telephones and pagers and a resellers of air time for the IRIDIUM network. As such, expect to see their revenues and profits grow in lock step with the growth of the overall satellite network. The IRIDIUM satellite phone system consists of 66 low-level satellites, which completely cover every point of the planet. This $5 billion dollar investment allows any point or individual on earth to access telephone, data transfer or paging service. The 19 members of this consortium, which has been spearheaded by Motorola, include some of the largest telecom companies in the world, as well as a number of very large Middle Eastern, Asian and South American private investment companies. The financial commitment is very large and IRIDIUM (http://www.iridium.com) will go into service November 1, 1998. The "start" date for IRIDIUM service is one of the reasons that we are bringing this company to your attention now. As you can see if you look at a chart of the stock (http://www.bigcharts.com) the USDI's share price peaked at $7.00 in early July of this year, in what we believe was anticipation of the original service commencement date of September 23, 1998. When it became obvious this date was going to be pushed back to November 1, momentum was lost by the stock. It then bottomed out on October 8 at $2.30. In the last week it has moved back to close on Friday (Oct 23) at $3.93 up 7/8s of a point or 28.5% for the day on 366,200 shares traded! See the October 23 USDI News Release at: http://biz.yahoo.com/prnews/981023/dc_fcc_us__1.html The IRIDIUM name will be on a lot of peoples "radar" screens soon as a $100 million public relations, marketing and advertising program will help launch this service. This is definitely a "timing" and "momentum" play and there is no doubt that the very wealthy and smart companies and individuals that are part of the IRIDIUM consortium are going to work hard to make this THE wireless network of the future. Given the momentum that is building in the stock, USDI could easily see its old high of $7.00 between now and shortly after startup of the IRIDIUM service in the next week. Depending on a stable market and some positive news, which we fully expect, and given the sophistication of the underwriters and companies behind the IRIDIUM project, USDI prices above $10 are quite possible over the next 90 days. 4. NUONCOLOGY LABS UPDATE NuOncology Labs Inc. (NLAB - OTC BB) continues to make progress on its business plan and have announced the opening of their new offices, predictive oncology testing and research building in Houston TX. (See October 15th News Release at: http://biz.yahoo.com/n/n/nlab.html). This new facility is capable of performing testing to the rate of 1000 comprehensive predictive profiles per month. MT heard NuOncology is planning a road show in Europe that will include NLAB management starting early in November. These "show and tell" meetings are intended to attract additional funding, market sponsorship as well as institutional and broker interest for NLAB. We expect soon after this trip there will be further word on the Arglabin/FTI issue by way of publication of their research in a recognized medical journal. In addition there will be more results coming on the second large sample of patients who have been undergoing treatment for various types of cancer with Arglabin. The share price has fallen on relatively small volume and somewhat tracks the skittish market we have had for the last 2 months. It would not be inconceivable that this market rebounds right back to the $6.50 range in a day or two of trading - especially if there is some further news on the use of Arglabin as a successful cancer therapy. REMEMBER this is not a theoretical concept NLAB is working on - people ARE BEING TREATED with ARGLABIN today and their CANCERS ARE IN REMISSIOIN. This company has the potential to be a $500 million - $1 Billion cap company and we believe you will begin to see some recognition of this in the marketplace BEFORE THE END OF NOVEMBER. For a current quote on NLAB please go to: http://quote.yahoo.com/q?s=nlab&d=d1 DEPARTMENTS A. Stock Quotes B. How to Unsubscribe to MT C. Disclaimer A. STOCK QUOTES For stock quotes on any company please go to: http://www.bigchart.com B. HOW TO UNSUBSCRIBE TO MT Please note, as per your request you are a subscriber to MT. If at any time you wish to unsubscribe please put 'unsubscribe' in the subject of your e-mail and return to: newsletter@premiumservice.com MT respects your privacy and will NEVER release your e-mail address to a third party for any reason. D. DISCLAIMER: By being a subscriber you are acknowledging you have read and fully understand our disclaimer below. MarketTiming (hereafter called MarketTiming) is an independent electronic publication devoted to providing information and factual analysis on selected companies that in the opinion of MarketTiming have investment potential. Companies featured by MarketTiming may have paid MarketTiming or their affiliates the editor or the editor's affiliates family or agents for the dissemination of company information through MarketTiming. MarketTiming and/or its affiliates or principals may have been paid in cash, stock or stock options to disseminate information about the companies it has featured. These payments may have been acquired prior to the dissemination of information on any particular company featured by MarketTiming and stock positions held by MarketTiming employees, affiliates or principals may increase or decrease at any time. Such compensation received by MarketTiming or any of its employees, the editor or any affiliates should be viewed by readers as a potential conflict of interest. The principals of MarketTiming or its affiliates may have from time to time had business dealings with, or hold a substantial stock position in any of the companies featured. Principals, family or affiliates of MarketTiming may also buy hold or sell securities (long or short) in the companies mentioned at any time prior to or after a particular company has been featured by MarketTiming. Our purpose is to locate and research equity investments in micro or small capitalization companies that in our opinion has the potential for long-term appreciation. Investing in any stock must be considered risky, however investing in the companies MarketTiming reviews must be considered to be high risk and use of the information provided is at the investor's sole risk. Purchase of such high-risk securities may result in loss of some or all of the investor's original investment. All statements and expressions are the opinion of MarketTiming and/or its principals and affiliates and are not meant to be a solicitation or recommendation to buy, sell, or hold securities. MarketTiming is not a registered investment advisor or broker dealer. The information MarketTiming basis its reports on are generally provided by the company being featured or may come from sources and/or interviews conducted by MarketTiming. While every effort is made to provide true and meaningful information no guarantee is made by MarketTiming as to the accuracy of the information provided. Investors should not rely solely on the information contained in MarketTiming reports to make an investment decision. They should consult a registered broker or financial advisor before purchasing any stock. Investors should consider the information provided by MarketTiming a starting point for doing additional independent research on any of the featured companies. Companies featured are often at very early stages of development and can therefore be subject to business failure, which could result in the investor losing all his or her investment. Statements of fact in the MarketTiming reports are made as of the date stated and are subject to change without notice. Recipients of MarketTiming reports must assume that there has been a change in the affairs of companies profiled, from the date of the report - to the time it may be seen by them. Recipients should independently ascertain from their own investment advisors or the company being profiled the current accuracy of any statements, which may influence their investment decisions. Investing in micro-cap securities is highly speculative and carries an extremely high degree of risk. It is possible that an investor's investment may be lost or impaired due to the speculative nature of the companies profiled by MarketTiming. By subscribing to MarketTiming all subscribers acknowledge they have read and fully understand the above disclaimer. end From rem-conf Fri Oct 30 21:59:40 1998 From rem-conf-request@es.net Fri Oct 30 21:59:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zZTws-0005Rs-00; Fri, 30 Oct 1998 21:51:42 -0800 Received: from sun.tck.ac.jp [210.154.58.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zZTwF-0005Qk-00; Fri, 30 Oct 1998 21:51:07 -0800 Received: from 210.154.58.3 by sun.tck.ac.jp (8.8.7/3.6Wbeta5+97081211) id OAA02213; Sat, 31 Oct 1998 14:27:44 +0900 (JST) From: jonny@worldnet.att.net Date: Fri, 30 Oct 98 22:00:21 EST To: jobby@worldnet.att.net Subject: Market Timing Message-ID: <> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list October 29, 1998 Market Timing Table of Contents 1. Market Commentary 2. USDI - a player in the IRIDIUM Satellite project 3. NLAB update 4. Departments 1. MARKET COMMENTARY As predicted in our last issue the US equity markets have stabilized and begun to head higher again. Asian markets have had a nice rebound and some currencies have begun to strengthen against the US dollar. Hong Kong continues to show some weakness, but these problems can probably be traced back to the actions of the Chinese government in Beijing. During the last week European markets have also begun to move higher once again. Against this backdrop and more importantly to our subscribers, there is a groundswell of interest and commentary developing in and about the "small cap" sector of the market. The Russell 2000 small cap index has moved from a low of 303.87 in the first week of October/98 to close on October 23/98 at 367.05. This is an increase of over 17% in 2 weeks. We believe the market is entering a phase where interest will begin to increase in this long neglected sector of the market. There are excellent investment grade and speculative opportunities in this area, which have long been overlooked by the institutional money managers with their fixation on the Dow 30 stocks. The DOW is now beginning to look, if not a little tired, at least fully valued. The fund managers are now going to have to go to work and find new areas in which to deploy their client's money. Leverage is a bad word on Wall Street these days and without leverage these managers are stuck with relatively low returns in the bond and money markets (under 5% on 30 year US treasury bills). It is our feeling this will result in more money flowing into the smaller cap sector of the market - and remember - with the huge amount of money now in mutual funds and the market in general, it only takes a relatively small reallocation of assets by market participants, to have a substantial impact on the price of these smaller company's shares. 2. US DIGITAL COMMUNICATIONS INC. (USDI) We are profiling a new company in this issue of MT: US Digital Communications Inc. Symbol: USDI Trades: OTC BB USDI is a proxy for one of the biggest events in the evolution of wirelesses communications the IRIDIUM Global Communications System. USDI in conjunction with its subsidiaries SKYSITE (http://www.skysite.com), INSAT and PROJECT 77 (http://www.project77.com), is a supplier of both the Motorola and Kyocera telephones and pagers and a resellers of air time for the IRIDIUM network. As such, expect to see their revenues and profits grow in lock step with the growth of the overall satellite network. The IRIDIUM satellite phone system consists of 66 low-level satellites, which completely cover every point of the planet. This $5 billion dollar investment allows any point or individual on earth to access telephone, data transfer or paging service. The 19 members of this consortium, which has been spearheaded by Motorola, include some of the largest telecom companies in the world, as well as a number of very large Middle Eastern, Asian and South American private investment companies. The financial commitment is very large and IRIDIUM (http://www.iridium.com) will go into service November 1, 1998. The "start" date for IRIDIUM service is one of the reasons that we are bringing this company to your attention now. As you can see if you look at a chart of the stock (http://www.bigcharts.com) the USDI's share price peaked at $7.00 in early July of this year, in what we believe was anticipation of the original service commencement date of September 23, 1998. When it became obvious this date was going to be pushed back to November 1, momentum was lost by the stock. It then bottomed out on October 8 at $2.30. In the last week it has moved back to close on Friday (Oct 23) at $3.93 up 7/8s of a point or 28.5% for the day on 366,200 shares traded! See the October 23 USDI News Release at: http://biz.yahoo.com/prnews/981023/dc_fcc_us__1.html The IRIDIUM name will be on a lot of peoples "radar" screens soon as a $100 million public relations, marketing and advertising program will help launch this service. This is definitely a "timing" and "momentum" play and there is no doubt that the very wealthy and smart companies and individuals that are part of the IRIDIUM consortium are going to work hard to make this THE wireless network of the future. Given the momentum that is building in the stock, USDI could easily see its old high of $7.00 between now and shortly after startup of the IRIDIUM service in the next week. Depending on a stable market and some positive news, which we fully expect, and given the sophistication of the underwriters and companies behind the IRIDIUM project, USDI prices above $10 are quite possible over the next 90 days. 4. NUONCOLOGY LABS UPDATE NuOncology Labs Inc. (NLAB - OTC BB) continues to make progress on its business plan and have announced the opening of their new offices, predictive oncology testing and research building in Houston TX. (See October 15th News Release at: http://biz.yahoo.com/n/n/nlab.html). This new facility is capable of performing testing to the rate of 1000 comprehensive predictive profiles per month. MT heard NuOncology is planning a road show in Europe that will include NLAB management starting early in November. These "show and tell" meetings are intended to attract additional funding, market sponsorship as well as institutional and broker interest for NLAB. We expect soon after this trip there will be further word on the Arglabin/FTI issue by way of publication of their research in a recognized medical journal. In addition there will be more results coming on the second large sample of patients who have been undergoing treatment for various types of cancer with Arglabin. The share price has fallen on relatively small volume and somewhat tracks the skittish market we have had for the last 2 months. It would not be inconceivable that this market rebounds right back to the $6.50 range in a day or two of trading - especially if there is some further news on the use of Arglabin as a successful cancer therapy. REMEMBER this is not a theoretical concept NLAB is working on - people ARE BEING TREATED with ARGLABIN today and their CANCERS ARE IN REMISSIOIN. This company has the potential to be a $500 million - $1 Billion cap company and we believe you will begin to see some recognition of this in the marketplace BEFORE THE END OF NOVEMBER. For a current quote on NLAB please go to: http://quote.yahoo.com/q?s=nlab&d=d1 DEPARTMENTS A. Stock Quotes B. How to Unsubscribe to MT C. Disclaimer A. STOCK QUOTES For stock quotes on any company please go to: http://www.bigchart.com B. HOW TO UNSUBSCRIBE TO MT Please note, as per your request you are a subscriber to MT. If at any time you wish to unsubscribe please put 'unsubscribe' in the subject of your e-mail and return to: newsletter@premiumservice.com MT respects your privacy and will NEVER release your e-mail address to a third party for any reason. D. DISCLAIMER: By being a subscriber you are acknowledging you have read and fully understand our disclaimer below. MarketTiming (hereafter called MarketTiming) is an independent electronic publication devoted to providing information and factual analysis on selected companies that in the opinion of MarketTiming have investment potential. Companies featured by MarketTiming may have paid MarketTiming or their affiliates the editor or the editor's affiliates family or agents for the dissemination of company information through MarketTiming. MarketTiming and/or its affiliates or principals may have been paid in cash, stock or stock options to disseminate information about the companies it has featured. These payments may have been acquired prior to the dissemination of information on any particular company featured by MarketTiming and stock positions held by MarketTiming employees, affiliates or principals may increase or decrease at any time. Such compensation received by MarketTiming or any of its employees, the editor or any affiliates should be viewed by readers as a potential conflict of interest. The principals of MarketTiming or its affiliates may have from time to time had business dealings with, or hold a substantial stock position in any of the companies featured. Principals, family or affiliates of MarketTiming may also buy hold or sell securities (long or short) in the companies mentioned at any time prior to or after a particular company has been featured by MarketTiming. Our purpose is to locate and research equity investments in micro or small capitalization companies that in our opinion has the potential for long-term appreciation. Investing in any stock must be considered risky, however investing in the companies MarketTiming reviews must be considered to be high risk and use of the information provided is at the investor's sole risk. Purchase of such high-risk securities may result in loss of some or all of the investor's original investment. All statements and expressions are the opinion of MarketTiming and/or its principals and affiliates and are not meant to be a solicitation or recommendation to buy, sell, or hold securities. MarketTiming is not a registered investment advisor or broker dealer. The information MarketTiming basis its reports on are generally provided by the company being featured or may come from sources and/or interviews conducted by MarketTiming. While every effort is made to provide true and meaningful information no guarantee is made by MarketTiming as to the accuracy of the information provided. Investors should not rely solely on the information contained in MarketTiming reports to make an investment decision. They should consult a registered broker or financial advisor before purchasing any stock. Investors should consider the information provided by MarketTiming a starting point for doing additional independent research on any of the featured companies. Companies featured are often at very early stages of development and can therefore be subject to business failure, which could result in the investor losing all his or her investment. Statements of fact in the MarketTiming reports are made as of the date stated and are subject to change without notice. Recipients of MarketTiming reports must assume that there has been a change in the affairs of companies profiled, from the date of the report - to the time it may be seen by them. Recipients should independently ascertain from their own investment advisors or the company being profiled the current accuracy of any statements, which may influence their investment decisions. Investing in micro-cap securities is highly speculative and carries an extremely high degree of risk. It is possible that an investor's investment may be lost or impaired due to the speculative nature of the companies profiled by MarketTiming. By subscribing to MarketTiming all subscribers acknowledge they have read and fully understand the above disclaimer. end From rem-conf Sat Oct 31 09:45:19 1998 From rem-conf-request@es.net Sat Oct 31 09:45:18 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zZf0J-0003Ui-00; Sat, 31 Oct 1998 09:39:59 -0800 Received: from jekyll.piermont.com [206.1.51.15] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zZf0I-0003UY-00; Sat, 31 Oct 1998 09:39:58 -0800 Received: from jekyll (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id MAA13916 for ; Sat, 31 Oct 1998 12:39:47 -0500 (EST) Message-Id: <199810311739.MAA13916@jekyll.piermont.com> To: rem-conf@es.net Subject: jonny@worldnet.att.net: Market Timing Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/mixed; boundary="Multipart_Sat_Oct_31_12:39:47_1998-1" Content-Transfer-Encoding: 7bit Date: Sat, 31 Oct 1998 12:39:47 -0500 From: "Perry E. Metzger" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --Multipart_Sat_Oct_31_12:39:47_1998-1 Content-Type: text/plain; charset=US-ASCII If the owners of this list would just restrict it to "only subscribers can post", idiots like this couldn't spam it. --Multipart_Sat_Oct_31_12:39:47_1998-1 Content-Type: message/rfc822 Return-Path: rem-conf-request@es.net Delivery-Date: Sat Oct 31 01:07:05 1998 From: jonny@worldnet.att.net Date: Fri, 30 Oct 98 22:00:21 EST To: jobby@worldnet.att.net Subject: Market Timing Message-ID: <> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list October 29, 1998 Market Timing Table of Contents --Multipart_Sat_Oct_31_12:39:47_1998-1-- From rem-conf Sat Oct 31 12:55:12 1998 From rem-conf-request@es.net Sat Oct 31 12:55:11 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zZhx0-0005Ku-00; Sat, 31 Oct 1998 12:48:46 -0800 Received: from revnet4.revnet.com [198.51.35.125] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zZhwy-0005Kk-00; Sat, 31 Oct 1998 12:48:44 -0800 Received: from gs4.revnet.com (gs4.revnet.com [198.51.35.84]) by revnet4.revnet.com (8.8.7/8.8.7) with SMTP id OAA31166; Sat, 31 Oct 1998 14:42:20 -0600 From: scj2@gs4.revnet.com Message-Id: <199810312042.OAA31166@revnet4.revnet.com> To: scj2@gs4.revnet.com Subject: ISM Corp has acquired 4.7 mill to begin production Stock up 100 percent Date: Sat, 31 Oct 1998 14:47:09 -0600 Originator: scj2@gs4.revnet.com X-Mailer: GroupMaster X-Mailer-Version: 1.5 X-GroupMasterUser: Revnet Express X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please open the following message in your web browser http://gs4.revnet.com/GM/MSGVIEW/MSOHNOPA.HTML ____________________________________________________________ International Shoe Manufacturing Corp Update: International Shoe Manufacturing Corp. (Ticker-ISHO) has acquired the final-stage financing to begin full-scale production at its plants in India. The $4.75 million is being used to purchase the final equipment needed to begin production at the company’s existing plant in India. With equipment in place, the company projects net profits of over $25 million a year within two years. The company stated that the financing will be followed up by a $9 million dollar IPO in India, anticipated for March 1999. The IPO will be handled by underwriters in India, and will leave ISM with control of its wholly owned subsidiary in India. The proceeds of the IPO will pay off the $4.75 million dollar financing. The balance will be used for the acquisition of additional shoe manufacturing. ISHO is in the business of manufacturing athletic footwear for the world’s leading shoe companies. It owns a 23,000-square-foot plant located in the protected “free trade zone” in Noida, just outside of New Delhi, India, where skilled labor is plentiful and very inexpensive. The Indian government recently developed new economic policy to attract foreign investment that is export-oriented, and could employ large numbers of people. ISM is the only athletic shoe manufacturer in India directed toward the international market. It currently has contracts with Adidas and The Pentland Group. These two companies have agreed to purchase all the shoes ISM can manufacture. The athletic shoe industry is estimated at $14.25 billion a year. The world’s leading shoe companies such as Adidas, Nike, and Reebok do not manufacture shoes. They are design and marketing organizations that spend hundreds of millions of dollars a year getting their products sold. They then rely on others to manufacture to their specifications. Almost, if not all athletic shoe manufacturers are privately owned, benefiting from the hundreds of millions of dollars spent on advertising by the name-brand companies. The result is an open purchase order where such manufacturers literally can sell every pair of shoes they can produce. A business like this lends itself to being privately held due to the large cash flow allowing for internal financing. International Shoe Manufacturing Corp. is the only company known to exist that offers a public investor the opportunity to own a share of this highly lucrative business in a pure investment play. For inquiries please contact the office of the director of investor relations toll free at: 877-ISM-CORP (877-476-2677) or send your e-mail request to nsi@smallcapjournal.com Your request will be handled immediately. Or write to ISM Corp at P.O. Box 520310 Longwood, Florida 32752 Please visit ISM’s web site at www.ismcorp.net Safe Harbor for Forward-Looking Statements: Except for historical information contained herein, the statements in this press release are forward-looking statements that are made pursuant to the safe harbor provisions of the Private Securities Reform Act of 1995. Forward-looking statements involve known and unknown risks and uncertainties which may cause the company’s actual results in the future periods to differ materially from forecasted results. These risks and uncertainties include, among other things, product price volatility, product demand, market competition, risk inherent in the company’s domestic and international operations, imprecision in estimating product reserves and the company’s ability to replace and expand its holdings. ____________________________________________________________ Unsubscribe or access your membership settings at: http://gs4.revnet.com/GMG/ctrlpanel/0/79