From rem-conf Mon Dec 01 09:09:32 1997 From rem-conf-request@es.net Mon Dec 01 09:09:32 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xcYyp-0006ee-00; Mon, 1 Dec 1997 08:45:55 -0800 Message-Id: <199712011645.LAA18023@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: rem-conf@es.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-avt-profile-new-02.txt,.ps Date: Mon, 01 Dec 1997 11:45:45 -0500 Sender: cclark@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A Revised 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 : RTP Profile for Audio and Video Conferences with Minimal Control Author(s) : H. Schulzrinne Filename : draft-ietf-avt-profile-new-02.txt,.ps Pages : 30 Date : 26-Nov-97 This memo describes a profile called ''RTP/AVP'' for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. The document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. However, the encoding definitions are independent of the particular transport mechanism used. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-profile-new-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-profile-new-02.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: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-profile-new-02.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971126153231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-new-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-new-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971126153231.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Dec 01 12:55:36 1997 From rem-conf-request@es.net Mon Dec 01 12:55:36 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xcchM-0001BD-00; Mon, 1 Dec 1997 12:44:08 -0800 Message-ID: <34832141.3EE3E46A@dnrc.bell-labs.com> Date: Mon, 01 Dec 1997 15:42:41 -0500 From: "Jonathan D. Rosenberg" Reply-To: jdrosen@dnrc.bell-labs.com X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: New I-D's Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list avt'ers, I haven't seen the announcement yet, so I thought I would advise everyone of a few new Internet Drafts: http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-avt-byerecon-00.ps or http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-avt-byerecon-00.txt discuss a BYE reconsideration algorithm that avoids BYE floods. It also summarizes the reverse reconsideration algorithm presented in Munich. http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-avt-fec-01.txt is an updated version of the FEC payload document, based largely on comments I received from people. Thanks, Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 PHONE: (908) 949-6418 Rm. 4C-526 FAX: (908) 834-5379 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Wed Dec 03 07:21:40 1997 From rem-conf-request@es.net Wed Dec 03 07:21:40 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xdGJ8-0006Ff-00; Wed, 3 Dec 1997 07:01:46 -0800 Message-Id: <199712031501.KAA19990@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: rem-conf@es.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-avt-info-repair-01.txt Date: Wed, 03 Dec 1997 10:01:37 -0500 Sender: cclark@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 : Options for Repair of Streaming Media Author(s) : C. Perkins, O. Hodson Filename : draft-ietf-avt-info-repair-01.txt Pages : 9 Date : 02-Dec-97 This document summarizes a range of possible techniques for the repair of continuous media streams subject to packet loss. The techniques discussed include redundant transmission, retransmission, interleaving and forward error correction. The range of applicability of these techniques is noted, together with the protocol requirements and dependencies. 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-info-repair-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-info-repair-01.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: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-info-repair-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971202102136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-info-repair-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-info-repair-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971202102136.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Dec 03 12:17:47 1997 From rem-conf-request@es.net Wed Dec 03 12:17:46 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xdL5u-00010q-00; Wed, 3 Dec 1997 12:08:26 -0800 Date: Wed, 03 Dec 1997 21:11:32 +0100 From: csmr98@DSI.UNIFI.IT Subject: Conf. Prog.: CSMR98+REF98: Maintenance & Reengineering in Florence To: rem-conf@es.net Message-id: <9712032011.AA22232@aguirre.dsi.UNIFI.IT> MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: QUOTED-PRINTABLE X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear colleague: Here is the prliminary program of this combined conference: 2nd EUROMICRO WORKING CONFERENCE on SOFTWARE MAINTENANCE AND REENGINE= ERING=20 and 6th REENGINEERING FORUM that will be help in Florence, Italy, 8-11 March 1998. Since their timeline for producing the preliminary program is=20 different we start with the diffusion of preliminary program without the papers of REF. =20 Please accept our apologies if you receive multiple copies of this ca= ll. Please post forward to all your interested colleagues. Please visit our www page: http://www.dsi.unifi.it/~nesi/csmr98.html thank you=20 ---------------------------------------------------------------------= - Preliminary Program 2nd EUROMICRO CONFERENCE on SOFTWARE=20 MAINTENANCE AND REENGINEERING and 6th REENGINEERING FORUM March 8-11, 1998, Florence, Italy Sponsored by: Euromicro, REF, IEEE (TSE) In cooperation with: CESVIT Patroned by: Univ.Firenze, AIIA, DSI, AICA, TABOO,... Please visit our www site:=20 http://www.dsi.unifi.it/~nesi/csmr98.html contact: csmr98@aguirre.ing.unifi.it Proceeding printed by: IEEE Press for the conference time. ------------Preliminary Program =20 Keynote Speakers:=20 * Continuous Engineering for Industrial Scale Software Systems. Prof. H. Weber, Fraunhofer-Institut fuer Software- und Systemtech= nik ISST,=20 Germany =20 =20 Session: Tool Architecture * Architecture and Functions of a Commercial Software Reengineering Workbench (H.M. Sneed D)=20 * Control Flow Normalization for COBOL/CICS Legacy System (Chris= =20 Verhoef, Alex Sellink, Mark van cen Brand - University of=20 Amsterdam - NL)=20 * Other REF papers will be inserted=20 Session: Data Reengineering * A Generic Approach for Data Reverse Engineering Taking into=20 Acoount Application Domain Knoledge (Sonia Ayachi Ghannouchi - ENSI (National School for Computer Studies) - Tunisie)=20 * A strategy for reducing the effort for database schema=20 maintenance (Donatella Castelli - Istituto di Elaborazione dell'Informazione - I)=20 * Other REF papers will be inserted=20 Session: Business Information Technology * An Organizational Framework for Mass-Customized Business Application (Petra Ludwig, Thomas Kaufmann, Harald Liessmann -= =20 Bavarian Research Center for Knowledge-Based Systems - D)=20 * Other REF papers will be inserted=20 Session: Year 2000 Problem * Variable Classification Technique for Software Maintenance and= =20 Application to The Year 2000 Problem (Keiko Kawabe, Akihiko=20 Matsuo, Sanya Uehara - Fujitsu Laboratories Ltd. JP - Akira=20 Ogawa - Fujitsu Ltd. - JP)=20 * Other REF papers will be inserted=20 Session: Program Understanding * On Constructing a Tool to Verify Programs for Processors Built= =20 in Machines (Tomoya Ohta, Norihiro Matsumara, Yukihiro Itoh-= =20 Shizuoka university - JP)=20 * Other REF papers will be inserted=20 Session: Reuse and Object Oriented Techniques * A Dependence-Based Representation for Concurrent Object-Oriented Software Maintenance (Jianjun Zhao - Fukouka Institute of=20 Technology - Jingde Cheng, Kazuo Ushijima -JP)=20 * OOA Metrics for the Unified Modeling Language (Michele Marchesi= =20 - Universita' di Cagliari - I)=20 * Protection Reconfiguration for Reusable Software (Christian=20 Damsgaarg Jensen - Universite Joseph Fourier - F)=20 Session: System Assessment * Towards Mature Measurement Program (Frank Niessink, Hans van=20 Vliet - Universiteit Amsterdam NL)=20 * A Tool for Process and Product Assessment of C++ Applications= =20 (F.Fioravanti, P.Nesi, S. Perlini - Univ Florence - I)=20 * Software Testability Measurement derived from Data Flow Analysis= =20 (Pu-Lin Yeh, Jin-Cherng Lin- Tatung Institute of Technology -= =20 Taiwan)=20 Session: Software Architecture * Assessing Architectural Complexity (Rick Kazman - Carnege Mellon= =20 University - USA - Marcus Burth - University of Mannheim - D)= =20 * Architecture recovery for Software Evolution (Juan C. Duenas,= =20 William Lopes, Juan A. de la Puente - Universidad Politecnica= =20 de Madrid - E)=20 * Other REF papers will be inserted=20 Session: Requirements and Specification Evolution * Requirements Evolution in the Midst of Environmental Change A= =20 Managed Approach (Wing Lam - University of Hertfordshire - UK)= =20 * A Method for Assessing Legacy Systems for Evolution (Jane Ransom, Ian Sommerville, Ian Warren - Lancaster University - UK)=20 * System Specification Reengineering Using the SpecView Tool=20 (Tereza G. Kirner, Rogeria C. Gratao - Federal University of Sao Carlos - BR)=20 * A Tool Supporting the Re-Design of Legacy Applications (Katja Cremer - RWTH Aachen- D)=20 Session: Maintenance Effort * Modeling Maintenance Effort by means of Dynamic System=20 (F.Calzolari, G. Antoniol, P. Tonella - IRST - I)=20 * Improving Defect Removal Effectiveness for Software Development= =20 (Hareton K. N. Leung - The Honk Kong Polytechnic University)=20 * The Extract-Transform-Rewrite Cycle A Step Towards metaCARE=20 (Bernt Kullbach - University of Koblenz - D)=20 Session: Logic Programming, Telecommunication * A Metric Suite for Concurrent Logic Programs (Jianjun Zhao -=20 Fukouka Institute of Technology - Jingde Cheng, Kazuo Ushijima -= =20 Kyushu University - JP)=20 * Identifying Fault Prone Modules An Empirical Study in=20 Telecommunication System (Sung-Back Hong, Kapsu Kim - ISDN =20 Call Processing Section, ETRI - KR)=20 Papers in OPEN FORUM Sections * DBFW A Simple DataBase FrameWork for the Evaluation and=20 Maintenance of Automated Theorem Prover Data (Peter Jakobi,=20 Andreas Wolf - Technische Universitat Munchen D)=20 * Reengineering of Distributed Systems Using Formal Methods=20 (Stephan Kleuker - University of Oldenburg D)=20 * Metrics-based Evaluation of Object-Oriented Software=20 development Methods (Reiner R. Dumke - Erik Foltin -=20 University of Magdeburg - D)=20 * Supporting Software evolution using Zones (Cathy Waite, Ray=20 Welland, Malcom Atkinson - University of Glasgow - UK)=20 * RENAISSANCE, A Method To Migrate From Legacy To Immortal intecs Sistemi S.p.A. - I)=20 * Visualization of Differences between Versions of=20 Object-Oriented Sofware (Jochen Seemann, Jurgen Wolff von=20 Gudenberg - Wurzburg University - D)=20 * Amber Metrics for the Testing & Maintenance of Object-Oriented= =20 Designs (Jill Doake, Ishbel Duncan - University - UK)=20 * Tailoring the Process Model for Maintanance and Reengineering (Sara Stoecklin, Deidre Wiliams - Florida Agricoltural &=20 Mechanical University - Peter Stoecklin - PCSA Inc. - USA)=20 * Toward a systematic object-oriented transformation of a Merise= =20 analysis (Isabelle Borne, Annya Romanczuk, Frederique Stefani -= =20 Ecole des Mines de Nantes - F)=20 * Object Evolution through Model Evolution (Roland T.Mittermeier,= =20 Helfried Pirker, Dominik Rauner-reithmayer - Univeritat =20 Klagenfurt - A)=20 * A sound and Pratical Approach to the Re-Engineering of Time=20 Critical System (H.Zedan - H. Yang - De Montfort University - UK)= =20 * Reengineering a Computerized Numerical Control Towards=20 Object-Oriented (F. Butera, B. Fontanella, P. Nesi, M. Perfetti - ELEXA S.r.l. - I)=20 * Software Artifacts Reuse and Maintenance An organizational=20 Framework (Claudine Toffolon, Salem Dakhli - Paris-Dauphine=20 University - F)=20 =20 csmr98@aguirre.ing.unifi.it=20 Dip. Sistemi e Informatica, Universit=E0 degli Studi di Firenze=20 Via S. Marta, 3, 50139 Firenze, Italy=20 Tel: +39-55-4796523, Fax: +39-55-4796363=20 Home Page http://www.dsi.unifi.it/~nesi/csmr98.html=20 ---------------------------------------------------------------------= =20 =20 From rem-conf Wed Dec 03 14:08:21 1997 From rem-conf-request@es.net Wed Dec 03 14:08:21 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xdMnU-0002BO-00; Wed, 3 Dec 1997 13:57:32 -0800 Date: Wed, 3 Dec 1997 16:57:28 -0500 (EST) Message-Id: <199712032157.QAA02797@bmt.cs.columbia.edu> From: Jonathan Lennox To: rem-conf@es.net Subject: vic with Parallax card on HP/UX 9 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Does anyone have any experience getting vic to work with a Parallax framegrabber on an HP 700 running HP/UX 9? The binary at lbl doesn't recognize the presence of the card, and a copy of vic compiled from source, though it sucessfully detects the card's presence, pops up an error box reporting "vic: can't open parallax capture device" when I click on "Transmit". -- Jonathan Lennox lennox@cs.columbia.edu From rem-conf Wed Dec 03 22:47:31 1997 From rem-conf-request@es.net Wed Dec 03 22:47:30 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xdUzU-0004eo-00; Wed, 3 Dec 1997 22:42:28 -0800 Date: Thu, 4 Dec 1997 07:42:18 +0100 (MET) From: Christoph Fleck X-Sender: fleck@rncmm1 Reply-To: Multimedia Referenzzentrum To: Jonathan Lennox cc: rem-conf@es.net Subject: Re: vic with Parallax card on HP/UX 9 In-Reply-To: <199712032157.QAA02797@bmt.cs.columbia.edu> 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 Jonathan, > Does anyone have any experience getting vic to work with a Parallax > framegrabber on an HP 700 running HP/UX 9? It works on my site: HPUX10.2 HP725/100 (US-SE-HP 1997) Vic binary with HP-Parallax is aviable at: http://www.parallax.com/support/vic.html ftp://parallax.com/tech_support/scott/misc/vic If you play around with Videotool and vic (put the Vic-Overlay on the Videotool-Overlay, then iconify the Vic-Overlay) you can get picture in picture video (from differnt videoinputs). Ask for more assistance if needed. It is able to send 4CIF with nv & nvdct (only 1..2 fps ) for slides o.k., CIF with h.261 (5...8 fps). Good luck. Christoph Fleck ,------------------------------------------------------------------. | Referenzzentrum fuer multimediale Teledienste (MMRZ), TU Dresden | | Dr. Klaus Koehler, Christoph Fleck, Rainer Kranz | | e-mail: mmt-ref@tu-dresden.de Tel.: 0351 / 463 5653 | | WWW: http://www-mm.urz.tu-dresden.de (GERMANY) | `------------------------------------------------------------------' From rem-conf Wed Dec 03 23:25:26 1997 From rem-conf-request@es.net Wed Dec 03 23:25:25 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xdVbl-0005LJ-00; Wed, 3 Dec 1997 23:22:01 -0800 Date: Wed, 3 Dec 1997 23:20:56 -0800 (PST) From: Stephen Casner To: rem-conf@es.net Subject: AVT Meeting at December IETF In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list AVT Working Group: Here's the proposed agenda for the AVT meeting next week. If you requested a slot and I overlooked it, or if you have other comments, please let me know. Also please note the drafts associated with each topic. I had hoped we would have more discussion on the mailing list regarding dynamic payload type mapping for generic payload formats (a topic I mentioned in my initial message about this meeting), but I know some people were busy preparing I-Ds, etc. Please think about this problem and bring your good ideas to the meeting so we can have a productive discussion. Although this problem and potential solutions are not strictly tied to the proposals for QuickTime and ASF payload formats, those proposals have focussed attention on the problem. -- Steve Casner Audio/Video Transport WG A G E N D A Wednesday, December 10, 13:00-15:00 - Introduction and status [Casner] 5 - Status of RTP spec and Profile - Redundant Audio payload approved for Proposed Std draft-ietf-avt-rtp-redundancy-00.txt, .ps - IP/UDP/RTP header compression on hold in Last Call draft-ietf-avt-crtp-04.txt (revised) - Last call requested on MPEG2 payload update draft-ietf-avt-mpeg-new-02.txt - New drafts of RTP spec and Profile [Casner] 15 draft-ietf-avt-profile-new-02.txt, .ps - RTCP BYE reconsideration [Rosenberg] 10 draft-ietf-avt-byerecon-00.txt, .ps - Generic payload type mapping and fragmentation draft-ietf-avt-qt-rtp-00.txt draft-klemets-asf-rtp-00.txt - Proposals to set the stage 45 [Klemets, Schulzrinne, Casner, maybe others] - Discussion 45 Thursday, December 11, 9:00-11:30 - Revision of RTP MIB specification [Baugher] 15 draft-ietf-avt-rtp-mib-01.txt - New RTP payload format proposals - DMIF for MPEG4 [Balabanian] 20 - H.263+ payload format [Gardos and Wenger] 20 draft-ietf-avt-rtp-h263-video-00.txt - BT-656 video payload format [Tynan] 10 draft-tynan-rtp-bt656-00.txt - Revised JPEG video payload format [Fenner] 10 draft-ietf-avt-jpeg-new-00.txt, .ps - FEC payload format [Rosenberg] 10 draft-ietf-avt-fec-01.txt - Options for Repair of Streaming Media [Perkins] 10 draft-ietf-avt-info-repair-01.txt - New GSM formats [Petrack] 5 From rem-conf Thu Dec 04 05:16:28 1997 From rem-conf-request@es.net Thu Dec 04 05:16:27 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xday3-00078W-00; Thu, 4 Dec 1997 05:05:23 -0800 Message-ID: <3486AE55.D9F08B59@finetuning.com> Date: Thu, 04 Dec 1997 05:21:25 -0800 From: Lisa Rein Reply-To: lisarein@finetuning.com Organization: http://www.finetuning.com 425-803-0638or785-9272 X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Stephen Casner CC: rem-conf@es.net Subject: Re: AVT Meeting at December IETF References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list where exactly is this meeting located. I keep hearing about it but nothing regarding where it is! And I may be back east next week for another conference. thanks! Lisa Rein Stephen Casner wrote: > > AVT Working Group: > > Here's the proposed agenda for the AVT meeting next week. If you > requested a slot and I overlooked it, or if you have other comments, > please let me know. Also please note the drafts associated with each > topic. > > I had hoped we would have more discussion on the mailing list > regarding dynamic payload type mapping for generic payload formats (a > topic I mentioned in my initial message about this meeting), but I > know some people were busy preparing I-Ds, etc. Please think about > this problem and bring your good ideas to the meeting so we can have a > productive discussion. Although this problem and potential solutions > are not strictly tied to the proposals for QuickTime and ASF payload > formats, those proposals have focussed attention on the problem. > > -- Steve Casner > > Audio/Video Transport WG > > A G E N D A > > Wednesday, December 10, 13:00-15:00 > > - Introduction and status [Casner] 5 > > - Status of RTP spec and Profile > - Redundant Audio payload approved for Proposed Std > draft-ietf-avt-rtp-redundancy-00.txt, .ps > - IP/UDP/RTP header compression on hold in Last Call > draft-ietf-avt-crtp-04.txt (revised) > - Last call requested on MPEG2 payload update > draft-ietf-avt-mpeg-new-02.txt > > - New drafts of RTP spec and Profile [Casner] 15 > draft-ietf-avt-profile-new-02.txt, .ps > > - RTCP BYE reconsideration [Rosenberg] 10 > draft-ietf-avt-byerecon-00.txt, .ps > > - Generic payload type mapping and fragmentation > draft-ietf-avt-qt-rtp-00.txt > draft-klemets-asf-rtp-00.txt > > - Proposals to set the stage 45 > [Klemets, Schulzrinne, Casner, maybe others] > > - Discussion 45 > > Thursday, December 11, 9:00-11:30 > > - Revision of RTP MIB specification [Baugher] 15 > draft-ietf-avt-rtp-mib-01.txt > > - New RTP payload format proposals > > - DMIF for MPEG4 [Balabanian] 20 > > - H.263+ payload format [Gardos and Wenger] 20 > draft-ietf-avt-rtp-h263-video-00.txt > > - BT-656 video payload format [Tynan] 10 > draft-tynan-rtp-bt656-00.txt > > - Revised JPEG video payload format [Fenner] 10 > draft-ietf-avt-jpeg-new-00.txt, .ps > > - FEC payload format [Rosenberg] 10 > draft-ietf-avt-fec-01.txt > > - Options for Repair of Streaming Media [Perkins] 10 > draft-ietf-avt-info-repair-01.txt > > - New GSM formats [Petrack] 5 From rem-conf Thu Dec 04 06:24:37 1997 From rem-conf-request@es.net Thu Dec 04 06:24:36 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xdc7u-0000JH-00; Thu, 4 Dec 1997 06:19:38 -0800 Message-Id: <199712041419.JAA15070@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: rem-conf@es.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-avt-fec-01.txt Date: Thu, 04 Dec 1997 09:19:32 -0500 Sender: cclark@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 : An RTP Payload Format for Generic Forward Error Correction Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-fec-01.txt Pages : 12 Date : 03-Dec-97 This document specifies a payload format for generic forward error correction of media encapsulated in RTP. It is engineered for FEC algorithms based on the exclusive or (parity) operation, although it can be used with other techniques. The payload format allows end sys- tems to transmit using arbitrary block lengths and parity schemes. It also allows for the recovery of both the payload and critical RTP header fields. It is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions. 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-fec-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-fec-01.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: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-fec-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971203150527.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-fec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-fec-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971203150527.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Dec 04 06:42:29 1997 From rem-conf-request@es.net Thu Dec 04 06:42:29 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xdcR7-0000q7-00; Thu, 4 Dec 1997 06:39:29 -0800 Message-Id: <199712041439.JAA15680@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: rem-conf@es.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-avt-byerecon-00.txt,.ps Date: Thu, 04 Dec 1997 09:39:21 -0500 Sender: cclark@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 : New Results in RTP Scalability Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-byerecon-00.txt,.ps Pages : 10 Date : 03-Dec-97 Recently, a number of problems related to RTP scalability to large multicast groups have been identified. The main problem, congestion of RTCP packets due to near-simultaneous joins, has been resolved in previous work. In this document, we present some additional problems and describe the solutions. In particular, we discuss the problem of BYE floods and premature timeouts. To resolve the BYE flood problem, we propose a BYE reconsideration mechanism. To help alleviate prema- ture timeouts, we propose a reverse timer reconsideration algorithm. Both algorithms are simple, and require minimal state and computa- tion. 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-byerecon-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-byerecon-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: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-byerecon-00.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971203152006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-byerecon-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-byerecon-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971203152006.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Dec 04 14:43:47 1997 From rem-conf-request@es.net Thu Dec 04 14:43:46 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xdjnZ-0005ev-00; Thu, 4 Dec 1997 14:31:09 -0800 Date: Thu, 4 Dec 1997 17:31:06 -0500 (EST) From: Chris Heermann X-Sender: heermann@east To: rem-conf@es.net Subject: Friday Dec 5: Rebroadcasts: Steve Deering Seminar on IPv6 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list USC ISI East will multicast Steve Deering's 2 hour seminar updating IPv6 and describing advances and open areas at the following times for everyone's enjoyment. 0800 EDT / 1300 GMT 1200 EDT / 1700 GMT This seminar was originally presented at the National Science Foundation on Sept 24, at a workshop of the Testbed Routers for Advanced Internet Laboratories (TRAIL) project. HTTP viewgraphs accompany it, with details to be found in the SDR advertisement. From rem-conf Fri Dec 05 03:48:41 1997 From rem-conf-request@es.net Fri Dec 05 03:48:40 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xdw3B-0002TK-00; Fri, 5 Dec 1997 03:36:05 -0800 Date: Fri, 5 Dec 1997 03:34:36 -0800 () From: Stephen Casner To: rem-conf@es.net Subject: Revised RTP spec and profile drafts Message-ID: X-X-Sender: casner@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the Audio/Video Transport working group: In the process of advancing the RTP spec (RFC 1889) and the companion A/V Profile (RFC 1890) from Proposed Standard to Draft Standard status, revisions in the form of Internet Draft documents are being prepared for both. The updated Profile has been posted to the I-D repositories: draft-ietf-avt-profile-new-02.ps draft-ietf-avt-profile-new-02.txt The updated RTP spec has not yet been posted as an I-D, but is available from: ftp://hydra.precept.com/pub/rtp/draft-ietf-avt-rtp-new-00.ps ftp://hydra.precept.com/pub/rtp/draft-ietf-avt-rtp-new-00.txt It is recommended that you get the .ps version because it has change bars next to the revised portions. There are also sections in the introduction listing the changes that have been made and the open issues for changes not yet made. Some of these changes and issues will be discussed at the AVT meeting next week Comments on these draft updates are highly encouraged. -- Steve From rem-conf Fri Dec 05 07:19:24 1997 From rem-conf-request@es.net Fri Dec 05 07:19:24 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xdzOs-00041A-00; Fri, 5 Dec 1997 07:10:42 -0800 Message-Id: <199712051510.KAA13668@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: rem-conf@es.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-avt-crtp-04.txt Date: Fri, 05 Dec 1997 10:10:23 -0500 Sender: cclark@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 : Compressing IP/UDP/RTP Headers for Low-Speed Serial Links Author(s) : V. Jacobson, S. Casner Filename : draft-ietf-avt-crtp-04.txt Pages : 22 Date : 04-Dec-97 This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. In many cases, all three headers can be compressed to 2-4 bytes. Comments are solicited and should be addressed to the working group mailing list rem-conf@es.net and/or the author(s). 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-crtp-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-crtp-04.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: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-crtp-04.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971204095252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-crtp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-crtp-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204095253.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Dec 05 20:56:45 1997 From rem-conf-request@es.net Fri Dec 05 20:56:45 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xeC8O-0001ux-00; Fri, 5 Dec 1997 20:46:32 -0800 From: Metzcy Message-ID: <9e687482.3488d78d@aol.com> Date: Fri, 5 Dec 1997 23:41:44 EST To: rem-conf@es.net Mime-Version: 1.0 Subject: Fwd: Friday Dec 5: Rebroadcasts: Steve Deering Seminar on IPv6 Content-type: multipart/mixed; boundary="part0_881383307_boundary" Organization: AOL (http://www.aol.com) X-Mailer: Inet_Mail_Out (IMOv11) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --part0_881383307_boundary Content-ID: <0_881383307@inet_out.mail.aol.com.1> Content-type: text/plain; charset=US-ASCII I don't have sdr nearby. Might there be a pointer where I could obtain the viewgraphs of Steve Deering's talk on IPv6?? Thanks.. --part0_881383307_boundary Content-ID: <0_881383307@inet_out.mail.aol.com.2> Content-type: message/rfc822 Content-transfer-encoding: 7bit Content-disposition: inline Return-Path: Received: from relay14.mail.aol.com (relay14.mail.aol.com [172.31.109.14]) by air16.mail.aol.com (v36.0) with SMTP; Fri, 05 Dec 1997 02:47:11 -0500 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by relay14.mail.aol.com (8.8.5/8.8.5/AOL-4.0.0) with SMTP id RAA18656; Thu, 4 Dec 1997 17:53:23 -0500 (EST) Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xdjnZ-0005ev-00; Thu, 4 Dec 1997 14:31:09 -0800 Date: Thu, 4 Dec 1997 17:31:06 -0500 (EST) From: Chris Heermann X-Sender: heermann@east To: rem-conf@es.net Subject: Friday Dec 5: Rebroadcasts: Steve Deering Seminar on IPv6 Message-ID: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit USC ISI East will multicast Steve Deering's 2 hour seminar updating IPv6 and describing advances and open areas at the following times for everyone's enjoyment. 0800 EDT / 1300 GMT 1200 EDT / 1700 GMT This seminar was originally presented at the National Science Foundation on Sept 24, at a workshop of the Testbed Routers for Advanced Internet Laboratories (TRAIL) project. HTTP viewgraphs accompany it, with details to be found in the SDR advertisement. --part0_881383307_boundary-- From rem-conf Sat Dec 06 14:58:25 1997 From rem-conf-request@es.net Sat Dec 06 14:58:24 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xeT0p-0006np-00; Sat, 6 Dec 1997 14:47:51 -0800 From: <3Lg28YO0n@upnor1th.com> DATE: 05 Dec 97 5:42:29 PM Message-ID: TO: lasers@44optic.com SUBJECT: Lasers/Optics/Optical Tables - Save! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MWK INDUSTRIES SALE! JUST A QUICK LETTER TO SHOW YOU SOME LASERS- OPTICS AND OPTICAL TABLES SURPLUS THAT WE JUST RECEIVED. ITEM TRIMMU12 14 WATT ARGON LASER MADE FOR HEART SURGERY, TRIMEDYNE MODEL 900 TEMOO, POLORIZED,220VAC INPUT , WATER COOLED , FIBER LAUNCH, ALL ON ROLLAROUND CART EXCELENT FOR LAB USE, THE POWER WAS MEASURED AT 13 TO 14 WATTS. PRICE $9500 12 MONTH WARRANTEE. ITEM: COHERENT ARTICULATING ARM FROM A MODEL 451 CO2 MEDICAL LASER. ECCELLENT COND. $200 ITEM CO220A: CO2 LASER MADE BY PFIZER ,1990, FOR SURGERY, TATTOO REMOVAL ECT. 20 WATT OUTPUT , TESTED AND IN EXC. COND. 110 VAC INPUT, COST $40,000 NEW OUR PRICE 4,900. MODEL 20-C ITEM:PDA-1U1 SPECTRA PHYSICS QUANTRA RAY PULSED DYE LASER , GOOD FOR SPARE PARTS MODEL PDA-1 $500 ITEM NEWU1 NEWPORT OPTICAL TABLE 16" BY 36" 4" THICK, 1 " HOLE SPACING, COMES WITH A RUBBER ISOLATED TABLE STAND, NOT AIR SUPPORTED, $750 ITEM: HEPSN1 HELIUM NEON POWER SUPPLY KIT OPERATES UP TO A 15 mW LASER, INCLUDES ALL COMPONENTS AND PRINTED CIRCUIT BOARD, ALL YOU HAVE TO DO IS STUFF AND SOLDER THE CIRCUIT BOARD . 4" BY 3" BY 3", PRICE $75 ITEM HENEU12 1 TO 1.5 MW HE-NE LASER 632.8 nM INCLUDES 12VDC INPUT POWER SUPPLY ALL IN A PLASTIC HOUSING 6.25 IN. BY 1.375IN BY 2.25 IN. TEMOO,RANDOM POL. ,1.7 MR DIVERGENCE. 12 MONTH WARRANTEE , PRICE $45 ITEM MELU12 1 TO 2 mW HE-NE LASER 632.8 NM , PULLS FROM MEDICAL EQUIPMENT .EACH UNIT INCLUDES HE-NE HEAD AND POWER SUPPLY[110VAC INPUT]. ALL YOU NEED TO PROVIDE IS A POWER CORD AND A FUSE TO MAKE THE UNIT OPERATIONAL. THE BEAM IS TEM00, POLORIZED WE WILL COVER EACH UNIT WITH A 12 MONTH UNLIMITED HOUR WARRANTEE, EXCELLENT FOR FOR LAB OR HOME USE. NEW THESE COST APPROX. $350 OUR PRICE $85. DIMENSIONS 9.75 BY 1.25 INCHES, P.S. 4.25 BY 3.25BY 1.25 INCHES. ITEM RAMCNS1: RAMAN CELL OPTICS 308 nm AR/AR 4600 A 0=0 DEGREES 1000 MM FL. 2" DIA. NEW. ORIGINAL PRICE $520 OUR PRICE $175 ITEM TFPOLNS1: POLARIZERS , THIN FILM FOR 532 nm , NEW, ORIGINAL COST $590 EACH OUR PRICE $200 EACH 10 MM DIA. ITEM CO2OCNS1: CO2 HIGH REFECTOR AND OUTPUT COUPLER 10.5 MM DIA, OC =79%R NEW. $200 A SET. ITEM 25MNS1: DIELECTRIC BROADBAND MIRRORS 450 TO 700NM , NEW WITH PLASTIC PROTECTIVE COATINGS , 2 SIZES 25 MM SQ. AND 50 MM SQ. RECOMENDED FOR HIGHER POWER LASERS. 25MM SIZE ITEM 25MNS1 $20 50MM SIZE ITEM 50MNS1 $25 ITEM # BSDNS1: 50/50 DIELECTRIC COATED PLATE BEAM SPLITTER 630 TO 660 NM COMES IN A TRIANGLE SHAPE EACH SIDE APPROX. 1" PRICE $20 ITEM # 45NS1 45 DEGREE RED REFLECTOR , PASSES 488 TO 532NM , CAN BE USED TO COMBINE RED AND GREEN/BLUE LASERS TO CREATE A WHITE LIGHT LASER. 1" SQ. PRICE $15 ITEM# PCINS1 PLANO/CONVEX LENS COATED FOR YAG 1064NM , AR COATED, 10MM DIA. NEW, ORIG. COST $250 OUR PRICE $100 ITEM# INFILTER : INTERFERENCE FILTERS USED FOR PASSING A PARTICULAR SPECTRAL LINE , 11.8 MM DIA. CAREFULLY REMOVED FROM MEDICAL EQUIPMENT AND WRAPPED IN LENSE PAPER. THE FOLLOWING WAVE LENGTHS ARE AVAILABLE. 523.5, 547.4 , 572.1, 512.9, 550.6, 488, 505.7 nm price $20 each. FOR A COMPLETE LINE OF NEW AND USED LASERS - OPTICS -ELECTRO OPTICS- LASER SHOWS ORDER A COMPLETE CATALOG AT MWKINDUSTRIES.COM TO: ORDER GO TO OUR WEB SITE MWKINDUSTRIES.COM {SECURE ORDERING SITE} QUESTIONS OR REMOVAL FROM MAILING LIST EMAIL: MWK@WORLDNET.ATT.NET MWK INDUSTRIES 1269 POMONA RD CORONA CA 91720 PHONE 909-278-0563 FAX 909-278-4887 From rem-conf Sun Dec 07 17:20:17 1997 From rem-conf-request@es.net Sun Dec 07 17:20:16 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xerfv-0004vU-00; Sun, 7 Dec 1997 17:07:55 -0800 From: qq1199 To: Message-Id: <19943672.886214@relay.comanche.denmark.eu> Tuesday, December 9th, 1997 Reply-To: qq1199@ix.netcom.com Date: Sun, 7 Dec 1997 17:07:54 -0800 Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Authenticated sender is Subject: 12/07 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 8am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From rem-conf Mon Dec 08 15:34:15 1997 From rem-conf-request@es.net Mon Dec 08 15:34:14 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xfCVV-0001n8-00; Mon, 8 Dec 1997 15:22:33 -0800 Date: Mon, 08 Dec 97 15:20:00 PST From: Gim L Deisher Message-ID: To: itu-adv-video@ferrari.iterated.com, rem-conf@es.net cc: Gim_L_Deisher@ccm.jf.intel.com, Chad_Zhu@mail.intel.com, Donald_Newell@mail.intel.com, Christian_Maciocco@mail.intel.com, Thomas_R_Gardos@ccm.jf.intel.com, stewe@cs.tu-berlin.de, jo@cs.tu-berlin.de, cabo@tzi.org, lscline@ideal.jf.intel.com Subject: Re: H.263+ RTP Packetization X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >To ITU-T Q.15/SG16 and IETF AVT Experts, > >Attached is the plain-text version of some comments >I have written regarding the drafted RTP payload >packetization format specification for H.263+. > >I understand that this topic will be discussed at >the IETF meeting on Dec 10&11 as well as at the ITU-T >Q.15/16 meeting Dec 2-5. ..deleted >I first wish to say that I am very pleased to see that the work on >this topic is progressing and that it in fact appears to be reaching >a pretty stable specification. However, I would like to express a >few (mostly minor) concerns. Although the work toward the >specification of the packetization is being conducted primarily in >the IETF, the ITU-T video coding experts would also presumably be >interested in these remarks as well. Please note that none of the >changes that I request below would have any effect of invalidating a >packetization process or a packetized bitstream designed according to >the existing draft [Oops - that's not true about item 2d]. > >1) The introduction (section 1) should mention Reference Picture > Selection along with Slices and ISD mode as a key aspect of > H.263+ affecting packet-network transport use. > Agree. >2) The specified format seems a bit heavy on the amount of overhead > recommended or required. Specifically: > > a) It *requires* (Sec. 4.2, first sentence) a copy of the entire > picture header to be attached to every packet that starts with > a GOB or slice start code. Although I think it is a *great* > idea to allow such extra picture headers to be attached, I > strongly suggest changing the text to *allow* and perhaps to > *encourage*, but not to require them. The extra picture > headers can be very repetitive and unnecessary in many > circumstances, and can result in a great deal of extra data > being sent. If we allow this, we should describe the ramifications in the document. Requiring the picture header to be always included provides better resiliency towards packet losses. If a picture header is not included in any packet that begins with a GOB/slice header, all packets besides the first packet in a frame would be treated as follow-on packets. The receiver would need to toss any incomplete frame in which the packet containing its picture header is lost. Furthermore, if any packet other than the first one in a frame is lost, the receiver will need to also parse for the GBSC/SSC in order to recover the partial frame, which is additional work. > b) It strongly recommends a header and a separate packet for every > GOB. But is it a bad idea, for example, to put two GOBs in > each packet and only have a header on the first of each two > (cutting the overhead in half)? I think the wording on this > could be softened a little bit (although the present wording > does allow freedom for implementers as I read it). We are not recommending that a separate packet is used for every GOB. When using GOB headers instead of slices, if more than one GOB is contained in a packet, the GOB header could be eliminated in the second GOB without affecting resilience to packet loss. This should be better described in the document. > c) It recommends a complete picture header (UFEP = '001') on every > picture. In some circumstances, this may be unnecessary since > the OPPTYPE and its accompanying data may be the same for many, > many pictures in a row and since GFID will let the decoder at > least know when it changes (and since a complete picture header > will appear periodically anyway). I think the wording on this > could be softened a little bit (although the present wording > does allow freedom for implementers as I read it). The receiver cannot assume that the OPPTYPE never changes. If UFEP='000' is allowed, the receiver will need to wait for a complete header with UFEP='001' if picture header information has been lost, or if joining a session in progress. GFID does not help in situations where more than one consecutive picture header may be lost. > d) When sending a redundant copy of a picture header, the first > six bits ('100000') are always the same, and are therefore > unnecessary. I suggest not sending them. I suppose the > motivation is ease of byte-oriented processing, but it doesn't > seem like that much of a burden to always shift the header by > six bits. We favor trading in the 6 bits for ease of processing. >3) The description of the TID and Trun fields is clearly inadequate > (Sec. 4). Their use is entirely undefined, and the reference > given as a citation (draft 20 of H.263+) will be of little or no > help to the reader trying to figure them out. (Also, I suspect > that TID and Trun will sometimes be present in INTRA pictures, > although no INTRA picture will use the RPS mode of H.263+.) TID and Trun are parameters used only for VRC. A detailed desription of the VRC and its related parameters should be made available in a separate document which can be referenced here. >4) It may be useful to allow redundant picture headers to be attached > to packets already containing picture headers, and to allow the > redundant picture header attached to packets that begin with a GSC > or SSC to be altered in one key way. If the picture header in the > H.263+ payload bitstream itself is an abbreviated picture header > (UFEP = '000'), then it would be useful to allow the packetization > process to construct and attach a redundant complete picture header > (rather than attaching a copy of the abbreviated picture header). > In this way, the error robustness of the system can be enhanced > without increasing the bit rate of the payload or adding knowledge > of the packetization process to the encoder which is generating the > payload bitstream. Not sure that we understand the scenario that you are describing. If you are talking about hardware coders with which you cannot force to set UFEP='001', and having a payload handler replace the picture header with a complete one, that is an implementation detail which is possible now. If you are talking about including a complete picture header for the first packet in a frame, where an incomplete picture header is part of the payload data, that does increase the bit rate of the payload. In this case, it is just as effective for the encoder to set UFEP='001'. >5) The draft as I have it appears not to be dated. Dating the > document would be helpful to establish when the draft has become > obsolete or which of two versions is newer. Agree. >Again, however, I wish to say that my overarching sentiment is that >I am pleased with the progress of work on this topic. ----------------------------------------------------------------------- These details will probably be discussed further during the AVT meeting. Thanks for the comments. Linda Cline Gim Deisher From rem-conf Mon Dec 08 18:45:58 1997 From rem-conf-request@es.net Mon Dec 08 18:45:58 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xfFU0-00037G-00; Mon, 8 Dec 1997 18:33:12 -0800 Date: Mon, 8 Dec 1997 21:20:43 -0500 From: garys@python.pictel.com (Gary Sullivan) Message-Id: <9712090220.AA01303@python.pictel.com> To: Gim_L_Deisher@ccm.jf.intel.com, itu-adv-video@ferrari.iterated.com, rem-conf@es.net Subject: Re: H.263+ RTP Packetization Cc: Chad_Zhu@mail.intel.com, Christian_Maciocco@mail.intel.com, Donald_Newell@mail.intel.com, Thomas_R_Gardos@ccm.jf.intel.com, cabo@tzi.org, jo@cs.tu-berlin.de, lscline@ideal.jf.intel.com, stewe@cs.tu-berlin.de, webber@world.std.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To Gim Deisher et al, Thanks for the reply. I have responded below. Again however, I want to say that I basically agree with the drafted scheme. This discussion is at a pretty low level of detail, and it would probably be better taken off line. -Gary Sullivan +> ------------------------------------------------------------ +> From Gim_L_Deisher@ccm.jf.intel.com Mon Dec 8 18:42:39 1997 +> Date: Mon, 08 Dec 1997 15:20:00 -0800 (PST) +> From: Gim L Deisher +> Subject: Re: H.263+ RTP Packetization +> To: itu-adv-video@ferrari.iterated.com, rem-conf@es.net +> Cc: Gim_L_Deisher@ccm.jf.intel.com, Chad_Zhu@mail.intel.com, +> Donald_Newell@mail.intel.com, Christian_Maciocco@mail.intel.com, +> Thomas_R_Gardos@ccm.jf.intel.com, stewe@cs.tu-berlin.de, +> jo@cs.tu-berlin.de, cabo@tzi.org, lscline@ideal.jf.intel.com +> +> >To ITU-T Q.15/SG16 and IETF AVT Experts, +> > +> >Attached is the plain-text version of some comments +> >I have written regarding the drafted RTP payload +> >packetization format specification for H.263+. +> > +> >I understand that this topic will be discussed at +> >the IETF meeting on Dec 10&11 as well as at the ITU-T +> >Q.15/16 meeting Dec 2-5. +> +> ..deleted +> +> >I first wish to say that I am very pleased to see that the work on +> >this topic is progressing and that it in fact appears to be reaching +> >a pretty stable specification. However, I would like to express a +> >few (mostly minor) concerns. Although the work toward the +> >specification of the packetization is being conducted primarily in +> >the IETF, the ITU-T video coding experts would also presumably be +> >interested in these remarks as well. Please note that none of the +> >changes that I request below would have any effect of invalidating a +> >packetization process or a packetized bitstream designed according to +> >the existing draft [Oops - that's not true about item 2d]. +> > +> >1) The introduction (section 1) should mention Reference Picture +> > Selection along with Slices and ISD mode as a key aspect of +> > H.263+ affecting packet-network transport use. +> > +> +> Agree. +> +> >2) The specified format seems a bit heavy on the amount of overhead +> > recommended or required. Specifically: +> > +> > a) It *requires* (Sec. 4.2, first sentence) a copy of the entire +> > picture header to be attached to every packet that starts with +> > a GOB or slice start code. Although I think it is a *great* +> > idea to allow such extra picture headers to be attached, I +> > strongly suggest changing the text to *allow* and perhaps to +> > *encourage*, but not to require them. The extra picture +> > headers can be very repetitive and unnecessary in many +> > circumstances, and can result in a great deal of extra data +> > being sent. +> +> If we allow this, we should describe the ramifications in +> the document. I agree. +> Requiring the picture header to be always included +> provides better resiliency towards packet losses. Yes, but at the expense of burdening the network with extra data. It is a tradeoff. In some situations it will be a good idea, in others it will be a bad idea. Flexibility is all I'm asking for. +> If a picture +> header is not included in any packet that begins with a GOB/slice +> header, all packets besides the first packet in a frame would +> be treated as follow-on packets. Would be treated that way by whom? +> The receiver would need to +> toss any incomplete frame in which the packet containing its +> picture header is lost. Not necessarily. +> Furthermore, if any packet other than +> the first one in a frame is lost, the receiver will need to +> also parse for the GBSC/SSC in order to recover the partial +> frame, which is additional work. If the packet starts with GBSC/SSC, there is no "parsing" needed. All you need to do is check whether or not the payload starts with sixteen zeros. This is no more work than checking whether a redundant picture header is attached. +> +> > b) It strongly recommends a header and a separate packet for every +> > GOB. But is it a bad idea, for example, to put two GOBs in +> > each packet and only have a header on the first of each two +> > (cutting the overhead in half)? I think the wording on this +> > could be softened a little bit (although the present wording +> > does allow freedom for implementers as I read it). +> +> We are not recommending that a separate packet is used for every +> GOB. When using GOB headers instead of slices, if more than +> one GOB is contained in a packet, the GOB header could be +> eliminated in the second GOB without affecting resilience to +> packet loss. This should be better described in the document. +> +> > c) It recommends a complete picture header (UFEP = '001') on every +> > picture. In some circumstances, this may be unnecessary since +> > the OPPTYPE and its accompanying data may be the same for many, +> > many pictures in a row and since GFID will let the decoder at +> > least know when it changes (and since a complete picture header +> > will appear periodically anyway). I think the wording on this +> > could be softened a little bit (although the present wording +> > does allow freedom for implementers as I read it). +> +> The receiver cannot assume that the OPPTYPE never changes. If +> UFEP='000' is allowed, the receiver will need to wait for a +> complete header with UFEP='001' if picture header information +> has been lost, or if joining a session in progress. GFID does +> not help in situations where more than one consecutive picture +> header may be lost. GFID does help even when more than one picture header is lost. Three times out of four, GFID will detect the problem even if an infinite number of picture headers is lost. I'm not saying that UFEP='001' isn't sometimes a good idea. I'm just saying it's not *always* a good idea. Again, it's a tradeoff. If joining a session in progress, it's not going to do you much good if UFEP='001' but the picture is a INTER picture anyway. What's the harm if you put the extra overhead only on every-other picture, for example? This cuts down on the wasted bits and only adds one frame time for joiners. In many sessions, the picture header contents will never change at *all*. Why send it on *every* picture if it will never change? Not all networks are alike, not all picture headers are unpredictable, and not all systems can allow a lot of extra wasted bandwidth. It is a trade-off that should be based on the conditions at hand, not a purely one-sided issue. +> +> > d) When sending a redundant copy of a picture header, the first +> > six bits ('100000') are always the same, and are therefore +> > unnecessary. I suggest not sending them. I suppose the +> > motivation is ease of byte-oriented processing, but it doesn't +> > seem like that much of a burden to always shift the header by +> > six bits. +> +> We favor trading in the 6 bits for ease of processing. I don't mind this that much, but it's hard for me to see how a constant 6-bit shift is a big problem. +> +> >3) The description of the TID and Trun fields is clearly inadequate +> > (Sec. 4). Their use is entirely undefined, and the reference +> > given as a citation (draft 20 of H.263+) will be of little or no +> > help to the reader trying to figure them out. (Also, I suspect +> > that TID and Trun will sometimes be present in INTRA pictures, +> > although no INTRA picture will use the RPS mode of H.263+.) +> +> TID and Trun are parameters used only for VRC. A detailed +> desription of the VRC and its related parameters should be made +> available in a separate document which can be referenced here. +> Some kind of description of what these fields mean should be in this document. Also, although it may be acceptable for the complete definition to be elsewhere, this is only if that other place is something that can be referenced as a "normative" reference (for example, a magazine article is not something that can be referenced to define the syntax of an Internet Standard). These fields are completely undefined. +> >4) It may be useful to allow redundant picture headers to be attached +> > to packets already containing picture headers, and to allow the +> > redundant picture header attached to packets that begin with a GSC +> > or SSC to be altered in one key way. If the picture header in the +> > H.263+ payload bitstream itself is an abbreviated picture header +> > (UFEP = '000'), then it would be useful to allow the packetization +> > process to construct and attach a redundant complete picture header +> > (rather than attaching a copy of the abbreviated picture header). +> > In this way, the error robustness of the system can be enhanced +> > without increasing the bit rate of the payload or adding knowledge +> > of the packetization process to the encoder which is generating the +> > payload bitstream. +> +> Not sure that we understand the scenario that you are describing. +> If you are talking about hardware coders with which you cannot +> force to set UFEP='001', and having a payload handler replace the +> picture header with a complete one, that is an implementation +> detail which is possible now. If you are talking about including +> a complete picture header for the first packet in a frame, where +> an incomplete picture header is part of the payload data, that +> does increase the bit rate of the payload. In this case, it is +> just as effective for the encoder to set UFEP='001'. Consider the distinction between the picture header that is in the payload and the redundant copy of the picture header that is in the packet header. I'm saying that if UFEP='000' in the payload *contents*, it would be nice if we could still use UFEP='001' in the redundant copy. The drafted text says it should just be a copy of what is in the payload, it does not allow alteration, and alteration is necessary to change UFEP and insert OPPTYPE etc. +> +> >5) The draft as I have it appears not to be dated. Dating the +> > document would be helpful to establish when the draft has become +> > obsolete or which of two versions is newer. +> +> Agree. +> +> >Again, however, I wish to say that my overarching sentiment is that +> >I am pleased with the progress of work on this topic. +> +> ----------------------------------------------------------------------- +> These details will probably be discussed further during the AVT meeting. +> +> Thanks for the comments. +> +> Linda Cline +> Gim Deisher From rem-conf Mon Dec 08 20:27:14 1997 From rem-conf-request@es.net Mon Dec 08 20:27:13 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xfHAa-000422-00; Mon, 8 Dec 1997 20:21:16 -0800 Date: Tue, 9 Dec 1997 13:21:09 +0900 Message-Id: <199712090421.NAA00362@alesi.potato.kansai.oki.co.jp> From: nakai@kansai.oki.co.jp (Toshihisa Nakai) Sender: nakai@alesi.potato.kansai.oki.co.jp To: itu-adv-video@ferrari.iterated.com, rem-conf@es.net Cc: Gim_L_Deisher@ccm.jf.intel.com, Chad_Zhu@mail.intel.com, Donald_Newell@mail.intel.com, Christian_Maciocco@mail.intel.com, Thomas_R_Gardos@ccm.jf.intel.com, stewe@cs.tu-berlin.de, jo@cs.tu-berlin.de, cabo@tzi.org, lscline@ideal.jf.intel.com, nakai@kansai.oki.co.jp Subject: H.263+ RTP Packetization for Annex N back channel Reply-to: nakai@kansai.oki.co.jp X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear ITU-T Q.15/SG16 and IETF AVT Experts, I talked at the Eibsee meeting with Dr. Stephan Wegner on the payload packet format and found out that the packet format could be used also for the back channel messages defined in Annex N separate logical channel mode of H.263+ if one bit in the H.263+ payload header indicated the back channel message. Since there are some reserved fields in the header, I believe it does not harm any functionalities in the current draft. Dr. Wegner said he will raise this issue during the AVT meeting if possible. My comment might be too late. I really appreciate if this issue is considered in the process of the payload packet format discussion. Sincerely, Toshi Toshihisa Nakai (nakai@kansai.oki.co.jp) OKI Electric Ind. Co., Ltd. Tel +81 6 949 5105; Fax +81 6 949 5108 From rem-conf Tue Dec 09 12:56:54 1997 From rem-conf-request@es.net Tue Dec 09 12:56:52 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xfWJf-00046K-00; Tue, 9 Dec 1997 12:31:39 -0800 Message-ID: <348DD5FB.E72@ctr.columbia.edu> Date: Tue, 09 Dec 1997 15:36:27 -0800 From: "Andrew T.Campbell" Reply-To: campbell@ctr.columbia.edu Organization: Center for Telecommunications Research, Columbia University X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: end2end-interest@ISI.EDU, ietf@ietf.org, int-serv@ISI.EDU, rem-conf@es.net CC: "Aurel A. Lazar" , campbell@ctr.columbia.edu Subject: IEEE to standardize "Programmable Interfaces for Networks" Content-Type: multipart/mixed; boundary="------------776A697F6EF1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------776A697F6EF1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks: I thought researchers interested in programmable broadband, wireless and Internetworking technologies might be interested in this new IEEE initiative. Best, Andrew -- Andrew T. Campbell http://comet.ctr.columbia.edu/~campbell Wireless Media Systems Project http://comet.ctr.columbia.edu/wireless --------------776A697F6EF1 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from ruebert.ieee.org (ruebert.ieee.org [199.172.136.3]) by sirius.ctr.columbia.edu (8.8.7/8.6.4.287) with ESMTP id PAA17838; Tue, 9 Dec 1997 15:21:02 -0500 (EST) Received: (from daemon@localhost) by ruebert.ieee.org (8.7.5/8.7.3) id NAA20501 for tccc-list; Tue, 9 Dec 1997 13:48:04 -0500 (EST) From: aurel@comet.columbia.edu (Aurel A. Lazar) Date: Tue, 9 Dec 1997 13:47:59 -0500 (EST) Message-Id: <199712091847.NAA16987@comet.columbia.edu> To: tccc@ieee.org Subject: important initiative Cc: aurel@comet.columbia.edu Sender: owner-tccc@majordomo.ieee.org Precedence: bulk X-Resent-To: Multiple Recipients X-Listname: tccc X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org X-Moderator-Address: tccc-approval@majordomo.ieee.org I would like to bring to your attention that Columbia University, Ericsson, ISS and NEC have submitted a Project Authorization Request to IEEE to standardize "Programmable Interfaces for Networks". The request was approved on Monday, December 8, 1997. Because of its breadth and wide scope I believe this to be a key development in networking. The standardization process will potentially have an enormous impact on the design and implementation of next generation network arhitectures. Information about the proposal is available under "Standards" in the OPENSIG home page (http://comet.columbia.edu/opensig). Aurel --------------776A697F6EF1-- From rem-conf Tue Dec 09 23:28:32 1997 From rem-conf-request@es.net Tue Dec 09 23:28:31 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xfgGp-0002QM-00; Tue, 9 Dec 1997 23:09:23 -0800 Date: Tue, 09 Dec 97 23:56:08 EST From: hamr@great-mail.com To: group@heliocomp.net Subject: Advertisement: DON'T BUY TARGET E-MAIL LISTS!! Message-ID: <> Reply-To: hamr@great-mail.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We have many great products and programs, which benefit the Internet Marketer. If we have reached you in error and you don't wish to receive future mail from us, double click the reply to address and type remove as the subject. Your address will be removed immediately!! ________________Don't Buy Target Email Lists!!________________ Create your own target lists with, with the same tools the professionals use!! GEOLISTtm Version 2.01 Geographical Email Address Collector GeoList 2.01 lets you create geographically targeted email address lists without knowing a thing about URLS or HTML. With this powerful new collector, target any city, in any state! then click extract! GeoList will start gathering addresses automatically!! Watch as the list of e-mail addresses appears! This is the same program the professionals use to gather and sell their own target lists!! Build an entire Nation wide marketing campaign by state, or specific city. GeoList will make it easier than ever, with its powerful multithreaded program. Download the demo and try it! Once you see GeoList in action, you will buy it! You can purchase GeoList and within 30 to 60 seconds after purchase have a registered FUNCTIONAL program!! We have a user friendly "SUPER FAST" secure order-processing system!!! To download the free demo send e-mail to hamr@great-mail.com Geolist Demo as subject DejaVuTM Version 1.0 Collect Address from the History of the NewsGroups! Introducing a completely new target oriented email collection software linked directly to Deja News. Use DejaVu to automate your collection from Deja News, a complete historical archive of anyone who ever posted to a newsgroup! 30 to 60 seconds and you are a registered user!! Millions of Newsgroup Articles to search! You can choose to search through recent (last two months) articles, or articles dating back to 1995. Simply enter a keyword to search with and press go! To download the free demo send e-mail to hamr@great-mail.com DejaVu Demo as subject SonicTM Version 1.0 build 9 Multi-Tasking Email Address Collector The Sonic is an all-in-one, Web collection tool, that includes TargetSmart® Technology, 30 Second Registration, and Multiple SearchToggle. Let us again say, the added benefit behind Multi-threading, a process which lets you capture and extract your targeted search results at staggering speeds. Sonic is... Multi-Threaded Enter a keyword and Sonic will search the Internet!! Ability to search multiple sites simultaneously. Search any one of 9 different search engines, or search them ALL simultaneously! To download the free demo send e-mail to hamr@great-mail.com Sonic Demo as subject Looking for Mailers? Download, NetContact, Stealth, Mach10 Send e-mail to hamr@great-mail.com Mailer demos as subject. When you purchase our software you receive at no additional cost; 1. Mr. Clean e-mail filter. Process 100,000 address files through 32 filters in 36 seconds!! 2. Our CD of 28 million addresses, updated as of 11/7/97. The best list available. All software is sold with tech support. We will take the time to walk you through the process step by step. To purchase the cd of 28 million adresses, Price $85.00 send e-mail to hamr@great-mail.com Type CD Purchase as subject. From rem-conf Wed Dec 10 07:43:00 1997 From rem-conf-request@es.net Wed Dec 10 07:42:59 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xfo5u-0006NZ-00; Wed, 10 Dec 1997 07:30:38 -0800 Message-ID: <01BD0555.80ECBF00@horspiste.wpine.com> From: aeisenberg@wpine.com (Alfred Eisenberg) To: "'rem-conf@es.net'" , "group@heliocomp.net" Subject: RE: Advertisement: DON'T BUY TARGET E-MAIL LISTS!! Date: Wed, 10 Dec 1997 10:22:18 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD0555.810E50C0" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ------ =_NextPart_000_01BD0555.810E50C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable remove -----Original Message----- From: hamr@great-mail.com [SMTP:hamr@great-mail.com] Sent: Tuesday, December 09, 1997 11:56 PM To: group@heliocomp.net Subject: Advertisement: DON'T BUY TARGET E-MAIL LISTS!! We have many great products and programs, which benefit the Internet Marketer. If we have reached you in error and you don't wish to receive future mail from us, double click the reply to address and type remove = as the subject. =20 Your address will be removed immediately!! ________________Don't Buy Target Email Lists!!________________ Create your own target lists with, with the same tools the professionals = use!! GEOLISTtm Version 2.01 Geographical Email Address Collector =20 GeoList 2.01 lets you create geographically targeted email address lists = without knowing a thing about URLS or HTML. With this powerful new collector, target any city, = in any state! then click extract! GeoList will start gathering addresses automatically!! Watch as the list = of e-mail addresses appears! This is the same program the professionals use to gather and sell their = own target lists!! Build an entire Nation wide marketing campaign by state, or specific = city. GeoList will make it easier than ever, with its powerful multithreaded = program. Download the demo and try it! Once you see GeoList in action, you will = buy it! You can purchase GeoList and within 30 to 60 seconds after purchase = have a registered=20 FUNCTIONAL program!! =20 We have a user friendly "SUPER FAST" secure order-processing system!!! To download the free demo send e-mail to hamr@great-mail.com Geolist = Demo as subject DejaVuTM Version 1.0 Collect Address from the History of the = NewsGroups!=20 Introducing a completely new target oriented email collection software = linked directly to Deja News.=20 Use DejaVu to automate your collection from Deja News, a complete = historical archive of anyone who=20 ever posted to a newsgroup! 30 to 60 seconds and you are a registered = user!! Millions of Newsgroup Articles to search! You can choose to search through recent (last two months) articles, or = articles dating back to 1995.=20 Simply enter a keyword to search with and press go! To download the free demo send e-mail to hamr@great-mail.com DejaVu = Demo as subject SonicTM Version 1.0 build 9 Multi-Tasking Email Address Collector = =20 The Sonic is an all-in-one, Web collection tool, that includes = TargetSmart=AE Technology, 30 Second=20 Registration, and Multiple SearchToggle. Let us again say, the added = benefit behind Multi-threading, a process which lets you capture and extract your targeted search = results at staggering speeds. Sonic is... Multi-Threaded=20 Enter a keyword and Sonic will search the Internet!! Ability to search multiple sites simultaneously.=20 Search any one of 9 different search engines, or search them ALL = simultaneously! To download the free demo send e-mail to hamr@great-mail.com Sonic Demo = as subject Looking for Mailers? Download, NetContact, Stealth, Mach10 =20 Send e-mail to hamr@great-mail.com Mailer demos as subject. When you purchase our software you receive at no additional cost; 1. Mr. Clean e-mail filter. Process 100,000 address files through 32 = filters in 36 seconds!! 2. Our CD of 28 million addresses, updated as of 11/7/97. The best list = available. All software is sold with tech support. We will take the time to walk = you through the process step by step. To purchase the cd of 28 million adresses, Price $85.00=20 send e-mail to hamr@great-mail.com Type CD Purchase as subject. =20 ------ =_NextPart_000_01BD0555.810E50C0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhcPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAGAMAAAIAAAAQAAAAAwAAMAMAAAAL AA8OAAAAAAIB/w8BAAAAPQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHJlbS1jb25mQGVzLm5l dABTTVRQAHJlbS1jb25mQGVzLm5ldAAAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAEAAA AHJlbS1jb25mQGVzLm5ldAADABUMAQAAAAMA/g8GAAAAHgABMAEAAAASAAAAJ3JlbS1jb25mQGVz Lm5ldCcAAAACAQswAQAAABUAAABTTVRQOlJFTS1DT05GQEVTLk5FVAAAAAADAAA5AAAAAAsAQDoB AAAAHgD2XwEAAAAQAAAAcmVtLWNvbmZAZXMubmV0AAIB918BAAAAPQAAAAAAAACBKx+kvqMQGZ1u AN0BD1QCAAAAAHJlbS1jb25mQGVzLm5ldABTTVRQAHJlbS1jb25mQGVzLm5ldAAAAAADAP1fAQAA AAMA/18AAAAAAgH2DwEAAAAEAAAAAAAAAxAAAAADAAAwBAAAAAsADw4BAAAAAgH/DwEAAABFAAAA AAAAAIErH6S+oxAZnW4A3QEPVAIAAAEAZ3JvdXBAaGVsaW9jb21wLm5ldABTTVRQAGdyb3VwQGhl bGlvY29tcC5uZXQAAAAAHgACMAEAAAAFAAAAU01UUAAAAAAeAAMwAQAAABQAAABncm91cEBoZWxp b2NvbXAubmV0AAMAFQwBAAAAAwD+DwYAAAAeAAEwAQAAABQAAABncm91cEBoZWxpb2NvbXAubmV0 AAIBCzABAAAAGQAAAFNNVFA6R1JPVVBASEVMSU9DT01QLk5FVAAAAAADAAA5AAAAAAsAQDoAAAAA HgD2XwEAAAAUAAAAZ3JvdXBAaGVsaW9jb21wLm5ldAACAfdfAQAAAEUAAAAAAAAAgSsfpL6jEBmd bgDdAQ9UAgAAAQBncm91cEBoZWxpb2NvbXAubmV0AFNNVFAAZ3JvdXBAaGVsaW9jb21wLm5ldAAA AAADAP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAABNqeAQSAAQAzAAAAUkU6IEFkdmVydGlz ZW1lbnQ6IERPTidUIEJVWSBUQVJHRVQgRS1NQUlMIExJU1RTISEAnw4BBYADAA4AAADNBwwACgAK ABYAEgADAB8BASCAAwAOAAAAzQcMAAoACgAWAA0AAwAaAQEJgAEAIQAAADk1MTE1QUVGQUY3MEQx MTE4MjE2MDA2MDk3NkFEQ0UxABEHAQOQBgCIDAAAIQAAAAsAAgABAAAACwAjAAAAAAADACYAAAAA AAsAKQAAAAAAAwAuAAAAAAADADYAAAAAAEAAOQCAHU5nfwW9AR4AcAABAAAAMwAAAFJFOiBBZHZl cnRpc2VtZW50OiBET04nVCBCVVkgVEFSR0VUIEUtTUFJTCBMSVNUUyEhAAACAXEAAQAAABYAAAAB vQV/Zz3vWhGWcK8R0YIWAGCXatzhAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4AHwwBAAAADgAAAGFs ZkB3cGluZS5jb20AAAADAAYQ68ljhQMABxD7CgAAHgAIEAEAAABlAAAAUkVNT1ZFLS0tLS1PUklH SU5BTE1FU1NBR0UtLS0tLUZST006SEFNUkBHUkVBVC1NQUlMQ09NU01UUDpIQU1SQEdSRUFULU1B SUxDT01TRU5UOlRVRVNEQVksREVDRU1CRVIwOQAAAAACAQkQAQAAAFYJAABSCQAAxBAAAExaRnXg wpw2dwAKAQMB9yACpARkAgBjgmgKwHNldDAgCFUfB7ICgwBQA9QCAHBycewyIAcTAoMyEScPhxIF Jn0KgAjIIDsJbzI1ZjUCgAqBdWMAUAsDYwMAQQtgbmcxMDMzqQxgbG4CIGULpiAJcH0EYHYYcAqx CoQKhAswbHhpMzYBQBdQAUARsG8KdAWQdBD0MTYgLfUcMk8FEGcLgAdABdAHkPBzYWdlHDMZdhtE GxGDCxMbRmktMTQ0AUBxGpAxODABQAzQH9Ni1CBGA2E6DINiD/APkIhtckAJwWF0LQDABQMQLgWg bSBbU03YVFA6If8DcF0ZdSEAFwZgAjAhZ1QKUHNkYbB5LCBEBZAZIGIQYYQwOSagMTk5NyeASDE6 NRwQUE0k11QObyFnCcAIYHBAaGXlGpBvIvFwLhhgG5Ak55h1YmobcSFnQWQZUB8AIAQAGSAlciaw T04nIFQgQlVZJiBBUgRHRS2QRS1NQUkATCBMSVNUUyF+IR3fHuoalBKTDAEZg1fWZSHhGVAgA4F5 KZEiYWogGzFkFsB0BCAAcGQXM2IJwCOgcyagd2hpvQ+AICcQGGAfoAVAdCoAXCBJAjAEkSq2TQrA a+sP0ASQLjXwZjTQMlUiUVMPgAmAIHkIYCALgCBfBJADYAXANAI4smQCICdnBUAD8TUgdG8ZASbg afEZVmZ1dAhwMqIDEQNSXCB1NLE6ACtwbDJQY/kakGNrNbMJcAtQMvA6sThhZGQJcAQRNAJ0eb5w OBIZMjPwBCA1wnMrdHc3YArjCoBZCGE+lwPwbL8DICcQGQU0IAdwB4BkBzCvG2A+QC8oGZhfRV1E OhN0QnUy8FQKwB1gBUBFfTwjTAQAM9AvIEVeGXpDzyJSMlA4sQXAb3cDoAGQ/0cTGpBH4TpRNcA0 wUvRQES/I6AyUDqwBvBANBsxZh0hbyowHNEEIDzAZUQcLiBPNS7SdCMQVgSQTgIgMpguMDFBEFDy R2U0Yv5wNPEc4UdkLGA+xAhQQoD/G3EFsUEWUVFHwlCkPUAz0f84sgUAShMdYFF4PkJHAziBvxkg PDI+pktoCGAFQGsYQP8D8BewM/A1sVlxGXQBoFjyGFVSTAXwBbFIVE36TDdgV0w0BAAzYEqwBJD/ O7ADIBhgB+AI4VM0JqBK9f0y0mM1kCaROPEy0kfgQ8GOITWyA6A9dGV4dDSA/xuALzVUJkJjX2EA ICmQInDfKgAFEFmCPrQHkWE7wANx/yywVoMvIFuwInA1EUAlS2LfSqA3kB1wV4pjonA/gA+h/UQr VFwiXDFMdzRFTV9OY786omKUM/MPwEKBNcFpSp//SAEZekawAxA0IAORJXFswP0yUE5kIVCBA/AB ADKxNwKvWXJR4CpwC3BnA6BiX0W7JqAFsXM/gF6QH6BjXoP+LmEPAyAAwDcQOOAFQCJg/wCQEGE1 wG8yLIFMBTWQXEn+bRggLLA1wCJRAQA0J3Nl/xl0RlBKwAkAPqA1swEABGCdPxRyMvA1kF+wT24m 4P84ow/AMlBUJl7yG4BOESagfziyQmRGwXshQTdxIQOgcH8IcA+BazFUJjPzS8I48TP/D/A6sRrA bDEFoDQQM+EBgP8QYX9HMnNZsAlwHLBH4ASQAziBGXRGVU5DVEn9LWBBLrA0RWShQSUyRlmwP06B BcADUAiQNBA+QSJTUFVQRVIhEEEu8CLvgZI74gWwBIEtGzEm4E3x+VmBc3mDwYWhZ6w6wDoA/3mp A1B8AXpTD8A0EWYlOrH/QRAjnyMBUTNloybAenIEIAtAlUQ/CiaxamFWdfdbcFDxUDYxUMBQ81MF Unf7PHM1wkhH0QWwMvBl8TXC+QfBc0cpskgAQSUZdDYB/zODWXQqUlTxQ+Fc40r1BbAvh2FXOF01 UHJzTcB0d3sKwGWCbjcQNCBDoDrhdN8+RJIilkM3YBl0VWsxkiT/PmNj5EpFmwk8c513JqCYmP+O EJVzUdMKwA+AOyFl4jLR/xhRNNE6wBl0deJcUYPBP0H7PoFc4nMpo4XBgR85hpwC94NrhvIvJk1C cU4RBCBl8f+WUimjEfFkMT1AQDGM8qNSf35dD4BNEGs0rGQ1sSmxZ+c1IDriAjAgKAtgVHGb4Mc6 wARgAjBocymjQavE33JDsNY58GQhWYFiANA9sfs6wCeRNZ4GBgAHcD4ymkLzOWFZIGV5sCALIK4Z TCPzNAQ+4mdvLzWLf4yPjZXfji+PM562kA+ReVMCIDUAr5KCktp98G7yOVDzTXdy8i1G8HNrWXJS L1M3QRa/aBYyUL2zaLIDkVaRLQuA/i0YUSagMkAhAJsJTQJdwXcPkHySPXB1AQAEIEb0U1NwkRuQ J2EyUFQFkGj7GEAJAGcmkabhBmCBwkEl/lKDkzSAfQQ0Ar/DmOEGUbOjUijwZ2c9QDdgTEcx/zzA M/BikDjxHUAmkTXCPqHfOIE1RicQWeHK1S13tFlx/ixaJTNiiaI01VT4UaA70/80AmCFSlRW565V PtF3cTPh/wVAX2HMAGLUcpEJgJ3wGXR9w2Yu10C/tnfGkbVQ9EX/tH00AsNkYeSuZjXoLybY1fxB YgMQXqGuGXdjy0IAkP8bYLxRB3B3cQBwUWA8wD5A/7NnUPTLhF5DpDJl8b9gQ6D/ASCD4a+BrlUJ 8ByxsTXbOP8jEIUQLrDfbIqvt8+437nv7yLUw2S7/xmYTE0QwFMCEPcFwSKxUEE/JrB5lSagB8De dAhQAjBgwSagUxtgB0D/S+I24A+AF9BBFiVh6M+6b7+/oe2jekMz4euHeLtXX+L/OLJ/R0Gim7c4 sjrl1QIYQP8+kjWQThNdIUfgFSAZg5NQ+wXQN1FDPUBvMmY0H6B3gM03QlDQpRfQMCwgYA/w7z6m +1GsAq7VMxHg+1RooX+A8RwQgaUvJlCwe1BBsUPyRGXiMjgysKpUYygmoD8p0LIxOIFAIWXxJ+Av N/4vJ7A3YMMiJxBUcWWjMoDvIrEsAMwhGXpBYgKbxlwx/5uwbwFMJMghQIFnQBTBW6H/pFFCcivw dME1wiywTNM00P/EID2wOLKuxmoFiaLchIPBf6uAccM+IHi75vF/RzXCYz80IADeAeb70DUAMlAk OL+zUPyhC+WNIvE/jo1UP3L9AKFQf1b0P9yLFoaQ/xnFCn0aEAAZMAAAAwAQEAAAAAADABEQAQAA AAMAgBD/////QAAHMOD1Y2R/Bb0BQAAIMOD1Y2R/Bb0BAwAGgAggBgAAAAAAwAAAAAAAAEYAAAAA UoUAALcNAAAeAAeACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjAAAwAIgAggBgAA AAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAAmACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAsA CoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwALgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUA AAAAAAADAAyACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMADYAIIAYAAAAAAMAAAAAAAABG AAAAABiFAAAAAAAAHgAOgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4AD4AI IAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeABCACCAGAAAAAADAAAAAAAAARgAA AAA4hQAAAQAAAAEAAAAAAAAAHgA9AAEAAAAFAAAAUkU6IAAAAAADAA00/TcAABX1 ------ =_NextPart_000_01BD0555.810E50C0-- From rem-conf Thu Dec 11 21:57:17 1997 From rem-conf-request@es.net Thu Dec 11 21:57:17 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xgNr8-00059Z-00; Thu, 11 Dec 1997 21:41:46 -0800 X-Sender: cckrees@dingo.uq.edu.au Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Dec 1997 15:49:42 +1000 To: rem-conf@es.net From: K.Rees@dingo.cc.uq.edu.au (kay rees) Subject: 7th International World Wide Web Conference X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list WWW7 - News Flash December 1997 ************************************************************************ Drop in Australian Dollar means great savings for international visitors ************************************************************************ Due to the recent financial crisis in the Asian region the Australian Dollar has dropped almost 20% in relation to the US dollar, the franc, the mark and the pound. Registering for WWW7 now will ensure you receive the Early Bird Registration Discount PLUS an ADDITIONAL 20% discount off the registration cost. But be quick - this situation is expected to change in the coming weeks because the underlying Australian economy is quite strong with economic growth rates of 4% To register go to: http://www.webventures.com.au/javelin/jssi/www7/welcome.jhtml ************************************************************************ The following Keynote Speakers (in alphabetical order) have confirmed for WWW7: =B7 Senator Richard Alston, Australian Minister for Communications, the Information Economy and the Arts =B7 Martin Bangemann, Member of the European Commission, responsible for Industrial Affairs and Information and Telecommunications Technologies =B7 Tim Berners-Lee, Director, W3C =B7 James Gosling, Vice President Sun Microsystems =B7 Xing Li, Deputy Director, China Education and Research Network =B7 Cathy Marshall, Principal Engineer, XEROX PARC =B7 John Patrick, VP of Internet Technology, IBM Information & Telecommunications Technologies =B7 Paul Saffo, Director, Institute of the Future ************************************************************************ A. World Class Keynote Speakers Confirmed B. Call for Papers now closed - Great response means lots of work for Reviewers C. Associated Event - 12th International Unicode Conference D. Conference Contact Details ************************************************************************ A. WORLD CLASS KEYNOTE SPEAKERS CONFIRMED Some of the world's most influential Web researchers and developers are amon= g confirmed speakers for the Seventh International World Wide Web Conference a= nd Exhibition in April, in Brisbane, Australia. SENATOR RICHARD ALSTON Minister for Communications, the Information Economy and the Arts, Deputy Leader of the Government in the Senate and Chairman of the Ministerial Council on the Information Economy TIM BERNERS-LEE Co-developer of the World Wide Web and Director of the independent World Wide Web Consortium JAMES GOSLING Dr Gosling was instrumental in the development of Java and is currently Vice-President of Sun Microsystems XING LI One of China's foremost Web experts, Prof Xing Li is the director of Net-Compass - a team developing a search engine for Chinese/English home pages. CATHY MARSHALL Co-author of 'Forward Anywhere' and principal engineer at the Xerox Palo Alt= o Research Center. Cathy Marshall is among the world's leading authorities on hypertext. JOHN PATRICK IBM Corporation Internet Technology Vice-President and created the AlphaWork= s web site and the successful ThinkPad brand PAUL SAFFO Dr Saffo, Director of the Institute for the Future, is a specialist in the long-term social and commercial impacts of new information technologies. ************************************************************************ B. Call for Papers now closed - Great response means lots of work for Reviewers WWW7 has attracted over 200 paper submissions and 30 tutorial proposals. This conference series is one of the most popular and valuable International Web conferences to be held annually. The Conference has a network of over 100 reviewers who have volunteered thei= r time to help select 60 of the best papers to be presented at the event ************************************************************************ C Due to the overwhelming response to the Call for Papers, the Twelfth International Unicode/ISO 10646 Conference, planned for April 1998 in Tokyo, is being extended from two days to three! The revised dates are April 8-10. This will give attendees plenty of time to get to Brisbane for the start of the 7th International World Wide Web Conference on April 14. See you in Tokyo and Brisbane! http://www.unicode.org *********************************************************************** D. If you would like to know more details about the Seventh International World Wide Web Conference and Exhibition, please visit our web site http://www7.conf.au or email: info@www7.conf.au =46urther contact details........ WWW7 Conference Secretariat PO Box WWW7 St Lucia South Queensland Australia 4067 Phone +61 7 3870 8831 =46ax +61 7 3371 9514 7th International World Wide Web Conference 14-18 April 1998 Brisbane Convention & Exhibition Centre Brisbane Australia http://www7.conf.au From rem-conf Fri Dec 12 10:01:33 1997 From rem-conf-request@es.net Fri Dec 12 10:01:30 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xgZ55-0001m9-00; Fri, 12 Dec 1997 09:40:55 -0800 Date: Fri, 12 Dec 1997 18:39:51 +0100 (MET) From: Christian Isnard - CERN/IT/CS/EN To: rem-conf MBONE List Subject: Vic voice-switched mode under Win95 ? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Help! The nice "voice-switched" mode of vic/vat does not seem to work under Win'95. We use vic v2.8 and vat v4.0b2. Has someone experienced the same problem, and - hopefully - found a fix? Thanks, -- Christian. From rem-conf Fri Dec 12 17:06:37 1997 From rem-conf-request@es.net Fri Dec 12 17:06:36 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xgfsa-0005ES-00; Fri, 12 Dec 1997 16:56:28 -0800 Message-ID: <69D8143E230DD111B1D40000F848584001210C9A@ED> From: "Eric Fleischman (Exchange)" To: "'rem-conf@es.net'" Subject: Network Aware Codecs Date: Fri, 12 Dec 1997 17:00:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > I would appreciate any information which members of this list could > provide concerning the current state-of-the-art of "network aware" > codec implementations. That is, for the Payload Formats which we have > defined which require a codec-specific header in addition to the "raw" > compression bits, what is the status of actual codec implementations > whose output consists of both the compression stream and the > codec-specific (Payload) header? Are any of these codec > implementations configurable so that one can specify the output to > either be compression bits only or else compression bits plus payload > header? Does the AVT WG implementations, which encode such payload > formats (e.g., H.263+), require altering the codecs (i.e., changing > the codecs' code) themselves or are these implementations basicly > interpreters which understands the codecs' output and insert the > Payload headers at the appropriate places? From rem-conf Fri Dec 12 17:23:09 1997 From rem-conf-request@es.net Fri Dec 12 17:23:08 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xggDW-0005hW-00; Fri, 12 Dec 1997 17:18:06 -0800 Message-ID: <69D8143E230DD111B1D40000F848584001210C9C@ED> From: "Eric Fleischman (Exchange)" To: "'rem-conf@es.net'" Subject: Network Aware Codecs Date: Fri, 12 Dec 1997 17:21:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I would appreciate any information which members of this list could provide concerning the current state-of-the-art of "network aware" codec implementations. That is, for the Payload Formats which we have defined which require a codec-specific header in addition to the "raw" compression bits, what is the status of actual codec implementations whose output consists of both the compression stream and the codec-specific (Payload) header? Are any of these codec implementations configurable so that one can specify the output to either be compression bits only or else compression bits plus payload header? Does the AVT WG implementations, which encode such payload formats (e.g., H.263+), require altering the codecs (i.e., changing the codecs' code) themselves or are these implementations basicly interpreters which understands the codecs' output and insert the Payload headers at the appropriate places? From rem-conf Mon Dec 15 05:34:02 1997 From rem-conf-request@es.net Mon Dec 15 05:34:01 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xhaMO-000648-00; Mon, 15 Dec 1997 05:15:00 -0800 Message-ID: From: "Yang, Jin (Jin)" To: "'rem-conf MBONE List'" Subject: transmit JPEG with vic Date: Mon, 15 Dec 1997 13:19:44 -0000 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 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 Hi, We'd like to transmit moving JPEG video picture using vic. Anyone there can provide any info about the configuration ? (platform, the card for encoder..) Thanks a lot, Jin From rem-conf Mon Dec 15 08:13:27 1997 From rem-conf-request@es.net Mon Dec 15 08:13:27 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xhd2T-0007QL-00; Mon, 15 Dec 1997 08:06:37 -0800 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: "Eric Fleischman (Exchange)" cc: "'rem-conf@es.net'" Subject: Re: Network Aware Codecs In-reply-to: Your message of "Fri, 12 Dec 1997 17:21:54 PST." <69D8143E230DD111B1D40000F848584001210C9C@ED> Date: Mon, 15 Dec 1997 11:06:33 -0500 Message-ID: <11161.882201993@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >I would appreciate any information which members of this list could >provide concerning the current state-of-the-art of "network aware" codec >implementations. That is, for the Payload Formats which we have defined >which require a codec-specific header in addition to the "raw" >compression bits, what is the status of actual codec implementations >whose output consists of both the compression stream and the >codec-specific (Payload) header? Are any of these codec implementations >configurable so that one can specify the output to either be compression >bits only or else compression bits plus payload header? Does the AVT WG >implementations, which encode such payload formats (e.g., H.263+), >require altering the codecs (i.e., changing the codecs' code) themselves >or are these implementations basicly interpreters which understands the >codecs' output and insert the Payload headers at the appropriate places? An example of this that I mentioned last week in DC is H.261. A little history: H.261 is a bitstream format. The smallest unit that can be trivially discovered from the bitstream is a Group of Blocks (GOB). The original H.261 format involved splitting the bitstream at GOB boundaries, and including a H.261-specific header starting how many spare bits were in the first and last bytes (because nothing in H.261 is byte-aligned). At the receiver, a valid H.261 bitstream can be reconstructed by splicing the GOBs back together, and when packet loss has occurred, by adding up to 7 11-bit H.261 pads to align GOBs that dont finish and then start at the same bit-position. You can't recreate a legal H.261 bitstream without at least this level of codec knowledge. The problem with this was that GOBs can be up to 3K long, so we saw a fair amount of fragmentation, which causes a "loss-multiplication" effect - packets are received but have to be discarded because fragments are missing. The current H.261 payload format solves this by requiring more parsing of the H.261 stream, and splitting on Macroblock boundaries. This involves including more information in the H.261 packet header to convey current MB number, quantiser state, etc. The resulting H.261 packet stream is much more robust to packet loss, at the expense of a little more work at the encoder. Now in either case, servers serving stored streams could pre-parse the data and store the packet headers along with the data in an RTP-specific file format, so the server never has to know anything about the format it is serving. Clients however need the relevant codec anyway, so you can't get around having codec-specific code in the client. Other payload formats that do similar things are H.263, H.263+ and Motion JPEG. The DVI4 encoding includes a 16 bit predictor value at the start of the packet. A few payload formats that are defined in RFC 1890 (particularly the frame-based audio codecs) should include some predictor state, but don't, making them less suitable for links with any loss. Someone should define proper payload formats for these. Mark From rem-conf Mon Dec 15 11:36:37 1997 From rem-conf-request@es.net Mon Dec 15 11:36:36 1997 Received: from list by mail1.es.net with local (Exim 1.80 #1) id 0xhgDv-0002Bw-00; Mon, 15 Dec 1997 11:30:39 -0800 Message-ID: <69D8143E230DD111B1D40000F848584001210CA9@ED> From: "Eric Fleischman (Exchange)" To: 'Mark Handley' Cc: "'rem-conf@es.net'" Subject: RE: Network Aware Codecs Date: Mon, 15 Dec 1997 11:35:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Thanks for your reply. I must have posed my question poorly because your reply gave me an example of the mechanism by which we have made codecs "network aware" when my question was entirely centered on implementations of that mechanism. Specifically: * Are there any implementations of codecs which natively contains our "network aware" approach (i.e., specific codec payload format)? * If so, is the codec configurable to permit a usage instance to request whether the codec payload format is included or not? * If not, do implementations require the addition of an "interpreter"-like functionality to correctly append the payload format to the codec-generated stream? * I also would appreciate insight into how widespread support for the codec-payload format is. That is, does this form part of the ITU/ISO/etc. codec defintion? How many codec vendors support this capability? One of my goals in asking this question concerns a generic payload format definition approach. In the general case, I believe that it is extremely desirable for the client itself to be entirely codec-independent (i.e., to not know anything about codecs). This way the client can theoretically support the several hundred distinct codecs for which media currently exists. It accomplishes this by the client relying on specific components (subsystems) by which specific "codec knowledge" is obtained. Currently, an extensive system of such components have already become publicly available permitting a client to transparently download a component to handle a codec which the client otherwise would not be able to understand. That is "real world" today -- and quite common within our industry. Unfortunately, I am not aware of any instance of any such codec which supports our "network aware" approach. Since this is so, it is highly relevant to learn whether there exists any codec implementations supporting AVT's "network aware" codec definitions. If so, does the "network aware" part come bundled within the codec decoder (and if so, is there a specific common way by which to enable or disable it) or must it be independently downloaded in addition to the decoder? Has anybody actually built clients supporting downloadable codecs supporting this feature or is this currently an "academic exercise"? If the latter, then on what basis can we conclude that this approach can work in a robust fashion with actual products? > -----Original Message----- > From: Mark Handley [SMTP:mjh@east.isi.edu] > Sent: Monday, December 15, 1997 8:07 AM > To: Eric Fleischman (Exchange) > Cc: 'rem-conf@es.net' > Subject: Re: Network Aware Codecs > > > >I would appreciate any information which members of this list could > >provide concerning the current state-of-the-art of "network aware" > codec > >implementations. That is, for the Payload Formats which we have > defined > >which require a codec-specific header in addition to the "raw" > >compression bits, what is the status of actual codec implementations > >whose output consists of both the compression stream and the > >codec-specific (Payload) header? Are any of these codec > implementations > >configurable so that one can specify the output to either be > compression > >bits only or else compression bits plus payload header? Does the AVT > WG > >implementations, which encode such payload formats (e.g., H.263+), > >require altering the codecs (i.e., changing the codecs' code) > themselves > >or are these implementations basicly interpreters which understands > the > >codecs' output and insert the Payload headers at the appropriate > places? > > > An example of this that I mentioned last week in DC is H.261. > > A little history: > > H.261 is a bitstream format. The smallest unit that can be trivially > discovered from the bitstream is a Group of Blocks (GOB). The > original H.261 format involved splitting the bitstream at GOB > boundaries, and including a H.261-specific header starting how many > spare bits were in the first and last bytes (because nothing in H.261 > is byte-aligned). At the receiver, a valid H.261 bitstream can be > reconstructed by splicing the GOBs back together, and when packet loss > has occurred, by adding up to 7 11-bit H.261 pads to align GOBs that > dont finish and then start at the same bit-position. You can't > recreate a legal H.261 bitstream without at least this level of codec > knowledge. > > The problem with this was that GOBs can be up to 3K long, so we saw a > fair amount of fragmentation, which causes a "loss-multiplication" > effect - packets are received but have to be discarded because > fragments are missing. The current H.261 payload format solves this > by requiring more parsing of the H.261 stream, and splitting on > Macroblock boundaries. This involves including more information in > the H.261 packet header to convey current MB number, quantiser state, > etc. The resulting H.261 packet stream is much more robust to packet > loss, at the expense of a little more work at the encoder. > > Now in either case, servers serving stored streams could pre-parse the > data and store the packet headers along with the data in an > RTP-specific file format, so the server never has to know anything > about the format it is serving. > > Clients however need the relevant codec anyway, so you can't get > around having codec-specific code in the client. > > > Other payload formats that do similar things are H.263, H.263+ and > Motion JPEG. The DVI4 encoding includes a 16 bit predictor value at > the start of the packet. > > A few payload formats that are defined in RFC 1890 (particularly the > frame-based audio codecs) should include some predictor state, but > don't, making them less suitable for links with any loss. Someone > should define proper payload formats for these. > > Mark From rem-conf Mon Dec 15 11:38:37 1997 From rem-conf-request@es.net Mon Dec 15 11:38:37 1997 Received: from list by mail1.es.net with local (Exim 1.80 #1) id 0xhgKy-0002L5-00; Mon, 15 Dec 1997 11:37:56 -0800 Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: "Eric Fleischman (Exchange)" , Subject: Re: Network Aware Codecs Date: Mon, 15 Dec 1997 14:32:44 -0500 Message-ID: <01bd0990$37613520$6782cf87@pcmrc.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 We implemented a system based on the MPEG-2 payload format. It packetizes and transmits A/Velementary stream outputs of a generic MPEG-2 encoder (a PC plug-in board) through application level software. A generic hardware decoder plug-in board is used at the reciever which decodes elementary streams generated by a software only de-packetizer application that processes received RTP packets with error resilience. The system can perfectly handle around 4.5 Mbps total bandwidth on a 200 MHz Pentium with a 10baseT Ethernet connection. Andrea Basso & Reha Civanlar AT&T Labs Research ---------------------------------------------------------------------------- ---------- -----Original Message----- >I would appreciate any information which members of this list could >provide concerning the current state-of-the-art of "network aware" codec >implementations. That is, for the Payload Formats which we have defined >which require a codec-specific header in addition to the "raw" >compression bits, what is the status of actual codec implementations >whose output consists of both the compression stream and the >codec-specific (Payload) header? Are any of these codec implementations >configurable so that one can specify the output to either be compression >bits only or else compression bits plus payload header? Does the AVT WG >implementations, which encode such payload formats (e.g., H.263+), >require altering the codecs (i.e., changing the codecs' code) themselves >or are these implementations basicly interpreters which understands the >codecs' output and insert the Payload headers at the appropriate places? From rem-conf Mon Dec 15 13:16:15 1997 From rem-conf-request@es.net Mon Dec 15 13:16:14 1997 Received: from list by mail1.es.net with local (Exim 1.80 #1) id 0xhhlf-0003lJ-00; Mon, 15 Dec 1997 13:09:35 -0800 Message-ID: <69D8143E230DD111B1D40000F848584001210CAB@ED> From: "Eric Fleischman (Exchange)" To: "'rem-conf@es.net'" Subject: Re: Network Aware Codecs Date: Mon, 15 Dec 1997 13:13:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Thanks for your reply. I must have posed my question poorly because your reply gave me an example of the mechanism by which we have made codecs "network aware" when my question was entirely centered on implementations of that mechanism. Specifically: * Are there any implementations of codecs which natively contains our "network aware" approach (i.e., specific codec payload format)? * If so, is the codec configurable to permit a usage instance to request whether the codec payload format is included or not? * If not, do implementations require the addition of an "interpreter"-like functionality to correctly append the payload format to the codec-generated stream? * I also would appreciate insight into how widespread support for the codec-payload format is. That is, does this form part of the ITU/ISO/etc. codec defintion? How many codec vendors support this capability? One of my goals in asking this question concerns a generic payload format definition approach. In the general case, I believe that it is extremely desirable for the client itself to be entirely codec-independent (i.e., to not know anything about codecs). This way the client can theoretically support the several hundred distinct codecs for which media currently exists. It accomplishes this by the client relying on specific components (subsystems) by which specific "codec knowledge" is obtained. Currently, an extensive system of such components have already become publicly available permitting a client to transparently download a component to handle a codec which the client otherwise would not be able to understand. That is "real world" today -- and quite common within our industry. Unfortunately, I am not aware of any instance of any such codec which supports our "network aware" approach. Since this is so, it is highly relevant to learn whether there exists any codec implementations supporting AVT's "network aware" codec definitions. If so, does the "network aware" part come bundled within the codec decoder (and if so, is there a specific common way by which to enable or disable it) or must it be independently downloaded in addition to the decoder? Has anybody actually built clients supporting downloadable codecs supporting this feature or is this currently an "academic exercise"? If the latter, then on what basis can we conclude that this approach can work in a robust fashion with actual products? -----Original Message----- From: Mark Handley [SMTP:mjh@east.isi.edu] Sent: Monday, December 15, 1997 8:07 AM To: Eric Fleischman (Exchange) Cc: 'rem-conf@es.net' Subject: Re: Network Aware Codecs >I would appreciate any information which members of this list could >provide concerning the current state-of-the-art of "network aware" codec >implementations. That is, for the Payload Formats which we have defined >which require a codec-specific header in addition to the "raw" >compression bits, what is the status of actual codec implementations >whose output consists of both the compression stream and the >codec-specific (Payload) header? Are any of these codec implementations >configurable so that one can specify the output to either be compression >bits only or else compression bits plus payload header? Does the AVT WG >implementations, which encode such payload formats (e.g., H.263+), >require altering the codecs (i.e., changing the codecs' code) themselves >or are these implementations basicly interpreters which understands the >codecs' output and insert the Payload headers at the appropriate places? An example of this that I mentioned last week in DC is H.261. A little history: H.261 is a bitstream format. The smallest unit that can be trivially discovered from the bitstream is a Group of Blocks (GOB). The original H.261 format involved splitting the bitstream at GOB boundaries, and including a H.261-specific header starting how many spare bits were in the first and last bytes (because nothing in H.261 is byte-aligned). At the receiver, a valid H.261 bitstream can be reconstructed by splicing the GOBs back together, and when packet loss has occurred, by adding up to 7 11-bit H.261 pads to align GOBs that dont finish and then start at the same bit-position. You can't recreate a legal H.261 bitstream without at least this level of codec knowledge. The problem with this was that GOBs can be up to 3K long, so we saw a fair amount of fragmentation, which causes a "loss-multiplication" effect - packets are received but have to be discarded because fragments are missing. The current H.261 payload format solves this by requiring more parsing of the H.261 stream, and splitting on Macroblock boundaries. This involves including more information in the H.261 packet header to convey current MB number, quantiser state, etc. The resulting H.261 packet stream is much more robust to packet loss, at the expense of a little more work at the encoder. Now in either case, servers serving stored streams could pre-parse the data and store the packet headers along with the data in an RTP-specific file format, so the server never has to know anything about the format it is serving. Clients however need the relevant codec anyway, so you can't get around having codec-specific code in the client. Other payload formats that do similar things are H.263, H.263+ and Motion JPEG. The DVI4 encoding includes a 16 bit predictor value at the start of the packet. A few payload formats that are defined in RFC 1890 (particularly the frame-based audio codecs) should include some predictor state, but don't, making them less suitable for links with any loss. Someone should define proper payload formats for these. Mark From rem-conf Tue Dec 16 10:16:45 1997 From rem-conf-request@es.net Tue Dec 16 10:16:44 1997 Received: from list by mail1.es.net with local (Exim 1.80 #1) id 0xi1Hm-0003Ho-00; Tue, 16 Dec 1997 10:00:02 -0800 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: rem-conf@es.net Subject: Draft on RTP payload format guidelines Date: Tue, 16 Dec 1997 12:59:56 -0500 Message-ID: <16473.882295196@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I just submitted the following new internet draft to the archive (it should appear in a few days), as I realised that we don't really have any guidelines for anyone writing a payload format document to start from. I don't know whether any of this is contentious - perhaps with the recent debate about generic payload formats it might be. If you have any suggestions for additional guidelines, or just comments in general, please let me know. Eventually I guess this might become an informational RFC or a BCP. Cheers, Mark -------- Title : Guidelines for writers of RTP payload format specifications Author : Mark Handley Pages : 4 Filename : draft-ietf-avt-rtp-format-guidelines-00.txt, .ps Date : 16-dec-97 This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifica- tions in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development. ASCII and Postscript are currently available from: http://north.east.isi.edu/~mjh/draft-ietf-avt-rtp-format-guidelines-00.txt and http://north.east.isi.edu/~mjh/draft-ietf-avt-rtp-format-guidelines-00.ps From rem-conf Tue Dec 16 10:16:47 1997 From rem-conf-request@es.net Tue Dec 16 10:16:46 1997 Received: from list by mail1.es.net with local (Exim 1.80 #1) id 0xi1O0-0003Ix-00; Tue, 16 Dec 1997 10:06:28 -0800 Date: Tue, 16 Dec 1997 10:05:25 -0800 (PST) From: "T. Todd Elvins" To: scwpf@sdsc.edu, web-watchers -- K Claffy , rem-conf@es.net, webteam@qualcomm.com, webheads@sio.ucsd.edu, java-ucsd@mib.org, flesner@nosc.mil, talks@ucsd.edu Cc: Talks , talks-ece@ece.ucsd.edu Subject: The Future of Java - Sun Evangelist to speak on Wednesday, 7pm, SDSC , & MBONE broadcast Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list "The Future of Java" Dave Meyers, Java Evangelist, Sun Microsystems December 17, 1997, 7pm San Diego Supercomputer Center (SDSC) Auditorium Dave Meyers will discuss future directions of Java, the pressures >from other technologies, and other related topics. This presentation will be broadcast on the MBONE. For parking and direction information, see our web site at http://www.sdsc.edu/scwpf Todd From rem-conf Thu Dec 18 10:50:10 1997 From rem-conf-request@es.net Thu Dec 18 10:50:09 1997 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xikcD-0004Jm-00; Thu, 18 Dec 1997 10:24:09 -0800 Message-Id: <199712181822.KAA08875@tweety.main.gnac.com> To: baylisa@baylisa.org, sage-members@usenix.org, rem-conf@es.net Cc: bigmac@baylisa.org Subject: BayLISA: Upcoming meeting: Date: Thu, 18 Dec 1997 10:22:37 -0800 From: Bryan McDonald X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [Appologies if you did not see this before today, there was a lost messages someplace...bigmac.] The BayLISA group meets monthly to discuss topics of interest to systems and network administrators. The meetings are free and open to the public. Please feel free to redistribute this meeting announcement. BayLISA holds monthly meetings on the third Thursday of each month at 7:30 PM PST. We meet at Cisco Building J in San Jose, on Tasman Drive near First street. See www.baylisa.org for more information. The meetings are also broadcast via MBONE. Schedule ======== Thursday, 18 December, 1997, 7:30pm: Short but Cool This will be a collection of short (10-15 minute) talks about various "Cool" topics. Currently, the following talks are scheduled (in no particular order): The latest WebTV box -- Arnold deLeon DHCP -- Greg Kulosa Cisco's LocalDirector -- Hal Pomeranz OpenNT -- Steven Wally Mobile Code Security (Java, JavaScript, ActiveX, etc.) -- Todd A. Radermacher, Digitivity PalmPilots -- Kevin Hood (and perhaps others, but details are unavailable) [Schedule subject to change] For further information on BayLISA, check out our web site: http://www.baylisa.org/ To get further information on the meeting location, you can also ftp it from ftp.baylisa.org:/BayLISA/location For any other information, please send email to: info@baylisa.org If you have any questions, please contact me or the info alias listed above. =============================================================================== Bryan McDonald bigmac@baylisa.org BayLISA http://www.baylisa.org =============================================================================== From rem-conf Thu Dec 18 13:42:39 1997 From rem-conf-request@es.net Thu Dec 18 13:42:39 1997 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xinde-0005zz-00; Thu, 18 Dec 1997 13:37:50 -0800 Date: Thu, 18 Dec 1997 16:36:32 -0500 From: rodgers@nlm.nih.gov (R. P. C. Rodgers) Message-Id: <199712182136.QAA00515@billings.csb> To: rem-conf@es.net Subject: Danish robot soccer competition -- what happened? X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Or rather, what didn't happen? This was announced on sdr for 7-11 AM EST (US) but nothing was sent out on its three announced groups. Any idea what went wrong, or if it might be rebroadcasted? Sorry for posting this here, but the annoucements have disappeard and I cannot find mention of it in the mbone or rem-conf mail archives or my own mailbox... Thanks and Cheerio, Rick Rodgers (robotics enthusiast) From rem-conf Thu Dec 18 13:42:40 1997 From rem-conf-request@es.net Thu Dec 18 13:42:40 1997 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xinhd-00060x-00; Thu, 18 Dec 1997 13:41:57 -0800 Date: Thu, 18 Dec 1997 17:09:55 +0200 Message-Id: <97121817095491@ps.uib.es> From: scijmf@ps.uib.es (Pepe Manas Florit) To: END2END-INTEREST@isi.edu, IETF@isi.edu, F-TROUP@aurora.cis.upenn.edu, ICAD@santafe.edu, REM-CONF@es.net, TCCC@cs.umass.edu, FORTE94_CFP@admin.unibe.ch, COST237-WORKSHOP@comp.lancs.ac.uk, COST237-TRANSPORT@comp.lancs.ac.uk, OSIMCAST@bbn.com, SC6WG4@ntd.comsat.com, RERES@laas.fr, HIPPARCH@sophia.inria.fr, XTP-RELAY@cs.concordia.ca, CSWG%SUNOCO@relay.nswc.navy.mil, ATM-REQUEST@matmos.hpl.hp.com, UTF@cnri.reston.va.us Subject: TOOLS'98 X-VMS-To: @EXPLODE.TXT X-VMS-Cc: SCIJMF X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Call for Papers PERFORMANCE TOOLS'98 10th International Conference on Modelling Techniques and Tools for Computer Performance Evaluation Palma de Mallorca, Spain, September 14 - 18, 1998 Organiser: Universitat de les Illes Balears, Palma, Spain. http://www.uib.es/tools98 In cooperation with: ACM/Sigmetrics IFIP WG 6.3 IFIP WG 7.3 TOPICS PERFORMANCE and DEPENDABILITY ANALYSIS are key factors in the development and improvement of computer systems, centralised as well as distributed, and at all levels of computer networks. But quantitative system assessment will, however, only become standard practice if supported by widely applicable TECHNIQUES and easily usable TOOLS. This conference will be a meeting point where PERFORMANCE and DEPENDABILITY engineers, system builders and managers and tool designers have a common discussion forum. The conference will focus on - software tools for the specification and analysis of quantitative models; - measurement approaches and tools, with an emphasis on their combination with modelling options; - case studies of general interest showing the importance of quantitative analysis; - applications of measurement and modelling techniques and tools; - modelling paradigms and model analysis techniques for quantitative system assessment, with an emphasis on their broad applicability. Conference proceedings will be published by Springer Verlag in Lecture Notes in Computer Science series and will be available at the conference. PROGRAM COMMITTEE CHAIR Ramon PUIGJANER Universitat de les Illes Balears Departament de Ciencies Matematiques i Informatica Carretera de Valldemossa km 7.5 E-07071 PALMA, Spain Tel: +34 71 173288 Fax: +39 71 173003 Email: tools98@ps.uib.es PROGRAM COMMITTEE Gianfranco Balbo (Poltecnico di Torino, IT) Heinz Beilner (Universitaet Dortmund, DE) Maria Calzarosa (Universita di Pavia, IT) Adrian Conway (Racal, US) Larry Dowdy (Vanderbilt University, US) Guenter Haring (Universitaet Wien, AT) Peter Harrison (Imperial College, UK) Boudewijn Haverkort (RWTH Aachen, DE) Peter Hughes (Modicum, UK) Raj Jain (Ohio State University, US) Pieter Kritzinger (University of Capetown, ZA) Allen Malony (University of Oregon, US) Raymond Marie (IRISA, FR) Luisa Massari (Universita di Pavia, IT) Richard Muntz (UCLA, US) Ahmed Patel (University College Dublin, IE) Brigitte Plateau (IMAG, FR) Rob Pooley (University of Edinburgh, UK) Guy Pujolle (PRISM, FR) Daniel Reed (University of Illinois, US) Martin Reiser (GMD, CH) Gerardo Rubino (IRISA, FR) William Sanders (University of Illinois, US) Herb Schwetman (Mesquite, US) Giuseppe Serazzi (Politecnico di Milano, IT) Bartomeu Serra (Universitat de les Illes Balears, ES) Juan-Josi Serrano (Universitat Politecnica de Valencia, ES) Kenneth C. Sevcik (University of Toronto, CA) Connie Smith (Performance Engineering, US) Arne Solvberg (University of Trondheim, NO) Edmundo de Souza e Silva (Universidad Federal do Rio de Janeiro, BR) Otto Spaniol (RWTH Aachen, DE) William Stewart (North Carolina State University, US) Hideaki Takagi (University of Tsukuba, JA) Yutaka Takahashi (AIST Nara, JA) Satish Tripathi (University of California at Riverside, US) Kishor Trivedi (Duke University, US) INFORMATION FOR AUTHORS PAPERS. Submission should contain previously unpublished material and not exceed 20 double-spaced pages of 12 points font. Electronic submission is strongly encouraged via e-mail, as uuencoded PostScript (TM) files. Send it to the Program Committee Chair. For regular mail submission, send six copies of your paper to Ramon Puigjaner Tools'98 Universitat de les Illes Balears Ctra. de Valldemossa km 7.5 E-07071 PALMA (Spain) Every submission should be accompanied by a written undertaking by the authors that, if accepted, one of them will present the paper at the conference. Each accepted paper will be allocated up to ten pages (single spaced 10 points font) in the proceedings. The registration of at least one of the authors should accompany the camera-ready copy. Otherwise the paper will not be included in the conference proceedings. TOOLS. Presentations of analysis tools from both academia and industry are encouraged. Accepted submissions will be presented during a tool session. In addition, tool exhibit booths will be available throughout the duration of the conference. Each tool description will be allocated up to two pages in the proceedings. Submit your proposal to the Program Committee Chair (e-mail preferred), 2 pages length, before April 10. TUTORIALS. The conference will be accompanied by tutorials sessions devoted to basic aspects, new developments and major applications of quantitative techniques and tools. Submit your tutorial proposal to the Program Committee Chair (e-mail preferred) with the objectives and an outline, before April 10. MORE INFORMATION: see at http://www.uib.es/tools98 IMPORTANT DATES FOR PAPER SUBMISSIONS: FEBRUARY 15, 1998: deadline for submissions APRIL 30, 1998: notification of acceptance JUNE 15, 1998: camera-ready version due IMPORTANT DATE FOR TUTORIAL AND TOOL PRESENTATION PROPOSALS: APRIL 10, 1998: deadline for tutorial and tool presentation proposals APRIL 30, 1998: notification of acceptance JULY 31, 1998: tutorial material due ORGANISING COMMITTEE CHAIR Bartomeu SERRA Universitat de les Illes Balears Departament de Ciencies Matematiques i Informatica Carretera de Valldemossa km 7.5 E-07071 PALMA, Spain Tel: +34 71 173128 Fax: +34 71 173003 Email: tools98@ps.uib.es From rem-conf Fri Dec 26 20:21:13 1997 From rem-conf-request@es.net Fri Dec 26 20:21:12 1997 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xlnSx-0000tM-00; Fri, 26 Dec 1997 20:03:11 -0800 X-Authentication-Warning: bongo.comet.columbia.edu: xwang owned process doing -bs Date: Fri, 26 Dec 1997 23:03:07 -0500 (EST) From: Xin Wang To: rem-conf@es.net Subject: request Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list From rem-conf Sun Dec 28 01:08:50 1997 From rem-conf-request@es.net Sun Dec 28 01:08:48 1997 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xmEUH-0005yR-00; Sun, 28 Dec 1997 00:54:21 -0800 From: WhyNotSF Message-ID: <69ded94d.34a609b3@aol.com> Date: Sun, 28 Dec 1997 03:11:28 EST Subject: HOLOGRAPHIC UNIVERSE Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Organization: AOL (http://www.aol.com) X-Mailer: Inet_Mail_Out (IMOv11) Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list NEW YEARS GREETINGS TO THE WORLD from the UNIVERSITY OF GLOBAL EDUCATION UNITED NATIONS GENESIS II THE HOLOGRAPHIC UNIVERSE Objective Reality Exists in the Mind of the Observer. By changing ones point of reference we see the Phantom of the Dying Planet and the rebirth of the new. It began in 1982 when a remarkable event took place. At the University of Paris. A research team led by physicist Alain Aspect performed the most important experiment of the 20th century. We did not hear about it on the evening news, and unless you are in the habit of reading scientific journals you probably have never even heard Aspect's name. But for the "100 MONKEY's" who have undergone THE TRANSFORMATIVE EXPERIENCE, AA's work changed our former sense of reality from the old to the new world. Aspect and his team discovered that under certain circumstances subatomic particles such as electrons are able to instantaneously communicate with each other regardless of the distance separating them. It doesn't matter whether they are 10 feet or 10 billion miles apart. This is the REALITY OF ATLANTIS! In Atlantis each particle always seems to know what the other is doing. This feat violates Einstein's long-held tenet that no communication can travel faster than the speed of light. Since travelling faster than the speed of light is tantamount to breaking the time barrier... Ah So! A.A's findings inspired others to offer even more radical explanations. University of London physicist David Bohm, for example, believes Aspect's findings imply that objective reality does not exist, that despite its apparent solidity the universe is at heart a phantasm, a gigantic and splendidly detailed hologram. To understand why Bohm makes this startling assertion, one must first understand a little about holograms. A hologram is a three- dimensional photograph made with the aid of a laser. To make a hologram, the object to be photographed is first bathed in the light of a laser beam. Then a second laser beam is bounced off the reflected light of the first and the resulting interference pattern (the area where the two laser beams commingle) is captured on film. When the film is developed, it looks like a meaningless swirl of light and dark lines. But as soon as the developed film is illuminated by another laser beam, a three-dimensional image of the original object appears. (This principle reflects the Heironymous Machine used by ET at the Coe Hill Star Base, to change the ASSEMBLAGE POINT of the first "ATLANTEANS.") The three-dimensionality of such images is not the only remarkable characteristic of holograms. If a hologram of a rose is cut in half and then illuminated by a laser, each half will still be found to contain the entire image of the rose, like an implosive binary system. Indeed, even if the halves are divided again, each snippet of film will always be found to contain a smaller but intact version of the original image. Unlike normal photographs, every part of a hologram contains all the information possessed by the whole. The "whole in every part" of Nature hologram gave us an entirely new way of understanding COSMOS - Beauty and Order. For most of its history, Western science has laboured under the bias that the best way to understand a physical phenomenon, whether a frog or an atom, is to dissect it and study its respective parts; like kids talking Dad's watch apart and feeling very clever in so doing. A hologram teaches us that some things in the universe may not lend themselves to this approach. If we try to take apart something constructed holographically, we will not get the pieces of which it is made, we will only get smaller wholes, or BLACK HOLES in a single fabric, as we say in METAPHYSICS. This insight suggested to Bohm another way of understanding Aspect's discovery. Bohm believes the reason subatomic particles are able to remain in contact with one another regardless of the distance separating them is not because they are sending some sort of mysterious signal back and forth, but because their separateness is an illusion. He argues that at some deeper level of reality such particles are not individual entities, but are actually extensions of the same fundamental ONE THING - SOURCE. Locating SOURCE is like being blindfolded and folding a kaleidoscopic SPIDERWEB (7.12) into a silk parachute... as the COSMIC CUBE describes, in complete FAITH of the Holy Covenant (12.7) - see Entry Point 4.1. Bohm offers the following illustration. Imagine an aquarium containing a fish. Imagine also that you are unable to see the aquarium directly and your knowledge about it and what it contains comes from two television cameras, one directed at the aquarium's front and the other directed at its side. As you stare at the two television monitors, you might assume that the fish on each of the screens are separate entities. After all, because the cameras are set at different angles, each of the images will be slightly different. But as you continue to watch the two fish, you will eventually become aware that there is a certain relationship between them. When one turns, the other also makes a slightly different but corresponding turn; when one faces the front, the other always faces toward the side. If you remain unaware of the full scope of the situation, you might even conclude that the fish must be instantaneously communicating with one another, but this is clearly not the case. This is precisely what is going on between the subatomic particles in Aspect's experiment, according to Bohm. The apparent faster-than-light connection between subatomic particles is really telling us that there is a deeper level of reality we man is not privy to; a more complex dimension beyond our own that is analogous to the aquarium. Bohm adds, we view objects such as subatomic particles as separate from one another because we are seeing only a portion of their reality. Such particles are not separate "parts", but facets of a deeper and more underlying unity that is ultimately as holographic and indivisible as the previously mentioned rose. And since everything in physical reality is comprised of these "engrams", the universe is itself a projection, a hologram. In addition to its phantomlike nature, such a universe would possess other rather startling features. If the apparent separateness of subatomic particles is illusory, it means that at a deeper level of reality all things in the universe are infinitely interconnected as a UNIFIED FIELD FORCE (+1)+(-1) = 0. The electrons in a carbon atom in the human brain are connected to the subatomic particles that comprise every salmon that swims, every heart that beats, and every star that shimmers in the sky. Which is why Santa Claus comes "down the chimney." Everything interpenetrates everything, and although human nature may seek to categorize and pigeonhole and subdivide, the various phenomena of the universe, all apportionments are of necessity artificial and all of nature is ultimately a seamless web. (Circuit 7.12/12.8) The Holographic Universe exists in IT: INFINITE TIME. The time space continuum is no longer fundamental. The Cyberspace Concept congeals the Holographic Universe in which nothing is truly separate from anything else. Time and three-dimensional space, like the images of the fish on the TV monitors, are viewed as projections of this deeper order. PROFOUND REALITY is a sort of Superhologram in which the past, present, and future all exist simultaneously. The Person who has prepared themselves can REACH into the superholographic level of reality today - TODAY - HALLELUJAH! AMEN! We have plucked out scenes from the long-forgotten past. The Superhologram is open-ended question. 4.4 - 5.5 - 6.6. The Superhologram is the MATRIX - THE MOTHER GODDESS - GAIA-GALAXIA that has given birth to everything in our universe. This was explained in the MOTHERSHIP COMMUNIQUES of Christmas 1983. IT contains every subatomic particle that has been or will be -- every configuration of matter and energy that is possible, from snowflakes to quasars, from blue whales to gamma rays. IT is THE COSMIC CUBE - THE CRYSTAL OF ATLANTIS - The Cosmic Storehouse of "All That Is" - 4.1 is "Heaven's Gate." What lies hidden in the SUPERHOLGRAM? IT contains MORE!! of everything that is GOOD for Consciousness. The 13th Plane from which we first viewed the SUPERHOLGRAM is a "mere stage" beyond which lies an infinity of further development in THE UNITED NATIONS SOLUTION - GENESIS II. Working independently in the field of brain research, as "I*AM THE BOOK OF LIFE" (1978) explains, Dr. Wilder Penfield, the famous Canadian Neurologist said in an interview that you will find that life has prepared you for something much greater and more glorious than the human imagination can conceive. He understood the holographic nature of reality as a result of human brain surgery. Penfield was intrigued by the riddle of how and where memories are stored in the brain. His studies showed that rather than being confined to a specific location, memories are dispersed throughout the brain. In a series of landmark experiments in the 1920s, brain scientist Karl Lashley found that no matter what portion of a rat's brain he removed he was unable to eradicate its memory of how to perform complex tasks it had learned prior to surgery. The only problem was that no one was able to come up with a mechanism that might explain this curious "whole in every part" nature of memory storage. The concept of holography explains both AK-KA-BA in the Egyptian Cosmic Thesis and MER-KA-BA vehicles in the UFO Community. For THE MOTHERSHIP - is composed of a whole Fleet of Galactic Warriors from all dimensions, as memories, encoded not in neurons, or small groupings of neurons, become patterns of a SINGLE NERVE IMPULSE that crisscross ITS ENTIRE MIND in the same way that patterns of laser light interference crisscross the entire area of a piece of film containing a holographic image. THE HUMAN BRAIN is ITSELF a HOLOGRAM drawn from the TREE OF LIFE. It has been estimated that the human brain has the capacity to memorize something on the order of 10 billion bits of information during the average human lifetime (or roughly the same amount of information contained in five sets of the Encyclopedia Britannica). Some people use less that 5% of its total capacity. For in addition to their other capabilities, holograms possess an astounding capacity for information storage--simply by changing the angle at which the two lasers strike a piece of photographic film, it is possible to record many different images on the same surface. It has been demonstrated that one cubic centimetre of film can hold as many as 10 billion bits of information. The human ability to retrieve needed information from the enormous store of our memories becomes more understandable if the brain functions according to holographic principles. THE COSMIC CUBE (Circuit 11.8/8.11) allows the human thinking process to instantly cross-correlated pieces of timeless information. Because every portion of THE CRYSTAL OF ATLANTIS is infinitely interconnected with every other portion, in Nature's Supreme Example of a cross-correlated system. The brain is able to translate the avalanche of frequencies it receives via the senses (light frequencies, sound frequencies, and so on) into the concrete world of our perceptual assemblage point. WE HAVE CROSSED THE RAINBOW BRIDGE! An impressive body of evidence suggests that the brain uses holographic principles to perform its operations. Encoding and decoding frequencies is it does best. It functions as a MOON LENS - the translating device able to convert a meaningless blur of frequencies into a coherent, FLAWLESS REFLECTIVE IMAGE. Circuit 4.9 DIGITAL allows us to convert this image into "hard reality" by mathematically converting the input received through the Cube Senses. This process is now underway. Argentinean-Italian researcher Hugo Zucarelli recently extended the holographic model into the world of acoustic phenomena. Puzzled by the fact that humans can locate the source of sounds without moving their heads, even if they only possess hearing in one ear, Zucarelli discovered that holographic principles can explain this ability. Zucarelli has also developed the technology of holophonic sound, a recording technique able to reproduce acoustic situations with an almost uncanny realism. It has been found that each of our senses is sensitive to a much broader range of frequencies than was previously suspected. Researchers have discovered, that our visual systems are sensitive to sound frequencies, that our sense of smell is in part dependent on what are now called "osmic frequencies." Each molecular cell in our bodies is sensitive to a broad range of frequencies. Only in the holographic domain of consciousness can such frequencies be sorted out and divided into conventional perceptions. THE UNIVERSITY OF GLOBAL EDUCATION of the UNITED NATIONS GENESIS II PROGRAM - explains how the concreteness of the "TITANIC WORLD" a secondary reality. Matter is actually a holographic blur of frequencies; The human brain is also a hologram. It selects some of the frequencies out of this blur and mathematically transforms them into sensory perceptions. Objective reality then ceases to exist. Eastern Religions have long upheld, the material world is Maya, an illusion. People may think they are physical beings moving through a physical world, but this is an illusion. We are "receivers" floating through a kaleidoscopic sea of frequency, and what we extract from this sea while transmigrating into physical reality. This striking new picture of reality is the METAPHYSICAL VIEWPOINT, (3.2/2.3). It was galvanized a small Ecclesia who matrixed the most accurate model of reality to solve the Luciferin Mystery. All paranormal and channelling phenomena make sense in terms of the holographic paradigm, as do the most ancient pagan practices. In a universe in which individual brains are indivisible portions of the greater hologram and everything is infinitely interconnected, BREAKING OUT OF THE EGG SHELL, is how we access of the Holographic Universe. Information can travel from the mind of individual 'A' to that of individual'B' at a far distance point and helps to understand a number of unsolved puzzles. It explains the baffling phenomena of UFO ABDUCTEES and altered states of consciousness. In LSD research in the 1950s, one woman suddenly became convinced she had assumed the identity of a female of a species of prehistoric reptile. During the course of her hallucination, she not only gave a richly detailed description of what it felt like to be encapsuled in such a form, but noted that the portion of the male of the species's anatomy was a patch of coloured scales on the side of its head. The woman had no prior knowledge about such things, but a zoologist confirmed that in certain species of reptiles coloured areas on the head do indeed play an important role as triggers of sexual arousal. TOTEMIC ANIMALS are the Big Players in the Nature Holograph. Memory regression reveals that people identify with virtually every species on the evolutionary tree. Such experiences frequently contained obscure zoological details which turn out accurate. Regressions revealed that patients tapped into the collective racial unconscious. Individuals with little or no education suddenly gave detailed descriptions of how to build Star Ships - such as David Hamel of Gilmour, On. who tapped into the mindstream of RAMSES II...his apparent past-life incarnations. The common element in such experiences was the transcending of an individual's consciousness beyond the usual ego boundaries. Limitations of space and time become insignificant. Mind is part of THE UNIVERSAL CONTINUUM. We can exit the labyrinth back to source through any cubit circuit. THE COSMIC CUBE is connected to every other mind that exists or has existed; to every atom, organism, and region in the vastness of space and time itself. The Cube is used as a vehicle when IT makes occasional forays into the labyrinth to 9.1 Harvest the fruit of the TREE OF LIFE. THE RED QUEEN reflects holographic implications for hard sciences like biology. Keith Floyd, a psychologist at Virginia Intermont College, points out that if the concreteness of reality is but a holographic illusion, it is no longer be true to say the brain produces consciousness. Rather, it is consciousness that creates the appearance of the brain, as well as the body and everything else around us we interpret as physical. ....."Faster, faster little feet. We passed it ten minutes ago - faster! FASTER!!! Such a turnabout in the way we view biological structures, flips our understanding of the healing process, as in 2.11/11.2 the holographic paradigm. The physical structure of the body is a holographic projection of consciousness. We are each much more responsible for our health than current medical wisdom allows. What was viewed as miraculous remissions of disease may be due to changes in consciousness which in turn effect changes in the hologram of the body. New healing work well because in the holographic domain of thought images are ultimately as real as "reality". Many Visions and "extra-ordinary" events - like the death of Princess Dianne, or the curse of Grimaldi, are explainable under the holographic paradigm. In his book "Gifts of Unknown Things," biologist Lyall Watson describes his encounter with an Indonesian shaman woman who, by performing a ritual dance, was able to make an entire grove of trees instantly vanish into thin air. Watson relates that as he and another astonished onlooker continued to watch the woman, she caused the trees to reappear, then "click" off again and on again several times in succession. METAPHYSICS is fully capable of creating such an event on a PLANETARY SCALE - IT HAS ALREADY HAPPENED!! - It happened for me in September 1973. Since then "hard" reality is only a projection. For a full decade, we learned about what is "there" or "not there." We saw how consensus reality is formulated and ratified at the level of the human unconscious at which all minds are infinitely interconnected the MORTAL ASSEMBLAGE POINT . Experiences such as Watson's came because his beliefs did not preclude them. In a holographic universe there are no limits to the extent to which we can alter the fabric of reality. What we perceive as reality is the canvas of GENESIS II waiting for us to draw upon it any picture we want. Anything is possible, >from bending spoons with the power of the mind to the phantasmagoric events experienced by Castaneda during his encounters with the Yaqui brujo don Juan, for magic is our birthright, no more or less miraculous than our ability to compute the reality we want when we are in our dreams. In a holographic universe, random events are noted as MCE; mean chance expectation. Synchronicities or meaningful coincidences make sense. Everything in reality is metaphoric, MCE proves that even the most haphazard events express an underlying symmetry. Instantaneous CHRIST MASS COMMUNICATIONS are now passing back and forth between subatomic particles in this new REALITY, as Choirs of Angels sing. "PEACE ON EARTH - GOODWILL TO MEN..." HALLELUJAH! - AMEN! From rem-conf Mon Dec 29 01:32:39 1997 From rem-conf-request@es.net Mon Dec 29 01:32:38 1997 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xmbGu-0003WZ-00; Mon, 29 Dec 1997 01:14:04 -0800 Message-ID: <34A76811.E92772A4@KEGO.COM> Date: Mon, 29 Dec 1997 01:06:25 -0800 From: Cameron Elliott Organization: KEGO - Software & Datacommunications X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net CC: czhu@ideal.jf.intel.com Subject: H.263 & RFC2190 issue Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I'm kind of stumped here, I'm attempting to write a RFC2190 compliant encapsulator, and I have an issue I don't know how to address. Basically, how does an encoder decide when to generate the GOB headers without generating them for every GOB? I need to know the length of the current GOB to determine whether it can fit in the remaining space for the current RTP packet. (MTU) But! to generate the current GOB, I need to know in advance whether I'm going to generate a GOB header, because section 6.1.1 of H.263 is affected by whether or not this GOB is going to be generated with a header or not. So, my choices appear to be: A. Generate all GOBs with the header, and live with the overhead. B. Generate all GOBs without the header, and if the resulting GOB doesn't fit within the remaining space of the RTP packet, regenerate it with the header for the next packet. I'm wondering if I'm missing some option here, anyone who is familiar with RFC2190, please help me out. Thanks Cameron Elliott -- Cameron Elliott Kego - Software & Datacommuncations Unix, Embedded Software, TCP/IP, H.323 888-FOR-KEGO Cam@Kego.com From rem-conf Mon Dec 29 09:27:01 1997 From rem-conf-request@es.net Mon Dec 29 09:27:01 1997 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xmihC-0005gf-00; Mon, 29 Dec 1997 09:09:42 -0800 Message-Id: <199712291709.MAA17260@ns.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 MPEG1/MPEG2 Video to Proposed Standard Date: Mon, 29 Dec 1997 12:09:38 -0500 Sender: scoya@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 MPEG1/MPEG2 Video' as a Proposed Standard. This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Allyn Romanow and Scott Bradner. Technical Summary This memo is a revision of RFC 2038, an Internet standards track protocol, prepared for publication as a revised RFC to cycle-in-grade at Proposed Standard. In this revision, the packet loss resilience mechanisms in Section 3.4 were extended to include additional picture header information required for MPEG2. The existing RFC 2038 implies that the mechanisms described therein are suitable for both MPEG1 and MPEG2 when in fact they are insufficient for MPEG2. In addition a new section in included on on security considerations for this payload type. Working Group Summary R. Civanlar is the author of this revision; the revision was reviewed by the other three authors (the authors of RFC 2038) and by the AVT Chair. This revision was presented to the working group in Memphis and in a working group last call. It was accepted without controversy. Protocol Quality This document has been reviewed for the IESG by Allyn Romanow. Precept has an implementation of the encapsulation of MPEG Elemenary Streams for MPEG1 (section 3). AT&T has an implementation of the new extensions for MPEG2 Elementary Streams (section 2). There are experimental implementations from Sun of MPEG transport and Program Streams (section 2). From rem-conf Mon Dec 29 10:34:08 1997 From rem-conf-request@es.net Mon Dec 29 10:34:08 1997 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xmjul-0006Vw-00; Mon, 29 Dec 1997 10:27:47 -0800 Message-Id: <3.0.32.19971229102247.00927100@mailhost> X-Sender: jose@mailhost X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 29 Dec 1997 10:22:57 -0800 To: WhyNotSF , rem-conf@es.net From: Jose Rodriguez Subject: Re: HOLOGRAPHIC UNIVERSE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please don't put this material in this session again At 03:11 AM 12/28/97 EST, WhyNotSF wrote: > NEW YEARS GREETINGS TO THE WORLD > > from the > > UNIVERSITY OF GLOBAL EDUCATION > > UNITED NATIONS GENESIS II > > THE HOLOGRAPHIC UNIVERSE > > >Objective Reality Exists in the Mind of the Observer. By changing ones >point of reference we see the Phantom of the Dying Planet and the >rebirth of the new. > >It began in 1982 when a remarkable event took place. At the University >of Paris. A research team led by physicist Alain Aspect performed the >most important experiment of the 20th century. We did not hear about it >on the evening news, and unless you are in the habit of reading >scientific journals you probably have never even heard Aspect's name. > >But for the "100 MONKEY's" who have undergone THE TRANSFORMATIVE >EXPERIENCE, AA's work changed our former sense of reality from the old >to the new world. Aspect and his team discovered that under certain >circumstances subatomic particles such as electrons are able to >instantaneously communicate with each other regardless of the distance >separating them. It doesn't matter whether they are 10 feet or 10 >billion miles apart. This is the REALITY OF ATLANTIS! > >In Atlantis each particle always seems to know what the other is >doing. This feat violates Einstein's long-held tenet that no >communication can travel faster than the speed of light. Since >travelling faster than the speed of light is tantamount to breaking the >time barrier... Ah So! > >A.A's findings inspired others to offer even more radical explanations. >University of London physicist David Bohm, for example, believes >Aspect's findings imply that objective reality does not exist, that >despite its apparent solidity the universe is at heart a phantasm, a >gigantic and splendidly detailed hologram. > >To understand why Bohm makes this startling assertion, one >must first understand a little about holograms. A hologram is >a three- dimensional photograph made with the aid of a laser. >To make a hologram, the object to be photographed is first >bathed in the light of a laser beam. Then a second laser beam >is bounced off the reflected light of the first and the resulting >interference pattern (the area where the two laser beams commingle) is >captured on film. > >When the film is developed, it looks like a meaningless swirl >of light and dark lines. But as soon as the developed film is >illuminated by another laser beam, a three-dimensional image >of the original object appears. (This principle reflects the Heironymous >Machine used by ET at the Coe Hill Star Base, to change the ASSEMBLAGE >POINT of the first "ATLANTEANS.") > >The three-dimensionality of such images is not the only >remarkable characteristic of holograms. If a hologram of a >rose is cut in half and then illuminated by a laser, each >half will still be found to contain the entire image of the >rose, like an implosive binary system. > >Indeed, even if the halves are divided again, each snippet of >film will always be found to contain a smaller but intact >version of the original image. Unlike normal photographs, every >part of a hologram contains all the information possessed by >the whole. > >The "whole in every part" of Nature hologram gave us an entirely new way >of understanding COSMOS - Beauty and Order. For most of its history, >Western science has laboured under the bias that the best way to >understand a physical phenomenon, whether a frog or an atom, is to >dissect it and study its respective parts; like kids talking Dad's watch >apart and feeling very clever in so doing. > >A hologram teaches us that some things in the universe may >not lend themselves to this approach. If we try to take apart >something constructed holographically, we will not get the >pieces of which it is made, we will only get smaller wholes, or BLACK >HOLES in a single fabric, as we say in METAPHYSICS. > >This insight suggested to Bohm another way of understanding >Aspect's discovery. Bohm believes the reason subatomic >particles are able to remain in contact with one another >regardless of the distance separating them is not because >they are sending some sort of mysterious signal back and >forth, but because their separateness is an illusion. He >argues that at some deeper level of reality such particles >are not individual entities, but are actually extensions of >the same fundamental ONE THING - SOURCE. > >Locating SOURCE is like being blindfolded and folding a kaleidoscopic >SPIDERWEB (7.12) into a silk parachute... as the COSMIC CUBE describes, >in complete FAITH of the Holy Covenant (12.7) - see Entry Point 4.1. > >Bohm offers the following illustration. Imagine an aquarium containing a >fish. Imagine also that you are unable to see the aquarium directly and >your knowledge about it and what it contains comes from two television >cameras, one directed at the aquarium's front and the other directed at >its side. > >As you stare at the two television monitors, you might assume >that the fish on each of the screens are separate entities. >After all, because the cameras are set at different angles, >each of the images will be slightly different. But as you >continue to watch the two fish, you will eventually become >aware that there is a certain relationship between them. > >When one turns, the other also makes a slightly different but >corresponding turn; when one faces the front, the other >always faces toward the side. If you remain unaware of the >full scope of the situation, you might even conclude that the >fish must be instantaneously communicating with one another, >but this is clearly not the case. > >This is precisely what is going on between the subatomic particles in >Aspect's experiment, according to Bohm. The apparent faster-than-light >connection between subatomic particles is really telling us that there >is a deeper level of reality we man is not privy to; a more complex >dimension beyond our own that is analogous to the aquarium. Bohm adds, >we view objects such as subatomic particles as separate from one >another because we are seeing only a portion of their reality. > >Such particles are not separate "parts", but facets of a >deeper and more underlying unity that is ultimately as holographic and >indivisible as the previously mentioned rose. And since everything in >physical reality is comprised of these "engrams", the universe is itself >a projection, a hologram. > >In addition to its phantomlike nature, such a universe would >possess other rather startling features. If the apparent >separateness of subatomic particles is illusory, it means that at a >deeper level of reality all things in the universe are infinitely >interconnected as a UNIFIED FIELD FORCE (+1)+(-1) = 0. > >The electrons in a carbon atom in the human brain are connected to the >subatomic particles that comprise every salmon that swims, every heart >that beats, and every star that shimmers in the sky. Which is why Santa >Claus comes "down the chimney." > >Everything interpenetrates everything, and although human nature may >seek to categorize and pigeonhole and subdivide, the various phenomena >of the universe, all apportionments are of necessity artificial and all >of nature is ultimately a seamless web. (Circuit 7.12/12.8) > >The Holographic Universe exists in IT: INFINITE TIME. The time space >continuum is no longer fundamental. The Cyberspace Concept congeals the >Holographic Universe in which nothing is truly >separate from anything else. Time and three-dimensional space, like the >images of the fish on the TV monitors, are viewed as projections of >this deeper order. > >PROFOUND REALITY is a sort of Superhologram in which the past, present, >and future all exist simultaneously. The Person who has prepared >themselves can REACH into the superholographic level of >reality today - TODAY - HALLELUJAH! AMEN! > >We have plucked out scenes from the long-forgotten past. >The Superhologram is open-ended question. 4.4 - 5.5 - 6.6. The >Superhologram is the MATRIX - THE MOTHER GODDESS - GAIA-GALAXIA >that has given birth to everything in our universe. This was explained >in the MOTHERSHIP COMMUNIQUES of Christmas 1983. > >IT contains every subatomic particle that has been or will be -- every >configuration of matter and energy that is possible, from >snowflakes to quasars, from blue whales to gamma rays. IT is THE COSMIC >CUBE - THE CRYSTAL OF ATLANTIS - The Cosmic Storehouse of "All That Is" >- 4.1 is "Heaven's Gate." > >What lies hidden in the SUPERHOLGRAM? IT contains MORE!! of everything >that is GOOD for Consciousness. The 13th Plane from which we first >viewed the SUPERHOLGRAM is a "mere stage" beyond which lies an infinity >of further development in THE UNITED NATIONS SOLUTION - GENESIS II. > >Working independently in the field of brain research, as "I*AM THE BOOK >OF LIFE" (1978) explains, Dr. Wilder Penfield, the famous Canadian >Neurologist said in an interview that you will find that life has >prepared you for something much greater and more glorious than the human >imagination can conceive. He understood the holographic nature of >reality as a result of human brain surgery. > >Penfield was intrigued by the riddle of how and where memories are >stored in the brain. His studies showed that rather than being confined >to a specific location, memories are dispersed throughout the brain. > >In a series of landmark experiments in the 1920s, brain >scientist Karl Lashley found that no matter what portion of a >rat's brain he removed he was unable to eradicate its memory >of how to perform complex tasks it had learned prior to >surgery. The only problem was that no one was able to come up >with a mechanism that might explain this curious "whole in >every part" nature of memory storage. > >The concept of holography explains both AK-KA-BA in the Egyptian Cosmic >Thesis and MER-KA-BA vehicles in the UFO Community. For THE MOTHERSHIP - >is composed of a whole Fleet of Galactic Warriors from all dimensions, >as memories, encoded not in neurons, or small groupings of neurons, >become patterns of a SINGLE NERVE IMPULSE >that crisscross ITS ENTIRE MIND in the same way that patterns of laser >light interference crisscross the entire area of a piece of film >containing a holographic image. THE HUMAN BRAIN is ITSELF a HOLOGRAM >drawn from the TREE OF LIFE. > >It has been estimated that the human brain has the capacity to memorize >something on the order of 10 billion bits of information during the >average human lifetime (or roughly the same amount of >information contained in five sets of the Encyclopedia >Britannica). Some people use less that 5% of its total capacity. > >For in addition to their other capabilities, holograms possess an >astounding capacity for information storage--simply by changing the >angle at which the two lasers strike a piece of photographic film, it is >possible to record many different images on the same >surface. It has been demonstrated that one cubic centimetre >of film can hold as many as 10 billion bits of information. > >The human ability to retrieve needed information from the enormous store >of our memories becomes more understandable if the brain functions >according to holographic principles. THE COSMIC CUBE (Circuit 11.8/8.11) >allows the human thinking process to instantly cross-correlated pieces >of timeless information. Because every portion of THE CRYSTAL OF >ATLANTIS is infinitely interconnected with every other portion, in >Nature's Supreme Example of a cross-correlated system. > >The brain is able to translate the avalanche of frequencies it receives >via the senses (light frequencies, sound frequencies, and so on) into >the concrete world of our perceptual assemblage point. >WE HAVE CROSSED THE RAINBOW BRIDGE! > >An impressive body of evidence suggests that the brain uses holographic >principles to perform its operations. Encoding and decoding frequencies >is it does best. It functions as a MOON LENS - the translating device >able to convert a meaningless blur of frequencies into a coherent, >FLAWLESS REFLECTIVE IMAGE. Circuit 4.9 DIGITAL allows us to convert this >image into "hard reality" by mathematically converting the input >received through the Cube Senses. This process is now underway. > >Argentinean-Italian researcher Hugo Zucarelli recently >extended the holographic model into the world of acoustic >phenomena. Puzzled by the fact that humans can locate the >source of sounds without moving their heads, even if they >only possess hearing in one ear, Zucarelli discovered that >holographic principles can explain this ability. > >Zucarelli has also developed the technology of holophonic >sound, a recording technique able to reproduce acoustic >situations with an almost uncanny realism. > >It has been found that each of our senses is sensitive to a >much broader range of frequencies than was previously suspected. >Researchers have discovered, that our visual systems are sensitive to >sound frequencies, that our sense of smell is in part dependent on what >are now called "osmic frequencies." Each molecular cell in our bodies is >sensitive to a broad range of frequencies. Only in the holographic >domain of consciousness can such frequencies be sorted out and divided >into conventional perceptions. > >THE UNIVERSITY OF GLOBAL EDUCATION of the UNITED NATIONS GENESIS II >PROGRAM - explains how the concreteness of the "TITANIC WORLD" a >secondary reality. Matter is actually a holographic blur of frequencies; >The human brain is also a hologram. It selects some of the frequencies >out of this blur and mathematically transforms them into sensory >perceptions. Objective reality then ceases to exist. > >Eastern Religions have long upheld, the material world is Maya, an >illusion. People may think they are physical beings moving through a >physical world, but this is an illusion. We are "receivers" floating >through a kaleidoscopic sea of frequency, and what we extract from this >sea while transmigrating into physical reality. > >This striking new picture of reality is the METAPHYSICAL VIEWPOINT, >(3.2/2.3). It was galvanized a small Ecclesia who matrixed the most >accurate model of reality to solve the Luciferin Mystery. All paranormal >and channelling phenomena make sense in terms of the holographic >paradigm, as do the most ancient pagan practices. > >In a universe in which individual brains are indivisible portions of the >greater hologram and everything is infinitely interconnected, BREAKING >OUT OF THE EGG SHELL, is how we access of the Holographic Universe. > >Information can travel from the mind of individual 'A' to that of >individual'B' at a far distance point and helps to understand a number >of unsolved puzzles. It explains the baffling phenomena of UFO ABDUCTEES >and altered states of consciousness. > >In LSD research in the 1950s, one woman suddenly became convinced she >had assumed the identity of a female of a species of prehistoric >reptile. During the course of her hallucination, she not only gave a >richly detailed description of what it felt like to be encapsuled in >such a form, but noted that the portion of the male of the species's >anatomy was a patch of coloured scales on the side of its head. The >woman had no prior knowledge about such things, but a zoologist >confirmed that in certain species of reptiles coloured areas on the head >do indeed play an important role as triggers of sexual arousal. > >TOTEMIC ANIMALS are the Big Players in the Nature Holograph. Memory >regression reveals that people identify with virtually every species on >the evolutionary tree. Such experiences frequently >contained obscure zoological details which turn out accurate. > >Regressions revealed that patients tapped into the collective >racial unconscious. Individuals with little or no education suddenly >gave detailed descriptions of how to build Star Ships - such as David >Hamel of Gilmour, On. who tapped into the mindstream of RAMSES II...his >apparent past-life incarnations. The common element in such experiences >was the transcending of an individual's >consciousness beyond the usual ego boundaries. Limitations of space and >time become insignificant. > >Mind is part of THE UNIVERSAL CONTINUUM. We can exit the labyrinth back >to source through any cubit circuit. THE COSMIC CUBE is connected to >every other mind that exists or has existed; to every atom, organism, >and region in the vastness of space and time itself. The Cube is used as >a vehicle when IT makes occasional forays into the labyrinth to 9.1 >Harvest the fruit of the TREE OF LIFE. > >THE RED QUEEN reflects holographic implications for hard sciences like >biology. Keith Floyd, a psychologist at Virginia Intermont College, >points out that if the concreteness of reality is but a holographic >illusion, it is no longer be true to say the brain produces >consciousness. Rather, it is consciousness that creates the appearance >of the brain, as well as the body and everything else around us we >interpret as physical. > >....."Faster, faster little feet. We passed it ten minutes ago - faster! >FASTER!!! > >Such a turnabout in the way we view biological structures, flips our >understanding of the healing process, as in 2.11/11.2 the holographic >paradigm. The physical structure of the body is a holographic projection >of consciousness. We are each much more responsible for our health than >current medical wisdom allows. What was viewed as miraculous remissions >of disease may be due to changes in consciousness which in turn effect >changes in the hologram of the body. New healing work well because in >the holographic domain of thought images are ultimately as real as >"reality". > >Many Visions and "extra-ordinary" events - like the death of Princess >Dianne, or the curse of Grimaldi, are explainable under the holographic >paradigm. In his book "Gifts of Unknown Things," biologist Lyall Watson >describes his encounter with an Indonesian shaman woman who, by >performing a ritual dance, was able to make an entire grove of trees >instantly vanish into thin air. Watson relates that as he and another >astonished onlooker continued to watch the woman, she caused the trees >to reappear, then "click" off again and on again several times in >succession. > >METAPHYSICS is fully capable of creating such an event on a >PLANETARY SCALE - IT HAS ALREADY HAPPENED!! - It happened for me in >September 1973. Since then "hard" reality is only a projection. > >For a full decade, we learned about what is "there" or "not there." We >saw how consensus reality is formulated and ratified at the level of the >human unconscious at which all minds are >infinitely interconnected the MORTAL ASSEMBLAGE POINT . > >Experiences such as Watson's came because his beliefs did not preclude >them. In a holographic universe there are no limits to the >extent to which we can alter the fabric of reality. > >What we perceive as reality is the canvas of GENESIS II waiting for us >to draw upon it any picture we want. Anything is possible, >from bending spoons with the power of the mind to the phantasmagoric >events experienced by Castaneda during his encounters with the Yaqui >brujo don Juan, for magic is our >birthright, no more or less miraculous than our ability to >compute the reality we want when we are in our dreams. > >In a holographic universe, random events are noted as MCE; mean chance >expectation. Synchronicities or meaningful coincidences make sense. >Everything in reality is metaphoric, MCE proves that even the most >haphazard events express an underlying symmetry. >Instantaneous CHRIST MASS COMMUNICATIONS are now passing back and forth >between subatomic particles in this new REALITY, as Choirs of Angels >sing. > >"PEACE ON EARTH - GOODWILL TO MEN..." HALLELUJAH! - AMEN! > > > > From rem-conf Mon Dec 29 12:24:06 1997 From rem-conf-request@es.net Mon Dec 29 12:24:06 1997 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xmlfc-0007Xe-00; Mon, 29 Dec 1997 12:20:16 -0800 Message-ID: <3D33CF40366DD111AC4100A0C96B22AC2329DF@FMSMSX34> From: "Zhu, Chad" To: "'rem-conf@es.net'" Subject: RE: H.263 & RFC2190 issue Date: Mon, 29 Dec 1997 12:19:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > I have not found a optimum solution to this problem either. But my > colleague and I have worked a simple solution that you might find > helpful: > > 1. Set up a flag for a GOB, indicating whether the gob starts with a > GOB header. Default is no when starting a new gob. > 2. After encoding each Macroblock, make a decision about whether to > start the MB in a new packet, if yes and the gob did not start with a > gob header, and the current MB happens to be the first MB in the gob, > re-encode the MB and add a GOB header. Change the flag according. A > mode A packet will be generated, otherwise, generate mode B packet by > default. > > You can also add a twist to this algorithm by using heuristics based > on buffer length and current MB position. I am sure there are better > algorithms to handle this, the question is whether it is worth the > effort. > > Hope this helps. > > --Chad > > > > > -----Original Message----- > From: Cameron Elliott [SMTP:cam@elliott.net] > Sent: Monday, December 29, 1997 1:06 AM > To: rem-conf@es.net > Cc: czhu@mailbox.jf.intel.com > Subject: H.263 & RFC2190 issue > > I'm kind of stumped here, > > I'm attempting to write a RFC2190 compliant encapsulator, > and I have an issue I don't know how to address. > > Basically, how does an encoder decide when to generate > the GOB headers without generating them for every GOB? > > I need to know the length of the current GOB to determine > whether it can fit in the remaining space for the current > RTP packet. (MTU) > But! to generate the current GOB, I need to know in advance > whether I'm going to generate a GOB header, because section > 6.1.1 of H.263 is affected by whether or not this GOB is > going to be generated with a header or not. > > So, my choices appear to be: > A. Generate all GOBs with the header, and live with the overhead. > B. Generate all GOBs without the header, and if the resulting GOB > doesn't fit within the remaining space of the RTP packet, regenerate > it with the header for the next packet. > > I'm wondering if I'm missing some option here, > anyone who is familiar with RFC2190, please help me out. > > Thanks > Cameron Elliott > > > > > > -- > Cameron Elliott > > Kego - Software & Datacommuncations > Unix, Embedded Software, TCP/IP, H.323 > > 888-FOR-KEGO > Cam@Kego.com From rem-conf Mon Dec 29 13:03:18 1997 From rem-conf-request@es.net Mon Dec 29 13:03:18 1997 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xmmJ7-0000VW-00; Mon, 29 Dec 1997 13:01:05 -0800 Sender: strayer@bbn.com Message-ID: <34A80F5A.1A770E1A@bbn.com> Date: Mon, 29 Dec 1997 16:00:10 -0500 From: Tim Strayer Organization: BBN Technologies X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: xtp-relay@cs.concordia.ca, end2end-interest@isi.edu, tccc@ieee.org, enternet@bbn.com, apc@eee.nthu.edu.tw, dbword@cs.wisc.edu, f-troup@codex.cis.upenn.edu, g-troup@ccrc.wustl.edu, hipparch@sophia.inria.fr, cost237-transport@comp.lancs.a, reres@laas.fr, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@tadpole.com, ieeetcpc@ccvm.sunysb.edu, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, multicomm@cc.bellcore.com, activenets_all@ittc.ukansas.edu, fokus-users@fokus.gmd.de, arpanet-bboard@mc.lcs.mit.edu, cabernet-events@ncl.ac.uk, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, ieee.announce@bellcore.com, osimcast@bbn.com, cif@injector.ca.sandia.gov Subject: CFP: LCN'98 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms38D974A1403B43B9A56CF74F" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a cryptographically signed message in MIME format. --------------ms38D974A1403B43B9A56CF74F Content-Type: multipart/mixed; boundary="------------0CD637DBB690FC16845CDF0A" This is a multi-part message in MIME format. --------------0CD637DBB690FC16845CDF0A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attached is the Call For Papers for LCN'98, apologies for multiple receipts of this CFP. The URL for LCN'98 is http://www.hill.com/lcn Best Regards, -Tim Strayer Program Chair, LCN'98 -- Tim Strayer BBN Technologies strayer@bbn.com 617/873-2295 --------------0CD637DBB690FC16845CDF0A Content-Type: text/plain; charset=us-ascii; name="CFP.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="CFP.txt" ------------------------------------------------------------------------ CALL FOR PAPERS LCN'98: IEEE Annual Conference on Local Computer Networks The Conference on the Leading Edge of Practical Computer Networking **** This year in Boston **** ------------------------------------------------------------------------ The Westin Hotel Waltham Boston (Waltham), Massachusetts October 11-14, 1998 Sponsored by: IEEE Computer Society TC-Computer Communications Theme ----- The emphasis of this conference is on practical solutions to important problems in computer networking. Our unique approach stimulates a workshop environment and enables an effective interchange among users, researchers, and product developers. As requirements for global collaborative computing take root, the once clear boundary between local and wide area networks is blurring. The focus of the LCN'98 conference will be on this and related issues, consistent with this year's theme of "The Impact of Collaborative Applications On/By the LAN and WAN." Papers that address this particular area are explicitly sought and will be given preference. All papers will be reviewed by the Program Committee. They will be judged with respect to their quality, originality, and relevance. Accepted papers will be published in the conference proceedings, conditional upon the author's advanced registration. *** An award will be given for the best paper. The most outstanding papers will be submitted to Transactions on Networks for fast-tract consideration. *** Sessions are being organized on ------------------------------- * Collaborative Applications * Internetworking * Network/Protocol Design * PCS and Wireless Networks * Routing/Switching * Multimedia * Multicast Algorithms * ATM/Gigabit Ethernet * Quality of Service/Congestion Control * High Speed Networks * High Performance Protocols * Internet/Intranet/Extranet * LANs, MANs, and WANs * Networking to/at Home & Office * Cable Modems/xDSL * Security/Privacy/Authentication * Object Oriented Communications * Distributed Systems * Real-Time Networks * Active Networks Information for Authors ----------------------- Full technical manuscripts in English must be delivered by the submission date below. Electronic submissions in generic Postscript format are encouraged. Hard copy submissions must include five 8.5"x11" copies. The first page of the paper should contain the title, the names and complete addresses of all authors (including telephone, fax, and e-mail), a designation of the corresponding author, an abstract, and a list of key words. The camera ready paper will be limited to 10 pages. Authors should consult the manuscript submission instructions that will be available on the LCN web site. Send papers to -------------- Tim Strayer BBN Technologies GTE Internetworking 10 Moulton Street Cambridge, MA 02138 U.S.A. Phone: +1 617-872-2295 E-mail: strayer@bbn.com Important dates --------------- * Submission: April 25, 1998 * Acceptance: June 30, 1998 * Camera Copy: August 15, 1998 For more information, please consult The LCN Web page at: http://www.hill.com/lcn --------------0CD637DBB690FC16845CDF0A-- --------------ms38D974A1403B43B9A56CF74F Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIJ2wYJKoZIhvcNAQcCoIIJzDCCCcgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CEkwggOTMIIC/KADAgECAhAhonz+sCDBLrJ3XnfP7N7YMA0GCSqGSIb3DQEBBAUAMGIxETAP BgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVy aVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzExMTQwMDAw MDBaFw05ODAxMTMyMzU5NTlaMIIBCDERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVh bCBTdWJzY3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BT IEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk2MSYwJAYDVQQLEx1EaWdpdGFsIElEIENs YXNzIDEgLSBOZXRzY2FwZTEUMBIGA1UEAxMLVGltIFN0cmF5ZXIxHjAcBgkqhkiG9w0BCQEW D3N0cmF5ZXJAYmJuLmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQChNOxMaQzHvaqOalgI qKZIR1dqte17YpzUCZzA0l0OkLlnageChsJ77bXpjeEZkAzhOJaBM0XrQr5IDQ558IjZAgMB AAGjgeUwgeIwCQYDVR0TBAIwADCBrwYDVR0gBIGnMIAwgAYLYIZIAYb4RQEHAQEwgDAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUW DlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJl bmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24AAAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeA MBAGCmCGSAGG+EUBBgMEAhYAMA0GCSqGSIb3DQEBBAUAA4GBAEIbDd9jlnSyIKpjIFoQF8Wi 7G2Mv4t0Y8uRlTT9NUiDznwiI6Ei+MjGDDEqFByqz/U09R1yTvywbHeFV9i/YLORjS3h5UR+ M1dUAwaCn5O05muRoPyK32+S8apeCZRSMKBaHiFxtCv9SNz5pwsslRAJ/yUGfAZ5yMSHFNKx jZD/MIICeTCCAeKgAwIBAgIQUh81HfJwfgArvspZhwTVOTANBgkqhkiG9w0BAQIFADBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwNjI3MDAwMDAw WhcNOTkwNjI3MjM1OTU5WjBiMREwDwYDVQQHEwhJbnRlcm5ldDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xNDAyBgNVBAsTK1ZlcmlTaWduIENsYXNzIDEgQ0EgLSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALYUps9N0AUN2Moj0G+qtCmS Y44s+G+W1y6ddksRsTaNV8nD/RzGuv4eCLozypXqvuNbzQaot3kdRCrtc/KxUoNoEHBkkdc+ a/n3XZ0UQ5tul0WYgUfRLcvdu3LXTD9xquJA8lQ5vBbuz3zsuts/bCqzFrGGEp2ukzTVuNXQ 9z6pAgMBAAGjMzAxMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIB AQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQDB+vcC51fKEXXGnAz6K3dPh0UXO+PSwdoPWDmO rpWZA6GooTj+eZqTFwuXhjnHymg0ZrvHiEX2yAwF7r6XJe/g1G7kf512XM59uhSirguf+2db SKVnJa8ZZIj2ctgpJ6o3EmqxKK8ngxhlbI3tQJ5NxHiohuzpLFC/pvkN27CmSjCCAjEwggGa AgUCpAAAATANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNOTkxMjMxMjM1OTU5WjBfMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGlj IFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBW hBiHmgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5Ep uzbJY1zF4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAUnO6 mlXc3D+CfbCQmGIqgkx2AG4lPdXCCXBXAQwPdx8YofscYA6gdTtJIUH+p1wtTEJJ0/8o2Izq nf7JB+J3glMj3lXzzkST+vpMvco281tmsp7I8gxeXtShtCEJM8o7WfySwjj8rdmWJOAt+qMp 9TNoeE60vJ9pNeKomJRzO8QxggFaMIIBVgIBATB2MGIxETAPBgNVBAcTCEludGVybmV0MRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3MgMSBDQSAt IEluZGl2aWR1YWwgU3Vic2NyaWJlcgIQIaJ8/rAgwS6yd153z+ze2DAJBgUrDgMCGgUAoH0w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTcxMjI5MjEwMDEx WjAeBgkqhkiG9w0BCQ8xETAPMA0GCCqGSIb3DQMCAgEoMCMGCSqGSIb3DQEJBDEWBBSBdUH4 ymly4XQs7Lrkl/UeB5FFtTANBgkqhkiG9w0BAQEFAARAerRKJvOq1sE/eaTfnlXISvaeo0VW hA+IjLvFx3FZ6aACHxVkRemV4H5+qEJfsgPkwRbWRHdsMCewah0YXHyuQg== --------------ms38D974A1403B43B9A56CF74F-- From rem-conf Mon Dec 29 13:16:51 1997 From rem-conf-request@es.net Mon Dec 29 13:16:50 1997 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xmmVp-0000xA-00; Mon, 29 Dec 1997 13:14:13 -0800 Message-ID: From: Wayne R Miller To: "'rem-conf@es.net'" Subject: Date: Mon, 29 Dec 1997 15:06:28 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 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 unsubsribe webmaster@rock106.com From rem-conf Mon Dec 29 14:22:52 1997 From rem-conf-request@es.net Mon Dec 29 14:22:52 1997 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xmnVL-0001yV-00; Mon, 29 Dec 1997 14:17:47 -0800 Date: Mon, 29 Dec 1997 17:21:28 +0000 From: mkincaid@attmail.com (Michael Kincaid) Subject: Re: CFP: LCN'98 In-Reply-To: your message <34A80F5A.1A770E1A@bbn.com> of Mon Dec 29 16:00:10 -0500 1997 To: strayer@bbn.com (Tim Strayer) Cc: xtp-relay@cs.concordia.ca, end2end-interest@isi.edu, tccc@IEEE.ORG, enternet@BBN.COM, apc@eee.nthu.edu.tw, dbword@cs.wisc.edu, f-troup@codex.cis.upenn.edu, g-troup@ccrc.wustl.edu, hipparch@sophia.inria.fr, cost237-transport@comp.lancs.a, reres@laas.fr, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@tadpole.com, ieeetcpc@ccvm.sunysb.edu, cnon@maestro.bellcore.com, commsoft@cc.belcore.com, multicomm@cc.bellcore.com, activenets_all@ittc.ukansas.edu, fokus-users@fokus.gmd.de, arpanet-bboard@mc.lcs.mit.edu, cabernet-events@ncl.ac.uk, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, ieee.announce@bellcore.com, osimcast@BBN.COM, cif@injector.ca.sandia.gov Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please change my email address to mkincaid@bellatlantic.net From rem-conf Tue Dec 30 08:30:56 1997 From rem-conf-request@es.net Tue Dec 30 08:30:56 1997 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xn4NC-0000BV-00; Tue, 30 Dec 1997 08:18:30 -0800 Message-Id: <199712301618.LAA05114@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: rem-conf@es.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-format-guidelines-00.txt,.ps Date: Tue, 30 Dec 1997 11:18:23 -0500 Sender: cclark@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 : Guidelines for writers of RTP payload format specifications Author(s) : M. Handley Filename : draft-ietf-avt-rtp-format-guidelines-00.txt,.ps Pages : 5 Date : 29-Dec-97 This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifica- tions in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development. 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-rtp-format-guidelines-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-rtp-format-guidelines-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: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-format-guidelines-00.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971229160418.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-format-guidelines-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-format-guidelines-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971229160418.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Dec 30 10:39:31 1997 From rem-conf-request@es.net Tue Dec 30 10:39:31 1997 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xn6ME-0001YW-00; Tue, 30 Dec 1997 10:25:38 -0800 Sender: thass@ee.tu-berlin.de Message-ID: <34A93C44.491B@ee.tu-berlin.de> Date: Tue, 30 Dec 1997 19:24:04 +0100 From: Theodoros Assimakopoulos Organization: tu-berlin X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5 sun4m) MIME-Version: 1.0 To: REM-CONF@es.net Subject: MoMuC'98 Content-Type: multipart/mixed; boundary="------------1441556A72A7" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --------------1441556A72A7 Content-type: text/plain; charset="us-ascii" -- Theodoros Assimakopoulos Technical University of Berlin Dept. of EE Telecommunication Networks Secr. FT 5-2 Einsteinufer 25 10587 Berlin Germany Tel.: ++49 (030) 314-25628 Fax.: ++49 (030) 314-22514 Email: assimakopoulos@ee.TU-Berlin.DE, thass@ft.ee.TU-Berlin.DE --------------1441556A72A7 Content-type: text/plain; charset="iso-8859-1"; name="a" Content-transfer-encoding: quoted-printable Content-Disposition: inline; filename="a" Dear Colleague Enclosed is the first CFP for MoMuC'98. 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. Best regards and a happy new year = Adam Wolisz = _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ MoMuC '98 _/ FIFTH INTERNATIONAL WORKSHOP ON _/ MOBILE MULTIMEDIA COMMUNICATION _/ /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ FIRST CALL FOR PAPERS Berlin, Germany October 12-14, 1998 (immediately after ICUPC`98, Florence, Italy) = WWW: http://momuc98.ee.tu-berlin.de = email: momuc98@ee.tu-berlin.de Sponsored by IEEE Communication Society (approval pending) WORKSHOP OBJECTIVE = This is the fifth in a series of international work- shops - Tokyo in 1994, Bristol in 1995, Princeton in = 1996 and Seoul in 1997 - aimed at stimulating tech- nical exchanges in the emerging and strategically = important field of Mobile Multimedia Communica- tions. MoMuC'98 is intended to provide a timely = forum for exploratory research contributions, and to = promote cross-disciplinary technical interactions in = an informal setting. The scope of the workshop = includes broadband wireless networking for data = and multimedia, mobile multimedia system & appli- cations together with associated mobile computing = terminals, video processing and software. MoMuC = is an IEEE Communication Society sponsored = Workshop. = The workshop goal is to bring together researchers, = practitioners and potential users of this emerging = technology. The workshop targets at experts in mul- timedia systems, mobility issues in network proto- cols and communication systems. The impact of the = workshop is to provide an effective forum for origi- nal and fundamental advances in Mobile Multime- dia Systems and to foster communication among = researchers and practitioners working in a wide vari- ety of scientific areas with a common interest in = mobile multimedia communication. TECHNICAL PROGRAM = The 3-day technical program will primarily consist = of contributed research papers. In addition, there = will be a few distinguished invited speakers and = expert panel sessions providing a broad perspective = in each technical area. The conference language is = english. TECHNICAL TOPICS COVERED INCLUDE = (but are not limited to): = WIRELESS NETWORKS FOR MULTIMEDIA COMMUNICATION - broadband wireless networks - wireless ATM - voice/data in CDMA & TDMA systems = - high-speed wireless modems & radio techniques - medium access/data link control and handoff protocols - quality-of-service (QoS) management in wireless networks - wireless network signaling, control & mobility management - mobile internet protocol = - wireless network management & services control MOBILE MULTIMEDIA TERMINAL HARDWARE AND SOFTWARE - multimedia terminal hardware - signal processing techniques - low power VLSI for mobile computing - video compression, including MPEG-4 - network API and transport protocols - software technologies for personal multimedia MOBILE MULTIMEDIA SYSTEMS - mobile computing = - optimization of bandwidth use - powers saving - mobility support in ATM and INTERNET - QoS and mobility - adaptive applications - system architectures for mobile multimedia = - innovative prototypes, systems & products = - multimedia satellite systems = - personal multimedia applications = We especially invite submissions pertaining to sys- tem approach rather than investigation of individual = mechanisms. If individual mechanisms are consid- ered, their relevance to the multimedia communica- tion system should be clearly stated. Papers on all = aspects of multimedia mobile communication are = welcome. Of particular interest are papers which = address the system aspects: design, real-life experi- ences, but relevant papers concerned with individual = important mechanisms are also welcome. Authors = are invited to submit extended abstracts, clearly stat- ing the problem statement, the approach to its solu- tion, the approach used as well as the main results. = In case of system description the new features/ mechanisms should be exposed, in case of contribu- tions concerned with individual mechanisms their = relevance for multimedia mobile communication = should be stressed. = SUBMISSION INFORMATION: Contributions in english are invited in the form of = extended abstracts (about 1500 words) which should = be submitted to the Technical Program Committee = before May 8, 1998. Those planning to present a = paper are also requested to send a short abstract in = advance via e-mail for planning purposes. All submitted papers will be refereed for quality, = correctness, originality and relevance. The program = committee reserves the right to accept a submission = as full paper or poster presentation. All accepted = papers will be published in the conference proceed- ings. Authors will be interested to know that issuing = a book containing outstanding papers from the = Workshop is being planned. Submissions should = include the title, author(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. Electronic submission is strongly = encouraged. The Conference's web page will include information on electronic submission. For hardcopy = submission, send five copies of the manuscript to the = submission address. = SUBMISSION ADDRESS: Prof. Dr.-Ing. Adam Wolisz TU Berlin, Sekr.FT-5-2, Einsteinufer 25 10587 Berlin, Germany For more information visit our WWW site at: http://momuc98.ee.tu-berlin.d= e = or mail your question to: momuc98@ee.tu-berlin.de WORKSHOP CHAIR Adam Wolisz (Technical University of Berlin) STEERING COMMITTEE: = D. Goodman (Rutgers University) D. Raychaudhuri (NEC, Princeton) = H. Tominaga (Waseda University Tokyo) = TECHNICAL PROGRAMM COMMITTEE: E. Bonek, TU Wien A. Campbell, Columbia University N. Davis, Lancaster University G. Fettweis, TU Dresden Z. Haas, Cornell University T. Hattori, Sophia University Tokyo R. Jain, UC Los Angeles M. Karol, Bell Labs R. Kraemer, Phillips Research P. Kuehn, Universit=E4t Stuttgart K. S. Kwak, Inha University Seoul G. Maguire, KTH Stockholm H. Mitts, Nokia P. Noll, TU Berlin S. Pink, Lulea University G. Polyzos, UC San Diego K. Sabnani, Bell Labs O. Spaniol, RWTH Aachen C.-K. Toh, Hughes Research Labs B. Walke, RWTH Aachen A. Wolisz, TU Berlin R. Popescu-Zeletin, GMD Fokus IMPORTANT DATES: Submission Deadline: May 8, 1998 = Notification of Acceptance: June 12, 1998 = Camera Ready Full Paper August 14, 1998 = Venue: October 12-14, 1998 VENUE: = MoMuC `98 will be held in Berlin, the city which = after 40 years of splitting is now the live symbol of = the German reunification, and on its way to the grow = into the role of the German capital. It is currently = one of the largest construction sites worldwide. On = the other hand it is also a city of industry, where glo- bal companies like Siemens started off and still have = a strong position. Nowadays Berlin is changing its = economic role away from mainly industrial to = become a service-oriented gateway to the new = democracies in eastern europe. Located between = numerous lakes it has a more bridges than Venice, = Italy within its city limits. It is a vibrant cultural = metropolis, with 3 Opera Houses, several Musicals = Houses and hundreds of theaters. It offers a very = exiting and surprising nightlife scene with countless = restaurants, bars, clubs and galleries. = --------------1441556A72A7-- From rem-conf Tue Dec 30 11:13:22 1997 From rem-conf-request@es.net Tue Dec 30 11:13:22 1997 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xn74E-0002oH-00; Tue, 30 Dec 1997 11:11:06 -0800 Message-ID: From: Wayne R Miller To: 'Theodoros Assimakopoulos' , "'REM-CONF@es.net'" Subject: RE: MoMuC'98 Date: Tue, 30 Dec 1997 12:52:15 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 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 somebody please tell me how to get off this damn list!! I would even settle to know what list it is, according to the "unsubscribes" I send....I am not even on a list!!! >-----Original Message----- >From: Theodoros Assimakopoulos [SMTP:thass@ee.tu-berlin.de] >Sent: Tuesday, December 30, 1997 12:24 PM >To: REM-CONF@es.net >Subject: MoMuC'98 > >-- >Theodoros Assimakopoulos >Technical University of Berlin >Dept. of EE Telecommunication Networks >Secr. FT 5-2 >Einsteinufer 25 >10587 Berlin >Germany > >Tel.: ++49 (030) 314-25628 >Fax.: ++49 (030) 314-22514 >Email: assimakopoulos@ee.TU-Berlin.DE, > thass@ft.ee.TU-Berlin.DE > << File: a.txt >> From rem-conf Tue Dec 30 13:48:01 1997 From rem-conf-request@es.net Tue Dec 30 13:48:00 1997 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xn9Mp-0004CP-00; Tue, 30 Dec 1997 13:38:27 -0800 Message-Id: <3.0.3.32.19971230164025.031b28bc@cactus.pictel.com> X-Sender: webberr@cactus.pictel.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 30 Dec 1997 16:40:25 -0500 To: rem-conf@es.net From: Robert Webber Subject: H.263+ "Draft 20" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list During the recent Washington, DC meeting I mentioned the availability of the last draft of H.263 with the enhancements to form "H.263+" at ftp://standard.pictel.com/video-site/h263plus/draft20.doc or equivalently ftp://standard.pictel.com/video-site/h263plus/draft20.zip These documents are in MS Word 6.0 format; at the meeting, Dave Oran graciously offered to produce Adobe Acrobat files. I wasn't able to take Dave up on his offer, but we have a PDF version anyway. The "draft20" document is now available as: http://standard.pictel.com/h263+rtp/draft20.pdf http://standard.pictel.com/h263+rtp/draft20.doc http://standard.pictel.com/h263+rtp/draft20.zip A few caveats: * Only the ITU-T published version of H.263 has force as a standard. People who use drafts to write commercial implementations should break down and spend the money for a real copy when it becomes available. Order via http://www.itu.ch. * Copies of the draft20 document are provided for information only and to promote the goals of the ITU-T w.r.t. H.263 "packetization." * The current version of the PDF file is cluttered with change marks from MS Word and has printed page numbering which does not correspond to Acrobat logical page numbering. A new version without change marks might be produced by mid-January. From rem-conf Wed Dec 31 20:27:21 1997 From rem-conf-request@es.net Wed Dec 31 20:27:20 1997 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xnc1D-0003Wu-00; Wed, 31 Dec 1997 20:14:03 -0800 From: Alice here Message-ID: <33fd0823.34ab0f40@aol.com> Date: Wed, 31 Dec 1997 22:36:27 EST Mime-Version: 1.0 Subject: ALICE IS HERE Content-type: multipart/mixed; boundary="part0_883625790_boundary" Organization: AOL (http://www.aol.com) X-Mailer: Inet_Mail_Out (IMOv11) Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --part0_883625790_boundary Content-ID: <0_883625790@inet_out.mail.aol.com.1> Content-type: text/plain; charset=US-ASCII ALICE IS HERE HAPPY NEW YEAR ENJOY THE NEW HOLOGRAM WE PASSED THE DANGER 10 MINS AGO. PEACE ALICE ALICE IS THE 12:12 SOLUTION Now I've been happy lately, thinking about the good things to come And I believe it could be, something good has begun And I believe it could be, this day it's going to come Cause out on the edge of darkness, there rides a Peace Train Oh peace train take this country, come take us home again Get your bags together, go bring your good friends too Cause it's getting nearer, it soon will be with you Now I've been smiling lately, thinking about the good things to come And I believe it could be, something good has begun Oh peace train sounding louder, Glide on the peace train Come on now peace train, Yes, Peace train holy roller Everyone jump upon the peace train, Come on now peace train Now come and join the living, it's not so far from you And it's getting nearer, soon it will all be true Now I've been crying lately, thinking about the world as it is Why must we go on hating, why can't we live in bliss Cause out on the edge of darkness, there rides a peace train Oh peace train take this country, come take us home again --part0_883625790_boundary Content-ID: <0_883625790@inet_out.mail.aol.com.2> Content-type: application/applesingle; name="merkaba.jpg" Content-transfer-encoding: base64 AAUWAAACAAAAAAAAAAAAAAAAAAAAAAAAAAUAAAABAAAwxgAAP/4AAAACAAAAxgAAKksAAAAD AAAAVgAAAAsAAAAIAAAAlgAAABAAAAAJAAAApgAAACBtZXJrYWJhLmpwZwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsMgVCbDItyWAAAAA gAAAAEpQRUc4QklNBQD/////AAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAKckAACjJAAAAggAA A01heQAAAAAAAAAAAAAAAARKdW5lAAAAAAAAAAAAC21lcmthYmEuanBnAgAAAEpQRUc4QklN BQD/////AAAAAEpQRUc4QklNBQD/////AAAAAAAAAAAAAIAAAAAAAAAAsMgVCQAAP/4AACpL AAAAAAhEZWNlbWJlcgAAAAAAAAAA/wADAAAAACwgAAAgAAAALCAAAAAAAAAAAaifBwAAAQAA AAABegAAAAIAAAF8AAAAAgAAAX4AAAAeAAABnAAAADIAAAHOAAAABgAAAAAABwNTdW4DTW9u A1R1ZQNXZWQDVGh1A0ZyaQNTYXQADAAAABUUQWRvYmUgUGhvdG9zaG9wqCA0LjAAACOSI5IA AAAAAHAAcAARAv8MAP/+AAAASAAAAEgAAAAAAAAAcABwAAAAAAChAfIAFjhCSU0AAAAAAAAA cABwR3KJcGivYmoAAQAKAAAAAABwAHCCAAAAISwAAAABAAAAAAAAAAAAAAAAAAAAAQAAAAAA AAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAABAAAAAAABwAHAAAAMAAAAAAAAAAFZqcGVnAAAA AAAAAAAAAQABYXBwbAAAAAAAAAMAAHAAcABIAAAASAAAAAAgkQABDFBob3RvIC0gSlBFRwAA AAAAAAAAAAAAAAAAAAAAAAAAGP///9j/4AAQSkZJRgABAQEASABIAAD//gAMQXBwbGVNYXJr Cv/bAIQAAwICAgICAwICAgMDAwMEBgQEBAQEBwUGBQYJCAkJCAgICAkKDQsJCg0KCAgMEAwN Dg4PDw8JCxAREA4RDQ4PDgEDAwMEAwQHBAQHDgoICg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O/8QBogAAAQUBAQEBAQEAAAAAAAAAAAECAwQF BgcICQoLAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgsQAAIBAwMCBAMFBQQEAAABfQEC AwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5 OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Sl pqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+hEA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/8AAEQgAcABwAwEhAAIRAQMRAf/aAAwDAQACEQMRAD8A/KqigAoA zQBesNC1jVdx03TLm6CcM0UTOo+pAwKvweA/GN2zJZ+G7+5KZ3CCIy4x1ztzXvYPhfOcworE YbCzlB7O3xW/lvbm/wC3bm1LDV69vZU5Sv8Ayxb/ACTMy+0rUtLmNvqVhcWko/5ZzxtE35MB TLSwvdQmFtYWk1zM3SOGNpGP4AZrzHgMVHEfVHSl7W9uTlfNfty2vf5GbhJS5Gtb2t1v2t3N WXwL4vt3SO68O39s0hwgnhaHd9N2KpX+ga1pQDalpd1aq33WliZA30JGD+Fepi+Fs6wFF4jE 4ScYLduL93zlb4fnY1q4atQbVWnKLW/NFq3rdIolSMjI496SvA2MAooAKKAJLa3lup47a3he WWVgkcaDczMTgADucmu2XTPDXgRFfXoU1rWyob+z1f8A0a1PYTMP9Yw4+UfL1619Zw3gcJTh VzjM4c+Ho2She3tarvyQ/wAKtzTfRJK3vHTh4wV61VXjHp/M+i9Or8la6bRkax4+8T6wBBJq BtrWPiO2tVEEUQ9FVcYrOTxL4hQbU13UABnAF1IMevescx4wzvMsS8TUxU4t6JQk4RS6JKLS SXQmWKrVJ+0cnfy0t2SSskl0SO/0O+vtL8Pvq3jueJrC/iP2KC402K7nuj/eRnKlV5Bzk8dM cZff31xq3hqOb4fmKNdPjL39rBpsdvcQj+/5ilmkHvweM/T62GbYiWHjTdWP132TalyR5rc3 Ny8389r9N9W+r+iimsOsM43xTjzL93Hm5XaXLzX5udw99Ts52tTTvJ28+m8UeI58LPr+oyBS doe6kbH0ya0NI+IHinRx5UWpNcWzfftrpRcQuPQo2a+Ty/jHO8uxKxNPFTk+qnJzjJdYtNvR 9dvKx89HF14VPaqb5vN3uuzvdNd07o2Y9P8ADXj1WTRYI9D15gWFm0n+iXZ4yImP+rcn+FuO nNcVe2c9hcyWd1C8M8LFJI3G1kYHBBH1rfiXBYStSpZ1lkeSjWbUoX/hVVrKH+Fp80H2uuhe IhBxValpGV9P5X1Xp1j5XW6ZBRXyJyBRQB22g2J8M+F5PHN4wjlu5HstKT+KRsYlkHcIoOCw 6n5R94kcZNM88rTSuXdySzE8k19NnTlg8Dg8u/u+1l/iq6r/AMpqH3nRXougoQk9Wub05tV9 8eV/MZXQ+D9Jgv7uXUL42/2LTUNxOs8hRZcdIxj5mJ9B1AxkZzXkZXRjiMXThP4b3fotX+Qs LTVWtGLtbd8zsrLV3a1Wl9tShr+tS69qMuoSoI9xxHEudsSZ4Vck/wD681Ho+r3Oi30WoWrf vI2yVJO117qcEHB//Vg05ZhUeNeMvd81/l2flbR+QSxEnX9ulZ35vJO9/uNjxjY25a38Q6dD BDZasplWKGXzBDID86HPzLzzg++CRXM1WbUo0sZPkd4y95Pupa/rb5FYyKjWlZKKeqUXdJSS lFX8k0tdVsOjdo3V0YqynIIOCD2INdlqy3Hi7wv/AMJSR5t7pRS21Bx94o3ETvjqOMBvqp4C 59XIpvE4XGZa9VOHtIr+/S95W/7c50/IilGdRSpwV9G//AdW/lHmOLIwSDRXzBiFAGRTQHpn inwX4l1OXSdFsbYzQadZQ2zSFhFDFO43tGGbALAEM5HQlieMVgD4fpHsW58VaLHJJN5KqLkM Pdy3AVB0yevYGvu86yDE4nHVK1aajDSMW+qhFRVrtJL3dNb21Stqe5icpxCnKVepGKT5U5y5 eblaj7q1bS0V7W5VdPQP+FZ6/PGZtHez1VQX4s7gM21OWfacELjucZrX0/QNZ/4V4bTT7C5W fVNSIuGliWGJYogCFMz4JO7B2jj6kgDPLuGsfSnV5IcylTkoyWzbajq3to7+dtOtlSy+vhpS kvevCXLKFpRafLGV3tFWnq3Zxurq5j/8IJDBJt1PxRpVoTk7d7Ow/MLSN4C89iNK8RaZekZ+ VZCrfoCPzIrN8Gy/hLF0nW/kUtb9u9/+3Tg+qw+FVouXbX87W/E1YtD1M+AdU0nULCdZ9PvI bm1KwCZXD/K4WZcgeuM7Tz3HOcfhjr9sA+sSWWkruQEXtyqMAwyrbRk7cdxmqxvDWOrqg5x5 FGmlJy2TjKcbK176JO+3md8svrYqMHZRUY+9KVoRXvTS1fxXUdOW7bTSTaY0fD9JPltvFOjS SCYwsjXATBzgODyGQn+IdO+K3/BfhPxXoOtT6bdaYzWusW1xp0hBV4Zjs3+XvBwHwuUzg5Ck cc1vkmR4jBZjQxFGSqR5uWXLa6UvdfWz0eqTuk72tqPC5VilUhVwso1FdJ8kua3M+W0lpJJ3 ava1uuqPNZF2SMuc4JGabXwcouLcX0PCWquKiljwM4Ga7m00zTfAEVnq/iexS+1G5t/tdnpk nKIG/wBU849MZbb/ALoPVtv0PD+Go81TMcVHmpYdKTX80m7Qj83dvyTvodeFioS9vUjzQg02 ntJ9Iv169eVNrUT4oX92+oW1rDdXR0x7OGe3jkkJV2cfvpcdCXkDEn6dgMcNzXPxBNyzGrHm bjF2jfpFJW/A1zOpOrjKs5tvV2vvy/Z/8lsdb4e0ey02xHirxBJKlsCRa20bFHujnBJIwQmQ RwQWIIBABI6y68WaX4i8OWt94mQq15cSW0t1BcM93CiA+UqISI4ofug4HzHJxxX3PDscHl+G WGx93zU3Vk1JpwjJqmuVbc6hKU9fhaTd7JHThsYsDh6mGkrxqxTnr5rksusopykk/dbkr/Ce c67olzod61rM8cqsN8csbh1dT6EEjI6Edj7YNLoGhz63ei3SaOFIwZJZpJFRUUDPU8bjg4Gf yAJHxq4fxP8AbX9j8yU1Pl5rrltf47/y8vv325dTyLa8t1vbdWve2+256TpnivStP0PU7rRo 7prfTBFAl2915d3cLKwV1mj3FJohkgDAKkryueOG8T6LGix65pl1Jd2FyeHclmibP3STzj68 g5B7M32HE0cLmWBTwLl7sfapSldzpqUqPPJdJ2pxlPVq8nJfFI9bG4z65h6NKN+WlF8ut9HJ puzvyydouSTs3eSWpzZ6123wxv7+XX4dJOsXNpp8oaSbaxZY2RSYpQvQFX2HPHGR0Jr4jIKt SlmFKNObipNRlZ7xekvwvbs7NanNldSVPG0ZRm4+8ldbpN2f4XJNR0jTfHMOoa94Wsls761h +13mmJ9wqOJXg9uj7ewLD+EbuFII6108RYSkqlPMMKrUsQnJL+WSk1OHyevo0Ri4qUlXpx5Y Tu0ltHXWPy6d4uLerOk8HaXbSy3muaiubLSYxLIuM73Y4RPrwx/4DWZr+t33iHVrnWdQk3z3 Tl2x0UdFVfRVGAB6AVeLk8FkeGw6/wCX8pVX6Qbpw+5qp95m5ONH2a2l7z+V0vuvL7zf1It4 m8IWd9H5017oamC6PVUthsWI+vU/z9KxPDujDWtZttOdmWJ2LzOvVYlG5yPfaDj3xWdbCvH4 7Cpf8vlC76X+F/dbU6MRF4itCWtpqOr66KMmvJSUkvQseLdaOq6m8cSqlpa/uLeNPuoq/KMe 2AAPYCtHwfG2v6ZqXhASKss6m8tQ8iRIZY1y25m5PyKcAHua9fLcZHH8Q1abdo11UpLbRShK FNa7K/Jd72vbU8zF4hxjOv8AN6X0vqkvTRdtC7ocEfirwvqfh3UJ1i1HRIGvNO8+VwzKpHm2 6RhDuc5yMlcBevygUzxIsfhXw3pnhmzuY3vdTtlv9TeGZzw5zHBIjINsiAHOCQcjnk16FTFT WA/th/xXh/q99b83N7Jv19guW2+t+p5ScniPq3K+Xn5tlbl5b97/ABve25W8TQTeHfD2n+GJ l23U+3UroEI23eo8va6knBUrkHugPeq3gu/V7mTw7eDfa6p+6C5+7KfuEfX7v1Kn+EVzYrER wPEGHwb+GnCnQn84KNRPulOUreSR62BxDxEY1XtK/wD4C3ZfhZ+ph39i+n381jMcmFyufUdj +IwfxrpvDrf8I54c1TXXdorm/h+xWiMvEkcm9ZHB9ivHutfO5fh5YPG1ZNa0VO/qvdt97O/B v2VV1HKzipO9r62tH75NL5mFoGvXvhzWLbV9PbEls+cEnDqRhkPsykqfY1f8YaTb2k9pq2ng /YdVhNxF/ssG2uv54P8AwKtsLfGZHiKMv+XE41F5Kdqc/vfs/uMOZzp8l9I3f38qf5R+4vxO lp8Lrl0dfNvtaSJxnkxxxbhx9TXHE5o4hfLDA0/5cPD/AMmlKf8A7cVX0UF/d/Nt/qbHhrxB L4f1JLsRCe3fCXVs5OyeLcCUP5Cu60Pw1aPLd6x4MnN9FfWq2sFv9yWG8ky/k7SeQPKPzdOe /U+pwry4yUKKa9rSk5QT+1zaOPb4uV79ul2vRy+m8bBYemm6sW3BLVyTi24rzTScV1vO2rRy /wDwh1lYRo+u+J7G1Z445fKiP2h1V2IIIU8MACxHPYdTWnpdh4BsBBqdr4/vbTUbXzbmH/iW NIomR1+zrzgAMMsxOQAuMNmuxcPZLk/L9ezRRxSs+WnBzjCSeilLXVW2sj5zHvE0n7KjSVRP SXv2VndPXr027nqul6Dpeu+PdJ8Z+A/EsGrarLezWep2+n6m1jc6lH9naS+1EyyxgWETeYY8 OvO12AwCKrXnhrTtO8fat46+I/iGLSr2PUfs2nW2o6gb26s2W3EtheyERn7bbARLGSi8koSA CBXovE4OpjfZuqvY+1Vdx0ts1z3+H2bn70tdH+7tzWT/AD367VjWlRVF/W/Y8ihyLn5ed6+0 UuXlT921/wDp5flPNdYtvh/qdzNqt945vbq+vzHdXBi0wwRxzSEmdAoyMIcbduAwbGFxWZB4 Xsbj9/4f8U2c08IMyRTZt3JV8Kq5+85GGxxxn0rhlkmS5pUdTBZoni23K04OEZSvtGTsk30W renU/QcveJqJU61NU0lZXlfa276PffTz1Ok8S+DYD4kvtY124i03S7bzBIWPM9zHjdbxgc7v mUZHGOR7cX4q8RNr16n2eM2+n2geGxts58iHcSFz3PP9O1cHFNGnltXEU006lao5O3SCbttp eTu9NtU0mj6XHUpYBVKE1y1Zy1j/ACxTuk/8TtL0jF9TDB5zmuxvGS7+GGmySyL5ljq88CZ6 7JI1c/hkV5XD/vUcfTezoS/8lnTkvxiedQ+Cou8fyaf6BAEvPhbdRKqmWw1pJnwPmEckRUH6 ZX9K440+IrShgaq2lQh/5LKcH+MRV9VB94/k2v0Njw14dl8Q6nHZrMsFuCGublwSkEeQCzfi QPrXdaB4ksor2TQfBtqLGK2hS5gumAklmvYwUEuSOFPmsduMYHbpXq8KezwU6dZpOrVnywur 2td39eblVn89G0/RwFSWAgsVB2qybjB9lZpyXndpRfRqXVHL/wDCV6TfKq674WtJ5ESOMy25 Nu7BWyzPj7zMCVJJ7Agcc6WmXHw6v2h0608HaxealeB7e3T7cI0Nw7qID33DGVYcZyCCuK6/ 7dyDN+V4/LH9abSbpScYzk31hdJN33TvfVtnzePeKn79CpGmlq7xutL62/ra56rpOraB4f8A HGneEPA3hiDStTjupr3VLq30+fVZtMtzbMl9ps8En/H9EhjLlyRgO4z1Ij1HX9J8QeOtU8F/ Efw7Dqupy3y3Wm3d3YS6dcaiptkisNPCK4NjA3mLJlTztUHgA16P1DAwxik6S9l7VUb6Wtdv ktty8/uuTV3O9RyvZr8++pYiVf6z7d/WvY86nzxUuTn1XsrOPLtLmt2ptHlmsSeANOvV0y48 J6vZXliyW9/ENQSZWlQkTkHHAYgBQDhQM5bOKp2fiLSYJEtfD3hS3+13H7iOW6YzsHaQFWQH 7rYwoOcdTjmuNZrw7llRwwOWyeLTcV7Sd4Rne1+W75mul9U9U7n6FlzxKSqVpxqJr3bRtvs2 n1/DutDo/E/jKzm8TalofiO2iv8ATZJJTvUBGguZNu+4QqOfur8vTHTuDxHinw5J4e1AwpKb iyn3SWdzjAnh3EBh78c/4V5/FM6WZVK9WmkpUKkoO2nNByfK7d07+bu2z6XMK08xVTFVHerG T5n3i3aL7e7ZR+cTFHUA+tdjfhLT4X6XA6qJb/Vp7kcclERU/ma8rh/3aOPqvZUJL/wKdOC+ 9yPMou0aj/u/ql+pQ8H6tb21xcaRqT4sNUQQznONpDAqw9xlh/wKqHiPQL7wzrV3oeoJia0c puHAdequv+yykEexp4pPG5Hh661dCcqcvSd6kPx9p8/xPZylR9r0i0vvu1+Uje1Av4X8I2th GZob3XEae6H8L2p2NEPxIP8A4961zujao2k6lb6iuSYWO4DuhGGA9Dgms8VifqGMw/L/AMuV B6dZK0m/V/ma4pulUjFN2go2T6OylJLy53Jr1NPxdpItrpdXsfmsdQ/fROowFc4LL7dQwHow HUHFvwi7aFpeoeLWiR5IAbS1EkaSp5si4bcrcg7WyGHoa9vB4KOD4iqVuW9OlGpXjbsoOdPf dczipdd9mrLhxlCVSE6UNn52912u1t01Re0m4Twr4V1LXL9RJq3iGJrSy89ZhJHC5zLcJIrg bjyuGDAh845pPEEqeLfDOneIrGNF1LR4FsdSWJJSzon+ruJJHdgXIOMKAAF6cV2zw9T6p/Yy b9r9X9u1Z83Pf21vX2L5ubeytuzxowar/W76c7j0ty8vL2vbnV7X3d9kVPFM0niLQ9P8WMF+ 0ADTroqqRqWjUBNqrj+BQS2Orik8EWUempceM9SULbaZn7KG/wCWt1j5Av8AuZDn32D+Ksau HhieIqWPkrU5U4YiV7aWgpTvbRJ1E0vJo9zLqDoqMJaqF3vfSN2k/NpJerOYu7qS7upbqVvn kdmJHueldToaDxJ4Y1DR3V5rvS4vtdo7PxFAm9pVH1LcD1b2r5fLa0sViqkJ71VP72r3+9aH Vgl7Sq6bTfNGSte13ZuN/JTUZP0MXw34dvfFGuWui2Aw9w/LnpFGOXkb2VQSfpVrxhq9vf3V vYacSLDTYjb24zwfmyzfiSBnuFFdWHvgsir1XviJqmv8NO05fLmcPK6+6OSUKHtOkm4/+A2b /OJgKcGu103WdM8ZW0Wi+L7z7NdQ232fT9SYZClB+7Sc9SpHybuw2k42nOXD+MpQqVMDipWo V1yye/K73hP/ALdl+DZeEnBy9jWdoS0b7dpfJ79bXS3JviZo+pNf22oW1heHSRZRRWsjKWEY QfvIyRwpSQuuD6A9CK4QrjoajiHD1KWYVJTg4xk7xvpdWVvwtddHobZrRnQxtWE01q7X6xes X842Z0/hfWJPLk0O806XUNNn4eJFLNEezKR055z2OTyCyt3Fx4Q07SdEh067guLybT55Lh7G K12XzF+YiwIZJ4RgcoeMtkY4r7zhdYfMcHGpj6Um4QlSVo3dWCaqKMHtzpQlBdGny3vJG2Bw bxtCrUe1NJbP3ru6gmtFKyk1fRpW3seZ69ql7q+oS3V/CsMn3fKSMRrGM9AuBjnk++af4c1P UNM1KOXTrc3UjfKbcx+asvttwcnuOOv4iviI5zjXnizTkvW9pzcltN/4fLvy29zl/l0PJVpS 0S32tpe99vU9SsvA+mT6Ve2ogv4I9TMU66b9mWS/j8vDSEkAJbRMR1bJOFAXtXnfi7XLy/mh sFsG03TrNdtnZlSgRMnnnkkkkkknJJOSa+24sVHLMu9ng6U05pU5Nxt7OCk6qptreX7yMW9r QUU/d19rMcHLAYekrO1RPW1rWk3yN/amrxc9uV2hq1K3ObSzAeprufhlo+pw6wdZn0m6l0uK Jo7ghdomLjEUSk43F5NgAGeMnoCR8Hw/h61XH06lKm5KDUpW6Jb/AIXsurOXKaUq+OoxhFy9 5Npfyp3l8rJ3ItV1vS/CFvdeH/B90biW4t/st/qeMGUn/WJD6J0TPcBiPvccUzbjnGK04gxd KdWGBwrvRoJwi/5ne85+sn+CRji6kHL2VJ3hC6T795f9vPXyVl0EpQxArwEch6P4r8XeJdJ1 LTdf0y7ltI9RsYLrYuDDLIFCNIEIK5YABuOu4Guffx9fytbPPpekSvaytKjNaA7geqODwyeg PTPBFfc5zn+MwWZVqckpxbUle90pxUlqmrq0tL3tstEj2MRmmJ55RqKMot8yjKEZKLk4yfLz J2TslZact1tJ3fJ8SfFBgNrZ3sWnxFXj22kYiJRuShblivbBJrSXU9SuPhzbXlne3qz6NqL+ YfPDoEmAIbafmGWwM8g47HrjgeIsdiJVv3jjalLlUb2TTjLq23tbV9X5hHGYnH88JzekHyqN opKLjN2SSW0OZ21k0m7tGYvxK8UeWIri6gughGDcQrKf1ok+JfixofIt7+O1TGCLaJYs+vSt H4hZ06fKpRUrW5+Vc/3/APAONZhil9vXvaPN/wCBW5r+d7l+zvbyz+Hmr6pcXd55+rX0MELf aSgbyzvY7M5bGSM9B9elGL4leKPKEF9eRahEAi7byFZSUXkJu4YL7AisMVxBjsIqCVRyvTTk pNtNylOV9007SWzXnodjxlfARpxpS+KHvJ2lF3lKSvFpraTeuqbbTTY2Hx9qFubg22l6RHJc zec7rZrkc5CKM4VB6Ac981v+CvE/ivWdfuNavNUmkTSrS4v5WZtsUJ2bfM2DC7huwvHXaBXV k2fY3H5lQoxShDmTdr6qKTerbaVo3drX1vdDoZni5VIU6HLBcyk1GMYptNyvKyV0rvRuyS0S secyOzuzt1Ykmm18K3d3PGtbQKKQHa6NeN4o8JP4NuSr3OmvJeaYx+8oPMsY9UP3iOx+boGr jJEZHKOpVgSGB4IPpX02eKWKweCzDe8PZSf96l7qv6w5LI6K9R1lCo97Wf8A27ovujZfIbXR eDdTt7W5n0q/Ft9i1WM20rTqWERP3ZARypGeozjqQcYrycqrKhjKcpX5W7O3Z6P8wws1TrRc rWej5k2rPRt210TZm61otzol/NY3Lo5jPyyIcrKueGU+h/ToeaZpOl3GsXsNhbY8yZ9u4/dQ cZZsdhSngKsMY8Hb3r2/4PpbX0FKhJVnQum78vle9vzNnxhf22638Pac1tJZ6SpiWaCMqJpM /M7E/M5zxk4HXAANczV5vUjUxlTk0UXypduXT9B4qanWlytNLROOiailFP5pJu+71HRxl2VQ CSxwABkk+1dlqktx4Q8J/wDCL7vKu9ZMd1foPvmJeYkb0XPIXqSSx42V6mRRnhcNi8yWihB0 0/79X3LLz5Od+SQqMp01OpDs1/4Fo1848xxZ5JNFfMmAUUAT2V5c2N1FeWs7wzQOJI5FOCrA 5BB9a7Nrzwt48VW1Oa30LXzwbnaRZ3Z9XA/1L+4+X6dK+u4axWExNOrkmZTUKNZpwm9qVVXU Zv8AuyTcJ+TT+ydWGlTknRquyls/5X3fWz2fyetrPG1nwJ4o0Ns3ekyPE43Rz2/76Jx2KsuQ RWWNG1raNulXuGzjED4Pr2rgzHhfN8rxEsNXw0rrrGLlFro00rNPdGVSjVoy5Zxaf9bd15o9 C0TTr/XvD7ad45tiLKwhJsrue/gtZrY9Au2T5nXgccdAOeMSajp914d8ORR+A4g6ahFi9vod Qt55peoKLGmGRevr19c19lHKcSsMsS6H+2+zdlzxUrXUefk+Jytfy6eR9Naf1ZYx/wC8qNl7 8L8vwKfLbmuo+5y/E7KpstfOpdF1pGxJpN6uTwDA4/pWlo/gTxTrRJtdImSJeXnuAIYkHqzv gAV8fgOFc5zDERw1HCzUn1lFxil1bk1ZJdz5unh6tap7KMXzfdbzfZeb0NtLrwx4ALPp89vr 3iBRhLgKfsdm3coCP3zehICj0454y+vrrUbuW+vbh57idy8kjtuZ2Pcmu7iPFYbB0aeR5dNT pUW5TqLarVatKS/uwXuQ7q8vtGmIlTilRpaxW7/ml39FtHy10cmivRXyByBRQAUA4oA09N8S 65oylNL1W7tkJy0ccpEbfVPun8RV62+IXjKxYtY+I7+13ZyIZvLBz14XAr6TBcYZ5l1GOHw2 KlGEdEtHyrtFyTcV5JpHTSxmIoNOlVlFrblk1b7mZV/rOp6rMbjU9QubuQ87p5mkOfq1NstV 1DTJvtGnX1xaSjnfBK0bfmDXkPMcXLFfXXVl7a9+fmfNfvfcx55c3Pf3r3v1v3vvfzNa4+IP jK8aN7zxHfXRh+59ol84D8GyD+NUdS8Sa5rKhNT1a7uUXpG8pKD6L0H5V7GL4wzzH0HhsRi5 uEtGr25l2k0k5LybaNq2MxGIbdapKV9+aTlf1uzOLZpK+bbOYKKQH//ZAACYAAoAAAAAACwA RQAAAAAALABFAAAAAABwAHAAAAj9/wIAAP7+AAsHgH///wAH/8D/AAsHgH///wAf//D/AAsH gH///wB///z/AAsHgH///wD///7/AAoEgH/A/wH+//8ACwmIfwA/A/8B/4AACwmIfgAfA/wA f4AACwmIfAAPB/gAP8AACwmAeBwHB/AAH8AACwmAeBwHD+AAD+AACwmAcBwDD8AAB+AACwmA cBwDH8AAB/AACwmAcBwDH4AAA/AACwmAcBwDH4AAA/AACwmAcBwDH4A//PAACwmAcBwDH4An /PAACwmAcAgDH4A//PAACwmAcAADH4AAA/AACwmAcAADH4AAA/AACwmH8BwDH8AAB/AACwmB 8BwDD8AAB+AACwmB8BwHD+AAD+AACwmB8AAHB/AAH8AACwmB8AAPB/gAP8AACwmB4AAfA/wA f4AACwmPgAB/A/8B/8AACwCB/v8AAf7/AeAACwCB/v8AAP7/AfAACwCB/v8FAH////AACwCB /v8FAB////AACf3/BQAH/8/wAAj8AAQB/wPwAAL3AAsJOAAMfAAAPc/4AAsJRAIEVIAAEpGo AAsJggAEEAAAEqAgAAsJg7Z1kbfYHKAgAAsJgpKVEJpkEKAgAAsJgpKHEJJ8EKAgAAsJRJKF EJJgEJEgAAsJOP9/uft8Oc9wAAQAGPgABAAO+AAA/wAAAA6wyBUOAABQSUNUfewAAAAABAD/ //////////////////////////////////////////////////////////////////////// //////////////////////////Tx8rHz///0sfLx8/////////////////////////SLsLGx sbGwjbGxsbGwi/P///////////////////+xi/P//////YaMsf/////zi7H///////////// ////86/q//////OM//+Nsv//////r/H///////////////+L6v//////jP////+w//////// jP//////////////sbH//////7Ky//////2x//////+xsP////////////+x/vOystb/sf3W sbHW/7H/1rKy8+qx/////////////4yMsbLy/IyMsfHy/bGxjI2xsvGNjIz///////////+w Yv//////sIyw4P///7Bnqv///+r/jIz/////////i/Sx/v///4zq1bHu//+p1tXzsP////+r 84v///////Cx/7Kx//+w8v/V1s/xz9bz8P+x8f//srH/sdX/////jOr//7D//7Dq///O4M7O /87g//+w//+M6v//r////9aw/////Y3y/v/W1qrOz8/Pqtby/7HqjbL///+M8///8rH///// /oyMsPHP1qvJpc7yz/HwjIzW/////7Hy//+xsf/////zjIzv8fLQz8nDz9DW8qqMjP7///// sfL///Ow////84zW8ury/c7Oq8/Oqtbx/7H0jLL///+w/f///7D///+M6v+w4P//zv/Ozv/O ////sOr/sP///6//////sbD/srH/6rGx/9XWz/Hx8fPw/4zy///8sv+M8f//////hfOx//// /7D+8bGw//+q8vGxsP////+x/ov/////////jGjq/////7BnsOr///+wZ6r//////2iw//// ////////jIz8srGNsYaxsbGwsLGMsY3ysrGMjOr///////////+x//PW1v7/sfTz1v306rH/ /rLy/uqw/////////////7Gx//////+xsv////+ysf//////sbH//////////////4v///// //+M/////7Dq//////+w6v//////////////8rD//////7KM//+Nsv//////r7H///////// ///////qsYv0//////2MjbH/////9Iux////////////////////1ouw8fGxsYyGsbHxsbCL 1v///////////////////////9axsbH+///zsbHx1v////////////////////////////// ////////////////////////////////////////////////////////////////////AAAB AP/////////////////f/////3///v3/f//73//////////v//v//7//6+//+/+7//2//9// +33////f/7++fv//1+///v19e9///////3/f79/f//v379///v/////v3/33//////////3/ //9/v3//v9v///////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////8AAAEAAAApyQAAKMkA AACCAb/XKEG8AAAAHACCAARTVFIgAAAAKlBJQ1QAAAA2cG5vdAAAAEJpY2w4AAAATklDTiMA AABav/T//wAAAAABxc4sfez//wAAABkAAAAAAAD//wAAI68Bxc4gv7n//wAAI8EBxc4kv7n/ /wAAJ8UBxc4wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA/9j/4AAQSkZJRgABAgEASABIAAD/7RUiUGhvdG9zaG9wIDMuMAA4QklN A+kAAAAAAHgAFQAAAEgASAAAAAAC5AJA//f/9wMPAlsgAgUoA/wAAQAAAWgBaAAAAAAOdAtA AWgAMAtAQ4AATgABAQEAAAABJw8AAQABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAA AJQQAAACAAEAZMwAVmU5Q1YrU1I4QklNA+0AAAAAABAASAAAAAEAAQBIAAAAAQABOEJJTQPz AAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklN A/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAA AAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////////////// //////////8D6AAAAAD/////////////////////////////A+gAAAAA//////////////// /////////////wPoAAAAAP////////////////////////////8D6AAAOEJJTQQIAAAAAAAQ AAAAAQAAAkAAAAJAAAAAADhCSU0ECQAAAAATLgAAAAEAAACAAAAAgAAAAYAAAMAAAAATEgAY AAH/2P/gABBKRklGAAECAQBIAEgAAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9z aG9wqCA0LjAA/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMT FRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4O DhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AA EQgAgACAAwEiAAIRAQMRAf/dAAQACP/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkK CwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQh EjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX 0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cR AAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MV Y3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2 hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A8qSSSSUpJJHxMK/Ls9Olsxq5x0a0 eL3JLoQlOQjEGUpaADdBCkyqx/0GF3wBP5FqE9K6f7Q0Z2SOXHSoHyb+egW9bzbNAWsZ2Y0C B/Z+ik2Dy+HHplzevrjwj3eH+9k4oY/8T3Gm6m5v0q3D4ghQhX6+u9TrG1toDf3Q1oH/AEGt Vuk15tD7cuhogaXl+yY/dmXIiNkAH8NP+7VHBhymsWSXFRPDkhQ0/r45ZHFUm1WuEtY4jyBK 2HtqxMVl+LQ155NvqbyPONrXKrZ13qTwWusG3w2tP/VByJjWhP2a/wDeqPL4cdDNklxEA1jh xb/18ksTRfVYww9hafMEflUYK0KuuZzPaS17Dyxw0/zUUP6V1CBY0YOQeHt1qJ/lD8xNUOXw 5NMWb1/uZo+1xeEcnFPH/j+25SSsZuDfh2bLhodWOGrXD95rlXSa84ShIwmDGUdDE7qSSSSW v//Q8qSSSSUzpqddY2tv0nGAtDOyBi1fs/G9gb/POH0nO77/AOV/57/m0ulPbi0X5sA21t20 z2cfz/xbtWa4uJJcSSdST5pV4/RtCXs4AYn9ZnB4iN4YR6eH/qsv+YtKSSUJNVs4WM26ybDt qZq4/wDfU+bmOvdtb7am6NaBEgcEo104/TqqwYdf7naRp9Ln/Mas/VOJocI66y/7mLPkPtxG MaEgSyfX5YtjDzH47yRqx30mwD8xKnm49bHC2kg1WcROh/tfvKotDCm/EtxnHVg31yP9dvv/ AOrSGo4fqP5f1lYjxxOI69cfhL93/Cc9KUoKSawOlgZotr/Z+XNlL9Kj+cx35uxUsih1Frq3 akcEcEdnIYkLTzy3L6fRmj+eb+jv8/3bP+j7kq8W2JHPgIkbyYBxQJ+aWHaUP+p/PBy0kkkm o//R8qTtY5ztrRLjoAOSmAkgDUngBaxFfS8WswHZ143mdQxn5g/tJM2HDx8UieHHjFzn+UY/ 15JW49WPgfZ82a2hwfaW6kuP8zRPu/N3Peqf23CrgVYwMcl0T/3/AP6pT9azJ6XZvdufXYXu k6kn/wAx3LNUkpVXCABWl+o/y9LPzGbh4PbAEeAcMpASnw/ut/8AaVbp347TJk8f5rfZtajU 0dPzg7ZW+h7dXOH0APD87c9yoYmM7JuFYMDl7vAeKtZmY1jfsmL7KmaEjkn873fvfvv/APRS bxd6I7V/3XzKxTJicmbhlj+WMTEcWSfaP/fN3ObQxteRk02vbGyr1NBA7+m0t9Nv9d6pDqrK /wCaxmNHjAn8GK7k5rqfRtcC7Hy6wLd0PcY+k9u/ds527VndRwhjPbZWQ6i4bqiCHED910Js sgMtPTxfKP7WxzZnEynhI9PD7vojx+sejJxfpY5pD1Sqz+dx2OHy/wDI/wDflcwK6AXZ2Ky1 jGAtsDRuifGtxduZ/Uc9UOnYTb3Put0x6RuskgE/yWq/hZr8jKdaNzMbErO3YGtcB+a5+3bu ShMCeuvCRxf76OVMpGEsxBMz+p9I9z0/Nl4v81j/AOe17mdOwoDq3XvPuBP0HNPETt/7+hDq dbQAzHaAD5ajwd7NrlPHyW5rPs2TBe7WuyNZ/wDSn/nz6Co30vpsdW/6TTyOCOxCPF0AA+n/ AHXzMGacogTw0MUtNIxuMv3J/N6m2MzCskXY0eBbyP8AqHf9JWxj0W4NtGE42mw76geQRtdb Sf5W33sWKtKi1+N0t1jTtfZYCx45BaR/33enxlZPEARRuhX/AEVcvm4jP3ACOCXFIRrJw9Yj +85zmlpIcII5BTLVLauqYlj2gMzaPcQNNzPzo/quWURCja+bD7fCQeKExxQl/wBKJ/rxf//S 856TQ11tmRZ/N4zC8/1j7Wf+TVXJvffa61/LjoPAD6Lf7KvYzhX0TMcPpWWMZ8uVmJNrP6MG CA/Tic0/GUpyxw/8bg2+n3NZY6twBbaNsHie3/VbULJx3UXuqOsH2nxE8oK0qbaM2n0Mg7bm j9FZ+84n87/X/ppw1FHpqP4LMdZIjGTU464763vBZh+ydNLxpbkHQ9w3UN/6l7v+21nGVtZP Trb/AEag9ldVM1utcYAcxrd3/UqsMbpLG/pMlz37ZAYNN0/R0D/zU2fpJsG9qrVsZ+WyExHp hjhERjLJKOMSPzTMeL+tJN0+r9o4D8FoByqj6mO0NJfZ/wAHP8n3onSa39QwcrpW177mNN+M xjGk7mfzoe53vbW1v7ilj/8AN+nIbZjZ2Tiva9rWXFpO1hEZFjvTG/8Ak+mxadeHg5fUqM7p 3o2PsNnq4bXOrqFNTRV62Tdv30Ov/nXsVLLkri0lEH9ZAyj8mWPqr/D/ALy6wIxlKUJGEThy cErGTD04v3eD+u5HWWnAxMbpW17LA0XZLLGtaQ9+oa1zZe6v+uoZFX7O6aKHgDKyjNjdQ+to /MeP5bCtc4GFj9Uuz+q+lWyuysMwy9xaarAa25GPbu33/Z/53Ys/Ms6FkZDr8rNyMu5xc11g bALWjbjOZvbv9233scjjyXwgCUh/OTlGOk8kvXw+n9FV3xzEoxlIezi45CMceH5eL+txR/cc MEgyNCO60M4DJxKswRv+jZ8eHf8AS9//AF1O7H6O/wDmsh7HbQdrxpun3CdrVZZ097MO2hlj LhZYG0PYdHOLd3f+qxW43LYG+1a/Ytw8tk4ckfTkhOO+OccnDkj6sfy+pyKKX32tqYPc4/d5 qxn2tivHr0ZU0SP5UR/1KM91HT6vTqcLMl4Be79wg8LNJkknUnunnQVuTv8Awa8x7UDCwZy+ ev0R+5/3yXFvfRc21vbkeIOjh/mqz1agV3suZ/N5DBYI4n6L/wDpe5UVp5hD+j4Lyfcxz2fK f9ib4r8Pr5fPA/5MDPDzE44p/wCNDI//0/PcUCzomYwfSrsY/wA4OizFe6XkCu19Nn83kMLC PMe5n/kP7ar5eO7GvdS7lp0Pi06sf/aalbaz+vBhyD/JxOGfhITnkh/jQmhhaNNNGHT6+SN9 zx+hr8CD+d/r7EHp9LbLHWP0ZUC6TxMf6vQsnIdfc6w6AnQeAlOFAWdb+VZjrHH3CAZSsY76 VvP/AL11cjqDqmVWmpltNxdZZU4SNzmt3f8AVKsL+jWN/S0Prft+kw6bp5jd+7/JSxx9rwHY 3+FqO6sePJaP+lZX/wBtLOOiZK5kkk2et6tnPzOQcEqjkxzjYjkhGYhP5ckYu3js+rr72100 ZWU8vaW1AxuZE3slvua7+WtOrI6fh9RpwMAUV2NNouyzNlLqLGttZTlM2OsfZV/MP2LH6fae m4L+oMMZVh9PGeHEOrP5z9v5zXt3onTHv6f07J6mXvZfkNOPjPYW67v571Gumza5v7ip5cfF xaykP5uAlL58svTfD8vDBPCJRjGUIxMonNk4I0IYP6373uOm/MwMzqd2D1P0bC99fp5kFtYp raX+hi17Wvp9b+aa9ZmZT0Gm19V2PlYl4c4upkENa4bsdjTZ7/zve96bq739Qwsbqu59lrGi jKe8t+kwfo/TYza/Y1v76hmW/tLpzcuwh2Xjnbc9xJfYD+e6f9Gzajjx8PCQZRH83OMZaQyR 9PFX7slUAJxjCEjGPvY+OOk8NfLH+4iNvRKx7KrLXbRBcdN35/5w9qtDPJwbMmuplLK7ZorA kB23Z5fvrEY1z3ta0bnOIAA5JK0epFuPRTgt1NYmwj946n/pf9QrkbjqJG+9+pGHmZ8GWfDD HCMeH9XCMOLLP+b9Xzen51W10Z9Xq47fTyGACxn7xJ7LNIhEx7n02tsbyOR4j90qx1Cloc29 hltokn+VG7/pNTjRAI0I+b9kmvOssTkqpx/nK/S/r1/02mFp5oFfR8Gs/SeX2ecE/wC1UsTH dk3tqHBkuI7NHue7/NR+q5AtvbWz+boYK2xxPL/+l7U1dh9HL5pn/KAYIf48MuT/ABY43//U 8qGhWq2yvqlFVTyGZlI2NeeHt/M3LKTtJBkGCOCEbZcOb2+IEcWOYqcP3v8A0KLpOptxemPb Y3a+yzaZ5BHI/wA1ZmsrabkV2dP+0ZYN4c4MtA5BE+ld29239GqhxunWEGu81zyH9j/a2e1P lEGuEjbqRH+XzNjmMIPB7chXBHhhI1PhPX91qY9z6bRYzkcjxCv5GMzMZ9qxNbD/ADlXcnxb /L/fZ/1ytBbhY0S/Ja2DBA2zH7zfd7kZl3TcMTUHX2EEOkw0j/obUwR2Nj7f2R9SsUOGJx5j EYjrrL1wl+/j4eNtZOEH+k21xGJiMHqnRrwT9JkO+lthZvUM37VYA0BtVQ21gAN0H5zg385a OffjA14+WLLGBu6t7j7gD23t/nG/u796qHE6W/VmWWeT2g/9+qQlCIl34bon0tjmwZmUMRgO Lh90SnGOQ8A9EP1nD+rh+j6kXT80Yz3NsAdTcNlgIDiAfzm7vzlo4mEarnsrJdiZjDsiHPI/ NYdv0d25Uxi9KYJsynP/AJLGgf8AfrFbwMmix7sPErfXS5pdY5roeY8Xu+i3/MShCJmLNcRA lXqVyo4DGGWUCYn9SIz48nr+fH+r44+1k/SQ1Us6XWb7/dluEV1/ueZ/4T/z1/XWXY91ji9x lzjJWjZb0zLJe8Ox7TAkatgeP00F2Fi6FmS0gmBMAx+873e1OMTvYrz/AGS9TXzxM+GGExOK PyiMvUSf8pk4uD1yaS06KbMrpnpsEvrsAY3uSf8AzFz0P7P02qTZebPBrRz/AJu5W/tFDMCy /FaaDWTXV3JJ2+rc7+Vs/RtTogAniI2NgG7r+7/Wirl8IiZmco1wS4oRN5OHqidbV0zGtorI fl3+2x44a0fS2/1llFIkkydSUkwlr5sxycIA4YQHDjgP0R/30v0n/9XypJJJJTp9LY3KxcjC mLiPUpn84iN1f/RbsWaQQYIg9wp49zqLW2s5aZ+Pkr3UMYX1/tDG91T/AOdjlru+8fvfvf8A biTar3sA4ReTACJAbywfNx/9S/Sc2UpSSSaroZE5GBVcJJo9r9Z00b/Z/NWfKtYWQyp+y3Wp +jvLz/8AJJszDdjuka1P+g4EH+yYTiLHF20l/H5f0mfIDkiMo1IAjk84/LJrLQw5x8O7JI1e NjJMfh+d7v8AqFXw8SzJfA0YPpPMD5a/nKedex7hVUA2uuBprJHn+61IaDi+g/l/VViBxxOU 6bxx+Mv3v8FqJSklCawLjVaee1mJ0+jDmb3/AKS/+T+5X/0veo9Pwgys5+UfTx69WGNXO/ND Gn6SpZN7r7nWu03cNmYHYJW2xE4cMjIVPOOGAPzRw/p5K/1nDwRRJJJJNR//1vKkkkklKVnC z78OzfUdDo9h1a4fuuCrJJLoTlCQnAmMo6iQdU19L6h7qn/YrzzU/wDmyf5D/wA1Au6Nn1al gc3s4EQf7RVGVNl91Yit7mA8hpI/Ik2Dnw5NcuKp9Z4T7fF/excMsf8Aie222dE6o/VtBI8Q QR/0SVcpY3DofVmW1wRApcwuI+H0HrJOReebH68+4ocp0ZUQQPtNj/uExz4MWuLHMyqryT9P +JjjD/pO1YK8vFbTh3VtI0dU1haT8fpuVOzonU2Dc6mG/vEgD/pFqoypjIvaIbY4DwkpSlZJ I8qND/ulHPhyUcuOVgAXinQ0/qZI5G3T0XPt1DA1v7znCP8AObKOKelYHuvf9svHFVejAf5T /wA5Zr77rBFljnjtucT+VQlNQM+DHriw3PpPOfd4f7uLhhj/AMf3Gzm59+ZZvtPtboxg0a0e DQqySSTXnklkkZzkZSlvKW6kkkklr//ZOEJJTQQGAAAAAAAHAAAAAQABAQD//gAnRmlsZSB3 cml0dGVuIGJ5IEFkb2JlIFBob3Rvc2hvcKggNC4wAP/uAA5BZG9iZQBkgAAAAAH/2wCEABAL CwsMCxAMDBAXDw0PFxsUEBAUGx8XFxcXFx8RDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwBEQ8PERMRFRISFRQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAUwBTAMBIgACEQEDEQH/3QAEABX/xAClAAEAAwEB AQEAAAAAAAAAAAAAAwQFAgEHBgEBAAMBAQAAAAAAAAAAAAAAAAIDBAEFEAACAgIBAwIFAwME AwEBAAAAAQIDEQQhMUESUTJhcSITBYFCFKFSI5FiMxWxgsIkQxEAAgEDAAcFBAcFBgYDAAAA AQIAERIDITEiMkJSBEFicqITgpLC0lFhcbIjM0OBkeIUBfDyU3Oz08Fjg6PjNJMkFf/aAAwD AQACEQMRAD8A+fgARAAEQABEAARAAEQABEAARAAEQABEAARAAEQABEAARAAEQABEAARAAEQA BEAARAAEQABE/9D5+ABEAARAAEQABEAARB6dQhKbxFZZep/HrCla8L0L8PTZcp2Rs8x3Z1VL GgFZQjCUniKyWIaN8llrxXxLrt19dYikn6srWbyl0yzX/K9Ni/NyXtyrsyVqjW1fB80fwYR9 8/8AQ8/i1uWI+UiJ7U88JL+p5/MvTypYIHL0g1J5b/vzlV+g/vlmP42U3xFpHUvxMl0kl8yr /N2M582ereu/c8nfV6I60P7rfuSQOKmlX96e2aF0OmJfIglCUXiSwWo7Vcn/AJPJfJlmuOpa vfn4Mj/L4cn5bW+1d5d+AgY7JC/5htmUDRu0KW81zx8Gd06OtBZlPLKh0jlqErTmrO+hkrSg Herse9M6FVk/bHJZr/G3S7pE109avpY38EV3uePsz+rLRi6bH+Ybj4vhSctVTRjd/l/NJv8A qrF15+RHPTcJYaaRx/2Gx2lg5lt3yeXNsl6vRDUh926GOLhDj2pL/EokuJtP4h/jp9YSUiL+ XY+uH+h1Dckn0/0Cv0TaGW36xckiCvaDOJ610PdEixjqaNf5CuXE/wCpJPX171mGMkj0OLIK 9Pku7jTtgO413dbZeZILN2nZW+FlFdprqYcmF8Zo62yBFDQzkAFcQABEAARAAEQABE//0fn4 AEQABEAARAAET0sa2pO9+ke7PdXVdr8pcQXVlq7YjTX4w4j2Xqbum6VbfVzG3HwrzySqKVbQ vmbwztfY1YcYbXcqX7tk3iPC9SvZbKx5kzgZ+uZhZi/CxDlhnJFBspyz1ybeW8s5AMRJOkyM AA5EADAidJc4L+ppZxO2Xj6I91dSMY/csaUn0+Bxs3wrbjW3KXdmvEi49t94eT+OXLjCgZMg 2TupxPJr5adb5bbO669a2v6JtZMltt5fJ1CydbymdXqVvqVoDxcftR6+naRCnJ8sm2taVMsp +UfUrZNOh1Xx92H3iyrtarql5R5g/QhmxDeTxFfiScfGQt66cR8ndaVQAZpVAAEQSV2zreYv BGCSsymqkqfqiaVG/GeIXI6v04WrzqZmFnV25VPDf0noYesXIPS6kBgf1JMODofaHNxrIJ1y hJxkuTk1raqtqGY4U+xl2Vyrk4yWGjP1XSnEQym/E263zTjLb9andacAAyyMAARAAEQABE// 0vn4AEQABEAARBLTU7J46LuyNGjq630c8R6zZo6bD6j6RVV0mdVSxoJ5OxRhxxCPT4soznKc sv8AREuzb9yeI8QjxFEBLqs97WA7C+aCan7J4ADLOQABEAARPS5qasp/5Hwl0yVq63ZNJfqX JznVDL+mK4ijRgTjNO7XzPJ4wtauCyLrtnOzZ9r6FLyk+vwKTeT2UnKTk+rPCvLkLHujVOM1 xJ1TwAFcjJK7JQl5Iv1L78MxeU+sWZpLRbKuXDwn1L8OQg2k693uNJ42CnaFyHeWL6ZUzcZd OxEXrlO2GJrLXMZFFrBzNjtNaUDeVuJZxgAxpW3hu5Z4ACmRgACIAAiWdbYlXJJvjsWb4R2I Z6WR6fEzi7qzdi8c/wCSPt+KN/S5rlOB9pWGiSU8P0yk008Pqjws7VfP3EsZ4kviVjJlx+m5 X3fDIwACuIAAiAAIn//T+fgARAAEQABEs6VLuuUey5Zd/IXxqq+zX36si02qqXP90uEVtqbl bh9j0Qww9Lo/My/HLQwXHQb+Xe/y+WVwAedKoAAiAAIgA6istL1OgVNIl3TxWvPx8pS6EW5d Kyfi+kexc866acRWXFdTLbbbb6s05thAo7dj2U3vPLshKouMNWv4jjvTkAGWUwABEAARNDU2 M1eMl5eP+uCttQUbG4+2XKPdSzwtWej4ZZ3YVyr84dY9Uat/F3qefH/45dpfFpI/BPtWNM4A GWUwABEAARB3XN1zU11RwDqkggjhibFtUdij7sO6+pGS1htPsaP47Y8V4S9vRlXerVd7x7Zc o39WFyYUzLvcftS3JRlVxrOzk8a8UrAA8+VQABEAARP/1Pn4AEQABEAHUFmSXqzoFSBE06Ks Vfcl7YLj5mbJ+Um/Vmtb/wAUaIvlrkj/AIdVEcyXlP0Z6GfFfaqkBUrd/dmh8JNAo0Igvfhv aZqrnL2xbJP4t2MtY+ZejdRSm5NeXaK7EMtyty8mnL0XYo9HGu8feazyyBxoAKuLjwoLrZGt C3x8m0keLTnLiElJndu8rFhx4Fe9GtYjD9TluGmtfeeKYbqBns5qbXuyKWpbHqiKVdkfdFot w26vLymnkn/kVXNJSSj6HRhxtun3WuizGQSHpyqw+KZfJNqw87or9S7fravise9/2nGvo2Kz K9rXUknSsuRToZQdP92c9JwwWl+kbm0s7351xq8K3lt8szVFt8LJqX0a6xGUs47I484Vr6Iq C9X1LMmD1GBLUUDh2pPMp9Rr7U+yU46t8ukH+pItG3u0iSe1DvNy+C4I3tQ7Qb+bIen0y7zV 9r/blewOZp1/1772RyePQnn6ZRZz/Mjn/jQ/lQzzXx8Gcp0v1f8AciqfQ375zLTuj+3PyIpQ nH3Jr5lqO1V6yh/UlVnmusbF6Phnf5fE+43x/wAcUU6jT7ZnxeJJ+hrWVwt13KLXl48orTop n0zXL0fQs160vtpxfKWHgswYWS4GjLolmJGqyhb7kOqZB6k30WS7DVqjZ/mzyWLIUU4cJRSK B0p0lj7sguJiKkhAOY7XuTOjr2v9uPmSLSuxl4SLFu7RJYay/gcR31FOPi3H4g48Q1kftf5J K3CDQuzaN5F+aRR0ZT9s036HktO2MvHjJ6tuKl5KOGSS3oWL64vK6NC3BXWvvNIgYipqWDjV o2WlaVFsesXgjax1NKrcplHwm/k2dKumx+M0pLtJD+XVt00/7i+SS9JTSx1a7hbYZZT0+bHD +5cfMk3MuMXL3R4ZK9Na90bIv6eqOvyUYupWRXuxn5lwxsOndGpoDfPBxMEeotbGVr4WmWAD z5TAAEQABE//1fn4AEQAS00zun4wXzJKpYhVFWMTmMZTeImlraldMPuz5l2OFCupqPSMeZy9 SLY3ZWSSh9MF0NqY8eAVfayfF3PnlqWpUuLnG4ne5nlr6oQnsyWWuIoz7dm215k/0NG+flqq C7xyZDIdSWQBVNAbru80lnY1Ars2q3ttPAAY5RAAET0Au62tFR+7b0/bH1LMWNsjUHtNyzqq SaCe6ldqX3Jy8a169y1K22/6Kvpj/Vla/YS93XtDsiPUvs+85J/U1wbwcYK4SWN317XtfJLk y+mbUJtb8xubwy7ZqKqptySm+76mXbGcZfW8/Eu3znX4yu+pSfJ1ZZrTqSUcp9yeXCmRSgPp NiA2Oa7mWcylWYlR6dOFuOZYJbapVvno+jIjy3VlYqwowlMAAjEHSznjr2CTbwurLmvXClp2 xzJ/0LsGFsjaDao3n5YGukl065TXjbNYfRPqTSpu135VSzH07FbZ2Kk8VL6vX0JqbrK60pLM ZLn5npW4mriqWOL9Vdr3ppxZFQ006Kn1UM52LLbo5g/Ga6x7mdLyy/LOfiW69iNkvGf0zz9M j22lW5TXjauj/uM+ZPVW5Gupo7rezzypzeS9asdcoA6lFxeGsNHJgIpoMrgAHIg7jOcXmLaO AdBINQaRL9O5KzFVnKlwn6FmuMbYy17e3RmbrLN0PmaG/JVKNsOHLBvwuWS9zuXe1jt4ppxO bGZttVtRk7jylsasqZNLlIrmj/JjsRUv/wCkeq9URbGr9P3ql9PdehXl6cMC+LSN63u92Uso qSmlPMvilIAGOQgACJ//1vn4AETuMXKSiurNbXqhrazm/dLuU9anCTfuk+Pkdb+z5NVQf0x4 Z6OBVwYmyvvkbI8ctxkKC53t3H4ueV773Y2l7SAAwu7OxZtcqmrrr7tXk+ijgzbF4za9GW9O 5qmUO65RFt1uM1L+5ZL8u3jDfY3wvLXoceMjWoKv8MrAAyyqACSqt2TUV3JKpYgDtiT6lCk3 ZZ7I/wBWSbF3ivJ9f2R9Ed2ShXHwXsr6/FlCc3OTbNrsMGMKu+fvf4nySbG0WjXxzyUnJ5fU k1p+F0WQnqeGn6GNHKuH7QwaQl7alO2uUmuIvgrUXOqWese6Ljs+7WoRXElyZ8ouMmn1Ru6w lMiZkYk03u9BNTrqZoTf3448V4voyjZXKuTi+xNq3ut+GeH0+ZNs69s63Y1yu69CWUL1OH1V qc673s8MgXIbaI2tUzz08LGrRK6zCWUuWefjRncIutjJEgCpkmvTKCVrjl9kzrZ2XjwSSl3Z 3dbZRBxlw3xFFBtt5fVm/PlGDGMOIm5h+JWRRmIPKZ7FOUkvVmjK9KiUJLDiuCnrL/J54yo8 k+5bFwXjw5dTnS/h9Pky1oW7Odf78sBpWh7vvSiW9e7zSrm8Ne1lM9TafBjxZTjautTvrzQD Q1lu+nzTkl/kj7l6lQv1Wfdr8l/yQ6/FFbYr8ZeUfbLlF/U4wVGVO3e+zmnWHaNRkAAMcjAA ES1o1udja7I73bG4Qg+p3or7aTf7v/BX25qV0sdFwjWdjDT6RT2sm1LTQYRp2nbaHdTdkMZO LyuGamhdC1OuX7uGjKO67JVzUovlEOm6g4nFdOPiEgj2MG183eWTbms6bHjpkrGpfKGxCFna axL5mbZBwk4vsT6vCFa9Py2+KHADGm6dK+GcAAySM//X+fktFbttUPXqRl78fX77H2XBf0uL 1Myqd3ebwrOqKkD6Z3bNVZkv2rxj8zPbbbb6sn255l4/qyuT6zJdktG6n3oJqZ4ADLOSaifh Ys9Hwy5uYt+mPVLMTOL2m1bKKl7o8foacDAgqeyvuNvyzGSQcQ/VK+8sonhZ26vCblH2tlco dCrUkCCCQdYMF7Uh4VStfulxEpRi5SS9TRnitRh2rjl/M09ImkueHQPE0kna3L96VNqfP212 5fzK51JuTbfc5KMr3uW93wyEAAriXdO7EZRfLXQ42q5Jq3GFLqQ1Tdc1JdupqT//AGwjVXH6 cZz8T0sTDP03pMdrFufBKnNjXU2W3mmQa2lLY2q1XB9OGjLtrlVNwksNFjRvsquxB+LlwZ+l c48thqt+w3i4Z3KtyEilw2lrONuiVF8q5LHoX9XU2KddXR+lPltne1+P2bJ1zsXlKT64G9La 1aXVZLClwkakxDE+TIQQNad3mlJyXqiqyFm3vZ3pmbN0rrXJvPZEILGrrysbs8cwhyzAA2bL 3nO1NGhV+oSfXjGqPjNcy5ZV2Jqdjx0XCLu7fV9qPgsTaxj0M35mvrMgVEwLQqmn2eGQx1NX IIrPAAefLZNr2uuzPZ8MtXVqUZQXf6oFA0Kp+eupfug8G3pWuVsbeIeH9SSXTUTOBLsR8bXj o+V+pEZHW1ip4TSRnp1CLnJROcF6nXaoc37mTxJc1Turr+WSVSxoB2Xe7JbnCumM12WEZreX n1J9i1ySrT4j1+ZXO52qba7uvxzuRwzVAooAX3Z4ACmQlrWs4dT6PlfM726/KuNq6riRUjJx kpLsadaVuvOPqso9HpvxsT4jrVdn4JJdNR9VVmUD1rDa9Dw8+hrSRn//0PwBqasfDUz6mWup rvMNM9D+mgBsj8iSePWTyqxmXbLysk/iRnp4YWNzEntMhAAIxBJVZKqamuxGDoJBBHZE1Kow vhNvlNZKF1Trl/tfRnWvfKmX+18NGhGNN2tJvnHQ1gLmXlZfJ/45eAMqgCgyoD/1Zn6kPK+K 9OSfal/jk/7pY/0PdbXlXOU/244ZHsqThWks5yyaq2PAwI29rzfhyvUn2mVQWKtO2xZ9qXVs lp1KpZy28FOPo8zkbNt3PsyND9EpA0KqasvMUkumSXVhU7frUVEuH9PagJyKLjSVNkAroJtm UXvx29LVm+6a4+DLar1rNnE/GNR7PU1rtr7dUUof3EsfTPjYOjg6bdW9K3yowKurW23NI79C 7Zoltd1yZkXKE0+jize2IzoS0KrHJS5ZB+U/FV0VQn5Ytkvac6jGpcFTTKPP/HIYs4FFYgjI fwaD9PvSev8A7LYhGcHmKX0mb+UuvnZGF8syj1L2ptfkqqI108QiuShdXbtbjc3jyaTkcyNk YZE16VX3ttpzCtuRiRjCJW2zflfW1rNmxV1rLNWq6OjXZTZBYxx8ySWpZ+KnXZH28Zfrk6/I 6sbILZbU/LnxLOnRUQlCGycUi+ZcjKCa4H3SN71FmDbY7ZuT7nOH6G1OjSWtGcMK3umcOVH2 VjxVncrPRMxJbILiL9U0LnBGhW12zHBp+NcofUo+RHHXrnBuUcNegP8ATn0WurXC6WK1xIpq lAt6LzKcH+5Baf3E3W+V1TPdWm2vYWVx0bIYsGXHlRiuwxtuXd2tmWLUEEjtnG1HiMvmmVi7 txfhLHaX/kaen9yebOEucHM2FnzUH0C5p2ws9qirEznT1XPNkukeUiS7YddTr/dJndt0aHJL q1hIzpScm2+Ww5XEto3v7fiP8EmxCLap2zcuVvgWcgAySmAAInppfjZZj4/NGYXvxr/yNGz+ ntb1Cjm0SeM0dftlfaj43SX6kJb344uz6lXsPTH87Z2ep/FI02qd62f/0fwC6o07pS/hr4mb HqvmatijLT6ep6X9P/LzjuSaan8EyAAebIQABEAARPSSq6Vb46PqiNLLwi/r6L+3KyfVLhF2 BHLVU228UkqsxooqZYqmpakmlg7prhLWdjWZJYRxG2DpdP7mskT2vs0xg1mM1yekpCtcxASy ntfBNZyYwqXUyUQrq3XnMtr7Nbh4tt9+xVe1bjEfpXwLtNlE6nHKb7ZIo60LU8rxa9DmXHmy W+llFCuyq7Ps+pMrVNNN2j3ZTdk31kzzL9SytNTz4S5XZiGjZY8Rkm12MTdL1OsqWr3rpVco 7aStl+p1G2yLzGTTLMPxt05+EWvL0JK/xcnd9mcvGRFenz/QV9q2ROXGK1YarvZkFW9fXNTz 5Nepcjuy3tmE7k21xjsdy/GVau1Gq76ov93YtfkNSGnOrYox9trlFtrDZyH1SeClzf8AySh8 uFmUKKvkVvTeaFt9Oqq641eX3EsvHqUfy2tVVGMoJpvEl8CWj8vTKv8Ayxi3H2tlHZ3Z71qp zht4/Qqx48gdrtpQdpLt7lmTDiyLkqVKhPzWLb8r7f5e66uNLXEFjLKU9q+aw5vC6I3fymrp 1VVwglK3CTfxZT2Pw8KqI3eeHJZ8S0plcE42ovJ+TNeHNgtWi+nextqJkuUn1bPC8/xV6rVu V4PuyF6Vyj5YzH1Kj03UE7rN5poGRDqYSvl+p3G62PSTJo6c3HyysHdenCScnLKXoTTpeqqL QUrq2rZIEE0Gmc07s63ys56l7RlGycnh4kujIdamheUpRwl0bJNbYhC5pPLlwkuxvwrkQJ6u QOCdkcvtS/CbWQswsru706prjPZnGXKXOCC/YdE5OC+p8Z9DqWwqLJW4y28HVUa9qUs8xa/q VGtCtwv1r3JazK2xj2cvqN7XLtTMlOUm5SeWzgsbGu6m8cx9SuebkVlYht6ZSCDQ9kAAhOQA BEFvQbVywVC7+Oina2zT0X/s4/tkl3l8QnP5Bt3PPYqFv8i197jqVDRUf/oV7/wTv6nt/FP/ 0vn5r1Pz00ZJo6E80zr9Df8A05qZGQ/qIfLJ496nMCsz5LEmvRnJNsw8bM9mQmPKtrsv0GQg AEInoBa0qFZYnL2oki3NT+yidVSzBRrY0kunqrDnP3YykeX7bhX9qD5fVnt1zoUor3S6fIot 55fU0vk9NbU0Ej3F5vHLWYIti6G0jK3N3ZNqTf31n93BLsRzQn/ZLBVhLxmpejL84qanFdJr yiT6fbxMnbtefd88rGlSP2zOzjoSw2LYdJETWDwyK7odliv2SMsw3LIvOFkkq31XLz8OSmeF o6vOABedEiUU6xL7/JyVn3YRxL1D3ti+1SSXn6oo4Nb8XCmmT++uZIuwZM2VqFqJW5tEryKi KWsuYD2pakqZ6Dstt/yx5TMnY3Lr8VuT8FwkNu+MpyhVxWmyPVrVl8Iv255GbKXyDGmsmx3n MWMKCzaeNQf0+7N3Uo/GPXh/I/5EjJ/IqFez5UPEf2tfA0tmrQqlWoNvzeJFf8vr60K4y13n HUsy4TY5B73ufwSjCwGQGuQ+tdRX3Fnn47Zquvh/Kk/p6HX5G2bsk6X5Qj1i+cIyE2nldjX0 Nyj+PZGcc2Ncs502a8HGTY+u7nluXHY3qKC/D6fD4pWf5S6daqmvoXZHE9+UoKtRxFEe1Q4N TSxCfQrlL9R1GNipb6t1dpJauPGQCFH0+1LX83EPCMeDj+ZYl4xwkQHhA9ZnPGRops7MmFA1 SSVs5cOTx6FjQjm1y/tRTNHUj9vWlPvPhEulufMGYlvTBfTJoKsPq0+7INuXCXq2yKm6dMsx ePU92ZZsx2jwQkM2Q+sWU0t2fdnK6a/XWatE674zb5yuUULqnXLK9r6HlNsqpZXTui/412az fVN8MsquVNOhvuN/tvLvzVpoGTGrMW/xFmWDqcXGTTOTKQQSD2SiAAciemh+Mj+71Znmpqr7 dTb/AGrk3f05a5ruQSePfB5dr3ZS3ZeV8vgVzuyXlOUvVnBT6v8A9n1f+ZdIV7Z//9P5+WNO 37dyz0lwyuep4J4nON1ccJiXdivyjLHWHP6FI0NexWOLff6ZFbbodNrj2fQ19XjDKMy6V1N8 EkRUXDUT5pXABhkZ1CLk8Lqy/j+PJdlFc/Mr6sOXZ2iTb1qfjFd1lmrEAmMsRvC75FligBGe tHUr6fxSnbY7Jub6s4AMxJJJPbK4L9FnlXF/urfPyKJLr2fbms+18Mu6fJY+ndbZnQaGe7Vf hZle2XKIDQnWrK3X3jzB+qKLTTw+qJdVjte4DZyeV+JYYUM5ABmnJPrQzPzazGPJb3dmDqj4 rE2uvwOdfFUVGS9yyypdPzsbXRcI9JqYOlAB/Ey73db+5Kitz1I3NUjNT8VrUyUpXy8U+hn1 VuyaXbuzRuetXQpQ9yWEV9Hi3srUtQcXmaczEkWCoL8S8Mqb04Rv8KnmMOjNGqrUu1XOUv8A JJdPiYrbbbfVlrRnW5/bt9r6DBnuzMCB+LuV3V5YyYzYKEizTo4pWnFwk4vsz2qx1zUv9UW9 6qpvzq7dUUCjMjYcug6jcjSxTcoP0zV2LVsxUEuMZRmSTi2n1Rb1LsQlHuuhHtQakp4x5Grq guXCuZTV+PurI41K1WmyJWAB50sklVbsmoLq2aF8o1wUF7a1/U406vtwd8ur4iQbNnk/H9ZH oYx6GAud/J/bGsnupXif7krN5bb7ngBgJrpkILNFjw6m+JdPmVjpSaaa7Esb2sD73hipGqXN qjFUbF1XDKRpef34QXZrkz5xcJuL7Mtzrqf6dlvhaWZQtQybjDzcc4APUm+hnlcl1q/OeX7Y 8stX2eGvjvP/AMHcKPs667Ts6/Ip7Fv3J8e2PCPR/wDXwEfqZB5snyJJkFRTiYeWQAA86Qn/ 1Pn4AESWq11yz2fU1NiuGzrRmuqWMmOW9TbdX+OfMJf0NvSZ1AOLJ+Xk0eGWY2AuVtzJr7rc LytOEoSwzk0J0xubh36wZSnVOufhJYeSrNgKGo0pWnh7rSBUjSZoadcf4zT6vkoXS8rG+3RG hJOmvK4XiZbJdRsqF+v/AE5Zl0LjWlCq/f2p4ADLKoAAiXNe3yioN/XH2v1/2nuzT9xfdrXP 7olRNpprqi7Rf58r3r3R9TdhyLlT0n/t3l78kCCKH9konVcfKaj6stX6ykvuVf8AtEj00len LpHqUjp2XMiNuswo/CyzhBBoZYutj9lvH1R4RQScnhctl/cjGTjGlZ83lo5prevzKOZPqzZ1 GJ82YBtGPGAGyKNnanWBuI+jRdPaI1VwcZcy/cyrsWqcsR4iuhNtbCk/GCx6tFQq6vOoUYMd tia3XilYQBia1nh6m08rqjwGEGhrJTRpsqnX5Nc90Vb6vF+UfY+hxVY65ZXTui996FlaUYZT 6o9JWTqsVrlUy4hs6Npu9IqgBJrrlPWn42xb6Phlnaf3YPC4h0ILdedWJYfj1RdlKDo8Evqk uR06uMWXA+xxaeO7dtlgGsE26LpllrU1nbLzlxXHqxrakrX5T+mtdWWLroVw8IcQX9Snp+np +Ll0KN1TxeLuTqqKXNuffnOzeorjouIooNtvL6s9ssc5Zf6I5KeozHI3dEizFjUzwAFE5AAE TQ/HTXKf7eSDcX+Xz/u5PNOTVuP7lgs/kKvGut9zWBfgJ+hf9Nv45dpbDT/Cb/UmeXdDV87F KXTsc0arUfvTX0rovUnlsrXqeP8Akl29CfTYQh9XLoC7VJFFAIZ9ze8c8/I3pz8IPpwjOPZS cm2+rOTP1GY5XLcPDIuxZix4oABTIz//1fn4AEQABEs07Dg0pcpdH6Ghaq9ipWxw5LqY5LRd OuS8Xw3yjXg6kiiPtA7N0sTJaCrC5G8veWaN8nbpvx90eGjJNeL+zPyfsmuUc7GvRP64rKfd FubCzgEm1kqO63el2bHftAi5VVWTi8UygXZ/j34+cJZiQPVu7LPyMZw5B2XeHamdkZdDAiQA klVZHrFo8VVj6RbOem/K37pGcnqk4vK4ZLHUul0iS1aLk8Skl8CS4cpOgW/bsSQRjqBM9p2P J/2z/oy1T/Hdj814yfDOFqx1pJuKkv7iRvX2ZeEeJruj0ULhRW13H07rfxy/GlDTJbcDs4n3 mnV1DpXnXJOCKOxuTsXgundlqX3KX9ubUl6MilRrWesJEspyNjtxn0rt9WP3WnMoBZggsFdr FXimeeF2X4+f7JKSIpad8f25+R5rdNmGtGPh2pQVYawZXBN/Gu/sZ7HUvl0gyIw5TwP7sUMh JKbpVTUo/wChNH8de/diPzJo6evXzZLyfoi7F02cMGH4VOJjbJBGOmlPt2ZJXZPcwo/qmWft 6+tHM2pT9Cs9iutYrSgvUkrqrsirrZZXVI9AuwGimTLouY/LNOGypBpky0O235aJIdjZUY9M R7RRQsslN5f6I07ZVXJRhBSIbfxyUfJS8X6GbqVyPusCvLu+aUvjdiSp9VV4k3ZnnhZend1i vJfAjdFq6xZiOLIOEyogjWKSIHfhP0Z0ta6XSDOem/K37pyRgs16ds3jhE0NKEZ+L+prq+xN encnTRPt3vdk1xuwqFNPpkGpCUr4tLhPlmg2ti55X0R4yJzqqgqa2vOXDwR7UZUayw8OXU2I npLr2Vud/ll6qqI4JGS218i8PcSc7u1HKjDlR6IzpSlJuUnls8bPDHmztkPKvLM7uXYse2AA UyMAARP/1vn4AEQABEHUXiSfozkHQaGsTYsau1Gv3RX9DMhdZX7ZNfAuUyf2o2Lo14yKNsfG yUfRm3qi1EyKSPs722ssyNdax3rQvuy1VvzhxKKafU9juVqXksr1RSBmGd+0K32icGXIKC47 O73Zev2KLEnHiR7Tt1Ri4z6FAEv5g0pb5nnfWe4tUVPdWXlt11ybg216HNm85PMYpP1KYOHO /YFX9kHLkItuNvLJZ32We6Tx6Emkm7fFPDkuCsSUScLIv4jHkPqqzEnT2yAOkEyzvxsioufV cZK8b7I8ZyvR8l3bcrKWpLmPKZmlnUMyuGViLh92TzADI1K6dra3tqWY7eOscfJki3Vj3NFE 9Ir1eUdoP7JAMw1Ey8t7j3f0H85Y5k8/BFA9JHrcv1ead9R+Yy1Ldz6v5sils2Pp9PyIQVt1 OVuKnhnCSdZJnWXJ88s1FVONHlJ4jGPCM2mPlbFfE0NqyaoeeE+Ei7pjRWc9p+5tSzGBa7Gu yvZzNzTOU5RlmLa+RNHcsXEvqXxKwMy5XXUx/wCErBI1aJf/AOwTj4+Pj8juvb14xby3J+pn AmM7dqr92WDPkrW66nNtS0rq5WeU3hehPZu0+PjBvHczhydPUE02Ro+tpwZXAIB397ml3+eo RxXH9WQS2bZcJ4T9CA9wROfIdRt8GzIs7tQFiaSxpLy2IuT4XLJ9+12L/bnC/Qi04SbbXV8H u9iM4wX7VyaVqvSknir550E+mRwsw8spgAwyEAARAAET/9f5+ABEAARAAETR/GTjLyon0l0I t+h1WZxw+CvVY65qS7Gpa47dHi/+SKyn6no4qZ+mOM/mY9z4ZatGQrxptJ3l4kmODqScW0+q OTzyKGkqgAHIgACIPUzwCJqV3+dKU1lNYyZ1kPCbiWdK5QbhLlPlHu7GE0rK+3Ekan/Ex1A0 73+5LnN+NWLAtj2LeK3hlIAGWUwABEAHUYuTSXVnQKmgiWdPEZOxrOOEdb10ptRfzwTVWVUV +KWZJcsoWzdk5Tfc05NjHb7H+7LWNuMIGreb3Xl5ZGADLKoAAiAAInoR4WdSpWWJy9keWTxo XcKOIwBXRNDTqjr633Z9eqXxMu+x2Wym+7Lm5suUOOF0ivgZ5s63IoVMKbqafllmRhoRd3H5 n42ngAMErgACIAAif//Q+fgARAAEQABE9LerY5Lwzicfa/8A5KZ1GTi011Rbhy+m4PDqbwwD Q1lrar8v8iWJL3r/AOioaNTjswyuLF1XqVdjXdbylwaeqwXD1se0raW+aSYcXCZXABhkYAAi AAInUW4tNdjQphVfDyTSb4kjOJKrXXL4PqXYclptJtB7eVpPGwVqsodeJZ7sUSpm0+nZkWDT /j/ehw/KL6fAoXUzpl4yXyZ3Njobl1cXcadyYyumhsbcaRAAolc9LunrZX3Jvxz0yca2nOz6 5LEexNsONCxnM+yNOLHaL2NvwLzy1EoPUda4x7N7SLbnCP8Ajr/9mVD1tt5fVnhTke5q9g3f DK2NSTSlZ4ACE5AAEQAdKLk8Lls6ASaCJ7GLk1FdWXq61GvD4guZP1Z7ranivKX6sh3NlS/x V+xdfiejjxDp8Ry5N9t1Obu/PJgUFx7d2QX2fcnldFwiIA892LMWPFIQACMQABEAARP/0fn4 AEQABEAARAAESSq2VclKLw0aVV1O1HEuJmUexk4vKeGaem6psJoRfibeT5ZJWK/WOWW9nSlB 5guPQqNY4Zf195NKFvK+JLZq03ryg+f6mp+lxZx6nTsK9uOSsDaU9zimSCzbpWwfHKIHGS6r BgyYciGjKVlf2zkAFcQABEno2JVvGfpfUvfZ/kw4fmu3qZsYSlxFN/Iu6uttRfksxXobOnLt slSy8/L4pbiY7pVsiHgX4ZBdp3VSx4trsybW0LH9c18kWprZ7ywvieuG3KDXlz2wWrgQPUI3 1V/L9mXegoJNMjgfpi2/2pXvsVK8fLMu0UUJzlOXlLlsmu1diLbnFv4ldprqZs7PW0qUX6+L xTO7MTpFtOHlngAM8hAAEQe5O4VWT9sWy5R+Pb+qx4Rfi6XNlOyppzHZWdCljQCsp11TseIo 0aNSumPnZ1OpW0a0cRxn1KF+1O19cI2hMHSC5iM2fl5ZPZTXtv5Fk21uuf8Ajr4ivQpA8MGf O+ZrnPs8sgSSamAAVTkAARAAEQABE//S+fgARAAEQABEAARAAEQS132Vv6X+hECSuyGqkqYm lD8jGXF0f1JP/wA1qzCS+TMo9Ni/1B6UyKuUe60n6h1NR/FNCequvgpfIjjr62cTUolWN1se kmh9219ZM6ep6c68ZH7EecqOxZfjpac3xNr5kv8A1+vHlSizL+5PrkO2x9ZM7/NdMNWHT7sk HSmnGvvNNCfhT0sS+RE9+UeIScvj0KIKn6xjuKE8856jDdNngktmzbY8ykySrdvr4y2iseFA zZA11xrIhiDUE1mhHaVnErHH5k0KKbes4syj1NrozQnWU30D/ttkg/MPU8c1ZaGpjLmv0K89 fVi8Rk5fIqK21dJM8+7L1LP5rpjrxAeyrzrOp1Y1X9rS5DWg1xBv4tk0deqHMvGJn/yLsY83 g4c5Pq2wOrwLu4q/ban3ZEFRwg/bNOW3rVL6fqZVu37J8LhFUFeTr8zii0xL9CQXYilaLyrs rPZScnlvJyAZCSTUmsjAAORAAEQABEAARAAET//T+fgARAAEQABEAARAAEQABEAARAAEQABE AARAAEQABEAARAAEQABEAARAAEQABEAARAAEQABE/9k= --part0_883625790_boundary--